|
|
When a new worker joins a fabric or new packages are deployed, an exchange process ensures that all workers maintain the same version of fabric software, configuration files, FAR files and applications. An administrator can easily upgrade an entire fabric without having to touch every (or any) machine. The files with the highest version numbers are always considered to to be the latest. A machine with newer fabric software, but older configuration files or applications, will deploy the newer system software into the rest of the fabric and then receive the latest configuration files and applications. |
Upgrade Methods
As with other fabric operations, a production fabric can be updated while continuing to process requests.
Generally, there are two methods for upgrading a fabric:
- Deploy the .upgrade file - this will spread a package containing Appistry's services and files to every worker in the fabric.
- Introduce an upgraded worker to the fabric - a worker with newer fabric services will automatically exchange its files with other workers in the fabric.
When a fabric worker receives newer versions of fabric services, the fabric keeper service and fabric system service will update using a rolling update process that progresses at the rate allowed by the keeper leader and the concurrent-shutdown-threshold. This process ensures that a faulty update cannot take down an entire fabric. After the fabric keeper service is updated, it will update storage, request, process and task services as required. When all files and services have been updated, the worker's fabric keeper service will signal the keeper leader that it has completed the upgrade and another worker may proceed.
It is always a best practice to thoroughly test all applications and services with the new version before upgrading a production fabric. Appistry recommends using a test fabric with five workers to ensure stability.
Administrative Utilities
The fabric_ctl, log_monitor, fabric_user, fabric_pkg, stor and fabric_gac client tools are considered to be administrative utilities: they are installed as part of the 'Administrative Utilities' package or the full installation of the product. They are not essential to a fabric worker installation and are not considered to be part of a worker (even though they reside in the 'FABRIC_HOME' directory). Client tools are not upgraded through any of the Upgrade processes. They must be reinstalled using the installation package.
Upgrade a Fabric That is Using Storage
Upgrading from CloudIQ Platform v4.2
If you are running Storage on CloudIQ Platform v4.2 and wish to upgrade, be sure to delete the storage FAR (and ensure all workers are finished with the delete process) before following any of the upgrade procedures. All of your data will remain intact and come up under the new system.
Upgrading from CloudIQ Platform v4.3 or v4.4
New Keeper Creates 'installation.properties'
The storage.cfg properties 'mountPath', 'metadataPath' and 'freeSpaceMin' have moved into installation.properties. They are individually configurable, per worker.
| storage.cfg property |
installation.properties property |
| mountPath |
storage-files-path |
| metadataPath |
storage-metadata-path |
| freeSpaceMin |
storage-min-free-space |
When a new fabric keeper service comes up:
- IF the installation.properties file does not exist, it will create an empty one
- IF the installation.properties file is missing a property, it will attempt to read the storage.cfg AND write the corresponding properties to the installation.properties file.
- IF a property does not exist in the storage.cfg, the keeper service will write the default value to the installation.properties.
When Storage Nodes Have Millions of Files
If Storage is loaded with a large number files (e.g., one million or more files per node), it is recommended that Storage be stopped prior to the upgrade process. The storage system can then be started following the upgrade deployment (which should be very quick with storage stopped). If storage is not stopped, the upgrade process should still succeed, but it may take a very long time (due to the length of time that storage will take to stop and start again with that many files) and the upgrade behavior may appear odd.
Deploy an Upgrade File
You can deploy a '.upgrade' file from the Management Console Home page:
- Click Actions --> Deploy Files and browse to an 'appistry-cloudiq-[version]-[distribution].upgrade' file with a higher version value than the current platform version. Click Open.
- A File Uploads dialog will display; select Ok to acknowledge the completion of the upload or any errors that occur.
- View and confirm the new platform Version on the Home page. Contact Appistry Customer Support with any issues.
- Deploy the .upgrade file to the fabric using fabric_ctl deploy appistry-cloudiq-<version>-<OS>.upgrade:
- (Optional) Watch the deployment using log_monitor or the Management Console.
- Use fabric fabric-version-detail all to verify the new version:
Uninstall the Platform to Prepare a Clean Installation
Optionally, you may uninstall the fabric software from a worker before installing the new version.
- On Windows platforms, remove Appistry's services by by going to "Add or remove programs" and selecting "Appistry CloudIQ Platform".
- On Linux platforms, remove Appistry's services by issuing the command 'rpm -e appistry-cloudiq'.
Reinstall the production using the Windows Installation or Linux Installation instructions.
