Sametime Gateway Sizing Guidelines – September 2008
Deployment architecture planning guidelines
These guidelines are intended for technical solutions architects who are planning a Sametime Gateway deployment.
In these guidelines, a CPU core is an independent physical CPU core (not hyper threaded), running at a clock speed of ~2-3 GHz.
Each DB2 server consumes about 512MB-1GB of RAM.
Each Sametime Gateway instance should be on a single CPU and have 2GB of RAM.
Each SIP proxy instance consumes about 600MB of RAM.
The WebSphere Application Server nodeagent process uses a relatively small amount of RAM, about 150MB. Normally, you would have one or two such processes on each physical box. Nodeagent CPU usage is negligible.
The WebSphere Application Server Deployment Manager process consumes 150MB of RAM. Deployment Manager CPU usage is negligible.
The term Sametime Gateway instance refers to either a stand-alone Sametime Gateway server, or to a Sametime Gateway server participating in a cluster instance.
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.
A Sametime Gateway cluster (basically a Websphere application server cluster), can include one or more server instances.
In order to connect through a NAT device, a SIP Proxy Server must be used.
A SIP Proxy Server cannot work with a stand-alone Sametime Gateway Server. Instead, It must be a connected to a Sametime Gateway cluster (A cluster includes one or more servers)
Running on a single CPU, a SIP proxy server can handle the amount of traffic that eight, fully loaded, Sametime Gateway instances generate, thus n SIP proxies instances are needed to support 8n Sametime Gateway instances (on routine, each Sametime Gateway instance runs at about 60 Tx/sec).
Collocation versus High Availability
When deploying multiple Sametime Gateway (WebSphere Application Server) instances on the same physical box, you should take fail-over 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. Although, in the event of a process crash, the other process could 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.
Scenario #1 – Basic Environment
Requirements:
Please provide the following information:Question / Value / Question details
How many online users? / 5,000 / 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? / 5 / 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? / 0 / No=0 Yes=1
Network Address Translators (NATs) in use? / 0 / Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
Estimations:
Sametime Gateway instances / 1 / The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
Sip Proxy instances / 0 / The total number of Sip Proxy instances needed to satisfy requirements
DB2 instance / 1 / The total number of DB2 instances needed to satisfy requirements
Discussion
This is a minimal configuration; one Sametime Gateway instance has the capacity to support the corporate environment.
In order to save resources, the Sametime Gateway instance and its corresponding DB2 instance are collocated on the same physical box. If NAT support would have been required, a SIP-proxy instance could have been placed on that same single box, as well.
Summary
This Sametime Gateway deployment requires a single box with a single CPU and 3GB of RAM. Note: the Sametime community server and the corporate LDAP directory are not considered to be part of the Sametime Gateway deployment. In most cases, they are already deployed and running.
Diagram:
Scenario #2 – Large deployment using NAT, no High Availability
Requirements:
Please provide the following information:Question / Value / Question details
How many online users? / 35,000 / 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? / 10 / 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? / 0 /
No=0 Yes=1
Network Address Translators (NATs) in use? / 1 / Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
Estimations:
Sametime Gateway WebSphere Application Server instances / 8 / The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
Sip Proxy instances / 1 / The total number of Sip Proxy instances needed to satisfy requirements
DB2 instance / 1 / The total number of DB2 instances needed to satisfy requirements
Discussion:
This configuration depicts large deployment (35K of internal users); each local user has a relatively high average number of external contacts (10) in his buddy list.
Eight instances of Sametime Gateway are required; we can place every four Sametime Gateway instances on a quad core, 8GB of RAM box (a 4X8 box). Thus, two 4X8 boxes are needed.
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 the incoming traffic will be load-balanced between the Sametime Gateway instances.
If one wishes to also implement a High Availability solution, then two or more SIP proxies would have been needed.
The SIP proxy instance will be collocated along side the DB2 server, and the WebSphere Application Server Deployment Manager, on a 1X2 box.
The SIP proxy instance is responsible for performing the NAT translation.
This environment doesn't support High Availability. Recovery from a node failure will be longer than in an environment which implements High Availability.
Summary
Two 4X8 boxes and one 2X4 box support this company’s requirements.
Diagram:
Scenario #3 – Large environment with High Availability
Requirements:
Please provide the following information:Question / Value / Question details
How many online users? / 75,000 / 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? / 5 / 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? / 1 /
No=0 Yes=1
Network Address Translators (NATs) in use? / 1 / Should the system be deployed in a public-IP configuration, or a NAT network configuration?
Public-IP=0, NAT=1
Estimations:
Sametime Gateway WebSphere Application Server instances / 16 / The total number of Sametime Gateway WebSphere Application Server instances needed to satisfy requirements
Sip Proxy instances / 2 / The total number of Sip Proxy instances needed to satisfy requirements
DB2 instance / 2 / The total number of DB2 instances needed to satisfy requirements
Discussion:
This configuration depicts a very large deployment (100K of internal users); each local user has a normal average number of external contacts (5) in their buddy list.
Sixteen instances of Sametime Gateway are required; we can place every four Sametime Gateway instances on a quad core, 8GB of RAM box (a 4X8 box). Thus, four 4X8 boxes are needed.
Since High Availability is a requirement for this customer, the sizing planning takes that into account and the environment can continue to function as normal even if two out of the four Sametime Gateway instances physical boxes are down (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-15, 12-16
If a box fails, its 100% load is distributed as: (50%, 25%, 25%) between the two remaining servers.
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 High Availability requirements, (16/8)*2=4.
Box #5 will contain SIP proxy instances #1 and #2, collocated along side the #1 DB2 server, and the WebSphere Application Server Deployment Manager.
Box #6 will contain SIP proxy instances #3 and #4, collocated along side 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.
The DB2 server is also clustered (an active-passive configuration is good enough) to allow for fail-over.
The SIP proxy instances are responsible for performing the NAT translation.
This environment fully supports High Availability.
Summary
Four 4X8 boxes and two 2X4 boxes support this company’s requirements.