Moving Gaia portal IP to a new interface

[abihsot__]

Hi,

clusterxl, two nodes, R80.20.

I want to move gaia portal IP to a new physical interface.

My idea was to use temporary another IP of different interface as gaia portal while manipulating interfaces.

I though it should work, but gaia portal doesn't load although it seems to listen on any IP:

tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN

In smartconsole in cluster object there is a section "platform portal", however it has only one setting - main url. So I can't modify it per node separately, right?

[Maarten_Sjouw]

When you change IP addresses on a cluster node, you also need to change the interface name in the cluster configuration in SmartConsole. Let's assume you moved the IP from interface eth1 to eth3

Double click the cluster object, go to the tab Network Management, find the interface with the IP you assigned for the Gaia portal.

With interface names you change the name from eth1 to eth3 and push policy.

 

[abihsot__]

Hi,

but before modifying cluster object with new interface name eth1 to eth3, in Gaia portal the IP should have been transferred already to eth3, right? Are you saying once modified in cluster object it will transfer IP in Gaia automatically? That would be awesome because so far I did like this: go to gaia, move IP to the new interface, modify cluster object with new interface and push the policy.

I am stuck only on interface which has Gaia portal on it, and I cannot modify it because it complains "you are going to modify interface which you are connected to".

[Maarten_Sjouw · Accepted solution]

Ok, so you need the full step by step guide...

• ssh to member 1 of the cluster
• ssh from member 1 to member 2 on the sync network (if not allowed by policy set it to be allowed)
• on member 2 issue the following commands from clish (the hostname> prompt)
  • to remove the ip form the old interface:
    • delete intyerface eth1 ipv4-address 
  • Top add IP 1.2.3.4/25 to the eth3 interface:
    • set interface eth3 ipv4-address 1.2.3.4 mask-length 25
  • update SmartConsole for member 2
  • push policy
• ssh into member 2 on the 1.2.3.4 IP
• ssh from member 2 to member 1 on the sync network
• on member 12 issue the following commands from clish (the hostname> prompt)
  • to remove the ip form the old interface:
    • delete intyerface eth1 ipv4-address 
  • Top add IP 1.2.3.5/25 to the eth3 interface:
    • set interface eth3 ipv4-address 1.2.3.5 mask-length 25
  • update SmartConsole for member 1
  • push policy

You have now completed the change of the interfaces .

[abihsot__]

Now I got it! Totally forgot about ssh between the cluster nodes using other interfaces. Thanks!

[abihsot__]

Hi there,

I ran into another issue while using this procedure.

The procedure works fine if the interface is not part of "required interfaces" here:

#cphaprob -a if

CCP mode: Automatic
Required interfaces: 8
Required secured interfaces: 1

eth5 UP non sync(non secured), unicast
eth3 UP non sync(non secured), unicast
eth4 UP non sync(non secured), unicast
Sync UP sync(secured), unicast
Mgmt Non-Monitored non sync(non secured)
bond1 UP non sync(non secured), unicast, bond Load Sharing (bond1.1)
bond1 UP non sync(non secured), unicast, bond Load Sharing (bond1.2)
bond2 UP non sync(non secured), unicast, bond Load Sharing (bond2.3)
bond2 UP non sync(non secured), unicast, bond Load Sharing (bond2.4)

Once I try to migrate IP from bond1.1 to bond2.1 on standby node, the interface dissapears from this table and "required interfaces" becomes 7, and cluster do not want to failover because of lower number of interfaces available. Meanwhile new interface appears with correct bond in "Virtual cluster interfaces" table below. 

I found in checkpoint documentation that interfaces for this table are selected by the gateway atomatically and I cannot intervene here. It all went well with interfaces which were not in this table and now I am stuck here. Only two vlans left and I can't move them.

Any ideas hot to proceed?

[Maarten_Sjouw]

You can still flip over by running cphastop on the active member.

[abihsot__]

But that would be disruptive to sync'ed connections? I want to have as minimal impact as possible.

[Maarten_Sjouw]

the sync is still working and with the cphastop you will just disable the primary member so the other one can take over and should not be disruptive.
It would be better though to do it at the end of the business day to prevent disruptions as much as possible.

[abihsot__]

Oh, I forgot to mention that while modifying interfaces on standby node I put it in down state to avoid cluster flapping by using "clusterXL_admin down" command. Once finished with modifying interfaces and I want to do clusterXL_admin up, it won't jointhe cluster as number of required interfaces is not equal. My guess is that at such condition connections won't be synchronized.

[Maarten_Sjouw]

Then I'm afraid you will have to make the move when you have a window to do so.

[abihsot__]

I just need a way to temporary remove bond1.x interfaces from that list. Somehow two vlans bond2.x (migrated ones) appeared in there...

[abihsot__]

ok, so migration is completed. In the end I was able to manipulate which interfaces were monitored in ClusterXL by using sk92826, which helped to remove interfaces from "required list"