This page contains a Flash digital edition of a book.
How Much Is Enough?

Determining Network Bandwidth Needs for Virtual Data Centers


T pros often cite virtualization and backups as reasons why they need more network

bandwidth, but they don’t necessarily need a 10 GbE network to maintain a high level of performance. On the surface, it makes sense that

a virtual infrastructure needs plenty of network bandwidth. Let’s say that an organization just consolidated 20 physical servers, each with two Gigabit Ethernet (GbE) ports, into one virtual host. Surely that means the host needs more than a few GbE ports? The reality is that almost all of those

physical hosts didn’t use their full network bandwidth, apart from tiny bursts. So sharing a GbE port among a dozen virtual machines (VMs) won’t be a problem. Virtualization tends to increase the average utilization of these ports from less than 1% to 5% or 10%. The VMs just don’t need a lot of network bandwidth.

Move It That said, the virtualization

hosts do require fast ports for transferring VMs between hosts. Moving 16GB worth of a VM’s contents during a powered-on live migration will saturate a GbE port for a few minutes. The issue is exacerbated when migrations involve a huge amount of RAM. If a virtual host with 128GB of RAM

is filled to capacity, it may take a half an hour or more to migrate all of the VMs using a single GbE port. If you are migrating these VMs because of an

impending physical failure, it will feel a lot longer. (Just imagine that feeling when a host with terabytes of memory is about to fail.) But emptying the same 128GB host with a 10GbE connection will take about 5 minutes, reducing the risk of a VM outage because of a virtual host failure.

Store It Storage networks with plenty of

bandwidth are valuable assets in virtual infrastructures. The required amount of storage bandwidth depends not only on the number of transactions but also on the transaction size. Windows File Servers, for example, tend to use tiny transactions to access the storage, and database servers use medium-sized transactions. In both cases, these workloads will

likely be limited by the transaction rate long before network bandwidth becomes a factor. For low-utilization, easy-to-virtualize VMs, the storage network won’t be limiting, even at GbE speeds. For more critical, resource- intensive VMs, however, you’d better make sure you have dozens of spindles or a fair amount of solid-state drives before you start demanding faster storage networks.

Back It Up As we’ve moved from the 9-to-5

workday to the always-on Internet age, the working day overlaps with the backup window; this is when organizations back up their servers, usually during off-peak times.


Now companies need full-speed performance during a backup, so the network cannot be saturated. Backups involve large transactions

and can quickly fill a network. As such, it’s common sense to have a nice, fat pipe to carry the data. If that’s the case, the storage disks will be the limiting factor, rather than the link itself. More specifically, if your backup

tool uses agents inside the VMs, then you will want fat pipes into the virtual hosts to avoid a blowout during the backup windows. You will also need to make sure your hosts have ample CPU and RAM to cope with this load spike. Hopefully, your backups are offloaded from your VMs and virtual hosts. Connecting your backup server to the storage array using the fattest pipe you have is definitely a good idea. If you have a fast network between your backup server and your main storage, does it make sense to have a slower network for your hosts? On the one hand, if you are buying new equipment, probably not. The incremental cost of fast network ports won’t be much, and over time the demand for bandwidth will likely increase. On the other hand, if you’re simply solving the problem of backup speed, you will probably buy faster ports just for the backup servers and storage. In the end, as you buy new

networking equipment, you will put in faster network ports. Over time, you’ll wonder how you ever managed with those slower networks.

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36