D2000 Architecture Examples

In today's blog, I would like to present several possible architectures for deploying the Ipesoft D2000 application server.

Given the flexibility and the possibility of running individual D2000 processes on remote computers, the list will certainly be incomplete - but I will try to describe the most common configurations.

I will start with the simplest. All processes - system core (Kernel), communication process (Kom), archiving process (Archiv) and others (Event, Calc, DbManager, ...) are run on a single computer. This computer also runs a database server (configuration, monitoring, archive database). If an application database is used, it can also be local. The system has no redundancy.

Today, most applications require redundancy (a separate blog), which can ensure uninterrupted operation not only if a problem occurs with the D2000, but especially when applying updates (firmware, OS, databases, D2000), which is now a natural part of taking care of application servers. To put it simply, in a redundant system, the active component works (collects data, runs scripts) and the passive one (or multiple, since D2000 also supports redundancy of multiple servers) does nothing. However, this is a gross simplification, because, for example, the calculation process ([Calc]) calculates even when it is passive. All values ​​are distributed from the active Kernel process to the passive Kernel processes (and from there to the connected processes that need them).

A special case is the Archiv process. In redundant systems, it is configured similarly to user processes ([Hi], [Cnf]) to connect to the active Kernel (using the /RD or /RF startup parameters), with multiple archive processes running as instances (e.g., instances 1 and 2 of the SELF.ARC process). This allows for redundancy of the Archive process and possibly switching the active/passive instance as needed, without the need to switch the application server redundancy. What is the difference between an active and passive Archiv instance? Both archive data of the same historical tags (each to its own database), but the active instance provides the data to users or scripts that need it.

In the past, architecture with dedicated archive servers was used for larger applications. With today's hardware capabilities, it is no longer a problem to use virtual servers with sufficient CPU, memory and disk space to be able to run D2000 processes together with the Archiv and the archive database (usually on the PostgreSQL platform).

D2000 is sometimes also used in triple redundancy. Usually it is a redundancy + disaster recovery configuration, when two servers are at the main site and the third is at the backup site. This makes sense if the subject of control is a geographically distributed system (e.g. several power plants or a transit gas pipeline), or if it is an MES system with high availability. In this case, all the facts mentioned for a redundant system with two nodes also apply, except that the Archive process will exist in three instances.

It is also possible to create multi-node redundancy, but in practice 3 nodes are enough. I have only seen a four-node redundancy configuration at a customer site for a short time - during the migration of a two-node redundancy to new two nodes (even located in a different network). And at another customer, even six-node redundancy ran for almost half a year - as you can guess, it was also a migration, this time migrating a three-node system to new servers, which were also located on different networks.

Another option is to push selected processes to a demilitarized zone - i.e. to a server that is in a network with a lower level of security, which is separated from the D2000 network by a firewall. Examples of use:

• DbManager process accessing external databases.
• Event process downloading and processing data from the web or from external partners.
• Kom process publishing data to external systems.
• SAS process (Security Access Server), through which external D2000 clients connect.
• OPC and OPC UA servers to which external OPC and OPC UA clients connect.

For such clients, it is possible to configure a so-called reverse connection, where the Kernel process connects to a defined TCP port and IP address (instead of the client process connecting to the Kernel). This ensures that if the server in the DMZ is attacked, it will not be possible to attack the D2000 server from there.

Figure 4 shows a non-redundant system, but we use redundant architectures with DMZ in a similar way. Servers and processes in the demilitarized zone can also be redundant – DbManager, Event, Kom configured as instanced (similar to Archive processes), SAS OPC and OPC UA servers as non-instanced (with all of them being active). Clients (user processes such as HI) connect with the /RF parameter to the redundancy defined as the IP addresses of the servers on which the SAS processes are running. Similarly, in the configuration of OPC and OPC UA clients, it is possible to specify all IP addresses on which OPC and OPC UA servers are running.

