VMware NSX-T

Application Version and Upgrade Details

Introduction

VMware NSX-T™ Data Center provides an agile software-defined infrastructure to build cloud-native application environments. NSX-T Data Center focuses on providing networking, security, automation, and operational simplicity for emerging application frameworks and architectures that have heterogeneous endpoint environments and technology stacks.

VMware NSX

VMware NSX is a network virtualization and security platform that enables the virtual cloud network, a software-defined approach to networking that extends across data centers, clouds and application frameworks.

VMware NSX is suitable for all infrastructure types:

• Multi-cloud environments
• On-premises data centers
• Bare metal servers
• Containerized workloads

Benefits of NSX-T

The main benefit is that NSX-T can be deployed in heterogeneous environments with many different components. NSX-T is not under the confines of the vCenter deployment. You can have multiple vCenter servers and use one NSX manager as a single pane of glass for controlling your virtual network. Or, you do not have to deploy a vCenter at all. Instead, you can choose ESXi as the operating system in the NSX-T GUI, for example.

NSX-T Main Components:

The primary components of VMware NSX-T are:

• NSX-T Manager: provides graphical user interface (GUI) and RESTful API for creating, configuring, and monitoring NSX-T components, such as segments and gateways.

• NSX-T Controller: they are responsible for the programmatic deployment of virtual networks across the entire NSX-T architecture, and control the virtual networks and overlay transport tunnels.

• NSX-T Edges: provides routing services and connectivity to networks that are external to the NSX-T deployment.

• Logical Firewall: NSX-T handles traffic in and out of the network according to firewall rules.

• Logical Routers (Gateways): NSX-T Gateways provide North-South connectivity so that workloads can access external networks and East-West connectivity between different logical networks.

• Transport Zone: A transport zone defines a collection of hosts that can communicate with each other across a physical network infrastructure.

Prerequisites

• OpsRamp Classic Gateway 14.0.0 and above.
• OpsRamp Nextgen Gateway 14.0.0 and above.
  Note: OpsRamp recommends using the latest Gateway version for full coverage of recent bug fixes, enhancements, etc..

Hierarchy of NSX-T resources

NsxT Manager Cluster
    – NsxT Manager (i.e, nodes)
    – NsxT Edge Cluster
        – NsxT Logical Router
            – NsxT Firewall
    – NsxT Transport Zone
        – NsxT Transport Node (i.e, Host(ESXi) nodes & Edge nodes)
            – NsxT Edge Physical Network Interface
            – NsxT Host Physical Network Interface
            – NsxT Virtual Machine (i.e, Host & Edge VMs)
        – NsxT Logical Switch

Application Migration

1. Check for the gateway version as a prerequisite step - classic gateway-12.0.1 and above.
   Notes:

   • You only have to follow these steps when you want to migrate from sdk 1.0 to sdk 2.0.
   • For the first time installation below steps are not required.

2. Disable all configurations associated with sdk 1.0 adaptor integration application.

3. Install and Add the configuration to that sdk 2.0 application.
   Note: refer to Configure and Install the VMware NSX-T Integration & View the VMware NSX-T Details sections of this document.

4. Once all discoveries are completed with the sdk 2.0 application, follow any one of the approaches.

   • Direct uninstallation of the sdk 1.0 adaptor application through the uninstall API with skipDeleteResources=true in the post request
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
         }

     
     
     (OR)
     
     
   • Delete the configuration one by one through the Delete adaptor config API with the request parameter as skipDeleteResources=true
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/config/{configId}?skipDeleteResources=true.
     
     
   • Finally, uninstall the adaptor application through API with skipDeleteResources=true in the post request.
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
         }

Default Monitoring Configurations

