On This Page
Classic to Aurora - Start Here
Overview
Upgrading from TOS Classic to TOS Aurora? Start here.
Avoid delays and errors. Read the process carefully before you start. Understand the preparations and checks you need to make.
DIY or PS?
There are two ways to upgrade from TOS Classic to TOS Aurora
-
Do it yourself. In this case we get you started and then you continue independently. You will send us your current system configuration so we can give you the sizing (resources) you need to upgrade to TOS Aurora You will need to download and run the free Tufin Upgrade Planner on your TOS Classic setup, which will analyze your current system. Based on this analysis, Tufin engineers will email you the sizing requirements and from there on, you do it yourself.
-
Hire a Tufin Professional Services (PS) engineer / Tufin partner to guide you through every step. This is an optional paid service and is not included in your maintenance agreement. If you have questions, email us at [email protected].
Whatever decision you make, you must thoroughly learn the process from these pages before you start; you must understand the preparations and checks you need to make to avoid delays and errors.
Upgrade Path
-
This procedure supports upgrading from TOS Classic R21-2/R21-3 only. If you are on an earlier release, you must first upgrade it to the latest hot fix of one of these TOS Classic releases.
-
If you are running operating system TufinOS 2.x (TOS Classic R20-1 and earlier), the upgrade procedure to TOS Classic R20-2 or later will include upgrading to TufinOS 3.x.
Examples:
TOS Classic R18-1 > TOS Classic R19-1 > TOS Classic R20-1 >TOS Classic R21-2 > This procedure
TOS Classic R18-3 > TOS Classic R19-3 > TOS Classic R21-1 > TOS Classic R21-3 > This procedure
TOS Classic R19-3 > TOS Classic R21-1 > TOS Classic R21-3 > This procedure
TOS Classic R21-2 > This procedure
For all upgrade paths, see TOS Classic to Classic and TOS Classic to Aurora.
Platforms
TOS Aurora can be deployed on a new VM setup, AWS, Azure, or Tufin appliances. In some instances, we can repurpose the VMs or appliances you are currently using for TOS Classic.
TOS Aurora runs on a new architecture and infrastructure, compared to TOS Classic. Many TOS Classic functions have been improved or replaced entirely with brand new TOS Aurora functions.
The upgrade procedure is run only on SecureTrack central servers and SecureTrack remote collectors, not on distribution servers or standby servers. If SecureChange is deployed on a separate server, some additional steps are involved to transfer the data.
You can install TOS Aurora to the same server/VM as your current TOS Classic server if it meets the requirements of TOS Aurora. These requirement will be detailed in your sizing requirements email, based on your current TOS Classic setup and in the workprerequisites detailed later in this procedure. Otherwise, you will have to install on a new server.
Once the upgrade process is complete, there is no going back; the old TOS Classic system will no longer be usable.
Architecture
TOS Classic
TOS Aurora
No More Separate Server for SecureChange
In TOS Aurora, SecureChange is installed on the same cluster as SecureTrack. When upgrading a deployment of TOS Classic in which SecureTrack and SecureChange were installed on separate servers, the resulting TOS Aurora cluster contains both applications. There is no option to install SecureChange on a separate server or on a separate TOS Aurora cluster. High performance achieved from using the Kubernetes micro-service infrastructure.
However, if you want to separate user access to SecureTrack and SecureChange, this can be done using a reverse proxy.
High Availability
If you have a TOS Classic HA (high availability) setup, you will be instructed to uninstall it at the appropriate stage of the upgrade. Only active servers are upgraded, not standby servers.
High availability is implemented in TOS Aurora differently than in TOS Classic. There is no manual failover and no notion of active/standby. In TOS Aurora, three nodes in the cluster are active and failover is only automatic. HA can be set up only after you have completed the upgrade to TOS Aurora - see High Availability.
In TOS Aurora, high availability can be enabled on TufinOS and RHEL/CentOS operating systems.
SecureTrack/SecureChange Scripts
If you have any Tufin Professional Service scripts or customizations, Tufin Professional Services can adapt them for TOS Aurora. Consult with Tufin support or your Tufin Professional Services representative before commencing with the upgrade.
If you have any scripts or customizations made independently by your own organization, some will be unusable, and others will need to be adapted to work on TOS Aurora. More information is given in Prepare.
Tufin Extensions (formerly Tufin Marketplace)
If you have Tufin extensions, you will need to backup your data and then reinstall and restore the data when the upgrade has completed. Instructions are given at the appropriate stage.
Distribution Servers
Distribution servers are not upgraded. TOS Aurora,uses a new highly efficient microservice-based architecture, which is initially deployed on one server, called the primary data node. If more processing power is needed, additional servers, called worker nodes, will be added and then TOS Aurora will automatically distribute the services to achieve optimal performance. If you need worker nodes, this will be detailed in your sizing requirements. For more information about nodes, see Distributed Processing.