ShowTable of Contents
Introduction
This article provides best-practice deployment guidelines assuming you have obtained formal sizing estimates from
IBM Techline.
Unlike past v8.0 versions, this v8.5 sizing guidelines document is NOT accompanied by a spreadsheet sizing calculator for computing the required number of Gateway server instances.
The v8.0 calculator does not work for v8.5 deployments. Instead, formal software sizing support is available from
IBM Techline. Contact your local IBM sales representative for assistance.
To get the most from this article, calculate the amount of CPU cores, RAM, and Internet bandwidth required to operate the recommended number of server instances, as provided by the IBM Techline sizing service. Also, use Scenarios 1, 2, & 3 (Sections 5, 6, & 7) below as deployment examples.
Defining our terms
CPU. Through this document, we refer to a CPU core as an independent physical CPU core (not hyper threaded), running at a clock speed of ~2--3GHz.
Sametime Gateway instance. This term refers to either a standalone Sametime Gateway server, or to a Sametime Gateway server instance that is part of a Sametime Gateway cluster.
CPU and memory requirements by component
A clustered Sametime Gateway deployment includes more than a single process. Table 1 presents the required RAM and CPU allocations for each type of process.
Table 1. RAM and CPU requirements
|
|
|
|
IBM WebSphere® Deployment Manager
|
|
|
|
|
|
|
Sametime Gateway Server instance
|
|
|
WebSphere SIP Proxy Server instance
|
|
|
XMPP Proxy Server instance
|
|
|
|
|
|
|
|
|
|
|
A note on operating system memory requirements:
The actual RAM required for the operating system will vary depending on the different operating systems and on the amount of processes collocated on the box.
A note on the machine's RAM size:
All the above processes' memory must fit into the physical available RAM. Do not rely on the operating system, storage backend, or virtual memory.
If there's not enough physical RAM to accommodate all the processes' memory requirements, the OS will begin using its virtual memory as a container from the process memory, which will cause paging.
The paging concept does not work as well for Java
TM Virtual Machines (JVMs) as it does for C++ applications. During JVM garbage collections, the JVM must “walk” across all objects in memory; therefore it's excessively loading memory pages into the RAM while off-loading others (paging). This behavior quickly leads to trashing.
A note on hypervisor RAM overcommitment for virtual machine (VM) deployment:
Even if you make sure to configure your VM with sufficient RAM, you should consult your system administrator to make sure that your VM will not be affected by hypervisor-wide RAM overcommitment.
To do this, configure the VM with a memory reservation (VMWARE term) equal to the VM's provisioned RAM size. Likewise, you should disable memory ballooning in the VMware tools agent. Note that similar concepts under different names exist for hypervisors other than VMWare.
A Sametime Gateway cluster (basically a WebSphere Application Server cluster) can include one or more server instances. Multiple Sametime Gateway instances can be collocated on the same physical box.
For example, a quad-core, 8GB RAM server can support four Sametime Gateway instances per
the following sizing calculation:
Gateway instances = 1.8GB x 4 = 7.2GB
WebSphere node agent = 180MB
Operating system = 512MB
___
Total = 7.9GB
Running on a single CPU, a Session Initiation Protocol (SIP) proxy server can handle the amount of traffic that eight fully loaded Sametime Gateway instances generate; thus
n SIP proxy instances are needed to support 8
n Sametime Gateway instances (typically each Sametime Gateway instance runs at about 60 transactions/sec).
Bandwidth requirements
The Sametime Gateway communicates with external communities over the public Internet. The related required network bandwidth depends on the number of awareness subscriptions (internal user1 subscribing on the awareness status of external user2, and
vice versa).
The projected number of active subscriptions in the system is a direct product of the number of external contacts that an average user has on their buddy list.
In this example we use a 100,000 subscriptions value, which is computed as 10,000 online users, local users with 5 external contacts in their buddy list, and external users with 5 local contacts in their buddy list (10K*(5+5)).
The measurements below were taken by the Sametime Gateway Development team while federating with an external community over the SIP Protocol, not over the Extensible Messaging and Presence Protocol (XMPP).
Startup process bandwidth usage
If the Sametime Gateway starts up when both internal and external users are online, the Gateway will start sending and receiving all the users' pending awareness subscription requests.
Assuming there are 100,000 pending subscriptions that require delivery, a total of 170MB will be sent and received over the wire, and the duration of this startup process will depend on the bandwidth available.
Assuming a symmetric bandwidth of 105KB/s is available, the process will end after 27 minutes [170MB / (105KB/s * 60s)].
Post-startup (steady-state) bandwidth usage
After the Sametime Gateway has finished the initial bulk exchange of awareness subscriptions, traffic will reduce to the normal operations traffic, which includes sending and receiving messages such as awareness state changes, instant messages, and re-subscribes.
The steady-state average bandwidth required is 105KB/s for every 100,000 subscriptions. If your system is expected to handle a different number of subscriptions, you should adjust the network requirements accordingly.
For example, if your system is expected to handle 200,000 subscriptions, the normal operations required bandwidth is 105KB/s * 2 = 210KB/s.
Other deployment considerations
In order to connect through a Network Address Translation (NAT) device, a SIP Proxy Server must be used. However, a SIP Proxy Server cannot work with a standalone Sametime Gateway Server; instead, it must be a connected to a Sametime Gateway cluster (where a cluster is defined as one or more servers).
Collocation versus high availability
When deploying multiple Sametime Gateway (WebSphere Application Server) instances on the same physical box, you must take failover considerations into account. Each Sametime Gateway instance replicates its SIP sessions to peer Sametime Gateway instances; however, placing these two instances on the same physical box reduces the overall system availability.
Even though, in the event of a process crash the other process can take the place of the process that crashed, a failure of the box itself (operating system, power, physical malfunction) will pose a single point of failure, and the system availability will be reduced. Hence, peer instances are best placed on different boxes.
NOTE: The Sametime Community server and the corporate LDAP directory are not considered to be part of the Sametime Gateway deployment. In most cases, these components are already deployed and running.
Scenario #1: Basic environment
Requirements
The requirements for the basic environment are listed in table 2.
Table 2. Basic environment requirements
Provide the following information:
|
|
|
|
|
|
|
|
During peak times, what is the number of online user in your local IM community?
Default value=5,000, Values range=10--1,000,000
|
How many external contacts in a buddy list?
|
|
On average, how many external contacts are in each local user’s buddy list?
Default value=5, Values range=1--50
|
Should the system include high availability?
|
|
|
|
|
|
Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
|
|
|
|
|
|
|
|
Sametime Gateway instances
|
|
The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
|
|
|
|
The total number of SIP Proxy instances needed to satisfy requirements
|
|
|
|
The total number of DB2 instances needed to satisfy requirements
|
Discussion
This scenario is a minimal configuration that includes a standalone Sametime Gateway instance capable of supporting the capacity requirements.
To conserve resources, the Sametime Gateway instance and its corresponding DB2 instance are collocated on the same physical box. If NAT support were required, a Sametime Gateway cluster with a single Sametime Gateway server plus a SIP-proxy instance could have been placed on that same single box as well.
CPU requirements:
A single core
RAM requirements:
Gateway instances = 1.8GB
Operating system = 512MB
___
Total = 2.3GB
A note on the Total RAM usage: If the expected peak number of online users is lower than 7,500, then the system could be hosted on a system with 2GB of RAM only.
Bandwidth requirements:
In this example we use a 100,000 subscriptions value that is computed from 10,000 online users, each with 5 external contacts in their buddy list, and external user also subscribes on internal user (10K*5*2).
Therefore, we require a symmetric Internet connection with a bandwidth of at least 105KB/s.
NOTE: The above bandwidth requirement is true for communication over SIP only (not applicable to XMPP).
Summary
This Sametime Gateway deployment requires a single box with:
- A single CPU core
- 2.3GB of RAM or more
- Symmetric Internet connection with a bandwidth of at least 105KB/s
Scenario #2: Large deployment using NAT, no high availability
Requirements
The requirements for the large environment with NAT are listed in table 3.
Table 3. Requirements for large environment with NAT
Provide the following information:
|
|
|
|
|
|
|
|
During peak times, what is the number of online user in your local IM community?
Default value=5,000, Values range=10--1,000,000
|
How many external contacts in a buddy list?
|
|
On average, how many external contacts are in each local user’s buddy list?
Default value=5, Values range=1--50
|
Should the system include high availability?
|
|
|
|
|
|
Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
|
|
|
|
|
|
|
|
Sametime Gateway WebSphere Application Server instances
|
|
The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
|
|
|
|
The total number of SIP Proxy instances needed to satisfy requirements
|
|
|
|
The total number of DB2 instances needed to satisfy requirements
|
Discussion
This configuration depicts a large deployment (35K internal users) in which each local user has a relatively high average number (10) of external contacts in his buddy list (the normal is considered to be 5).
Because the environment consist of more than a single instance of Sametime Gateway, this automatically means that at least one SIP-proxy instance is needed, so that the incoming traffic can be load balanced between the Sametime Gateway instances.
If you wish to implement a high-availability solution, then two SIP proxies would be needed. The SIP proxy instance is collocated alongside the DB2 server and the WebSphere Application Server Deployment Manager, and is responsible for performing the NAT translation.
This environment doesn't support high availability, so recovery from a node failure will take longer than in an environment with high availability.
CPU requirements:
Box1: Three Sametime Gateway server instances = 3 cores
Box2: Two Sametime Gateway server instances = 2 cores
Box3: DB2 + SIP Proxy = 1 + 1 = 2 cores
RAM requirements for Box1:
Gateway instances = 1.8GB * 3 = 5.4GB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 6.1GB
RAM requirements for Box2:
Gateway instances = 1.8GB * 2 = 3.6GB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 4.2GB
RAM requirements for Box3:
WebSphere SIP Proxy Server instance = 750MB
DB2 = 512MB
WebSphere Deployment manager = 350MB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 2.3GB
Bandwidth requirements:
The SIP Proxy will be the only component that talks directly with the outside world via the Internet connection.
In this example we use a 700,000 subscriptions value that is computed from 35,000 online users, each with 10 external contacts in their buddy list, external user also subscribes on internal user (35K*10*2).
Therefore, we require a symmetric Internet connection with a bandwidth of at least 735KB/s
(computed as 105KB/s * 7).
NOTE: The above bandwidth requirement is true for communication over SIP only and is not applicable to XMPP.
Summary
This Sametime Gateway deployment requires three boxes:
- Box1 with three CPU cores
Box2 with two CPU core
Box3 with two CPU cores
- Box1 with 6.1GB of RAM or more
Box2 with 4.2GB of RAM or more
Box3 with 2.3GB of RAM or more
- Symmetric Internet connection with a bandwidth of at least 735KB/s.
Figure 1 shows boxes 1, 2, and 3 that were provisioned with more than enough resources to support the above requirements. This is the case because these are physical machines; if you have a virtualized infrastructure, it will be easier to match the requirements exactly, thus saving on resources.
Figure 1. Provisioned boxes
Scenario #3: Large environment with high availability
Requirements
The requirements for the large environment with high availability are listed in table 4.
Table 4. Requirements for large environment with high availability
Provide the following information:
|
|
|
|
|
|
|
|
During peak times, what is the number of online user in your local IM community?
Default value=5,000, Values range=10--1,000,000
|
How many external contacts in a buddy list?
|
|
On average, how many external contacts are in each local user’s buddy list?
Default value=5, Values range=1--50
|
Should the system include high availability?
|
|
|
|
|
|
Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
|
|
|
|
|
|
|
|
Sametime Gateway WebSphere Application Server instances
|
|
The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
|
|
|
|
The total number of SIP Proxy instances needed to satisfy requirements
|
|
|
|
The total number of DB2 instances needed to satisfy requirements
|
Discussion
This configuration depicts a very large deployment (75K internal users) in which each local user has a normal average number of external contacts (5) in their buddy list. Fourteen instances of Sametime Gateway are required, and we can place every three or four Sametime Gateway instances on its own box.
The sizing planning takes into account the requirement for high availability, so that the environment can continue to function normally, even if two out of the four physical boxes are down (seven to eight Sametime Gateway instances are enough).
Session replication peers are configured in a way that guarantees maximum load dispersion in the event of a box failure. Here is the suggested pairing: 1-5, 2-9, 3-13, 4-6, 7-10, 8-14, 11-12.
If a box fails, its 100% load is distributed as 50%, 25%, 25% between the three remaining boxes (see figure 2 in the Summary section below). For more details about replication domains, refer to the Lotus Sametime Gateway InfoCenter topic, "
Setting up node replication and failover for the cluster".
The architecture includes four SIP proxy instances because we need a single SIP proxy instance for each eight Sametime Gateway instances, plus a backup instance due to the high availability requirement (16/8)*2=4.
Box #5 contains SIP proxy instances #1 and #2, collocated alongside the DB2 server #1, and the WebSphere Application Server Deployment Manager.
Box #6 contains SIP proxy instances #3 and #4, collocated alongside the #2 DB2 server.
Some sort of a hardware load balancer (with an appropriate backup) device should be placed in front of the four SIP proxies. For more details on multiple SIP Proxies, refer to the InfoCenter topic, “
Guidelines for using multiple SIP or XMPP proxy servers.” The SIP proxy instances are responsible for performing the NAT translation.
The DB2 server is also clustered (an active-passive configuration is good enough) to allow for failover.
This environment fully supports high availability.
CPU requirements:
Box1/Box2: Four Sametime Gateway server instances = 4 cores
Box3/Box4: Three Sametime Gateway server instances = 3 cores
Box5/Box6: DB2 + SIP Proxy + SIP Proxy = 1 + 1 +1 = 3 cores
RAM requirements for Box1/Box2:
Gateway instances = 1.8GB * 4 = 7.2GB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 7.9GB
RAM requirements for Box3/Box4:
Gateway instances = 1.8GB * 3 = 5.4GB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 6.1GB
RAM requirements: Box5
WebSphere SIP Proxy Server instance = 750MB
WebSphere SIP Proxy Server instance = 750MB
DB2 = 512MB
WebSphere Deployment manager = 350MB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 3GB
RAM requirements: Box6
WebSphere SIP Proxy Server instance = 750MB
WebSphere SIP Proxy Server instance = 750MB
DB2 = 512MB
WebSphere Node Agent = 180MB
Operating System = 512MB
___
Total = 2.7GB
Bandwidth requirements:
The SIP Proxies are the only components that talk directly with the outside world via the Internet connection.
In this example we use a 750,000 subscriptions value that is computed from 75,000 online users, each with 5 external contacts in their buddy list, external user also subscribes on internal user (75K*5*2).
Therefore, we require a symmetric Internet connection with a bandwidth of at least 788KB/s
(computed as 105KB/s * 7.5)
NOTE: The above bandwidth requirement is true for communication over SIP only and is not applicable to XMPP.
Summary
This Sametime Gateway deployment requires six boxes (see figure 2), as follows:
- Box1 and Box2
- Four CPU cores
- 7.9GB of RAM or more
- Box3 and Box4
- Three CPU cores
- 6.1GB of RAM or more
- Box5 and Box6
- Three CPU cores
- ~3GB of RAM or more
- Symmetric Internet connection with a bandwidth of at least 788KB/s.
Figure 2. Six-box deployment scenario
Conclusion
To summarize the key points of the article:
- Sizing is an important process that should be conducted early in deployment planing.
- The gateway sizing results are mostly affected by the overall number of subscriptions in the system, which dictates memory usage requirements.
- The number of subscriptions is the product of the number of online local users times the average number of external contacts in the local user's buddy list. A good estimation for the number of users in the buddy list could be determined during a pilot project.
- Even for the same set of sizing requirements, there are multiple topologies that are possible. Each topology has a different set of pros and cons, which the system architect should carefully consider before committing to a particular one.
- Remember that you can start with a small-capacity cluster, then add more servers as your requirements grow over time.
- Formal software sizing support is available from IBM Techline. Contact your local IBM sales representative for assistance.
Resources
Lotus Sametime Gateway information center:
http://publib.boulder.ibm.com/infocenter/sametime/v8r5/index.jsp?topic=/com.ibm.help.sametime.v85.doc/overview/over_server_gw.html
Lotus Sametime documentation:
http://www.ibm.com/developerworks/lotus/documentation/sametime/
IBM Techline sizing service:
http://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/LLIE-6LLS4T/lc=en_US
developerWorks® white paper, “Using Session Initiation Protocol with IBM Lotus Sametime:”
http://www.ibm.com/developerworks/lotus/library/d-ls-sip-sametime/
About the authors
Gili Nachum is an Advisory Software Engineer with 11 years of software development experience. Gili has been at IBM since 2007, developing the Lotus Sametime Gateway server on top of WebSphere Application Server. He is active in the Israeli software community. You can read Gili's opinions on software development at his
Java Tuning blog.
Itai Zapler is a Staff Software Engineer based at IBM's Israel Software labs, where he develops the Sametime Gateway server, focusing on the XMPP protocol and Java performance tuning. Itai has 8 years of software development experience. You can reach him at
itaiz@il.ibm.com.