Are there advantages to virtualizing your database? That database question is front and center now that IT organizations are expanding virtualization to mission-critical applications. This tip will address the important factors to consider when deciding whether or not to invest in a virtualized database environment.
Virtualizing small databases
Performing a virtual migration or virtual machine base installation is relatively easy on application servers hosting a standalone database. This is a plausible solution for single systems that contain a database locally or a development database environment for testing purposes. Virtual machines running a single instance of a database engine with a small number of databases are welcome and accepted for hosting on an application server. A virtualized database server makes a great alternative for a database engine outside the primary environment. For example, an organization might purchase a specialized line-of-business application that is available only with a Firebird database. The Firebird engine is uncommon in enterprise computing environments, but if a specialized application requires this database, there may be no alternative for the product in question, making virtual hosting of this dbase engine a good choice.
The same applies for database-centric applications that prefer or require the database to be installed locally, instead of accessing a central database server. Many solutions that include, for example, Microsoft SQL MSDE or SQL 2005 Express instances, are installed locally with specific applications. These application servers include a database installation, increasing the footprint in regards to database engine patching from a database management perspective.
Performance and virtual databases
The resource provisioning for a virtualized database server will generally be very high if many databases or very large databases are to be hosted virtually. Thus, provisioning an enterprise database server virtually for many databases requires specific configuration and ample resources needed to ensure successful operation. Of course, implementation would benefit from performance testing and benchmarking to establish a proof-of-concept for a virtualized database environment similar to the planned environment.
A virtualized operating system will not be a transparent factor in a virtual database implementation. VMware is aggressively trying to address this and there have been some success stories with virtualized Oracle environments. VMware provides archives of presentations from VMWorld last fall that are a good starting point for those considering an Oracle implementation on VMware. According to VMware, "Oracle database runs on VMware ESX Server at near-native performance" and "the CPU overhead for Oracle Database on ESX Server can be less than 10%." Virtualization administrators should adjust their expectations accordingly.
The large amount of available storage needed for the virtual machine on a database server may be an initial deterrent for many organizations. However, the large amount of storage would be needed regardless of the database environment being physical or virtual. Concerns should be focused more on the management aspects of the virtual environment. With a large virtual machine storage footprint, administrators may find the virtualized database having a dedicated logical unit number, or LUN, for that virtual machine within shared storage. A large virtual machine would be a slight inconvenience, as any virtualization-specific storage management would take longer simply because of the size.
One topic that varies widely for virtualization administrators is the size of a LUN provided to virtual environments. For fiber channel and other shared storage strategies, LUN sizes come in increments of 100, 200, 320 and 500 GB, with some in the Terabyte range. Coordination of this procedure can identify how storage will be provisioned, administered, and expanded. This will vary by storage type and internal procedures from the storage administrator (if not the virtual administrator). A good starting point for a large virtualized database environment is to identify the following procedures and expectations between the virtualization administrators, database administrators or developers and the storage administrators:
- LUN size for virtual operating system
- LUN size (and number of LUNs) for database files
- LUN size (and number of LUNs) for transaction logs
- LUN arrangement for other roles, like database backups
- Transfer rates if using fiber channel
- Shared storage performance
These practice points mirror what might occur in provisioning a database server. In doing so, an important consideration to make is the class of disk performance. While every LUN assigned to a virtual environment may not be able to get the highest performance class of shared storage, the drive mechanisms that will contain the database files and transaction logs should have the highest performance available.
The cost of virtualized database
For most large database implementations built on physical servers, the hardware inventory may often model the inventory of virtual host system. Here, running the database in a virtual environment may require a dedicated host system from a resource perspective. When considering the costs of the virtualization software, it may not make sense to have an enterprise database run on a virtual machine when it is provisioned as the equivalent of a physical machine. Further, having a very large virtual machine (in terms of memory, CPU and storage) compared to the other virtual machines, may make managing that particular virtual machine an inconvenience. This would be due to large time requirements for migrations and the possible effective requirement of a dedicated virtual host.
Another cost-effective strategy is to pair down database servers to a fixed limit of databases. In this situation, a number of virtual database servers with 10-15 databases would replace a single physical database server that has over 100 databases hosted. This workload distribution can better suit a migration to a virtualized database server environment.
Supported environments and disaster recovery
For organizations that are aggressively embracing the virtualized database environment, the common denominator is disaster recovery. Disaster recovery is made easy when storage and networking can accommodate a mobile virtual machine. And among those either implementing or considering, the critical factor is ensuring database vendor support for the virtualized database environment. Determining the exact supported platform level from the database vendor perspective will be more challenging than most applications, but definitely something that should not be omitted from the concept phase of a solution for the database environment.
About the author: Rick Vanover is an MCSA-certified system administrator for Belron US in Columbus, Ohio. Rick has been working with information technology for over 10 years and with virtualization technologies for over seven years.