...
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 (in dimensions of TB unitsstoring 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.
...
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, more rarely less frequently for SCADA systems.
In this environment, resources are shared, resulting in two basic sharing 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:
...
- RAM - allocation of a sufficient amount of memory. It is ideal to reserve memory in a virtual environment , so that memory is not shared between virtual machines (so-called ballooning).
Small D2000 applications need roughly 1 GB of RAM (the minimum for an application server on Windows/Linux is 4-8 GB), and large ones need several GB to tens of GB, depending on the number of configured objects, processes, and users. If more memory is available, we recommend allocating it to the SQL database for the archive (we recommend PostgreSQL) and the archive cache (we recommend several GB for the so-called isochronous cache). Applications using EDA technology (Energy Databank) benefit from several GB of memory allocated to the EDA server. - CPU - the usage of CPU strongly depends on the nature of the application (constant CPU consumption for SCADA-type applications, significant peaks for balance systems or systems where user-triggered events take place - e.g. preparation of documents for monthly invoicing). In the case of physical servers, today's processors have enough necessary performance. In a virtualized environment, we encountered a case where VMware administrators artificially limited the maximum usable frequency for the balance system, because they thought it "consumed too much CPU". First, they caused significant user dissatisfaction (the preparation of invoicing documents took several hours instead of 30 minutes several hours) and, on the one hand, the analysis showed that a significant part of the performance was consumed by the antivirus (ESET NOD) , since it did not have configured exceptions.
For large applications, it is advisable to allocate more vCPUs (4-8-16) - the D2000 architecture allows good parallelization (parallel tasks within the D2000 Kernel, D2000 Event, and D2000 Archive processes [configurable]). - Disk space:
- for the partition with the OS, we recommend approx. 20 GB (Linux) or 100 GB (Windows)
- for the partition with D2000, we recommend at least 40 GB for the start, while the archive database usually has the largest consumption - several GB to several TB (for SELT systems, the monitoring database - up to tens of GB)
- if depository databases are enabled in the D2000 Archive (storage of historical data with unlimited depth), we recommend a separate partition for the depository databases (the size of the depository databases will gradually grow on it). Currently, there are customers with more than 20 TB depository databases, but newer versions of the D2000 allow you to turn on depository data compression, which usually has a compression ratio of 1:10 and better, which significantly saves disk space.
For the partition with the OS and D2000, we recommend fast disks (SSD), for the partition with safesdepositories, slower HDDs or NAS are also sufficient.
...
- graphs of the CPU load of D2000 servers, other virtual servers within the guesthost, and the total CPU load of the guests host (to diagnose if there is a lack of CPU power)
- graphs of RAM consumption (proof that there is no ballooning - memory sharing between servers when there is a lack of RAM and subsequent swapping)
- graphs of I/O subsystem load (metrics: reads/writes per second, read/write data amounts [kB/s], read/write latencies) - again, for D2000 servers, other virtual servers within the guest, and if the storage in question is shared then a load of all hosts using disk storage (to diagnose whether there is a lack of I/O performance). Some shared storages provide their own load diagnostics from individual guests that can be used (LeftHand, 3PAR).
...
In a virtualized environment, not only both the speed but also the and latency of the disks is 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.
...
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 reset configure exceptions so that antiviruses do not overload the CPU and slow down the functionality of D2000 systems.
...
- Resource monitor (available from Task Manager) - display displays statistics about CPU, memory consumption, disk operations, and network usage
On the Linux platform:
...