Building management systems are taken for granted by most people within an organization – until they fail! Todd Doane looks at the use of high availability to enhance resilience in this area.
Building management systems (BMS) are great for ensuring that people with appropriate access credentials can get in and out securely, that the lights go on in the building or around the campus when they’re supposed to, that the elevators work, and that the fire suppression systems will engage the moment a flame is detected. But what happens if the BMS unexpectedly goes offline? The doors don’t open; the lights don’t go on. The people stuck between floors on the elevator desperately hope a fire isn’t breaking out somewhere.
A BMS is great as long as it is working, and the best way to ensure that it remains working is to configure your BMS for high availability (HA). In this context, HA means that your BMS would be operational no less than 99.99% of the time. If something were to cause your BMS to stop working suddenly – a power failure or a flooded data center, for example — the infrastructure supporting your BMS would detect that stoppage and automatically engage another instance of your BMS system, running in a separate location but containing an identical copy of the BMS database and application code, to take over the tasks that had been supported by the previously-active instance of your BMS. This automated failover mechanism ensures that your BMS would effectively be operational between 99.99% and 100% of the time.
So how do you configure a BMS infrastructure for HA? Let’s start with the concept of a failover cluster, which consists of two or more workstations, servers, or virtual machines (VMs) — the nodes of a failover cluster instance (FCI). These nodes are monitored by software and services that can cause the workloads on an active node to fail over to a secondary node in the FCI if the monitoring software detects that the active node has become non-responsive.
Historically, FCIs often relied on a shared storage area network (SAN) that every compute node in the FCI could access, but in an FCI configured for HA that approach doesn’t work. Shared storage constitutes a single point of failure, which precludes a guarantee that your BMS could access the data in storage at least 99.99% of the time. So, in an FCI configured for HA, each compute node will have its own storage subsystem and the software ensuring HA will provide services designed to replicate data – in real time – from one node to another. These synchronous data replication services ensure that an up-to-the-instant copy of the database supporting your active BMS instance resides on the other node (or nodes) in the FCI. If something suddenly happens to the node running the BMS, the software monitoring the FCI can fail over to the secondary node and the instance of the BMS on that secondary node can immediately pick up where BMS running on the previously active node had left off. There’s no loss of data and no more than a few seconds lost in terms of BMS responsiveness during failover.
Configuring a workstation-based BMS for HA
If your BMS is running on a workstation, the easiest way for you to configure your BMS for HA is to put an identically-configured workstation in another location – ideally in a separate building a few miles away – and connect them using SANless clustering software running over a high speed network. The SANless clustering software will link both workstations in a logical FCI and then use synchronous data replication services to ensure that all the data on the active BMS system is replicated in real-time to storage on the secondary workstation. If something causes the BMS on the active workstation to fail, the SANless clustering software will automatically fail over to the secondary workstation, where an instance of the BMS running on that workstation would immediately take over. Because all the data that the previously active system had been using has been replicated to the second workstation in the FCI, there’s no data loss during failover and your BMS, now running on the secondary workstation, is back online within seconds.
Configuring a server-based BMS for HA
If your BMS is running on a server or VM – on-premises or in the cloud – the path to HA is basically the same as it is for a workstation-based BMS, though there are points where the path may branch depending on what operating system and database you’re using. As in a workstation-based HA configuration, a server/VM-based HA configuration requires two identical instances of the infrastructure supporting your BMS. This infrastructure should be located in separate but geographically proximate data centers or, as they are known in cloud-based environments, availability zones (AZs). If your BMS goes offline because of an event affecting an entire AZ – say, a network failure or a water main break – the secondary instance of your BMS needs to be running in a data center that is unlikely to be affected by the same network failure or water main break.
Navigating server infrastructure variables
Here’s where the path towards HA encounters branching options. If your BMS runs on Windows Server and SQL Server, you can configure for HA in one of two ways. You could use the same SANless clustering approach described above. The SANless clustering software would create an FCI consisting of two or more servers/VMs and then synchronously replicate BMS data between the primary and secondary nodes. If the SANless clustering software detects that your BMS is not responding – whether because of a flood, a disk failure, or human error – it will interact with the Windows Server Failover Cluster (WSFC) management services built into Windows Server and cause your BMS processes to fail over to the BMS infrastructure configured on the secondary FCI node. Your BMS would be back online in seconds.
Alternatively, instead of using a third party’s SANless clustering software to ensure HA, you could use the Availability Groups (AG) feature built into SQL Server. The AG feature relies on WSFC to monitor the database processes running on the active instance of SQL Server. In the event that SQL Server becomes unresponsive, WSFC will orchestrate failover to a second instance of SQL Server running in a separate location. Services built into the AG feature ensure the synchronous replication of data between the active and secondary instances of SQL Server. If the secondary instance of SQL Server needs to take over after the failure of primary infrastructure, your BMS can be back online in seconds – with no loss of data.
SANless clustering vs. Availability Groups
While the SANless clustering and AG approaches to HA sound very similar, there are significant differences to be considered. First, the AG approach is only available if you are using Windows SQL Server – so, not viable if your BMS relies on any database other than SQL Server. Then, if your BMS stores any other important data on the same storage system – a repository of images or data streams from a video surveillance management system, for example – that data would not be replicated to secondary infrastructure in an AG-based HA configuration. The AG feature replicates only SQL Server databases (and only user-defined SQL databases at that). Finally, if your BMS relies on multiple SQL Server databases (or if you choose to replicate a single SQL database to multiple nodes), you’ll need to use the Always On AG services built into SQL Server Enterprise Edition, and that will be a costly upgrade if your BMS system doesn’t otherwise make use of the features of SQL Server EnterpriseEdition.
The SANless clustering approach, in contrast, is database agnostic. It provides high-performance block-level data replication services, so anything written to storage on the active node – whether that be an Oracle database or a cache of CCTV security videos – is automatically replicated to the secondary infrastructure. Moreover, because the SANless clustering approach takes no notice of what kind of data it is replicating, it imposes no limit upon the number of databases you can replicate and no limit on the number of secondary nodes you might choose to configure in your failover cluster. If your BMS relies on SQL Server Standard Edition and interacts with multiple SQL databases, you can use SANless clustering to replicate all those databases to the secondary infrastructure. To replicate multiple SQL databases in an AG-based approach to HA, you’d need to upgrade to SQL Server Enterprise edition.
Enabling HA for Linux-based environments
What if your BMS runs on Linux? The AG path to HA is not an option in the Linux world, as AGs are a feature of Microsoft SQL Server and depend on the Windows Server operating system. However, the SANless clustering path leads directly to the HA configuration that a BMS in the Linux world requires. The same SANless clustering tools that run on Windows also run on Linux, with added services for creating and managing an FCI in a Linux environment.
About the author
Todd Doane is a Solutions Architect at SIOS Technology with more than two decades of designing and implementing HA solutions. Todd has generated highly resilient reference architectures for telecommunications, financial and healthcare applications that have stood the test of time. His work has been implemented by Fortune 500 companies and government entities.
