Skip Navigation

Configuring BEMS for disaster recovery in an on-premises environment

You can configure your
BEMS
environment so that it continues to function in the event of a severe disruption. This section describes a disaster recovery configuration for a large organization with a primary site and a remotely located secondary, or disaster recovery, site.
The servers at the disaster recovery site are assigned secondary priority. They are powered on, but their services are stopped. This configuration allows for server maintenance such as security patches. Because the services are off, TCP connections are quickly rejected if there is an attempt to connect to one of the disaster recovery servers. In a disaster recovery event, the primary servers go offline. An administrator must manually start the services on the disaster recovery servers after the failover of the databases is complete.
When you configure your environment for disaster recovery, consider the following:
  • The
    BEMS
    servers with
    BlackBerry Push Notifications
    ,
    BlackBerry Connect
    ,
    BlackBerry Presence
    , and
    BlackBerry Docs
    are generally configured as single clusters in large environments.
  • BEMS
    with
    BlackBerry Presence
    can be a cluster on its own, or it can be in a
    BEMS
    with
    BlackBerry Push Notifications
    cluster, or in a
    BEMS
    with
    BlackBerry Connect
    cluster.
  • For
    BlackBerry Connect
    and
    BlackBerry Presence
    , the
    Skype for Business
    front-end pool connection may need to be reconfigured in a disaster recovery event.
  • For
    BlackBerry Connect
    , the
    BlackBerry Proxy
    start up node must be configured for the disaster recovery site on the servers with secondary priority.
Two general principles underlie the configuration:
  • Avoid cross-site configuration, connectivity traffic, and database access because the network latency and server searches between two sites can lead to slower response times and undesired timeouts.
  • Configure the secondary site with servers up and all BlackBerry services off because this allows rapid connectivity timeouts at the application layers, rather than slower TCP timeouts. In addition, it allows security patches for the operating system to be applied regularly in a timely fashion.