Hébergement des composants serveur Sage X3 V12 : recommandations

Recommandations génériques sur le matériel

Vous trouverez ci-dessous des recommandations génériques sur le matériel à utiliser pour des performances optimales.

Des recommandations de dimensionnement additionnelles seront fournies dans une mise à jour ultérieure de ce document.

Remarques sur le CPU

CPU Intel®

Que votre solution Sage X3 V12 soit hébergée sur des serveurs physiques ou virtualisés, le matériel utilisé doit s'appuyer sur les dernières générations de processeurs (Intel® Xeon® E5 v4 ou supérieure, E7 v4 ou supérieure).

Sage vous recommande d'utiliser la dernière version (troisième génération) ou générations précédentes (première et deuxième) des processeurs Intel® Xeon® Scalable, éditions Gold ou Platinum.

CPU AMD™

Les processeurs Opteron™, optimisés pour les nombres à virgule flottante, sont plus lents que les processeurs équivalent Intel® Xeon® pour la plupart des calculs Sage X3 basés sur des entiers DCB (pour éviter la perte de précision de la virgule flottante).

Les processeurs EPYC™ de première génération (7001 series) sont moins performants que les processeurs Intel® Xeon® de même génération. Leur utilisation n'est pas recommandée.

Les processeurs EPYC™ de deuxième génération (7002 series) peuvent être utilisés. Leurs performances sont similaires aux processeurs Intel® Xeon® Scalable de même génération.

Fréquence d'horloge des processeurs

Une fréquence d'horloge élevée du CPU permet un débit plus élevé des opérations individuelles ; un "core count" (nombre de cœurs) élevé du CPU permet une meilleure tolérance globale face à une charge de travail multi-utilisateur.

Il est nécessaire de trouver un bon équilibre entre niveau élevé de cœurs et fréquence d'horloge élevée. En effet, seuls des processeurs onéreux permettent d'obtenir les deux à la fois.

Evitez les processeurs à basse consommation avec une fréquence d'horloge faible (modèles Xeon® L). Ils entraîneront de mauvaises performances. Pour de meilleurs résultats, utilisez des processeurs à 2.4 GHz ou plus.

Pour des charges lourdes à un fil (thread), vous pouvez également utiliser un processeur avec une fréquence d'horloge de base de 2.8 GHz ou plus.

Remarques sur la mémoire

La vitesse du bus mémoire doit être maximale car l'architecture de Sage X3 requiert peu de bande passante mémoire.

Veuillez noter que pour certaines générations de cartes mères, la bande passante réelle du bus mémoire diminue en fonction du nombre de cartes (puces) mémoires installées.

Dans ce contexte, la vitesse du bus mémoire est ralentie car la mémoire globale est composée d'un grand nombre de petites cartes mémoires (avec de petites puces mémoire). Il est plutôt recommandé d'utiliser peu de cartes mémoires, mais d'une grande capacité (avec des puces de grande taille). Cependant, si cette configuration est recommandée, elle est généralement plus onéreuse.

Veuillez consulter la documentation technique de votre serveur avant de choisir une configuration de composants pour votre mémoire RAM.

Remarques sur le réseau

Mise en réseau serveur(s) SGBDR et runtime / application

Sage X3 est un produit hautement interactif par les nombreuses communications qu'il existe entre la couche application et la couche base de données.

Pour des performances et une expérience utilisateur optimales, assurez-vous que le temps de réponse du réseau est le plus court possible entre ces deux couches.

