Servidor JBOD para ZFS sem unidade de inicialização dedicada

Question

Estou pensando em comprar uma máquina econômica para usar openAttic , que é simplesmente Ubuntu 14.04 64bit com o ZFS.

O servidor que estou vendo me dá 8 compartimentos de 3.5 ", onde eu planejo colocar HDDs de classe empresarial SAS 7.2k, provavelmente 3Tb ou 4Tb. Estou apontando para 18Tb a 24Tb de espaço utilizável, com 2 HDDs para redundância.Eu vou ter 32Gb de ECC RAM, pelo menos, mas vou olhar para o custo de 64Gb.

Não tenho experiência suficiente com o ZFS, mas inicialmente meu plano era usar uma pequena partição de inicialização e de sistema, espelhada em todas as unidades, usando o ext4. Em seguida, usando o espaço restante para o ZFS.

O servidor tem um slot M.2: devo obter um SSD M.2 para usar como unidade de inicialização / sistema? O OpenATTIC precisa de muito pouco para a partição do sistema, então parece um desperdício obter um SSD premium para isso, quando a RAM e as unidades SAS estarão fazendo a maior parte do trabalho e serão o gargalo.

Eu li que o ZFS gosta de obter acesso direto aos discos, então me pergunto: O ZFS pode funcionar bem quando você o configura para não usar todo o disco? Ou devo obter o SSD e deixar o ZFS usar todos os discos SAS?

Se o dinheiro não é uma limitação, é claro que recebo o SSD, mas estou procurando o "melhor custo-benefício". Obrigado!

    

Answer 1

Para algo dessa escala, use uma unidade separada ou um par de unidades para o sistema operacional. Talvez o slot M.2 SSD seja o mais adequado.

Conceda ao ZFS os discos completos e não tente distribuir o sistema operacional pelas unidades.

Para a escala doméstica, não ouça todas as sugestões para obter um ZIL e L2ARC. O ZIL é útil somente para gravações síncronas, e o L2ARC é superestimado. Você tem uma boa contagem de RAM e é isso que deve maximizar.

    

Answer 2

Você tem várias opções:

• Barramento USB 2.0 barato: não recomendado porque eles são lentos e as gravações matarão a maioria rapidamente, exceção: um sistema somente leitura como o SmartOS (para ZFS) ou o ESXi (sem ZFS, apenas como um exemplo) que só grava no arranque ou uma vez por hora e mantém tudo na RAM ou nos seus conjuntos de dados.
• USB 3.0 stick mais caro com memória SLC ou USB 3.0 HDD: Embora não seja oficialmente suportado na maioria dos sistemas, funciona muito bem. Eu sugeriria o espelhamento dessas unidades, o que também permite atualizações e backups contínuos facilmente.
• Disco / SSD SATA ou M.2: pode desperdiçar espaço valioso, mais caro, mas livre de problemas. Eu sugeriria um par espelhado se você puder pagar. Melhor solução para a maioria dos casos em que espaço e dinheiro não são as restrições mais importantes. A melhor escolha seria a proteção total contra perda de energia (como o Intel 730 e todas as versões S3xxx / DC3xxx).
• Montagem NFS / iSCSI: interessante se você tiver várias caixas sem espaço / portas e quiser ter gerenciamento / configuração central. Inicialize via PXE, mapeie as unidades de rede e use-as. Quase todas as NICs de servidor suportam isso, mas você precisa de um servidor separado para fornecer os serviços.

Minha sugestão pessoal:

• Se você tiver apenas uma configuração de arquivador normal e quiser saturar 1Gbps: use dois dispositivos USB SLC como os modelos MX-ES (externos) ou dois pequenos SSDs SATA Intel (internos)
• Se você tem uma configuração maior, deseja alto desempenho, troca rápida de discos com falha, talvez tenha virtualização ou solicitações de alta disponibilidade: use seus gabinetes normais com 2 SSDs Intel com proteção contra perda de energia
• Se você tiver / aumentar uma grande quantidade de máquinas e quiser economizar tempo / dinheiro: considere o SmartOS (criado para este caso de uso) ou use a inicialização pela rede via PXE

I have read that ZFS likes to get direct access to the disks, so I wonder: Can ZFS can work well when you configure it to not use the whole disk? Or should I get the SSD and let ZFS take all the SAS disks?

É recomendado para usar discos inteiros em sua piscina:

For production systems, use whole disks rather than slices for storage pools for the following reasons:

• Allows ZFS to enable the disk's write cache for those disks that have write caches. If you are using a RAID array with a non-volatile write cache, then this is less of an issue and slices as vdevs should still gain the benefit of the array's write cache.
• For JBOD attached storage, having an enabled disk cache, allows some synchronous writes to be issued as multiple disk writes followed by a single cache flush allowing the disk controller to optimize I/O scheduling. Separately, for systems that lacks proper support for SATA NCQ or SCSI TCQ, having an enabled write cache allows the host to issue single I/O operation asynchronously from physical I/O.
• The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
• ZFS pools (and underlying disks) that also contain UFS file systems on slices cannot be easily migrated to other systems by using zpool import and export features.
• In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.