Referências principais

O ZFS L2ARC (Brendan Gregg) (22-07-2008) e o ZFS e o conceito de armazenamento híbrido (Blog da Anatol Studler) (11-11-2008) incluem o seguinte diagrama:

Questão

Devo interpretar a linha branca vertical - na camada SSDs - como uma preferência para usar SSDs separados -

• uma preferência para não misturar L2ARC e ZIL em um único disco?

Antecedentes (resposta aos comentários)

Pessoalmente, em casa, é improvável que eu use o L2ARC ou o ZIL com qualquer computador disponível para mim. (Meu computador comum é um MacBookPro5,2 com 8 GB de memória e o híbrido Seagate ST750LX003-1AC154. Não há planos de substituir a unidade óptica por um SSD.)

Em outros lugares: no trabalho, haverá um novo redirecionamento do kit, mas não tenho uma data ou detalhes completos. (Xserve RAID x2 na mistura ... no momento não imagino entregá-los ao ZFS, mas mantenho a mente aberta.)

Minha curiosidade sobre as melhores práticas de SSD para o L2ARC e o ZIL começou enquanto seguia as discussões relacionadas ao desempenho na área do ZEVO - em particular o tópico mencionado abaixo, onde um usuário tem o L2ARC e o ZIL em um único disco.

Outras referências e discussões

Imagens de L2ARC (Brendan Gregg) (30-0-2009)

Imagens de SLOG (Brendan Gregg) (26-06-2009)

[zfs-discuss] O backup raiz ZFS / recuperação de "desastre" e a movimentação do pool raiz (2011-01-10) recomendam uma mistura de três itens (pool raiz, ZIL e L2ARC) em um único disco -

… Não vale a pena as dores de cabeça que podem ocorrer ao tentar gerenciar todos os 3 no mesmo disco. Por exemplo, se você decidir reinstalar e obstruir acidentalmente o conteúdo do ZIL do seu conjunto de dados. Não compartilhe discos para componentes de pool ou entre pools para manter o gerenciamento e a recuperação simples. ...

- Estou mais interessado em saber se é recomendável não misturar duas dessas coisas em um único disco.

/superuser//a/238744/84988 (2011-01-28) menciona "cache (cache L2ARC) e grava log (ZIL) no SSD" ( singular ). No entanto, no que se refere ao FUSE e ao Windows, não trato essa resposta como particularmente relevante para os usos mais comuns e voltados para o desempenho do ZFS.

O @ChrisS mencionou ZIL e L2ARC na The Comms Room em 16/08/2011 .

http://forums.macrumors.com/showpost.php?p=14248388 (31-01-2012) discute vários SSDs:

Algo que você precisa entender sobre o ZFS: Ele possui dois tipos diferentes de cache, leitura e gravação (L2ARC e ZIL), normalmente armazenados em SSDs. O ZIL é o cache de gravação. Provavelmente é daí que vem esse equívoco. O ZIL está sendo martelado (assumindo um sistema ativo) a cada gravação que ocorre no zpool. O problema é que o uso de um SSD baseado em mlc como ZIL faz com que se desgastem e falhem rapidamente. Você precisa de um SSD baseado em slc (muito mais caro) para ser usado como uma unidade ZIL.

Ter um zpool composto inteiramente de SSDs não é apenas possível, mas funciona muito bem. Ele também basicamente elimina a necessidade de unidades separadas para o ZIL e o L2ARC. Sim, você não tem suporte ao TRIM, mas com base na natureza de cópia na gravação do ZFS, isso provavelmente é uma coisa boa.

Dito isso, o ZFS NÃO funciona bem com zpools quase cheios (digamos, 85% ou mais). O desempenho começa a diminuir significativamente - independentemente de você estar usando mídia magnética rotacional ou de estado sólido. A falta de suporte ao TRIM provavelmente exacerbaria esse problema, mas já é um problema.

/server//a/397431/91969 (11/06/2012) recomenda:

