Hi Dojo,
Planning the steps towards 10.6 and I understand that 10.5 CU11 (or higher) is almost mandatory to properly manage the dependencies on the newer BrokerGateway
(especially if coming from an earlier release like 10.5 CU4).
I'm thinking of 3 stages:
10.5 CU4 [Current stage] --> 10.5 CU12 or CU15 [Intermediate stage] --> 10.6 [Final Stage]
I'm wondering:
are there any specific tests that can be recommended to expedite the upgrade from the intermediate stage towards 10.6?
If a long soak phase is not strictly required to assess stability of the newer BrokerGateway configuration,
I'd possibly try to upgrade to the latest CU of 10.15 and then go directly to 10.6 as part of the same maintenance day - at least in staging, to assess timelines and technical viability. The goal is to minimize the days of calendar for which DM downtime has to be planned for the upgrade to 10.6
Any input will be helpful - thanks
Hi Alberto,
Your plan seems solid. Although it's technically possible to migrate in CU4, We indeed recommend you first go to 10.5.0 [CU11] or higher before migrating to the new BrokerGateway-Managed NATS to ensure you have all the bugfixes related to BrokerGateway
The migration tool itself will fail if not all the expected NATS nodes (as specified in C:\Skyline DataMiner\Configurations\ClusterEndpoints.json) can reach each other. The migration will then automatically roll back to the old NATS config you had prior to migrating. Therefore I'm fairly confident that if the migration tool reports a success, you don't need a big soaking period afterwards.
From DataMiner's perspective not much has changed. It's still using "a NATS endpoint" like before, only the endpoint itself has now changed and will be managed differently than before. If there would be an issue somewhere, you would see it very quickly in the alarm console in Cube, as DataMiner would start generating error alarms because it can't communicate across its different modules anymore.
Actions that will be affected by this new NATS are generally DataMiner clustering actions: adding/removing agents should add/remove new NATS endpoints. If NATS was configured to have a manual config however, the new NATS config will still be manual, and changing your DataMiner cluster will now be blocked until you manually update your NATS config first.
Hope this gives some insight.
If a supercluster/leafnode setup was configured in the old NATS config, then I assume this config was configured as a "manual config"?
Manual configs can also be migrated using the same procedure but under the hood a different path will be followed.
Rather than looking at ClusterEndpoints.json to learn all the endpoints and build a config from that, the migrating tool will migrate the config based on the existing custom config if it detects a manual config was present.
This means that the resulting NATS cluster will still need to be manually maintained as well, as BrokerGateway will not make any changes to the NATS cluster based on cluster changes done in DataMiner. The nice thing is that once you have a BrokerGateway managed NATS cluster, you can edit your manually configured supercluster setup via API calls to BGW rather than having to edit the config files on each machine if you want to change the setup.
Thanks for all the info, provided, Alexander.
We'll review with our squad and plan steps accordingly for our systems.
Marking as solved.
Thanks for this helpful insight, Alexander – much appreciated
When it comes to the new NATS config, are there any different steps triggered in presence of "NATS supercluster & leaf nodes" topology?