We recently completed a project to virtualize a sizeable number of AlphaServers which, during the virtualization process, were relocated to another site without stopping the applications.
The virtualization was routine, but the non-stop aspect was kind of special. This is how we did it:
The starting point was to replace a number of ES45 clusters in the various regional offices of the customer. They wanted to get rid of the old Alpha hardware and move to more modern and standard equipment (x86). There are only two ways to do that: software migration or Alpha virtualization. First they explored the migration option, which caused major stomach-pains across the board. Virtualization was a much more elegant and less complicated way to achieve their goals.
They looked at the alternatives available and decided for vtAlpha: reliable, secure and fast. With HPE ProLiant Blade systems and 3PAR storage as host hardware. vtAlpha hides the architectural differences of the new host environment from the existing Alpha based software. This way they could use a modern 3PAR SAN, even though that isn’t supported by their OpenVMS version.
Image may be NSFW.
Clik here to view.
As mentioned, the virtualization part is easy: install vtAlpha, copy the Alpha disk content to the new hosts, boot from the copied disks and continue to work. However, the regional systems were to be relocated to sites that were about 30 – 50 miles away and everything had to be done without stopping the applications. The customer operation had to continue, a non-stop transition!
The combination of vtAlpha and OpenVMS clustering allowed us to pull this off.
First, we installed vtAlpha on the (centralized) host system, created a virtual equivalent of the AlphaServers to replace, set up a (long-distance) network and FibreChannel link to marry the regional AlphaServers with the central virtual Alpha(s) in a cluster. The OpenVMS shadowing ensured the data was synchronized to the vtAlpha systems. When all data was duplicated, the decentral cluster members were turned off and the vtAlpha cluster continued the operation.
We used HPE Fibre Channel over IP devices to ensure high data transfer speed levels during the shadowing operation, to avoid that user access during that operation would become sluggish because of the distance/latency. After all, an OpenVMS shadow disk operation is only completed when fully executed on all shadowset members, including the ones far, far away.
After some careful planning it was a smooth transition process that we managed to repeat for all the regional offices. The customer is currently running their operation of a fully virtualized vtAlpha environment without any problems. Another happy vtAlpha customer.
Contact us when you like to hear more about this kind of virtualization projects.
