ZFS parte 1: conceitos, tuning, compre ou monte o seu data storage server

Este é o primeiro de uma série de artigos sobre ZFS e Btrfs. Abordaremos desde situação legal do código fonte, apresentação básica do funcionamento para administradores de sistemas, passando por tuning, thin provisioning, tiered storage e configurações de alto desempenho, até dicas de como adquirir ou montar seu Data Storage de alto desempenho, com uma boa BIBLIOGRAFIA selecionada. Este artigo não é um tutorial iniciante. É um resumo de lições aprendidas. Leia a bibliografia selecionada para detalhes. Esta parte 1 é focada nos tópicos para análise e consideração no projeto.

Apresentação básica do funcionamento ZFS para administradores de sistemas
Do ponto de vista do administrador de sistemas, ZFS engloba as funções de sistema de arquivos POSIX transacional Copy On Write CoW com checksum e tamanho de blocos dinâmico, gerenciador de snapshots e clones, gerenciador de volumes, gerenciador de dispositivos de blocos e hot spares, RAID, servidor de arquivos NFS, servidor de arquivos SMB (CIFS), servidor de dispositivos de blocos para serviços em softwares externos de iSCSI e Fiber Channel, gerenciador de tiered storage.
Não é sistema de arquivos em cluster nem compartilhado. Mas oferece NFS, SMB, e o necessário para compor um iSCSI ou FC com outros softwares.
Importante característica corporativa é que faz checksum em ciclo completo, escrita e leitura. Isso permite recuperar dados corrompidos após gravação, se houverem informações de paridade suficientes ou espelhamentos por configuração. No mínimo saberá que o dado não é mais confiável.
Também muito importante nas corporações é que permite fazer verificação (scrub ou “fsck”) ONLINE em background com sistema de arquivos em uso.
O tamanho de blocos dinâmico entre 512 Bytes e 128 Kbytes garante melhor utilização de recursos.
Leia a bibliografia recomendada.

Gerenciador de volumes e dispositivos de blocos para iSCSI e Fiber Channel
No ZFS é possível criar um Volume, internamente composto por um conjunto de arquivos pré-alocados ou não, neste caso “sparse”, no sistema de arquivos dentro de um pool e ele o apresentará como um dispositivo de blocos.
Quando é apresentado como um dispositivo de blocos virtual (vdev), então pode ser exportado como um target iSCSI ou Fiber Channel através de outros softwares, como o ComStar.
Importante notar que um vdev pode ser composto por dispositivos de blocos físicos, ou até outros vdevs, como arquivos, volumes, mirror, raidz, spare, log, cache.
Leia a bibliografia recomendada.

ZFS thin provisioning
Se o Volume no sistema de arquivos dentro do pool for criado como sparse, ele não pré-alocará espaço significativo no disco. Apenas alguns estruturas de controle. O dispositivo de blocos resultante declarará o espaço especificado, mas consumirá muito menos fisicamente no disco.
Apenas ocupará efetivamente quando dados forem escritos. É o thin provisioning.
O administrador de sistemas deverá acompanhar a mudança no espaço efetivo utilizado e, caso necessário, aumentar o tamanho físico do pool incluindo novos dispositivos de blocos.
Voltaremos ao assunto em outro artigo.
Leia a bibliografia recomendada.
Veja os resultados da Intel para thin provisioning, tiered storage, desduplicação.

ZFS tiered storage with Hybrid Storage Pool
O ZFS por definição de arquitetura tem Hybrid Storage Pool. Os dados automaticamente migram entre cache tipo Adaptative Replacement Cache, ARC (composto de um MRU e um MFU, conjugados a MRU Ghost e MFU Ghost) de memória e tipos de armazenamento que constituem o pool.
Basicamente, para sair do RAM L1 cache tipo ARC via ZFS POSIX Layer ZPL , os dados de escrita síncronaprimeiro são gravados no ZFS Intent Log, ZIL, que é um log de transações, e periodicamente em grupos de transações a sincronizar (sync transaction group) escritos também na área permanente do pool. Em seguida as transações correspondentes são descartadas do ZIL.
O ZIL só é lido em recuperação de desastres, para fazer um REDO log , um replay do log das transações pendentes e levar o sistema de arquivos a um estado consistente. Repare que uma transação não é lida do ZIL para a área permanente em utilização normal. Sai do L1 ARC para área permanente periodicamente, já tendo migrado para o sync transaction group na RAM.
ZIL pode estar espalhado no espaço de armazenamento permanente, arquivos normais sem área específica, ou ser um vdev separado.
Os dados de leitura podem ser lidos da área permanente para um opcional L2 ARC, constituído de vdevs diferentes e também lidos para o ARC. Na próxima leitura em que não estiver no L1 ARC, tentará do L2 ARC antes de ler da área permanente.
No data path de escrita síncrona, temos L1 ARC, ZIL “e” área permanente.
No data path de escrita assíncrona, temos L1 ARC, área permanente.
No data path de leitura, temos área permamente, opcional L2 ARC, L1 ARC.
Leia a bibliografia recomendada.
Leia os resultados da Intel para thin provisioning, tiered storage, desduplicação.

