Práticas recomendadas para adicionar o segundo switch FC ao fabric no ambiente de produção?

Question

Eu tenho um único comutador Brocade Silkworm 200e em produção agora. O servidor de troca corp e 3 hosts ESX 3.5 são conectados ao array clariion cx3 através dele. A porta 0,1 é SPA0 e 1 e a porta 4,5 são SPB0 e 1.

Meu plano é adicionar um comutador Brocade Silkworm 300 ao lado do 200 (ele já está montado e ligado), ir ao datacenter e extrair SPA1 e SPB0 dos 200 e inseri-los nas portas do switch 300.

Estou um pouco paranóico ao extrair caminhos FC que estão em produção. Eu tenho uma suposição lógica de que as coisas vão apenas falhar no SPA0 e SPB1 e A1 e B0 não serão perdidas. No entanto, eu gostaria de ter 100% de compreensão firme do que eu poderia fazer para minimizar ainda mais os riscos, se possível.

Se um LUN é atualmente propriedade do SPA, ele utiliza automaticamente o SPA0 e o SPA1 no round robin ou o switch prefere um caminho específico exclusivamente a menos que falhe dele? Exemplo - é um servidor de troca usando SPA0 ou SPA1, ou usa 0 e 1 ativo / ativo?

Suponho que, se estiver usando os dois caminhos para um SP ativo / ativo, interromper um deles é menos arriscado, porque tenho certeza de que ele já está usando o outro caminho sem problemas. Estou com medo de forçar o failover para um caminho alternativo que ele não usou antes e depois descobrir que o cabo estava ruim ou algo assim.

Devo ser totalmente prejudicial para a empresa e desligar todas as máquinas virtuais e o servidor Exchange apenas para garantir que não ocorra corrupção de dados no caso de um failover incorreto? Ou isso é excessivo? De qualquer forma, eu farei a operação imediatamente após um ciclo de backup completo.

Como você monitoraria o failover quando isso acontece? O brocado 200e vai registrá-lo em detalhes? Eu quero máxima garantia de que tudo ainda está funcionando quando eu puxo esses plugues. Posso verificar novamente o armazenamento nos hosts esx e assistir ao monitor do caminho de energia da troca. Qualquer coisa melhor que eu possa estar fazendo?

Eu prefiro ser muito mais cauteloso do que os méritos da situação do que fazer suposições excessivamente confiantes sobre como fazer algo assim pela primeira vez, quando todos os nossos ovos estão nesta cesta.

    

Answer 1

Espero que o seu plano seja criar um segundo tecido independente, o que geralmente é considerado uma boa ideia.

Você não diz se seus servidores têm vários HBAs ou não. Eu espero que assim como ele permitirá que você reconfigure corretamente para tecidos redundantes, mas se não, isso não afetará significativamente seu plano imediato.

O Powerpath lidará com o failover para o servidor Exchange e deverá escolher um caminho via A1 quando A0 estiver desconectado, e não B0 ou B1, a menos que as duas portas SPA tenham falhado. Se algum caminho não estiver operacional, ele dirá ou, no mínimo, você não verá os caminhos esperados. Dependendo da versão do Powerpath (ou seja, da versão SE ou da versão totalmente licenciada), você pode ter políticas de vários caminhos de balanceamento de carga ativas, mas em qualquer caso, o failover de caminho deve ser confiável para a configuração descrita. Se acontecer de você desconectar um caminho ativo, o Powerpath redirecionará os pedidos de veiculação com falha através do caminho alternativo, desde que estejam em boas condições. Você pode verificar o status do caminho dentro da GUI do Powerpath ou da linha de comando usar powermt check para verificar se há \ caminhos com falha ou e powermt restore para verificar e remover \ adicionar caminhos mortos \ novos. Se a política de caminho já estiver configurada para balanceamento de carga e houver caminhos íntegros visíveis por meio de SPA0 e SPA1 (por exemplo), você terá um alto nível de confiança de que tudo está OK.

Nos servidores ESX, você poderá verificar os caminhos disponíveis para cada LUN na guia VI Client- > Configuration- > Storage. Nas propriedades, você pode ver os caminhos disponíveis, que estão ativos e que estão em espera. Na caixa de diálogo Gerenciar Caminhos, você pode alterar a política (Fixed \ MRU \ Round Robin). Você não precisa mudar nada, mas novamente, você desejará certificar-se de que o caminho de failover que deseja usar esteja disponível. Novamente, a pilha multi-caminho do ESX lidará com o failover, se os pedidos de informação estiverem em andamento em um caminho ativo, eles serão reenviados em outro caminho se detectar que houve falha. O ESX 3.5 suporta apenas múltiplos caminhos de round robin experimentalmente, então você não quer estar mexendo com isso neste caso. Você poderia definir temporariamente uma política de caminho fixo e forçar o LUN ao caminho que você quer, se você quer ser proativo, mas a configuração padrão para o CX3 é deixá-lo em MRU e isso deve ser bom.

Em ambos os casos, pode haver algum atraso antes que o failover ocorra e os IOs podem parar rapidamente, mas nada deve falhar, desde que os caminhos redundantes estejam realmente saudáveis.