Note: Please refer to the latest architecture guide for the most up to date information regarding components and sizing recommendations

Most Sage components can be deployed on virtual machines

Hints, tips, and tricks:

• • Application and Main process server
  • Additional process server
  • Print server
  • Web Syracuse server
  • Elastic Search server
  • Web Services and ADC server
  • If you decide to virtualize your architecture, you must acquire and develop a physical infrastructure adapted to a virtual environment for optimum performance. We recommend dedicated resources assigned to your environment, rather than sharing resources.
  • A production virtualization architecture can be built with multiple physical hosts, but in this case, it must rely on a shared storage system (SAN) providing high availability and adequate performance to cope with the I/O and throughput need of applications. all hosted VMs and Do NOT deploy Syracuse (node.js), MongoDB and Elastic Search together in the same VM, deploy them in separate VMs. This will make it much easier to tune the configuration because different components won't be competing for the same resources (memory, CPU, disk) inside a single VM. It will also make 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 setup a cluster (replica set) with an odd number of nodes (3 is a good start). There are lots of 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 big datasets and very high transaction rates and X3 is stressing it very little in comparison to some of the big web apps/sites that use mongo (dating sites like eHarmony for example)
  • Elastic Search is hungrier on memory and CPU than MongoDB but usage varies a lot. You can start with the same configuration as MongoDB and then scale up if necessary. Some cool things about the Elastic Search component: It is decoupled from the rest so if you have a performance issue in this layer it will not impact the rest of the application, just search function. It is easy to redeploy on a larger VM because it does not hold critical data. It's only an index which can be rebuilt from data that resides in mongo or SQL. It can be clustered and you'll find resources on the Internet about cluster deployment.
  • Node.js (Syracuse server) - the most likely to be responsible for poor performance
    • Give it more VM power than the other two (like 4 times more CPU and memory than what you allocate to MongoDB).
    • Size the VM with at least 2GB RAM per core (so at least 32GB for 16 cores). Node.js is single threaded so if you have 16 cores and a node.js process is taking 6.25% of overall CPU 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 will start to garbage collect aggressively and that's usually when it will start to saturate its CPU thread. So it is important to keep the individual node.js processes below 75% of 1 CPU (5% of overall CPU on a 16 1GB. core VM) and below
    • The number of node.js processes can be changed via the "host" entity in Syracuse admin. As a starting point you should set the number of node.js processes to 1.5 * number of cores (24 node.js processes on 16 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 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 a number of processes for web service requests. This setting will dramatically depend on the activity of your web services.
    • If a significant part of your transactions go through web service, you should deploy a node.js cluster and dedicate one or more nodes of your cluster to web services.
    • Do not mix web service and interactive sessions on the same cluster node. The Syracuse server does very little with the disk. Save the fancy/expensive disks for MongoDB and Elastic Search.
    • Plan to acquire adequate backup tools so that you can save online
      virtual machines and ensure redundancy for physical servers and
      storage systems.

In case of virtualized infrastructure on VMware ESX (or Hyper-V) with a MS-SQL Server DB in a dedicated VM (for lowering license cost if per vCPU) the following rules should be applied:

• Virtualization hosts power management should be set up to “Maximum Power” (not ‘balanced or “economy”) otherwise CPU may not run at max speed for more than a fraction of seconds
• Virtual network cards should be of VMXNET3 type (and report 10 Gbps network connection in Windows, even if it’s virtual)
• MS-SQL Server DB VM and X3 VM(s) with Application / Main runtime and Additional runtime(s) should be placed in the same ESXi host if technically possible (no CPU or memory constraints), hence avoiding network between runtime and DB to go through PHYSICAL network (only a virtual switch in that case)