Sistema de arquivos Linux para um grande servidor de arquivos

Gostaria de saber, de pessoas mais experientes, qual seria a melhor escolha de sistema de arquivos para um servidor de arquivos com mais de 20 TB de discos rígidos. Pessoalmente, sempre usei EXT3 (antigamente) e EXT4 (desde que disponíveis) [e uma vez o ReiserFS 3, apesar de causar muita corrupção de dados] em meus computadores pessoais e nos discos "pequenos servidores" BOOT e ROOT.

No entanto, como as ferramentas EXT4 (embora não a própria EXT4) estejam limitadas a partições de 16 TB, essa pode não ser a minha melhor aposta. A distribuição será Debian 6.0 (Squeeze) e / ou Gentoo (versão mais recente), portanto o kernel deve ser bem recente (no Debian pelo menos com backports), significando o kernel do linux> = 2.6.32.

O servidor de arquivos será usado para três propósitos principais (e também partições separadas, porque o objetivo é manter os dados "seguros" e realmente não se preocupam muito com a sobrecarga). Todos os discos devem ser criptografados usando LUKS :

1. Mídia, downloads e repositório debian local [Eu tenho pelo menos 6 máquinas executando o Debian]> 20 TB (talvez uma separação adicional entre Mídia, Downloads e repositório Debian)
2. Dados (documentos, fotos, ...) ~ 4 TB SAFE (ou seja, disco de backup raid1 ou raid6 +)
3. Backups> = 20 TB para backups de outros computadores na minha LAN de gigabit (você pode sugerir um software que faça backup de todo o sistema operacional, mesmo que seja Windows, o BackupPC diz que faz isso, alguma alternativa?)

Velocidades rápidas não são realmente necessárias (acessos simultâneos: máximo de 2 ou 3 arquivos grandes, digamos vídeos), mesmo que sejam "apenas" 200 MB / s de leituras de um 10 HDD Raid6 que eu possa viver com isso.

Em resumo, procuro um sistema de arquivos confiável e escalonável (ou seja, facilmente expansível) que suporte mais de 20 TB / partição. Quanto mais seguro e confiável for o FS, melhor. O hardware empregado será de pelo menos um quad core (amd x4 630 ou intel i5-2500k) e muita RAM (> 8 GB, talvez> 16 GB), para que os requisitos de hardware sejam atendidos.

Meus PCs / servidores serão conectados a um no-break (fonte de alimentação ininterrupta) em caso de falta de energia Pode também fazer mídia e backups em máquinas separadas (ou seja, dois servidores).

Muitas pessoas estão sugerindo o ZFS. Mas o ZFS não está disponível nativamente no Linux, exceto através do fusível. Eu não recomendaria isso para sua situação em que o desempenho provavelmente é importante.

Infelizmente, o ZFS nunca estará disponível como um módulo nativo do kernel, a menos que os problemas de licenciamento sejam resolvidos de alguma forma.

O XFS é bom, mas algumas pessoas relataram problemas de corrupção e não posso comentar sobre isso. Eu brinquei com pequenas partições XFS e não tive esses problemas, mas não em produção.

O ZFS possui muitas vantagens e recursos úteis que não podem ser ignorados. Em resumo, eles são (consulte a Wiki do ZFS para obter uma descrição completa do que eles significam):

• Integridade de dados
• Pools de armazenamento
• L2ARC
• Alta capacidade
• Copiar na gravação
• Instantâneos e clones
• Striping dinâmico
• Tamanhos de bloco variáveis
• Criação de sistema de arquivos leve
• Gerenciamento de cache
• Endianness adaptável
• Desduplicação
• Criptografia

Então, como podemos contornar isso? Minha alternativa sugerida, que pode se adequar à sua situação, é considerar nexenta . Este é um kernel do Open Solaris com as ferramentas da terra do usuário GNU em execução. Ter um kernel do Open Solaris significa ter o ZFS disponível nativamente.

Você deve tentar o XFS, se encaixar bem nos seus requisitos:

O XFS é um sistema de arquivos de 64 bits. Ele suporta um tamanho máximo do sistema de arquivos de 8 exbibytes menos um byte, embora isso esteja sujeito a limites de bloqueio impostos pelo sistema operacional host. Nos sistemas Linux de 32 bits, isso limita os tamanhos de arquivo e sistema de arquivos a 16 tebibytes.

