As tecnologias de aprimoramento de desempenho baseadas em SSD que são amplamente usadas em sistemas de armazenamento são inventadas há muito tempo. Primeiro de tudo, esse é o uso de SSDs como espaço de armazenamento, que é 100% eficiente, mas caro. Portanto, são usadas tecnologias de emparelhamento e cache, onde os SSDs são usados apenas para os dados mais populares ("quentes"). O rasgo é bom para cenários de uso a longo prazo (dias-semanas) de dados "quentes". E o armazenamento em cache, pelo contrário, é para uso a curto prazo (minutos-horas). Ambas as opções são implementadas no armazenamento QSAN XCubeSAN . Neste artigo, consideraremos a implementação do segundo algoritmo - cache SSD .

A essência da tecnologia de cache de SSD é o uso de SSDs como um cache intermediário entre discos rígidos e memória do controlador. O desempenho dos SSDs, é claro, é menor que o desempenho do cache do próprio controlador, mas o volume é muito maior. Portanto, temos um compromisso entre velocidade e volume.
Indicações para usar o cache de leitura SSD:
- A predominância de operações de leitura sobre operações de gravação (geralmente característica de bancos de dados e aplicativos da web);
- A presença de um gargalo na forma de desempenho de uma matriz de discos rígidos;
- A quantidade de dados solicitados é menor que o tamanho do cache do SSD.
As indicações para o uso do cache SSD de leitura / gravação são os mesmos motivos, com exceção da natureza das operações - um tipo misto (por exemplo, servidor de arquivos).
A maioria dos fornecedores de armazenamento usa cache SSD somente leitura em seus produtos. A diferença fundamental entre o QSAN e eles é a capacidade de usar o cache também para gravação. Para ativar a funcionalidade do armazenamento em cache do SSD no armazenamento QSAN, é necessária uma licença separada (entregue em formato eletrônico).
O cache SSD no XCubeSAN é fisicamente implementado como conjuntos de cache SSD separados. Pode haver até quatro deles no sistema. Cada pool, é claro, usa seu próprio conjunto de SSDs. E já nas propriedades de um disco virtual, determinamos se ele usará o pool de cache e qual. A ativação e desativação do uso de cache para volumes podem ser feitas online sem interromper a E / S. Também no "hot", você pode adicionar SSDs ao pool e removê-los de lá. Ao criar um cache do conjunto SSD, você deve escolher em qual modo ele funcionará: somente leitura ou leitura + gravação. Sua organização física depende disso. Como o cache de conjuntos pode ser vários, a funcionalidade pode ser diferente (ou seja, o sistema pode ter conjuntos de cache para leitura e leitura + gravação ao mesmo tempo).
Se você usar um cache de pool somente leitura, ele poderá consistir em 1 a 8 SSDs. Os discos não precisam ter o mesmo volume e um fornecedor, pois são combinados em uma estrutura NRAID +. Todos os SSDs no pool são compartilhados. O sistema tenta, de forma independente, paralelizar solicitações recebidas entre todos os SSDs para alcançar o desempenho máximo. No caso de falha de um dos SSDs, nada de terrível acontecerá: afinal, o cache contém apenas uma cópia dos dados armazenados em uma matriz de discos rígidos. Apenas a quantidade de cache SSD disponível diminuirá (ou zero, se você usar o cache SSD original de uma unidade).

Se o cache for usado para operações de leitura + gravação, o número de SSDs no pool deve ser um múltiplo de dois, pois o conteúdo é espelhado nos pares de unidades (usando a estrutura NRAID 1+). A duplicação do cache é necessária devido ao fato de que ele pode conter dados que ainda não foram gravados nos discos rígidos. E, nesse caso, a falha do SSD no pool de cache levaria à perda de informações. No caso do NRAID 1+, uma falha no SSD simplesmente levará a uma transição de cache para um estado somente leitura com o despejo de dados não registrados em uma matriz a partir de discos rígidos. Depois de substituir o SSD com falha, o cache retornará ao seu modo original de operação. A propósito, para maior segurança, um cache trabalhando para leitura + gravação pode ser designado como hot spare dedicado.

