VMware vShield App best practices list
After a couple of recent projects that implemented vShield app in various ways I thought it would be good to start building a list of best practices. These are some of the suggestions that I have collected in working with different customers and VMware people. I will continue to update as new things come to light.
Consider reading my list of vCloud best practices when you are done with this list, since they are used together often.
- Do not deploy vShield manager appliance to a cluster that it will be protecting, can cause connection to itself and vCenter to be lost. (With vShield 5.0.1 you can exclude the appliance from protection, but I would still avoid)
- Access to default services like DNS, syslog, NTP and other similar services that all your VMs need access to should be created as Layer 3 low precedence rules at the datacenter level.
- To provide additional resiliency beyond HS considering using Fault Tolerance (FT) for protecting vShield Manager
vShield App instances (Appliances)
- When deploying use local datastore on host if available to prevent accidental vMotion
- Consider setting DRS host affinity to make sure the vShield app appliance does not get vMotioned off of host, DRS is disabled by default for the appliance VM.
- Follow vSphere hardening recommendations for virtual switches
- Use Security Groups to group together server of same functions (Domain controllers, Web server, DB server etc.)
- Ensure that the HA restart priority for the vShield App appliance is set to high to ensure it is the first to restart, making sure that its running before the VMs its protecting are started.
About Brian Suhr
Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design