System sizing guidelines

The following table provides guidelines for System Platform hardware configurations, based on application size. These guidelines are subject to the limitations of your Windows operating system, and if applicable, to the SQL Server edition (Express, Standard, or Enterprise). See the Technology Matrix on the AVEVA Knowledge and Support Center website (https://softwaresupport.aveva.com/) for supported versions of Windows operating systems and SQL Server.

• An HD display is recommended for engineering tools such as the System Platform IDE.

• A 64-bit operating system is required, regardless of system size.

• A Windows Server operating system is required for large installations.

• SQL Server Express is supported only for small systems, that is, installations with less than 25,000 I/O per node.

• Pagefile.sys, the Windows paging file (also called the swap file or virtual memory file), must be enabled. The Windows default setting is enabled.

To access the relevant information from the Technology Matrix, go to the Knowledge and Support Center website, select the Technology Matrix icon, and then enter the name of the System Platform product (for example, Application Server or Historian), or enter the Windows or SQL Server version you wish to use (for example, SQL Server 2022 Standard x64).

Definitions

In the table below, hardware guidelines for different types of System Platform are listed. Definitions for the terminology used in the table are:

Level (minimum and recommended)

Minimum level describes the baseline hardware configuration that will provide at least minimally acceptable performance for the role. Recommended level describes an expanded hardware set that provides improved performance.

IDE node

Integrated Development Environment (IDE) nodes are engineering workstations. These are used for creating, editing, and deploying objects.

Application Object server node

Application Object Server nodes, also called AOS nodes, are remote runtime nodes. AppEngines, and the objects assigned to them, are deployed from the Galaxy Repository to AOS nodes, where the AppEngines run on the AOS WinPlatform object. Each active AppEngine requires one logical processor and runs as a 32-bit process. We recommend that each AppEngine in a redundant pair is also assigned one logical processor (one for active and one for standby). If redundant AppEngines consume less than 40% of CPU and memory resources, you can allocate one active and one standby AppEngine to a single logical processor. However, if the AppEngines exceed 40% of the computing resources, you run the risk of over-leveraging the node (such as when CPU and/or memory usage hits 100%) when a failover occurs.

AOS resource allocation

Areas are assigned to AppEngines, and objects are assigned to areas. The total number of objects that can be assigned to a single AppEngine is very variable, and depends on the complexity of the objects, including the number of attributes, attribute datatypes, if the object is running scripts, script complexity, and if the object contains graphics (owned graphics will take more memory than linked graphics). In most system configurations, an AppEngine can host anywhere from 5,000 to 50,000 objects, but even this broad range does not cover non-typical configurations, depending on the factors just mentioned (such as attributes, datatypes, and owned graphics). For example, a single object attribute of datatype BigString can, conceivably, consume 2 GB of memory. All of the areas and objects under them that are assigned to an AppEngine cannot require more than 2 to 3 GB of total memory. Do not forget to take into account CPU, memory, and disk requirements for running Windows when provisioning the AOS nodes. Device Integration objects also run on the AppEngine and consume resources.

AOS deployment performance

When you deploy a galaxy, the GR node is deployed first. After the GR, remote AOS platforms are deployed. Deployment of AppEngines to the AOS platforms is done in parallel. The AppEngines, along with the areas and the objects they contain are deployed serially. Thus, deployment is much quicker if you use multiple AOS nodes, each hosting fewer AppEngines, rather than using a single AOS node to host, for example, 30 active AppEngines. The improvement in deployment performance that you gain by using multiple nodes is nearly linear. Using two AOS nodes instead of one can reduce deployment time by half, using four AOS nodes reduces the time to a quarter, eight nodes reduces the time to an eighth. Once the AppEngines are deployed, deployment of areas and their contained objects to each AppEngine occurs serially. Thus, deployment is much more efficient if you use multiple, AOS nodes that are provisioned with fewer hardware resources, rather than using a few, highly-resourced nodes.

Galaxy Repository node

Galaxy Repository nodes, also called GR nodes, host the galaxy database. The GR is tightly coupled to a Microsoft SQL Server database.

Historian Server node

Historian Server nodes host the AVEVA Historian. The Historian is tightly coupled to a Microsoft SQL Server database.

Thin client

Thin clients include include smart phones and tablets. In the context of System Platform, thin clients are platforms for web browsers and remote desktop sessions (for example, InTouch Access Anywhere clients).

Client

In the context of System Platform, clients are computers that can be used to develop and/or view and interact with applications. Remote IDE workstations, as well as for run-time applications like WindowViewer, AVEVA OMI ViewApps, and Historian Insight can be System Platform clients.

The following guidelines are provided for reference only. The system configuration required for your application will depend on multiple factors, including but not limited to the size and complexity of the application, and the features and components used.

1) To calculate the number of logical processors: multiply the number of physical cores by the number of threads each core can run. A four core CPU that runs two threads per core provides eight logical processors. The terms Hyper-Threading and simultaneous multithreading (SMT) are also used to describe logical processors.
2) SSD drives are highly recommended.
3) In redundant environments, increase CPU and RAM to maintain a maximum of 40% typical resource utilization.
4) For optimal performance of all-in-one nodes, a high clock speed (>2.8 GHz) is recommended.
5) You can deploy two AppEngines (one active and one standby) per logical processor provided that the CPU and memory load is less than 40% for each AppEngine.
6) Using multiple Application Object Server platform nodes reduces deployment time.
7) For large applications on all-in-one nodes, dual XEON processors are recommended.