• SSD do tipo SLC (especificamente não MLC) para ZIL
• SSD do tipo MLC para L2ARC.

/superuser//a/451145/84988 (19/07/2012) menciona um "SSD singular para o ZIL e o L2ARC para acelerar o ZFS".

zevo.getgreenbytes.com • Exibir tópico - Problema de desempenho com a ordem de conexão do FW800? (24/09/2012) se preocupa com a ordem das coisas em um barramento FireWire com um único SSD para ZIL e L2ARC

• pedido de ônibus à parte, esse tópico do ZEVO me fez pensar se seria preferível um SSD separado.

Mais especificamente: eu me perguntava sobre interpretações da linha branca no diagrama acima…

Resposta curta, já que não vejo qual problema você está procurando resolver ...

Se puder, use dispositivos separados. Isso depende da escala do seu ambiente ... Se for apenas um sistema doméstico simples ou uma solução ZFS virtualizada ou tudo em um , você poderá usar um único dispositivo.

Em soluções ZFS maiores ou de alto desempenho, uso dispositivos adequados especificamente para suas funções ZIL ou L2ARC ... Por exemplo, STEC ZeusRAM ou DDRDrive for ZIL e qualquer SLC corporativo ou SSD MLC SAS para L2ARC.

• Os dispositivos ZIL devem ser de baixa capacidade e baixa latência, capazes de altos IOPS. Eles geralmente são espelhados.
• Os dispositivos L2ARC devem ter alta capacidade (dentro do motivo: você precisa adicionar RAM à medida que o tamanho L2ARC aumenta). Eles escalam por faixas.

O que você está fazendo?

Existem alguns conceitos errôneos fundamentais desde o início sobre o ZIL que precisam ser corrigidos antes de continuar.

Entenda isto: Em circunstâncias "normais", o ZIL / SLOG não é tocado.

Ele é gravado somente quando as gravações síncronas são comandadas ou se sync = always estiver ativado em um conjunto / conjunto de dados específico ("zfs get sync pool / dataset")

O ZIL nunca é lido em circunstâncias normais. É um recurso de recuperação de desastre.

IE: O ZIL está lá apenas para quando a energia é desligada. É usado para reproduzir dados que foram devolvidos ao sistema operacional antes que esses dados fossem confirmados no pool. Todas as gravações do ZFS no pool (sincronização ou assíncrona) são de buffers de memória.

Em circunstâncias normais, uma vez que os dados atingem o pool, a entrada de slog é evaporada - é apenas um grande buffer de gravação circular e não precisa ser muito grande (até 1 GB é um exagero na maioria das circunstâncias)

As gravações não síncronas são armazenadas em buffer no ram, agrupadas e gravadas no disco em um momento oportuno. se a energia desligar, esses dados são perdidos, mas a integridade do FS é mantida (é por isso que você pode definir sync = always)

Por outro lado, o L2ARC é fortemente martelado no nível de leitura e gravação.

Existe algo como "l2arc em excesso", porque os metadados do conteúdo em l2arc saem da ram ARC (ou seja, se você aumentar o tamanho da l2arc, deverá aumentar a ram para se adequar. Caso contrário, isso poderá resultar em grave degradação do desempenho e eventualmente, o uso do l2arc se estabilizará em algum nível bem abaixo de "todo o espaço disponível")

Apesar dos protestos de alguns fabricantes, você não pode compensar um déficit de memória aumentando os tamanhos de l2arc (vários fabricantes de matrizes de raide de hardware que se ramificaram nos dispositivos ZFS fizeram essa suposição)

tl; dr: Se sua carga de E / S for uma atividade do banco de dados, é provável que o ZIL seja afetado com força. Se houver outra coisa, é provável que ela seja levemente tocada. É altamente provável que em 99,9% da atividade as funções do ZIL nunca entrem em ação.

Sabendo disso, você poderá decidir se precisa de uma partição SLOG para o ZIL, se pode coabitar com a partição l2arc ou se precisa de uma unidade autônoma (e qual o nível de desempenho dessa unidade autônoma).