Notre laboratoire a testé trois solutions de mise en grappes de serveurs Unix. Le système comportait deux n?”uds, ou serveurs, ainsi qu’une baie de stockage sécurisée d’une capacité de 50 Go. Les deux serveurs accédaient simultanément à cette baie. Aucune technologie spécifique n’a été imposée pour la solution de stockage. Chaque serveur a été attaché au réseau local via deux liens Fast Ethernet redondants. Chacun des deux n?”uds abritait une application qui lui était propre. Le premier n?”ud hébergeait la base de données Oracle 8i, tandis que le second accueillait le serveur Web Netscape Server. Les requêtes provenaient de deux postes clients dédiés : un client Oracle et un client Netscape. Cette plate-forme a servi à réaliser les tests de reprise sur arrêt matériel ou logiciel.
Intégration
Pour évaluer ce critère, deux tests ont été effectués. Le premier consistait à réinstaller un n?”ud du cluster après qu’un des deux serveurs Unix a été arrêté. Il a été réinstallé comme s’il s’agissait d’une nouvelle machine. Cette opération comprend l’installation du système d’exploitation, des applications ainsi que l’intégration dans le cluster. Quant au second test, il s’agissait d’ajouter une application. La facilité de mise en ?”uvre a été notée pour les différentes étapes nécessaires à l’intégration d’une application.
Administration
L’administration graphique du cluster (serveurs, couche cluster et baie) à partir d’un point unique, la gestion en ligne à l’aide de commandes en mode texte, ou encore, les outils de mise à jour et de cohérence de données partagées sur les n?”uds ont servi pour cette évaluation. La remontée des alarmes lors d’incidents et leur intégration dans des outils de supervision tiers sont venues en complément.
Reprise sur panne logicielle
Afin de mesurer ce critère, deux caractéristiques ont été évaluées : le basculement des applications et la facilité de ce basculement. Pour la première, on a forcé le basculement d’Oracle 8i ou de Netscape Server sur le serveur de secours. Cette opération devait être suffisamment souple pour être effectuée à partir d’un outil de surveillance automatique. Pour la seconde, les outils mis à la disposition de l’administrateur pour réaliser le basculement (la maintenance planifiée, par exemple) ont été contrôlés. Le degré de complexité a aussi été pris en compte.
Reprise sur panne matérielle
Quatre épreuves ont été nécessaires pour noter ce critère : arrêt du serveur, perte d’une connexion vers la baie de disque, perte d’une connexion réseau, perte de l’interconnexion des deux serveurs Unix. A chaque fois, les alertes sont remontées à la station d’administration.
Lors du premier test, nous avons arrêté brutalement un des deux serveurs Unix, en coupant sa tension d’alimentation. Nous avons vérifié les conséquences pour les postes clients Oracle et Netscape (perte de connexion, basculement des applications sur le n?”ud toujours actif…) ainsi que l’impact sur le système. Puis le n?”ud défaillant a été réintégré dans le cluster.
Le deuxième test a consisté à débrancher une des cartes assurant la liaison entre un des serveurs et la baie. La redondance de la connexion a été validée en envoyant des requêtes Oracle et Netscape. L’attitude du système a été analysée.
Lors de la troisième épreuve, les techniciens du laboratoire ont débranché un des liens du cluster directement sur le concentrateur Fast Ethernet. Le comportement du serveur Web et de la base de données a servi de référence.
Enfin, pour le quatrième test, le lien physique reliant les deux n?”uds du cluster a été débranché afin d’étudier la réaction du système.Coefficients de pondération
La note globale a été établie en fonction des coefficients de pondération suivants : intégration, 4 ; administration, 2 ; reprise sur panne logicielle, 2 ; reprise sur panne matérielle, 2.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
