DX NetOps

  • 1.  What is the Best Practice for introducing the MLS at the end of an upgrade?

    Posted Apr 20, 2018 12:19 PM

    This week I upgraded to 10.2.2 from 9.4.2.1.  To do this I need to run two DSS environments which requires an MLS for each environment.  So I keep primary MLS (specmom) in the 9.4.2.1 environment and upgrade my secondary MLS (specmomb) in the new 10.2.2 environment.  As I upgrade SS's and OC's to the new environment I remove them from the old environment.  Eventually I'm left with my original primary MLS (specmom) that I upgrade and need to re-introduce to the new as the primary MLS again.  Before I start the SS for the primary MLS I open SCP for each SS in my DSS and update the Host Security to add "specmom" and then I update Location Server to make "specmom" the Main MLS and "specmomb" the Backup MLS.  I then start the SS on specmom and then on my OneClick servers under Administration > Spectrum Configuration I make the same updates which unfortunately requires a restart of the OneClick server.  Then I sit back and hope everything properly communicates with each other after all the updates on each server.  Re-introducing the primary MLS back into the environment is probably the most challenging process of the upgrade.

     

    Which brings me to my subject title.  Am I doing the best practice or is there another documented easier procedure I should reference for future upgrades?



  • 2.  Re: What is the Best Practice for introducing the MLS at the end of an upgrade?

    Broadcom Employee
    Posted Apr 20, 2018 01:06 PM

    Hi John,

     

    It sound like you covered most the bases. One other thing to check is the precedence settings on both MLS servers, specmom and specmomb. The server with the lowest precedence value will take over as the active server, so you will want the primary server to have the lowest value. By default this is 10, but can be any number.

     

    If both servers show precedence 10, then you will want to change the precedence of specmomb to a higher value, such as 20. You can do this by stopping spectrum and reloading a copy of the SSdb from specmom, via command line '../SS-Tools/SSdbload -cm -r 20 <dbsavefilename>' from the $SPECROOT/SS directory.

     

    If specmon is running as a higher precedence than specmomb, you will need to change the precedence on specmom to a lower number than specmomb. For example, if specmomb is running precedence 10 and specmom is precedence 20, you will need to stop Spectrum and reload the SSdb database on specmom, via command line '../SS-Tools/SSdbload -cm -r 5 <dbsavefilename>' from the $SPECROOT/SS directory.

     

    For more information regarding the SSdbload command line see https://docops.ca.com/ca-spectrum/10-2-3/en/administrating/database-management/spectroserver-database-maintenance/ca-spectrum-database-tools/ssdbload

     

    Thank you,

    Brad



  • 3.  Re: What is the Best Practice for introducing the MLS at the end of an upgrade?

    Posted Apr 20, 2018 03:01 PM

    Brad,

     

    Thanks for responding!  I did have a minor gotcha because specmomb did have a precedence of 10 and interfered when I started specmom with the same precedence value.  When I built specmomb in the new environment I should have set the precedence to 20.  I worked it out with a few database loads and setting the proper precedence's values.  Good to know I was on track with the exception of my precedence mistake.



  • 4.  Re: What is the Best Practice for introducing the MLS at the end of an upgrade?
    Best Answer

    Broadcom Employee
    Posted Apr 20, 2018 01:11 PM

    Hi John,

     

    I guess my reply really didn't answer your question regarding the best practice for upgrading a fault tolerant DSS environment. The steps can be found here: https://docops.ca.com/ca-spectrum/10-2-3/en/installing-and-upgrading/upgrading/upgrade-best-practices-fault-tolerant-deployments

     

    Thank you,

    Brad



  • 5.  Re: What is the Best Practice for introducing the MLS at the end of an upgrade?

    Posted Apr 26, 2018 06:01 AM

    Hi John,

    From your original post, I got the impression that you don't have a permanent Fault tolerant environment - i.e. for business as usual your environment just has a single set of SSs?  Whereas the best practice doc Brad mentions is about a fully redundant fault tolerant environment where every primary SS has a secondary peer SS.

    So you  were necessarily having to do something a bit different anyway!

    It might've been possible to modify the .hostrc files on the SSs as you went along, to keep your two environments quite separate and not have to alter precedence values (perhaps).

    Cheers

    Dan.