VMware-NSX-T application has default Global Device Management Policies, Global Templates, Global Monitors and Global metrics in OpsRamp. Users can customize these default monitoring configurations as per their business use cases by cloning respective global templates and global Device Management Policies. OpsRamp recommends doing this activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   OpsRamp has a Global Device Management Policy for each Native Type of VMware-NSX-T. You can find those Device Management Policies at Setup > Resources > Device Management Policies, search with suggested names in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: vmware-nsx-t NsxT Manager Cluster - 2 (i.e, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

2. Default Global Templates

   OpsRamp has a Global template for each Native Type of VMware-NSX-T. You can find those templates at Setup > Monitoring > Templates, search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: vmware-nsx-t NsxT Manager Cluster Template - 2 (i.e, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

3. Default Global Monitors

   OpsRamp has a Global Monitors for each Native Type which has monitoring support. You can find those monitors at Setup > Monitoring > Monitors, Search with suggested names in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: NsxT Manager Cluster Monitor vmware-nsx-t NsxT Manager Cluster 2 (i.e, monitorKey = NsxT Manager Cluster Monitor, appName = vmware-nsx-t, nativeType = NsxT Manager Cluster, version = 2)

Configure and Install the VMware NSX-T Integration

1. From All Clients, select a client.
2. Go to Setup > Integrations and Apps.
3. The INSTALLED INTEGRATIONS page, where all the installed applications are displayed.
   Note: If there are no installed applications, it will navigate to the ADD APP page.

4. Click + ADD on the INSTALLED INTEGRATIONS page. The AVAILABLE INTEGRATIONS AND APPS page displays all the available applications along with the newly created application with the version.
   Note: You can even search for the application using the search option available. Also you can use the All Categories option to search.

5. Click ADD in the VMware NSX-T application.
6. In the Configurations page, click + ADD. The Add Configuration page appears.
7. Enter the below mentioned BASIC INFORMATION:

Notes:

• By default the Is Secure checkbox is selected.
• NSX-T Manager IP Address and Port should be accessible from Gateway.
• Select the following:
  • App Failure Notifications: if turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.
  • Event/Alert Polling: enables integrating third party alerts into OpsRamp using further configurations.
    • Below are the default values set for:
      • Event/Alert Cleared Status: Possible values of Event/Alert Cleared Status configuration property are “ACKNOWLEDGED”,“SUPPRESSED”,“RESOLVED”.
      • Event/Alert Severity: Possible values of Event/Alert Severity configuration property are “CRITICAL”,“HIGH”,“MEDIUM”,“LOW”.
      • Event/Alert Severity Mapping: Possible values of Event/Alert Severity Mapping Filter configuration property are “CRITICAL”:“Critical”,“HIGH”:“Warning”,“MEDIUM”:“Warning”,“LOW”:“Info”.
  • API Timeouts: These are the maximum API Timeouts that the application can use to connect and get responses from the end device.
    • Connection Timeout in Secs: a time period in which a client should establish a connection with a server.
      Note: By default, 60 is selected.
    • Connection Request Timeout in Secs: a time period required to process an HTTP call: from sending a request to receiving a response.
      Note: By default, 10 is selected.
    • Socket Timeout in Secs: a maximum time of inactivity between two data packets when exchanging data with a server.
      Note: By default, 10 is selected.

8. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

9. In the RESOURCE TYPE section, select:
   • ALL: All the existing and future resources will be discovered.
   • SELECT: You can select one or multiple resources to be discovered.
10. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:
    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly
11. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it. From the same page, you may Edit and Remove the created configuration.

12. Click Next.

13. Below are the optional steps you can perform on the Installation page.

• Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

  Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

• Click +ADD to create a new collector by providing a name or use the pre-populated name.

14. Select an existing registered profile.

15. Click FINISH.

The integration is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the VMware NSX-T application.

View the VMware NSX-T Details

The VMware NSX-T integration is displayed in the Infrastructure > Resources > Cluster. You can navigate to the Attributes tab to view the discovery details and Metrics tab to view the metric details for VMware NSX-T.

The NSX-T Manager(nodes), Edge Cluster and Transport Zones are displayed under Components:

The Metrics tab to view the metric details for VMware NSX-T

Resource Filter Input Keys

VMware NSX-T application resources are filtered and discovered based on below keys:

Supported Alert Custom Macros

Customize the alert subject and description with below macros then it will generate alert based on customisation.
Supported macros keys:

Supported Metrics

Risks, Limitations & Assumptions

• Application can handle Critical/Recovery failure notifications for below two cases when user enables App Failure Notifications in configuration
  • Connectivity Exception
  • Authentication Exception
• Application will not send any duplicate/repeat failure alert notification until the already existed critical alert is recovered.
• Application cannot control monitoring pause/resume actions based on above alerts. Metrics can be used to monitor the resources and can generate alerts based on the threshold values.
• vmware-nsx-t Event/Alert polling will be started only if the user enables Event/Alert Polling in configuration.
  Notes:
  • Here Event/Alert polling support is given for vmware-nsx-t Alarms only.
  • When a status value which presents in Event/Alert Cleared Status field occurs, OpsRamp will create an Ok alert accordingly. Otherwise, OpsRamp will create an alert based on Event/Alert Severity Filter & Event/Alert Severity Mappings of the Event/Alert Polling configurations.
• Default values of Event/Alert Cleared Status configuration field are: ACKNOWLEDGED, SUPPRESSED, RESOLVED.
• Possible vmware-nsx-t status values are OPEN, ACKNOWLEDGED, SUPPRESSED, RESOLVED.
• Default/Possible values of Event/Alert Severity Filter configuration are CRITICAL, HIGH, MEDIUM, LOW.
• OpsRamp has provided default mappings to map vmware-nsx-t Severity with OpsRamp Severities as part of Event/Alert Severity Mapping configuration.
• Users can modify them as per their use-case at any point of time from the application configuration page. Possible OpsRamp Severities are Critical, Warning, Ok, Info.
• No support of showing activity log and applied time.
• This application supports both Classic Gateway and NextGen Gateway.