Zfs: Solicitação de recurso - clone dividido online

Parece que zfs promote já pode fazer o que você precisa.

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

Eu estava olhando para o zfs promotion, mas isso parece apenas para mudar a relação pai-filho ...

o que eu estava pensando era um estado final onde ambos os sistemas de arquivos são completamente independentes um do outro ...

alguns casos de uso para isso podem ser
clonagem de modelos de VM - ter uma imagem de base que é clonada para criar outras VMs, que por sua vez são divididas do modelo para que o modelo possa ser atualizado / destruído / recriado
clones de banco de dados - clonagem de um banco de dados de produto para dev que passará por muitas mudanças e que, por sua vez, pode ser a base para um clone de teste em si, no caso de ser bom dividir o dev do produto, pois o instantâneo de base pode ficar maior do que ter um sistema de arquivos independente para dev

Depois de clonar o @ snapshot original, você pode modificar o conjunto de dados e o clone livremente, eles não afetarão um ao outro, exceto que compartilham dados ainda comuns a ambos no disco.

Se você quiser destruir / recriar o modelo (original), você pode simplesmente destruir todos os instantâneos nele (exceto aquele (s) usado (s) como origens de clones), zfs renomear original e zfs criar um novo com o mesmo nome (propriedade origin de clones não está vinculado ao nome do conjunto de dados original, portanto, você pode renomear os dois livremente).

A única desvantagem disso é que todos os dados _únicos_ mantidos no @ snapshot original (= base do clone) não podem ser liberados a menos que você esteja disposto a destruir o (s) clone (s) ou (após uma promoção do clone) o original.

@greg-hidrogênio no final você determinou se zfs promote atendia às suas necessidades? Ou ainda existe uma solicitação de recurso possível aqui.

Para comentar sobre isso, seria bom se houvesse uma funcionalidade para transformar os relacionamentos origem-clone em um tipo desduplicado: removendo os links lógicos que impedem os conjuntos de dados de serem destruídos individualmente à vontade - enquanto mantém apenas uma cópia do ainda compartilhado dados.

@behlendorf : quase certamente não atende a necessidade.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
faz um bom trabalho ao explicar o problema.

Aqui está o que estou tentando fazer conceitualmente:

usuário @ backup :

1. gerar um instantâneo baseado em data
2. envie-o de backup para testar como um espelho

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

usuário @ teste :

1. crie um lugar para higienizar o espelho
2. higienizar
3. instantâneo
4. clone a versão higienizada para uso
5. use-o

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

usuário @ backup :

1. tendo usado a produção ainda mais ...
2. criar um instantâneo atualizado
3. envie as mudanças incrementais de produção para teste
4. exclua o marcador incremental anterior (que no meu caso libera 70 GB)

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

usuário @ teste :

• é aqui que aparecem os problemas.
• com alguma dose de bajulação, pode-se destruir os volumes de sanitização.
• Mas, fico com test/mirror@20170901 que é a origem das duas coisas restantes: test/mirror@20170908 e test/test .
• Eu poderia destruir o espelho atualizado ( test/mirror@20170908 ) se quisesse, mas isso não me adianta nada (já que meu objetivo é usar esses dados).

Para que eu possa progredir, eu realmente tenho que executar o sanitize, parar o que está usando o teste, destruir o teste (completamente), clonar o espelho como teste, reiniciar a coisa usando o teste e, então, posso finalmente tentar destruir o original instantâneo. Ou posso decidir que vou dar uma passada, acionar um novo instantâneo no backup mais tarde e enviar seu incremento, excluir o instantâneo que nunca foi espelhado para teste e tentar novamente.

Fwiw, para ter um gostinho disso ...:

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(os números estão realmente errados, na verdade eu tenho 1 volume com 4 volumes contidos, daí os sinalizadores recursivos ...)

Agora, eu entendo que posso usar zfs send | zfs recv para quebrar dependências, e para pequenas coisas tudo bem. Mas esta parte do meu pool tem aproximadamente o dobro do espaço disponível no pool e a metade é provavelmente maior do que isso, o que significa que a execução dessa operação é problemática. Também é uma grande quantidade de bytes para reprocessar. Minha esperança em usar instantâneos era poder me beneficiar do COW, mas em vez disso, estou sendo cobrado pelo COW porque o ponto de ramificação que eventualmente terá dados usados ​​por nenhum dos lados da minha árvore de ramificação ainda deve ser pago.

@behlendorf Oi, algum progresso nisso? Dividir o clone de seu sistema de arquivos original será realmente ótimo para modelos de VMs e / ou grandes restaurações em nível de arquivo. Veja o link @jsoref colado acima para um exemplo prático.

