The release of AirWatch 8.3 will include a new version of the Remote File Storage (RFS). This article will detail migration and upgrade considerations for environments using previous versions of these components. AirWatch 8.3 is still compatible with previous versions of RFS and Content Rendering Engine (CRE), so an upgrade of these components can be done at your discretion.
With the release of RFS 2.3, we will see the following two significant changes:
- RFS 2.3 will be supported on both Linux and Windows servers*
- RFS 2.3 will no longer use Redis. This functionality is replaced with Hazelcast
It is important to note that CRE will still have a dependency on Redis. If using CRE, depending on your current configuration you may need to leave the current Redis database installed, or re-run the CRE installer to create a new instance of Redis. Please see details on this below.
Hazelcast, which is replacing the functionality provided by Redis in previous RFS versions, is directly integrated into the RFS-Tokens and RFS-Files components and so you will not be prompted to install separately. For details on the network and port requirements for Hazelcast, see the “Remote File Storage with Content Rendering Engine Install Guide” available in the AirWatch Resources portal.
If you are currently not using RFS or CRE, please follow the configuration and installation steps found in our Install guide. If you currently have CRE and/or RFS installed, please follow the guidelines provided below.
If currently using RFS 1.x on Windows:
Because of the significant changes between RFS 1.x and RFS 2.3, it is recommended to completely uninstall the RFS 1.x instance from the Windows Server prior to upgrading to RFS 2.3. The RFS 2.3 upgrade can then be treated as a fresh installation.
When upgrading from RFS 1.x you have the option of installing RFS 2.3 onto the existing Windows Server(s), or migrating to Linux. If planning on using the CRE, which is only available for installation on a Linux server, it is recommended that you also install RFS on a Linux server(s).
If currently using RFS 1.0 with the “Access via Content Gateway”** option, this indicates that the RFS server is not directly accessible from the internet, but is instead installed on an internal network behind the AirWatch Content-Gateway. When using RFS 2.3 it is not currently recommended or supported to use this option. The server(s) on which RFS 2.3 is installed should be accessible from the internet via a load balancer; for more details see the Network Requirements section in our RFS 2.3 installation guide.
If currently using RFS 2.0-2.2 on Linux without CRE:
RFS versions 2.0, 2.1, and 2.2 only support installation on a Linux OS server. When upgrading from any of these versions to RFS 2.3 (which supports both Windows and Linux) it is recommend to continuing using the Linux platform and not migrate RFS to a Windows server.
RFS 2.3 can be installed directly on top of the existing RFS instance. During the upgrade process the installation wizard will detect that Redis is installed, and will prompt you on whether to uninstall or to leave installed. RFS 2.3 has removed any dependency on Redis, and so the Redis component can be uninstalled from the server.
If currently using RFS 2.0-2.2 on Linux with CRE:
RFS versions 2.0- 2.2 and all versions of CRE only support installation on a Linux OS server. When upgrading from any of these versions to RFS 2.3 (which supports both Windows and Linux) it is recommend to continuing using the Linux platform and not migrate RFS to a Windows server.
RFS 2.3 has removed its dependency on Redis, however CRE still requires Redis. Depending on your current configuration it may be necessary to re-install Redis, or make no changes and leave your current Redis instance installed. Consider the following examples:
Example 1: RFS 2.2- (consisting of RFS-Files, RFS-Tokens, Redis, and optionally HAProxy components) is installed on one or more Linux servers. CRE is installed on a separate server from all of these components and is using the same instance of Redis used by RFS. When running the RFS 2.3 installer it detects that Redis is installed and we see the following prompt during the installation process:
We enter “N” to leave the current Redis instance installed.
When upgrading CRE, we choose to only install the CRE component instead of both CRE and Redis, and configure CRE to use the existing Redis instance which has remained installed on the RFS server.
Example 2: RFS 2.2- (consisting of RFS-Files, RFS-Tokens, Redis, and optionally HAProxy components) is installed on one or more Linux servers. CRE is installed on a separate server from all of these components and has its own instance of Redis installed. When running the RFS 2.3 installer it detects that Redis is installed and we are prompted if we want to remove Redis (see example prompt above). We select “Y” and uninstall Redis from the server.
When upgrading CRE, we choose to install both of the existing components, CRE and Redis, onto the server.
Load Balancing: When using RFS it is required that incoming traffic from a single port (443 by default) is directed to the correct servers and ports for the RFS-Files and RFS-Tokens endpoints.
The RFS installer on Linux provides us with the option to install HAProxy, a service that can do this filtering and redirection for us.
The RFS 2.3 installer on Windows does not include HAProxy, and so you must provide a load balancer or equivalent in order to properly filter and redirect requests. For more details on requirements and architecture considerations, see our RFS 2.3 Installation guide.
File Storage Path: If migrating RFS to a new server (such as migrating RFS 1.0 on Windows to RFS 2.3 on Linux), please ensure that your existing RFS File Storage location is accessible from the new RFS instance. For details on network requirements, see our RFS 2.3 Installation guide.
*For up-to-date information on supported operating systems, see the ‘Remote File Storage with Content Rendering Engine Install Guide’, available at http://resources.air-watch.com.
**Previous versions of AirWatch showed the option as “Access via MAG” instead of “Access via Content Gateway”. The functionality provided by MAG has been migrated and renamed to Content Gateway in AirWatch 8.3.