Geography planning

If you are a transcontinental organization, you need to decide whether to support regional or centralized deployments of the Sametime Community Server.

Many companies divide clusters or users by geography. However, to do this, each geography would have to host a set of connected servers which users would access by means of different URLs. For example, if Acme Company divided its users geographically between the US and Asia Pacific, they would have two URLs, such as us.acme.com and ap.acme.com. This would require client updates on all Sametime clients worldwide to go to the correct server name. It would also mean an increase in hardware cost. When servers are distributed across geographies, network impact is lessened, and you can use the "follow the sun" principle to determine the maximum number of concurrent users you need to provision.

When all servers are in one location, you can take advantage of the different time zones so that many servers are not needed. You can decide to let the different time zones work in your favor. For example, let's say you have 300,000 users. To have servers set up in the Asian Pacific geography, you would have to have enough servers to handle a load of 150,000 simultaneous users, and enough US servers to handle 150,000 simultaneous users. Because the servers are located centrally, you can have enough servers to handle a peak load of 225k users and keep them running around the clock. For this deployment, you would likely need three servers for approximately 225K concurrent users per day.

If all servers are in one location, you can take full advantage of all of the servers around the clock. Some companies allow different time zones work in their favor. Instead of having some servers under a lot of load some of the time because of the different groups worldwide, the user population is split up rather evenly across all of the servers/clusters so that the servers are able to maintain a more consistent state and usage around the clock. Users are sorted onto different servers and/or clusters by means of a the Home Server attribute set in their LDAP person record.

Sametime deployment at IBM®

The Sametime deployment at IBM has all servers in one location. The company's Sametime population is approximately 425,000 users. IBM decided to let the different time zones work in their favor. IBM did not use this method to identify the user's home server because the Sametime server uses a shared LDAP that the Sametime deployment team did not control. Adding and populating a field for all user records within IBM was not feasible. IBM determined that three clusters of three servers each was the optimum number for approximately 225,000 concurrent users per day. See Sametime Deployment at IBM for details.

One community and three vpuserinfo.nsf databases

Typically, most administrators will divide their users among clusters. Having one cluster in IBM would mean that the contacts list database vpuserinfo.nsf would be too big. Every action such as searching, loading, and so on took too long. IBM came up with the idea to divide the user information into three files, one for each cluster. Each cluster would have its own vpuserinfo.nsf. All the servers within a cluster share information about users such as contacts lists, privacy lists, and alerts. All of that user information is contained within a single database called vpuserinfo.nsf. By using three clusters, we were able to breakdown the size of a single vpuserinfo.nsf file to a third of its original size. To break down the vpuserinfo.nsf file, Sametime development created a tool that took the single vpuserinfo.nsf and broke out into the needed number of clusters all of the users information based upon the algorithm that is used for their logins. This allowed us to take an approximately 15 GB vpuserinfo.nsf and break it down into 3 vpuserinfo.nsf files of roughly 5 GB each.

Calculating a user's home server

When a user logs on, the user is directed to a cluster and one of three servers in the cluster. If a user's data is on Cluster 2, then the user must log on to Cluster 2. The user need only log onto one server in the cluster. Through an algorithm that calculates the user's name, Sametime always know which server the user belongs to. Sametime developers came up with a way that allows the home server field to be set at the server layer that determines, by means of an algorithm, the cluster and server that users are sent to as they log in. After the first log in, users are always be sent to the same cluster. This happens by means of a custom class file specified in the Sametime configuration database (stconfig.nsf) LDAP settings. Custom class files within the stconfig.nsf LDAP settings have been used in Sametime for many years. For more information on custom class files, refer to the section entitled "Use Java™ classes to customize LDAP directory searches" in the Sametime product documentation. When a user logs into the cluster, information for that user has already replicated across the servers in the cluster.