Entries Tagged 'VMware' ↓

Here are some quick performance results from VMware servers with 10 Gigabit Ethernet cards (from Sun with an Intel 82598 controller. The servers were Sun X4150 with Dual-Quadcore processors.

Network tests

I fired up two test VMs with Suse Linux Enterprise Desktop 10 (64 bit) and used netperf to measure TCP bandwidth between them (the exact command used was netperf -H <target ip> -t TCP_STREAM -C -c -l 60 -f M).

VM to VM (both VMs placed on the same physical server): 230 MB/s

VM to VM (each VM on a different physical server using 10 GigE through a single switch): 250 MB/s

VM to a physical server with a 10 GigE card: 540 MB/s

Physical server to VM: 290 MB/s

Looks like there is a bottleneck somewhere on the receive side but the performance is sufficient even for the most demanding (business) applications. Remember: this is out-of-the-box performance, no tuning.

Disk performance to a NFS based datastore on a Netapp

Here I simple used IOzone in the Linux-VM to write and read several GBs of data to a virtual disk (formatted with XFS). The virtual disk was placed on a NFS datastore (Netapp 6070 with Ontap 7.2.4, 2×16 disk FC aggregate).

Write: 160 MB/s

Read: 160 MB/s (200 MB/s from filer cache)

I think these numbers can be improved as neither the filer nor the server were fully utilized, so I expect more VMs will bring additional performance. Perhaps the receive-side problem mentioned above also plays a role.

Summary

Generally this is exactly what we expected: to be able to provide good performance to many virtual servers which do network and/or disk-I/O only periodically without overprovisioning the whole infrastructure.

At the moment there is exactly one dual-port 10 GigE card in every VMware server and there are two physical connections to two different switches - a much cleaner setup than the 12 (!) GigE interfaces per server we had before

How do your numbers look like? Comments welcome (moderated). 

What happened before: Part 1 of this series presented a technology overview of deduplication, part 2 showed a hands-on-example using a Netapp filer and VMware datastores.

(Not so) Thin provisioning

When using NFS your virtual disks in ESX are thin provisioned - that means that if you create a 50 GB virtual disk it will not use the whole 50 GB at once. Instead a sparse file is produced which grows when you write data to the virtual disk.

Unfortunately the “thin” property is lost when you VMotion your disk to another datastore or create a new virtual machine from a template in the datastore. In this case your “thin” 50 GB will become 50 GB immediately. 

Deduplication helps

Filesystem deduplication will help here: the filer will write the 50 GB virtual disk normally but deduplicate it at night. The trick here is to schedule your snapshots right as any un-deduplicated data will remain frozen until the snapshots is deleted.

Rule: deduplicate first - do backup snapshots later!

Of course this depends on your data protection strategy - we usually take one consistent snapshot (VMware snapshot, then Netapp snapshot) per datastore in the morning so deduplication can run around midnight. An example schedule for a datastore looks like this:

• Deduplication daily @ 2 am
• Consistent VMware/Netapp snapshots daily @ 4 am, keep 7
• Normal Netapp snapshots: every 4 hours, keep 6

If you do it the other way round your deduplication savings will be smaller as you’ll keep around un-deduplicated data captured inside your long-lasting backup snapshots.

Update: here is how to estimate potential savings.

What are your best tricks here? Comments welcome (moderated).