Lorsque le SGBDR et les couches application / exécution ne sont pas hébergées sur le même serveur, cela est possible grâce à un équipement réseau haute qualité à 10 Gbit/s et en portant une attention particulière à la pile réseau (pilotes d'adaptateurs réseaux, microprogramme des commutateurs de réseau, types de cartes réseau virtuelles, etc.).

Mise en réseau runtime / application et serveur Syracuse Sage X3

Ce type d'accès réseau est moins contraint : quand la base de données et l'application sont hébergées sur le même serveur (pas de chemin réseau physique entre SGBDR et le runtime), vous pouvez utiliser un équipement réseau à 1 Gbit/s.

Remarques sur le stockage

Stockage de données Oracle ou SQL Server

La qualité du système de stockage est primordiale pour les performances de la base de données.

La configuration de votre stockage doit permettre d'optimiser la performance en IOPS des volumes sur lesquels les fichiers de données sont hébergés, que vous utilisiez Oracle (tablespaces système, tablespaces de données ou d'index, Redo Logs) ou SQL Server (fichiers de données TempDB, groupes de fichiers d'index, de données, ou journaux).

Pour cela, vous pouvez utiliser un stockage SSD (avec système de redondance RAID-10, RAID-1, RAID-5 ou RAID-6). Sinon, vous pouvez utiliser une configuration RAID optimale avec disques tournants (nombre élevé de lecteurs de disque 15krpm avec redondance RAID-10).

Il est préférable d'utiliser un nombre élevé de petits lecteurs de disque, qu'un nombre limité de lecteurs de grande taille. En effet, la capacité en IOPS dépend du nombre, et non de la taille, des lecteurs dans une matrice RAID.

Il ne faut jamais utiliser un lecteur 7.2krpm et/ou un système RAID-5 ou RAID-6 pour héberger une base de données de production.

Stockage de l'application Sage X3

Le stockage de l'application Sage X3 ne requiert pas autant de IOPS que le stockage de base de données.

Dans Sage X3, les composants peuvent utiliser un niveau de stockage modéré en termes d'IOPS ; par exemple des lecteurs disque 10krpm avec une redondance RAID-5 ou RAID-6.

Les lecteurs 7.2krpm ne sont pas recommandés car ils peuvent impacter les performances des opérations techniques comme l'intégration de patch, la création de dossier (etc.).

Stockage de données MongoDB

Les besoins en IOPS sont généralement modérés, sauf en cas de stockage intensif de pièces jointes Sage X3 dans MongoDB.

Vous pouvez utiliser le même type de configuration de stockage que pour Sage X3.

Les lecteurs 7.2krpm ne sont pas recommandés car ils peuvent ralentir les opérations en cas de forte concurrence d'accès à MongoDB ; par exemple, plusieurs traces utilisateurs sont créées dans Sage X3 sur un intervalle de temps court.

Stockage des données Elasticsearch

Si vous prévoyez d'utiliser massivement l'indexation Elasticsearch, il est recommandé d'utiliser un niveau de stockage performant pour héberger les données Elasticsearch.

Cependant, un disque SSD pourrait être excessif. Pour fournir une réponse adéquate aux requêtes de recherche des utilisateurs et aux mises à jour des index Elasticsearch, utilisez des disques 10krpm en RAID-10.

Autre stockage de composants Sage X3

La plupart des autres composants Sage sont des données statiques, avec un accès au disque limité, qui ne nécessite pas un stockage de haut niveau. Des disques 10krpm en RAID-5 ou RAID-6 sont suffisants.

Des disques 7.2krpm pourraient affecter les opérations techniques comme la mise à jour des composants.

Remarques sur la virtualisation

Vous pouvez déployer la solution sur des serveurs physiques ou sur un environnement virtuel comme VMware vSphere, Hyper-V, RedHat KVM, Citrix XenServer ou Oracle VM.

Les composants Sage X3 suivants peuvent être installés sur des machines virtuelles. :

• Serveur(s) de traitement principaux et applicatifs,
• Serveur(s) de traitement additionnels,
• Serveur(s) MongoDB,
• Serveur(s) Elasticsearch,
• Serveur(s) web Syracuse,
• Serveur(s) d'impression,
• Serveur(s) ADC (terminaux portables).

Lorsque vous décidez de virtualiser votre architecture, vous devez mettre en place une infrastructure physique qui soit adaptée à un environnement virtuel pour obtenir les meilleures performances. Nous vous recommandons d'utiliser des ressources dédiées affectées à votre environnement Sage X3, plutôt que des ressources partagées.

Une architecture de virtualisation de production est en général constituée de plusieurs hôtes physiques et s’appuie sur un système de stockage partagé (SAN) fournissant une répondre aux besoins (débit et E/S) de toutes les machines virtuelles et applications hébergées.

En dehors des environnements de test/développement ou des petits environnements de production, il n'est PAS RECOMMANDE d'exécuter le RDBMS (SQL Server ou Oracle) dans un environnement virtualisé.

Cependant, si vous décidez d'exécuter le RDBMS depuis une machine virtuelle, vous devez prendre toutes les précautions nécessaires pour vous assurer que cette machine virtuelle peut fournir une capacité optimale d'exécution à tout moment et qu'aucun goulot d'étranglement n'est présent au niveau du CPU, de la mémoire ou du stockage entrée / sortie en raison d'un excédent de ressources sur la plateforme de virtualisation.

Les goulots d'étranglement de CPU causés par un excédent de ressources ont aussi un lourd impact sur les performances des serveurs qui hébergent les moteurs d'exécution 4GL (runtime Sage X3).

Pour déterminer la qualité d'une infrastructure de tout type (physique, virtuelle, à un ou plusieurs niveaux, Oracle ou SQL Server, Unix-Linux ou Windows, etc.), Sage fournit le programme test AIOBENCH pour évaluer la performance de Sage X3. Pour cela, un ensemble d'opérations d'entrée/sortie de données sont effectuées sur le dossier de référence pour simuler des transactions de haut niveau.

Les résultats de ce programme vous permettront de comparer les performances mesurées aux systèmes de référence standard, et au feedback des clients d'autres infrastructures de production.

Remarques de sécurité

Remarques importantes sur le dimensionnement pour la virtualisation

Dans la majorité des cas, un environnement Sage X3 complet que vous exécutez sur un serveur physique dual-socket 24-core ne fonctionne pas correctement avec une "grosse" machine virtuelle 24-vCPU : elle doit être divisée en plusieurs machines virtuelles plus petites.

Une limite maximum raisonnable serait d'utiliser 4 à 6 vCPUs par machine virtuelle. Cette limite peut être augmentée si la plateforme de virtualisation comprend des serveurs avec un "core count" élevé ET si aucun excès, ou un excès modéré de CPU n'existe.

Virtualisation de MongoDB, Elasticsearch et Syracuse : bonnes pratiques

L'utilisation de plusieurs serveurs permet d'adapter plus facilement la configuration car les différents composants ne sont pas en concurrence sur les mêmes ressources (mémoire, CPU, disque E/S) au sein d'une même machine virtuelle. Cela permet également de modifier le déploiement plus facilement dans le cas où vous constatez un goulot d'étranglement au niveau d'un des composants.

MongoDB requière en général moins de CPU et de mémoire que le composant node.js. Vous pouvez commencer par une configuration de machine virtuelle restreinte. Idéalement, vous devez paramétrer un cluster (replica set) avec un nombre impair de "nodes" (3 est un bon début). Il y un grand nombre de ressources sur Internet sur les outils et techniques pour synchroniser le déploiement MongoDB. N'exagérez pas son dimensionnement ou son architecture, à moins que MongoDB représente un goulot d'étranglement pour vos performances. MongoDB est conçu pour supporter un nombre important de jeux de données et des taux de transaction très élevés : par comparaison, les ressources demandées par Sage X3 ne sont presque rien à côté des plus gros sites et applications web qui utilisent MongoDB.

Elasticsearch utilise plus de mémoire et de CPU que MongoDB, mais l'utilisation peut énormément varier. Vous pouvez commencer avec la même configuration que MongoDB puis l'augmenter si nécessaire. Quelques informations intéressantes sur le composant Elasticsearch : Ce composant est dissocié du reste : si vous rencontrez un problème de performance à ce niveau, il n'impactera pas le reste de l'application, uniquement la fonction de recherche. Ce composant peut facilement être redéployé sur une machine virtuelle plus volumineuse car il ne contient aucune donnée critique. Il s'agit d'un simple index à reconstruire à partir des données d'une base MongoDB ou Sage X3 (SQL ou Oracle). Il peut également être mis en cluster ; vous trouverez des ressources sur le déploiement de cluster sur Internet.

Node.js (Serveur Syracuse) est l'élément le plus difficile à configurer des trois, mais aussi celui qui cause le plus souvent des problèmes de performance.

Astuces pour la virtualisation du niveau de présentation

Remarques sur le CPU et la mémoire pour Syracuse

En appliquant les valeurs de configuration par défaut, un processus node.js standard devrait solliciter moins de 1,5 Go de RAM. Dans ce cas, le traitement lance une récupération de mémoire "agressive", ce qui sature en général le thread du CPU. Il est important de maintenir les traitements node.js individuels sous les 75% pour 1 CPU (20% pour le total de CPU sur une VM à 4 cœurs), et sous 1,5 Go.

Étant donné que vous devez conserver des ressources CPU pour le système d'exploitation, une VM Syracuse doit avoir au minimum 2 cœurs. Un minimum de 2 Go de RAM doit être disponible pour le système d'exploitation.

Un processus node.js est requis pour environ 25 sessions interactives, selon l'activité sur ces sessions. Pour un utilisateur de pages classiques, une session correspond à un onglet ou une section ouverts. Pour un utilisateur de fonctions Syracuse, une session supplémentaire est nécessaire pour tous les onglets ou sections ouverts.

Un cœur de CPU est requis pour 2 à 4 processus node.js (selon leur activité).

Par exemple, une VM avec 2 cœurs et 8Go est suffisante pour exécuter 4 processus node.js avec les valeurs de dimensionnement par défaut.

Si vous devez gérer de très grandes tables dans les pages classiques, vous devez augmenter la taille mémoire associée au node.js (jusqu'à 8 Go). Se reporter à la documentation dédiée au dimensionnement node.js pour plus d'informations.

Les règles à ne pas oublier :

• Node.js est un processus à un fil (thread) : si vous avez 4 cœurs et que le processus node.js sollicite 25% du CPU total, cela signifie que le thread du CPU est saturé, ce qui n'est pas souhaitable,
• Surveillez l'utilisation globale de la mémoire pendant que l'application est en cours d'exécution et augmentez le nombre de processus nodes avant que l'utilisation globale de la mémoire atteigne les 75-80%.

Dimensionnement des services web

Si la majorité de vos transactions utilisent des services web, il est recommandé de déployer un cluster de node.js et de dédier un ou plusieurs processus nodes de votre cluster aux services web.

Dans ce cas, assurez-vous de ne pas utiliser des services web et des sessions interactives sur le(s) même(s) node(s).

Dimensionnement de MongoDB

Prenez en compte les éléments suivants pour votre instance MongoDB :

• Le dimensionnement de la mémoire de MongoDB n'est pas lié au dimensionnement de la mémoire Syracuse, MongoDB utilise généralement moins de 1 Go, ce qui convient à une VM de 3 Go.
• Par principe, allouez toujours 20% du CPU de la VM de moins à MongoDB qu'à Syracuse.

Dimensionnement Elasticsearch

Elasticsearch nécessite au moins deux cœurs et 4 Go de RAM et doit être hébergé sur une machine virtuelle dédiée. Si vous indexez une base de données très volumineuse, plus de CPU et de mémoire peuvent être requis.

Remarques sur le stockage

Syracuse effectue très peu d'entrées/sorties (E/S). Sauvegardez les disques pour MongoDB et Elasticsearch.