7 Replies Latest reply on Feb 28, 2018 4:24 AM by Duncan Grisby

    New consolidator and resync

    Andrew Mark Shaw

      Hi All.

       

      We are about to replace one consolidation cluster with another. Our plan is to leverage on resync to have the new cluster take ownership of the existing CMDB dataset. Given the size of the dataset, a complete resync is likely to take at least one week, potentially a lot longer. During this time I assume no new (Discovery) CMDB updates will go across. I imagine that even continued Discovery will negatively impact the resync process.

       

      From previous posts here, it appears an incremental resync would be the right approach. If I understand it correctly, only discovery of local CI’s would trigger resync to update the same (and related) CI's in CMDB – thus a gradual synchronisation of the datasets. If so, this would allow us to update CMDB and continue discovery without the downtime of a lengthy complete resync. I assume it would also reduce CMDB load/impact.

       

      One last point – we plan to kick off a resync once we have a full Discovery dataset on the new consolidation cluster to avoid CMDB CI deletion of yet to be discovered CI’s.

       

      Is this how resync is supposed to be used in our situation? Is there a better approach?

       

      Many thanks

      Andy

        • 1. Re: New consolidator and resync
          Andrew Waters

          How are you getting data into the new consolidator? Are you doing a backup and restore, or using tw_root_node_key_export and tw_root_node_key_import (docs). If you are not doing either then there will be no "taking ownership" as the keys used for node will almost certainly be different.

          2 of 2 people found this helpful
          • 2. Re: New consolidator and resync
            Andrew Mark Shaw

            Hi Andrew,

             

            Yes, should have mentioned that. We are importing the root node keys into the new consolidator prior to any discovery.

            • 3. Re: New consolidator and resync
              Duncan Grisby

              As long as you have done the root node key export / import, the majority of the keys should match up, and so a resync should be successful, in terms of not changing too much data in the CMDB dataset. I'd suggest you choose "prepare only" for the resync, and look at the summary of work it intends to do, to ensure it does not look like it is going to create and delete too many CIs.

               

              Incremental resync will do all the same work as a complete resync, it will just spread the work over the time it takes to scan your environment. It does sound like a good option for you.

              2 of 2 people found this helpful
              • 4. Re: New consolidator and resync
                Andrew Mark Shaw

                Thanks Duncan. I hadn't realised that the root node keys were all that we needed to run a resync - I assumed we needed a full Discovery dataset to avoid CI deletion. That means we can bring the incremental resync forward, which helps a lot.

                 

                Thanks again

                • 5. Re: New consolidator and resync
                  Duncan Grisby

                  No!  I didn't mean that!  You do need to scan the environment after the key import, before you do a resync. Incremental resync means that it then applies the resync changes to the CMDB in subsequent scanning.

                  1 of 1 people found this helpful
                  • 6. Re: New consolidator and resync
                    Andrew Mark Shaw

                    Thanks for clarifying

                     

                    I'm unclear on one final thing - if we have half of our environment scanned into the new consolidation cluster (post key import), and then trigger an incremental resync, will resync delete all CMDB CI's that are not already discovered on the new consolidator? Given past comments - the deletion process runs as a background thread - so I assume the answer is yes, get everything scanned, then incremental resync.

                     

                    EDIT: no need to reply unless I'm wrong Duncan. I think you've clarified. Thanks.

                    • 7. Re: New consolidator and resync
                      Duncan Grisby

                      Yes, you are right. If you have not scanned everything before you do a resync, all the CIs corresponding to things you have not yet discovered will be marked as deleted. In an incremental resync, that does indeed run as a background thread, so the deletions will be spread over some time, but they will still occur. The simple message is to scan everything that is important to you before you do the resync.

                       

                      Alternatively, as Andrew mentioned at the start of the discussion, if you can restore a backup of your old consolidator onto the new one, then you don't need to bother with any of this. The new consolidator will just directly take over the CMDB dataset with no need for a resync at all.

                      1 of 1 people found this helpful