|
Load Balancing
The Weblicon PIM system architecture implements a highly scalable and robust load-balancing mechanisms at all tiers of the architecture using a combination of hardware- and software load-balancing.
HTTP Server
Load-balancing at the HTTP server tier can be implemented using a hardware load-balancer which distributes incoming HTTP requests to a cluster of identical HTTP servers. Alternatively, a round-robin DNS load-balancing can be implemented to distribute requests to the HTTP server tier. However, a hardware load-balancer provides additional robustness and flexibility in the load-balancing mechanism and should be preferred for mission-critical installations.
WebObjects Application Server
The WebObjects application server architecture provides a highly scalable and robust software load-balancing mechanism dispatching incoming requests to a cluster of application servers. Load-balancing at the application server tier is implemented in software between the HTTP server and application server using the WebObjects HTTP adaptor and the wotaskd agent.
WebObjects HTTP Adaptor
The WebObjects HTTP Adaptor is a Web Server plug in available as a native API plug-in for leading HTTP servers such as Apache, iPlanet Web Server and Microsoft IIS. It handles all incoming HTTP requests directed to the application tier and maintains a list of application servers and application instances available on these servers.
The WebObjects HTTP Adaptor implements a software load-balancing algorithm for dispatching incoming requests to the application layer. When receiving the first request, the adaptor routes the incoming request to an arbitrary application instance based on the active load-balancing algorithm. The WebObjects HTTP adaptor supports random, load-based or round-robin load balancing. Load balancing takes place when receiving the first request, subsequent requests will be dispatched to the same application instance.
wotaskd Agent
The “wotaskd” agent running on each application server reports the list of available application instances to the WebObjects HTTP adaptor. It is responsible for launching application instances and reports application failures to the adaptors.
HTTP Server Partitioning
When deploying large-scale installations, using HTTP server partitioning can ensure optimal resource usage and guaranteed bandwidth for a particular application. Instead of running a large cluster of identical HTTP servers, multiple clusters of HTTP servers are built each serving a specific application (e.g. SyncML or WebDAV server). The incoming traffic is split at the hardware load-balancer level redirecting traffic to the appropriate HTTP server cluster based on URL inspection.
Application Server Partitioning
For large-scale installations, application server partitioning should be used in combination with HTTP server partitioning. Instead of running identical application server configurations including all applications on a large uniform cluster, multiple clusters of application servers are built, each serving a specific application (e.g. HTML or SyncML server).
J2EE Application Servers
The Weblicon PIM applications are built using the WebObjects application framework, which can be deployed on either the WebObjects application server or on virtually any J2EE compliant application server, such as BEA WebLogic. When deploying on these application servers, the load-balancing mechanisms of the J2EE application server is used instead of the WebObjects HTTP adaptor mechanism described above.
Application Instances
The Weblicon PIM application instances support multithreading by spawning a thread for every session initiated by the WebObjects HTTP adaptor. By handling every session in a separate thread, load-balancing for concurrent user sessions on a single server is handled by the operating system. Support for symmetric multi-processing and additional robustness of the application can be achieved by running multiple instances of the same application on a single application server.
Session Handling
When receiving the first request, the application instance creates a new session and handles the request. It assigns a unique session ID, which is sent back to the client along with the application ID of the application instance. The session ID / application ID pair can be stored in the URL or a cookie. The WebObjects HTTP adaptors maintain a global application ID / Host IP:Port mapping table. When receiving subsequent requests, the WebObjects HTTP adaptors identify the associated application ID and route the request to the appropriate application instance handling the session. This session handling mechanism ensures that subsequent requests will be handled by the same application instance.
RDBMS
Load-balancing and scalability at the database tier can be implemented by using clustering mechanism of leading database systems such as
Oracle 9i.
Oracle Real Application Clusters (RAC) delivers flexible and effortless scalability by providing a single virtual high performance cluster server. Adding nodes to the database is easy and manual intervention is not required to partition data when processor nodes are added. Oracle automatically balances the user load among the multiple nodes in the cluster. While each node has a different physical IP address, application clients connect at a logical database service name level. The clients are therefore not concerned with issues such as multiple addresses for the multiple server machines.
Using the Oracle Cache Fusion architecture of the Oracle 9i database system provides the benefits of both shared disk and shared nothing databases without the drawbacks of either architecture. It does so by exploiting rapidly emerging disk storage and interconnect technologies. The Cache Fusion architecture is an evolution of the Oracle Parallel Server architecture and utilizes a shared cache for performing cache coherency. This eliminates the need for disk IO for internode synchronization.
LDAP
Separating the LDAP directory into LDAP master- and slave- servers and using multiplexer technology for scaling the master server cluster provides a high level of scalability at the LDAP directory server tier. The Weblicon PIM supports different read- and write-servers for connecting to LDAP directories directly supporting the master/slave architecture of large-scale LDAP directories.
Professional LDAP Directory Servers, e.g. from iPlanet or Critical Path provide virtually unlimited horizontal and vertical scalability to support millions of users without performance degradation. By using a Multiple Database Architecture, directory data can be partitioned among multiple servers. Using multiplexer technology, clients have transparent access to directory data distributed across multiple databases. This makes it possible to maintain a logical view of the directory tree on a single directory server while storing directory data on databases managed by other directory servers.
  |
|
|
