Dedupe do ZFS (de novo): O uso de memória depende de dados físicos (deduzidos, compactados) armazenados ou de uso lógico?

3

Eu estive pesquisando muito sobre isso, mas não consigo obter informações suficientes sobre isso. A regra de ouro parece ser 5gb de RAM para 1TB de armazenamento. Mas o que é armazenamento realmente? Física ou lógica usada?

Digamos que eu tenha um disco rígido de 6 TB, sem desduplicação, sem compactação. Eu tenho 6 TB de dados reais. Vamos supor que isso tenha deduzido 2: 1, até 3 TB de dados. Nós (aproximadamente) exigiríamos 3 * 5GB de memória ou 6 * 5GB?

Pelo que entendi, depende de um registro. Como não posso armazenar mais de 6 TB de registros reais no disco, cerca de 30 GB devem ser suficientes, independentemente da taxa de compactação / desduplicação, é claro, dependendo do tamanho real dos registros?

O problema é que gostaríamos de calcular o que é mais barato: Substitua os discos 6 * 6TB (3x de armazenamento no local / espelho / hot spare, 3x offsite, não temos mais slots disponíveis nessas caixas) com os maiores para backups, ou compre alguma RAM para ambas as caixas.

(Disclaimer: Eu não sou um administrador de sistemas, mas alguém precisava colocar esse chapéu, para que possamos continuar a ter backups.)

    
por Daniel 19.01.2017 / 10:23

2 respostas

2

Enquanto a resposta do user121391 está correta, o limite de 1/4 para metadados não é mais o caso / não é o caso há muito tempo:

There's a limit to how much of the ZFS ARC cache can be allocated for metadata (and the dedup table falls under this category), and it is capped at 1/4 the size of the ARC

Em primeiro lugar, o zfs_arc_meta_limit (a quantidade de memória cache que pode ser usada para metadados, incluindo a tabela de descompactação) sempre foi ajustável (iirc). Portanto, mesmo em versões muito antigas do ZFS em que 25% pode ter sido o padrão, você poderia usar essa configuração para ajustar a quantidade de cache disponível para metadados. No caso de um sistema de backup em que a maioria dos dados do usuário raramente é acessada, > = 75% para metadados + < = 25% para os dados do usuário pode ser mais apropriado. Por favor, tenha em mente que o dito ajuste é a quantidade de memória disponível em bytes, não uma porcentagem.

Dependendo da sua implementação do ZFS, considere também o seguinte:

Para o ZFS no Oracle Solaris 11 , o limite foi completamente removido por padrão por completo:

Prior to this change being implemented, the ARC limited metadata to one quarter of memory. Whatever the rationale for this might once have been it carries now a serious adverse effect on dedup performance. Because the DDT is considered to be metadata, it is subject to the 1/4 limit. At this point, this limit is an anachronism; it can be eliminated (or rather, set to arc_c).

Então, enquanto você ainda pode definir o limite, não é mais recomendado.

Para o ZFS no Linux até 0.6. x , por exemplo no Ubuntu 16.04, o padrão parece ser 75%:

zfs_arc_meta_limit (ulong): The maximum allowed size in bytes that meta data buffers are allowed to consume in the ARC. When this limit is reached meta data buffers will be reclaimed even if the overall arc_c_max has not been reached. This value defaults to 0 which indicates that 3/4 of the ARC may be used for meta data.

Há também um ajuste se você quiser garantir que uma quantidade mínima de memória seja sempre reservada para metadados:

zfs_arc_meta_min (ulong): The minimum allowed size in bytes that meta data buffers may consume in the ARC. This value defaults to 0 which disables a floor on the amount of the ARC devoted meta data.

Em ZFS no Linux 0.7.0 , parece que há uma maneira de ajustar a quantidade de memória com um limite percentual:

zfs_arc_meta_limit_percent (ulong): Percentage of ARC buffers that can be used for meta data. See also zfs_arc_meta_limit which serves a similar purpose but has a higher priority if set to nonzero value.

Se você planeja usar uma implementação do ZFS baseada em Linux, antes de gastar muito dinheiro em hardware, considere simular seu caso de uso em uma máquina virtual. Eu recomendaria testar o pior caso de dedução (= 100% de dados aleatórios). Se você não tiver os recursos de virtualização necessários à mão, saiba que sempre é possível criar instâncias insanamente grandes na maioria dos provedores de nuvem por algumas horas por muito pouco dinheiro.

Uma última coisa a considerar: Você sempre pode ajustar o tamanho do registro do ZFS. De modo geral, pequenos tamanhos de registros renderão taxas de dedução melhores (mas obviamente exigem mais RAM para a tabela de desduplicação). Tamanhos de registro maiores resultarão em taxas de dedução piores, mas exigirão menos RAM para a tabela de desduplicação. Por exemplo: embora atualmente não utilizemos dedup em nosso armazenamento de backup do ZFS, definimos o tamanho do registro do ZFS como 1M para corresponder ao tamanho de bloco com o qual o aplicativo de backup está trabalhando.

Não sei por que eu acabei de escrever uma tese de doutorado sobre o cache de metadados do ZFS, mas espero que ajude. :)

    
por 31.01.2017 / 23:37
3

O cálculo é do tamanho real do conjunto antes da dedução, ou mais precisamente, do número de blocos armazenados no conjunto (cada bloco precisa de 320 Bytes de espaço no DDT, o número de blocos necessários varia dependendo dos dados reais armazenados ). Portanto, você assumiria 6 * 5 = 30 como regra geral.

Mas isso não é tudo o que é necessário, conforme declarado neste guia excelente em dedup :

The Total RAM Cost of Deduplication

But knowing the size of your deduplication table is not enough: ZFS needs to store more than just the dedup table in memory, such as other metadata and of course cached block data. There's a limit to how much of the ZFS ARC cache can be allocated for metadata (and the dedup table falls under this category), and it is capped at 1/4 the size of the ARC.

In other words: Whatever your estimated dedup table size is, you'll need at least four times that many in RAM, if you want to keep all of your dedup table in RAM. Plus any extra RAM you want to devote to other metadata, such as block pointers and other data structures so ZFS doesn't have to figure out the path through the on-pool data structure for every block it wants to access.

Portanto, a regra dos polegares é estendida:

  • For every TB of pool data, you should expect 5 GB of dedup table data, assuming an average block size of 64K.
  • This means you should plan for at least 20GB of system RAM per TB of pool data, if you want to keep the dedup table in RAM, plus any extra memory for other metadata, plus an extra GB for the OS.

No seu caso, isso chega a aproximadamente 120 GB de RAM, portanto, não está fora de questão para as atuais placas de servidor Xeon E5 (128 - 512 GB de tamanho habitual de RAM por CPU). O artigo também contém um exemplo do mundo real com dólares que devem atendê-lo bem.

    
por 19.01.2017 / 11:14

Tags