This section contains two examples of availability strategies based on the identity-based communications solution for a medium-sized enterprise of about 1,000 to 5,000 employees, as described previously in Identity-Based Communications Example. The first availability strategy illustrates load balancing for Messaging Server. The second illustrates a failover solution that uses Sun Cluster software.
The following table lists the estimates for CPU power for each logical Messaging Server component in the logical architecture. This table repeats the final estimation calculated in the section Update the CPU Estimates .
Table 5–6 CPU Estimate Adjustments for Supporting Components
Component |
CPUs |
Memory |
---|---|---|
Messaging Server(MTA, inbound) |
2 |
4 GB |
Messaging Server(MTA, outbound) |
2 |
4 GB |
Messaging Server(MMP) |
2 |
4 GB |
Messaging Server(Message Store) |
2 |
4 GB |
For this example, assume that during technical requirements phase, the following quality of service requirements were specified:
Availability. Overall system availability should be 99.99% (does not include scheduled downtime). Failure of an individual computer system should not result in service failure.
Scalability. No server should be more than 80% utilized under daily peak load and the system must accommodate long-term growth of 10% per year.
To fulfill the availability requirement, for each Messaging Server component provide two instances, one of each on separate hardware servers. If a server for one component fails, the other provides the service. The following figure illustrates the network diagram for this availability strategy.
In the preceding figure the number of CPUs has doubled from the original estimate. The CPUs are doubled for the following reasons:
In the event one server fails, the remaining server provides the CPU power to handle the load.
For the scalability requirement that no single server is more than 80% utilized under peak load, the added CPU power provides this safety margin.
For the scalability requirement to accommodate 10% increased load per year, the added CPU power adds latent capacity that can handle increasing loads until additional scaling would be needed.
The following figure shows an example of failover strategy for Calendar Server back-end and Messaging Server messaging store. The Calendar Server back-end and messaging store are replicated on separate hardware servers and configured for failover with Sun Cluster software. The number of CPUs and corresponding memory are replicated on each server in the Sun Cluster.
Directory services can be replicated to distribute transactions across different servers, providing high availability. Directory Server provides various strategies for replication of services, including the following:
Multiple databases. Stores different portions of a directory tree in separate databases.
Chaining and referrals. Links distributed data into a single directory tree.
Single master replication. Provides a central source for the master database, which is then distributed to consumer replicas.
Multi-master replication. Distributes the master database among several servers. Each of these masters then distributes their database among consumer replicas.
Availability strategies for Directory Server is a complex topic that is beyond the scope of this guide. The following sections, Single Master Replication and Multi-Master Replication provide a high-level view of basic replication strategies. For detailed information see Chapter 12, Designing a Highly Available Deployment, in Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide.
The following figure shows a single master replication strategy that illustrates basic replication concepts.
In single master replication, one instance of Directory Server manages the master directory database, logging all changes. The master database is replicated to any number of consumer databases. The consumer instances of Directory Server are optimized for read and search operations. Any write operation received by a consumer is referred back to the master. The master periodically updates the consumer databases.
Advantages of single master replication include:
Single instance of Directory Server optimized for database read and write operations
Any number of consumer instances of Directory Server optimized for read and search operations
Horizontal scalability for consumer instances of Directory Server
The following figure shows a multi-master replication strategy that might be used to distribute directory access globally.
In multi-master replication, one or more instances of Directory Server manages the master directory database. Each master has a replication agreement that specifies procedures for synchronizing the master databases. Each master replicates to any number of consumer databases. As with single master replication, the consumer instances of Directory Server are optimized for read and search access. Any write operation received by a consumer is referred back to the master. The master periodically updates the consumer databases.
Multi-master replication strategy provides all the advantages of single master replication, plus an availability strategy that can provide load balancing for updates to the masters. You can also implement an availability strategy that provides local control of directory operations, which is an important consideration for enterprises with globally distributed data centers.