BBWC: em teoria, uma boa ideia, mas alguém já salvou seus dados?

Estou familiarizado com o que um BBWC (cache de gravação com bateria) pretende fazer - e os usei anteriormente em meus servidores, mesmo com um bom no-break. Há falhas óbvias para as quais não fornece proteção. Estou curioso para entender se ele realmente oferece algum benefício real na prática.

(NB, estou procurando especificamente respostas de pessoas que têm BBWC e tiveram falhas / falhas e se o BBWC ajudou na recuperação ou não)

Atualizar

Após o feedback aqui, estou cada vez mais cético quanto à possibilidade de um BBWC agregar algum valor.

Para ter alguma confiança sobre a integridade dos dados, o sistema de arquivos DEVE saber quando os dados foram comprometidos com o armazenamento não volátil (não necessariamente o disco - um ponto em que voltarei). Vale a pena notar que muitos discos ficam sobre quando os dados foram confirmados no disco ( http://brad.livejournal.com/2116715.html ). Embora pareça razoável supor que a desativação do cache no disco possa tornar os discos mais honestos, ainda não há garantia de que esse seja o caso.

Devido aos buffers tipicamente grandes em um BBWC, uma barreira pode exigir que muito mais dados sejam comprometidos no disco, causando atrasos nas gravações: o conselho geral é desativar as barreiras ao usar um cache de gravação não volátil (e desativar o cache de disco). No entanto, isso parece comprometer a integridade da operação de gravação - apenas porque mais dados são mantidos no armazenamento não volátil não significa que eles serão mais consistentes. De fato, sem dúvida, sem demarcação entre transações lógicas, parece haver menos oportunidade de garantir consistência do que de outra forma.

Se o BBWC reconhecesse as barreiras no momento em que os dados entram no armazenamento não volátil (em vez de estar comprometido com o disco), ele pareceria satisfazer o requisito de integridade dos dados sem uma penalidade de desempenho - o que implica que as barreiras ainda devem estar ativadas. No entanto, como esses dispositivos geralmente exibem um comportamento consistente com a liberação dos dados para o dispositivo físico (significativamente mais lento com barreiras) e os conselhos gerais para desativar barreiras, eles não podem, portanto, se comportar dessa maneira. POR QUE NÃO?

Se a E / S no SO for modelada como uma série de fluxos, haverá algum escopo para minimizar o efeito de bloqueio de uma barreira de gravação quando o cache de gravação for gerenciado pelo SO - uma vez que nesse nível apenas a transação lógica (um único fluxo ) precisa ser comprometido. Por outro lado, um BBWC sem conhecimento de quais bits de dados compõem a transação precisaria comprometer todo o cache em disco. Se o kernel / sistema de arquivos realmente implementa isso na prática exigiria muito mais esforço do que estou disposto a investir no momento.

Uma combinação de discos informando mentiras sobre o que foi cometido e perda repentina de poder indubitavelmente leva à corrupção - e com um sistema de arquivos estruturado em diário ou log que não faz um fsck completo após uma interrupção, é improvável que a corrupção seja detectada e muito menos. uma tentativa feita para repará-lo.

Em termos de modos de falha, na minha experiência, a maioria das quedas repentinas de energia ocorre devido à perda de energia da rede elétrica (facilmente mitigada com um no-break e desligamento gerenciado). As pessoas que puxam o cabo errado do rack implicam em baixa higiene do datacenter (rotulagem e gerenciamento de cabos). Existem alguns tipos de eventos repentinos de perda de energia que não são impedidos por um no-break - uma falha no PSU ou no VRM, um BBWC com barreiras forneceria integridade dos dados no caso de uma falha aqui, no entanto, quão comuns são esses eventos? Muito raro a julgar pela falta de respostas aqui.

Certamente, mover a tolerância a falhas mais alta na pilha é significativamente mais caro no BBWC - no entanto, implementar um servidor como um cluster tem muitos outros benefícios em termos de desempenho e disponibilidade.

Uma maneira alternativa de mitigar o impacto da perda repentina de energia seria implementar uma SAN - AoE faz disso uma proposta prática (eu realmente não entendo o ponto no iSCSI), mas, novamente, há um custo mais alto.

Certo. Eu tive o cache com bateria (BBWC) e, mais tarde, o cache de gravação com flash (FBWC) protegem os dados em andamento após falhas e perda súbita de energia.

Nos servidores HP ProLiant, a mensagem típica é:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

O que significa: " Ei, existem dados no cache de gravação que sobreviveram à reinicialização / perda de energia! Vou gravar isso de volta no disco agora !! "

Um caso interessante foi meu post-mortem de um sistema que perdeu energia durante um tornado , a sequência da matriz foi:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

O erro POS93 1793 é único. - Enquanto o sistema estava em uso, a energia foi interrompida enquanto os dados estavam na memória do Array Accelerator. No entanto, devido ao fato de ser um tornado, a energia não foi restaurada em quatro dias; portanto, as baterias do array se esgotaram e os dados foram perdidos. O servidor tinha dois controladores RAID. O outro controlador possuía uma unidade FBWC, que dura muito mais tempo que uma bateria. Essa unidade se recuperou corretamente. Alguma corrupção de dados resultou na matriz suportada pela bateria vazia.

Apesar do tempo de execução da bateria nas instalações, quatro dias sem energia e condições perigosas impossibilitaram o desligamento seguro dos servidores.

Sim, tive esse caso.

Servidor "sem no-break" em um data center (com o data center tendo um no-break). Falha na PDU - o sistema travou com força. Sem perda de dados.

E é basicamente isso. O bom de um BBWC é que ele está na máquina. Tenha um no-break - acredite em mim, às vezes alguém faz algo estúpido (como puxar o cabo errado). Um no-break é externo. Ah, esse cabo;)