Sua opção mais fácil é usar o XFS. Muitas das más experiências em torno do XFS são baseadas em versões antigas e problemas de hardware de desktop que não considero realmente relevantes para novas implantações em hardware de servidor de qualidade padrão. Eu escrevi um post sobre este assunto que pode ajudá-lo a resolver a situação atual. Existem várias instalações de banco de dados XFS ocupadas com centenas de usuários e terabytes de dados que eu ajudo a gerenciar. Eles estão todos no kernel do Debian Lenny (2.6.26) ou posterior e eu não ouvi uma dica de problema com eles há anos. Eu não usaria o XFS com nenhum kernel anterior a isso. Eu ouvi alguns relatos diretos de pessoas que ainda veem um comportamento XFS estranho quando o sistema fica sem memória ou espaço em disco; Eu ainda não vi isso ainda.

A única outra opção razoável é usar o ext4 com alguns hackers para oferecer suporte a sistemas de arquivos maiores. Eu não esperaria que isso tivesse um nível de confiabilidade muito diferente. Eu tive que recuperar dados de vários sistemas ext4 quebrados que funcionavam com bugs do kernel, até agora todos corrigidos a montante, mas não no kernel do distribuidor naquele momento. O ext4 tem seu próprio conjunto de problemas de metadados, como perda de dados de alocação atrasada , coisas que eram menos prováveis ​​de acontecer no ext3. Eu estimaria que as chances de você encontrar um bug ext4 seriam ainda mais altas do que o normal se você o forçar acima do limite de tamanho normal, simplesmente porque parece mais provável que você esteja encontrando um novo caminho de código menos testado em algum momento .

A idéia alternativa é usar apenas o ext3 mais seguro e chato, aceitar o limite de 16 TB e particionar as coisas melhor para que nenhum sistema de arquivos precise ser tão grande.

Uma extremidade solta relacionada a edições do diário. Você não falou sobre como todas essas unidades serão conectadas. Certifique-se de entender a implicação de qualquer cache de gravação que esteja em sua cadeia de armazenamento aqui. Desative-o ou verifique se o sistema de arquivos está liberando o cache. Eu guardei alguns recursos sobre isso em Reliable Writes, se isso não é algo que você está verificando ainda.

Drives sugam. Matrizes RAID são péssimas. Os sistemas de arquivos são péssimos. Várias falhas acontecem. Fico feliz em ver que você já está pensando em backups; passar de boa a ótima confiabilidade no armazenamento requer mais do que apenas RAID e algumas unidades sobressalentes. A redundância custa algo em todos os níveis, e o dinheiro para a complexidade de hardware versus software é difícil de navegar. E observe suas expectativas de desempenho. Enquanto uma matriz RAID como a que você está pensando pode facilmente executar centenas de MB / s, basta dois leitores simultâneos que procuram o disco constantemente para reduzir esse número para apenas alguns MB / s. Posso facilmente esmagar uma matriz RAID10 de 24 discos, de forma que ela ofereça apenas <5MB / s contra uma carga de trabalho de referência . Uma coisa que ajuda é garantir que você ajude o readahead para cima, se vários leitores de streaming forem possíveis.

A implantação no ZFS usando o FreeBSD pode acontecer aqui usando o gbde para criptografia. O próprio ZFS seria o provedor de RAID de software, via RAIDZ . A complexidade do gerenciamento de armazenamento da construção de zpools não é significativamente diferente do que o Linux fará com o mdadm e, em alguns casos, será realmente mais fácil. Minha primeira instalação do ZFS (no Solaris 10 há cerca de 3 anos) tinha um sistema de arquivos de 17 TB em 48 unidades. Eu sobrevivi a várias falhas sem problemas, aprendendo o gerenciamento do ZFS à medida que avançava.

A principal vantagem é que a soma de verificação do ZFS fornece melhor detecção de erros do que o Linux, o que é uma defesa contra hardware ruim que vale a pena considerar. As principais desvantagens são que o FreeBSD é menos popular. Você ainda não sabe como administrá-lo, o suporte a hardware é um pouco mais fraco que o Linux e, como é uma plataforma menos popular, não há tantas pessoas para pedir ajuda se você encontrar problemas.

Uma matriz de armazenamento de muitos terabytes realmente destaca no que o ZFS é bom. Vale a pena considerar seriamente se você estiver disposto a mergulhar em algo novo. Se você quiser explorar a verdadeira paranóia de backup, construa servidores de backup Linux e FreeBSD, para reduzir as chances de erros do SO como um único ponto de causa de falha.

De acordo com a página de comparação de sistemas de arquivos da wikipedia , existem muitos sistemas de arquivos notáveis ​​que atendem às suas necessidades, como JFS, XFS, UDF, ZFS, GPFS e Btrfs. Basta clicar no tamanho máximo do arquivo para classificar e selecionar o mais apropriado