RAID0 em vez de RAID1 ou 5, isso é loucura?

Estou pensando em usar uma instalação RAID0 para um de nossos clusters do SQL Server. Vou descrever a situação e procurar por que isso pode ser uma má idéia. Além disso, se alguém com casos de uso, documentos técnicos ou outra documentação puder me indicar esse tópico, seria ótimo.

Temos 3 servidores em 2 datacenters que fazem parte de um cluster SQL. Todos eles estão executando o SQL Server em um grupo de disponibilidade. O primário tem uma réplica bem ao lado dele e outra no outro datacenter. Eles estão executando replicação síncrona com failover automático. Todas as unidades são SSDs de classe empresarial. Eles estarão executando o SQL Server 2017 ou 2019.

Estou pensando que haveria vários benefícios em executá-los em matrizes RAID0 sobre outros métodos, com poucas, se houver, desvantagens reais. O único aspecto negativo que estou vendo atualmente é a falta de redundância no servidor principal e, portanto, aumenta a falha. Como profissionais:

1. Se uma unidade falhar, em vez de executar em um estado lento e degradado até que alguém receba um aviso e aja manualmente, o servidor falhará imediatamente para um secundário, mantendo a capacidade operacional total. Isso terá um benefício adicional de nos notificar sobre um failover, para que possamos investigar a causa mais cedo.

2. Reduz a chance de falha geral por capacidade de TB. Como não precisamos de unidades de paridade ou espelho, reduzimos o número de unidades por matriz. Com menos unidades, há menos chance total de uma falha na unidade.

3. É mais barato. Necessitar de menos unidades para a capacidade necessária obviamente custa menos.

Sei que esse não é o pensamento comercial convencional, mas há algo que não estou considerando? Eu adoraria qualquer entrada a favor ou contra.

Não estou tentando fazer isso para obter ganhos de desempenho de consulta, embora, se houver algum significativo, fique à vontade para apontá-lo. Minha principal preocupação é não considerar ou resolver um problema de confiabilidade ou redundância em que não pensei.

O sistema operacional está em uma unidade espelhada separada, portanto, o próprio servidor deve permanecer ativo. Uma dessas unidades pode ser substituída e novamente espelhada. É pequeno e não há nenhum arquivo de banco de dados além dos bancos de dados do sistema. Não consigo imaginar que demore mais do que minutos. Se uma das matrizes de dados falhar, substituímos a unidade, reconstruímos a matriz, restauramos e ressincronizamos com o AG. Na minha experiência pessoal, a restauração foi MUITO mais rápida que a reconstrução de uma unidade RAID5. Como nunca tive uma falha no RAID1, não sei se essa reconstrução seria mais rápida ou não. As restaurações seriam provenientes de um backup e encaminhadas para corresponder ao primário, portanto, o aumento de carga no servidor principal deve ser muito mínimo, sincronizando apenas os últimos minutos dos logs com a réplica recuperada.

Acho que falta um aspecto muito importante na sua avaliação:

Como você planeja se recuperar?

Quando o raid5 perde uma unidade, ele será executado em um estado degradado até que se recupere automaticamente. (Pelo menos se você tiver uma reposição quente à mão.)

Quando um ataque0 perde uma unidade, ele nunca pode se recuperar. Isso significa que você perdeu a redundância e, para recuperá-la, é necessário reconstruir o seu raid0 e copiar todos os dados (não apenas os dados da unidade quebrada) do secundário que agora está sob carga de produção. Ou seja, em vez da matriz RAID5 degradada, agora é toda a sua configuração de produção que atinge o desempenho.

Se a penalidade de desempenho do estado degradado do RAID5 (ou RAID6) não for algo com que você possa lidar, provavelmente você deve executar o RAID 1 + 0 . Sim, custa mais, mas, como os preços dos discos são, será um dinheiro bem gasto.

Talvez "monitorar ativamente o estado do raid5 e transferir a carga do primário quando uma unidade falhar" é a solução que oferece a maioria dos benefícios sem inconvenientes? (Além de perder o fator de frieza de executar sem redundância local, é claro.) Se a recuperação da sua unidade RAID5 estiver demorando muito mais do que uma sincronização completa dos dados do banco de dados, o seu software RAID está agindo de maneira estranha ou você possui discos muito grandes, Eu pensaria.

Falha na unidade deve ser levada em consideração aqui.

Imagine por um segundo que nossas unidades em um determinado dia tenham uma taxa de falhas de 1/1000. Imagine então que temos 20 unidades em cada uma de nossas 3 matrizes.

A chance de uma única unidade falhar em uma matriz é, portanto, 20/1000 = 1/50. A chance de duas unidades falharem na mesma matriz é algo próximo a 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Portanto, ao mudar de RAID 0 para RAID 5, já temos uma probabilidade significativamente menor de matar uma de nossas matrizes.

