"Virtual" Test

Budgets, budgets, budgets. We all have to deal with budgets. Making sure we can pay the mortgage, make the car payment, and feed the family fit into the home budget. For anyone that is a member of an organization, such as IOUG, we may want to start a really cool project, but being a volunteer organization, the budget will not support it this year. Even sending my daughters to school has become interesting as the private school system that they attend has run into budgetary issues. Most everyone in the technology field, definitely has run into budget constraints at work. In my case, the most recent budget "issue" has been creating a test system for our latest project.

A project was started to consolidate some remote MS Access databases into a centralized Oracle database. This is a vendor application and either installation method is supported. As the application becomes more mission critical, however, the decision was made (and the correct one, in my opinion) to consolidate to our Network Operations Center. The issue that came up though was dollars. When the original budget was written for the project, dollars for a test system were forgotten. The production system was budgeted as a two-node cluster to support two different application databases. This was fine and should support what we want to accomplish, but test was completely overlooked.

So, how do you create a test cluster to support a production implementation when dollars are limited? In our case, the decision was made to purchase one physical server and user Oracle VM to create a test cluster. Not exactly the same as production, but at least we will have somewhere to test out operating system, database, clusterware, and ASM upgrades and patches before going directly into production.

Of course, we have had issues. There is a larger VM learning curve than we expected especially as it relates to storage. We are also feeling our way through resource allocation. Originally we underallocated CPU resources and couldn't install anything. The virtual guest machine showed that the CPU was pegged, but the physical host showed no activity. Allocating an extra virtual CPU took care of that issue, but we still had issues installing and configuring ASM. The normal installation of 11g and configuration of ASM was hanging and showing full CPU utilization, although it was creating the instances. My coworker has spent a couple days with Oracle support trying to figure things out and finally ended up creating everything manually instead. Just one instance of how virtualized environments are not quite as seamless as the are touted to be.

In any event, we have the viritual servers up and running. So now we need to create the databases and away we go! That is just one example of how, if necessary, budgets can be saved. Of course, we haven't proven that we can support any kind of test load on this architecture, but we should at least be able to see if the applications still function after an upgrade or patch.

One final plug, by the way, for the IOUG Forum at Collaborate 09. If you are looking for more ways to save budget dollars, there are lots of tips and tricks you can learn from your peers. I'm hoping to learn more about virtualization and how we can better tune our test system. Since budgets are tight everywhere, make sure you register online before April 30 to save $200. Also, the conference hotel rates have been discounted. There is not better bargain for training than learning from people that have actually used the technology...