Best practise: Upgrade gateway cluster without downtime

[Dennis Melis]

Hello everyone,

I am wondering how to upgrade my gateway cluster nodes without downtime for the customer. We have 10.0 appliance gateways.

We have configured the gateway nodes as displayed in the image. These settings were recommended by our integrator. Node A is primary, Node B is secondary. During normal upgrades or security patches, it's perfectly possible to route the loadbalancer to a single node, patch the other, reboot and switch to the other node. Production is guaranteed. However, when you have a minor or major release (for example 10.0 to 10.1) you have a database upgrade. In that event, i see no possible way to upgrade a single node first, and process the traffic by the other node without downtime. Even when you disconnect the databases from one other, you'll have to re-establish replication at one point. Re-initializing replication requires that both nodes are down.

Is there any way to guarantee uptime during a major/minor upgrade of the gateway?

Thanks very much in advance,

Dennis Melis
Layer7 administrator
Municipality of 's-Hertogenbosch
Netherlands

[Daniel Galvez]

Hi Dennis,

There are several ways to do it; for me the simplest is:
- Deploy the new nodes with 10.1 image, consider increase disk partitions size.
- Restore db backup, upgrade the db.
- Configure the replication between them.
- Test everything, apply the CR1 and the OS Platform Update; Keep in mind any MySQL limitation if you have API Portal.
- Publish the new nodes behind the F5 and shutdown the "old" nodes

Regards,
Daniel

[Dennis Melis]

Thank you very much Daniel,
This procedure takes a bit of time, but it's indeed a way to guarantee uptime.

Regards,
Dennis

[Sebastian van Voorn]

Hello Dennis,
I suppose the db is a MASTER-MASTER myusql replication cluster?
A more simple and faster way is to split the cluster:
First you have to configure the LB to just use NODE B for traffic
then upgrade NODE A without DB upgrade!
stop the slaves on both nodes
disconnect NODE A with iptables -I INPUT -s "NODE B" -j REJECT
upgrade the DB on NODE A
check if ssg starts well on NODE A
configure the LB to just use NODE A for traffic
Upgrade Node B
allow connect on NODE A with iptables -D INPUT -s "NODE B" -j REJECT
check if ssg starts well on NODE B
check if DB replication is restarted on NODE B or rebuild.
restart replication on NODE A

This worked on API Gateway 9.x upgrades.

We check if this also works for 10.0 - 10.1 upgrades (don't know why it shoudn't)

Sebastian.

------------------------------
Greetings,
Sebastian van Voorn.
[JobTitle]
[CompanyName]
------------------------------