Eu tive dois casos em que o cache com bateria nos controladores HW RAID falhou completamente (em duas empresas separadas).

A BBC baseia-se na idéia surpreendente de que a bateria funciona. O problema é que, em algum momento, a bateria do controlador falha e o que é devastador é que em muitos controladores HW ela falha silenciosamente . Achamos que tínhamos um cache protegido contra perda de energia, mas não o fizemos.

Na perda de energia, a perda de dados da matriz RAID foi tão extensa que todo o conteúdo do disco ficou irrecuperável. Tudo estava perdido. Um dos casos envolveu uma máquina dedicada inteiramente para testes, mas ainda assim.

Depois disso, eu disse "nunca mais", mudei para o espelhamento de disco baseado em software (mdadm) no Linux + fs baseado em diário que tem resiliência decente contra perda de energia (ext4) e nunca olhou para trás. É verdade que eu o usei em servidores que não tinham um uso extremamente alto de IO.

Isso parece exigir uma segunda resposta para a pergunta ...

Acabei de fazer com que um host VMware ESXi independente perdesse uma unidade em uma matriz RAID 5. A matriz degradada impactou o desempenho no nível da VM e do aplicativo.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

A pessoa de TI desta empresa não sabia que uma unidade falhou e reinicializou o servidor com força ( para melhorar tudo? ).

O efeito interessante de fazer isso em uma matriz comprometida com máquinas virtuais ocupadas em execução no topo foi o seguinte:

Detalhes do status do cache: O atual controlador do array tinha dados válidos armazenados no cache de gravação com bateria / capacitor na última vez em que foi redefinido ou ligado. Isso indica que o sistema pode não ter sido desligado normalmente. O controlador da matriz gravou automaticamente ou tentou gravar esses dados nas unidades. Esta mensagem continuará sendo exibida até a próxima redefinição ou ciclo de energia do controlador de matriz.

Portanto, mesmo que o sistema tenha sido interrompido abruptamente, os dados em voo foram protegidos pelo BBWC. Todas as máquinas virtuais se recuperaram corretamente e o sistema está em boa forma agora.

Além de "salvar seus dados", eles são bons para outras coisas. Eles também são bons em buffer de gravações (no cache) para melhorar o desempenho do subsistema de E / S, mantendo a fila de gravação em disco baixa. Isso é particularmente importante para servidores onde o desempenho interativo é fundamental - por exemplo, Citrix XenApp ou Windows Terminal Services.

Isso é menos importante para um servidor da web ou um servidor de arquivos. Você pode não perceber, ou mesmo estar acostumado a, um pequeno atraso. No entanto, quando você clica em um ícone em um aplicativo do Office, espera uma resposta. E o mesmo acontece com o seu CEO.