Cluster Upgrades 2 of 2
A cluster software upgrade is essentially an entire software rebuild of your cluster environment. Depending on your storage configuration, it may be necessary to archive all user data onto other media, although in most cases your important data resides on a partition or RAID that can be disconnected and later re-connected. Aspen will take a full O.S. image of each discrete node type to be upgraded, excluding your user data, then install and localize your new distribution and utilities on a single unit of each node type in your cluster. Once the basic functionality of these upgraded nodes has been verified, new images are made of these nodes, and deployed to all the other nodes in your cluster. Regression testing is then performed across the entire cluster to verify baseline functionality.
In almost all cases, your codes must be re-compiled or applications re-installed to operate correctly in your new environment. Once your new environment is stable, user data is restored or re-connected and user testing commences. If desired, Aspen can familiarize your users to their new environment and help them rebuild codes and re-install applications.
There are three ways in which Aspen can perform a software upgrade on your cluster.
- On-site: Aspen can deploy an engineer to your site to perform the upgrade. The engineer will arrive with a baseline image that he or she can then deploy from their laptop. Normally the upgrade images are contained on the engineers laptop, and the laptop can be used to PXE boot the entire cluster and perform an upgrade. If the cluster is in a classified environment and laptops are not allowed, the engineer may utilize DVD or CD-ROM media to upgrade the master node first. After the upgrade is performed, the Aspen engineer will localize the cluster to operate in your environment and assist your end-users in getting codes and applications running in the new environment. This option is preferred, because all local site integration is accomplished by our engineer while they are there, little local site labor is needed, and your cluster is returned to operation more quickly than via other upgrade methods.
- Unit Shipping: In many cases where the complexity of the upgrade is not high, remote access is allowed, and extended downtime is acceptable, you can ship a single master node and one or more nodes of each discrete node type back to Aspen for an upgrade at our engineering facility. You will be asked to perform remote testing and system certification and approve the baseline configuration prior to the units being shipped back to your location. After the upgraded units are returned and re-installed, Aspen engineers will use you or other local site resources as eyes and hands to upgrade the remainder of your cluster.
- Remote Upgrade: This is the least desirable option, and we do not often recommend it. In this case, Aspen will walk you through upgrading the master with an image we provide. We must have remote access to your cluster to even consider this option, and many customers find that the level of technical interaction and time required of them is undesirable.
Cluster Upgrade with 32/64 Bit Integration
Occasionally, a customer requests that an existing 32 bit cluster be upgraded with 64 bit nodes. Building a heterogeneous cluster environment with both 32 bit and 64 bit computing resources is more complex and expensive than an homogeneous cluster upgrade, and introduces some additional complexity to the upgrade process , long term management, and user experience on the cluster.
The basic upgrade process follows the same flow as our hardware upgrade and software upgrade processes, but two complete images, one 32 bit, and one 64 bit, must be built for each of the different discrete node types. Generally, the master node of the installed cluster (which is 32 bit) must be replaced by a newer 64 bit master node which is configured to support both the 32 bit and 64 bit libraries and utilities for the selected distribution. A decision must be made as each utility is built as to whether it can be built and deployed across the entire cluster as a 32 bit application with no loss of functionality, or if it must be built for each specific architecture and reside in different locations on the file system.
If your current distribution or version does not support both 32 bit and 64 bit architectures, a full software upgrade is needed. User utilities such as environment modules or equivalent functionality must be modified or added to manage the end-user environment and allow users to easily switch between 32 and 64 bit computing. Modifications to your current scheduler must be made to separate the 32 bit and 64 bit nodes and allow job submission selection.
User training becomes more critical on a heterogeneous cluster, as the development and execution environment offers more choices. The user must be trained to interact with the environment tools and successfully transition from one to the other. Management becomes slightly more complex, as disaster recovery images must be maintained for each architecture, and the correct image must be identifiable and selectable for node restore purposes. Future upgrades also become more complex, as each architecture must be upgraded separately.
While integrating your 32 bit and the added 64 bit nodes is more complex than a single architecture build, the added benefits to your users of having a single integrated computing resource that contains both your old nodes and your newer nodes may be large. That is why Aspen supports this upgrade path.
Let our experienced engineers help you with your cluster upgrade needs today.
Contact Aspen Systems sales at 1-800-992-9242 for more information.
