- Resource Pooling
- Resource Reservation
- Hypervisor Clustering
- Redundant Storage
- Dynamic Failure Detection and Recovery
- Multipath Resource Access
- Redundant Physical Connection for Virtual Servers
- Synchronized Operating State
- Zero Downtime
- Storage Maintenance Window
- Virtual Server Auto Crash Recovery
- Non-Disruptive Service Relocation
This chapter is from the book
This chapter is from the book
This chapter is from the book
Synchronized Operating State
How can the availability and reliability of virtual servers be ensured when high availability and clustering technology is unavailable?
Problem |
A cloud consumer may be prevented from utilizing high availability and clustering technology for its virtual servers or operating systems, thereby making them more vulnerable to failure. |
Solution |
A composite failover system is created to not rely on clustering or high availability features but instead use heartbeat messages to synchronize virtual servers. |
Application |
The heartbeat messages are processed by a specialized service agent and are exchanged between hypervisors, the hypervisor and virtual server, and the hypervisor and VIM. |
Mechanisms |
Cloud Storage Device, Failover System, Hypervisor, Resource Replication, State Management Database, Virtual Server |
Problem
Technical restrictions, licensing restrictions, or other reasons may prevent a cloud consumer from taking advantage of clustering and high availability technology and products. This can seriously jeopardize the availability and scalability of its cloud services and applications.
Solution
A system comprised of a set of mechanisms and relying on the use of heartbeat messages is established to emulate select features of clustering and high availability IT resources (Figure 4.27).
)
Figure 4.27 Special heartbeat agents are employed to monitor heartbeat messages exchanged between the servers.
Application
Heartbeat messages are processed by a heartbeat monitor agent and are exchanged between:
- hypervisors
- each hypervisor and each virtual server
- each hypervisor and the central VIM
If an operating system is placed on a physical server, it needs to be converted into a virtual server prior to the issuance of heartbeat messages.
The following steps are shown in Figure 4.28:
- A virtual server is created from the physical server.
- The hypervisor proceeds to host the virtual server.
- The primary virtual server is equipped with fault tolerance and maintains a synchronized state via the use of heartbeat messages.
The secondary server that shares the synchronized state is available in case the primary virtual server fails.
Figure 4.28 The cloud architecture resulting from the application of this pattern.
)
The application/service monitoring station monitors the servers and cloud services. In the event of failure, this station attempts recovery based on sequential pre-defined policies. If the primary server’s operating system fails, procedures are in place to avoid downtime (Figure 4.29).
)
Figure 4.29 When the primary virtual server fails, along with its hosted cloud service, heartbeat messages are no longer transmitted. As a result, the hypervisor recognizes the failure and switches activity to the secondary virtual server that maintains the synchronized state. After the primary virtual server is back online, the hypervisor creates a new secondary for the new primary, and proceeds to save it as a synchronized non-active state.
Mechanisms
- Cloud Storage Device – Cloud storage devices may be used to host the primary and secondary (shadow) copies of virtual server data and cloud service instances.
- Failover System – The failover system is responsible for providing failsafe logic in support of switch cloud consumer requests from a primary virtual server to a secondary virtual server.
- Hypervisor – The hypervisor hosts the primary and secondary (shadow) state data, in addition to providing the features that resource replication needs to replicate the primary state.
- Resource Replication – Resource replication performs the replication of the primary virtual server state to a secondary (shadow) copy.
- State Management Database – The state management database actively stores and restores secondary operating state data in support of primary virtual server failure and recovery.
- Virtual Server – Virtual servers are the primary mechanism to which this pattern is applied.