In network operations, balancing server loads is an ongoing concern with varying solutions employed. The industry overall has attempted to address global server load balancing (GSLB) issues and typically includes one or more of the following solutions:
Active-Standby
This solution is a more traditional disaster recovery approach where deployment uses two data centers; one is active and a second remains idle operating in standby mode. When the active faults, the second becomes the active data center.
Active-Active
This deployment alternative is typically more cost-effective and more resilient to interruptions. This solution usually has at least two data centers that are actively serving data so that if one center is disrupted, the other data center continues processing on behalf of the other, perhaps with degraded service.
Proximity
This solution is a variation of the active-active GSLB deployment which is configured to route the client to the “closest” data center to achieve better exploiter experience and to save or avoid over-usage of expensive wide-area bandwidth. This deployment alternative is attractive for applications that involve the transfer of large volumes of data, require a global presence or relies on real-time interaction with remote users.
In a network system, it is difficult to load balance millions of query activities over a number of servers in an open cluster environment when queries may vary from very simple to resolve to being complex and rather timely to resolve, for example, queries to a lightweight directory access protocol (LDAP) server or to web application servers. For example, using a light weight directory protocol (LDAP) scenario as an example, since no two exploiters requests typically consume equal amounts of LDAP resources, determining optimal load balancing for these varying requests at a server level becomes an issue. Too many longer running queries hitting one LDAP server or site may impact the whole site throughput and, in turn, negatively impact other exploiting applications also directed to that site. Therefore, if queries can be intelligently directed to an LDAP site known to be able to process a request based on current performance criteria then response times may be optimized while minimizing the probability of overloading a particular LDAP site.
Further, once a request arrives at a site, then selecting a server from among multiple servers at the LDAP site may also be relevant for optimizing overall throughput to the site and for a client's continual overall experience. Currently, there is no capability to sense when a server, for example, an LDAP server or web application server, is heavily burdened either absolutely or in relation to other servers. This may lead to further overloading of the overburdened server, which creates inefficiencies within the system. Thus, temporary or even permanent reallocation of new queries to other servers in a cluster or shifting of server assignments is a desirable capability to improve overall query throughput and lessening of bottlenecks in network operations.