# Architecture for Distributed Control Center **URL:** \ **Category:** Ignition\ **Created:** [February 1, 2024, 4:33pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104 "2024-02-01T16:33:26Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![akp](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@akp](https://forum.inductiveautomation.com/u/akp)\ **Post date:** [February 1, 2024, 4:33pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/1 "2024-02-01T16:33:26Z")
Hello All, What would be the best architecture to follow for a central control center with 6 regional control centers? All of these control centers need to have a backup control center. The complete system has 14 control centers in total. One option that came up was to put up a redundant pair of gateways in each of the regions. Would it be wise to have the primary server in one location and its redundant pair in another location? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 1, 2024, 6:06pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/2 "2024-02-01T18:06:19Z")
> [@akp](#): > > primary server in one location and its redundant pair in another location? Absolutely not. ---
**Author:** ![akp](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@akp](https://forum.inductiveautomation.com/u/akp)\ **Post date:** [February 1, 2024, 6:22pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/3 "2024-02-01T18:22:31Z")
What would be the best way to implement the live/warm backup control center, with another pair of redundant servers ? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 1, 2024, 6:27pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/4 "2024-02-01T18:27:47Z")
Do the servers in the alternate location need to be able to control remotely when **both** of the on-site servers are dead? If you can count on at least one of the local servers running, then you can simply use Remote Tag Providers and design projects that perform **parallel** control. (Distinct from **redundant**.) Perhaps you can describe your required functionality in more detail? ---
**Author:** ![akp](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@akp](https://forum.inductiveautomation.com/u/akp)\ **Post date:** [February 1, 2024, 7:35pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/5 "2024-02-01T19:35:42Z")
Certainly, the primary objective of establishing a backup control center is to maintain control over assets in the event of a disaster occurring at the main control center, such as a lack of access due to road collapse or in the event of a flood. All the assets/PLC have a redundant communication path to both these stations, the primary being a couple of FOC connections from different regions, with a failover to LTE (MPLS). The requirement, in essence, is to have a replica of the main site at the backup center. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/0/b0b56f4150df68a06f2b7838661c8d40e6f7dc6a.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 1, 2024, 8:13pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/6 "2024-02-01T20:13:41Z")
Parallel control. Not so much an Ignition redundancy setup. I'd make sure each site (which you probably want redundant **within** the site) has a uniquely named realtime tag provider (not "default"), so that remote tag providers pointing into each site from the multi-site control centers can use those names. Then the UI projects can be shared across sites. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [February 1, 2024, 8:36pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/7 "2024-02-01T20:36:19Z")
> [@pturmel](#): > > > [@akp](#): > > > > primary server in one location and its redundant pair in another location? > > Absolutely not. Phil, can you explain your answer? This architecture is quite common, especially for a lot of government projects I see. ---
**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\ **Post date:** [February 1, 2024, 8:42pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/8 "2024-02-01T20:42:15Z")
> [@Remote Backup Gateway](https://forum.inductiveautomation.com/t/remote-backup-gateway/77945): > > I am having a problem with the lack of physical diversity in my backup systems. I am currently running a Stratus Fault Tolerant server as a virtualization host, which turns out is a problem with updating the virtualization host or software. What I want to do, is run the Backup Ignition Gateway on different host at a high bandwidth connected remote location. When I discussed this with the initial Integrator and Inductive Automation, they both warned me against it, but they couldn't explicitly t… ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 1, 2024, 8:42pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/9 "2024-02-01T20:42:58Z")
Ignition redundancy is both latency sensitive and subject to split brain syndrome. If the comms goes down between sites, both servers will end up active and therefore numerous properties start to diverge. So let me amend my answer to: Ignition redundant servers must be installed on a common LAN with a robust network layout (preferably multi-path, like RTSP), such that any loss of comms also results in loss of comms to all clients and all devices and all databases. (Trunk port for multiple VLANs, or multiple trunk ports with RTSP and all VLANs on all ports.) ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [February 1, 2024, 8:53pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/10 "2024-02-01T20:53:31Z")
Thanks Phil, sorry I didn't read the OPs topic close enough (I just saw the word location). A location could be anything really, 2 feet away or 2 states away. The architectures I see are in different locations but close enough where they are connected via fiber. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 1, 2024, 9:02pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/11 "2024-02-01T21:02:47Z")
> [@jlandwerlen](#): > > The architectures I see are in different locations but close enough where they are connected via fiber. If that comms layout makes it possible for both servers to talk to various parts of the system while also **not** being able to talk to each other, the resulting system could be unreliable when needed. A dedicated fiber between two physically nearby locations can typically satisfy the criteria, and have reasonable latency. Anything going through the cloud or multiple service providers is unlikely to suffice. ---
**Author:** ![akp](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@akp](https://forum.inductiveautomation.com/u/akp)\ **Post date:** [February 2, 2024, 10:25am UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/12 "2024-02-02T10:25:01Z")
The backup locations are ~30 to 40 km away. The entire ~400 stations are connected with dedicated single-mode fiber connections. And there is LTE failover, just in case there is any switch failure or fiber break. There are no multiple service providers or cloud in the picture. So as I understand the best way to do this would be to have two pairs of GW, one at the main and another at the backup, and the GW with Modbus Client, polling all the PLCs (Modbus Masters). Thanks Phil! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 2, 2024, 3:11pm UTC](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/13 "2024-02-02T15:11:49Z")
If you expect the on-site redundant gateways to be functional, just without humans available, you don't really need more gateways elsewhere. You just need a robust set of network paths to open clients on those gateways from the remote control centers. I would not poll **any** modbus devices remotely. Or any other ordinary PLC protocol. An external set of gateways for **convenience** working with many sites is advisable, but would not need to themselves be redundant. You should get IA sales engineering involved to fine tune your plan based on your actual requirements.