Teremos uma máquina trabalhando, que em desempenho máximo, deve ser capaz de enviar 50 ("cabeças de gravação") x 75 GB de dados por hora. Esse é o desempenho máximo de ~ 1100 MB/s de velocidade de gravação. Para obter isso da máquina, são necessárias duas linhas de 10 GBi. Minha pergunta é que tipo de servidor + tecnologia pode manipular/armazenar esse fluxo de dados?
Atualmente, para armazenamento de dados, trabalhamos com ZFS, embora as velocidades de gravação nunca tenham sido uma questão. (não estamos nem perto dessas velocidades) O ZFS (zfs no linux) seria uma opção? Também precisamos armazenar muitos dados, o "Guia de TI" sugere algo entre 50-75 TB no total. Portanto, provavelmente não podem ser todos os SSDs, a menos que queiramos oferecer nosso filho primogênito.
Algumas adições com base nas excelentes respostas:
- o máximo é 50x75GB/hora durante o pico, que é inferior a 24h (provavelmente <6h)
- Não esperamos que isso aconteça em breve, provavelmente rodaremos 5-10x75GB/hora
- é uma máquina pré-alfa, no entanto, os requisitos devem ser atendidos (mesmo que muitos pontos de interrogação estejam em jogo)
- usaríamos NFS como conexão da máquina para o servidor
- layout: máquina geradora -> armazenamento (este) -> (safe raid 6) -> cluster de computação
- portanto, a velocidade de leitura não é essencial , mas seria bom usá-la no cluster de computação (mas isso é totalmente opcional)
- provavelmente serão arquivos de dados grandes (não muitos pequenos)
Para uma velocidade de gravação tão extrema, sugiro contra ZFS, BTRFS ou qualquer sistema de arquivos CoW. Eu usaria o XFS, que é extremamente eficiente em transferências grandes/de streaming.
Há muitas informações ausentes (como você planeja acessar esses dados? A velocidade de leitura é importante? Você vai escrever em grandes blocos? etc.) para fornecer conselhos específicos, no entanto, alguns conselhos gerais são:
Absolutamente... O ZFS no Linux é uma possibilidade se arquitetado corretamente. Existem muitos casos de design ruim do ZFS , mas bem feito, seus requisitos podem ser atendidos.
Portanto, o principal determinante será como você está se conectando a este sistema de armazenamento de dados. É NFS? CIFS? Como os clientes estão se conectando ao armazenamento? Ou o processamento, etc. é feito no sistema de armazenamento?
Preencha mais alguns detalhes e veremos se podemos ajudar.
Por exemplo, se for NFS e com montagens síncronas, é definitivamente possível dimensionar o ZFS no Linux para atender às necessidades de desempenho de gravação e ainda manter o requisito de capacidade de armazenamento de longo prazo. Os dados são compressíveis? Como cada cliente está conectado? Gigabit Ethernet?
Editar:
Ok, eu vou morder:
Aqui está uma especificação que custa aproximadamente $ 17k- $ 23k e cabe em um espaço de rack 2U.
Essa configuração forneceria a você 80 TB de espaço utilizável usando hardware RAID6 ou ZFS RAIDZ2.
Como o foco é o desempenho baseado em NFS (assumindo gravações síncronas), podemos absorver tudo isso facilmente com as unidades P3608 NVMe (SLOG distribuído). Eles podem acomodar 3 GB/s em gravações sequenciais e têm uma classificação de resistência alta o suficiente para lidar continuamente com a carga de trabalho que você descreveu. As unidades podem ser facilmente superprovisionadas para adicionar algumas proteções em um caso de uso SLOG.
Com a carga de trabalho do NFS, as gravações serão combinadas e liberadas para o disco giratório. No Linux, ajustaríamos isso para liberar a cada 15 a 30 segundos. Os discos giratórios podem lidar com isso e podem se beneficiar ainda mais se esses dados forem compressíveis.
O servidor pode ser expandido com mais 4 slots PCIe abertos e uma porta adicional para adaptadores FLR 10GbE de porta dupla. Então você tem flexibilidade de rede.
A Ethernet de 25 Gbps já está no limite do mainstream, enquanto o NVMe baseado em PCIe absorverá esse tráfego facilmente.
Para referência, criei recentemente uma pequena solução de 'captura de log' usando quatro servidores dual-xeon regulares (HPE DL380 Gen9s neste caso), cada um com 6 unidades NVMe, usei IP sobre Infiniband, mas esses NICs de 25/40 Gbps seriam os mesmos e estamos capturando até 8 GBps por servidor - funciona muito bem.
Basicamente, não é barato, mas é muito viável hoje em dia.
Não parece grande coisa. Nosso fornecedor de hardware local tem isso como um produto padrão - aparentemente, ele pode atingir 1400 MB/s sustentado no modo de gravação CCTV, o que deve ser mais difícil do que seus requisitos de pico.
(O link é a configuração padrão de 12 GB, mas eles observam que 20x4 TB também é uma opção. Nenhuma experiência pessoal com este modelo de servidor específico.)
Gravações sequenciais a 1100 MB/s não são um problema com hardware moderno. Curiosamente, minha configuração doméstica com unidades de laptop de 8x5900 RPM, unidades de 2x15000 RPM e unidades de 2x7200 RPM sustenta 300 MB/s com uma carga única de 16 GB.
A rede é 10GbE com cabos de fibra, 9000 MTU em ethernet, e a camada de aplicação é Samba 3.0. O armazenamento é configurado em raid50 com três distribuições em três volumes raid5 de 4 unidades. O controlador é LSI MegaRAID SAS 9271-8i com até 6 Gb/s por porta (tenho um multiplicador de porta adicional e mais lento).
Fale com qualquer administrador de sistema experiente e ele poderá dizer exatamente quais controladores e unidades atenderiam aos seus requisitos.
Acho que você pode tentar com qualquer controlador de 12 Gb/s e configurar duas faixas espelhadas de oito unidades de 7200 RPM cada (quase qualquer unidade deve servir). Inicie 3-4 conexões TCP para saturar o link e se um único par de placas de 10 GbE não puder lidar com isso, use quatro placas.
Algo como uma tangente, mas considere usar InfiniBand em vez de links duplos de 10 GbE. Você pode obter placas Infiniband de 56 Gbps muito baratas, ou placas de 100 Gbps por não muito mais, e no Linux é fácil usar NFS com RDMA sobre IB, o que lhe dará latência extremamente baixa e taxa de transferência de velocidade de linha quase teórica (se seu armazenamento subjacente puder lidar com isso). Você não precisa de um switch, apenas duas placas InfiniBand e um cabo de conexão direta (ou um cabo de fibra InfiniBand se precisar de distâncias maiores).
Uma placa Mellanox de 56 Gbps de porta única (8x PCIe 3.0) como o MCB191A-FCAT custa menos de 700 dólares, e um cabo de conexão direta de cobre de 2 metros custa cerca de 80 dólares.
O desempenho geralmente vai explodir 10GbE fora da água em todos os casos de uso. Não há desvantagens, a menos que você precise acessar o servidor de vários clientes diferentes que nem todos podem usar o InfiniBand (e mesmo assim, os switches da Mellanox podem conectar 10GbE e 40GbE ao IB, mas isso é um pouco mais de investimento, é claro).
Fazer isso com o ZFS é possível, no entanto, considere usar o FreeBSD, pois o FreeBSD tem a pilha de rede mais rápida. Isso permitiria possivelmente 100 GBit em uma única máquina.
1100 MBps parece muito, mas você pode conseguir isso de forma realista usando apenas discos rígidos comuns. Você diz que precisa de 75 TB de espaço, para poder usar discos rígidos de 24 8 TB em espelhos. Isso daria a você 12x a velocidade de gravação de uma única unidade e 24x a velocidade de leitura da unidade. Como essas unidades têm mais velocidade de gravação do que 100 MBps, isso deve ser capaz de lidar facilmente com a largura de banda. Certifique-se de não obter unidades SMR, pois elas têm velocidades de gravação extremamente lentas.
O ZFS cria somas de verificação para cada bloco. Isso é implementado em um único thread. Como tal, você deve ter uma CPU com uma taxa de clock razoavelmente rápida para não bloquear.
No entanto, os detalhes exatos da implementação dependem enormemente dos detalhes.
Atrelamos um NIC 10G despejando dados para um cluster Gluster em seu cliente de fusível. Demora um pouco de ajuste que você não acreditaria no desempenho que pode alcançar desde 3.0.