SATA Discos que manipulam o cache de gravação corretamente?

Question

É muito comum ver conselhos para desabilitar o cache de gravação em discos individuais usados para bancos de dados, porque senão alguns discos reconhecerão gravações que ainda não chegaram à superfície do disco.

Isso implica que alguns discos não reconhecem gravações até chegarem à superfície do disco (Atualização: ou que relatam com precisão quando solicitados a liberar o cache. Onde posso encontrar esses discos ou onde posso procurar? informações confiáveis sobre onde encontrar esses discos?

Estou configurando alguns servidores de banco de dados que realmente se beneficiariam do uso de cache de gravação, mas o aplicativo é sensível ao preço e prefiro não dobrar o custo do meu subsistema de disco para algum controlador RAID de armazenamento em cache porque não tenho informações suficientes para saber se posso confiar no cache de cada unidade.

    

Answer 1

De um modo geral, em resposta direta à sua pergunta, eu não estou ciente de quaisquer marcas importantes de drives SATA que o próprio drive teve erros em relação à operação adequada com o cache de gravação ativado. Ou seja, apenas a partir de uma perspectiva de unidade, a unidade faz o que deve fazer a partir de uma perspectiva de armazenamento em cache. Eu também notaria que mesmo quando escreve cache é ativado, que o atraso de uma gravação em disco no cabo SATA para a mídia rotativa sendo fisicamente atualizado ainda é muito curto (~ 50 a 100ms tipicamente). Não é como se os dados do cache sujo estivessem lá por segundos de cada vez ..... a unidade está continuamente tentando obter dados sujos do cache na mídia física o mais rápido possível. Esta não é apenas uma questão de segurança de dados, mas de estar pronto para aceitar futuras gravações sem qualquer atraso (ou seja, escrever postagem).

O problema que surge quando o armazenamento em cache é ativado é que a ordem de gravação para a unidade sobre o cabo SATA e a ordem de gravação para a mídia rotativa não é a mesma. Isso nunca pode causar um problema, a menos que você tenha uma perda de energia ou uma falha do sistema antes de todo o conteúdo do cache chegar ao disco. Por quê? - >

O problema que pode surgir aqui é relativo à robustez da transação do sistema de arquivos e / ou do conteúdo do arquivo de banco de dados a gravações perdidas fora de ordem. Na verdade, as gravações potencialmente perdidas podem corromper teoricamente a integridade da lógica de transação que, de outra forma, teria sido garantida pelas gravações em disco ocorrendo em uma ordem muito específica na mídia.

Agora, é claro, os projetistas do sistema de arquivos, bancos de dados, controladores RAID, etc. estão cientes (ou certamente devem estar cientes) desse fenômeno em relação ao cache de gravação. O cache de gravação é extremamente desejável do ponto de vista do desempenho na maioria dos cenários de E / S de tipo de acesso aleatório. Na verdade, ter o cache de gravação disponível é um elemento-chave para poder ter qualquer benefício real para o Enfileiramento de Comando Nativo mais avançado ( NCQ ) que é suportado no SATA mais recente e nas últimas gerações de implementações do PATA. Assim, para garantir a ordem à mídia física em determinados momentos críticos, o sistema de arquivos e / ou o aplicativo etc. podem solicitar especificamente uma liberação dos caches de gravação para a mídia. Na conclusão desta solicitação de sincronização - tudo o que está pendente de (potencialmente) buffers de arquivo, cache de disco do SO, cache de disco físico, etc. está realmente fora da mídia conforme o projeto do sistema de transação nas operações críticas corretas. Isto é, isso acontece corretamente se os programadores fizerem a (s) chamada (s) certa (s) no topo E cada elemento dessa cadeia de camadas de software e hardware fez o trabalho corretamente. ie: Não há bugs a esse respeito na unidade, nos controladores RAID, nos drivers de disco, nos caches do SO, no sistema de arquivos, no mecanismo de banco de dados, etc. Isso é um monte de software que tem tudo para funcionar corretamente. Além disso, verificar a exatidão a esse respeito é muito difícil, pois em quase todas as situações, normalmente, a ordem de gravação não importa em nada .... e os cenários de falhas de energia e acidentes são testes difíceis de serem construídos. Então, no final, "desligar o cache de gravação" em uma ou mais das várias camadas e / ou significados deste termo ... tem a reputação de "consertar" certos tipos de problemas. Com efeito, desligar os comportamentos de cache de gravação do controlador RAID ou dos Caches de disco do SO, ou da Unidade, etc. está evitando um ou mais bugs no sistema ..... e a origem de tal conhecimento.

De qualquer forma, voltando ao núcleo da questão: Sob SATA, o tratamento específico de todos os comandos de leitura / gravação de disco e os comandos de cache flush são bem definidos pelo Especificações SATA . Além disso, os fabricantes de unidades devem ter documentação detalhada para cada modelo de unidade ou família de inversores, descrevendo sua implementação e conformidade com essas regras, como este exemplo para Seagate Barracuda drives. Em particular, veja detalhes do comando SATA SET FEATURES que controla o modo operacional da unidade e especificamente a opção 82h pode ser usada para desabilitar o cache de disco no nível da unidade porque o padrão é certamente o cache de gravação habilitado em todas as unidades I estou ciente de. Se você realmente quisesse desabilitar o cache, este comando deve ser feito no início de cada reinicialização ou energização da unidade e normalmente está sob o controle dos drivers de disco do sistema operacional. Você pode incentivar seu driver de sistema operacional a definir esse modo por meio de um tipo de configuração IOCTL e / ou de registro, mas isso varia muito.

    

Answer 2

Tem sido minha experiência que um controlador de disco de armazenamento em cache com bateria irá desativar o cache na unidade. Eu não estou ciente de uma maneira de desativar o cache no disco de outra forma. Mesmo se você pudesse desativar o cache em disco, o desempenho seria significativamente afetado.

Para uma opção de baixo custo, você pode usar um no-break barato que pode sinalizar seu sistema para um desligamento ordenado.

    

Answer 3

Eu uso um sistema RAID com um supercapacitor em vez de uma bateria para manter o cache. As baterias se desgastam, devem ser monitoradas, devem ser substituídas e representam um possível ponto de falha nesses aspectos. Um capacitor carrega na inicialização, libera o cache quando a energia do no-break falha, dura virtualmente para sempre, não requer monitoramento, etc. No entanto, a menos que você esteja executando um negócio na linha da pobreza (não incomum nos dias de hoje) você deve ter um no-break e software que desliga o sistema de forma limpa em caso de falha - geralmente dou 5-15 minutos (dependendo da carga do no-break e, portanto, da bateria disponível) antes do desligamento, caso a energia volte a funcionar.

Durante uma tempestade você pode (ou pode ter - sistemas de energia estão melhorando) ver as luzes tremeluzirem, às vezes pouco antes de eles saírem. Este é um dispositivo chamado de religador. É um disjuntor que, ao disparar, tenta fechar a chave aberta, caso a sobrecarga seja transitória, o que é mais provável. Se não conseguir fechar depois de, digamos, três tentativas, fica aberto. O pobrezinho tem que sair na chuva e lidar com isso. Não se sinta muito triste por ele, enquanto faz apenas o dobro do que você e eu fazemos e duas vezes, se for hora extra, é um trabalho perigoso.

    

Answer 4

Um dos equívocos se os caches de write-back do disco é que eles só perdem dados na perda de energia. Isso nem sempre é o caso, especialmente em dispositivos sATA. Se um dispositivo sATA tiver um erro (como um bug FW ou erro de controlador) e ele for redefinido externamente, não há garantia de que os dados no cache de write-back ainda estarão disponíveis após o travamento. / p>

Isso pode levar a cenários em que um dispositivo tem um erro transitório, é redefinido, ocorre perda de dados na perda de qualquer cache sujo e isso é silencioso acima do nível de bloqueio dos drivers.

Pior ainda, a desativação do cache da unidade por meio de ferramentas do sistema operacional também será perdida nas redefinições do dispositivo, portanto, mesmo que um dispositivo tenha seu cache desativado no início do dia, se o dispositivo for redefinido, ele reativará a devolução cache. Em outra reinicialização, o dispositivo perderá dados.

As unidades SCSI / SAS e algumas unidades sATA têm a capacidade de salvar o estado do perfil de write-back para garantir que a redefinição da propriedade não seja perdida, mas, na prática, isso raramente é usado.

Os controladores RAID, que integram a camada de bloco nas camadas superiores, podem perceber redefinições de unidade e desativar o cache de write-back novamente, mas os controladores SSATA e SAS padrão não farão isso.

Essa limitação também vale para outros parâmetros SET FEATURE e similares que são configurados para desempenho e confiabilidade.

    

Answer 5

Como você disse, um controlador RAID com bateria adequada será caro, mas você pode encontrar controladores Dell Perc5 / i no eBay por £ 100 (US $ 150) e, especialmente com RAID5, a velocidade de um controlador como o Perc5 / i irá surpreender você. Eu tenho vários servidores com Perc5 / is e seis arrays de disco RAID5, e eles estão entre os discos mais rápidos que eu já vi. Especialmente para aplicativos de banco de dados, discos rápidos vão realmente melhorar o desempenho.

Eu iria morder a bala e comprar um controlador RAID.

JR

    

Answer 6

Tanto quanto eu entendo, o faking do fsync () é uma propriedade de controladores RAID com suporte de bateria, não de unidades. O controlador RAID contém uma bateria que pode alimentar seu cache de gravação até que a energia seja restaurada na unidade e a gravação possa ser confirmada com segurança no disco. Isso permite que o controlador retorne imediatamente ao sistema operacional, já que ele garante que a gravação será gravada no disco.

Deve-se observar que, se o cache de write-back das unidades ficar cheio, as gravações serão bloqueadas até que o cache seja gravado de volta na unidade. Isso significa que o cache geralmente não é tão eficaz em gravações sustentadas.

Quantas IOPS você requer do aplicativo? Tem certeza de que está sendo limitado pelo cache de gravação das unidades ou que um pequeno (comparado à memória do seu servidor) na unidade será benéfico?