VMware NSX Advanced load balancer discovery
Summarize
Summary of VMware NSX Advanced Load Balancer Discovery
The ServiceNow Discovery application includes a VMware NSX Advanced Load Balancer discovery pattern designed to identify VMware NSX load balancers. This pattern leverages REST APIs and is activated by the NSX HTTP classifier responding to HTTP probes. It supports both legacy S series and newer T series NSX load balancers, maintaining consistent functionality and data collection across versions. To enable this discovery, customers must ensure their Discovery and Service Mapping Patterns application is up to date.
Show less
Prerequisites
- Enable NSX Basic Authentication: Must be configured within VMware NSX to allow secure API access.
- Update Applications: Ensure CMDB CI Class Models, Visibility Content, and Discovery and Service Mapping Patterns are current.
- Configure Authentication Credentials: Basic authentication credentials need to be set up within ServiceNow AI Platform with specific API permissions for NSX and NSX-T endpoints.
- Discovery Trigger: HTTP discovery triggers only if SSH or SNMP discovery fails, targeting the NSX Main Controller IP.
- Discovery Scheduling: Create or run a discovery schedule or quick discovery on the NSX Main Controller IP.
Data Collection and CMDB Impact
The discovery process populates the CMDB with detailed configuration items (CIs) representing NSX load balancer components, including:
- NSX Load Balancer: Includes edge names, IDs, IP addresses, and operational status.
- Load Balancer Service: Captures virtual server details such as names, IP addresses, ports, and listener protocols.
- Load Balancer Pool and Members: Includes pool names, member IPs, ports, and object IDs.
- Cloud Load Balancer Health Service: Monitors with details like monitor names, timeout settings, check intervals, protocols, and max retries.
CI Relationships
The discovery establishes relationships among load balancer CIs to provide a complete dependency map, such as:
- Load Balancer Services running on NSX Load Balancers.
- Load Balancer Services using Load Balancer Pools.
- Load Balancer Pools hosted on NSX Load Balancers and owning Pool Members.
- Health Services hosted on NSX Load Balancers and using Load Balancer Pools.
Troubleshooting
Common issues and recommendations include:
- Discovery REST Timeout: Occurs if the MID Server cannot process REST responses within the default 30-second timeout. Increase the
mid.sa.cloud.requesttimeoutparameter on the MID Server to allow more time. - Pattern Designer Timeout: During debugging, if a timeout occurs, increase the
sa.debugger.maxtimeoutparameter on the MID Server (default 240 seconds).
This discovery pattern enables ServiceNow customers to effectively identify and map VMware NSX Advanced Load Balancers and their components within the CMDB, ensuring accurate infrastructure visibility and dependency tracking for better service management.
The ServiceNow Discovery application uses the VMware NSX Advanced load balancer discovery pattern to find VMware NSX load balancers. Discovering some of these resources may require updating to the latest version of the Discovery and Service Mapping Patterns application from the ServiceNow Store.
Request apps on the Store
Visit the ServiceNow Store to view all the available apps, and for information about submitting requests to the store. For cumulative release notes information for all released apps, see the ServiceNow Store version history release notes.
Prerequisites
- Enable NSX Basic Authentication
- In VMware NSX, enable NSX Basic Authentication.
- Verify that the applications are up to date
-
- CMDB CI Class Models
- Visibility Content
- Discovery and Service Mapping Patterns
- Configure basic authentication credentials
- On the ServiceNow AI Platform, configure basic authentication credentials. The credentials must have the following API permissions:
- NSX:
- /api/4.0/edges
- /api/4.0/edges/<edge_id>loadbalancer/config
- NSX-T: /api/v1/edge-clusters
- NSX:
- Verify HTTP discovery is triggered against the NSX Main Controller IP
- The HTTP discovery is triggered only if SSH or SNMP discovery is unsuccessful.
- Create a discovery schedule
- Create the discovery schedule for VMware NSX load balancer discovery or run a quick discovery on the IP address of the NSX Main Controller. For more information about running a quick discovery, see Run a Quick Discovery.
Data collected by Discovery for VMware NSX Advanced load balancer
Discovery populates the data in the CMDB when running the VMware NSX Advanced load balancer patterns.
| Field | Description |
|---|---|
| Name [name] | Edge name. |
| Object ID [object_id] | Edge ID. |
| IP Address [ip_address] | IP address of the NSX Main Controller. |
| Operational status [operational_status] | Load balancer status: Active or inactive. |
| Field | Description |
|---|---|
| Name [name] | Virtual server name. |
| IP Address [ip_address] | Virtual server IP address. |
| Object ID [object_id] | Virtual server object ID. |
| Port [port] | Virtual server port with which to communicate. |
| Listener Protocol [listener_protocol] | Listener protocol. For example: HTTP, HTTPS. |
| Field | Description |
|---|---|
| Name [name] | Pool name. |
| Object ID [object_id] | Pool object ID. |
| Field | Description |
|---|---|
| Name [name] | Pool member name. |
| IP Address [ip_address] | Pool member IP address. |
| Object ID [object_id] | Pool member object ID. |
| Service port [service_port] | Pool member port with which to communicate. |
| Field | Description |
|---|---|
| Name [name] | Monitor name. |
| Object ID [object_id] | Monitor object ID. |
| Timeout in seconds [timeout_sec] | Time in seconds to wait for a response. |
| Interval in seconds [check_interval_sec] | Interval in seconds after which the monitor sends the request again. |
| Monitor type protocol [monitor_type] | Monitor type. For example: HTTP, HTTPS, TCP. |
| Request path [request_path] | Path where the monitor sends the request. |
| Max retries [max_retries] | The maximum number of times the resource is tested before it is declared "Down". |
CI relationships
| CI | Relationship | CI |
|---|---|---|
| Load Balancer Service [cmdb_ci_lb_service] | Runs on::Runs | NSX Load Balancer [cmdb_ci_nsx_lb] |
| Load Balancer Service [cmdb_ci_lb_service] | Uses::Used by | Load Balancer Pool [cmdb_ci_lb_pool] |
| Load Balancer Pool [cmdb_ci_lb_pool] | Hosted on::Hosts | NSX Load Balancer [cmdb_ci_nsx_lb] |
| Load Balancer Pool [cmdb_ci_lb_pool] | Owns::Owned by | Load Balancer Pool Member [cmdb_ci_lb_pool_member] |
| Cloud Load Balancer Health Service [cmdb_ci_lb_health_service] | Hosted on::Hosts | NSX Load Balancer [cmdb_ci_nsx_lb] |
| Cloud Load Balancer Health Service [cmdb_ci_lb_health_service] | Used by::Uses | Load Balancer Pool [cmdb_ci_lb_pool] |
Troubleshooting
| Symptom | Cause | Solution |
|---|---|---|
| Discovery fails. The discovery message contains the information about an error caused by the REST timeout. | There are many CIs sending the REST call response in the deployment. The MID Server cannot process the REST call response without exceeding the time limit controlled by the mid.sa.cloud.request_timeout parameter. | By default, the mid.sa.cloud.request_timeout parameter is set to 30000 milliseconds. Increase the value of this parameter on the relevant MID Server and run discovery again. Note: If the Configuration Parameters related list for the relevant MID Server does not show this parameter, you may need to add it. |
| Pattern Designer fails during a debug session. The Pattern Designer message contains information about an error caused by a timeout. | The Pattern Designer fails because of a timeout during pattern debugging (and not during discovery). | By default, the sa.debugger.max_timeoutparameter is set to 240 seconds. Increase the value of this parameter on the relevant MID Server. |