In the prior article, Part 1: IBM Satellite replacing the Secure Gateway, we discussed IBM’s change to how data is loaded through a VPN tunnel into Planning Analytics on Cloud, PAoC. The IBM Satellite replacement option should be ready later in August.
Ready to use:
Once available, the Satellite Connector can be used to create named Connectors that will need to be connected to Satellite Connector Agents that are running in your private-cloud/on-premises. A “Connector” defines its VPN tunnel from IBM Cloud to an on-premises Agent and will contain the data source “Endpoints” that are associated with that specific tunnel. It is also where data sources get added or created that need that particular Connector-Agent VPN tunnel. With a valid connected Connector, we can import the existing data sources from the Secure Gateways that we created in PAoC previously. Once imported, they will only work through the Satellite Connector they are imported into, but they can be reverted to the Secure Gateway temporarily should an issue arise. However, the clock is ticking on the Secure Gateway’s availability so “temporarily” indeed.
The aforementioned “data sources” are what the Secure Gateway and Satellite Connector use to create the ODBC System DSNs in PA. These are the System DSNs that the TI processes use when “Database Connection” is chosen as a “Data source”. This “switch” to Satellite is telling the System DSN to use the Satellite tunnel defined by the “Connector” to connect to an private cloud/on-premises database.
In a complex PAoC model environment with many Secure Gateways and data sources, it remains to be seen how well it will work having a blend of Secure Gateway and Satellite Connector data sources during the transition process if that transition is spread over several days. It has also been reported that while both the SG Client and SC Agent can be installed to the same Windows server, they can’t be used concurrently on one host server. It might be worth planning on transitioning all Dev data sources on one day, validating and testing, and then transitioning all of Prod on another day if temporarily blending SG and SC is too unknown or problematic.
Firewall considerations:
The Secure Gateway Client has a dependency on needing to make outbound requests on ports 443 and 9000, but the Satellite Connector Agent only needs port 443 for outbound activity. Since the VPN tunnel starts when the Agent service starts, inbound firewall rules should not be needed as the tunnel is initiated internally and is the result of outbound activity.
The target IP addresses are different for Satellite than Secure Gateway so any outbound corporate firewall or proxy rules you may have will need to add three IBM IP addresses depending on the PAoC region you are in. The IBM Satellite IP addresses by region list can be viewed here. Enable all three IP addresses for your region as being allowed outbound targets for your firewall or proxy security rules.
In either case, the on-premises tools “phones home” to IBM Cloud on port 443 when the service is started, utilizing a unique connector ID and Access key that PAoC administration provides when a Connector is created. For Satellite, these will probably have an expiration date of 90 to 365 days after the creation date. This is an assumption based on the current Secure Gateway settings.
Additionally, since ODBC requests from PAoC will be traversing the tunnel and exiting from the on-premises Agent hosted on a server, they need to be able to access their targeted data source. Any internal network security will have to allow for the Agent’s host server to connect to the database’s server on the database’s prescribed port. (e.g. port 1433 typically for SQL Server, etc.)
Install Information:
For the Windows service
Installing the Satellite Connector Agent is straight forward.
What to do now:
Determine your IBM PAoC data center and whitelist the destination IP addresses in any corporate firewall or proxy servers. IBM Satellite IP list here.
Identify/provision hardware or virtual machines for Windows Servers where the Satellite Connector Agent can be installed. You can reuse existing Secure Gateway Client servers, but the Secure Gateway and Satellite services cannot be used concurrently on the same server.
You will need one Windows server on-premises for each PAoC Environment you have, Dev and Prod, whereas Secure Gateway could have more than one Gateway Connection to one Secure Gateway Client. This could change.
Transition Dev first! Minimize any potential lengthy outage to Prod by transition testing with Dev first.
While dropping encrypted packets in a VPN tunnel is unlikely, you may want to prepare for validation testing and check that there are no dropped records when updating PAoC via SCA. Generally speaking, VPN tunnels just encrypt incoming and decrypt outgoing IP packets and are not really concerned with what is being transferred—a packet could be data, could be a movie.
Clean up any old or unused Secure Gateway Connections or data sources so that the import to Satellite connections mechanism can readily transfer the items to the new Satellite when it becomes available. Remember, deleting a datasource from an SG connection does not delete the underlying ODBC System DSN for the server on which PA for PAoC is running. IBM Support can delete those unused System DSNs.
By all indications transitioning from SG to SC is reversable if there is an issue with SC or SCA, but only until October 26, 2024.
Planning for these changes is critical. Between the Secure Gateway deprecation and the deprecation of the PA Cloud Rich Tier, there are quite a few items to sort out. Planning Analytics is one of our long-time specialties, especially PA on Cloud, and we can help you through these changes this summer.
Notes:
With Satellite, there may be an option to integrate with other IBM logging tools when you connect your Satellite Connector Agent location to IBM Cloud Activity Tracker, LogDNA, and Sysdig.