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.