Est-ce que je fais cela correctement ? Réseau - Haute disponibilité : SAN, Cluster de basculement Microsoft, Agrégation de cartes réseau

J’ai travaillé dans un environnement de laboratoire pour déterminer comment concevoir un SAN avec un cluster de basculement Microsoft utilisant plusieurs cartes réseau, MPIO et iSCSI. J’essaierai d’ajouter autant d’informations utiles que possible, pardonnez-moi si je manque des détails… C’est une toute nouvelle expérience d’apprentissage pour moi.

Objectif :
Augmenter la disponibilité/tolérance aux pannes en ajoutant un second chemin (commutateur) de chaque nœud du cluster vers le stockage. Permettre aux clients du réseau d’accéder aux ressources/services fonctionnant dans le cluster.

Ce que j’ai fait jusqu’à présent :
J’ai configuré et mis en place avec succès un cluster à 2 nœuds avec MPIO et iSCSI. Ils partagent le stockage via un CSV sur un NAS QNAP. Chaque nœud a 2 cartes réseau dans une équipe Switch Embedded. Chaque carte réseau est connectée à l’un des commutateurs. Chaque port Ethernet QNAP (il n’y en a que 2) est également connecté à l’un des commutateurs. J’ai créé les adaptateurs réseau virtuels suivants dans l’OS hôte…

  • Management 192.168.1.XX

  • CSV 10.10.10.XX

  • Live Migration 10.10.40.XX

  • iSCSI-01 10.10.20.XX

  • iSCSI-02 10.10.30.xx

Les commutateurs que j’utilise dans le laboratoire sont des commutateurs de couche 3 assez basiques. Je n’ai fait aucune configuration dessus car je ne sais pas s’il y a quelque chose que je dois faire. Tout semble fonctionner correctement tant que les deux commutateurs sont reliés l’un à l’autre via un câble Ethernet. Comme le QNAP n’a que 2 ports Ethernet, j’ai dû créer un chemin pour que les nœuds puissent atteindre la 2ème cible iSCSI du QNAP sur le second commutateur. C’est une configuration bricolée, mais ça fonctionne. J’ai simulé des pannes en débranchant l’une des connexions à un nœud… tout va bien de ce côté.

Ce que je ne sais pas :
Mon laboratoire est limité aux nœuds, aux 2 commutateurs et au NAS. Je ne sais pas quelles seraient les prochaines étapes appropriées pour intégrer cela dans un réseau afin que les clients puissent accéder aux ressources dans le cluster. S’il n’y avait qu’un seul commutateur SAN/« fabric » (est-ce le bon terme ?), pas de problème. Je le relierais simplement à un autre commutateur connecté aux clients… C’est ainsi que notre configuration actuelle fonctionne.

Au début, je pensais que ça allait juste fonctionner par une sorte de magie (c’est ce que le réseau est pour moi), mais j’ai le sentiment que je manque quelque chose. Y aura-t-il un problème avec la façon dont le trafic circule en reliant les deux commutateurs SAN à un seul commutateur LAN ? Je ne suis même pas sûr que ce soit la « bonne » chose à faire.

Je sais qu’il me manque un routeur dans cette équation… Cela ne semblait pas nécessaire pour cette expérience de laboratoire puisque je ne faisais aucun routage. En production, notre réseau est segmenté avec des VLAN.

Quoi qu’il en soit… Voici un diagramme de ce à quoi je pense que cela ressemblera en production.
Diagramme réseau.

Modification : Ou devrais-je faire quelque chose comme cela ?? Le SAN devrait-il se connecter au LAN via les commutateurs SAN ou les serveurs devraient-ils se connecter directement au LAN via un commutateur ?

(1) Stockage. QNAP ferait une cible de sauvegarde correcte, par exemple utilisé via iSCSI avec Veeam, mais c’est un assez mauvais choix en termes de stockage principal. Les performances ne sont pas excellentes, mais le pire est… C’est un contrôleur unique, donc un temps d’arrêt planifié ou non planifié du stockage entraînerait l’arrêt de votre cluster entier. Pas bon !

https://en.wikipedia.org/wiki/Single_point_of_failure

(2) Commutateurs. Pour l’iSCSI, ils devraient avoir des tampons Tx/Rx assez importants sinon vous verrez des blocages aléatoires et des pics de latence d’E/S pendant les charges lourdes. Cela entraînerait le gel et le plantage des VM. Parfois… Voici quelques bonnes lectures sur le sujet :

https://community.arubanetworks.com/discussion/iscsi-and-packet-buffer

https://community.cisco.com/t5/switching/iscsi-switch-recommendations/td-p/1771478

En résumé… Ce que vous devriez faire, c’est vous débarrasser de votre configuration actuelle et passer à une configuration 100% hyperconvergée. Ajoutez du flash et des disques rotatifs dans vos deux nœuds de cluster, activez Storage Spaces Direct ou StarWind Virtual SAN (Gratuit ?). Ces deux solutions supportent très bien la configuration sans commutateur, vous n’aurez donc qu’à connecter directement vos deux nœuds de cluster avec une paire de cartes réseau 10 GbE ou 25 GbE sans infrastructure commutée ! Aucun commutateur ne peut surpasser un câble cuivre en termes de latence et de coût ! Vos commutateurs existants assureraient la connectivité frontale avec deux chemins redondants de vos clients vers le cluster HCI lui-même. Une conception très élégante et bien plus fiable.

https://learn.microsoft.com/en-us/azure-stack/hci/concepts/storage-spaces-direct-overview

https://www.starwindsoftware.com/starwind-virtual-san

Storage Spaces Direct est une solution de premier plan et mérite d’être mentionné, mais il est plutôt fragile, nécessite la coûteuse édition Datacenter, et la configuration S2D à deux nœuds avec résilience imbriquée ne peut pas évoluer au-delà de la configuration initiale à deux nœuds. StarWind est bien plus fiable, fonctionne avec l’édition Standard, peut être 100% gratuit et évolue comme vous le souhaitez.

(3) Sauvegarde. Vous pouvez réutiliser le QNAP et utiliser Veeam gratuit pour gérer cela. Respectez la règle de sauvegarde 3-2-1 et vous serez tranquille !

https://www.backblaze.com/blog/the-3-2-1-backup-strategy/

https://www.veeam.com/virtual-machine-backup-solution-free.html

J’espère que tout cela a aidé au moins un peu…