MAESTRO SGM change

[AkosBakos]

Hi Team,

I need your advice:

I have a dual-site MAESTRO (2pcs MHP140, 4 pcs CP6500). The CP6500 are end-of-life soon.

The new SGMs are CP9300. I know the mix-and-match does not work between this types. 

What would be the most effective process of the change from the downtime point of view?

Have somebody done such kind of changes already? If yes, what was the experience? Please share with me.

I have two scenario:

• I delete, then rebuild the Security Group -> this is the last what would I do
• I put the CP9300 next to the two CP6500 -> if the config arrives to the CP9300, I remove the two 6500, then

I don't want to do it without outage, because it is impossible, but I want to cause as short outage as is can.

Every answer would be very appreciated!

Akos

[emmap]

As long as everything is on the same version (so R81.20) the configuration will sync between your SGMs. You can't use auto-clone though as they are not the same hardware. So, add the new ones, let them sync config, remove the old ones, install JHF take on the new ones, check CXL config and reset if you need to (enable dynamic balancing, basically). 

[AkosBakos]

Hi @emmap ,

thanks for the valuable info.

We did the same steps but the results sere different.

If we created a new security group and did the steps that you mentioned -> the result was the new SGM came up to active and everything was fine.

but an upgraded SG (which was r81.10 before) the new SGM remained in detached state, the version was r81.20 as in the first step.

Did you expreienced this kind of behaviour?

And one more question:

if I put an SGM next to 2 SGMs its “number” will be 1_3. The member id remains this if remive the two old sgms?

akos

[emmap]

Not sure I properly follow. The existing MHOs and SGMs must be running R81.20 before you can add the 9300s in, as they are also running R81.20 (though you may have to re-image them to the Maestro R81.20 image if they are not already running that). 

Yes when adding a new SGM, it will take the lowest available ID. So if you have 2 SGMs in the group and you add another one, it'll be 1_3. If you remove SGM 1_2 from the group, you'll have a group with 1_1 and 1_3 in it. If you then add another SGM it'll take the 1_2 ID. 

[AkosBakos]

Hi @emmap 

A short summary of the chnage: 

• removed the 2 old SGMs from site A
• put the new SGM to site A
• Came up in down state (it took ~10 minutes)
• #cphaprob synscat showed policy installation error
  • realized that the original lic expired - we knew that therefore created EVAL earlier-  and the EVAL license has just expired - (that1s the fun fact) 
    • we assume that because of the lack of valid lic (in this situation only InitialPolicy was availabe on the SGM) the SGM couldn't pull from its own lic from the usercenter (the initialPolicy didn't allower the traffic to usercenter)
• We created a new EVAL for the new SGP
• install the lic with cplic put
• rebooted the SGM, then it came up in Active state
• install the necessary jumbo take 
• than manual failover to the ne SGM

The arrange of the other three SGMs into Security Group were easy after this experience.

Cleaunup: we remoed all EVAL licenses from the SGM-s g_cplic del <signature>

Akos

[Lesley]

Is it not better to install the Jumbo before makeing it a cluster? 

If you have a default R81.20 image and mix it with other gateways the version difference is to big. 

Also many issues solved in a jumbo so was maybe worth testing to build it with updated systems.

Of course no license does also not help 😉 

[AkosBakos]

Ok, but if I want to intall a jumbo hotfix onto an SGM, the SGM must be in Security Group.(admin guide)

So how? 😉