Proven Practice: Migrating Production Siebel to VMware
Metadata
Title | Proven Practice: Migrating Production Siebel to VMware |
Version | Bobstgroup 31/JUL/2008 1.0 |
Authors | Christian Rieder Christian.Rieder@bobstgroup.com
Gilles Ziegler |
Tags | strategy applications siebel oracle |
Location | |
Context | Our production Siebel applications (web, app, DB) were running on hardware that was due to become obsolete. Our choices were whether to migrate the applications from old physical to new physical, or to new virtual machines.
As we had experience of running Siebel already in virtual machines in our test environments, we were confident that migrating to new virtual machines would be the best option for the business (avoiding more capital costs) and also technically. |
Actors | VMware Certified Professionals, Siebel Application Experts and Busines Owners |
References | TBD |
Outline | Our process to migrate Siebel from physical to virtual was very straight-forward and adhered to standard best practices that are applicable to the migration of any application - there was nothing special performed for Siebel and we had no issues. The process was:
|
How to use this proven practice
This document can be used as an outline for your own migration plan for Siebel. There is nothing exceptional required to migrate Siebel so if you are already proficient at VMware ESX Server and P2V, you will find this process very normal and straight-forward.
Proven Practice
Approving the solution
We have been running Siebel in VMware ESX Server since 2003 so the application owners are familiar with this configuraiton.
The current hardware we want to migrate from is more than four years old, and it is not heavily used in terms of capacity, so the performance running on VMware should be better not worse.
We agreed to optimize the virtual machine configuration - the physical servers had two physical CPUs but the virtual machines were configured with one virtual CPU - based on our capacity analysis and the fact that the physical hardware was old compared to the latest hardware under our virtual machines, there were no concerns about performance.
The physical servers were web, application and Oracle database all on Windows 2000. We have been running Oracle on virtual machines already without issue.
We accept that in the unlikely event that a problem with Seibel can be identified as a problem with a hardware driver or VMware ESX Server, we will do a virtual-to-physical migration - we haven't had to do once that in four years.
Migrating the production web, app and db servers.
This was a standard P2V for migrating Windows servers, nothing special was performed for Seibel. Our process was:
Analyse the source physical server capacity for CPU, RAM, Network and Storage activitiy. These servers were using around 10% of their available physical capacity
onfigure the target virtual machines - we allocated the same RAM amounts but only 1 VCPU (source physical machines had 2 PCPUs).
Using Platespin, we migrated the storage from the source physical machines dedicated LUNs to virtual disks that are stored on our fibre-channel SAN.
Modify the now-virtual Windows virtual machines to install VMware Tools and check that there are no errors.
Have the application user test.
Life with Siebel on VMware ESX Server
Although we have had no issues with Siebel that are caused by VMware ESX Server, we did have a Unicode issue that a Siebel employee fixed with us - at no time did Siebel refuse to support us because we were running on VMware ESX Server, and the problem was fixed.
Interesting topic, I had major issues with hosting SAP Environments in my previous Datacenter, mainly due to the nature of them requiring Three stages for the relevant module.
It was annoying as I hit barriers with support of SAP on Vmware, it was crazy, my Virtual infrastructure was capable and able host the SAP instances but because of a ISV not playing ball I had to rearrange my datacenter facilty around the physical kit!
Glad you guys took the ball by the horns and ignored the Vendor!
Dan