Upgrading Sentinet to newer versions

Existing Sentinet deployments can be upgraded in two ways:

  1. Traditional process of using Sentinet.msi installation package and User Interactive configuration wizards for Repository and Node(s) configurations. This process is described below in this chapter.

  2. Automated (scripted) upgrade that uses PowerShell scripts and Sentinet template configuration files. This option can also be used to install and configure a new instance of Sentinet and its components. Please refer to Appendix A in this document for more details on automated and scripted deployments and upgrades.

User Interactive Upgrade

To upgrade Sentinet to a newer version, the currently installed version must be uninstalled and the new version must be freshly installed. New installation will then have to be attached (configured) with the existing Sentinet Repository database. If required by the new version, it will automatically update the existing Repository database schema to a new database schema which is done by the Repository Configuration Wizard. No Sentinet configuration data will be lost during the upgrade process. All physical and virtual services, their policies, access rules, behaviors and other configurations will be available immediately after the upgrade process is completed.

Note

Sentinet product can be upgraded with zero-downtime, if current deployment includes load-balanced instances of the Sentinet components, which is described below in this document.

Follow steps below to execute Sentinet upgrade process:

  1. Uninstall current Sentinet version from all computer systems on which it is currently installed.

  2. Make sure IIS Management console application is closed before proceeding to the next steps.

  3. Install new Sentinet version. Start from the machine(s) on which the Sentinet Repository Web Application must be installed.

  4. Upgrading Sentinet Repository Web Application

    Start Sentinet Repository Configuration Wizard and attach it to existing Sentinet Repository database (select Use existing database option). Sentinet Repository Configuration Wizard will automatically update the Repository database schema if required. If stand-alone Monitoring database was used, attach to existing Monitoring database at the Monitoring Database page. Follow all other Configuration Wizard screens providing the same settings as for the previous installation (typically), or change them to new settings if desired.

  5. Upgrading Sentinet Node

    a. Start IIS Manager console and navigate to the IIS Application that used to have an older version of the Sentinet Node.

    b. Optionally: Delete existing Sentinet Node's web.config file from the physical location that is mapped to IIS Server Node virtual directory. If the old web.config is not deleted, Sentinet Node Configuration Wizard will later identify versions mismatch and will warn the user that old web.config file will be automatically deleted.

    c. Launch Nevatech Sentinet Node plug-in in the IIS Manager console from the Configure Node icon.

    d. Select Create from the right pane Actions screen to start Sentinet Node Configuration Wizard that creates a Sentinet Node in the current IIS Application.

    e. Select existing Node from the Repository Tree. This will re-attach new installation of the Node to the previously created Node. New Node will automatically get all the configuration of the older Node and will be fully operational upon the completion of the Sentinet Node Configuration Wizard.

  6. Upgrading Developer Portal Web Application

    Start Developer Portal Configuration Wizard and attach it to existing Repository database and existing Developer Portal database (select Use existing database option). If stand-alone Monitoring database was used, attach to existing Monitoring database at the Monitoring Database page.

    Follow all other Configuration Wizard screens providing the same settings as for the previous installation (typically), or change them to new settings if desired.

Upgrading Sentinet with Zero-Downtime

Upgrading Sentinet Nodes with zero-downtime assumes that Sentinet Node’s instances are deployed behind an external load-balancer as shown here.

Note

Sentinet Repository Web Application does not have to be deployed behind an external load-balancer.

The upgrade process assumes that a load-balancer can be configured to take Node instances ON and OFF load-balancer’s rotation, while keeping at least one Node instance in rotation at any given time. This would allow all API calls to flow through at least one active Node instance while Sentinet is undergoing an upgrade. Only monitoring data can be lost for a brief period of time. The process below describes this scenario with two load-balanced Node instances, A and B.

  1. For each Node instance find Node’s web.config file and change autonomous attribute in their configuration to true as shown below. Both Node instances in this case will stop sending monitoring data to the Repository Web Application instance(s).

    <nevatech.vsb.runtime>
 <node … autonomous="true" … />
    Note

    This step is optional, it does not affect the upgrade process. Temporarily changing web.config prevents Node server’s Event Viewer from being flooded with error messages, while Node is being upgraded.

  2. Upgrade Repository Web Application instance(s) first.

  3. Configure load-balancer to take Node instance A off the load-balancer rotation. Now all traffic goes through Node instance B.

  4. Upgrade Node instance A. Make sure after an upgrade its web.config is configured with autonomous="false".

  5. Configure load-balancer to take Node instance A back to the rotation (first), and to take Node instance B off the rotation (second). Now all traffic goes through Node instance A and monitoring is also going through the Sentinet.

  6. Upgrade Node instance B. Make sure after an upgrade its web.config is configured with autonomous="false".

  7. Configure load-balancer to take Node instance B back to the rotation. Now all traffic goes through both Node instances A and B, and each Node instance delivers monitoring data to the upgraded Repository Web Application.

Appendix E of this document describes advanced Node Instances Synchronization configuration, which allows load-balancers to automate Node instances rotation.