Virtualization

Deploying the solution within a virtualized environment like VMware Infrastructure 3, VMware vSphere 4 or Hyper-V, KVM, XEN, AWS, OVM... are recommended, but you have to pay attention to the platform and its configuration in order to have good performances, especially in production environments.

Sage does not have a return of experience on every flavor of virtualization environment, and doesn’t support or reject any virtualization technology in particular. We consider Sage X3 should run on any virtual machine as soon as the OS vendor and the virtualization platform vendor have agreed on mutual compatibility. Sage does only certify that the software runs on given operating systems, independently of the type of server and the virtualization used.

All Sage X3 components can be deployed within virtualized machines, and this includes notably:
* the Syracuse node.js web servers.
* the MongoDB instances (they can be on the same servers than the previous ones)
* the application and main processing server for Sage X3
* the additional process server(s) for Sage X3
* the Elasticsearch instances(s)
* the print server(s)

Virtualizing the database servers is also possible according to the recommendations of the database providers.

Precautions when virtualization is used

If you host your hardware, make sure your physical infrastructure configuration is adequate:
* a set of dedicated servers adapted to virtualization (see the next paragraph) with an external high performance storage device type SAN.
* an adequate backup tool in order to be able to save online virtual machines.
* possibly consider a redundancy of the bay and the servers.

Pay also attention to the virtualization bias :

• Oversubscription of CPU and/or memory resources in virtualization farm. You may have to reserve CPU and/or memory for the most important components, that is Database Server (if virtualized), Process Servers and Syracuse Servers.
• “Fat” Vms (for instance 8 vCPUs) not being efficient in dense environments, so depending on the size of the project you may have to leverage on several “small” (less than 4 / 6 vCPUs) VMs what you would have put in a single multicore physical machine.
• “Noisy neighbor” syndrome. This syndrome applies to a cloud computing instance co-tenant that monopolizes network bandwidth, disk I/O, CPU, or other resources, thus affecting negatively the performance of other virtual machines or components sharing the infrastructure.

A good illustration of this last recommendation is the case where the database tier (SQL Server or Oracle) and the application / runtime tier (X3 core) are not on the same server: it is HIGHLY recommended that the network backbone between these two tiers has a bandwith of 10 GBits/s. This recommendation is valid on virtualized infrastructures as well as on not virtualized structures, or on hybrid structures (physical database cluster and the other servers virtualized, for example). This is not a throughput issue, but a latency issue. In situation where a lot of atomic transactions are done by the Sage X3 process server towards the (distant) database server, having the lowest possible latency will make the difference. Stress tests program have shown a 1-to-3 performance difference between 1 Gbps network link and 10 Gbps network link, all other things being the same.