High Availability Virtualization Network is a fallacy

Whether it is a virtual machine crash or a host error, the High Availability Virtualization (HA) utility guarantees that the virtual machines that are wrong can be restarted automatically. These HA applications have created unrealistic expectations for http://www.aliyun.com/zixun/aggregation/7155.html > Developers and server Administrators.

The server management team is beginning to believe that they can apply HA tools to a wide variety of enterprise casing programs, but the recent challenges posed by the mobility of virtual machines between data centers are a false belief in the immediate consequences of Ha's magic.

Let's take a look at the legends and realities of HA products:

VMware's High availability: assuming you can accurately detect a virtual machine operating system or an application service error (for example, database software), but you still need to restart the virtual machine. Some of the loss of time is the system's operational performance of a 9 loss (the system's operational performance is generally expressed as a percentage, commonly used is 5 9--99.999%, a 9 loss will make the operational performance to 99.99%).

VMware's fault tolerance: This feature refers to two different copies of the same virtual machine running at the same time on both hosts. This is a perfect solution for short-term problems, such as: I don't want to interrupt my long batch task with hardware problems. The real problem is that if the virtual machine or its own software crashes, two copies of the virtual machine will crash at the same time.

High Availability Clustering: a policy similar to the Windows Server Failover clustering technology (Failover clustering) restarts failed services (for example, SQL Services) on the same or another server, while This reboot can take several seconds to a few minutes, sometimes even longer if the database has to be massively restored. This can also reduce the system's operational performance.

Now let me bring up another point of view: We have recently experienced a forwarding loop caused by a single station STP protocol error. Recovery time takes nearly 30 minutes when the network Management system (NMS) discovers problems in a timely manner and an operator onsite support. Admittedly, some of this time has been spent collecting evidence that facilitates the processing of hindsight.

Next fact: Bridging between data centers can lead to long-distance forwarding loops, or you may see a traffic flood overflow that is caused by a forwarding loop that links other data center WANs and truncates traffic between all other data centers (if you have the guts to use a long cluster, Also truncates the cluster heartbeat line traffic) and the storage response. Are you really willing to put the entire IT infrastructure at risk to support an application that cannot be reached at any rate by 3.5 9? Don't forget, everyone wants server administrators to patch the server, and patching occasionally requires a reboot, right?

The moral of the story: "Magic" products give you a false sense of security; like MySQL database clusters, good application architectures and products that use truly high availability are the only solutions that are right to meet the challenges of high availability.