Como posso construir um servidor de arquivos que possamos incrementalmente crescer no Linux?

2

Eu trabalho em um laboratório científico com um orçamento limitado e uma necessidade crescente de armazenamento. Um ano atrás nós precisávamos de ~ 2-3 TB de armazenamento, hoje precisamos de 13+ TB que preencha o nosso servidor atual (linux, raid 6 com 9 drives), e ele continuará crescendo. Os arquivos são enormes - 50 GB + cada.

Eu quero construir um servidor que:

a) Pode lidar com tamanhos de disco desiguais, para que possamos substituir unidades mais antigas por unidades maiores à medida que elas se tornam disponíveis no mercado. b) Pode lidar com adições de discos (que são potencialmente maiores que qualquer outro disco) após a criação do "volume" inicial. Idealmente, eu só quero colocar uma unidade em um hotswap bay e torná-lo parte do volume. b) Tem redundância e pode lidar com várias falhas de disco. d) Rápido 'fscking'. A última vez que nosso servidor atual fez isso demorou uma eternidade para voltar.

Posso fazer (a) e (b) com o RAID? Eu sei que posso particionar partições raid de tamanhos iguais a partir de discos de tamanho irregular, mas eu não quero entrar no negócio de microgerenciar partições com múltiplos arrays de raid. O ZFS é uma opção? (O FreeBSD também seria aceitável.)

O desempenho, honestamente, não é um grande problema. Ele só armazenará e servirá conteúdo estático para um punhado de pesquisadores. Nossa LAN é de 1Gbit e nossa WAN é de apenas 100Mbit.

Todas e quaisquer sugestões são bem-vindas.

    
por user1481 13.07.2012 / 04:07

4 respostas

6

Eu recomendaria soluções baseadas em ZFS, mas executando um sistema operacional específico ( NexentaStor ), em vez de tentar executar aplicativos adicionais em o sistema. Isso proporciona a flexibilidade de tratar seu armazenamento como um appliance e elimina as dependências do aplicativo. Exportar para seus sistemas Linux via NFS ou iSCSI.

O restante de seus requisitos está bem coberto pelas soluções ZFS. Você tem um orçamento estabelecido?

Eu recomendo ir com um integrador / parceiro que possa ajudar a projetar um sistema robusto e aliviar qualquer problema de escala / longevidade. É provável que eles tenham visto uma situação como a sua ou tenham lidado com requisitos semelhantes. No entanto, se você for por conta própria, faça sua due diligence e evite os erros que outras pessoas cometeram.

Bons lugares para começar:

link

link

link

    
por 13.07.2012 / 04:17
4

Divorcia suas necessidades de armazenamento de suas necessidades de processamento. Você pode comprar um san por preços relativamente baixos (os HP P2000 são baratos se você não os comprar totalmente preenchidos e você pode expandi-los até 6 prateleiras de discos de 3 TB, para 36x6 TB de armazenamento RAW), e se você ficar com iSCSI você pode evitar HBAs e fibras caras. O iSCSI também permite que você continue utilizando o servidor que você está usando atualmente como servidor de arquivos, ele permite que você conecte vários discos. Você também pode ver modelos mais antigos, como o MSA 2000. A Dell também tem algumas ofertas que são decentes. Em seguida, conecte-o ao seu servidor com alguns discos iniciais (2 para o ataque 1, 3 para o ataque 5 ou ataque 1e, 4 para o ataque 1 + 0 ou ataque 6, dependendo dos seus requisitos de armazenamento).

No servidor, use o LVM para extrair um volume físico deles e crie um grupo de volume / volume lógico em cima disso. No futuro, você pode adicionar discos adicionais ao chassi SAN e adicioná-los como novos volumes físicos e, em seguida, expandir o volume lógico. Então, quando você maximizar a capacidade da prateleira de disco da sua SAN, basta adicionar outra prateleira com alguns discos e crescer da mesma maneira que a primeira prateleira. Usamos isso para muitos dos nossos sistemas de armazenamento. Algum planejamento cuidadoso pode ajudá-lo a não ter dados para o mesmo volume lógico hospedado em duas prateleiras diferentes (caso algum idjit decida que deseja tropeçar em um cabo que conecta as duas prateleiras san).

Para o sistema de arquivos, ext3, ZFS, ext4, todos suportam o aumento do tamanho do sistema de arquivos em tempo real. No entanto, se você estiver sempre preocupado, precisará encolhê-lo, inclinar-se para o ext3. É melhor documentado e suportado. Essa solução é simples, não requer um consultor e permite que você aumente sua solução com seu conjunto de dados.

Você realmente deseja remover o Armazenamento do seu servidor, embora precise expandi-lo muito.

    
por 13.07.2012 / 04:20
1

Acho que o ewwhite está bem aqui, para algo que eu gostaria de ter com esse aparelho grande e dedicado com suporte comercial.

Caso contrário, você poderia colocar algo junto com o Linux usando md para adicionar pares de unidades espelhadas (as unidades do par teriam que ser do mesmo tamanho que as outras, mas poderiam ter tamanhos diferentes das unidades antigas), usando LVM para incorporar esse novo par em seu sistema de arquivos migrando volumes lógicos de volumes físicos antigos e / ou aumentando-os para o novo volume físico. A redundância seria um problema (você poderia perder metade das unidades, mas somente se elas forem a metade correta ), mas você teria muito mais flexibilidade na adição de novas unidades e na remoção de unidades antigas.

... apenas certifique-se de ter backups.

    
por 13.07.2012 / 04:46
0

Uma coisa a considerar é que o ZFS não suporta a remoção de vdevs. Isso significa que, se você expandir seu array sem saber, ou se decidir mudar de, por exemplo, RAID6 para RAID10, estará sem sorte. Contanto que seu layout de disco seja fixo e você esteja atualizando cada disco em um vdev (por exemplo, ambos os discos em um espelho), eu concordo que o ZFS é provavelmente uma boa solução.

O BTRFS suporta a remoção de dispositivos, pelo seu equivalente de RAID10. Ele ficou muito mais estável nos últimos anos também.

Se você estiver disposto a considerar o Windows, o Windows Espaços de armazenamento é, na verdade, uma boa solução para a necessidade de lançar um monte de discos heterogêneos em um servidor com redundância e para que eles funcionem bem.

    
por 13.05.2014 / 08:13