Multipathing vs. conexões ligadas

2

Recentemente, tentei vender a ideia de multipathing em um dos nossos bancos de dados de produção (graças ao Brent no SQL Pass Summit!) usando atualmente apenas 1 arquivo de banco de dados (189 GB !!!) em um servidor físico com 2 linhas para um HP LeftHand. P4000 SAN (via comutadores etc). Um dos argumentos contra isso é que as duas linhas fora da SAN estão atualmente conectadas, fornecendo capacidade de 2 x 1 Gbps r / w de e para a SAN. O administrador da SAN não estava preparado para separar as linhas, em parte devido a outras VMs no servidor que as utilizavam e ao impacto desconhecido que qualquer separação poderia ter. Eu me esforcei para articular os benefícios do multipathing do banco de dados em face disso - há algum benefício que m / p traria versus conexões ligadas?

    
por Derek Colley 29.09.2011 / 10:16

1 resposta

2

Não sei ao certo o que você quer dizer com ligação no contexto de SAN.

O multipathing na SAN é feito antes de tudo para o RAS. Você geralmente tem caminhos para o LUN independente. Isso significa diferentes cartões FC, diferentes tecidos, diferentes controladores de armazenamento. Se o seu armazenamento suportar a operação ativa / ativa, você também poderá usar a largura de banda de ambos os links (você pode emitir solicitações em paralelo sobre ambos).

Se o seu armazenamento não oferecer suporte à operação ativa / passiva, o uso de vários caminhos significa perda de metade da largura de banda, pois você poderá falar com o LUN em um link em um determinado momento.

No entanto, a perda de rendimento (se houver) é, na minha opinião, mais do que aceitável, devido ao aumento da disponibilidade. Você elimina os SPOFs do lado do armazenamento dessa maneira e, por exemplo, pode escalonar as atualizações / mudanças de zoneamento do firmware da SAN, sem arriscar o impacto na produção (se, após a atualização, o comutador FC falhar, basta alternar para a outra malha enquanto o pessoal da SAN executa a estratégia de recuperação).

    
por 29.09.2011 / 11:32