Take a legacy ERP system running on five servers and virtualise it.
Global manufacturing and controls company.
A legacy ERP system spread over five NT4 servers with no maintenance and no support.
Consolidate the five physical servers into a single server and then virtualise it. Virtualise the clients.
- VMware ESX
- VMware P2V
- 16+ years NT experience
Exmos took a legacy ERP system running across five ageing NT4 servers and virtualised it. This immediately removed the dependency and costs
of five physical servers and introduced a, never considered achievable, level of high availability. More importantly, the historical data
in the system is protected on an ongoing basis.
The Business Problem
This manufacturing company based in England had a requirement to keep a legacy ERP system operational while they went through the process of looking for a replacement. Once that replacement was found, it was still unclear whether it would be feasible to port all the legacy data into the new ERP system from both a technical and cost perspective.
At the same time, the legacy system required five Windows NT 4.0 servers to run, all of which were old and long out of warranty. Finding spare parts was becoming difficult as were the skills to keep such an old system operational. The ability to re-install on new hardware was no longer possible and the vendor no longer had people who could provide support. However, the skills did exist within the company to perform the day to day running of the application. Given it had been in use for so long, it was a considerable time since any new, never before encountered, problems had occurred. One final remaining issue was the dependency on a specific make/model of laser printer (Kyocera) for all the document printing. This was also becoming a headache in terms of keeping these printers running and sourcing parts/replacement units.
The business issues were several:
- Keep the system operational on NT 4.0.
- Reduce the number of servers required.
- Remove the dependency on a single type of printer.
We had already encountered some compatibility/upgrade issues a number of years earlier in moving the company's workstations from a mix of Windows 95/98 and NT 4.0/2000 up to Windows XP. The ERP client software would only install and work on either Windows 95/98 or NT 4.0. The solution we put forward on that occasion was to virtualise a Windows NT 4.0 Workstation installation, load a fresh install of the ERP client software plus other associated applications and then clone/deploy this to the various users. This was working exceptionally well, especially when considering the whole virtualised operating system worked comfortably in 64Mb of RAM. With such a low resource requirement, it was very easy for the user to open the virtual machine and have it running all day long. After all, it was consuming considerably less memory to run the whole virtual computer than Outlook was using to handle e-mail!
We did discuss the possibility of doing a bare-metal backup/restore onto some new server hardware, but we felt this would be overly complex as well as the ongoing difficulties in many new components stopping to have NT 4.0 driver support. This would also have only deferred the problem as once that hardware became obsolete, the issue would again rear its head (given they want to keep the legacy data).
We put forward a proposal to not only virtualise the server back-end of the ERP application, but to reduce the whole system to run on a single server. We had already ascertained that the five server configuration was overkill. This could be traced back to the division pre-acquisition where they belonged to a very large organisation and this was the standard configuration deployed to everyone. We had already made obsolete two of the servers and had become comfortable with some aspects of how the system operated. Finally, we proposed to do the whole exercise remotely (in order to avoid travel costs) and to prove the system would work, without the purchase of any additional hardware or software (and without retaining any of the legacy server hardware).
This exercise would also be different from the workstation virtualisation in that we would have to do a physical to virtual migration of the live database server - there was no scope for doing a fresh install of the application and a backup/restore of the database. The configuration was not only complex, but very bespoke and largely undocumented.
Having completed the physical to virtual migration, we then proposed to consolidate all the print server functionality (using a legacy version of a printing application called "JetForms") onto the new server along with making it a Primary Domain Controller (PDC). Moving the printing would require a considerable understanding of how that printing configuration was modified (also undocumented and something we had been warned of as being "out with our capabilities").
Ideally we would have liked to virtualise onto our preferred VM platform - VMware VI3 (ESX). However, given our constraint (self imposed) of no additional hardware we chose to virtualise to the VMware Server (no software cost) platform. This allowed us to install the virtual machine (VM) on an existing server which we considered to have sufficient disk and processing resource spare. With most servers now shipping with 4Gb+ of memory, the paltry 512Mb that this server required would go almost unnoticed.
We had a slight advantage in this project in that (with agreement) we had about 18 months earlier taken an image copy of the main server system partition and hand-migrated it into a VM environment as a proof of concept test. Although somewhat akin to brain surgery, it allowed a proof of concept clone of the main server to be booted (albeit it did not have the ERP application or data available).
VMware's physical to virtual migration tool was used to take an image of the system partition on the main database server. This was then shipped on a physical drive (along with a backup of all the data partitions) to our offices for virtualisation. We also did the same with the primary domain controller (PDC). Having converted the main server, we then had to perform additional configuration steps to remove the original OEM's system tools/utilities and also carried out a general housekeeping exercise. A specialist tool was then used to convert the machine into the primary domain controller for the domain.
The application and data partitions were then created and the necessary data copied into place. Once the application was operational, we then started testing (using a virtualised workstation). Having satisfied ourselves that the application was working correctly, we then set about migrating the printing from its own server into our single core server and at the same time, switching the printing to use a generic HP driver (thus opening up printing to any HP laser, or laser that supported the HP PCL emulation - in other words, pretty much anything mainstream). In some respects, re-working all the application printing was more complex than the migration of the server to a virtual environment.
We then went through a phase of user acceptance with key users from each department accessing a test workstation remotely across our VPN. As well as confirmation that all the functionality was working as expected, we also started getting feedback that the system seemed considerably quicker.
The finished virtual server was then shipped back to the customer site on a physical disk. We then remotely installed that onto the target server for some final testing. At close of business on a Friday, a backup from the live system was restored into the new virtual server ready for live running on the Monday. Some final configuration changes were made to point to the various printers, plus some new (HP) ones.
Reduced power, cooling and maintenance costs
The customer was firstly able to finally dispose of five old servers, all of which had large, redundant power supplies and were stacked full of disks. This was beneficial both in terms of power consumption, cooling requirements plus server room space. They also immediately dispatched the headache of having to try and maintain those servers and some ageing laser printers.
They also no longer had the problem with dependency on these old servers. The virtual machine technology is hardware vendor agnostic. We can take that virtual machine and copy it from a Dell server to an HP server and it will run with no configuration changes whatsoever.
One of the key benefits is the improved capability for business continuity.
In addition to the standard ERP data backup (as they have always done), the actual server image itself is also backed up.
Recovery onto a backup server could be done in a a very short period of time compared to having to deploy to a fresh server.
In the process of performing both the virtualisation and the consolidation to a single server, we have been fortunate enough to have explored many configuration aspects of the system. This has now been fully documented and presented to the company.
Finally, the application is now faster and more stable than before.
After running in this configuration for a number of months, the virtual server was then re-homed onto a new VMware Vi3/ESX server. This involved another migration (this time virtual to virtual) due to the differences in the underlying virtualisation platform. This was again carried out remotely, although on this occasion it took only a few hours.
This move to ESX was the first step into the enterprise class virtualisation platform for this company and we have since started down a virtualisation route for other servers/applications within their organisation.