Ao usar a função de armazenamento em cache SSD no XCubeSAN, existem vários requisitos para a capacidade de armazenamento dos controladores de armazenamento: quanto mais memória do sistema, maior o pool de cache estará disponível.
Diferentemente da maioria dos fornecedores de armazenamento que oferecem apenas a opção liga / desliga como as configurações de cache do SSD, o QSAN fornece mais opções. Em particular, você pode selecionar o modo de operação do cache, dependendo da natureza da carga. Existem três modelos predefinidos que estão mais próximos em seus trabalhos aos serviços correspondentes: banco de dados, sistema de arquivos, serviço da web. Além disso, o administrador pode criar seu próprio perfil, definindo os valores de parâmetro necessários:
- Tamanho do bloco (tamanho do bloco de cache) - 1/2/4 MB
- O número de solicitações para ler um bloco para que ele seja copiado no cache (Limite de População em Leitura) é 1..4
- O número de solicitações para gravar um bloco para que ele seja copiado no cache (Limite de População na Gravação) é 0..4
| 
|
Os perfis podem ser alterados rapidamente, mas, é claro, zerando o conteúdo do cache e seu novo "aquecimento".
Considerando o princípio de operação do cache SSD, podemos distinguir as principais operações ao trabalhar com ele:
Lendo dados quando não estão no cache
- A solicitação do host vai para o controlador;
- Como os solicitados não estão no cache do SSD, eles são lidos nos discos rígidos;
- Os dados lidos são enviados ao host. Ao mesmo tempo, há uma verificação para ver se esses blocos estão "quentes";
- Nesse caso, eles são copiados para o cache do SSD para referência futura.
Lendo dados quando estão presentes no cache
- A solicitação do host vai para o controlador;
- Como os dados solicitados estão no cache do SSD, eles são lidos a partir daí;
- Os dados lidos são enviados ao host.
Gravar dados ao usar o cache de leitura
- Uma solicitação de gravação do host vai para o controlador;
- Os dados são gravados em discos rígidos;
- O host retorna uma resposta sobre a gravação bem-sucedida;
- Ao mesmo tempo, é verificado se o bloco está "quente" (o parâmetro Populate-on-Write Threshold é comparado). Nesse caso, ele é copiado para o cache do SSD para uso futuro.
Gravando dados ao usar cache de leitura / gravação
- Uma solicitação de gravação do host vai para o controlador;
- Os dados são gravados no cache do SSD;
- O host retorna uma resposta sobre a gravação bem-sucedida;
- Os dados do cache SSD em segundo plano são gravados em discos rígidos;
Verificação nos negócios
Suporte de teste2 servidores (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) são conectados por duas portas via Fibre Channel 16G diretamente ao sistema de armazenamento XCubeSAN XS5224D (16GB de RAM / controlador).
Usado 16 x Seagate Constellation ES, ST500NM0001, 500 GB, SAS 6Gb / s, combinado em RAID5 (15 + 1), para matriz de dados e 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, HUSMH8010BSS200, 100GB, SAS 12Gb / s como cache
2 volumes foram criados: um para cada servidor.
Teste 1. Cache somente leitura do SSD com 1-8 SSD
Cache SSD
- Tipo de E / S: Personalização
- Tamanho do bloco de cache: 4MB
- Limite de preencher na leitura: 1
- Limite de preencher na gravação: 0
| Padrão de E / S
- Ferramenta: IOmeter V1.1.0
- Trabalhadores: 1
- Excelente (profundidade da fila): 128
- Especificações de acesso: 4KB, 100% de leitura, 100% aleatório
|
Em teoria, quanto mais SSDs no pool de cache, maior o desempenho. Na prática, isso foi confirmado. O único aumento significativo no número de SSDs com um pequeno número de volumes não leva a um efeito explosivo.
Teste 2. Cache SSD no modo de leitura + gravação com 2-8 SSD
Cache SSD
- Tipo de E / S: Personalização
- Tamanho do bloco de cache: 4MB
- Limite de preencher na leitura: 1
- Limite de preencher na gravação: 1
| Padrão de E / S
- Ferramenta: IOmeter V1.1.0
- Trabalhadores: 1
- Excelente (profundidade da fila): 128
- Especificações de acesso: 4KB, 100% de gravação, 100% aleatório
|
O mesmo resultado: crescimento explosivo do desempenho e dimensionamento com um aumento no número de SSDs.
Nos dois testes, a quantidade de dados operacionais foi menor que o tamanho total do cache. Portanto, com o tempo, todos os blocos foram copiados para o cache. E o trabalho foi, de fato, realizado com um SSD, praticamente sem afetar os discos rígidos. O objetivo desses testes era demonstrar claramente a eficácia do aquecimento do cache e da escalabilidade de seu desempenho, dependendo do número de SSDs.
Agora, vamos voltar do céu à terra e verificar uma situação mais vital quando a quantidade de dados for maior que o tamanho do cache. Para que o teste seja aprovado em um tempo normal (o termo "aquecendo" o cache aumenta significativamente com o aumento do tamanho do volume), nos restringimos ao tamanho de 120 GB.
Teste 3. Emulação do banco de dados
Cache SSD
- Tipo de E / S: Banco de Dados
- Tamanho do bloco de cache: 1MB
- Limite de preencher na leitura: 2
- Limite de preencher na gravação: 1
| Padrão de E / S
- Ferramenta: IOmeter V1.1.0
- Trabalhadores: 1
- Excelente (profundidade da fila): 128
- Especificações de acesso: 8 KB, 67% de leitura, 100% aleatório
|
O veredicto
Como uma conclusão óbvia, é claro, uma boa eficiência do uso do cache SSD sugere aumentar o desempenho de qualquer sistema de armazenamento. Com relação ao QSAN XCubeSAN, esta declaração é totalmente aplicável: a função de armazenamento em cache do SSD é implementada perfeitamente. Isso se aplica ao suporte para leitura e leitura + gravação, configurações flexíveis de trabalho para qualquer caso de uso, bem como ao desempenho final do sistema como um todo. Portanto, por um custo muito razoável (o preço de uma licença é comparável ao custo de 1 a 2 SSDs), você pode aumentar significativamente o desempenho geral.