Introduction
This document discusses consideration for accurately sizing the Storage Infrastructure for VMware virtualized environments and takes a more pragmatic approach to the need as opposed to common generalities. VMware is a multifaceted product with options and add-ons which have a direct impact on the amount of raw storage space required for a successful implementation. Without proper planning, there is room for errors and potential lack of scalability and support for some of these features. The purpose of the document is to provide architectural guidelines to implement a VMware configuration from the very basic storage array, such as the iSCSI Sun Storage 2510TM, to modular midrange and high Sun Storage arrays. Guidelines will be based on general VMware storage capabilities along with advanced features such as VMware VMotionTM, VMware HATM, VMware DRSTM, VMware Fault ToleranceTM and Disaster recovery. All of these features have an impact on how a storage array or a SAN, both IP based and FC based, needs to be implemented in order to achieve optimal availability, reliability and performance. Detailed best practices for such implementations will also be discussed. Application storage considerations are not included in this white paper.
General Storage Sizing Considerations
There are four main considerations to keep in mind for storage sizing:
1. Basic Space Requirement
2. Shared Storage
3. Storage VMotion
4. Disaster Recovery
Basic Space Requirement
VMFS Space Overhead
An additional amount of disk space is used up by VMware to lay down the VMFS filesystem on any given lun. It is not a set percentage of available space to be formatted, however, an algorithm based on the space required to save metadata. Currently, there isn't a specific calculation to determine what the exact overhead for VMFS is, however, as a general rule about 500MB of overhead should be considered as space used for metadata when creating a VMFS volume.
Virtual Machine Home Directory
VMware has specific requirements to calculate basic Virtual Machine Home Directory space. A Virtual Machine Home Directory includes
- Virtual Machine Operating System
- Virtual Memory for the Virtual Machine; In the form of a flat file
- Log files
- Virtual Machine Config file (vmx)
- Swap file (vswp)
- Snapshots (If any)
To determine the basic VM home directory space requirement, following questions need to be answered
- # of VM: Number of virtual machines being consolidated to
- Size of OS: OS + Swap + Patches
- “Size of OS” x 2: Account for snapshot space VMware creates when a VM is set to “Suspend” mode
- Memory: Virtual Memory for each VM
- Log Size: VM Status, error logs
Once all of the required information has been gathered, the following calculation can be used to determine space required:
Example:
This calculation lays the foundation for a very basic VMware storage sizing. Additionally, for configurations which may include snapshots and virtual machine templates it is recommended to reserve 15% of space for snapshots, another 15% for possible Virtual Machine Templates and 10% to 15% of free space. Example continuing from above:
1.55 TB + (1.55 TB x 15% for snapshots) + (1.55 TB x 15% for Virtual Machine Templates) = 2.02TB of space needed approximately
Shared Storage
Almost all VMware advanced features require shared storage, with the exception of Storage VMotion. Storage VMotion will allow for a live migration of storage between internal hard disks in the ESX Server, direct attach or SAN (IP or FC) storage arrays in many different combinations. Features such as VMware VMotion, Distributed Resource Scheduling, Fault Tolerance and High Availability require shared storage configuration to work. Following is an example of a basic configuration which would allow all of these VMware advanced features to function:
In the example above, all Virtual Machines stored on the 2510 can be migrated using VMotion between both servers as long as the Virtual Machine Home Directories are saved on volumes mapped to both servers. DRS, Fault Tolerance and VMware HA can be configured on both servers for the given set of virtual machines as long as both servers have access to the storage where the virtual machines are stored. All virtual machines which require high availability should be part of of a DRS and/or VMware HA cluster to ensure the virtual machine can withstand resource related issues and hardware failures. In a direct attach configuration, all virtual machines will be exposed to downtime due to the server or the direct attach storage (JBOD for example) being a Single Point of Failure. However, the need for high availability is purely based on the what specific Virtual Machines are going to be used for. A company payroll database running on Oracle 11g with an SAP front-end probably requires high availability capabilities of VMware such as VMotion, VMware HA and DRS. However, a Virtual Machine created to test operating system and or application patch upgrades probably does not.
Storage VMotion
Storage VMotion requires additional amount of space on the source Datastore (storage device or volume) which is equal to Virtual Machine Home Directory, any existing snapshots and if required, space used by application and/or user data. Storage VMotion requires this additional space in order to create a snapshot of the existing data on the current storage device. Once the data is copied over to the new storage device, the snapshot is removed. However, if the required space is not available, Storage VMotion process will fail.
Since it is unlikely that all Virtual Machines on an ESX server will require Storage VMotion, and those which do require it will likely not use the capability at the same time due to the doubling of CPU and memory resource usage for the VM during the process, it is recommended to perform not more than the absolutely needed Storage VMotion migrations at any given time given the amount of CPU, Memory, Storage I/O Paths and Storage space available. In most cases, it can be very costly and unnecessary to allocate enough hardware resources to allow Storage VMotion on all VMs to occur at the same time. One or two at a time is likely. Since Storage VMotion temporarily requires twice the amount of space in the same volume where the VM data (home directory and application data) is located, storage sizing needs to be determined on a per VM basis along with the determination of how and where the VMs reside.
Continuing with example above, assuming ESX server has enough CPU and memory resources to accommodate two Storage VMotion processes at one time, that allows for 2% of additional space required:
Refer to VMware Storage VMotion Best Practices for the 2500 and 6000 Series Arrays for further details.
Disaster Recovery
Disaster recovery doubles the storage requirement as the exact same amount of storage is needed at both the Protected and DR sites. The most important determination to make is exactly how many Virtual machines at the Protected site need to be replicated to the DR site. Assuming the entire virtualized infrastructure need to be replicated, the total storage space requirement needs to be doubled. Another question is whether Storage VMotion will be used at the DR site as well as the answer will have a significant impact of storage space requirement at the DR site. For example, assuming complete mirroring of the Protected Site to the DR site via remote replication along with Storage VMotion, amount of storage space required at the DR site will be equal to the amount of space used at the Protected site. Continuing with example above, a total of 2.06TB approximately will required at the DR
The example is generalized. The actual calculation will be based on the number of Virtual Machines which require the use of Storage VMotion and protection via a disaster recovery implementation.
PART-II NOW POSTED.....!!!