Fenêtres de maintenance : ce qui se fait sous charge à la place

Deux sortes de travaux planifiés

Les travaux planifiés se répartissent en deux groupes. Le premier est absorbé par la conception : un contrôleur de stockage qui reçoit un nouveau firmware, un leaf switch remplacé, un hôte hyperviseur arrêté pour de la mémoire, une paire de firewalls qui déroule une mise à jour. Le second change quelque chose qui n'a pas de partenaire à ce moment-là : une bascule de plateforme, la synchronisation finale d'une migration de stockage, un changement de schéma irréversible. Le premier groupe se fait sous charge. Le second reçoit une fenêtre, et la fenêtre est conçue plutôt que simplement annoncée.

Ce que la conception absorbe

Une baie HPE 3PAR porte deux nœuds contrôleurs qui servent les mêmes volumes, chaque hôte étant raccordé par deux fabrics Brocade indépendants. Le firmware se pose sur un nœud à la fois. Pendant qu'il redémarre, la couche multipath des hôtes maintient le flux d'I/O sur les chemins survivants, et le nœud rejoint l'ensemble avant qu'on touche au second. Le même schéma s'applique à chaque couche construite en paires. Les leaves Cisco Nexus 9000 sont déployés par paires, chaque hôte étant agrégé sur les deux, de sorte qu'un switch peut recevoir une mise à niveau ou un remplacement pendant que l'autre lien porte le trafic. Les hôtes hyperviseurs sont vidés par live migration avant qu'on leur fasse quoi que ce soit, et les machines virtuelles reviennent ensuite. Les routeurs edge tiennent des sessions avec plus d'un opérateur, et une session est vidée avant qu'on touche à son routeur.

Rien de tout cela n'est inhabituel dans un datacenter sérieux. Ce qui compte, c'est si les paires sont exercées. Un partenaire qui existe sur le schéma mais n'a pas porté la production est une supposition, et le moment de découvrir que c'était une supposition n'est pas pendant le changement.

Vérifier le partenaire avant de toucher au principal

La discipline utile est le contrôle qui a lieu avant le changement. Avant d'arrêter un contrôleur, on demande à chaque hôte raccordé combien de chemins actifs il tient vers la baie. Un hôte qui ne rapporte qu'un seul chemin est corrigé d'abord, parce que pour cet hôte la fenêtre arriverait sans invitation. Avant de toucher à un switch, on lit le bond sur chaque hôte pour confirmer que les deux membres sont up et passent du trafic, et on confirme que le second switch commute et pas seulement qu'il est sous tension. Avant de vider un hôte, on confirme que la cible de migration a la marge pour ce qui arrive.

# on each attached host, before controller work: every LUN should show two or more active paths
$ multipath -ll | grep -c 'active ready'

# before switch work: both bond members up and passing traffic
$ grep -E 'Slave Interface|MII Status' /proc/net/bonding/bond0

Puis le changement est fait, et les mêmes relevés sont pris de nouveau pendant que le partenaire rejoint l'ensemble. Le résultat, ce sont des travaux planifiés qui ne vous interrompent pas, ce qui est différent de travaux planifiés qui ne sont pas communiqués : le changement est dans notre journal et, là où il touche votre plateforme, dans votre boîte de réception, avec le mécanisme énoncé.

Les changements qui méritent une fenêtre

Une fenêtre est la bonne réponse quand une étape est irréversible, quand le composant n'a par nature pas de partenaire à ce moment-là, ou quand la procédure du constructeur exige que le service soit mis au repos. La bascule de plateforme est le cas courant : au moment où le trafic passe de l'ancien environnement au nouveau, il y a un intervalle, en général borné par la propagation DNS ou le déplacement d'une VIP, pendant lequel le service est en transit.

Une fenêtre bien conçue se reconnaît. Elle nomme le composant et le mécanisme, pour que vous sachiez ce qui change et pourquoi cela ne peut pas se faire sous charge. Elle énonce l'impact visible pour le client séparément de la durée de l'opération : une opération de deux heures peut avoir un impact visible de quelques minutes, et l'avis dit lequel est lequel. Elle a un point de décision et un retour arrière qui a été répété, pas seulement décrit. Elle est convenue avec vous : si un changement peut toucher votre trafic, nous convenons d'abord de l'horaire avec vous. Et elle se termine par un rapport qui compare le réel à l'annoncé.

Lire un avis de maintenance

Trois questions vous disent l'essentiel de ce que vous devez savoir sur la conception sous n'importe quelle plateforme, la nôtre comprise : quel est le composant, pourquoi cela ne peut pas se faire sous charge, et quel est l'impact visible attendu par rapport à la durée de l'opération. Un avis qui répond aux trois est un plan. Nous écrivons les nôtres pour qu'ils y répondent.