Quelques détails sur le Multipath :
Dans le monde des serveurs et du stockage, il est nécessaire de se protéger contre une défaillance du lien physique reliant un serveur à une baie de stockage.
Lorsqu’il n’existe qu’un unique lien entre deux périphériques, il y a un point de faille (ou SpoF, Single Point of Failure) qui peut être un problème, par exemple en cas de rupture d’un câble, de défaillance, d’un commutateur ou de maladresse d’un administrateur. Pour se protéger de ce risque, les outils de multipathing permettent d’établir de multiples chemins physiques entre deux périphériques (et ce quel que soit le protocole, FC, FCoE ou iSCSI). En cas de rupture d’un lien, le trafic est automatiquement routé sur le second voire sur un troisième, etc.
ETUDE SUR UN PROBLEME REEL :
Configuration système / réseaux :
Dans la situation suivante nous avons 2 serveurs de base de données Linux ORACLE (ACTIVE /PASSIVE), 2 baies SAN EMC ainsi que 2 SWITCH DELL N2000. Les serveurs et baies SAN sont répartis dans 2 bâtiments ; les données des BDD Oracle sont écrites simultanément sur les 2 baies SAN grâce au service Multi-Pathing installé sur les 2 serveurs (mode round-robin). Tout est redondé et devrait continuer à fonctionner si 1 équipement tombe en panne.
Exemple du problème survenu :
De nombreux utilisateurs ont commencé à se plaindre de la lenteur de l’applicatif métier, le problème est très vite remonté aux Admins système car le service applicatif passait en condition dégradée, puis en arrêt de service.
1ère investigation : Vérification des performances des serveurs CPU/RAM ; OK, cependant beaucoup trop d’IO disque en attente.
2e : Vérification côté SAN ; aucun problème dans les LOG ou sur les performances du SAN.
3e : Vérification du SWITCH ; de nombreuses erreurs T/R sont détectées sur un port Ethernet, il s’agit d’un câble RJ45 HS.
Cause à effet dans le cas du Multipathing :
Dans le cas du câble Ethernet défectueux, il n’a pas été rejeté par le Switch car il le considère encore fonctionnel, puisque 50% des packets étaient encore correctement transmis. Mais les autres 50% polluaient le réseau avec de nombreuses trames en erreur, ce qui a incité le SAN à demander la retransmission de nombreuses fois les requête TCP en erreur.
Le fait que le SAN demande de nombreuses fois au serveur de retransmettre les requêtes TCP, a causé une attente des I/O très élevée sur le serveur.
De plus, la configuration du service multipath en mode roud-robin fait que les requêtes passent par plusieurs chemins au même moment ; le fait qu’un chemin sur les 8 disponibles soit plus lent va ralentir tous les autres chemins.
Extrait des configurations possibles pour le Multipath :
La solution :
Pour une meilleure fiabilité de la configuration multipath si vous ne supervisez pas les port Ethernet sur le serveur, je recommande de mettre le path selector en mode service-time : le chemin le plus rapide sera utilisé, les chemins lents ne seront pas priorisés.
Si vous souhaitez conserver le mode roud-robin pour des performances améliorées, il faut prévoir de superviser les interfaces réseaux sur le serveur afin de détecter des erreurs et corriger le problème rapidement.
Exemple de supervision de ports sur un serveur avec la solution Shinken Enterprise :
Shinken Entreprise : https://www.shinken-enterprise.com/fr/partenaires/