The best thing about the Scale Out Architecture is that it is easy to scale up Ignition as your system grows. In the image below, we added more front-end Gateways to help handle an increase in clients, and a Load Balancer to automatically distribute the clients between them.
Launching clients behind a load balancer works as of 7.9.15, but the projects on each Gateway MUST have identical UUIDs, meaning that all visualization gateways must be restored from the same Gateway backup (GWBK), as project imports won't work.
When utilizing Scale Out, an Ignition Gateway is given focus due to it's placement. There are two possible types:
- Tags & I/O: Also known as a Back-End Gateway, is responsible for communicating with the PLCs, and executing Tags. They share their local Tags with the Front-End Gateways via a Remote Tag Provider, and are generally responsible for recording history. Additionally, alarms can be added to Tags locally, and exposed elsewhere in the system.
- Front-End Gateway: Sometimes called a Visualization Gateway, this Gateway is responsible for hosting the clients, allowing the Back-End Gateways to focus solely on PLC communication and history.
With this type of architecture, both types of Gateways will need database access: the Tag & I/O Gateways need to be able to store data, while the Front-End Gateways need to query the data out.
Scaling Out the Databases
Multiple on-site databases may also be utilized with this architecture. This typically involves configuring a database cluster.
Why Use the Scale Out Architecture?
Scale Out is utilized in large systems to distribute the workload across multiple servers. This is in contrast to a 'Scale Up' ideology where you have a single powerful server manage the whole system.
In this architecture, each server only deals with a small part of the overall system. Should a server fault, only that part of the system is hindered, allowing other parts in organization to continue uninterrupted. Applying Redundancy to the the Tag & I/O servers is ideal to maximize uptime.
Pooled Resource Usage
Since multiple servers are working together bottlenecks are reduced. A massive amount of work can be performed in this system without slowing down other servers.
Improving performance in this architecture is simple: add another Gateway where appropriate. Because the system is spread out on purpose, it's easy to determine which kind of Gateway to add. A Back-End Gateway would help if you're adding new PLCs, and a Front-End Gateway will help when more clients need to be active at a time.