vADC Docs

Upgrading and reinstalling SteelApp Traffic Manager Virtual Appliances

by jbrookman on ‎07-31-2014 02:07 AM - edited on ‎07-09-2015 06:43 AM by Matt.Thomson (6,413 Views)

In many cases, it is desirable to upgrade a virtual appliance by deploying a virtual appliance at the newer version and importing the old configuration.  For example, the size of the traffic manager disk image was increased in version 9.7, and deploying a new virtual appliance lets a customer take advantage of this larger disk.  This article documents the procedure for deploying a new virtual appliance with the old configuration in common scenarios.

 

These instructions describe how to upgrade and reinstall Brocade Virtual Traffic Manager appliance instances (either in a cluster or standalone appliances). For instructions on upgrading on other platforms, please refer to Upgrading Stingray Traffic Manager.

 

Upgrading a standalone Virtual Appliance

 

This process will replace a standalone virtual appliance with another virtual appliance with the same configuration (including migrating network configuration). Note that the Brocade Virtual Traffic Manager Cloud Getting Started Guide contains instructions for upgrading a standalone EC2 instance from version 9.7 onwards; if upgrading from a version prior to 9.7 and using the Stingray Application Firewall (now Brocade Virtual Web Application Firewall) these instructions must be followed to correctly back up and restore any firewall configuration.

 

  1. Make a backup of the traffic manager configuration (See section "System > Backups" in the Brocade Virtual Traffic Manager User Manual), and export it.
  2. If you are upgrading from a  version prior to 9.7 and are using the Stingray Application Firewall, back up the Stingray Application Firewall configuration
    1. Log on to a command line
    2. Run /opt/zeus/stop-zeus
    3. Copy /opt/zeus/zeusafm/current/var/lib/config.db off the appliance.
  3. Shut down the original appliance.
  4. Deploy a new appliance with the same network interfaces as the original.
  5. If you backed up the application firewall configuration earlier, restore it here onto the new appliance, before you restore the traffic manager configuration:
    1. Copy the config.db file to /opt/zeus/stingrayafm/current/var/lib/config.db (overwriting the original)
    2. Check that the owner on the config.db file is root, and the mode is 0644.
  6. Import and restore the traffic manager configuration via the UI.
  7. If you have application firewall errors
    1. Use the Diagnose page to automatically fix any configuration errors
    2. Reset the Traffic Manager software.

 

Upgrading a cluster of Virtual Appliances (except Amazon EC2)

 

This process will replace the appliances in the cluster, one at a time, maintaining the same IP addresses. As the cluster will be reduced by one at points in the upgrade process, you should ensure that this is carried out at a time when the cluster is otherwise healthy, and of the n appliances in the cluster, the load can be handled by (n-1) appliances.

 

  1. Before beginning the process, ensure that any cluster errors have been resolved.
  2. Nominate the appliance which will be the last to be upgraded (call it the final appliance).  When any of the other machines needs to be removed from the cluster, it should be done using the UI on this appliance, and when a hostname and port are required to join the cluster, this appliance's hostname should be used.
  3. If you are using the Brocade Virtual Web Application Firewall first ensure that vWAF on the final appliance in the cluster is upgraded to the most recent version, using the vWAF updater.
  4. Choose an appliance to be upgraded, and remove the machine from the cluster:
    • If it is not the final appliance (nominated in step 2), this should be done via the UI on the final appliance
    • If it is the final appliance, the UI on any other machine may be used.
  5. Make a backup of the traffic manager configuration (System > Backups) on the appliance being upgraded, and export the backup.  This backup only contains the machine specific info for that appliance (networking config etc).
  6. Shut down the appliance, and deploy a new appliance at the new version.  When deploying, it needs to be given the identical hostname to the machine it's replacing.
  7. Log on to the admin UI of the new appliance, and import and restore the backup from step 5.
  8. If you are using the Brocade Virtual Web Application Firewall, accessing the Application Firewall tab in the UI will fail and there will be an error on the Diagnose page and an 'Update Configuration' button. Click the Update Configuration button once, then wait for the error to clear.  The configuration is now correct, but the admin server still needs to be restarted to pick up the configuration:

    # $ZEUSHOME/admin/rc restart

    Now, upgrade the application firewall on the new appliance to the latest version.
  9. Join into the cluster:
      • For all appliances except the final appliance, you must not select any of the auto-detected existing clusters.  Instead manually specify the hostname and port of the final appliance.
      • If you are using Brocade Virtual Web Application Firewall, there may be an issue where the config on the new machine hasn't synced the vWAF config from the old machine, and clicking the 'Update Application Firewall Cluster Status' button on the Diagnose page doesn't fix the problem. If this happens, firstly get the clusterPwd from the final appliance:
        1. # grep clusterPwd /opt/zeus/zxtm/conf/zeusafm.conf
          clusterPwd = <your cluster pwd>
        2. On the new appliance, edit /opt/zeus/zxtm/conf/zeusafm.conf (with e.g. nano or vi), and replace the clusterPwd with the final appliance's clusterPwd.
        3. The moment that file is saved, Brocade vWAF should get restarted, and the config should get synced to the new machine correctly.
      • When you are upgrading the final appliance, you should select the auto-detected existing cluster entry, which should now list all the other cluster peers.
      • Once a cluster contains multiple versions, configuration changes must not be made until the upgrade has been completed, and 'Cluster conflict' errors are expected until the end of the process.
  10. Repeat steps 4-9 until all appliances have been upgraded.

 

Upgrading a cluster of STM EC2 appliances

 

Because EC2 licenses are not tied to the IP address, it is recommended that new EC2 instances are deployed into a cluster before removing old instances.  This ensures that the capacity of the cluster is not reduced during the upgrade process.  This process is documented in the "Creating a Traffic Manager Instances on Amazon EC2" chapter in the Brocade Virtual Traffic Manager Cloud Getting Started Guide.  The clusterPwd may also need to be fixed as above.

Comments
by ITSystemEngineer
on ‎09-28-2015 04:47 PM

Thanks for the great article,

 

So by using the article above to Upgrade a cluster of Virtual Appliances, is there any downtime involved or it will be transparent to the users ?

by ChristopheH
on ‎10-19-2016 08:05 AM

Hello

 

Just wanted to add 2 things:

If you are restricting the access to the machine with the dedicated IP of you members of the cluster, the IP of the machine you are removing is removed from the restricted access so before (re)joining the cluster make sure to add manually the IP again in the other members of the cluster

 

And if you are making an upgrade between 2 different versions and you do have extra files they are not copied because of the folders path being zeus/$version$/yourfiles...and if you have 2 differents versions not working so a scp is necessary

 

It is transparent for users if you make sure that you have no traffic on the node you are exiting from the cluster

 

Kind Regards

by Nishant
on ‎11-05-2016 10:07 AM

I have the standaalone VTM

 

How I can check the the application firewall is enabled or not?

 

and during the export of config backup there is option of include the application firewall or not  . what i need to do on that?

 

and same for the import ?