A similar case (but in meaning opposite) that is used in practice is a remote communication process, which is located on the contrary in a network with a higher level of security than D2000 (as a rule, this is a technological network). In this case, of course, the reverse connection is not used, since the Kom process in question is in a more secure network and therefore it is logical that it connects to a less secure network. Again, the note that the D2000 system can also be redundant applies.

Another reason for moving the Kom process to the technological network is the possibility of using the KOM Archive technology. This is the ability of the Kom process to locally store the values ​​of the I/O tags obtained from the communication if the connection to the D2000 Kernel is lost, and send them after the connection is restored. This way, it is possible to eliminate data outages caused by network problems.

And the last reason may be OPC communication. For this, it is safer and easier to configure firewalls to place the Kom process directly on the computer with the OPC server and allow the Kom process access to a single TCP port (3119) of the computer running the Kernel, than to open all ports needed for remote Windows communication, or to install and configure third-party software like OPC Tunneler.

This year we migrated the existing SCADA system, while its architecture was also changing. For logistical reasons, redundant application servers were moved to two geographically distributed server rooms, while the communication processes remained in the technological network on two redundant communication computers (these were industrial PCs with passive cooling, mounted on a DIN rail). There were several communication processes in the system, which were configured as instances 1 and 2, which connect to the active D2000 server, as shown in the following figure:

This design is resilient to the simultaneous failure of a single application server and a single communication server. Furthermore, instances 1 and 2 of multiple communication processes (labeled KomA, KomB, and KomC in the figure) can be switched independently, so that active instances can be distributed across both ServerKom1 and ServerKom2, thereby distributing the load across both communication servers.

One “upstream” communication channel, to the MES system, remained directly on the application server—so a communication process was also running there.

Of course, all of the above designs are models. In practice, the design is adapted to the needs of a specific customer. So, for example, it is possible to have a 2-node application with a redundant SAS server in a demilitarized zone, with five communication servers (non-redundant) located in technological networks and another communication process on a dedicated server, which is used to communicate with an external partner.

How do we design a server for the application database?

By application database, I mean a general SQL database, which is used in larger and more complex SCADA systems and practically in all MES and EMS systems. The structure is managed by the application programmer, and the DbManager process is used to access this database. This database may also be an EDA database—more info in a separate blog post on database types.

In the simplest case, the application database can be located directly on the server, but it usually has its own dedicated server. It can be Windows or Linux; today, Linux solutions are preferred for reliability and performance.

If we want to make the database redundant, we typically use a 2-node Linux cluster (Corosync/Pacemaker), in which the data is mirrored on both nodes (using DRBD) and the database server runs on one of the nodes. Clients access it via a virtual IP address, which is also shared within the cluster (so both servers must be on the same network segment). This solution is suitable if both servers are in the same location (so the network latency between them is minimal). More information about this architecture and its monitoring is available in a separate blog post.

If the servers are located in two different sites, we use master-slave replication (typically asynchronous, so that a failure at the backup site does not halt production). In this case, manual switching between the master and slave database servers is required. Therefore, when the D2000 redundancy switches between locations, the database servers must be manually reconfigured.

If we have a 3-node D2000 architecture (two nodes at the primary site, one at the secondary site), we typically use the same level of redundancy for the application database as well. At the primary site, we create a database cluster that is asynchronously replicated to the secondary site:

Conclusion

In this blog post, I wanted to demonstrate some basic and commonly used architectures of systems built using the Ipesoft D2000 application server. In reality, system architecture evolves over time—often a system is initially built as non-redundant, and as it grows and expands, its importance increases, and users begin to consider adding redundancy (redundant archives, application servers, databases...).

The good news is that such modifications generally do not require changes to the application logic—perhaps only expanding diagnostics and visualizing the system architecture in diagrams so that the functionality of currently inactive redundancy components can also be monitored.

June 8, 2026, Ing. Peter Humaj, www.ipesoft.com