Un switch peut mourir et votre stockage continue de servir
Le disque de votre VM vit sur une baie dédiée, accessible par deux réseaux de stockage qui ne partagent rien. Les deux sont actifs à tout instant, de sorte qu'un switch mort, un câble arraché ou tout un réseau sorti pour maintenance n'est pas un événement pour la charge de travail.
Dans cet article 4 sections
- Chaque hôte de notre SAN atteint son stockage par deux fabrics Fibre Channel complètement indépendants, avec des switches séparés, en mode actif/actif.
- Un switch, un câble ou un port peut tomber et votre LUN continue de servir par l'autre chemin. Les deux chemins transportent des I/O de production en permanence, donc il n'y a pas de standby à réveiller ni de bascule à survivre.
- Le RAID à l'intérieur d'un seul serveur couvre une seule panne, un disque mort. Tout le reste dans cette boîte emporte votre stockage avec lui.
- La conception permet de sortir tout un fabric du service avec chaque machine virtuelle qui tourne encore sur l'autre.
Le disque sur lequel votre charge de travail écrit ne vit pas dans le serveur qui la fait tourner. Il vit sur une baie de stockage à un réseau de distance, et ce réseau peut tomber comme n'importe quoi d'autre : des switches meurent, des câbles sont arrachés, des ports se mettent à battre. Ce qui décide si votre charge de travail le remarque un jour, c'est s'il existe une seconde route vers le disque, et si cette seconde route est vraiment séparée de la première.
Le multipath donne à chaque hôte deux routes vivantes vers son LUN
Un LUN est le périphérique bloc que votre machine virtuelle voit comme son disque. Sur un SAN, ce disque vit hors du serveur qui fait tourner votre charge de travail, sur une baie all-flash dédiée à double contrôleur, et le serveur l'atteint par un réseau de stockage. Multipath signifie que le serveur tient plus d'une route physique vers le même LUN en même temps, par des ports différents, des câbles différents et des switches différents.
Actif/actif signifie que les deux routes transportent du trafic chaque seconde de la journée. Un chemin de secours qui ne se réveille qu'en cas de panne est un chemin que vous n'avez jamais vraiment testé, et la panne est le pire moment possible pour son premier test. Quand les deux chemins transportent des I/O vivantes en continu, en perdre un laisse simplement l'autre faire tout le travail dont il faisait déjà la moitié. La charge de travail ne voit rien, parce que de là où elle se trouve, rien ne s'est passé.
Deux ports HBA sur l'hôte
Deux câbles, sur deux cheminements séparés
Deux switches, un par fabric
Deux fabrics Fibre Channel, tous deux actifs/actifs
Les deux fabrics ne partagent aucun switch, donc une panne ne peut pas passer de l'un à l'autre
Deux chemins par le même switch, c'est un seul chemin avec deux étiquettes. Ce qui tue le switch tue les deux. Une vraie indépendance signifie que les deux fabrics sont construits comme deux réseaux séparés avec des switches séparés, et que rien dans le chemin de données entre l'hôte et la baie n'apparaît dans les deux. Une panne dans un fabric, qu'il s'agisse d'un switch mort, d'un port qui bat ou d'un lien congestionné, n'a nulle part où se propager. Le second fabric n'en entend pas parler.
Un fabric Fibre Channel est le réseau commuté entre les serveurs et les baies de stockage, l'équivalent de votre LAN pour le stockage. En faire tourner deux, entièrement séparés, signifie que le trafic de stockage a toujours un second réseau où vivre. Les pannes coûteuses en réseau de stockage sont rarement des morts propres. Ce sont des liens qui restent actifs mais se figent, et l'indépendance est ce qui garde ce genre de maladie confiné à un seul côté.
Le RAID à l'intérieur d'un serveur meurt avec le serveur
Le RAID sur une carte contrôleur à l'intérieur de votre serveur vous protège d'exactement une chose, un disque mort, et il le fait bien. Mais les disques, la carte RAID, le fond de panier, les alimentations et la carte mère vivent tous dans la même boîte, et la boîte est le domaine de défaillance. Quand n'importe quoi d'autre à l'intérieur meurt, votre stockage s'en va avec, et il revient quand le serveur revient. Si la carte RAID elle-même tombe, les disques les plus sains du monde sont inaccessibles.
Un SAN sort le disque du domaine de défaillance de la machine qui l'utilise. Votre serveur peut mourir et le LUN sur lequel il écrivait une seconde plus tôt est toujours là, intact et en service, prêt pour que la charge de travail redémarre sur un autre hôte. La conception à double fabric étend la même idée à la route entre les deux : le chemin vers votre stockage a le droit de tomber lui aussi, c'est pourquoi nous en avons construit deux.
| Ce qui tombe | Ce que vos charges de travail voient |
|---|---|
| Un câble ou un port | Le LUN continue de servir par l'autre chemin. Pas de bascule, pas de redémarrage. |
| Un switch entier | Le second fabric transporte tout. Rien ne se réveille ni ne bascule. |
| Un fabric entier, sorti pour maintenance | Chaque hôte garde un bon chemin sur le fabric sain pendant les travaux. |
| Un nœud contrôleur de stockage | Le second contrôleur continue de servir pendant le remplacement du matériel. |
| Le serveur lui-même | Le LUN lui survit. La charge de travail redémarre sur un autre hôte et retrouve son disque là où elle l'a laissé. |
Sortir tout un fabric du service sous des charges de travail vivantes
Quand un fabric a besoin de maintenance, la procédure n'a rien de spectaculaire : nous confirmons que chaque hôte tient un bon chemin sur l'autre fabric, nous sortons le fabric du service, nous faisons le travail, puis nous le réintroduisons délibérément. Les machines virtuelles tournent sur un seul fabric pendant les travaux et ne voient rien. C'est la bonne quantité de drame pour une maintenance de stockage.
La même posture vaut côté baie. Les baies sont à double contrôleur : un contrôleur peut être entretenu pendant que l'autre continue de servir. Le matériel est entretenu sur notre SAN comme il devrait l'être partout : pendant que la chose à laquelle il appartient continue de faire son travail.
Réponses directes
Actif/actif, est-ce juste un mot plus joli pour failover ?+
Non. Une conception en failover garde un second chemin inactif jusqu'à ce que le premier meure, puis tente une bascule dans les pires conditions de la journée. Actif/actif signifie que les deux fabrics transportent des I/O de production en permanence, donc une panne retire un chemin qui fonctionne pendant que l'autre chemin qui fonctionne continue. Il n'y a pas d'événement de bascule à survivre ni de standby qui passe son premier test pendant votre incident.
Mon serveur a du RAID-10. Est-ce la même protection ?+
Le RAID à l'intérieur du serveur protège vos données d'un disque mort, et seulement de cela. La carte RAID, le fond de panier, les alimentations et le serveur lui-même restent des points uniques de défaillance, et votre stockage partage leur sort. Sur un SAN, le stockage survit à la mort du serveur qui l'utilise, et avec deux fabrics il survit aussi à la mort de la route entre les deux.
Et si toute la baie tombe, ou tout le site ?+
Autre classe de panne, autres outils. Cet article couvre les chemins entre un hôte sain et une baie saine, là où vivent les pannes de tous les jours. Survivre à la perte d'une baie ou d'un site est une conversation de reprise, et nous l'avons écrite à part : quelle perte de données et quelle interruption votre entreprise peut honnêtement tolérer.
Comment savoir que les deux chemins fonctionnent vraiment avant que l'un ne tombe ?+
Parce que les deux fabrics transportent des I/O vivantes en continu, un chemin mort n'est pas un état silencieux : à l'instant où un côté cesse de faire passer du trafic, cela remonte dans la supervision. Et chaque maintenance commence de la même façon, en confirmant que chaque hôte tient un bon chemin sur le fabric restant, avant de sortir quoi que ce soit du service.
Demandez à un ingénieur sur quoi repose vraiment votre stockage
Les gens qui conçoivent et exploitent les fabrics sont ceux qui répondent. Apportez votre installation actuelle et nous vous dirons clairement ce qui survit à quoi.
Parler à un ingénieurSwitches morts, câbles arrachés et maintenance de contrôleurs sont les pannes que cette conception met à la retraite. Perdre une baie entière ou un site entier est une autre classe de panne, et celle-là commence par la conversation de reprise. Si vous évaluez des hébergeurs, les questions sur le stockage qu'il vaut la peine de poser à n'importe qui, nous compris, sont dans le sale petit secret de votre hébergeur, c'est son stockage.
Vous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur