The Ipesoft D2000 real-time application server can be used for a whole range of applications - from small SCADA systems (built on the Raspberry PI platform or on industrial computers with OS Windows/Linux) to large MES/EMS type systems with dozens of users, large application databases (storing terabytes of data), multi-terabyte archives and depository databases. In this chapter, we will try to summarize some best practices for designing and managing D2000 systems.

Virtualization

Today, the D2000 application server is often also operated in a virtualized environment (VMware, Hyper-V, Proxmox), especially for systems such as MES, EMS, SELT, and balance systems, less frequently for SCADA systems.
In this environment, resources are shared, resulting in two basic sharing problems:

The "hyper-converged architecture", in which we use powerful servers with local disks (in a RAID10 or RAID50 disk array), has proven to be successful. It is ideal when the virtualized D2000 applications have their own servers (which are not shared with other applications) and when the administrators of the D2000 applications not only have administrative rights to the virtual machines on which the D2000 is running but also have access to the virtualization environment so that they can perform operational performance diagnostics in case of problems.

In the case of several administrators (e.g. for network infrastructure and firewalls, virtualization, Active Directory, and application servers), we recommend the introduction of an operation log in which all operations that could affect the functionality of the servers will be recorded, in particular:

The subsequent analysis (usually if there is a slowdown and reduction in performance) is greatly facilitated by the existence of the operation log. To share the log, you can use e.g. SVN or GIT repository, SharePoint repository, and the like.

Allocation of sufficient resources in a virtualized environment

The resources that the D2000 primarily needs are three: memory (RAM), CPU, and disk space (we haven't experienced any problems with bandwidth limits on network interfaces yet). We recommend:

For the partition with the OS and D2000, we recommend fast disks (SSD), for the partition with depositories, slower HDDs or NAS are also sufficient.

Monitoring and diagnostics in a virtualized environment

In a virtualized environment, it is essential to have access to monitor operational parameters to ensure that the D2000 application does not suffer from resource sharing. We recommend that environment administrators monitor and be able to provide the following data (according to the graphs available in vCentre):

We recommend having all these graphs and data for them available for at least 3 months, for long-term performance monitoring.

In a virtualized environment, both the speed and latency of the disks are important for the D2000 Archive. It should be noted that when archiving, hundreds and thousands of database tables for individual archive objects are written in parallel.
Note: for older D2000 installations, we recommend increasing the PostgreSQL ODBC parameter BatchSize (starting with PostgreSQL ODBC version 12.02) from the default value of 100 to 10000 - the change can speed up interval calculations (RECALC) and the INSERTARCHARR action.

Antiviruses

In the case of using antivirus and antimalware programs (Microsoft Defender, ESET Nod, Symantec, and others, on the Linux platform e.g. McAfee 'OAS Manager'), it is necessary to correctly configure exceptions so that antiviruses do not overload the CPU and slow down the functionality of D2000 systems.

Directory exceptions: by default, we recommend adding directories with D2000 and databases for D2000, e.g. on the Windows platform:

Note: In the case of ESET antiviruses, it is necessary to add not only directory names to Performance exclusions, but also all files (i.e. "\*" is required after the directory name, e.g. D:\D2000\* ). We recommend adding files from the D2000 installation (e.g. D:\D2000\D2000_EXE\bin64\* ) and PostgreSQL (e.g. C:\Program Files\Postgresql\15\bin\* ) to Detection exclusions.

On the Linux platform:

Exceptions for programs in memory - so that antiviruses do not try to analyze communication (external - D2000 KOM, between processes - D2000 Kernel, with databases - D2000 DbManager). We recommend adding exceptions to the D2000 processes that consume the most CPU, by default they are:

Note: Microsoft Defender documentation recommends entering the full path to the process (e.g. d:\D2000\D2000_EXE\bin\kernel.exe) in the exception to prevent malware from using the same file name and thus avoiding detection.

On the Linux platform:

In the case of some antiviruses (Microsoft Defender), it is advisable to monitor the total CPU consumption of the antivirus (msmpeng.exe) in the Task Manager. If it is high, exceptions are insufficient (and exceptions should be set for other processes, usually those that also have high CPU consumption). Other antiviruses (ESET NOD) work "undercover" and consume the CPU in the context of running processes - Task Manager thus shows e.g. high CPU consumption for postgres.exe.

There are also negative experiences with the program xagt.exe (FireEye Endpoint Security), which (probably due to missing exceptions) consumed quite a lot of CPU power (4 out of 16 available CPUs) and disabled several real-time communications (IEC 870-5-101 and IEC 870-5-104 protocols).

Useful diagnostic tools

On the Windows platform:

On the Linux platform: