Su inventario es una hipótesis hasta que la red lo confirma

Todo inventario de datacenter empieza exacto y se desvía desde el primer día. Se mueve un servidor, se sustituye un cable con prisas, se reutiliza una dirección, y el registro deja de describir la realidad sin hacer ruido. La solución no es una hoja de cálculo más grande. Es un hábito: trate cada registro como una afirmación, y compruébela contra la red en vivo cada vez que la escriba o se apoye en ella.

El dispositivo en vivo gana

La primera regla es la que zanja todas las discusiones. Cuando el registro y el dispositivo no coinciden, el dispositivo tiene razón y el registro se corrige. Un DCIM reconciliado de forma continua con la red en funcionamiento se convierte en la herramienta más útil que tiene a las tres de la madrugada.

Operamos un DCIM self-hosted construido sobre RackTables y ampliado con módulos que extraen datos en vivo de los dispositivos: tablas ARP, estado de puertos, zoning Fibre Channel, exports de storage y configuraciones de switches. Las extracciones existen para que el registro pueda comprobarse contra el cable, no para creérselo por sí solo.

Demuestre que una dirección está libre de tres formas

Un registro que dice «libre» es la primera comprobación, no la última. Antes de asignar cualquier dirección la comprobamos de tres formas:

1. El registro. ¿Está asignada a algo en el DCIM?
2. Las tablas ARP. ¿La ha visto recientemente algún router o switch de ese segmento? En dispositivos Cisco, show ip arp <address> responde en un segundo.
3. El propio cable. Desde un host del mismo segmento, la detección de direcciones duplicadas pregunta a todo el segmento si alguien posee la dirección:

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

El ping es la más débil de las comprobaciones, porque un host detrás de un firewall no responderá, y por eso el ARP cuenta más en el segmento local. Si cualquiera de las comprobaciones discrepa del registro, gana la respuesta en vivo, y usted investiga antes de asignar nada. A cada asignación le siguen después sus registros DNS directo e inverso, para que cada dirección de la red resuelva a un nombre que diga lo que es.

Confirme el hardware y sus enlaces

Lea las direcciones MAC desde la máquina

Las direcciones MAC copiadas a mano de una pegatina o de un presupuesto están mal con la frecuencia suficiente como para importar. Antes de que un servidor entre en el rack, su controlador de gestión ya puede decirle la MAC real de cada puerto de red, y en los sistemas de blades el chasis puede decirle cada MAC y cada WWPN Fibre Channel de cada bahía. Léalas de ahí y escríbalas en el registro. Cuando el servidor se conecte, la tabla de direcciones MAC del switch debe mostrar exactamente las direcciones que anotó, exactamente en los puertos que planificó.

Confirme el cableado con LLDP

Un plan de cableado es una declaración de intenciones. LLDP le dice qué se conectó de verdad. En el switch:

show lldp neighbors detail

En un host Linux que ejecuta lldpd:

lldpctl

Cada lado informa del vecino que ve: nombre de sistema y puerto. Compárelo con los enlaces del registro. Un servidor que informa del switch correcto en el puerto equivocado es un desliz de cableado detectado antes de llevar tráfico, en lugar de una tarde de confusión más adelante.

Relea cada campo

Cuando un montaje o un trabajo de cableado termina, lea de vuelta desde la base de datos cada campo que escribió y compárelo con el plan: unidades de rack, puertos, direcciones MAC, enlaces en ambos extremos, cable IDs, asignaciones de direcciones con la interfaz en la que viven, controlador de gestión y, para los blades, su posición en el chasis. Un objeto a medio rellenar es trabajo sin terminar, no un borrador para completar más tarde. «Más tarde» es la forma en que se desvían los registros.

Una salvaguarda más es barata y detecta una cantidad sorprendente de cosas: ejecute un informe de duplicados con regularidad, porque dos registros para una máquina engañan tanto como ninguno.

Reconcilie también el fabric de storage

En un fabric Fibre Channel, el registro debe guardar el WWPN de cada puerto de host, el puerto de switch en el que aterriza y las zonas a las que pertenece. El propio fabric puede confirmar las tres cosas. En switches Brocade, switchshow lista qué ha hecho login en cada puerto, nsshow lista los WWPN registrados en el name server del fabric y zoneshow imprime el zoning activo. Compárelos con el registro en los dos fabrics. Un host que aparece con login en un solo fabric es un host a un fallo de switch de perder sus discos, y la comparación lo encuentra antes de que ocurra. Extraemos el zoning de los switches a nuestro DCIM exactamente por eso, para que el registro de una zona sea la zona tal como la aplica el fabric.

Nunca reutilice un cable ID

Cada cable que instalamos lleva una etiqueta plastificada en los dos extremos con un cable ID numérico único y el rack, el dispositivo, el puerto y la longitud del extremo lejano, y el mismo número se registra en el enlace del DCIM. La regla que hace que esto funcione es la que más tienta romper: un cable ID nunca se reutiliza, ni siquiera el número de un cable ya retirado. Los nuestros salen de un allocator dedicado, se reservan antes de imprimir las etiquetas y se vigilan por si hay duplicados. Por qué falla el método familiar de «el número más alto más uno», y cómo ejecutar bien la asignación, es el tema de Numerar cables: por qué «el más alto más uno» es la regla equivocada.

Construya primero sobre el papel

Todo esto converge en un hábito: el hardware nuevo está completo en el registro antes de llegar. Unidades de rack, controladores de gestión, cada puerto con su dirección MAC, port-channels, los puertos de switch del otro extremo y un cable ID reservado para cada enlace. El juego de etiquetas se imprime por adelantado, y el hardware se monta en el rack y se cablea contra un plan que ya es el registro. La verificación al final es entonces una comparación, no una reconstrucción.

Compruebe sus propios registros

• Elija una dirección marcada como libre y ejecute las tres comprobaciones. ¿Coinciden?
• Elija un servidor y compare sus MAC registradas con la tabla MAC del switch.
• Ejecute LLDP en un rack y compare cada enlace con el registro.
• Compare los WWPN de cada host en el registro con nsshow en los dos fabrics.
• Busque cualquier número de cable que aparezca en dos enlaces.

Si planifica una migración y quiere que se construya a partir de un registro en el que pueda confiar, podemos ayudar. Hable con un ingeniero

Related (rows[1])

Relacionado: DCIM: cada objeto, puerto, cable y dirección registrados · Montaje en rack, onboarding de blades, controladores de gestión · Medición de potencia y capacidad