O seu inventário é uma hipótese até a rede o confirmar

Todos os inventários de datacenter começam exatos e começam a divergir desde o primeiro dia. Um servidor é mudado de sítio, um cabo é substituído à pressa, um endereço é reutilizado, e o registo deixa silenciosamente de descrever a realidade. A solução não é uma folha de cálculo maior. É um hábito: tratar cada registo como uma afirmação, e confrontá-la com a rede em produção sempre que a escreve ou depende dela.

O dispositivo em produção ganha

A primeira regra é a que resolve todas as discussões. Quando o registo e o dispositivo discordam, o dispositivo tem razão e o registo é corrigido. Um DCIM que é continuamente reconciliado com a rede em funcionamento torna-se a ferramenta mais útil que tem às três da manhã.

Operamos um DCIM self-hosted construído sobre RackTables e estendido com módulos que recolhem dados em tempo real dos dispositivos: tabelas ARP, estado das portas, zoning Fibre Channel, exports de storage e configurações de switches. As recolhas existem para que o registo possa ser confrontado com o cabo, não para serem acreditadas por si só.

Prove que um endereço está livre de três formas

Um registo que diz «livre» é a primeira verificação, não a última. Antes de atribuir qualquer endereço, verificamo-lo de três formas:

1. O registo. Está alocado a alguma coisa no DCIM?
2. As tabelas ARP. Algum router ou switch nesse segmento o viu recentemente? Em dispositivos Cisco, o show ip arp <address> responde num segundo.
3. O próprio cabo. A partir de um host no mesmo segmento, a deteção de endereços duplicados pergunta a todo o segmento se alguém é dono do endereço:

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

O ping é a mais fraca das verificações, porque um host atrás de uma firewall não lhe responde, e é por isso que o ARP conta mais no segmento local. Se alguma verificação discordar do registo, a resposta em produção ganha, e investiga-se antes de atribuir o que quer que seja. Cada atribuição é depois seguida pelos seus registos DNS, direto e inverso, para que todos os endereços da rede resolvam para um nome que diz o que são.

Confirme o hardware e as suas ligações

Leia os endereços MAC a partir da máquina

Os endereços MAC copiados à mão de um autocolante ou de um orçamento estão errados com frequência suficiente para contar. Antes de um servidor ir para o rack, o seu controlador de gestão já lhe consegue dizer a MAC real de cada porta de rede, e nos sistemas de blades o enclosure consegue dizer todas as MAC e todos os WWPN Fibre Channel de cada baia. Leia-os a partir daí e escreva-os no registo. Quando o servidor for ligado, a tabela de endereços MAC do switch deve mostrar exatamente os endereços que registou, exatamente nas portas que planeou.

Confirme a cablagem com LLDP

Um plano de cablagem é uma declaração de intenções. O LLDP diz-lhe o que foi realmente ligado. No switch:

show lldp neighbors detail

Num host Linux a correr lldpd:

lldpctl

Cada lado reporta o vizinho que vê: nome do sistema e porta. Compare isso com as ligações no registo. Um servidor que reporta o switch certo na porta errada é um deslize de cablagem apanhado antes de transportar tráfego, em vez de uma tarde de confusão mais tarde.

Releia cada campo

Quando uma montagem ou um trabalho de cablagem termina, leia cada campo que escreveu de volta a partir da base de dados e compare-o com o plano: unidades de rack, portas, endereços MAC, ligações nas duas pontas, cable IDs, alocações de endereços com a interface em que vivem, controlador de gestão e, para os blades, o seu lugar no enclosure. Um objeto meio preenchido é trabalho inacabado, não um rascunho para completar mais tarde. O «mais tarde» é a forma como os registos divergem.

Mais uma salvaguarda é barata e apanha uma quantidade surpreendente: corra regularmente um relatório de duplicados, porque dois registos para uma máquina são tão enganadores como nenhum.

Reconcilie também o fabric de storage

Num fabric Fibre Channel, o registo deve guardar o WWPN de cada porta de host, a porta de switch onde aterra e as zonas a que pertence. O próprio fabric consegue confirmar as três. Em switches Brocade, o switchshow lista o que está em login em cada porta, o nsshow lista os WWPN registados no name server do fabric, e o zoneshow imprime o zoning ativo. Compare-os com o registo nos dois fabrics. Um host que aparece em login apenas num fabric é um host a uma falha de switch de perder os seus discos, e a comparação encontra-o antes de isso acontecer. Recolhemos o zoning dos switches para o nosso DCIM exatamente por esta razão, para que o registo de uma zona seja a zona tal como o fabric a impõe.

Nunca reutilize um cable ID

Cada cabo que instalamos leva uma etiqueta plastificada nas duas pontas com um cable ID numérico único e o rack, o dispositivo, a porta e o comprimento da outra ponta, e o mesmo número é registado na ligação no DCIM. A regra que faz isto funcionar é a que as pessoas mais se sentem tentadas a quebrar: um cable ID nunca é reutilizado, nem sequer o número de um cabo entretanto removido. Os nossos vêm de um alocador dedicado, são reservados antes de as etiquetas serem impressas e são vigiados quanto a duplicados. Porque é que o método familiar «o número mais alto mais um» falha, e como fazer a alocação como deve ser, é o tema de Numerar cabos: porque é que «o mais alto mais um» é a regra errada.

Construa primeiro no papel

Tudo isto converge num hábito: o hardware novo está completamente no registo antes de chegar. Unidades de rack, controladores de gestão, cada porta com o seu endereço MAC, port-channels, as portas de switch na outra ponta, e um cable ID reservado para cada ligação. O conjunto de etiquetas é impresso com antecedência, e o hardware é montado no rack e cablado segundo um plano que já é o registo. A verificação no fim é então uma comparação, não uma reconstrução.

Verifique os seus próprios registos

• Escolha um endereço marcado como livre e corra as três verificações. Concordam?
• Escolha um servidor e compare as MAC registadas com a tabela MAC do switch.
• Corra LLDP num rack e compare cada ligação com o registo.
• Compare os WWPN de cada host no registo com o nsshow nos dois fabrics.
• Procure qualquer número de cabo que apareça em duas ligações.

Se está a planear uma migração e quer que seja construída a partir de um registo em que pode confiar, podemos ajudar. Fale com um engenheiro

Related (rows[1])

Relacionados: DCIM: cada objeto, porta, cabo e endereço registados · Montagem em rack, integração de blades, controladores de gestão · Monitorização de energia e capacidade