Marico’s blade server virtualization approach brings key benefits

FMCG major Marico went in for a methodical blade server virtualization strategy that has brought in a string of gains.

Many server virtualization deployments have interesting requirements leading up to it, and Indian FMCG major Marico’s is such a story. In the case of Marico, the infrastructure requirements for its SAP ERP upgrade proved to be the catalyst for blade server virtualization.

Marico is a leading Indian group with global presence in the beauty and wellness space. The company’s products and services in hair care, skin care and health foods generated a turnover of about Rs. 26.6 billion (US$ 600 million) during 2009-10. The company markets well-known brands such as Parachute and Saffola. With its rising global presence and increasing forays in newer product categories, Marico felt the need to upgrade its existing SAP ERP solution in 2009.

In June 2009, Marico embarked on its SAP upgrade project, and was scouting for server options. “The SAP servers at that time were almost five years old. We had to change the platform as well as get ahead in terms of technology,” explains Satish Pai, the systems administration manager at Marico Ltd.

It is interesting to note how Marico decided to opt for blade server virtualization. After considering various options to replace its HP rack-mountable servers, Marico zeroed in on blade servers as one of the top options. Blade servers found favor, as the rack-mountable servers took up a lot of space. Further, Marico wanted an option which increased uptime and offered flexibility. Hence, blade server virtualization seemed to be the appropriate option. Marico decided to leverage its existing relationship with HP for replacement of its rack-mountable servers with blade servers.

Shifting to blade servers and going in for server virtualization was not that easy. Migration from a rack-mountable environment to blade server virtualization meant replicating the former, without getting the desired flexibility. Moreover, if additional servers are required to cater to extra loads, it’s not possible with such a move. In view of this, HP Virtual Connect has been used to separate physical servers from logical servers.

Marico embarked on a two-pronged blade server virtualization journey. One part of this solution uses logical application servers for SAP on the HP platform. The other aspect uses hardware virtualization for hosting non-SAP servers on VMware.

The blade server virtualization strategy at Marico uses three logical servers for SAP. In addition, the company has separate physical servers with which these logical servers are associated. “In case load increases and we require another Application Server for SAP R3, then we create a logical server (SAP R3) using a physical server and reboot the system. On rebooting, it takes the application server’s profile, and we don’t have to extensively change the configuration,” Pai points out. The process hardly takes 10 minutes, a key reason why blade server virtualization has paid rich dividends for the company.

Three applications from SAP (SAP EPO for supply chain, SAP R3 for ERP, and SAP BI for business intelligence) are in use at Marico. For its traditional SAP production server, Marico requires a corresponding development and quality assurance (QA) setup. Hence Marico anticipated major server sprawl issues after replication of these servers.

The earlier servers were running on HP’s Unix platform. Due to this dependency, Marico decided to adopt HP’s IVM (Integriti Virtual Machines) capabilities to create virtual machines on the blade servers.

For its development setup, Marico has created virtual machines for development and QA on a physical blade server. The blade server virtualization strategy has helped Marico’s team during the upgrade, especially during the testing stages. Earlier, the team created a virtual machine for SAP R3, configured storage, and replicated it on another machine. Later, the SAP instance was refreshed from the original SAP server and upgraded. This helped the team to identify problems.

Three physical blades from HP make up Marico’s blade server virtualization strategy. This includes a development server as well as two production servers. The development setup runs six virtual machines (VM) on HP Unix (with a two CPU configuration and 32 GB RAM). Several VMs (with 4 GB RAM each) have been created on the development server. In case of testing requirements, team members increase the particular VM’s RAM capacity. The development server is connected to HP EVA 4400 SAN storage. There are two separate blade chassis for development and production servers. The development chassis also inhabits non-SAP servers. The production chassis hosts SAP servers and critical Web portals. It is connected to EMC Clariion CX4-4480 networked storage.

The blade server virtualization project (including hardware migration) took around two months, and brought in varied challenges. For instance, the SAP R3 upgrade could be performed only on weekends (which were non-critical for business). The development chassis is located in the Marico’s data center at its Mumbai head quarters. The production chassis is located at VSNL's data center in Andheri, Mumbai. Since Marico had to accommodate old as well as new servers, extra space and power requirements came into the picture. So in order to get temporary rack space, Marico had to wait till one of the customers moved out of the hosted facility.

Two aspects came into play while planning the blade server virtualization project. On the technical side, the first part dealt with migration from rack-mountable to blade servers.  At the same time, Marico’s SAN storage was also being migrated from EMC CX3 40 to EMC CX4 - 480 for the production servers. Thus, the planning had to be in such a way that there were no clashes between these interdependent projects. Moreover, application servers were being migrated from HP Unix to Red Hat Linux. Interestingly, after changing the platform as part of the blade server virtualization initiative, Marico saved about Rs 40 lakh. That is because HP Unix requires proprietary hardware, whereas Linux works on normal Intel boxes. Marico’s database servers are still on HP Unix since the downtime for changing them is quite high.

As part of the blade server virtualization project, non-SAP servers (running on Linux) were consolidated from 30 spaghetti box servers to three physical servers running VMware ESX. This initiative is still underway.

Benefits and learnings

Unlike most such exercises where benefits are known clearly, Marico’s blade server virtualization project’s benefits came in as a string of surprises. For instance, in the case of non-SAP servers part of the blade server virtualization exercise, there was a lot of doubt in terms of achieving the expected performance. To the team’s surprise, the system delivered on its expectations.

Savings are a major benefit of Marico’s server virtualization project. The company has also had major savings on the hardware annual maintenance contracts (AMC). Instead of paying for 30 servers, the company has three blades with warranty, thanks to blade server virtualization.

The blade server virtualization exercise ensured that Marico’s team could have two mock servers simultaneously during the SAP R3 upgrade. In case of problems with the second upgrade, the team could refer to the first server.

Space savings have been accrued following blade server virtualization. Non-SAP servers occupied five racks in the earlier data center, now it requires only one-and-a-half racks. Marico is leveraging the freed up space to make workstations for people who could not be accommodated earlier due to lack of space.

Pai sums up the benefits of their unique slow and methodical blade server virtualization approach, “You have to know your application well. We discovered many application-specific aspects during migration of the servers to blades, since these applications used hardcoded IP addresses. The p2v software requires a database shut down, so it’s critical to plan the downtime.” A period of 15 days was kept aside for each application to gauge its functioning before the decommissioning of older servers.


Read more on Data centre hardware