G Deploying a Scalable Presence Deployment
This section describes the recommended and supported deployment topology for a large scale Presence Solution requiring Presence, XDMS, and User Dispatcher. It illustrates the typical flows from a multi-node perspective. Topics include:
G.1 Presence Cluster
A Presence Cluster is defined as a set of Presence Nodes connected after one or more Load Balancers. The Presence Cluster is responsible for processing incoming subscribe and publish requests made towards the presence event-package and for sending out notify's whenever appropriate. The Presence Cluster will also accept and process subscribe requests for the presence.winfo event-package.The Presence Cluster will interact with the XDM Cluster in order to obtain information needed to complete its responsibilities. The information queried of the XDM Cluster is user's presence-rules and pidf-manipulation documents.
The Presence Cluster is layered into the following three distinct tiers:
-
The load-balancing layer, responsible for dispatching incoming traffic to the User Dispatchers. The load balancers are stateless and are not required to understand SIP as a protocol.
-
The user-dispatching layer, responsible for dispatching traffic based on user information. A user is assigned to a particular Presence Server instance and all traffic destined to that user will be dispatched to the same Presence Server instance. Even though each User Dispatcher is stateless and does not share state with the other User Dispatchers, they still need to have the same view of the Presence Server tier.
-
The bottom layer is where the Presence Server instances reside. Each instance is separated from the others and does not share any state with any other instances. The purpose of the Presence Server tier is to serve incoming SUBSCRIBE and PUBLISH requests destined to the presence event-package as well as servicing subscriptions to the presence.winfo event-package.
The Presence Cluster consists of the following physical nodes:
-
The Load Balancer, such as an BigIP from F5 Networks.
-
The Presence Node, which consists of the following components:
-
User Dispatcher
-
Presence Server
-
G.2 XDM Cluster
The XDM cluster is defined as a set of XDM Nodes connected after one or more Load Balancers. The XDM cluster processes all XDM related traffic, that is, SIP subscribe traffic towards the ua-profile event-package and XCAP traffic. As such, it deals with everything that has to do with manipulating XML documents. The XDM Cluster uses a database for actual storage of the XML documents but note that the database, and potentially its cluster, is not part of the XDM Cluster.
The XDM cluster consists of the following layers:
-
The load-balancing tier, responsible for dispatching both SIP and XCAP traffic to the next layer. For XCAP traffic the next tier is the Aggregation Proxy but for SIP, the traffic goes directly to the User Dispatcher layer.
-
Aggregation Proxy layer – authenticates incoming traffic and upon successful authentication it forwards the requests to the User Dispatcher layer. All XCAP traffic from external networks (such as from outside the XDM cluster) goes through the Aggregation Proxy layer. Internal traffic, however, will not go through the Aggregation Proxy but rather directly to the User Dispatchers.
-
User Dispatcher layer – from a SIP perspective it carries out the exact same duties and functions as in the Presence Cluster (it is the same kind of traffic after all). The main difference in the XDM Cluster compared to the presence one is that in the XDM Cluster the User Dispatchers will also have to handle XCAP traffic. However, the XCAP traffic is treated in the exact same way as SIP and the purpose of the User Dispatcher for XCAP traffic is the same as for SIP: to extract user information based on the request and then dispatch it to the correct XDMS instance.
-
The XDM Server layer has the same function as the Presence Servers in the Presence Cluster. The XDMS instances serve incoming SUBSCRIBE requests for the event-package ua-profile and will send out NOTIFY messages to registered subscribers as appropriate. Note that the XDMS does not accept PUBLISH requests and updating the state of the Resources (which are XML documents) is achieved through XCAP operations. An XDM Client can manipulate the documents managed by an XDMS by issuing appropriate XCAP operations. A successful XCAP operation may alter the content of a document, causing the XDMS to send out NOTIFY messages to all subscribers of that document informing them about the change. Whenever the XDMS needs to get an XML document it queries the next layer, the database layer.
-
The Database tier physically stores the XML documents managed by the XDMS. This tier guarantees high-availability and scalability so that if one of the nodes in the database layer fails, documents that resided on that node will still be accessible to the XDMS without any loss of data or service.
The XDM Cluster consists of the following physical nodes:
-
The Load Balancer, such as an Big IP from F5 Networks.
-
The XDM Node, which consists of the following components:
-
Aggregation Proxy
-
User Dispatcher
-
The XDM Server (XDMS)
-
-
The database.
G.3 Presence Node
The Presence Node is the main component in the Presence Cluster and is responsible for dispatching the incoming traffic to the correct Presence Server instance and servicing users with presence information. The User Dispatcher servers the same purpose both in a single node deployment and in a multi-node deployment, which is to dispatch incoming traffic to a particular Presence Server instance; whether or not the target Presence Server instance is on the same physical node as the User Dispatcher is of no significance to the User Dispatcher.
A Presence Node will always have a User Dispatcher deployed that serves as the main entrance into the node itself. Typically, the User Dispatchers listen to port 5060 and the Presence Servers on that node listen on other ports. In this way, a single node will appear as one Presence Server to clients but is in fact multiple instances running behind the User Dispatcher. Each of the components deployed on the Presence Node is executing in their own separate Java Virtual Machine. That is, the User Dispatcher and the Presence Server instances execute in their own OWLCS and SIP containers. The reason for this is to be able to utilize all the available memory on that machine.
G.4 XDM Node
The XDM Node always has an Aggregation Proxy deployed that typically listens on port 80 for XCAP traffic. The Aggregation Proxy authenticates incoming traffic and upon successful authentication forwards the request to the User Dispatcher. As with the Presence Node, the XDM Node will also have a User Dispatcher deployed (usually on port 5060) and for SIP traffic there is no difference between the XDM and Presence Nodes. The difference between the two types of nodes is that the User Dispatcher will also dispatch XCAP traffic. As it does with SIP, it extracts the user id out of the request and, based on that, maps the request to a particular XDMS instance to which it forwards the request.
There will be a number of XDMS instances deployed to which the User Dispatcher dispatches both SIP and XCAP traffic. Just as in the case of the Presence Server instances on the Presence Node, each XDMS instance is not aware of the others and executes in isolation.
G.5 Complete Presence and XDM Cluster
Figure G-1 shows a complete Presence and XDM cluster with all necessary components. This figure also illustrates that the two clusters, Presence and XDM, are treated as two separate clusters and the way into those two networks for initial traffic is always through their respective Load Balancers. Even the Presence Servers will actually go through the Load Balancer of the XDM Cluster when setting up subscriptions. However, once a subscription has been established the subsequent requests will not go through the Load Balancer but rather directly to the XDMS instance hosting the subscription. All nodes in the XDM Cluster are directly accessible from the Presence Cluster.
