5 Best Practices for Improving Image-Based Backup Performance
Image-based backups are ideal for virtual environments and can provide significant time savings and performance improvements over agent-based approaches. However, you can improve your image-based virtual backups even more by managing some of the finer points of the process, as I explain below.
1) Manage Service Console Resources
Whether you're backing up via the service console, vStorage API network or fiber, having a healthy service console is important. By default, the vSphere service console is only given 272 MB RAM, and this space is NOT dynamic. Only 160 MHz of the CPU is reserved for the container operating system (COS); however it is allowed to expand its usage if resources are available. These defaults often aren’t optimized for system needs. Key points to remember are that commutation to vCenter and snapshot processes are done in the service console, and the service console is pinned to the level CPU 0 and cannot move across CPUs the way that VMs can.
So, where should you set your service console to be in good health? For years, I have recommended setting the memory reservation to 800 MB of RAM and setting the CPU reservation to 1500 MHz. These settings will allow the service console to handle all the tasks and operations for which it is responsible to execute with a fair amount of resources.
2) Get Around the Speed Limit
When backing up via the service console, you should be aware that VMware vSphere 4.0 and 4.0 1a have a read/write speed limit. You can overcome the limit by applying the VMware patch ESX400-200912001/build 219382. In our experience applying this patch to your host will make your backup and restore performance 2.5 times better.
3) Keep VMs Off the Management Network
Backup traffic will travel out of your management network, via the service console in the VMware ESX environment or via vStorage API in ESXi. For the best performance you should not share VMs with your management network. You can use vSwitch to route traffic between VMs and external networks. Splitting your VM traffic and your management network traffic will leave a lot more bandwidth for COS backup and vStorage API network backups.
4) Separate HBAs in LAN-Free Backups
If you are backing up without a LAN, you should still apply service console resources for healthy service console performance and for a higher success rate for snapshots to close. If you have ESX and not ESXi, the service console speed patch will still apply for network-based restores via the service console. When backing up LAN-free you should have one host bus adapter (HBA) for reads and one HBA for writes on your physical proxy server. Using separate HBAs will provide the best fiber bandwidth for reading and writing -- otherwise you're sharing your read and write bandwidth through the same pipe.
5) Bond Network Cards for Increased Throughput
When using network-based storage targets, it's a good idea to bond the network cards to improve speed. For example: two 1 GB network cards bonded with link aggregation at the network interface software level, and at the switch level with port/link aggregation, provide a 2 GB pipe to your target storage OS/hardware. In this way, you can gain the advantages of a bigger pipe, which, of course, will allow for more backups to occur at one time, which lowers your backup window.
Posted by Jason Mattox on 05/20/2010 at 12:49 PM