ZFS tuning
A bibliografia recomendada deve ser consultada. Mas a orientação básica é a seguinte:

Mais ECC RAM para o L1 ARC.
Ainda mais ECC RAM.
Precisa instalar mais ECC RAM.
Já falei que precisa mais ECC RAM?
Quanta ECC RAM afinal? Idealmente, até o suficiente para conter seu dataset ativo. Comece estimando 1 GB ECC RAM para cada 1 TB armazenado. Dado empírico. Analise suas estatísticas com o zilstat.sh e arcstat.pl.
Quantos IOPS você precisa? Quantos discos são necessários para atingir isso? Em que configuração? Como distribuir os subconjuntos de acordo com os IOPS? Essencial saber isso.
Não formate, particione ou virtualize (RAID, LVM ou similar) os discos. Simplesmente entregue os raw block devices para o ZFS gerenciar.
Então configure um Hybrid Storage Pool com vdevs de alto IOPS no ZIL e L2 ARC.
Aumente os IOPS dos vdevs no HSP ou compre outros tipos de dispositivo de blocos com maior IOPS para ZIL e L2ARC. Mirrored vdevs tem mais IOPS que RAIDZ.
Quanto L2 ARC? Idealmente, o suficiente para conter seu dataset ativo.
Qual o tamanho do dataset ativo? Isso depende de seu ambiente e aplicações e terás de medir. Cada caso é um caso. A experiência mostra estimativa inicial em até 20% dos dados totais. Mas o dado é empírico. Avalie seus dados do arcstat.pl.
Quanto ZIL? O suficiente para conter ao menos 2 períodos de 5 segundos (período default do flush de ARC) de escrita síncrona em máxima velocidade dos vdevs. Se o ZIL saturar antes do flush, a escrita síncrona passará a ir diretamente para a lenta área permanente do pool.
Precisa mesmo de atime?
ZIL logbias=latency no filesystem em uso?
Deduplicação consome muita ECC RAM. Veja bibliografia de como dimensionar. Considere usar compressão (baixa ou alta?) que resolveria 2 problemas de uma vez e até poderia aumentar desempenho em certos cenários. Como estimativa inicial, a tabela de deduplicação consome 5 GB para cada 1 TB armazenado.
Se for SGBD pode ser indicado alterar o tamanho do bloco para um volume ou filesystem num dado pool.
Veja a bibliografia recomendada para os parâmetros secretos de kernel tuning. Veja a memória RAM permitida e a pressão de memória sobre o cache. Não exagere: cuidado com o pior tempo necessário para liberar RAM. O Solaris e descendentes pré-alocam até 80% da RAM para ZFS. O zfs-fuse tem um arquivo simples de configuração que permite ajustar a RAM para o L1 ARC. Pode ser que sobre muita RAM no seu sistema e seja possível deixar apenas 1,5 GB RAM para o kernel e outros serviços básicos como ComStar. Avalie com cuidado. Raramente necessário alterar.
Contrate consultoria ou estude ainda mais que nós. Se chegou neste ponto, alcançou aquele 1% de casos que demandam 99% do esforço e investimentos.

Leia a bibliografia recomendada.

