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
/ 11 November 2008 / EDS INTERNAL
Content
Background
High Level View of Virtual Disks Associated with Virtual
Machines
Best Practices for Symmetrix Metavolumes

Set up Storage for Virtual Machines
Proposed Metavolume Size on Symmetrix
Justifications for Not Adopting VMware Extent
(Concatenating Metavolume)
Use Case
Calculations for Sizing the # of Metavolumes
AS-IS Size for Non-System Drives (Sample)
Recommendations
Next Steps
Growing VMware Infrastructure and Storage Space

2
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

3
High Level View of Virtual Disks Associated with Virtual Machines

4
Best Practices for Symmetrix Metavolumes

Metavolumes are another layer of abstraction over the standard Symmetrix volumes
Meta members need to be placed on separate physical disks and behind different DAs
to spread the load.
Always make sure that the number of meta members is a power of 2 (2, 4, 8, 16,
32). This minimizes the chance of roving hot spots, performance-wise.
Use fewer, larger volumes rather than more, smaller volumes.
Dont run striped metas over RAID5 meta members. RAID5 stripes already, so this is
striping over striping (often called plaiding). This practice can lead to inconsistent
performance.
In DMX-3/4, each DA pair has 8 DA processors, so a maximum of 8 concurrent I/Os
can occur. Therefore your metas should be limited to 8 members for each DA pair
you have.
DMX
# 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

5
Set up Storage for Virtual Machines

Each virtual machine defined in an ESX Server host will utilize SAN-attached storage
for all its operating system and data storage.
It is better to use a large SAN Metavolumes rather than many smaller sizes SAN
LUNs.
There is no significant data throughput or performance difference when using either
standard sized (i.e. 11.59GB) LUNs versus using a composite MetaLUN (e.g.
8*11.59=92.72GB).
Using a Metavolume can greatly reduce the complexity of defining and managing the
SAN configuration.
SAN LUN numbers must be masked to be below 256 for ESX Server.
Within each ESX server host, the service administrator will define VMFS volumes on
each MetaLUN.
The first group of VMFS volumes will be used to support VM system disks
The second group of VMFS volumes will be used to support application data.
The ESX service administrator will establish these mappings and preferred pathing through the
HBAs to balance the load between these VMFS volumes.
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.

6
Proposed MetaLUN Size on Symmetrix

For Symettrix Storage, the Metavolume Size will Depend on Age and Size of the
storage subsystem
Symmetrix
size (TB)
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.
7
Justifications for Not Adopting VMware Extent

VMware does NOT recommend VMware Extent Implementation as a Permanent Production
Solution.
Volume spanning for ESX hosts is the least favorable option for SAN administrators, for
two reasons.
First, since we cannot determine if all files related to one virtual machine are all on a single physical
extent, we also cannot know whether the loss of an extent will result in the loss of the virtual
machine or its data.
Second, a VMFS partition being used by a guest operating system, or serving as a data disk with
pending I/O, cannot be spanned while the virtual machine is in a powered-on state.
Volumes are concatenated and not striped, so there is no improvement to performance.

No Easy Method to Know which Extent(s) that a VM Data Resides. For Example,
Let's say there are 5 volumes and each volume is 10GB. If you concatenate them together with
VMware you have a 50GB datastore. What will happen if you loose the 3rd (or 4th) volume in that
storage set? Will a virtual machine be effected? Will all data for a VM be on volume 1, 2, 3, 4 or
combinations of them? It will be difficult to track down such information because VMware ESX
doesnt know.
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)

8
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)

9
Calculations for Sizing the # of MetaLUNs

The following tables illustrate sample calculations for sizing the number of MetaLUNs
required by using either the current 11.59GB or the proposed 34.77GB standard HVE
size.
Current
Standard
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

10
AS-IS Size for Non-System Drives (Sample)

Assess the Metavolume Size by Sampling the GBS Application Data Drive
Size from ADMS
Exclude the system drive (i.e. C:\)
21 servers in AH and PL respectively
The size of the same VMDK will be the same in AH and PL
Various current data drive size
Unknown combinations of data drives (e.g. (D:\), (D:\, E:\), and so on)
Data drive sizes range from 21GB to 288GB
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.

11
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
for Symmetrix Metavolumes
Must be retrofitted to the long-term solution if this option is chosen
Option2 Use VMware extent temporarily

Not recommended by VMware. Refer to slide Justifications for Not Adopting VMware
Extent
Must be retrofitted to the long-term solution if this option should be chosen
Long-Term (assumed the DMX2500 continues to be deployed)

Enlarge the sizes of LUN and metavolume for VMware as the Going Forward
Directions. The existing LUN sizes (11.59 or 3.86) will still be used.
Size of LUN - 34.77GB (3*11.59GB) on large drives (i.e. 300GB or 400GB)

Sizes of Metavolume
278.16GB
556.32GB
New sizes of LUN and Metavolume can be implemented when

New disks are added on the existing storage arrays.
Performance may not be optimized due to the small number of disks.
New storage arrays are added.
Refer to slide Calculations for Sizing the # of MetaLUNs.

12
Recommendations & Next Steps

Implement the Short-Term Solution Immediately
Option1 Increase the size of metavolume from 185.44 GB
(16*11.59GB) to 370.88GB (32*11.59GB)
Increase the Sizes of LUN and Metavolume for New Disks &
Storage Arrays
The new LUN size is 34.77GB

Support Two Metavolume Options
8 * LUN
16* LUN
Refer to the long-term solution in slide Options
Efficiency: Save the most amount of storage
Feasibility: Operations can configure the new LUN size while adding
disks or a storage array
Refer to Slide Proposed MetaLUN Size on Symmetrix

13
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

14
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

Growing Vmware Infrastructure and Storage Space: Beth Van Egeren & Vmware Team GM Hosting Services

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Growing Vmware Infrastructure and Storage Space: Beth Van Egeren & Vmware Team GM Hosting Services

Hochgeladen von

Copyright:

Verfügbare Formate

Growing VMware Infrastructure

and Storage Space

/ 11 November 2008 / EDS INTERNAL

Best Practices for Symmetrix Metavolumes