3 ms·
Keep in mind that although availability sets can help reduce the chances that two VMs will go down at once, you do have to deal with the maintenance cycles that
by znep 12y ago
Keep in mind that although availability sets can help reduce the chances that two VMs will go down at once, you do have to deal with the maintenance cycles that Azure has where they will reboot every one of your VMs over the course of x hours.
This means that with a master/slave setup, a simple failover from a master to a slave is not sufficient, you need to be able to fail back automatically as well. Depending on the exact technologies you are using and how you are using them, this can have a lot of tricky corner cases that can end up much worse.
If you don't do this, then when your master comes back up and they decide to reboot your slave next, which is a common scenario, you lose availability. This differs significantly from a scenario where VM failures/reboots aren't correlated so closely in time; if a VM failure is more random, it is more reasonable to require manual intervention to fail back to the master.
- dbarlett 12y agoSeconded. You're lucky to get clean ACPI shutdowns, half the time Azure "pulls the plug". The closest thing to an official explanation I've found (note date and chorus of comments): http://blogs.msdn.com/b/wats/archive/2013/09/24/windows-azure-virtual-machine-restarted-or-shutdown-with-out-any-notification.aspx http://blogs.msdn.com/b/wats/archive/2013/09/24/windows-azur...
- cpard 12y agotrue, that's why we went for a master-master setup with the db.
- ultimape 12y agoWould a Quorum ( http://en.wikipedia.org/wiki/Quorum_(distributed_computing) http://en.wikipedia.org/wiki/Quorum_(distributed_computing) ) method - like done with Ceph's monitoring system agents - be able to handle this? I mean, you still may end up with the split-brain problem in the long run, but if that happens within a data-center would be the least of your worries. (Something like netflix's chaos army comes to mind for dealing with that).