Rapport d’analyse du serveur VPS (SIC@2) 14 AVRIL 2023 SOMMAIRE I. CONTEXTE ........................................................................................................................2 II. OBJECTIF.......................................................................................................................2 III. RÉSULTATS ATTENDUS ...............................................................................................2 IV. METHODOLOGIE..........................................................................................................2 V. PISTE DE SOLUTIONS ..................................................................................................4 1 I. CONTEXTE L'Agence Nationale Pour l’Emploi, dans le cadre de la dynamisation de ses services et dans le souci d’améliorer la qualité et la performance de ses prestations, s’est dotée d’une nouvelle version de sa plateforme d’intermédiation (SIC@2). Mais dans sa mise en production, cette plateforme a montré certaines inconsistances, surtout en terme de résilience. Une analyse a été effectuée pour identifier l’origine de cette instabilité. II. OBJECTIF L’objectif de la mission est d’analyser les différentes ressources et de proposer des solutions pour le bon fonctionnement de la plateforme SIC@2. III. RÉSULTATS ATTENDUS Proposition de solutions pratiques pour un bon fonctionnement de la plateforme. IV. METHODOLOGIE Pour faire les analyses nécessaires, nous avons récupéré les logs et configurations du serveur applicatif et de la base de données. 4.1 Traces du CPU 2 Le test de performance du CPU a permis d’avoir le graphique ci-dessous 4.2 Traces de la mémoire 4.3 Traces du disque 3 Le CPU est un 2VCPU pour un total de 08 GHZ. Ce paramètre est très insuffisant, ce qui explique les pics remarqués sur la trace du CPU. En outre, des logs de la base données 06 Go de mémoire RAM sont utilisées par PostgreSQL. Ceci représente 80 % de la mémoire totale. Il ne reste donc que 02 Go à disposition du serveur applicatif et du système d’exploitation. Cette répartition de la ressource pénalise le serveur virtuel. V. PISTE DE SOLUTIONS EBAUCHE 1 Passer la RAM à 32go et le processeur à 8Vcpu tout en mutualisant sur le même serveur virtuel le serveur applicatif et le serveur de la base de données. Maintenir l’hébergement au Data Center National. EBAUCHE 2 Déplacer le serveur de la base de données sur une autre machine virtuelle de 16go de ram et 4 Vcpu avec un espace de stockage de 300go. 4 - Augmenter les capacités du serveur actuel qui hébergera seulement le serveur applicatif avec 16go de ram, 4Vcpu ; Maintenir l’hébergement des deux serveurs au Data Center National. EBAUCHE 3 Mettre le serveur applicatif dans le cloud avec des performances élevées et laisser la base de données sur le serveur actuel tout en augmentant la ram à 16go, le processeur à 4Vcpu et l’espace de stockage à 300go. Points d’attention : Datacenter National : Les serveurs applicatifs et de base de données restent joignables même en cas d’indisponibilité d’Internet à cause du Réseau National d’Administration. Aussi, la responsabilité en cas de risque est partagée avec la SBIN. Par contre, la difficulté sur la mise à jour soulignée est maintenue et il faut bien négocier les frais d’hébergements qui peuvent devenir cher à la longue. CLOUD : Moins cher et performance élevée. La difficulté de mise à jour n’existe plus. Cependant, il pourrait y avoir de difficulté d’accès du serveur applicatif au serveur de bases de données en cas de défaillance d’Internet. 5