By Antonin Perron
Have you ever questioned yourself about the environment you are responsible for and wondered how your servers and applications interact?
VMware Infrastructure Navigator (VIN) is a very powerful tool within VMware’s Cloud Management Platform that can answer such questions and provide application dependency mappings across your environment. Unfortunately, VIN is often forgotten in discussions. Why? Great question! VMware needs to do a better job of showing its value and ensuring our customers utilize this forgotten gem in our toolset. Application dependencies mapping is lacking from competitive Cloud Management offerings, so VIN is a differentiator that could provide tremendous value when trying to deploy and secure applications.
I have had various conversations with customers who are trying to find a quick and easy way to understand their applications workflow and how their environments are actually communicating at various levels, from a virtual and physical standpoint. Leveraging VIN will help in IT consolidation projects, workload migrations, defining firewall flows, and understanding communication from and to the virtual and physical environments.
Used in conjunction with other VMware products, VIN will help with architecture and design. As an example, when defining a disaster recovery (DR) fail-over plan within Site Recovery manager, knowing the applications workflow will help build that plan and prioritize application recovery by grouping the virtual machines. Finally, leveraging the network information (i.e. IPs, ports, services, etc.) captured by VIN will help define NSX distributed firewall (DFW) rules and implement micro-segmentation.
Virtual Infrastructure Administrators can leverage visibility of day-to-day operational management for quicker problem triage, proactive virtual environment resource planning, managing changes, accurate business continuity, recovery planning, and more.
VIN is provided in OVA format (single virtual machine appliance) and has a pre-built application database with easy and accurate labeling of application names and version numbers.
Application relationships extend to virtual machines, hosts, clusters, datastore folders, and virtual networks. VIN can map one hop away to gather information and offers the dependencies via maps and tabular presentations. It is also possible to extract the database information via PowerShell to an Excel format, helping you with internal and external communications. The following diagram shows incoming and outgoing dependencies for each object in the tree. Dependencies from the tabular and maps are exportable to a CSV format.
VIN Architecture and System Requirements
VIN registers with a vCenter server and installs a plug-in in the vSphere Web Client. It probes guest virtual machines with supported operating systems that are running compatible versions of VMware tools. Virtual machines must be powered on and accessible for VIN to gather the information. Data is inserted into the vCenter Inventory service with a default retention period of 72 hours, which can be extended if necessary.
User-Defined Services and Application Definitions
Services that are not part of the vCenter Infrastructure Navigator database are categorized as unknown services. VIN allows you to custom define unknown services within the database. Once defined, these services will be utilized for all discovered instances of the application.
From a VIN perspective, the manual application feature allows you to mark a collection of virtual machines with an application name. From a vCenter Operations Manager standpoint, it can then show the health of that application group, rather than individual virtual machines.
VMware NSX and VIN
As mentioned, application definitions, customized services, and all the other information contained in VIN can help with NSX deployments. Using VIN will help to define security groups, tags, and IP sets necessary to develop micro-segmentation rules.
Similar to application definitions, security groups are a collection of assets or grouping objects in the vSphere inventory. They can be used to allow or deny security policies for applications and or solutions. A subset of virtual machines will belong to the same security group and can then be used in Source and/or Destination fields or be applied to other fields of DFW policy rules.
Having the network information of all objects helps when defining a collection of IP addresses necessary to create the IP sets.
For example, security tags can be assigned to virtual machines using the services, user-defined services, or the application definitions from VIN, for use in NSX DFW rules.
Antonin Perron is a Technical Account Manager for VMware based in Ontario, Canada. He has over 17 years of IT experience filling various roles and after 12 years, 5 overseas deployments as a Communications Specialist in the Canadian Armed Forces, he joined VMware in 2015. He works with Shared Services Canada, Government of Canada, as the only one VMware resource on site and he his using experience to provide technical guidance, optimization recommendations to facilitate their workload migration across their 43 departments.