Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.
This morning, my colleague Joe Hoegler pointed me to a new post on VMware’s Business Critical Applications blog entitled High Availability for Exchange 2010 without DAG. Joe recently achieved his Microsoft Certified Master on Exchange 2010 and has a great deal of experience with Exchange. He and I have worked together on projects where we’ve been successful in virtualizing Exchange 2010 on vSphere. We both read the article and spent some time discussing it and both came to the same conclusions, so we wanted to share some of our collective thoughts.
Are you looking to build Windows Failover clusters on VMware vSphere with EqualLogic storage? If so, make sure to use the new EqualLogic Multipathing Extension Module (MEM) for VMware vSphere (assuming you have at least Enterprise licensing). There are several reasons that make the MEM an obvious choice, but let’s first review what the MEM actually is.
In VMware vSphere, there are several native Path Selection Policies (PSP) that handle how the ESX or ESXi hosts connect to the storage infrastructure. For best performance, most use VMware’s native for Round Robin PSP for iSCSI MPIO. This allows you to better utilize all of your NICs rather than keeping the paths in an active/standby configuration. In addition to the native policies, VMware has also opened this up to storage vendors to write their own PSPs to take better advantage of their storage arrays.
Continue reading…
Quite a while back I saw that Eric Sloof had figured out how to add his Twitter feed directly into the VI Client. I thought it was clever but didn’t really give it much more thought than that.
Today I decided to take that concept and extend it to systems that you might manage alongside your VI3/vSphere environment. Storage management seemed like the obvious first choice.
Continue reading…
For quite a while there has been confusion over how VMware’s Transparent Page Sharing (TPS) feature works with vSphere 4 running on Nehalem (or other modern) processors. Many people were noticing that it appeared that TPS was not actually working anymore and looked for ways to fix the problem.
In my recent post on the effects of ASLR in vSphere the comments turned into a discussion about TPS on modern processors. And there are countless posts about this issue on the VMTN forums where folks are looking for a fix. In reality nothing is broken and there is no need to fix the issue.
Continue reading…
When VMware released vSphere 4 last year, one of the changes they made was a completely re-written software iSCSI initiator. This was done to optimize performance which is great considering how popular iSCSI SANs have become. They also gave the ability to use Round Robin MPIO (mutlipathing) in the software initiator in addition to Fixed Path and MRU which were previously available.
I’m working on a vSphere implementation using Dell EqualLogic SANs and wanted to configure Round Robin on all of my datastores. Dell has a great whitepaper on how to set this up, but unfortunately the document fails to mention one key thing: this doesn’t change the default path selection plugin (PSP) from Fixed to Round Robin. That means that you’ll have to set the multipathing policy to Round Robin on all of your existing datastores and will have to remember to do that on all future datastores. When you’ve got multiple ESX hosts with lots of datastores this can quickly become a pain.
I’ve seen a lot of talk lately about VMware’s Transparent Page Sharing (TPS) and how it is affected by ASLR in Windows 2008/Windows 7. I wanted to see if there was any real measurable reduction in shared memory when using ASLR vs. when it was disabled. First, let’s talk about what TPS and ASLR actually are and what the acronyms mean.
Continue reading…
With the release of VMware vSphere 4, VMware has released a very powerful management tool called Fault Tolerance (FT). At a basic level, FT allows you to keep two virtual machines (a Primary VM and a Secondary VM) running in lockstep on two different physical ESX hosts. If one of the ESX hosts were to experience a hardware failure, the VM protected with FT would remain running on the second host without any downtime. This can greatly reduce downtime due to hardware failures and provide increased service levels for important applications.
FT is often compared to Microsoft Windows Failover Clusters, formerly Microsoft Cluster Server (MSCS), and in fact many have talked about how FT can replace Microsoft clustering altogether. Rather than jump to conclusions like this, it is important to understand the use cases for both technologies. In addition, there are several limitations to FT that need to be considered. Here are some important points to remember about FT:
Discovering that your ESX hosts have been unknowingly creating open snapshots can be an alarming, not to mention dangerous, event.
Third party storage and backup vendors frequently call the vCenter API to issue a snapshot creation of running virtual machines before they grab a copy of the virtual machine’s hard disk – VMDK files – which are located on the VMware VMFS datastore. This process is typically followed by an immediate deletion of the snapshot file which will merge the changes back into the initial VMDK file. Problems can occur when this process does not complete successfully leaving you with an “open” snapshot. This problem is compounded when it occurs multiple times against the same guest.
Each open snapshot can significantly degrade virtual machine performance and also contribute to poor storage utilization. Unless you monitor each of your virtual machines on a daily basis, you could quickly be left with an uncomfortable situation on your hands.