Professional Documents
Culture Documents
Growing Vmware Infrastructure and Storage Space: Beth Van Egeren & Vmware Team GM Hosting Services
Growing Vmware Infrastructure and Storage Space: Beth Van Egeren & Vmware Team GM Hosting Services
Growing Vmware Infrastructure and Storage Space: Beth Van Egeren & Vmware Team GM Hosting Services
Content
Background
High Level View of Virtual Disks Associated with Virtual
Machines
(Concatenating Metavolume)
Use Case
Calculations for Sizing the # of Metavolumes
AS-IS Size for Non-System Drives (Sample)
Recommendations
Next Steps
Background
Newly Published EMC, VMware and EDS Best Practices for LUN and
Metavolume need to be Incorporated into the VMware Storage Layout and the
Sizes of LUN and MetaLUN.
Multiple Sizes for VMware Metavolume (aka MetaLUN) are implemented in GM
VMware Farms
200 GB in GSC 36a North America
400 GB was proposed for GME
xxx GB in GSC 36b
# of DA Pairs
Model
# of Drive
Loops
Recommended
Max # of Members
DMX800, DMX950
DMX1000, DMX1500
DMX2000, DMX2500
16
16
DMX3500
24
24
DMX3000, DMX4500
32
32
To facilitate movement of virtual machines among hosts by the use of VMotion, each
ESX server host must be zoned and masked identically to all the other ESX server
hosts in the server farm.
ESX
usage
Existing
any
VMFS
11.59
16
VMFS
11.59
32*
raw
New Disks/
New Array
<2.5
VMFS
raw
>2.5
VMFS
HVE size
(GB)
HVE aggregation
factor
Symmetrix
age
34.77
34.77
MetaLUN
size (GB)
185.44
370.88
11.59
278.16
34.77
278.16
556.32
16
raw
34.77
The Hyper Volume Extension (HVE) aggregation factor 32 is not recommended for DMX2500.
What can happen (the worst case) is that a single IO will want to write to all 32 disks simultaneously. Then someone else will also want to do
work but can't do any IO because the first application has stalled everyone else. Now if you do this with many metaluns, you cause many
chances to stall or stop IO because each will be waiting for the other to complete.
Another issue is when two parts of a metalun get deployed on the same physical disk. If there is a disk failure on that disk, it is possible to lose
all data on that meta because two parts were on the same failed disk.
Growing VMware Infrastructure and Storage Space
7
In the context of ESX systems, an extent is a logical volume on a physical storage device that can be dynamically added to
an existing VMFS-based datastore. The datastore can stretch over multiple extents, yet appear as a single volume analogous to
a spanned volume
From page 129 of the "VMware SAN System Design and Deployment Guide - August 2008 (
http://www.vmware.com/pdf/vi3_san_design_deploy.pdf)
Use Case
When sizing the storage for a VMware ESX solution, one should keep in mind the
storage requirements of the target VMs within each ESX server cluster. An ESX
server cluster is a grouping of ESX servers that share a set of common network
/storage attributes.
Each ESX server is capable of supporting up to 28 typical low impact virtual
machines. VMs with high CPU or I/O loads will reduce this estimation. The Entry
point into the offering is at up to 80 virtual machines running on 4 ESX servers at an
estimated utilization of 70%. This level of utilization would allow a single server to
be taken offline without driving utilization above 100%.
Storage for an ESX server farm should be designed in the following manner. Using a
standard virtual disk size of 20 GB for VM system disks, estimate the number of
MetaLUNs required to support the number
Determine the number of VMs to run in the cluster (92)
Determine the standard size to make the VM system disks (20)
Calculate the total storage needed to support system disks (92*20)
Determine the size of MetaLUNs to be delivered from above table (278.16)
[for storage on a new Symmetrix DMX SAN]
Determine how many vdisks will fit into a MetaLUN must round down
(278.16 /20=13)
Determine how many MetaLUNs will be needed to accommodate the VMs round up (92/13 = 8)
Unused
# VMs VMDK
#
Space in a
in
size
HVE size MetaLUN Drives /
MetaLUN
Cluster (GB)
(GB)
size (GB) MetaLUN (GB)
92
20
11.59
185.44
9
5.44
92
40
11.59
185.44
4
25.44
92
60
11.59
185.44
3
5.44
92
80
11.59
185.44
2
25.44
92
100
11.59
185.44
1
85.44
# VMs
in
VMDK
Cluster size
92
92
92
92
92
92
92
92
92
92
20
40
60
80
100
20
40
60
80
100
Proposed
Standard
HVE size
(GB)
34.77
34.77
34.77
34.77
34.77
34.77
34.77
34.77
34.77
34.77
MetaLUN
size GB
278.16
278.16
278.16
278.16
278.16
556.32
556.32
556.32
556.32
556.32
#
Drives /
MetaLUN
13
6
4
3
2
27
13
9
6
5
Unused
Space in a
MetaLUN
18.16
38.16
38.16
38.16
78.16
16.32
36.32
16.32
76.32
56.32
Number of
MetaLUNs
to support
VM drives
11
23
31
46
92
Number of
MetaLUNs
to support
VM drives
8
16
23
31
46
4
8
11
16
19
Observations
For VMotion purpose, all GBS VMDK must be accessible in the GBS VMware
Farm.
The current metavolume size will most likely not large enough to accommodate
the largest VMDK.
Options
Short-Term
Option1 Increase the size of metavolume from 185.44 GB (16*11.59GB) to
370.88GB (32*11.59GB)
Twice as large as the Recommended Max # of Members. Refer to slide Best Practices
Extent
Directions. The existing LUN sizes (11.59 or 3.86) will still be used.
Increase the Sizes of LUN and Metavolume for New Disks &
Storage Arrays
Next Steps
Next Steps
Obtain consensus from GM/IIM, EMC, HP and EDS
Generalize the Design Principles
Standardize the short-term and long-term solutions globally
EDS, an HP company
5400 Legacy Drive
Plano, TX 75024
+1 972 605 6000 (optional)
beth.vanegeren@eds.com or eds.com
EDS and the EDS logo are registered trademarks of Hewlett-Packard Development Company, LP. HP is an equal
opportunity employer and values the diversity of its people. 2008 Hewlett-Packard Development Company, LP.
15