Um switch pode morrer e o seu storage continua a servir

O disco em que a sua carga de trabalho escreve não vive dentro do servidor que a executa. Vive num array de storage a uma rede de distância, e essa rede pode falhar como tudo o resto: switches morrem, cabos são puxados, portas começam a oscilar. O que decide se a sua carga de trabalho alguma vez repara é se existe uma segunda estrada até ao disco, e se essa segunda estrada é genuinamente separada da primeira.

O multipath dá a cada host duas estradas ativas até ao seu LUN

Um LUN é o dispositivo de blocos que a sua máquina virtual vê como o seu disco. Numa SAN, esse disco vive fora do servidor que corre a sua carga de trabalho, num array all-flash dedicado de controlador duplo, e o servidor chega-lhe através de uma rede de storage. Multipath significa que o servidor mantém mais do que uma rota física para o mesmo LUN ao mesmo tempo, por portas diferentes, cabos diferentes e switches diferentes.

Active/active significa que ambas as rotas transportam tráfego a cada segundo do dia. Um caminho standby que só acorda durante uma falha é um caminho que nunca testou a sério, e a falha é o pior momento possível para o seu primeiro teste. Quando ambos os caminhos transportam I/O real continuamente, perder um deixa simplesmente o outro a fazer todo o trabalho de que já fazia metade. A carga de trabalho não vê nada, porque, de onde está, nada aconteceu.

Os dois fabrics não partilham nenhum switch, pelo que uma falha não passa de um para o outro

Dois caminhos pelo mesmo switch são um caminho com duas etiquetas. O que mata o switch mata os dois. Independência real significa que os dois fabrics são construídos como duas redes separadas com switches separados, e nada no caminho de dados entre host e array aparece em ambos. Uma falha num fabric, seja um switch morto, uma porta a oscilar ou uma ligação congestionada, não tem para onde se espalhar. O segundo fabric não ouve falar dela.

O RAID dentro de um servidor morre com o servidor

O RAID numa placa controladora dentro do seu servidor protege-o de exatamente uma coisa, um disco morto, e é bom nisso. Mas os discos, a placa RAID, o backplane, as fontes de alimentação e a motherboard vivem todos na mesma caixa, e a caixa é o domínio de falha. Quando qualquer outra coisa dentro dela morre, o seu storage vai com ela, e volta quando o servidor voltar. Se a própria placa RAID falhar, os discos mais saudáveis do mundo ficam inacessíveis.

Uma SAN tira o disco do domínio de falha da máquina que o usa. O seu servidor pode morrer e o LUN em que estava a escrever um segundo antes continua lá, intacto e a servir, pronto para a carga de trabalho voltar a subir noutro host. O desenho de fabric duplo estende a mesma ideia à estrada entre eles: o caminho até ao seu storage também pode falhar, por isso construímos dois.

Retirar um fabric inteiro de serviço com cargas de trabalho ativas

Quando um fabric precisa de manutenção, o procedimento não tem nada de espetacular: confirmamos que todos os hosts mantêm um bom caminho no outro fabric, retiramos o fabric de serviço, fazemos o trabalho, e depois reintroduzimo-lo deliberadamente. As máquinas virtuais correm num fabric enquanto o trabalho decorre e não veem nada. É essa a quantidade certa de drama para a manutenção do storage.

A mesma postura vale do lado do array. Os arrays têm controlador duplo: um controlador pode ser intervencionado enquanto o outro continua a servir. O hardware é intervencionado na nossa SAN como devia ser em todo o lado: enquanto aquilo a que pertence continua a fazer o seu trabalho.

Switches mortos, cabos puxados e manutenção de controladores são as falhas que este desenho reforma. Perder um array inteiro ou um site inteiro é outra classe de falha, e essa começa na conversa de recuperação. Se está a avaliar fornecedores, as perguntas sobre storage que vale a pena fazer a qualquer um, incluindo a nós, estão em o segredo sujo do seu fornecedor é o storage dele.