Portanto, podemos levar isso adiante - se a chance de uma matriz falhar em um dia é 1/50, a chance de duas matrizes falharem em um dia é 1 / (50 * 50) = 1/2500. A chance de duas matrizes RAID 0 idênticas falharem é duas vezes maior do que uma matriz RAID 5 falhar, assumindo o mesmo conjunto de discos. Esse aumento exponencial nas chances de falha deve interessá-lo, pois aumenta enormemente a chance de mais de uma matriz falhar ao mesmo tempo.

Como é provável que esses discos tenham uma vida útil longa, é possível executar os números acima e ver diretamente o efeito que isso terá na confiabilidade - se você puder publicar as especificações da unidade, posso adicionar esse cálculo a esta postagem. Se o risco é aceitável ou não, cabe à sua organização decidir.

Outro item a ser observado é que a probabilidade de falha da unidade pode ser aumentada utilizando SSDs fabricados no mesmo lote (mesma fábrica, ao mesmo tempo). Se você não tomar cuidado, poderá acabar com os três nós inativos por causa desse problema.

Isenção de responsabilidade: Os cálculos acima foram simplificados - ainda são relativamente precisos.

Estou pensando que haveria vários benefícios em executá-los em matrizes RAID0 sobre outros métodos, com poucas, se houver, desvantagens reais.

Essa é uma configuração bastante comum ao executar AGs com unidades de armazenamento internas / de conexão direta. Especialmente com o NVMe ou outros dispositivos de armazenamento flash baseados em PCI.

Simplesmente equivale a tratar uma falha na unidade como uma falha no servidor. Com um pequeno número de unidades de estado sólido, você realmente não possui um MTBF significativamente menor para as unidades do que para os outros componentes de estado sólido do servidor e, portanto, simplesmente trata cada unidade como um ponto de falha para a unidade. servidor e substitua / reconstrua o servidor em caso de falha na unidade.

Estou intrigado com o que você está tentando alcançar? Você menciona a si mesmo que não está tentando obter ganhos de desempenho com essa configuração; então, qual ganho você está tentando obter?

Nota sobre o problema de desempenho: se você estiver executando SSDs de classe corporativa, seu cálculo de RAID é realmente um gargalo que você precisa para melhorá-lo?

Tomando seus 3 profissionais, acho que você não pensou nisso o suficiente:

1. O SQL failover será imediato? O que fará com que o failover seja acionado automaticamente? O servidor desativará a unidade assim que alguém a acessar? E se for apenas um setor ruim em um disco? Se o SQL não atingir o setor defeituoso, ocorrerá failover? Não tenho 100% de certeza disso.

2. Isso reduz a chance de falha geral por capacidade de TB. Seu pensamento parece ser o menor número de discos significa menos pontos de falha, mas não acho que isso esteja certo. As chances de falha de 1 disco permanecem as mesmas se você tiver 1 ou 10 discos (ou 100 discos), mas com o RAID 0, isso também significa que é uma falha catastrófica.

3. Um SSD extra vai custar muito mais para você obter RAID5? Eu entendo como RAID1 OU 1 + 0 poderia estourar o orçamento, mas um disco extra?

Sem redundância, se um disco falhar e o RAID ficar offline, esse nó ficará offline até você reconstruir o RAID e restaurar todos os seus bancos de dados do zero. Que processo você vai seguir para fazer isso acontecer? Você não pode remover o banco de dados do Grupo de Disponibilidade, pois isso interromperá a replicação no DR, mas se você não executar alguma ação, os outros dois servidores não poderão truncar seus arquivos de log. Tudo bem? O que acontece se falhar na sexta-feira à noite de um longo fim de semana? Ainda está bem? Seus secundários podem lidar com essa quantidade de dados acumulados?

Minhas últimas perguntas seriam em torno do tempo de reconstrução que você mencionou será mais rápido. Você tem 100% de certeza de que será mais rápido? Quanto mais rápido?

A configuração do servidor Brent Ozar ainda é meu guia para configurar novas instâncias SQL. O primeiro ponto do guia é o de confirmar que você não está usando o RAID0 para nenhuma unidade.

==== ATUALIZAÇÃO ====

Um pensamento extra: o que acontece quando os servidores secundários estão fora de sincronia com o primário? Mesmo com a replicação síncrona, seus secundários ainda podem reverter automaticamente para assíncrono e, assim que você perde a capacidade de realizar failover automático, pois qualquer failover resultará em perda de dados. Alguns exemplos em que isso poderia acontecer:

1. Reconstruindo um índice muito grande - a replicação pode ficar para trás em um ou em ambos os secundários
2. Falha no disco no RAID0 ao aplicar o patch no secundário. O servidor que você está executando o patch pode não conseguir voltar a ficar online devido ao fato de o primário estar offline.

São casos extremos, mas podem ser catastróficos, dependendo do que for perdido durante esses tempos.