3 ms·

Question from someone who doesn't know anything about architecting services that require fault-tolerance: are those hours or days-long delays tolerable in trans

• bayindirh 3y ago
  The reason these migrations take hours/days is because of you're not stopping the server in the first place. Your clients do not see or feel it, because the performance does not degrade. When the machines sync, the IP is transparently transferred to the new instance, and it continues as is while the now "old" machine is deleted. Also, we do these migrations not because of HA failovers. If we need that kind of resilience, we'd either setup an active/standby or active/active HA VMs in the first place. Instead we do this because machine maintenance and/or upgrades. A RAM stick dies, but the server tolerates it, so we leisurely drain the server for maintenance, or we replace the nodes with more powerful ones, so we decommission it by draining, take it out of the cluster, add the new one and remigrate stuff back in. Also, most of the VMs we migrate doesn't know or have the capability of multi-instance execution. They are designed to work as solo machines. This is another reason we prefer to migrate them. Lastly that's a multi-tenant system. We're not the admins of many of the systems sitting on that particular cluster, yet we proudly hit >99.98% uptime every month. TL;DR: Migration is a different modus operandi and is not for scaling or active HA 99.9% of the time. We move these machines around to service the hardware running these, and nobody notices anything.
• deleted 3y ago
  [deleted]