Como funciona uma arquitetura de SAN e, mais importante, escala?

Question

Estou tentando entender algumas infraestruturas de SAN e esperava que alguns de vocês com mais experiência do que eu pudessem me ajudar a entender o dimensionamento com uma SAN.

Imagine que você tenha alguns servidores de computador que possuem um HBA. Eles se conectam diretamente ou por meio de um switch a um SAN Controller. O SAN Controller fornece então um ou mais LUNs que são mapeados para uma matriz RAID em um dispositivo de armazenamento.

Então, se eu entendi corretamente, o "controlador" representa um gargalo de desempenho. Se você precisar de muito desempenho, adicione mais controladores com conexões ao próprio armazenamento, que serão mapeados para os servidores que precisam deles.

Eu imagino que você pode obter alguns controladores de desempenho muito alto com capacidades de armazenamento enormes e controladores de desempenho mais baixos com um desempenho máximo menor? Mas se você tem um switch, você pode adicionar vários controladores de desempenho inferior à sua rede, conforme necessário?

Por favor, rasgue o meu entendimento se eu estiver errado, mas estou tentando descobrir como você conecta os HBAs de um servidor ao armazenamento sem que o tecido simplesmente represente "mágica".

    

Answer 1

O controlador como um afunilamento de desempenho é bastante verdadeiro e pode representar um ponto único de falha em algumas arquiteturas. Isso é conhecido há algum tempo. Por um tempo, houve técnicas específicas de fornecedores para contornar isso, mas desde então a indústria como um todo convergiu para algo chamado MPIO ou Multi-Path I / O.

Com o MPIO, você pode apresentar o mesmo LUN em vários caminhos em uma malha de armazenamento. Se o HBA do servidor e o HBA da matriz de armazenamento tiverem duas conexões à malha de armazenamento, o servidor poderá ter quatro caminhos separados para a LUN. Pode ir além disso, se o armazenamento suportar isso; É bastante comum ter configurações de controlador duplo nos sistemas de matriz de disco maiores, com cada controlador apresentando uma conexão ativa ao LUN. Adicione em um servidor com duas placas HBA separadas, além de dois caminhos fisicamente separados conectando os pares controlador / HBA, e você pode ter um caminho de armazenamento sem pontos únicos de falha.

Os controladores mais sofisticados serão de fato um par Ativo / Ativo completo, com ambos os controladores realmente conversando com o armazenamento (geralmente há alguma forma de cache compartilhado entre os controladores para ajudar na coordenação). Os dispositivos da camada intermediária podem fingir estar ativos / ativos, mas apenas um único dispositivo está realmente realizando o trabalho a qualquer momento, mas o controlador em espera pode atender imediatamente se a primeira ficar silenciosa e nenhuma operação de E / S for interrompida. Dispositivos de camada inferior estão em ativa / espera simples, onde todas as E / S seguem um caminho e só se movem para outros caminhos quando o caminho ativo é interrompido.

Ter vários controladores ativos pode, de fato, fornecer melhor desempenho do que um único controlador ativo. E sim, adicione sistemas suficientes para armazenamento e armazenamento rápido suficiente atrás do controlador, e você pode saturar os controladores o suficiente para que todos os servidores conectados percebam. Uma boa maneira de simular isso é fazer com que um volume RAID de paridade tenha que ser reconstruído.

Nem todos os sistemas são capazes de aproveitar o MPIO para usar vários caminhos ativos , o que ainda é um pouco novo. Além disso, um dos problemas que precisam ser resolvidos por parte de todos os controladores é assegurar que todas as operações de E / S sejam comprometidas em ordem, apesar do caminho em que a E / S entrou e em qualquer controlador que recebeu a operação. Esse problema fica mais difícil quanto mais controladores você adicionar. E / S de armazenamento é uma operação serializada fundamentalmente e não funciona bem com paralelização massiva.

Você pode obter alguns ganhos adicionando controladores, mas os ganhos desaparecem rapidamente à luz da complexidade adicional necessária para que funcione.

    

Answer 2

O problema com a tentativa de agrupar dispositivos de baixo desempenho é a natureza do modo como o software acessa o armazenamento. Um programa típico emitirá uma solicitação read e a semântica da operação read exigirá que o sistema operacional forneça ao processo os resultados de read . O sistema operacional, em geral, não tem como saber o que esse processo ou thread desejará a seguir. Pode tentar adivinhar com readahead, mas nem sempre está certo.

Então, se você tentar usar muitos controladores medíocres, acabará com alta latência, porque os controladores medíocres demoram mais para receber seus pedidos e enviar seus pedidos do fio. O fato de você ter um monte de outros controladores ociosos não lhe dá muito mais velocidade.

Existe alguma dependência de aplicativos aqui. Algumas cargas de trabalho emitem muitas solicitações de vários locais diferentes ou usam APIs de leitura de arquivo assíncrono que permitem que o mesmo encadeamento emita várias solicitações antes de aguardar a conclusão de qualquer uma delas. Alguns aplicativos se beneficiam muito da leitura antecipada, removendo muito da latência. Mas se você quer uma solução de propósito geral que tenha um bom desempenho, você precisa de controladores que forneçam baixa latência para que você não fique esperando pelo controlador antes mesmo de descobrir quais dados você precisa em seguida.