A couple of weeks ago I wrote on vShield. As I said then, the Asia Pacific and Japan vSpecialists have spent a lot of time on this wonderful product. We love it. The purpose of my blog entry was to highlight a best practice that would avoid an annoying issue. That issue is that vShield App installation on ESX hosts running a vCenter virtual machine can disconnect vCenter from the network. The workaround–documented in the vShield Administration Guide–is to run vCenter and vShield manager on a management cluster. Case closed. Well, not yet.
Last last week Beth Pariseau at SearchServerVirtualization.com wrote a piece on vShield that quoted my blog. Beth kindly asked me for comment before her article went live but we were unable to connect. After reading her article, I wanted to add my thoughts to the discussion. I mailed these to her and want to share them with you here.
First, one of her claims is incorrect. Beth wrote, and cited an anonymous systems integrator in support, that “If vShield Manager is down, everything on its network is down.” The helpful technologists at VMware confirmed my understanding that the vShield architecture will not allow this. A vShield Manager failure will not affect network traffic.
vShield manager is a central point of management, but not a nexus through which traffic flows. The vShield architecture uses traffic-controlling security appliances on each ESX host managed by vShield. In the event of a vShield manager failure, the vShield security appliances continue with policies they previously received. A vShield Manager failure temporarily makes it difficult to change security policies but in no way affects connectivity or existing policies.
Furthermore, vShield Manager is protected by HA’s VM-aware monitoring. If the appliance’s guest operating system hangs, vpxa will restart the vShield Manager appliance. If the host running vShield manager fails, then HA will restart the appliance on another host in the cluster. This means that in the event of a vShield Manager failure, not only will the network continue to work with its existing security policies, but the network will be unmanageable for only the short duration measured by the appliance’s boot time.
This brings us to the issue I blogged about: installing vShield App on an ESX host running a vCenter virtual machine can disconnect the vCenter’s virtual NIC. VMware’s straightforward guidance for its management products is to run them in a separate management cluster. Following this recommendation vShield will only secure non-management virtual machines and this vCenter VM network connectivity issue cannot occur. While my support of this best practice is lukewarm, I recognize that some of VMware’s customers do follow it. And I am told that VMware is working on ensuring that all management products can be run as virtual machines on any host.
At the risk of belaboring the central point of this post, I will again say that no single appliance failure can bring down the network. I have already named vShield Manager in this regard and I reiterate with vCenter.
Beth solicited my comments and I explained my understanding of the article’s mistake. I also recommended she engage our friends at VMware, who I know from experience are always thrilled to share in limitless detail the workings of their fine products. I trust that Beth and VMware will get the right word out to customers. But as a constant commentator on VMware’s continued development on vShield, I wanted to append my thoughts to the ongoing vShield discussion.
VMware’s continued streak of incredible innovation of a constant source of marvel. When I expose warts on their products it is to help their faithful enthusiasts get the most out of VMware’s offerings. I believe Beth’s article was along that same vein: raise awareness and inspire continued improvement. Anyone that reads her article or mine should consider these tiny warts in the ongoing epic of datacenter rebirth.