@kpande : o objetivo é pagar (em espaço e transferência de dados) pelo que mudou (COW), não por todo o conjunto de dados (cada vez que essa operação acontece).

Se eu tivesse um conjunto de dados móvel de 10 TB e uma variação do conjunto de dados que desejo estabelecer, com certeza, poderia copiar os 10 TB, aplicar a variação e pagar por 20 TB (se eu tiver 20 TB disponíveis). Mas, se minha variação é realmente apenas 10 MB diferente dos 10 TB originais, por que não deveria ser capaz de pagar por 10 TB + 10 MB? - instantâneos + clones me dê isso. Até que os 10 TB se movam o suficiente para que eu esteja pagando por 10 TB (ao vivo + 10 TB de instantâneo + 10 TB divergidos) e minha variação de 10 MB se mova de forma que agora sejam seus próprios 10 TB (divergente tanto ao vivo quanto ao instantâneo). Nesse ínterim, para "consertar" meu problema de 30 TB, preciso gastar mais 10 TB (= 40 TB - por meio de seu zfs send + zfs recv). Isso não é o ideal. Claro, ele "funcionará", mas não é "rápido" nem remotamente eficiente em termos de espaço.

O envio / recebimento redigido parece interessante (já que mais ou menos corresponde ao meu caso de uso) - mas embora eu possa encontrá-lo mencionado em vários lugares, não consigo encontrar nenhuma explicação útil sobre o que ele está realmente redigindo.

Fwiw, para o nosso sistema, mudei para que a higienização aconteça no lado de envio (o que também é melhor do ponto de vista da privacidade), o que nos tirou de perigo.

Existem instâncias em que a variação de dados não está "redigindo" e em que o sistema tem os recursos para zfs snapshot + zfs send, mas não deseja realmente alocar os recursos para hospedar um segundo banco de dados para fazer a "mutação" - e não quer ter que pagar para enviar todo o volume entre primário e secundário (ou seja, prefere enviar um instantâneo incremental para um sistema que já possui o instantâneo anterior).

Sim, estou ciente de que posso usar a dedup. Estamos pagando por nosso cpus / ram, portanto, dedicar cpu + ram constante para fazer uma tarefa rara (atualizar o clone mutado) pareceu uma troca ruim (prefiro pagar por um pouco mais de espaço em disco).

@kpande este link mostra claramente o problema com os clones atuais. Afinal, se um clone diverge tanto do instantâneo de base, a relação pai-> filho permanente entre os dois é uma fonte de confusão. Dividir o clone seria uma indicação clara de que eles divergiram tanto a ponto de não serem mais considerados empatados.

Mas deixe-me dar um exemplo mais prático.

Seja kvm/vmimages um contêiner de armazenamento de dados para várias imagens de disco virtual, com instantâneos tirados diariamente. Eu sei que a resposta padrão seria "use um conjunto de dados para cada disco", mas os pools de libvirt não funcionam bem com isso. Portanto, temos algo como:

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

Em algum ponto, algo ruim acontece ao disco vm (por exemplo: corrupção grave do sistema de arquivos convidado), mas enquanto isso, outros usuários estão ativamente armazenando dados novos e importantes em outros discos. Você basicamente tem alguns requisitos contrastantes: a) para reverter para os dados antigos e não corrompidos de ontem, b) para preservar quaisquer novos dados carregados, que não são encontrados em nenhum instantâneo ec) para causar interrupção mínima do serviço.

Os clones vêm à mente como uma solução possível: você pode clonar kvm/vmimages@snap3 como kvm/restored para restaurar imediatamente o serviço para a VM afetada. Então você agora tem:

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

A VM afetada é executada em kvm/restored , enquanto todas as outras permanecem em kvm/vmimages . Neste ponto, você exclui todos os discos extras de kvm/restored e o disco original corrompido de kvm/vmimages . Tudo parece bem, até que você perceba que a antiga imagem de disco corrompida ainda está usando espaço em disco real, e qualquer sobrescrita em kvm/restored consome espaço adicional devido ao antigo kvm/vmimages@snap3 eliminável. Você não pode remover este instantâneo antigo sem remover seu clone também, e você não pode simplesmente promover kvm/restored e excluir kvm/vmimages porque não é a única fonte de dados "autorizada" verdadeira (isto é: dados reais são armazenados dentro de ambos os conjuntos de dados).

Dividir um clone de sua origem resolveria completamente o problema acima. Não está claro para mim como o envio / recebimento redigido ajudaria neste caso.

@kpande primeiro, obrigado por compartilhar sua visão e sua solução (o que é interessante!). Concordo totalmente que uma configuração de convidado cuidadosa e muito específica (e a árvore do conjunto de dados do host) pode evitar o problema exposto acima.

