Pillar Axiom Replication Engine (MaxRep)
 

PLA-Support>Sun Systems>DISK>Flash Storage>SN-EStor: FSx
 

In this Document

Goal

Solution

References

Created from <SR 3-12861599441>

Applies to:

Goal

A customer may have the need to relocate their FS1-2 and MaxRep to another subnet. This can be done manually by editing the various network configuration files as documented in other procedures. If the new IP addresses to be used are known before the relocation, the support UI can be used to make the changes to the new subnet before powering down the MaxRep engine. The following are the steps to make the changes to the IP addresses using the UI.

Solution

Synchronous Configuration Only

Prerequisites before relocation:

• DNS entry for FS1-2 and MaxRep IPs configured at the new network
• Zone FS1-2 FC ports to MaxRep engine ports configured at the new SAN

Steps to change IP before power down:

1. Take backup .amc file on the MaxRep engine (under the MaxRep Admin GUI, go to Settings -> Replication Engine Settings and use the Backup button)
2. Pause Protection Plans
3. Stop Replication Services (under the MaxRep Support GUI, go to Management Tasks -> Shutdown/Restart Services)
4. Change FS1-2 IPs: NTP, DNS, Pilot1, Pilot2, Management IP (Network connection will drop)
5. Power down FS1-2
6. Change the engine IPs: DNS, timezone, NTP, IP (wait 5 minutes before power off)
7. Shutdown engine
8. Relocate FS1-2 and MaxRep hardware to new subnet

Power up:

1. Power up FS1-2 (wait for FS1-2 to come fully ready before powering up MaxRep engine)
2. Power up MaxRep engine
3. On the MaxRep engine modify FS1-2 registration to the new IP
4. Start Replication Services if they remain stopped.
5. Resync the Protection Plans

For Asynchronous Configurations it is more complex due to an issue that has been escalated to MS for a fix

Issue:

1. Configure networking task of Control Service internally creates child tasks (one child task per secondary engine) to update the Control Service IP on all configuration files of secondary engine.
2. Once the all child tasks are completed then only parent task (Control Service change networking task) will progress.
3. Child task of secondary engine will change the control Service IP on all of its configuration files and updates the task status to Control Service (contains old IP)
4. Step #3 is failing here as secondary engine is trying to connect to control service with new IP instead of old IP. Hence the parent task is in pending state.

Workaround provided on customer setup:

1. Manually changed the PS_CS_IP in “/home/svsystems/etc/amethyst.conf” to old IP after child task completion on secondary engine so that the engine will use old IP to update its task status to the Control Service.
2. Once the task status update is done on Control Service, change the PS_CS_IP back to the new IP.

References

This solution has no attachment