ZFS iSCSI e capacidade livre no VMFS

Question

Eu uso o ZFS no FreeNAS 8.0.4 e uso o iSCSI para fornecer um LUN ao VMware ESXi 5.0.

Eu postei em link , mas acredito as pessoas aqui podem ter mais conhecimentos sobre o ZFS.

O FreeNAS não tem o iSCSI unmap. Eu criei / movi / deletei a máquina virtual entre o iSCSI do ZFS. Depois de um tempo, zpool list report 95% da capacidade usada. No entanto, o Vmware mostra que o VMFS usa apenas 50% da capacidade.

AFAIK, ao criar uma máquina virtual, zvol alocou espaço em disco. No entanto, quando movemos / excluímos a máquina virtual, o zvol não atualizou / não informou para atualizar a capacidade livre.

[root@data1] ~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
data1 2.25T 2.07T 185G 95% ONLINE /mnt

Agora, acredito que devido à capacidade livre errada informada na zpool list, o desempenho é profundamente afetado.

Como devo fazer para informar ao ZFS a capacidade real gratuita.

Obrigado milhões.

zpool status -v

  pool: data1
 state: ONLINE
 scrub: scrub stopped after 10h31m with 0 errors on Wed Feb  6 13:32:53 2013
config:

        NAME        STATE     READ WRITE CKSUM
        data1       ONLINE       0     0     0
          raidz1    ONLINE       0     0     0
            ada0p2  ONLINE       0     0     0
            ada1p2  ONLINE       0     0     0
            ada2p2  ONLINE       0     0     0
            ada3p2  ONLINE       0     0     0
            ada4p2  ONLINE       0     0     0
        spares
          ada5p2    AVAIL   

errors: No known data errors

lista de zpool

NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
data1  2.25T  2.08T   179G    92%  ONLINE  /mnt

    

Answer 1

Você tornou seu zvol muito grande e sua implementação do ZFS não tem a capacidade de desmapear blocos de liberação!

A melhor maneira de evitar que isso aconteça é desprovisionar os LUNs que você apresenta para o VMware. Como sabemos que o desempenho do ZFS degrada quando o disco está quase cheio, é melhor limitar o tamanho máximo do seu zvol.

por exemplo. se você tiver um armazenamento zpool de 200 GB, verifique se os zvols apresentados para o VMware são menores do que isso - talvez 150 GB.

O ZFS não está ciente do sistema de arquivos que está sendo usado sobre o dispositivo de bloco zvol, então tudo o que está acontecendo no seu volume VMFS é que ele sabe que possui 50% de espaço livre. O ZFS não tem como saber isso. Você não poderá recuperar o espaço sem reformatar / recriar o volume ou expandindo o zvol .

Uma solução melhor no seu caso seria usar o NFS em vez do iSCSI para essa finalidade. Se você não estiver monitorando com cuidado o uso e o crescimento de disco da VM o suficiente para impedir que isso aconteça com o iSCSI, o NFS poderá fazer mais sentido. Eu uso o NFS com minhas configurações de VMware do ZFS +.

Veja também: Ao usar o thin-provisioning com o ZFS, como garantir que você não fique sem espaço físico em disco?

e

Espaço usado incorreto relatado por zVol.

    

Answer 2

Você identificou corretamente a causa - e até mesmo com SCSI UNMAP, provavelmente ainda teria ocorrido, já que a matriz de suporte agora para TRIM e UNMAP é péssima. No entanto, existe uma solução que ninguém mencionou.

Primeiro - ativar a compactação (compress = on ou compress = lzjb, eu não sou um fã de compress = gzip, especialmente para VMs), nada disso funcionará sem isso.

Se você estiver lidando com unidades oferecidas em uma VM (ou como a unidade do SO da VM também) e, em seguida, formatadas com um sistema de arquivos, poderá usar utilitários como "zerofree" para Linux ou "sdelete" para o Windows escrever zeros em todos os blocos livres. Devido a uma peculiaridade em como o ZFS lida com blocos de 0 em sistemas de arquivos compactados, isso irá liberar o espaço no zvol, tornando o zvol muito mais alinhado com a capacidade real usada.

Se você fez o acima e não funcionou (improvável) ou ainda há uma discrepância muito grande (também improvável), mesmo depois de executar isso em todas as unidades em todas as VMs que estão no topo do LUN, você pode tente este artigo - note que eu não testei isso, de jeito nenhum, então não há promessas: link