In addition to deploying to physical hardware, Sage X3 can be deployed in virtual environments like:
Most of Sage X3 components below can be deployed on virtual machines.
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 X3 environment, rather than sharing resources.
A production virtualization architecture is usually built with multiple physical hosts, and relies on a shared storage area network (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, Sage does not recommend running the RDBMS portion (the SQL Server or Oracle portion) 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 will be 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.
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, etc.), Sage can provide a test program to meter X3’s performance by performing a set of data I/O operations of the reference folder to simulate some high-demand transactions. The results of the test program can help to compare metered performance to known reference systems and feedback from other customers’ production infrastructures.
Please noted that a full Sage X3 environment that you might put in a physical, dual-socket 24-core server will 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 may be raised to higher values if virtualization platform consists of servers with a high core count AND there is no or “moderate” CPU overprovisioning.
On PRODUCTION systems, do NOT deploy Syracuse (node.js), MongoDB and ElasticSearch together in the same VM, deploy them in separate VMs.
Placing these pieces in separate VMs makes it much easier to tune the configuration because different components will not 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 (Syracuse). You can start with a smaller VM configuration. Ideally you should set up a cluster (replica set) of mongod processes 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 stresses Mongo 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. ElasticSearch 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 Server 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.
Give Syracuse more VM power than for MongoDB or ElasticSearch (4 times more CPU and memory than what you allocate to MongoDB).
Size the Syracuse VM with at least 2GB RAM per core (so at least 8GB for 4 cores). 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 actually saturating its CPU thread - not good.
A healthy node.js process should take less than 1GB or 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 1GB.
The number of node.js processes can be changed via the "host" entity in Syracuse admin (for interactive sessions as well as for web services sessions). As a starting point, you should set the number of node.js processes to 1.5 times the number of cores (6 node.js processes on 4 cores). Then 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%.
If some node.js processes are still saturating the CPU when you reach that limit it, means that you need either a larger VM or a cluster for the Syracuse server. The host entity also lets you configure several processes for web service requests. This setting depends heavily on the activity of your web services.
If a significant part of your transactions go through a web service, 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).
The Syracuse server does very little I/O. Save the high-end disks for MongoDB and ElasticSearch.
-
- VMware vSphere
- Hyper-V
- RedHat KVM
- Citrix XenServer
- Oracle VM
Most of Sage X3 components below can be deployed on virtual machines.
- Application and Main process server(s)
- Additional process server(s)
- MongoDB server(s) (yes)
- Elastic Search server(s) (yes)
- Syracuse Web server(s) (yes)
- Print server(s)
- Legacy Web Services / ADC server(s)
- Legacy Java Bridge 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 X3 environment, rather than sharing resources.
A production virtualization architecture is usually built with multiple physical hosts, and relies on a shared storage area network (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, Sage does not recommend running the RDBMS portion (the SQL Server or Oracle portion) 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 will be 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.
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, etc.), Sage can provide a test program to meter X3’s performance by performing a set of data I/O operations of the reference folder to simulate some high-demand transactions. The results of the test program can help to compare metered performance to known reference systems and feedback from other customers’ production infrastructures.
Security considerations
- Plan to acquire adequate backup tools so that you can save online virtual machines.
- Ensure redundancy for physical servers and storage systems.
Important sizing considerations for virtualization
- Keep virtual machines small!
- 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).
Please noted that a full Sage X3 environment that you might put in a physical, dual-socket 24-core server will 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 may 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 practice
On PRODUCTION systems, do NOT deploy Syracuse (node.js), MongoDB and ElasticSearch together in the same VM, deploy them in separate VMs.
Placing these pieces in separate VMs makes it much easier to tune the configuration because different components will not 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 (Syracuse). You can start with a smaller VM configuration. Ideally you should set up a cluster (replica set) of mongod processes 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 stresses Mongo 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. ElasticSearch 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 Server 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.
Helpful ideas for Syracuse web server virtualization
Give Syracuse more VM power than for MongoDB or ElasticSearch (4 times more CPU and memory than what you allocate to MongoDB).
Size the Syracuse VM with at least 2GB RAM per core (so at least 8GB for 4 cores). 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 actually saturating its CPU thread - not good.
A healthy node.js process should take less than 1GB or 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 1GB.
The number of node.js processes can be changed via the "host" entity in Syracuse admin (for interactive sessions as well as for web services sessions). As a starting point, you should set the number of node.js processes to 1.5 times the number of cores (6 node.js processes on 4 cores). Then 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%.
If some node.js processes are still saturating the CPU when you reach that limit it, means that you need either a larger VM or a cluster for the Syracuse server. The host entity also lets you configure several processes for web service requests. This setting depends heavily on the activity of your web services.
If a significant part of your transactions go through a web service, 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).
The Syracuse server does very little I/O. Save the high-end disks for MongoDB and ElasticSearch.
-
Sage X3 and Sage Software are trademarks of Sage Software, Inc. Microsoft SQL Server, Microsoft SQL Enterprise Manager and SQL Server Management Studio are registered trademarks of Microsoft Corporation. Oracle is is a registered trademark or Oracle Corporation. All other product names used here are trademarks or registered trademarks of their respective owners.
-
