Cisco Cisco Expressway
High Availability for XMPP Federation
High availability for XMPP federation differs from the high availability model for other IM and Presence
Service features because it is not tied to the two node sub-cluster model.
Service features because it is not tied to the two node sub-cluster model.
To provide high availability for XMPP federation, you must enable two or more IM and Presence Service
nodes in your cluster for XMPP federation; having multiple nodes enabled for XMPP federation not only adds
scale but it also provides redundancy in the event that any node fails.
nodes in your cluster for XMPP federation; having multiple nodes enabled for XMPP federation not only adds
scale but it also provides redundancy in the event that any node fails.
High Availability for Outbound Request Routing
IM and Presence Service evenly load balances outbound requests from users within that cluster across all
the XMPP federation enabled nodes in the cluster. If any node fails, IM and Presence Service dynamically
spreads the outbound traffic across the remaining active nodes within the cluster.
the XMPP federation enabled nodes in the cluster. If any node fails, IM and Presence Service dynamically
spreads the outbound traffic across the remaining active nodes within the cluster.
High Availability for Inbound Request Routing
An additional step is required to provide high availability for inbound request routing. To allow an external
domain to discover the local IM and Presence Service deployment, a DNS SRV record must be published on
a public DNS server. This record resolves to an XMPP federation enabled node. The external domain then
connects to the resolved address.
domain to discover the local IM and Presence Service deployment, a DNS SRV record must be published on
a public DNS server. This record resolves to an XMPP federation enabled node. The external domain then
connects to the resolved address.
To provide high availability in this model, multiple DNS SRV records must be published for the local IM and
Presence Service deployment. Each of these records resolve to one of the XMPP federation-enabled nodes
within the local IM and Presence Service deployment.
Presence Service deployment. Each of these records resolve to one of the XMPP federation-enabled nodes
within the local IM and Presence Service deployment.
These records provide a choice of DNS SRV records for the local deployment. If an XMPP federation
enabled node fails, the external system has other options from which to connect to the local IM and Presence
Service deployment.
enabled node fails, the external system has other options from which to connect to the local IM and Presence
Service deployment.
Notes: Each published DNS SRV records must have the same priority and weight. This allows a spread of
load across all published records, and also allows the external system to correctly reconnect to one of the
other nodes with a DNS SRV record in the event of a failure.
load across all published records, and also allows the external system to correctly reconnect to one of the
other nodes with a DNS SRV record in the event of a failure.
DNS SRV records may be published for all or just a subset of XMPP federation enabled nodes. The greater
the number of records published, the greater the redundancy in the system for inbound request handling.
the number of records published, the greater the redundancy in the system for inbound request handling.
If you configure the Chat feature on an IM and Presence Service node in an XMPP federation deployment,
you can publish multiple DNS SRV records for chat node aliases also. This allows the external system to
find another inbound route to that specific chat node through another XMPP federation node, should any
XMPP federation-enabled node fail. Note that this is not high availability for the Chat feature itself, but an
extension of the XMPP federation high availability feature for inbound requests addressed to chat node
aliases.
you can publish multiple DNS SRV records for chat node aliases also. This allows the external system to
find another inbound route to that specific chat node through another XMPP federation node, should any
XMPP federation-enabled node fail. Note that this is not high availability for the Chat feature itself, but an
extension of the XMPP federation high availability feature for inbound requests addressed to chat node
aliases.
Cisco Unified Communications XMPP Federation Deployment Guide (1.4)
Page 57 of 59
XMPP Federation through IM and Presence Service