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érales sur le matériel à utiliser pour atteindre des performances adaptées.

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-utilisateurs.

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

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

Pour les charges lourdes à thread unique, 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 entre les serveurs RDBMS et le moteur d’exécution / l’application

Sage X3 est un produit hautement interactif de par les nombreuses communications qui existent entre la couche d’application et la couche de 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 les couches de la RDBMS et de l’application / du moteur d’exécution ne sont pas hébergées sur le même serveur, ces performances élevées sont possibles 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 entre le moteur d’exécution / l’application et le serveur Syracuse Sage X3

Ce type d'accès réseau est moins contraignant : 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 la RDBMS et le moteur d’exécution), 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 bases 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 dégrader les performances des opérations techniques comme l'intégration de patches, la création de dossiers, 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 dégrader 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 supplémentaires,
• 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. Sage vous recommande 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éponse 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 la RDBMS (SQL Server ou Oracle) dans un environnement virtualisé.

Cependant, si vous décidez d'exécuter la 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 impact important sur les performances des serveurs qui hébergent les moteurs d'exécution 4GL Sage X3.

Pour déterminer la qualité d'une infrastructure de quelque nature que ce soit (physique, virtuelle, à un ou plusieurs niveaux, Oracle ou SQL Server, Unix-Linux ou Windows, etc.), Sage fournit le programme de 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 » (nombre de cœurs) é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 demande 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 nœuds (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. Voici 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, et 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.

Comme 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 des tables très volumineuses 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 à thread unique : 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 des bases de données très volumineuses, davantage de CPU et de mémoire peut être nécessaire.

Remarques sur le stockage

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