High Availability Ignition Architectures Part 1 – Mitigating Server Failures

Inductive Automation’s Ignition software is a SCADA platform which has grown in market share over the years. Most folks are familiar with Ignition’s server-based architecture and the benefits of the unlimited platform when it comes to tags, connections, and clients. The fact that Ignition is server-based adds inherent risks which many find troubling. Inductive has addressed this by creating a platform that has a plethora of options to mitigate these risks. This is the first of a two-part blog post to help demystify designing Ignition architecture to address risks to server and network infrastructure.

The Risk of a Server-based SCADA System

Over the past 10 years OT networks have been setup at manufacturing sites and reliability is typically very high. As the confidence in the robustness of these networks have grown, the concept of running your entire plant on a server-based SCADA system has become more accepted; however, server-based architectures still add the risk of loss of operational visibility and data integrity for the equipment on the plant floor.

These risks have classically been addressed by adding an HMI locally to the equipment. Ignition offers an affordable product called Ignition Edge Panel which provides for this functionality. While Ignition Edge Panel mimics the functionality of other HMIs in the market, it does not provide all the features Ignition users have become accustomed to all the benefits that a full-blown Ignition SCADA system provides. The following features are typical in SCADA systems that NeoMatrix designs:

• Visualization and control of the equipment;
• Logging alarms and historical process data;
• Logging transactional data such as audit trails, work order transactions, etc; and
• SQL based recipes.

There are two main risks to a server-based architecture – server failure and network failure. This blog post will focus on risks to server failures. A subsequent post will detail the options on mitigating risks to the server network.

Mitigating the Risk of Server Failure in Ignition Architecture

The two methods to address a server failure in an Ignition architecture is with fault-tolerant hardware and redundant software. For mission critical systems we recommend both approaches.

Most companies today deploy a fault tolerant virtualized infrastructure. This technology provides the ability for continuous operation in the event that a primary server fails by failing over to a hot backup. If your server infrastructure isn’t fault tolerant. The process is extremely simple – install Ignition on a second server and configure it as a backup gateway to the primary – the process takes less than 5 minutes.

Whether or not your server infrastructure is fault tolerant – there are still benefits to having Ignition in a redundant configuration. Everyone is aware of the risks of cyber security events and as such companies are employing strict patching policies. OS patches often require server reboots to properly deploy which will temporarily shut down your server. Utilizing redundant Ignition gateways, you can allow your IT department to patch your servers on a regular basis without impact to production.

In addition to patches, redundant gateways also offer the ability to perform software upgrades to Ignition with no impact to production as well. This technote from Inductive Automation outlines this process.

Part 2 of this blog post will get into depth with dealing with network failures and the complexity of architecting an ‘Edge’ solution which addresses risk tolerance based on SCADA functionality.

Stay Tuned.