Hey…Rob Randell here again. A new feature that we will be sprinkling into the security blog is entries that will talk about some interesting or frequently asked questions that we feel deserves some more explanation to more than just the person who asked the question.
Recently we had a question come up a few times as to the resiliency of the vShield Endpoint SVM and what happens if it fails or if the app itself stops responding. Specifically, the question is: “What kind of availability capabilities do we have for the vShield Endpoint SVM?”
The issue obviously is that if it does fail the VMs being protected by the SVM for AV scanning will be vulnerable to virus’ during the time it is down. So because of this issue, we’ve built in “health monitoring” of all of its components through standard vCenter Events and Alerts. These events can trigger an alert in vCenter, which in turn can trigger an action. This is well documented in the vShield Admin Guide staring on page 81. That said, we thought it would be worthwhile to discuss this in deeper detail to bring it to folks attention.
The vShield Endpoint SVM that is provided by our partners is constantly monitored by the vShield Manager. If for some reason the SVM stops responding the vShield Manager will send an event to vCenter that will trigger an alarm. The screenshot below shows the prebuilt alarm for alertling on the status of the SVM appliance itself.
These alarms can be used to perform a number of actions like send a notification email or SNMP traps, reset the SVM, or reboot the VM. In addition, the host can be put into maintenance mode, which will force all VMs to migrate to other hosts in the same resource container that have working SVMs providing protection. It can be configured to even run a command. For example, because the SVM is stateless, a standby SVM can even be configured (by cloning the original SVM after registration) to take over in case of a failure. This can be accomplished through a script which can be run should the alarm be triggered. This allows us to minimize the downtime of an SVM as well as get notified should an issue such as this should arise so it can be responded to very quickly. The screenshot below shows a subset of the list of actions that can be taken.
So in short, there are a number of options to provide resiliency and redundancy into the deployment of the vShield Endpoint SVMs. Expect more of these FAQ type blogs in the future on the VMware Security Blog.