Redundancy design of cluster system |
Compared to the cluster service systems for the last generation SuperMap servers, clusters in SuperMap iServer not only keeps the redundancy design for GIS applications, but also add the redundancy design for cluster services. SuperMap iServer supports configuring backups of cluster services, providing higher reliability and more flexible deployment.
Figure 2 The fault-tolerance mechanism of clusters - The redundancy design of cluster servers and GIS servers
The redundancy design of GIS applications is to configure two or more GIS applications in a cluster system. These GIS applications provide GIS services with the same functionalities in GIS map data processing and GIS functions. Specifically which GIS service is responsible for handling a request from the client can be dynamically specified using the load balancing capacity of the cluster service.
First of all, the redundancy design can prevent single point failures of a GIS application, thus ensuring the reliability and the capacity to continuously operate of the GIS application. For example, four GIS applications are configured into the cluster system in figure 2. The cluster service is responsible for monitoring the status of the GIS services in a GIS application. A GIS application, on the other hand, is responsible for reporting its own status to the cluster service on regular basis. When a GIS application (e.g., GIS application 2) fails or cannot process GIS requests due to other reasons, the cluster service can be aware of that information from monitoring. The GIS services provided in the problematic GIS application (e.g., GIS application 2) is then removed from the table of load balancing information. When the client submits a GIS request to the cluster service, the cluster service selects other GIS services with the same service functionality based on the load balancing information of the cluster. Then the node information of the GIS application nodes corresponding to the selected GIS services is returned to the client. If the problematic GIS application recovers its functionality, it can be re-configured into the cluster system. The GIS application will automatically report to the cluster service. The load balancing table will be updated in the cluster system accordingly to add the GIS service information of GIS application 2. Then GIS application 2 is ready to continue to provide services to the client.
Secondly, the redundancy design of GIS applications can improve the GIS computing power, making the Service GIS system able to process highly concurrent access with high efficiency. When multiple clients access a cluster system simultaneously, the cluster system can employ multiple GIS applications configured with the same functionality to handle the requests at the same time. For example, the cluster system in figure 2 has four GIS applications with the same configurations (including the configurations of the hardware servers, the GIS data that can be processed, and the GIS functions). If 100 clients concurrently access this cluster system, the cluster service will equally assign the 100 requests to GIS application 1~4, i.e., each GIS application will be responsible for 25 requests. Without cluster, a GIS application would need to handle 100 requests. Therefore, a Service GIS system with highly concurrent access from clients and complicated GIS spatial analyses need a cluster mechanism to improve its efficiency and guarantee its reliability.
Cluster services cannot only ensure the system reliability in cases of unexpected shut down, damaged hardware and software, etc., but also makes it easier to perform scheduled tasks such as maintaining, upgrading, and testing, through controlling the operating status of some servers. With the help of cluster services, the application services can function without any interruption.
The redundancy design of cluster services has the same principles as that for GIS applications. It can prevent single point failures caused by cluster services. If there was only one cluster service, and it failed to function, the entire cluster would not be able to provide services, causing a single point of failure. To prevent this from happening, SuperMap iServer supports configuring backups of cluster services, acting as a fault-tolerance mechanism for the cluster services. As shown in figure 2, the cluster system has two cluster services providing GIS services at the same time. If the cluster service a1 fails, the client will identify the error in the cluster service and transfer the GIS request directly to cluster service a2 for implementation.