Architecting a vRealize Log Insight Solution : vRealize Log Insight Management Environment
   
vRealize Log Insight Management Environment
VMware strongly recommends separating management components into a logically or physically separate out-of-band management infrastructure, or management pod. The management pod can host the virtual machines that provide management services to the production workloads within the infrastructure. For example, services such as Active Directory, vCenter Server, vCenter Single Sign-On, syslog, storage array management tools, VMware Site Recovery Manager™, VMware vRealize Operations Manager™ or vCloud Director for Service Providers components can all reside in the management pod.
The primary benefits of separating the management components from the production resources they are managing include:
Quicker troubleshooting and problem resolution, as management components are strictly contained within a relatively small and manageable cluster.
Resource isolation between workloads running in the production environment and the actual systems used to manage the infrastructure.
Design the management infrastructure with the following host, storage and networking considerations:
ESXi Local USB/SD boot. Do not use auto deploy or boot from SAN. (It is likely that the management tools and services required to boot will be running from this environment, creating a “circle of dependency”.)
Highly available vSphere cluster configuration. Shared storage can be provided by Virtual SAN or a physical storage device to facilitate HA, VMware vMotion®, and DRS.
High availability of virtual and physical network switching components.
A minimum of N+1 resilience for all physical components.
Simplified configuration of each component for quicker disaster recovery and improved RTOs.
The following figure shows the management cluster conceptual design.
Figure 7. Typical Management Environment Conceptual Design
A primary goal of the management environment is simplicity. Designing a simple and static environment minimizes the risks of misconfiguration or human error. Furthermore, limiting the need for change and minimizing the technologies employed further reduces risk and speed up RTOs, should an outage or problem arise.
Running the management components on a large cluster or within a mixed production cluster complicates troubleshooting and makes it more difficult to track down management virtual machines in a recovery scenario. The optimum size of the management cluster will vary depending on the service provider’s requirements for management components. VMware recommends a minimum of a three-node cluster to provide sufficient resources to manage the production infrastructure components while maintaining the recommended operational availability of N+1. You can scale out hosts further if the management cluster becomes resource constrained.
Physically separating the management cluster to different racks, hosts, and switches provides a clear demarcation point between the management and production workloads, and helps to prevent an outage in which one environment affects the other. It might also be appropriate to place a firewall between the two environments to enhance security. The ultimate aim of the management pod is that any type of incident or outage affecting the production system cannot impact the management tools, and any type of problem with the management components cannot impact the production workload systems.