Distributed Systems
The distributed system configuration allows interconnecting several projects that run independently, either on one or several physical machines. The interconnection of the projects allows transparent engineering and operation through them seeing them as one only system. The distributed system configurations extends even further the support of very large systems, increase robustness eliminating single point of failures and allow geographical or discipline segregation.
Depending on the distribution connection (visibility of other projects), a distributed system’s configuration in Desigo CC can be one of the following types.
A combination of these two types is also supported. These types of distributed systems can be deployed on both physical and virtual server computers.
Fully Meshed Distributed System
This is a configuration choice where a single system image providing features equivalent that of the large scale system needs to be obtained.
In this configuration, each server is logically connected to all other servers in distribution. Servers can be geographically distributed. Virtual servers are also supported. Clients (Installed Client, Windows App Client, if web server (IIS) is installed) can access data from all the systems in distribution.
Even if one of the systems in distribution becomes unavailable, all other systems in distribution can still work with each other using the Global user.
Depending on whether the systems (projects) in distribution are located and running on the same single server or on separate servers, there are two types of Fully Meshed Distributed Systems:
You can set up a Fully Meshed Distributed System having multiple systems (projects) hosted on separate server computers and connected on the same network.
Fully meshed configurations are typically deployed on different physical (or virtual) machines, each running one project.
The projects, to be configured in this type of distributed system, are on different servers and secured.
The SQL Server can be on each server with the history database linked to a project on that server. You can also have a remote SQL Server with an SQL instance having multiple HDBs, each linked to a project on a separate server.
In both the cases, to view the global data, for example, global reports and so on, you must link the HDBs on different servers. (See Link HDBs on different SQL Servers in Additional Procedures for Configuring Projects in Distribution in Setting up the Distributed System.)
When logging onto the Installed Client or Windows App Client for any of the system using the Global user, you can work with the linked distributed systems.
You may also log onto the Desigo CC client of a linked FEP connected to one of the distributed systems and work with the other linked distributed systems.
Deployment Diagram
You can set up a Fully Meshed Distributed System having multiple Local Systems (projects) hosted on a single server computer.
The projects in distribution on the same server can have different security configurations. For example, you can set the Stand-alone project in distribution with a Secured project and so on. When you want to use a local Desigo CC client for accessing the projects in distribution, it is recommended to configure the stand-alone projects in distribution. However, if you have an FEP on a remote server linked to one of the projects, you must configure the projects with secured communication in distribution.
In the Fully Meshed Distributed Systems on a single server, the SQL Server is usually on the same server as that of the projects. Typically, the SQL Server can have one SQL instance with multiple HDBs, where each HDB is linked to one project.
When you log onto the installed client or Windows App client of any of the Local System (project) using the Global user, you can work with the other linked distributed systems. You may also log onto the client of a linked FEP connected to one of the distributed systems and work with the other linked distributed systems.
Important Characteristics:
- All Local Systems (projects) are running on the single server. Therefore, when the server is down, all the connected Local Systems are also down. Therefore, all field devices connected to the server that is down, is not available from any Local System in distribution.
- This deployment is helpful where the distribution of the servers is not possible or useful, and you must overcome the size limitation of a single system.
Deployment Diagram
Hierarchical Distributed System
This is a configuration choice where some servers (Supervised systems) need to be connected to one head server (Supervising system). Thus the Supervising System has visibility of its own system, in addition to all the Supervised Systems.
Clients connected to the Supervising system can see all objects where as clients connected to supervised systems can only see local objects.
If the Supervising system becomes unavailable, you can still work with all the Supervised systems in distribution by using the Global user.
Compared to the Fully Meshed Distributed Systems, the Hierarchical Distributed System allows more systems.
If one of the Supervised systems is down, it does not affect the distribution. The Supervising system and the other Supervised systems can still continue to work in distribution.
Typically you configure the Hierarchical Distributed Systems on separate Servers. However, you can also setup a Hierarchical distributed system where the multiple Local Systems are hosted on a single powerful Server computer.
When you set the systems (projects) in on a single Server in the Hierarchical distribution, the projects can have different Security configurations. For example, you can set the Stand–alone project in distribution with Secured project. When you use a local Desigo CC client for accessing the projects in distribution, it is recommended to configure the Standalone projects in distribution. However, if you have an FEP on a remote server linked to one of the projects you must configure the projects with secured communication in distribution.
The SQL Server is typically on the same Server as that of the projects. The SQL Server typically has one SQL instance with multiple HDBs, where each HDB is linked to one project.
Using the Global User, when you log onto the installed client or Windows App client of the Supervising Local System, you can work with all the linked Supervised systems on that Server. However, when you log onto the installed client connected to one of the Supervised Local System, you can only work with the Local system. You can neither see the data of the Supervising Local system nor of any sibling Supervised Local System.
All Local Systems (projects) are running on the single server. Thus, when the server is down all the connected Local Systems are also down. Thus all field devices connected to the server which is down will be not reachable from any Local System in distribution.
Deployment Diagram
Hierarchical distributed systems are typically deployed on different physical (or virtual) computers, each running at least one project. Therefore, you can set up a Hierarchical distributed system that has multiple systems hosted on separate server computers connected on the same network.
The projects to be configured in such a distributed system are on different servers and secured.
The SQL Server can be on each server with an HDB linked to a project on that server. Alternatively, you can have a remote SQL Server with an SQL instance having multiple HDBs, each linked to a project on a separate server. In both the cases, to see the global data, for example, global reports and so on, you must link the HDBs on different servers. (See Link HDBs on different SQL Servers in Additional Procedures for Configuring Projects in Distribution in Setting up the Distributed System.)
In such a configuration, when you log onto the Installed Client (or Windows App Client) of the Supervising System, you can work with the linked Supervised Systems located on the different servers.
However, when you log onto the installed client connected to one of the Supervised System, you can only work with that Local System. You can neither see the data of the Supervising System nor of any of the sibling Supervised System on other servers.
Deployment Diagram
NOTE:
In the distributed systems, disconnecting a system (for example, as a result of stopping the project) is specified as an event in all the systems in distribution.
Upon disconnection, all objects belonging to a disconnected system become unavailable for selection.
Once the system is reconnected, you can fully treat the event generated during disconnection and the Local System is realigned as part of the distributed system.
