Deployment scenarios
Depending on whether you have Helix subscription or BMC Helix IT Operations Management on-premises entitlement, and the location of the third-party product (SaaS, On-premises) from which you want to collect data, deploy BMC Helix Intelligent Integrations as described in the following scenarios.
Deployment scenarios for Helix subscribers
If you have the Helix subscription, depending on the data source location (SaaS, On-premises), the following deployment modes are available:
- Use the SaaS deployment of BMC Helix Intelligent Integrations
- Deploy the gateway in your on-premises environment
SaaS deployment of BMC Helix Intelligent Integrations
Use the SaaS deployment of BMC Helix Intelligent Integrations to collect data from the third-party products (on-premises and SaaS). In this scenario, collected data is sent to the BMC Helix applications that are part of your SaaS environment, as shown in the following diagram:
Port requirements
Depending on the third-party product (data source) location, the following ports are required for communication:
Data source location | Ports |
|---|---|
On-premises | Data source port: REST/ JDBC port Obtain the egress IP of your tenant. Request the egress IP from BMC Support if you don't already have it. To allow communication from the egress IP (data source connector) to the data source, open the port on which the data source is listening (default is 443). |
SaaS | Data source port: If the data source is externally accessible on port 443, no other port requirements. If the data source is not accessible, obtain the egress IP of your tenant. Request the egress IP from BMC Support if you don't already have it. To allow communication from the egress IP (data source connector) to the data source, open the port on which the data source is listening (default is 443). |
On-premises deployment of the BMC Helix Intelligent Integrations gateway
Deploy the BMC Helix Intelligent Integrations gateway in your on-premises environment to collect data from third-party products (on-premises and SaaS). In this scenario, collected data is sent to the BMC Helix applications that are part of your SaaS environment, as shown in the following diagram:
Port requirements
Depending on the third-party product (data source) location, the following ports are required for communication:
Data source location | Ports |
|---|---|
On-premises | BMC Helix Intelligent Integrations ports:Accessing the BMC Helix Intelligent Integrations UI from a client requires the following ports:
|
Data source port: REST/ JDBC port | |
SaaS | BMC Helix Intelligent Integrations ports: Accessing the BMC Helix Intelligent Integrations UI from client requires the following ports:
|
Data source port: REST port |
Deployment scenario for BMC Helix IT Operations Management on premises
If you have the BMC Helix IT Operations Management on-premises entitlement, deploy the BMC Helix Intelligent Integrations gateway in your on-premises environment. In this scenario, collected data is sent to the BMC Helix applications that are part of your on-premises environment, as shown in the following diagram:
Port requirements
Depending on the third-party product (data source) location, the following ports are required for communication:
Data source location | Ports |
|---|---|
SaaS | BMC Helix Intelligent Integrations ports: Accessing the BMC Helix Intelligent Integrations UI from a client requires the following ports:
|
Data source port: REST/ JDBC port. If a proxy is used for the incoming connection to the data source, the proxy port. | |
On-premises | BMC Helix Intelligent Integrations ports: Accessing the BMC Helix Intelligent Integrations UI from a client requires the following ports:
|
Data source port: REST/ JDBC port. If a proxy is used for the incoming connection to the data source, the proxy port. |
High availability deployment for the on-premises gateway
Provide high availability for the BMC Helix Intelligent Integrations on-premises gateway by deploying it in an active-passive high availability configuration. Use a standalone MinIO instance or an Amazon Simple Storage Service (S3) instance for the backup and restore location of the on-premises gateway.
When you update the docker-compose.yaml file or podman-compose.yaml file on a gateway instance with the bucket name and other MinIO or Amazon S3 instance details, a bucket is created with the specified name on the instance. The bucket contains the Leader_backup.json file for storing the backup of the configuration file. The instance is assigned as Active in the metadata of the configuration backup file. When you update any subsequent gateway instance with the MinIO or Amazon S3 details, it is assigned as Standby. The primary instance updates the configuration backup file on the MinIO or Amazon S3 instance according to the data push interval.
The secondary instance polls the backup file on the MinIO or Amazon S3 instance. The timestamp of the last backup performed by the primary instance is checked against the system clock of the secondary instance. If the difference between the backup file timestamp and system clock is greater than the data push interval, the secondary instance takes over and is assigned as Active in the metadata of the backup file. The existing primary instance becomes the secondary instance and is assigned as Standby. The backup file is restored on the primary instances and data collection resumes.
Scenario
Consider two nodes, Node A and Node B, which are assigned as primary and secondary instances. Node A is backed up every 5 minutes on MinIO and Node B polls MinIO every 5 minutes. Suppose Node A was last backed up at 01:00. If Node A fails at 01:02, Node B will evaluate its local time with the time of last update at 01:05 and 01:10. At 01:10, the difference is 8 minutes (01:10 – 01:02), which is greater than 5 mins. This difference causes Node B to come out of the standby mode and start data collection.