150 TB e crescendo, mas como crescer?

Meu grupo atualmente possui dois servidores de armazenamento largish, ambos executando o Linux Debian. O primeiro é um servidor multifuncional de 24 discos (SATA) com vários anos de idade. Temos dois RAIDS de hardware configurados com o LVM sobre eles. O segundo servidor é de 64 discos divididos em quatro gabinetes, cada um RAID 6 de hardware, conectado via SAS externo. Usamos o XFS com LVM para criar um armazenamento utilizável de 100 TB. Tudo isso funciona muito bem, mas estamos superando esses sistemas. Tendo construído dois desses servidores e ainda crescendo, queremos criar algo que nos permita mais flexibilidade em termos de crescimento futuro, opções de backup que se comportem melhor em falha de disco (verificar o sistema de arquivos maior pode levar um dia ou mais) e aguentar em um ambiente altamente concorrente (pense em pequenos agrupamentos de computadores). Não temos suporte à administração do sistema,

Portanto, o que buscamos é uma solução de armazenamento de desempenho aceitável e de custo relativamente baixo que permita crescimento futuro e configuração flexível (pense no ZFS com conjuntos diferentes com características operacionais diferentes). Provavelmente estamos fora do reino de um único NAS. Temos pensado em uma combinação de ZFS (no openindiana, por exemplo) ou btrfs por servidor com glusterfs rodando em cima disso se fizermos sozinhos. O que estamos avaliando é simplesmente morder a bala e investir em soluções de armazenamento Isilon ou 3Par.

Todas as sugestões ou experiências são apreciadas.

Espero que isso ajude um pouco. Eu tentei não deixar isso se transformar em uma parede cheia de texto. :)

3Par / Isilon

Se você pode e dedica uma quantidade fixa de horas-homem para alguém que assume a função de administrador da SAN e deseja desfrutar de uma vida indolor com sono noturno, em vez de trabalho noturno, é esse o caminho que devo seguir.

Uma SAN permite que você faça tudo o que um único "armazenamento" o limitaria (por exemplo, conectar um array flash purestorage e um grande monstro sata de 3par ao mesmo servidor), mas você também precisará pagar por isso e mantê-lo bem conservado. o tempo, se você quiser fazer uso da flexibilidade.

Alternativas

Amplidata

Prós: Dimensionar, barato, projetado com um bom conceito e camadas de cache de leitura / gravação dedicadas. Isso pode realmente ser a melhor coisa para você.

RisingTideOS

O software-alvo deles é usado em quase todos os armazenamentos Linux agora e está permitindo um gerenciamento um pouco melhor do que o simples material linux / gluster poderia. (Imho) A versão comercial pode valer uma olhada.

Gluster / btrfs

PRO: as escalas dimensionadas e os "tijolos" oferecem uma camada de abstração muito boa para o gerenciamento.

CON: O primeiro foi um total PITA para mim. Não era robusto e as falhas podiam ser locais para um tijolo ou remover tudo. Agora, com o RedHat no controle, ele pode realmente se transformar em algo funcionando e eu até conheci pessoas que podem domá-lo para que funcione por anos. E o segundo ainda é semi-experimental. Normalmente, um FS precisa de 3 a 4 anos depois de "pronto" até que seja comprovado e robusto. Se você se importa com os dados, por que você considera isso? Falando em experimental, o suporte comercial da Ceph está quase esgotado agora, mas você precisa se ater à camada "RBD", o FS ainda não está suficientemente testado. Eu quero deixar claro que o Ceph é muito mais atraente a longo prazo. :)

ZFS

Pro: Recursos que definitivamente colocam uma unha no caixão de outras coisas. Esses recursos são bem projetados (pense em L2ARC) e a compactação / desduplicação é divertida. Ter mais "clusters de armazenamento", o que significa ter apenas pequenas falhas em vez de um grande boom consolidado

Contras: Manter muitas pequenas caixas de software em vez de um armazenamento real. É necessário integrá-los e gastar horas $$$ para ter uma configuração robusta.

A rota XFS + LVM é realmente uma das melhores opções para uma solução de armazenamento Linux puro expandida nos últimos anos. Estou encorajado que você já está lá. Agora que você precisa crescer mais, você tem mais algumas opções disponíveis.

Como você sabe, os grandes fornecedores de hardware por aí têm cabeças NAS para armazenamento. Isso realmente daria a você um único fornecedor para trabalhar para que tudo acontecesse e funcionaria muito bem. São soluções fáceis de entrar (em comparação com os bricolage) e sua capacidade de manutenção é menor. Mas, eles custam bastante. Por um lado, você terá mais recursos de engenharia para solucionar seus principais problemas, em vez de problemas de infraestrutura; por outro lado, se você é como a maioria dos departamentos da Universidade, eu sei que a mão-de-obra é realmente barata em relação ao pagamento em dinheiro pelas coisas.

Seguindo a rota de bricolage, você já tem uma boa apreciação das opções de bricolage disponíveis. ZFS / BTRFS é o caminho óbvio de atualização do XFS + LVM para armazenamento em escala reduzida. Eu evitaria o BTRFS até que ele fosse declarado 'estável' no kernel da linha principal do Linux, o que deve ocorrer em breve agora que várias das principais distribuições gratuitas o estão usando como sistema de arquivos padrão. Para o ZFS, eu recomendaria o uso de uma base BSD em vez do OpenIndiana, simplesmente porque já existe há mais tempo e os problemas (mais) foram resolvidos.

O Gluster foi projetado para o caso de uso que você descreve aqui. Ele pode fazer replicação e apresentar um único servidor virtual com muito armazenamento conectado. Seus volumes distribuídos soam exatamente o que você está procurando, pois eles espalham os arquivos por todos os servidores de armazenamento no volume declarado. Você pode continuar adicionando servidores de armazenamento discretos para continuar a expandir o volume visível. Espaço de nome único!

O problema do Gluster é que ele funciona melhor quando seus clientes podem usar o Gluster Client para acessar o sistema em vez das opções CIFS ou NFS. Como você está executando um pequeno cluster de computação em cluster, poderá utilizar o cliente GlusterFS.

Você está no caminho certo aqui.

Tanto quanto eu entendo, você poderia usar uma solução SAN baseada no Linux SCST + FibreChannel ou infiniband, que é algo que estou construindo no momento. Como base para os LUNs, você pode usar o LVM em cima dos RAIDs de hardware e cuidar de instantâneos / replicação (considere o DRBD como exemplo) abaixo do nível do sistema de arquivos. Como um sistema de arquivos, não conheço nenhuma boa solução para simultaneidade, pois estou colocando o ESXi no topo dos nós; portanto, os datastores são gerenciados pelo FS simultâneo do ESX. Acho que o GFS2 pode funcionar com esse ambiente, mas não tenho 100% de certeza, pois você deve verificar seus requisitos precisos. De qualquer forma, uma vez que você tenha uma SAN robusta sob seus nós, é muito fácil fazer as coisas.