Sage X3 V12 server components hosting – Recommendations
Hardware generic recommendations
Below are generic recommendations on hardware to achieve adequate performance.
CPU considerations
Intel® CPUs
Whether Sage X3 V12 is hosted in physical servers or virtualized, underlying hardware should leverage recent processor generations (Intel® Xeon® E5 v4 or later, E7 v4 or later).
Sage recommends using the latest (third generation) or previous generation (second and first) Intel® Xeon® Scalable Processors, Gold or Platinum variants
AMD™ CPUs
Opteron™ processors, that are optimized for floating point, are slower than equivalent Intel® Xeon® processors for most Sage X3 computations that are performed with BCD integers (to avoid floating-point precision loss) and should not be used at all.
EPYC™ gen.1 (7001 series) are behind equivalent Intel® Xeon® CPUs of the same generation. Their use is discouraged.
EPYC™ gen.2 (7002 series) can be used. Its performance is similar to equivalent Intel® Xeon® Scalable processors.
Processor clock frequency
High CPU clock speed gives higher application throughput for single operations and high CPU core count gives a best overall resilience with multi-user workloads.
Since having both at the same time implies expensive processors, you might have to balance a high number of cores vs a high clock speed.
Avoid low-energy consumption processors with low clock frequency (Xeon® L models). These will give poor results. Use CPUs running at 2.4 GHz or higher to get good performances.
For heavy single-threaded loads, consider using a processor with a 2.8 GHz or higher base clock speed.
Memory considerations
Memory bus speed should be as fast as possible as Sage X3 architecture uses a small amount of memory bandwidth.
Please note that on certain motherboard generations/chipsets, the real memory bus bandwidth decreases with the number of memory sticks (and chips) installed.
In such cases, the memory bus speed is slower when used for a total memory composed of a high number of small capacity memory sticks (leveraging small memory chips). It is better to use a small number of high capacity memory sticks (leveraging big memory chips). Even though this recommended configuration is usually more expensive.
Please consult the technical documentation of your server’s vendor before choosing between possible options of components configuration for RAM.
Network considerations
Networking between RDBMS server(s) and runtime/application
Sage X3 is a highly interactive product with a lot of communications between the application tier and the database tier.
To get the best performance and user experience, you should ensure that the network latency between database and application tiers is as low as possible.
When RDBMS and application/runtime tiers are not hosted in the same server, this is achieved by using 10 Gbit/s high quality networking equipment and paying attention to the whole networking stack (network adapters drivers, network switches firmware, virtual NIC types, and so on)
Networking between runtime/application and Sage X3 Syracuse server
There is less exigence on this network path, so when the database and application are hosted in the same server (so you don’t have a physical network path between RDBMS and Runtime), you can use 1 Gbit/s network equipment.
Storage considerations
Oracle or SQL Server database storage
Storage quality is paramount for database performance.
You should use a storage configuration giving high IOPS performance for volumes hosting databases datafiles, whether it’s Oracle (system tablespaces, redo logs, data and indexes tablespaces) or SQL Server (TempDB datafiles, log, data and indexes filegroups).
This is achieved by using SSD storage (with RAID-10, RAID-1, RAID-5 or RAID-6 redundancy), or if you cannot use SSD, by using the best spinning disks in the optimal performance RAID configuration, that is a high number of 15krpm disk drives with RAID-10 redundancy.
A high number of small disk drives is better than a few bigger drives, as the IOPS capability is given by the number of drives in a RAID array, not by their sizes.
7.2krpm drives and/or RAID-5 or RAID-6 redundancy should never be used for hosting a production database.
Sage X3 application storage
Sage X3 application storage does not require as many IOPS as database storage.
In your Sage X3 application, components can reside on a storage tier providing moderate IOPS, like 10krpm disk drives with RAID-5 or RAID-6 redundancy.
7.2krpm drives are not recommended as they might impair performance in technical operations like patch integration, folders creation, and so on.
MongoDB data storage
Unless you plan to use MongoDB for intensively storing Sage X3 attachments, IOPS needs are moderate.
You can then use the same kind of storage configuration as for Sage X3 application.
7.2krpm drives are not recommended as they might slow down operations when there is high concurrency on MongoDB access, for instance when there are many user logs Sage X3 within a short amount of time.
Elasticsearch data storage
If you plan to make a massive use of Elasticsearch indexing, you can consider using a performing storage tier for hosting Elasticsearch data.
SSD might be too much, using 10krpm drives in RAID-10 gives adequate performance to users’ search queries, and to Elasticsearch indexes updates.
Other Sage X3 components storage
Other Sage components are mostly static data, with little disk access and don’t require high-end storage. 10krpm disks in RAID-5 or RAID-6 are enough.
7.2krpm drives might impair technical operations like components updating.
Virtualization considerations
You can deploy the solution on physical servers or in a virtual environment like VMware vSphere, Hyper-V, RedHat KVM, Citrix XenServer or Oracle VM.
Most Sage X3 components below can be deployed on virtual machines:
- Application and main process server(s)
- Additional process server(s)
- MongoDB server(s)
- Elasticsearch server(s)
- Syracuse web server(s)
- Print server(s)
- ADC server(s)
If you decide to virtualize your architecture, you must build a physical infrastructure adapted to a virtual environment for optimum performance. SAGE recommends dedicated resources assigned to your Sage X3 environment, rather than sharing resources.
A production virtualization architecture is usually built with multiple physical hosts and relies on a shared storage system (SAN) providing high availability and adequate performance to cope with the I/O and throughput needs of all hosted VMs and applications.
Apart from development / test or small production environments, it is NOT RECOMMENDED to run the RDBMS (SQL Server or Oracle) in a virtualized environment.
However, if you decide to run RDBMS in a virtual machine, you must take all precautions to ensure this virtual machine is able to run at full throttle any time, and not suffer from bottlenecks on CPU, memory or storage I/Os due to resource overprovisioning in the virtualization platform.
CPU bottlenecks due to over-provisioning is also a performance killer for the servers that host the 4GL execution engines (Sage X3 runtime).
To help determine the quality of an infrastructure regardless of its nature (physical or virtual, single or multi-tier, Oracle or SQL Server, Unix-Linux or Windows, and so on), Sage provides the AIOBENCH test program to meter the performance of Sage X3 by performing a set of data I/O operations of the reference folder to simulate some high-demand transactions.
The results of this program can help to compare metered performance to known reference systems and feedback from other customers’ production infrastructures.
Security considerations
Ensure redundancy for physical servers and storage systems.
Important sizing considerations for virtualization
Huge virtual machines won’t work properly, unless they run in a dedicated virtualization environment where there is NO overprovisioning at all (which removes most benefits from virtualization).
A full Sage X3 environment you would put in a physical, dual-socket 24-core server does NOT run properly in a big 24-vCPU VM in most cases and MUST be split on several smaller VMs.
4 to 6 vCPUs per VM is considered a reasonable upper limit. This number can be raised to higher values if virtualization platform consists of servers with a high core count AND there is no or moderate CPU overprovisioning.
Virtualizing MongoDB, Elasticsearch and Syracuse: good practices
In most cases, MongoDB can be deployed in the same server than Syracuse (node.js), but if you use MongoDB intensively to store documents, it is wise to host it on a dedicated server.
Using different servers makes it much easier to tune the configuration because different components won't be competing for the same resources (memory, CPU, disk I/O) inside a single VM. It also makes it easier to modify the deployment if you identify a performance bottleneck in one of the components.
MongoDB usually requires less CPU and memory than the node.js component. You can start with a smaller VM configuration. Ideally you should set up a cluster (replica set) with an odd number of nodes (3 is a good start). There are many resources on the Internet about tools and techniques to tune MongoDB deployment. Don't oversize/over-architect it unless you see that Mongo is your performance bottleneck. Mongo is designed to handle very large datasets and very high transaction rates and Sage X3 is stressing it very little in comparison to some of the larger web apps/sites that use Mongo.
Elasticsearch uses more memory and CPU than MongoDB but usage varies widely. You can start with the same configuration as MongoDB and then scale up if necessary. Some interesting facts about the Elasticsearch component: It is decoupled from the rest so if you have a performance issue in this layer it does not impact the rest of the application, just the search function. It is easy to redeploy on a larger VM because it does not hold critical data. It is only an index that can be rebuilt from data in a MongoDB or Sage X3 database (SQL or Oracle). It can be clustered and you'll find resources on the Internet about cluster deployment.
Node.js (Syracuse server) is the most difficult of the three to configure and the most likely to be responsible for poor performance.
Tips for presentation tier virtualization
Memory and CPU considerations for Syracuse
With default configuration values, a healthy node.js process should take less than 1.5 GB of RAM. If it goes above, it starts to garbage collect aggressively and that's usually when it starts to saturate its CPU thread. It is important to keep the individual node.js processes below 75% of 1 CPU (20% of overall CPU on a 4-core VM) and below 1.5 GB.
As you need to keep CPU resources for the operating system, a Syracuse VM should at least have 2 cores. A minimum of 2 GB RAM should be available for the operating system.
A node.js process is required for about 25 interactive sessions, depending on their activity. A session corresponds to an opened tab if the user uses a Classic page, plus one session for all tabs opened by a user on Syracuse functions.
A CPU core is required for 2 to 4 node.js process (according to their activity).
For instance, a VM with 2 cores and 8 GB is adequate to run 4 node.js processes with default sizing values.
If you manage huge grids in classic pages, you might need to increase the memory size associated to node.js (it can be raised up to 8 GB). Refer to the dedicated node.js sizing documentation for more details.
Remember the following rules:
- Node.js is single threaded so if you have 4 cores and a node.js process is taking 25% of overall CPU it means it is saturating its CPU thread - not good.
- You should observe overall memory usage while the app is running and bump the number of node processes until overall memory usage reaches 75-80%.
Web services sizing
If a significant part of your transactions to go through web services, you should deploy a node.js cluster and dedicate one or more nodes of your cluster to web services.
In this case, do not mix web services and interactive sessions on the same cluster node(s).
MongoDB sizing
For your MongoDB instance, you should consider:
- The memory sizing of MongoDB is not correlated to the Syracuse memory sizing. MongoDB generally uses less than 1 GB which makes a 3 GB VM suitable.
- As a rule of thumb, give MongoDB less than 20% VM CPU allocation than for Syracuse.
Elasticsearch sizing
Elasticsearch requires at least two cores and 4 GB of RAM and should be hosted on a dedicated VM. If you index huge database, more CPU and memory might be required.
Storage considerations
Syracuse does very little I/O. Save the high-end disks for MongoDB and Elasticsearch.