Dito isso, libvirt (e sua implementação de pools de armazenamento) não funciona muito bem com essa abordagem, especialmente ao gerenciar ambientes mistos com máquinas virtuais Windows. Ainda mais, este foi apenas um único exemplo. Os clones divisíveis seriam muito úteis, por exemplo, quando usados ​​para criar uma "imagem base / mestre de ouro", que pode ser instanciada à vontade para criar máquinas virtuais "reais".

Com o estado atual do caso, fazendo que será imposto você pesadamente no espaço alocado, como você não será capaz de nunca remover o original, potencialmente obsoletos, instantâneo. O que me surpreende é que, sendo ZFS um sistema de arquivos CoW, esta deve ser uma operação relativamente simples: ao excluir o instantâneo original, "simplesmente" marque como livre qualquer bloco não referenciado e remova a relação pai / filho. Em outras palavras, vamos clonar um sistema de arquivos real, desembaraçado de qualquer instantâneo de origem.

Observe que usei o mundo "simplesmente" entre aspas: embora seja de fato uma operação lógica simples, não tenho certeza se / quão bem ele mapeia para o sistema de arquivos zfs subjacente.

@kpande ok, justo - se existe um problema técnico real, devo aceitá-lo. Mas isso é diferente de afirmar que um caso de uso específico é inválido.

Se essa visão (ou seja: impossibilidade de dividir um clone de seu instantâneo pai original sem envolver o BPR "mítico") for compartilhada pelos desenvolvedores do zfs, acho que este FR pode ser fechado.

Obrigado.

+1 sobre a necessidade deste recurso. Sim, enviar / receber pode ser usado, mas isso exigiria tempo de inatividade de tudo o que está usando esse conjunto de dados para alternar do antigo (clone) para o novo.

Já me deparei com situações com LXD em que um contêiner é copiado (clonado), mas isso causa problemas com meu instantâneo gerenciado separadamente.

@kpande : novamente, meu caso de uso tem o conjunto de dados inteiro sendo um banco de dados e algumas variações do banco de dados.

Pelo que tenho visto, não parece que overlayfs funciona bem com w / zfs como o sistema de arquivos (parece feliz com w / zvols e ext4 / xfs de acordo com suas notas). Parece que essa abordagem cobriria a maioria dos casos, caso em que a documentação explicando como configurar overlayfs com ext4 / xfs seria bem-vinda.

Dito isso, alguns de nós estão usando o zfs não apenas para o gerenciamento de volume, mas também para o comportamento / navegação acl / allow / snapshot, e gostariam de poder usar overlayfs w / zfs em vez de ext4 / xfs, então se isso não não é possível, há um bug para isso? Se houver, seria bom se isso fosse destacado (a partir daqui), se não, se você está endossando a abordagem overlayfs, talvez você pudesse arquivá-lo (se você insiste, provavelmente poderia escrever, mas não não sei nada sobre overlayfs, e essa parece ser uma tecnologia-chave na redação).

Pelo que tenho visto, não parece que overlayfs funciona bem com w / zfs como o sistema de arquivos (parece feliz com w / zvols e ext4 / xfs de acordo com suas notas). Parece que essa abordagem cobriria a maioria dos casos, caso em que a documentação explicando como configurar overlayfs com ext4 / xfs seria bem-vinda.

A abordagem overlayfs não funcionará para um caso de uso extremamente importante e comum: clonar uma imagem virtual a partir de outra (ou um modelo "master gold"). Nesse caso, dividir o clone seria fundamental para evitar o desperdício de espaço à medida que as imagens originais / clonadas divergem.

@ ptx0 isso só funciona se o sistema operacional convidado overlayfs ( sem suporte para VMs do Windows) e se o usuário final (ou seja: nossos clientes) desejar alterar significativamente o provisionamento / instalação de suas imagens VM. Como uma observação lateral, embora eu entenda completamente - e aceite - este PR encerrado em uma base técnica (por exemplo: se envolve o BPR), é bastante frustrante ter um caso de usuário legítimo carimbado como "inválido". Se não for o seu caso de uso, tudo bem. Mas, por favor, não suponha que ninguém tenha um caso de uso válido para esse recurso.

O Windows não precisa de overlayfs, ele tem redirecionamento de pasta integrado e perfis de roaming.

O redirecionamento de pastas, embora exista desde o NT, nem sempre funciona de forma confiável, pois existe um software que (por motivos obscuros) não controla as pastas redirecionadas corretamente e simplesmente falha quando confrontado com uma área de trabalho ou documentos redirecionados. Além disso, os clones das instalações do Windows divergem, por si só, maciça e rapidamente da origem, cortesia do Windows Update - ter diferentes usuários fazendo logon e logoff apenas acelera isso.