7.2K Near Line SAS com Cache de Controlador RAID Grande vs 10 / 15K SAS

Question

Estou trabalhando em um aplicativo para capturar muito (10 milhões +) de blocos realmente pequenos de dados (16 bytes) todos os dias. Os dados não são sequenciais (ou seja, muita procura para escrever) e não é um fluxo constante (há períodos de silêncio).

O aplicativo tem servidores de cache na frente dele, então as leituras são um problema menor e eu antecipo que apenas 1% dos dados serão de interesse em um determinado dia e que 1% ficará no cache. Apenas a primeira leitura deve ser lenta.

Eu tenho um orçamento bom, mas limitado, e quero o RAID 1, que dobra meu custo de disco.

Minhas escolhas são:

• Fast SAS Discos no RAID 1 - caro, não muito armazenamento, mas rápido.
• Grandes discos near-line RAID 1 + 1gb NVCache em um controlador (PERC H700)

O que você faria? Ou dito de outra forma, um grande cache no controlador compensa, em termos de escrita, por um tempo de busca mais lento?

Somos uma loja da DELL e estou olhando para o R410 / R510.

    

Answer 1

Não tenho certeza se você terá uma resposta útil aqui. Eu estaria realizando benchmarks com o aplicativo e o hardware em potencial para ter uma idéia de como ele se comportaria, porque suspeito que há complexidade suficiente para tentar modelar o "fundo do envelope", que provavelmente é simplista demais.

Em geral, o cache do controlador pode gravar em buffer e permitir que o volume RAID responda mais rapidamente ao sistema operacional. Se sua taxa de gravação exceder a velocidade que o cache pode ser confirmado no disco por tempo suficiente para preencher o cache, o controlador começará a bloquear as gravações (voltando à velocidade dos discos físicos).

Parece que você não está usando um sistema de gerenciamento de banco de dados de prateleira, mas sim gerenciando o armazenamento de dados por conta própria. Você terá que avaliar como seu aplicativo interage com o gerenciador de cache do SO e com o sistema de arquivos subjacente (supondo que você não esteja armazenando dados em blocos brutos de disco), bem como com o controlador RAID. Se você estiver usando um sistema de gerenciamento de banco de dados, obviamente terá que ver como isso interage também.

Quando você diz "trabalhando em", fico pensando se você está envolvido no desenvolvimento do aplicativo. Se assim for, acho que vale a pena olhar para uma arquitetura de aplicativo que armazena em buffer as gravações recebidas em um log gravado em sequência e, mais tarde, escreve preguiçosamente esse registro sequencial na estrutura de armazenamento de acesso aleatório. Você estaria realizando a mesma coisa, na verdade, como o armazenamento em cache do controlador grava, mas você teria um controle mais granular do processo (você poderia explicitamente ordenar o armazenamento para o log de acesso sequencial versus aleatório).

    

Answer 2

Or put another way, does a large cache on the controller compensate, in terms of writing, for a slower seek time?

Até certo ponto. Existem alguns fatores a serem considerados:

• o cache só terá o efeito desejado, desde que não esteja saturado - se os dados estiverem chegando em rajadas ou em uma taxa sustentada em que os discos não podem lidar com a carga, os caches serão preenchidos, sendo o pior caso Bloco de E / S até que os caches sejam liberados para a marca d'água baixa para operação adicional
Os algoritmos de armazenamento em cache
• geralmente garantem que os dados no cache não podem ter mais de "X", iniciando um fluxo para ele mesmo quando ainda houver espaço para mais
• o armazenamento em cache acontece em "blocos", portanto, mesmo que seus registros tenham apenas 16 bytes de tamanho, isso não significa que você pode armazenar 67 milhões de registros em 1 GB de RAM de cache
A carga de leitura / gravação aleatória misturada
• é difícil mesmo para um cache maior
• é possível executar filas de comandos de preenchimento mesmo com caches grandes, portanto, se os requisitos de armazenamento não incluírem somente IOPS e requisitos de largura de banda, mas baixa latência (tempos de serviço baixos), seria difícil alcançar as opções de configuração fornecidas

Algumas estimativas de matemática: supondo que um tempo de serviço típico para uma única solicitação seja de 20 ms para discos SATA nearline, o subsistema de E / S levaria 200.000 segundos para gravar 10.000.000 nos discos - isso é mais de 55 horas 100% de utilização de disco . Se você está recebendo essa magnitude de solicitações de gravação por dia, é provável que você ultrapasse seu subsistema de E / S.

O quão difícil você será atingido por uma ou outra condição limite, depende muito da implementação do controlador e de seu mecanismo de armazenamento em cache. Você precisaria executar testes completos para que não houvesse surpresas desagradáveis.

    

Answer 3

Se o cache RAID for um fator limitante (uma das respostas anteriores indica que pode ser), eu consideraria adicionar alguns smarts ao cache na frente de stripes em matrizes separadas - digamos, 4 espelhos de 2 discos cada - e hash o destino para que você espalhe a carga uniformemente.

Isso não melhorará o uso do cache, mas fornecerá a você 4 conjuntos de fusos independentes para gravar, evitando assim a maior parte da latência incorrida em ter que gravar em todos os fusos de uma só vez.

No entanto, como disse o primeiro socorrista, você precisa testar o que funciona melhor.

    

Answer 4

Você já pensou sobre o H700 com o cache de 512 ou 1GB e depois em um SSD ou dois para usar como cache extra para as unidades. A Dell chama isso de tecnologia Cachecade.

Veja aqui: link