Configurando o cache do ZFS para io de alta velocidade

Configurando o cache no seu pool ZFS

Se você já passou por nossas postagens anteriores no Basics do ZFS, você já conhece que este é um sistema de arquivos robusto. Ele executa somas de verificação em todos os blocos de dados que estão sendo escritos no disco e metadados importantes, como as próprias somas de cheques, são escritas em vários lugares diferentes. O ZFS pode perder seus dados, mas é garantido que nunca lhe devolva dados errados, como se fossem os certos.

A maior parte da redundância para um pool ZFS vem dos VDEVs subjacentes. O mesmo vale para o desempenho do pool de armazenamento. O desempenho de leitura e gravação pode melhorar bastante pela adição de SSDs de alta velocidade ou dispositivos NVME. Se você usou discos híbridos em que um SSD e um disco giratório são incluídos como um único hardware, então você sabe o quão ruim os mecanismos de cache de nível de hardware são. ZFS não é nada assim, por causa de vários fatores, que exploraremos aqui.

Existem dois caches diferentes que uma piscina pode usar:

1. Log de intenção do ZFS, ou ZIL, para buffer operações de gravação.
2. Arco e l2arc, destinados a operações de leitura.

Gravações síncronas vs assíncronas

O ZFS, como a maioria dos outros sistemas de arquivos, tenta manter um buffer de operações de gravação na memória e depois escrevê -lo nos discos, em vez de escrevê -lo diretamente nos discos. Isso é conhecido como assíncrono Escreva e fornece ganhos decentes de desempenho para aplicativos que são tolerantes a falhas ou onde a perda de dados não causa muito dano. O sistema operacional simplesmente armazena os dados na memória e informa ao aplicativo, que solicitou a gravação, que a gravação está concluída. Este é o comportamento padrão de muitos sistemas operacionais, mesmo ao executar o ZFS.

No entanto, permanece o fato de que, em caso de falha do sistema ou perda de energia, todas as gravações em buffer na memória principal são perdidas. Portanto, os aplicativos que desejam a consistência sobre o desempenho podem abrir arquivos em síncrono Modo e, em seguida, os dados são considerados apenas escritos quando estão realmente no disco. A maioria dos bancos de dados e aplicativos como o NFS depende de graus síncronos o tempo todo.

Você pode definir a bandeira: sincronização = sempre Para fazer síncrono, grava o comportamento padrão para qualquer conjunto de dados.

Obviamente, você pode desejar ter um bom desempenho, independentemente de os arquivos estarem ou não no modo síncrono. É aí que Zil entra em cena.

ZFS Intent Log (ZIL) e dispositivos de slog

O ZFS Intent Log refere -se a uma parte do seu pool de armazenamento que o ZFS usa para armazenar dados novos ou modificados primeiro, antes de espalhá -los por todo o pool de armazenamento principal, removendo -se em todos os VDEVs.

Por padrão. No entanto, você pode fazer melhor se tiver um pequeno NVME ou qualquer outro tipo de SSD à sua disposição.

O pequeno e rápido armazenamento pode ser usado como um registro de intenção separado (ou slog), que é onde os dados recém -chegados seriam armazenados temporariamente antes de serem descartados no armazenamento principal maior da piscina. Para adicionar um dispositivo de slog, execute o comando:

Onde tanque é o nome da sua piscina, registro é a palavra -chave dizendo aos ZFs para tratar o dispositivo Ada3 Como um dispositivo de slog. O nó do dispositivo do seu SSD pode não ser necessariamente Ada3, Use o nome do nó correto.

Agora você pode verificar os dispositivos em seu pool, como mostrado abaixo:

Você ainda pode estar preocupado que os dados em uma memória não volátil falhem, se o SSD falhar. Nesse caso, você pode usar vários SSDs refletindo um ao outro ou em qualquer configuração Raidz.

Para a maioria dos casos de uso, os pequenos 16 GB a 64 GB de armazenamento flash muito rápido e durável são os candidatos mais adequados para um dispositivo de slog.

Cache de reposição adaptativa (ARC) e L2ARC

Ao tentar cache as operações de leitura, nossas mudanças objetivas. Em vez de garantir que tenhamos um bom desempenho, além de transações confiáveis, agora o motivo do ZFS muda para prever o futuro. Isso significa que, cache as informações que um aplicativo exigiria em um futuro próximo, ao mesmo tempo em que descartará as que serão necessárias mais à frente no tempo.

Para fazer isso, uma parte da memória principal é usada para os dados de armazenamento em cache que foram usados ​​recentemente ou os dados estão sendo acessados ​​com mais frequência. É aí que o termo cache de reposição adaptativa (arco) vem. Além do cache de leitura tradicional, onde apenas os objetos usados ​​recentemente são armazenados em cache, o arco também presta atenção à frequência com que os dados foram acessados.

L2arc, ou arco de nível 2, é uma extensão do arco. Se você possui um dispositivo de armazenamento dedicado para atuar como seu L2arc, ele armazenará todos os dados que não são muito importantes para permanecer no arco, mas ao mesmo tempo que os dados são úteis o suficiente para merecer um lugar na memória mais lenta do que a memória Dispositivo NVME.

Para adicionar um dispositivo como o L2arc ao seu pool ZFS, execute o comando:

Onde tanque é o nome da sua piscina e Ada3 é o nome do nó do dispositivo para o seu armazenamento L2arc.

Resumo

Para encurtar uma longa história, um sistema operacional geralmente buffers escreve operações na memória principal, se os arquivos forem abertos no modo assíncrono. Isso não deve ser confundido com o cache de gravação real do ZFS, ZIL.

Zil, por padrão, faz parte do armazenamento não volátil do pool, onde os dados vão para o armazenamento temporário antes de se espalhar corretamente por todos os VDEVs. Se você usa um SSD como um dispositivo ZIL dedicado, ele é conhecido como slog. Como qualquer vdev, o slog pode estar na configuração espelhada ou Raidz.

Leia o cache, armazenado na memória principal, é conhecido como arco. No entanto, devido ao tamanho limitado da RAM, você sempre pode adicionar um SSD como um L2arc, onde coisas que não podem caber na RAM são armazenadas em cache.