Up2date installation on HA killed slave

I read the link:

***
Main/first unit begins process via WebAdmin
Secondary unit notices master's downtime and takes over (failover occurs)
Main unit finishes process and reboots
Main unit comes up, slave (acting as main) recognizes a "better-versioned" unit is in place and hands back Master role.
Secondary unit performs upgrade, reboots, and enters passive state again without any network impact as a result.
***

When we do it, the secondary unit is the first one to be updated. It is not being processed according to the steps above.

Our steps are:

Update process started from WebAdmin
Secondary unit performs upgrade, reboots and dies
Up2date is terminated
Main unit remains with old version and keeps working as master
System is no longer HA

That looks the log during an Up2Date.  If you're convinced that it's not working, then you can disconnect the slave and factory reset it before reconnecting it:

Login as root
Type cc [enter]
RAW [enter]
system_factory_reset [enter] 

Angelo commented recently on how a normal Up2Date proceeds in HA.

Cheers - Bob

This might be a long shot but could there be any problems with the heartbeat interfaces, perhaps a MTU change with the new version of Astaro? I have some memory of a bug that made the master kill the slave if the MTU differed between them. If so, will I be able to find that in a log on the master? We run a crossed patch cable between the FW:s so no switch problems will affect this.

Maybe this way off, but to me it seems like the slave is not coming up at all. I have no access to the servers now.

I try to ping node2 (node2 coming from /etc/hosts file) from the master but no luck. There are some predefined IP addresses in the hosts file and I guess those are the ones I can use when I want to ssh into either the master or the slave. Otherwise an ssh to the FW of course always brings me to the current master, right?

Otherwise an ssh to the FW of course always brings me to the current master, right?

That's why I suggested disconnecting the Ethernet cables.  I know that it's possible to ssh to the Slave while it's online, but I always try to insulate myself from my own mistakes.

When I first read this, I had the same idea.  I had a similar problem; the MTU had gotten out of phase; one unit was at 1500 and the other was at 2000.  From the console, run ifconfig to see the existing MTU, then change it
 
cc
ha
advanced
mtu$
=2000
 
or         =1500 

Cheers - Bob

Ok, I was on the right path with the MTU. When I fixed that the slave came up and became master. The old master updated itself, rebooted and came back in the cluster. After that I got two problems:

1. It hangs while syncing with the following errors:


2011:07:13-10:17:15 rama-1 slon[4192]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:15 rama-1 slon[6058]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:15 rama-1 slon[6058]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:16 rama-1 slon[4193]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:16 rama-1 slon[6065]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:16 rama-1 slon[6065]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:25 rama-1 slon[4192]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:25 rama-1 slon[6067]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:25 rama-1 slon[6067]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:26 rama-1 slon[4193]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:26 rama-1 slon[6069]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:26 rama-1 slon[6069]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:35 rama-1 slon[4192]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:35 rama-1 slon[6072]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:35 rama-1 slon[6072]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:36 rama-1 slon[4193]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:36 rama-1 slon[6074]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:36 rama-1 slon[6074]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:45 rama-1 slon[4192]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:45 rama-1 slon[6077]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:45 rama-1 slon[6077]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:46 rama-1 slon[4193]: [1-1] CONFIG main: slon version 1.2.20 starting up
2011:07:13-10:17:46 rama-1 slon[6079]: [2-1] ERROR  cannot get sl_local_node_id - ERROR:  schema "_asg_cluster" does not exist
2011:07:13-10:17:46 rama-1 slon[6079]: [3-1] FATAL  main: Node is not initialized properly - sleep 10s
2011:07:13-10:17:55 rama-1 slon[4192]: [1-1] CONFIG main: slon version 1.2.20 starting up


2. One of our interfaces stopped working, I checked the switch, the cables and it has to be the firewall

I had no choice but to kill the new master and let the original master become master again


Sorry for being a bit annoyed but Astaro is now the weak link in an otherwise very nice hosting environment with full redundency - well we had full redundancy.

I don't know what to do now.

Upgrade to version 8, install cluster and pray to god that it will work the next time I run UP2DATE
Get my current version working
Switch to another brand?

I understand why the UP2DATE didn't work, clearly it is a bug in Astaro not managing to have the heartbeat interfaces set to MTU = auto

But why on earth did it not manage to sync itself?
And why will suddenly one of the interfaces stop working?

While there are a few cases like this, they don't seem to be widespread.  If you're haveing a consistent problem, I suspect a hardware problem.  Since you have to re-install for V8, you might want to change the "sync" ethernet adapters, choosing ones in more-common use.

This problem happened with my client when we moved them from "Cluster" to "Hot Standby" mode.  To fix it, I disabled HA from the Master, waited for the Slave to do a factory reset and powered it down. I then disconnected all Ethernet cables to the slave, powered it up, up2dated manually, confirmed the MTUs, powered down, reconnected and powered the Slave on.  Since then (about 18 months ago), there have been no issues.

CHeers - Bob

Thanks Bob, I really appreciate your answers!
 

We have it running on 7.511 fully functionally now. I took up the the slave again and the sync worked from master->slave but not vice versa. Also I fixed the network problem, that was probably an issue with NAT that worked when we configured it but stopped working when we restarted the firewalls. 

I still don't know why the sync did not run. And I am a bit unsure also about the network problem.

I am running this on Supermicro hardware with pretty common parts but I guess it still might be the hardware. The good thing about Astaro is that is runs rock solid, but as soon as I want to update it, it becomes a big mess. The up2date part is critical, after all it is a firewall and it needs to be updated.

Our local news contacted us since we had down time for our customers.

Do you have any recommendations how we could establish a more secure and safe up2date process. I dont feel like explaining to the media that our down time is due to a bug in our firewall. 

Should we buy a third firewall and upgrade that one, switch over to that and then run up2date on the HA-environment?
I have to get the FW up to standard that we need, this just wont do.

It's hard to make a recommendation based on limited knowledge.  Your reseller and/or Astaro should have some suggestions.  If your situation is such high-profile that the local news would call you, then maybe Platinum/Premium support is a good idea.

Best of luck! - Bob