Alterações de zoning Fibre Channel, um fabric de cada vez

Dois fabrics Fibre Channel protegem-no de um switch morto. Não o protegem de uma alteração de zoning descuidada aplicada aos dois fabrics no mesmo minuto. A disciplina que fecha essa lacuna é simples de descrever e fácil de saltar: altere um fabric, prove-o, e só então toque no outro.

Porque é que o zoning é a tarefa de rotina mais arriscada numa SAN

O zoning decide que initiators (portas HBA dos hosts) podem falar com que targets (portas do array). Muda sempre que um servidor é acrescentado, substituído ou retirado, por isso é trabalho de rotina, e o trabalho de rotina é onde a atenção se dispersa. Num fabric Brocade, a configuração de zoning ativa é um único objeto. Quando ativa uma nova versão dela, todo o fabric recebe a nova versão de uma vez. Uma gralha que deixa cair uma zona, um membro colado na zona errada ou uma configuração ativada antes de estar terminada podem retirar instantaneamente o acesso de um host de produção aos seus discos nesse fabric.

Num fabric único, isso é uma indisponibilidade. Num fabric duplo corretamente construído, é uma perda de caminho, desde que o outro fabric não tenha sido alterado da mesma forma ao mesmo tempo. Muitos operadores preparam um script e correm-no nos dois switches, um a seguir ao outro. Isso transforma dois fabrics independentes num ponto de falha partilhado: a pessoa que tem o script na mão.

Desenhe as zonas para que os erros sejam visíveis

Single initiator zoning. Cada zona contém uma porta HBA de host e as portas do array que ela deve ver. Os hosts nunca partilham uma zona, por isso uma HBA que se comporte mal não consegue perturbar os vizinhos, e remover um host significa remover as suas zonas e nada mais.

Aliases, não WWPN em bruto. Cada porta recebe um alias, e as zonas são construídas a partir de aliases.

Uma regra de nomes que carrega o fabric. Ponha a letra do fabric em cada nome de alias e de zona, para que uma zona do Fabric A colada no Fabric B seja obviamente errada para quem lê a alteração. Limite os nomes a letras maiúsculas, dígitos e underscores. Alguns fabrics recusam hífenes e outros caracteres em nomes de objetos, e os nomes distinguem maiúsculas de minúsculas, por isso uma convenção usada em todo o lado elimina uma classe inteira de erros.

alias:  WEB01_HBA_A          -> <host port WWPN, fabric A>
alias:  ARRAY1_N0_P1_A       -> <array port WWPN, fabric A>
zone:   Z_WEB01_A__ARRAY1    -> WEB01_HBA_A; ARRAY1_N0_P1_A; ARRAY1_N1_P1_A
config: CFG_FABRIC_A

Antes de começar: verificação prévia

Guarde o estado atual dos dois fabrics antes de alterar o que quer que seja:

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

O nsshow (o name server) confirma que as portas do novo host fizeram realmente login no fabric e mostra os WWPN tal como o switch os vê, que é a partir do que deve construir os aliases, e não de uma etiqueta numa caixa. O cfgtransshow diz-lhe se outra pessoa tem uma transação de zoning aberta neste fabric. Se houver uma aberta e não for sua, pare e descubra de quem é.

Em cada host existente que a alteração possa tocar, registe as contagens de caminhos (multipath -ll), para poder provar depois que nada mudou para eles.

A alteração em si, um fabric de cada vez

Comece pelo fabric que preferiria perder. Construa a alteração inteira numa única sessão, como uma única transação:

alicreate "WEB01_HBA_B", "<host port WWPN, fabric B>"
zonecreate "Z_WEB01_B__ARRAY1", "WEB01_HBA_B; ARRAY1_N0_P2_B; ARRAY1_N1_P2_B"
cfgadd "CFG_FABRIC_B", "Z_WEB01_B__ARRAY1"
cfgenable "CFG_FABRIC_B"

O cfgenable guarda a configuração e torna-a ativa num só passo, e pede confirmação antes de fazer commit. Se o puser num script, o script tem de responder a esse prompt e depois ler a saída à procura da mensagem de commit, não assumir sucesso só porque o comando retornou. Nada está em produção até o enable terminar, que é a sua última oportunidade de ler a alteração preparada mais uma vez com cfgshow.

Depois verifique, a partir de três sítios:

1. O switch. O cfgactvshow contém a nova zona, e todas as zonas que lá estavam antes continuam lá.
2. O array. A porta do novo host neste fabric aparece agora ligada às portas do array esperadas.
3. Os hosts. O novo host vê os seus volumes através da porta HBA deste fabric. Os hosts existentes mostram exatamente as contagens de caminhos que registou na verificação prévia.

No novo host Linux, um rescan e uma olhadela à HBA chegam:

cat /sys/class/fc_host/host*/port_state
rescan-scsi-bus.sh
multipath -ll

Só quando os três concordam é que repete a mesma alteração no outro fabric, construída da mesma forma e verificada da mesma forma. Se alguma coisa parecer errada no primeiro fabric, pára aí. A produção continua a correr no fabric intocado, e tem a sua configuração guardada para restaurar.

Depois da alteração

Atualize o inventário na mesma sessão, para que o fabric e o registo nunca discordem.

Como o fazemos

Os nossos fabrics são construídos como dois fabrics Brocade totalmente independentes, desde os switches core até aos switches embutidos nos nossos enclosures de blades HPE. Um lote de servidores novos pode ser colocado em zonas um fabric de cada vez em poucos minutos de tempo de alteração do fabric, enquanto as zonas que transportam produção ficam exatamente como estavam.

Se a sua próxima alteração de storage implicar tocar nos dois fabrics, teremos todo o gosto em rever o plano consigo antes de ele correr.

Fale com um engenheiro

Related (rows[1])

Relacionados: SAN Fibre Channel com fabric duplo em Brocade · Storage SAN enterprise em HPE 3PAR, all-flash · Bare metal servers em HPE e Dell