ZFS em configurações de alto desempenho
ZFS utiliza MUITA ECC RAM para o L1 ARC. O desempenho é fortemente influenciado pela quantidade de ECC RAM para o L1 ARC. Use sempre tipo ECC para prevenir erros silenciosos impossíveis de corrigir.
Depois da ECC RAM para o L1 ARC, ZFS utiliza MUITO poder de CPU, especialmente se utilizar compressão. Sempre calcula checksum. Quanto maior o número de núcleos e mais rápidos, melhor.
Então escolha os mais rápidos (high write IOPS) dispositivos de blocos que puderes adquirir para o mirrored ZIL, que tem forte impacto na LATÊNCIA do tempo de resposta e experiência do usuário. Como o ZIL é geralmente pequeno devido aos critérios de cálculo já apresentados, tente adquirir do tipo Enterprise ECC RAM SSD ou uma LUN em Enterprise RAM Data Storage.
Mirrored ZIL para alto desempenho e confiabilidade. Sem ZIL válido mesmo que vazio, não recupera um crashed filesystem. Se puder, aumente o número de espelhos por segurança. Avalie o impacto no desempenho.
Para o L2 ARC, que é idealmente maior que o ZIL, escolha o segundo tipo mais rápido de dispositivo de blocos que puderes adquirir. Enterprise Flash SLC SSD, Enterprise Flash MLC SSD são bons exemplos. Na prática, não vale muito a pena usar discos rotativos para L2 ARC, devido à pouca diferença de ganho entre discos 15 Krpm e 7,2 Krpm e o trabalho extra de popular o L2 ARC. Avalie e teste com cuidado.
Como L2 ARC é exigido na leitura, aumente o desempenho usando vdevs como striped block devices. Infelizmente L2 ARC não pode ser espelhado ainda.
Para a área permanente do pool, discos mais lentos porém ainda confiáveis. Enterprise NL-SAS, Enterprise SATA 7,2 krpm ou mesmo 5,4 krpm podem ser suficientes. Avalie seu cenário.
Para a área permanente, se as outras recomendações foram seguidas, você pode testar se o desempenho em IOPS de RAIDZ1 ou 2 ou 3 ainda é suficiente. Verifique se possui poder de CPU suficiente para calcular paridade 1, 2 ou 3 vezes em pools com mais de 8 vdevs. Podes tentar um trade-off usando RAIDZ1 e aumentando número de spares e favorecendo o desempenho. Quanto maior o número de vdevs no RAIDZ, menor o gasto relativo de espaço em paridade. Mas aumenta o uso de CPU.
Se você não tem ZIL separado nem L2 ARC, precisará discos rápidos em configuração pool striped over mirror vdevs para maior IOPS. Inicie com pares de espelhos fazendo cada stripe. Similar a RAID 10. Designe sempre ao menos um spare disk para o pool.
Como assim vai gastar 50% do espaço bruto com espelhamento, dependendo do tamanho do pool pode ser vantajoso investir em discos melhores para o ZIL e L2 ARC. Faça as suas contas para seu cenário.
Não abra mão dos spare disks. O custo deles é muito inferior ao downtime de um pool em produção.
Repare na bibliografia que um spare disk acionado VOLTA a ser spare disk se o disco que falhou for fisicamente e depois logicamente substituído com os comandos apropriados.
Existem alguns consumer desktop grade RAM Drives na bibliografia. Mas não utilize em aplicações de missão crítica corporativas, pois nem usam ECC RAM.
Rede TCP 10 Gb/s ou Fiber Channel 8 Gb/s.
Leia a bibliografia recomendada.

Como adquirir ou montar seu ZFS Data Storage de alto desempenho
Conceitualmente, você precisará ter uma poderosa CPU com bastante ECC RAM conectada a um JBOD contendo dispositivos de blocos de variados tipos para formar o HSP.
Já visto como escolher e dimensionar em outros tópicos, precisará satisfazer pela ordem

Fontes de alimentação e ventilação redundantes, enterprise grade.
No-break, UPS.
Muita, muita ECC RAM, com capacidade de expansão.
muitos e rápidos núcleos de CPU,
Quantos IOPS você precisa? Quantos discos são necessários para atingir isso? Em que configuração?
discos enterprise de diferentes tamanhos e desempenhos respectivamente para ZIL, L2 ARC, área permanente, configurados em JBOD ou DAS.
Múltiplas interfaces de rede TCP 10 Gb/s ou Fiber Channel 8 Gb/s.

Pesquisar este blog

Tech Force - blog sobre tecnologia

ZFS parte 1: conceitos, tuning, compre ou monte o seu data storage server

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Tutorial Cyrus IMAP aggregator (murder) 2.3.16 sobre Debian GNU Linux 5.x Lenny

How to configure multipath for high availability and performance on Debian and CentOS for storage at IBM DS8300 SAN

Instalar Squid forward proxy com SSL cache (SSL bump) em Rocky Linux 8.9 para cache de pacotes na infrestrutura