Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=205918003
Because we deliver services via the software-as-a-service model, we needed to maintain our 24/7 functionality, hosting, availability, reliability, and scalability. We also wanted to maintain our reliable disaster recovery process while adding flexibility to deploy multiple environments, including test and development, sales demos, and load-testing environments. We determined that a VMware virtual infrastructure would provide us with all of these attributes at a more reasonable cost than a new physical infrastructure.
We first thought of virtualization when considering a tiered storage strategy and a disaster recovery plan across multiple environments. We determined virtualization would help us move data quickly to the right storage source depending on our needs. We also realized virtualization would make it easier to deploy redundancy in our production environment, along with providing the horsepower to run disaster recovery and other environments.
Licensing costs were a critical factor when creating our near-real-time disaster recovery center. When a near-real-time data copy is used in disaster recovery, Oracle requires the same licensing model on both sides. We discovered that IBM p570 servers using IBM Power6 processors at the database layer would let us deploy fewer but faster processors. This let us further lower our Oracle licensing costs. The IBM p570 servers have logical partitions for which we can allocate as much memory and CPU power as we want, and we can share excess capacity across the partitions. By virtualizing the logical partitions, we can scale easier. And with the databases on shared storage, we can create extra partitions for our other production server to failover to, if necessary.
Virtualization also let us configure the disaster recovery box so that while we run test and development environments, we can also run smaller Oracle partitions. If we want to conduct load testing, we just reconfigure the development partitions for true load testing. If we have to run a disaster recovery process, we can use the whole box to run production.
For storage, we use virtualized Network Appliance devices, which we have configured in a classic enterprise shared storage setup. We use the devices to create extra copies of our database for test and development. Previously, when we wanted to refresh the test and development database, we had to make a full copy of the production database, which took 12 to 24 hours and required a lot of storage. Now, we just create a copy of the disaster recovery database, which is an up-to-date production copy. It takes very little space, and the process occurs within minutes.
At the application layer, most of our code is custom written in Java running on a BEA WebLogic app server. For hardware, we use Dell 2950 servers with two quad processors and 32 GB of RAM. We also added extra network interface cards to the servers for the subnets that connect the servers to our storage.
ADD WHEN NEEDED
A key virtualization feature at the application layer is VMware's VMotion capability. This lets us create a cluster of three or four severs to which we can add 20 to 40 virtual servers. VMotion manages the servers by monitoring how busy each server is and automatically moves a virtual server from one physical server to another if the original physical server is too busy. This occurs in real time without any interruption to the application.
When assessing the cost of converting to a virtual environment, it's important to realize that virtualization requires additional network storage since it takes 20 GB to load the OS of a virtual machine. You also will need additional network interface cards for the separate network subnets between the virtual machines and the storage devices. When you add the cost of the virtual operating system software and the extra memory you will require, your cost per server goes up. Alternately, when you consider that you can consolidate up to 10 virtual servers into one physical server, the overall savings becomes considerable--not just in up-front hardware costs, but also in terms of power and cooling costs, as well as data center space.
It's also important to understand the licensing requirements of your software vendors. Most offer CPU-based licensing, but they may factor in extra costs for virtual servers. Virtualization makes it easy to add new servers, but software vendors may want to charge extra for each server added.
Our virtual infrastructure has generated several benefits for Transplace. Not only did we save on hardware costs by decreasing the number of CPUs we needed, we also addressed the challenge of how to create databases when we need to. Virtualization also solved the challenge of how to copy to our disaster recovery server, and we can now create additional environments on-demand--without having servers specifically reserved for each environment. Our virtual machine clusters might run test virtual machines one day and load testing the next, or they could be running disaster recovery. We can choose which virtual machines we want running at any moment in time. This helps solve the challenge of scalability, since we can simply add new servers to the cluster whenever we want. Most importantly, virtualization has allowed us to maintain our 24/7 functionality, hosting, availability, and reliability for our customers.
Vincent Biddlecombe is CTO of Transplace, a provider of transportation management services and logistics technology.