Melhores práticas para adicionar o segundo switch FC à estrutura no ambiente de produção?

Melhores práticas para adicionar o segundo switch FC à estrutura no ambiente de produção?

Tenho um único switch Brocade Silkworm 200e em produção no momento. O servidor corp exchange e 3 hosts ESX 3.5 estão conectados ao array clariion cx3 por meio dele. As portas 0,1 são SPA0 e 1, e as portas 4,5 são SPB0 e 1.

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

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

Se um LUN pertence atualmente ao SPA, ele utiliza automaticamente SPA0 e SPA1 em round robin ou o switch prefere um caminho específico exclusivamente, a menos que falhe nele? Exemplo - o servidor Exchange está 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 será 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 não tenha sido usado antes e depois descobrir que o cabo estava instável ou algo assim.

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

Como você monitoraria o failover conforme ele acontece? O brocado 200e vai registrá-lo detalhadamente? Quero a máxima garantia de que tudo ainda está funcionando quando eu desligar os plugues. Posso verificar novamente o armazenamento nos hosts esx e observar o monitor powerpath do Exchange. Posso fazer algo melhor?

Prefiro ser muito mais cauteloso do que a situação merece do que fazer suposições excessivamente confiantes sobre fazer algo assim pela primeira vez, quando todos os nossos ovos estão nesta cesta.

Responder1

Espero que seu plano seja criar uma segunda estrutura independente, geralmente é considerada uma boa ideia.

Você não diz se seus servidores possuem vários HBAs ou não. Espero que sim, pois isso permitirá que você reconfigure adequadamente para malhas redundantes, mas se não, isso não afetará significativamente seu plano imediato.

O Powerpath tratará do 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 ambas as portas SPA tenham falhado. Se algum caminho não estiver operacional, ele lhe dirá ou, pelo menos, você não verá os caminhos esperados. Dependendo de qual versão do Powerpath (ou seja, a versão SE ou a versão totalmente licenciada) você possui, você pode ter políticas de balanceamento de carga de vários caminhos 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 IO's com falha através do caminho alternativo, desde que estejam íntegros. Você pode verificar o status do caminho na GUI do Powerpath ou na linha de comando powermt checkpara verificar se há caminhos novos\com falha ou powermt restorepara verificar e remover\adicionar caminhos novos\inativos. Se a política de caminho já estiver definida para balanceamento de carga e houver caminhos íntegros visíveis por meio de SPA0 e SPA1 (por exemplo), você terá um nível bastante alto de confiança de que está tudo bem.

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, quais estão ativos e quais estão em espera e na caixa de diálogo Gerenciar Caminhos você pode alterar a política (Fixed\MRU\Round Robin). Você não deve precisar alterar nada, mas novamente você vai querer ter certeza de que o caminho de failover que você deseja usar está disponível. Novamente, a pilha de múltiplos caminhos do ESX lidará com o failover; se os IO's estiverem em operação em um caminho ativo, ele os reenviará para outro caminho se detectar que houve falha. O ESX 3.5 suporta apenas experimentalmente multipathing round robin, então você não quer mexer com isso neste caso. Você pode definir temporariamente uma política de caminho fixo e forçar os LUNs para o caminho desejado se quiser ser proativo, mas a configuração padrão para o CX3 é deixá-lo em MRU e isso deve servir.

Em ambos os casos, pode haver algum atraso antes que o failover aconteça e os IO's podem parar brevemente, mas nada deve falhar, desde que os caminhos redundantes estejam realmente íntegros.

informação relacionada