Disaster Server Architecture

Companies with sensitive or high availability needs might want to deploy multiple, fully-redundant servers to maintain continuous operation even in the event of serious disruptions. BigFix includes the important ability to add multiple, fully redundant servers: a feature called Disaster Server Architecture (DSA).

Each server maintains a replica of the BigFix database and can be positioned anywhere in the world. In the case of a network fracture, these servers continue to provide uninterrupted service to the local network. As soon as the connection is reestablished, the servers automatically reconnect and sync up. The BigFix relays and clients are also capable of successfully recovering from such a disconnect. DSA provides the following capabilities:
  • Continued service availability on both sides of a network split (automatic failover).
  • Continued availability in the event of a server outage.
  • Distribution of console database load during normal operation.
  • Automatic failback upon reconnecting.

To take advantage of this function, you need one or more additional servers with a capability at least equal to your primary server. All the BigFix servers in your deployment must run the same version of SQL Server. If your existing Server is running SQL 2016, your new servers must run SQL 2016 as well.

For more information about using server redundancy, see Using multiple servers (DSA).

Multiple servers also help to distribute the load and create a more efficient deployment. Here is a simple diagram of how multiple servers might be set up to provide redundancy:


This window displays a Disaster Server Architecture with a simple diagram of how multiple servers might be set up to provide redundancy.

In case of a failover, the specific configured relays automatically find the backup server and reconnect the network. For more information about the relay configuration see, Configuring relay failover.

Note the following about the diagram:

  • The BigFix servers are connected by a fast WAN, allowing them to synchronize several times per hour.
  • The servers need both an ODBC and an HTTP link to operate and replicate properly.
  • There is a primary server with an ID of 0 (zero). It is the first server that you install, and it is the default server for running the BigFix Administration Tool.
  • For the sake of clarity, this is a minimal configuration. A more realistic deployment would have a top-level relay and other WAN connections to regional offices.
  • The BigFix servers and relays are configured so that control can be automatically routed around a server outage (planned or otherwise), and upon failover reconnection, the databases are automatically merged.
  • The BigFix servers communicate on a regular schedule to replicate their data. You can review the current status and adjust the replication interval through BigFix Administration > Replication. For the best possible performance, these pipes should be FAT.
  • This diagram only shows two servers, but the same basic architecture would apply to each additional server. With multiple servers, a shortest-path algorithm is used to guide the replication.
  • When an outage or other problem causes a network split, it is possible for a custom Fixlet or a retrieved property to be modified independently on both sides of the split. When the network is reconnected on failover, precedence goes to the version on the server with the lowest server ID.