Procedure shutdown and bootup secondary Maestro site

[Nikodemus]

Hi all,

We plan to move our secondary datacenter to another location.

We would like to shut down the Maestro environment (single SG, dual mho, dual site, R80.20SP + R80.30SP) properly to avoid any issues/corruptions afterwards.

This is how I would like to tackle the situation:

1. Move active VS’es from site B to site A (VSX VSLS – command: ??? )
2. We set site B down (command: ‘set chassis high-availability id 2 down’)
3. Disconnect the site sync cables
4. Shut down gateways
5. Shut down orchestrators
6. Disconnect all cables

Then, move appliances to new datacenter and ...

1. Connect cables (but not the site sync)
2. Boot up orchestrators
3. Boot up gateways
4. Check health (command: ‘asg monitor -v’)
5. Connect the site sync cables
6. Set site B active (command: ‘set chassis high-availability id 2 up’)
7. Redistribute VS’es between both sites (command: ???)

Does it makes sense? Any improvements? Caveats?

Thanks.

[_Val_]

@Anatoly can you please advise?

[Nikodemus]

I did not expect my question would be that complicated.  🙂

[Nikodemus]

I also opened a TAC case last week... just to be sure. But I'm still waiting for an answer.

Thought it would be easy going, but the question seems to be challenging. 

[Fabio_Catena]

I too will soon need to move a pair of Maestros and a pair of gateways from one datacenter to a new one.

The procedure I followed with Checkpoint is the same as yours, minus a few commands..

Fabio

[Fabio_Catena]

Have you moved to the new datacenter?

[T_Letts]

Not sure on the time line of this post - I've only just received an email to say it's been updated. Apologies if information is too late to be of use.

Hi 

We have moved datacentres within the last 2 months. Ours is just a simple security group (that is, no VSX). We had an issue connecting the site to site sync between the orchestrators following the relocation and consequently the 2 sites couldn't see each other (This turned out to be a transceiver issue and has been rectified). What happened when we powered up the orchestrator and gateways at the new site was the system couldn't verify the state of the partner orchestrator, it assumed it was isolated and became active. Consequently we had a split brain condition and had to power off the gateways at the new site to be able to correct the situation.  We did not use the   'set chassis high-availability id 2 down' command though before the move , so this may mean your experience might be different. Also we have Active/Active network operation at the sites, hence the traffic getting routed to both sites once the relocated gateways were booted up.