Overview
This section describes the different types of nextgen gateway installation procedures.
The NextGen gateway collector is currently deployed in the following three ways:
This section also includes:
- Installation of High Availability Gateway
- Installation of NextGen Gateway on Ubuntu VM
- Helm Based Deployment
Note
- OpsRamp provides support for ISO/OVA images built on top of Ubuntu operating system. If a customer is using OpsRamp ISO/OVA, then our team will assist you in configuring your Kubernetes cluster. However, for customers who do not use OpsRamp’s ISO/OVA and opt to utilize their own Kubernetes cluster, then they will be responsible for configuring and maintaining the Kubernetes cluster.
- Starting from version 18.0.0, when you deploy a new NextGen Gateway, it will be created as a separate device within the platform. However, this change only applies to new deployments. If you are updating an existing NextGen Gateway, it will continue to function as before without any changes. This is only applicable for ISO/OVA.
Examples:- For Single-Node Deployment: One agent is installed on a single server and one gateway device is deployed in the infrastructure.
- For Three-Node Deployment: Three agents are installed on three separate servers and one gateway device is deployed in the infrastructure.
- For Single-Node Deployment: One agent is installed on a single server and one gateway device is deployed in the infrastructure.
For advanced configuration, refer to the Collector Bootstrap Tool documentation.
Gateway Capacity Parameters
| Number of managed resources | Required server capacity |
|---|---|
| Up to 100 resources | 4 CPU cores, 8 GB RAM / 50 GB Disk / 1 NIC |
| Up to 500 resources | 8 CPU cores, 16 GB RAM / 50 GB Disk / 1 NIC |
| Greater than 500 resources at a single site | Deploy multiple gateways |
The above capacity parameters are approximate and can vary depending on various factors, such as template frequency, resource type, network protocol, and the type of metrics.
FAQs
What are the default PODs in NextGen Gateway?
The following pods are created when you install the NextGen Gateway:
- Primary Gateway Application POD:
nextgen-gw-0
This is the main pod where the gateway-related code runs. It contains the following containers:- Postgres: A database for storing gateway-related data.
- VProbe: The Gateway Application Container responsible for discovery, monitoring, and alerting.
- NativeBridge: A helper container for the VProbe container to execute commands.
- Cache Storage Pod:
nextgen-gw-redis-master-0
This pod is used by SDK applications to store cache data. - Optional Proxy Server Pod:
squid-proxy-596884d98b-jtm7n
This pod acts as a proxy server for proxy agents. It is created only if the Squid Proxy service is enabled. - Optional Third-Party App Pod:
stan-0
This pod is used by third-party SDK applications to publish data into a queue. It will be created only if the Third-Party App service is enabled.
Why do we install an OpsRamp Agent on every Node in the Cluster (ISO/OVA)?
Installing an OpsRamp Agent on each node ensures that if there is a disconnection between the Gateway and OpsRamp cloud, you can still launch the Agent console to troubleshoot the issues.
Without the Agent, you would be unable to access the Gateway console for troubleshooting during such disconnections.