Votre inventaire est une hypothèse tant que le réseau ne l'a pas confirmé

Tout inventaire de datacenter commence exact et dérive dès le premier jour. Un serveur est déplacé, un câble est remplacé à la hâte, une adresse est réutilisée, et l'enregistrement cesse discrètement de décrire la réalité. Le remède n'est pas un tableur plus grand. C'est une habitude : traiter chaque enregistrement comme une affirmation, et la confronter au réseau réel chaque fois que vous l'écrivez ou que vous vous y fiez.

L'équipement en production a raison

La première règle est celle qui tranche toutes les disputes. Quand l'enregistrement et l'équipement sont en désaccord, l'équipement a raison et l'enregistrement est corrigé. Un DCIM réconcilié en continu avec le réseau en fonctionnement devient l'outil le plus utile que vous ayez à trois heures du matin.

Nous exploitons un DCIM auto-hébergé, construit sur RackTables et étendu par des modules qui tirent des données en direct des équipements : tables ARP, état des ports, zoning Fibre Channel, exports de stockage et configurations des switches. Ces extractions existent pour que l'enregistrement puisse être confronté au fil, et non cru sur parole.

Prouvez qu'une adresse est libre de trois façons

Un enregistrement qui dit « libre » est la première vérification, pas la dernière. Avant d'attribuer une adresse, nous la vérifions de trois façons :

• L'enregistrement. Est-elle allouée à quoi que ce soit dans le DCIM ?
• Les tables ARP. Un routeur ou un switch de ce segment l'a-t-il vue récemment ? Sur un équipement Cisco, show ip arp <address> répond en une seconde.
• Le fil lui-même. Depuis un hôte du même segment, la détection d'adresse dupliquée demande à tout le segment si quelqu'un possède l'adresse :

arping -D -I <interface> -c 3 <address>
echo $?    # 0 means nobody answered, 1 means the address is in use

Le ping est la plus faible des vérifications, parce qu'un hôte derrière un firewall n'y répondra pas, et c'est pourquoi l'ARP compte davantage sur le segment local. Si une vérification contredit l'enregistrement, la réponse en direct l'emporte, et vous enquêtez avant d'attribuer quoi que ce soit. Chaque attribution est ensuite suivie de ses enregistrements DNS direct et inverse, pour que chaque adresse du réseau se résolve en un nom qui dit ce qu'elle est.

Confirmez le matériel et ses liens

Lisez les adresses MAC sur la machine

Les adresses MAC recopiées à la main depuis une étiquette ou un devis sont fausses assez souvent pour compter. Avant qu'un serveur ne soit racké, son contrôleur de gestion peut déjà vous donner la vraie MAC de chaque port réseau, et sur les systèmes de lames, le châssis peut donner chaque MAC et chaque WWPN Fibre Channel de chaque baie. Lisez-les là et écrivez-les dans l'enregistrement. Quand le serveur est connecté, la table d'adresses MAC du switch doit montrer exactement les adresses que vous avez relevées, exactement sur les ports que vous aviez prévus.

Confirmez le câblage avec LLDP

Un plan de câblage est une déclaration d'intention. LLDP vous dit ce qui a réellement été connecté. Sur le switch :

show lldp neighbors detail

Sur un hôte Linux qui exécute lldpd :

lldpctl

Chaque côté annonce le voisin qu'il voit : nom du système et port. Comparez cela aux liens de l'enregistrement. Un serveur qui annonce le bon switch sur le mauvais port est une erreur de câblage attrapée avant qu'elle ne porte du trafic, plutôt qu'un après-midi de confusion plus tard.

Relisez chaque champ

Quand une construction ou un travail de câblage est terminé, relisez chaque champ que vous avez écrit depuis la base de données et comparez-le au plan : unités de rack, ports, adresses MAC, liens aux deux extrémités, identifiants de câbles, allocations d'adresses avec l'interface qui les porte, contrôleur de gestion, et pour les lames leur place dans le châssis. Un objet à moitié rempli est un travail inachevé, pas un brouillon à compléter plus tard. « Plus tard » est la façon dont les enregistrements dérivent.

Une garantie supplémentaire ne coûte rien et attrape étonnamment beaucoup : lancez régulièrement un rapport de doublons, parce que deux enregistrements pour une machine induisent autant en erreur qu'aucun.

Réconciliez aussi le fabric de stockage

Sur un fabric Fibre Channel, l'enregistrement doit contenir le WWPN de chaque port d'hôte, le port de switch où il atterrit, et les zones auxquelles il appartient. Le fabric lui-même peut confirmer les trois. Sur les switches Brocade, switchshow liste ce qui est connecté sur chaque port, nsshow liste les WWPN enregistrés dans le name server du fabric, et zoneshow affiche le zoning actif. Comparez-les à l'enregistrement sur les deux fabrics. Un hôte qui apparaît connecté sur un seul fabric est un hôte à une panne de switch de perdre ses disques, et la comparaison le trouve avant que cela n'arrive. Nous tirons le zoning des switches vers notre DCIM exactement pour cette raison, pour que l'enregistrement d'une zone soit la zone telle que le fabric l'applique.

Ne réutilisez jamais un identifiant de câble

Chaque câble que nous installons porte une étiquette plastifiée aux deux extrémités avec un identifiant de câble numérique unique et le rack, l'équipement, le port et la longueur de l'autre extrémité, et le même numéro est enregistré sur le lien dans le DCIM. La règle qui fait marcher ce système est celle que l'on est le plus tenté d'enfreindre : un identifiant de câble n'est jamais réutilisé, pas même le numéro d'un câble retiré depuis. Les nôtres viennent d'un allocateur dédié, sont réservés avant l'impression des étiquettes, et sont surveillés pour détecter les doublons. Pourquoi la méthode familière du « plus grand numéro plus un » échoue, et comment gérer l'allocation correctement, est le sujet de Numéroter les câbles : pourquoi « le plus grand plus un » est la mauvaise règle.

Construisez d'abord sur le papier

Tout cela se rejoint en une habitude : le nouveau matériel est entièrement dans l'enregistrement avant d'arriver. Unités de rack, contrôleurs de gestion, chaque port avec son adresse MAC, port-channels, les ports de switch à l'autre extrémité, et un identifiant de câble réservé pour chaque lien. Le jeu d'étiquettes est imprimé à l'avance, et le matériel est racké et câblé selon un plan qui est déjà l'enregistrement. La vérification à la fin est alors une comparaison, pas une reconstruction.

Vérifiez vos propres enregistrements

• Choisissez une adresse marquée libre et lancez les trois vérifications. Sont-elles d'accord ?
• Choisissez un serveur et comparez ses MAC enregistrées avec la table MAC du switch.
• Lancez LLDP sur un rack et comparez chaque lien avec l'enregistrement.
• Comparez les WWPN de chaque hôte dans l'enregistrement avec nsshow sur les deux fabrics.
• Cherchez tout numéro de câble qui apparaît sur deux liens.

Si vous planifiez une migration et voulez la construire à partir d'un enregistrement fiable, nous pouvons vous aider. Parler à un ingénieur

Related (rows[1])

Voir aussi : DCIM : chaque objet, port, câble et adresse suivis · Montage en rack, intégration des lames, contrôleurs de gestion · Suivi de la puissance et capacité