Saudações à comunidade Habr! Recentemente, escrevi sobre nossa placa de cluster da primeira versão []. E hoje quero contar como trabalhamos na versão de memória RAM.
Nos apaixonamos por mini servidores que podem ser usados tanto para desenvolvimento local quanto para hospedagem local. Ao contrário de desktops ou laptops, nossos servidores são projetados para operar 24/7, podendo ser rapidamente conectados em uma federação; por exemplo, tínhamos 4 processadores em um cluster, e em apenas 5 minutos passamos a ter 16 processadores (sem equipamentos de rede adicionais), tudo isso em um formato compacto, silencioso e eficiente em termos de energia.
A base da arquitetura de nossos servidores é o princípio de construção em cluster, ou seja, fazemos placas de cluster que conectam vários módulos computacionais (processadores) por meio de uma rede ethernet na placa. Para simplificar, ainda não fabricamos nossos próprios módulos computacionais, mas usamos módulos Raspberry Pi Compute e tínhamos grandes expectativas para o novo módulo CM4. Contudo, tudo saiu do planejado devido ao novo formato, e acredito que muitos estão decepcionados.
Abaixo, conto como passamos de V1 para V2 e como tivemos que nos adaptar ao novo formato do Raspberry Pi CM4.
Então, após a criação de um cluster com 7 nós, a pergunta é: e agora? Como aumentar o valor do produto? 8, 10 ou 16 nós? Quais são os fabricantes dos módulos? Pensando no produto de forma abrangente, percebemos que o principal aqui não é o número de nós ou quem é o fabricante, mas sim a essência dos clusters como bloco de construção. Precisamos encontrar o bloco de construção mínimo que
Primeiro, servirá como cluster e ao mesmo tempo terá a capacidade de conectar discos e placas de expansão. O bloco de cluster deve ser um nó básico autossuficiente, com amplas possibilidades de expansão.
Segundo, para que os blocos de cluster mínimos possam ser conectados entre si, construindo clusters de maior tamanho, e que isso seja eficiente em termos de orçamento e velocidade de escalabilidade. A velocidade de escalabilidade deve ser superior à conexão de computadores comuns em uma rede e muito mais barata do que o equipamento de servidor.
Terceiro, os blocos de cluster mínimos devem ser suficientemente compactos, móveis, eficientes em termos de energia, rentáveis e não exigentes em relação às condições de operação. Esta é uma das principais diferenças em relação aos racks de servidores e tudo que está relacionado a eles.
Começamos definindo a quantidade de nós.
Quantidade de nós
Através de raciocínios lógicos simples, entendemos que 4 nós são a melhor opção para um bloco de cluster mínimo. 1 nó não é um cluster, 2 nós são poucos (1 mestre e 1 trabalhador, sem possibilidade de escalonamento dentro do bloco, especialmente para variantes heterogêneas), 3 nós parecem ok, mas não são múltiplos de 2 e o escalonamento dentro do bloco é limitado, 6 nós saem quase pelo preço de 7 nós (na nossa experiência, isso já é um alto custo de produção), 8 é muito, não cabe no fator de forma mini ITX e é uma solução ainda mais cara para PoC.
Acreditamos que quatro nós por bloco são o meio-termo ideal:
- menos materiais na placa do cluster, portanto, produção mais barata
- multiplicados por 4, um total de 4 blocos oferece 16 processadores físicos
- esquema estável com 1 mestre e 3 trabalhadores
- mais variações heterogêneas, módulos de computação geral + computação acelerada
- fator de forma mini ITX com discos SSD e placas de expansão
Módulos computacionais
A segunda versão é baseada no CM4, pensávamos que seria lançada no fator de forma SODIMM. Mas...
Decidimos criar uma placa filha SODIMM e montar o CM4 diretamente em módulos para que os usuários não se preocupem com o CM4.
Módulo de Computação Turing Pi com suporte para Raspberry Pi CM4
Na verdade, durante a busca pelos módulos, foi aberto um mercado inteiro de módulos de computação, desde pequenos módulos com 128 MB de RAM até 8 GB de RAM. Módulos com 16 GB de RAM e mais estão a caminho. Para hosting de borda de aplicações baseadas em tecnologias cloud native, 1 GB de RAM já é insuficiente, e o recente surgimento de módulos com 2, 4 e até 8 GB de RAM oferece um bom espaço para crescimento. Também consideramos opções com módulos FPGA para aplicações de aprendizado de máquina, mas seu suporte foi adiado devido à falta de uma ecossistema de software desenvolvida. Ao estudar o mercado de módulos, chegamos à ideia de criar uma interface universal para módulos e na V2 começamos a unificação da interface dos módulos de computação. Isso permitirá que os proprietários da versão V2 conectem módulos de outros fabricantes e os misturem para tarefas específicas.
A V2 suporta toda a linha de Módulos de Computação Raspberry Pi 4 (CM4), incluindo versões Lite e módulos com 8 GB de RAM
Periferia
Após determinar o fornecedor dos módulos e o número de nós, chegamos ao barramento PCI, onde se encontram os dispositivos periféricos. O barramento PCI é um padrão para dispositivos periféricos e está presente na maioria dos módulos de computação. Temos vários nós e, idealmente, cada nó deveria poder compartilhar dispositivos PCI em modo de requisições concorrentes. Por exemplo, se for um disco conectado ao barramento, ele estará disponível para todos os nós. Começamos a procurar switches PCI com suporte a multi-host e descobrimos que nenhum deles atendia aos nossos requisitos. Todas essas soluções eram, na maioria, limitadas a 1 host ou a múltiplos hosts, mas sem o modo de requisições concorrentes para os endpoints. O segundo problema era o alto custo, a partir de $50 ou mais por chip. No V2, decidimos adiar os experimentos com switches PCI (retornaremos a eles mais tarde, à medida que evoluirmos) e optamos por designar um papel para cada nó: os primeiros dois nós expuseram uma porta mini PCI express por nó, o terceiro nó expôs 2 portas de um controlador SATA de 6 Gbps. Para acessar os discos de outros nós, pode-se utilizar um sistema de arquivos em rede dentro do cluster. Por que não?
Sneakpeek
Decidimos compartilhar alguns esboços de como o bloco cluster mínimo evoluiu ao longo do tempo durante discussões e reflexões.
Como resultado, chegamos a um bloco cluster com 4 nós de 260 pinos, 2 portas mini PCIe (Gen 2) e 2 portas SATA (Gen 3). Na placa, um Switch Gerenciado de Camada 2 com suporte a VLAN está instalado. Da primeira nódulo, uma porta mini PCIe é disponibilizada, na qual pode-se instalar uma placa de rede para obter mais uma porta Ethernet ou um modem 5G, transformando a primeira nódulo em um roteador para a rede no cluster e portas Ethernet.
O barramento cluster tem mais funcionalidades, incluindo a capacidade de atualizar módulos diretamente por todas as slots e, claro, conectores de ventilador em cada nódulo com controle de velocidade.
Aplicação
Infraestrutura Edge para aplicações e serviços auto-hospedados
Projetamos o V2 com o objetivo de utilizá-lo como um bloco de construção mínimo para infraestrutura edge de grau consumer/comercial. Com o V2, é barato iniciar uma prova de conceito e escalar à medida que cresce, transferindo gradualmente aplicações que são economicamente e praticamente mais viáveis de hospedar no edge. Os blocos cluster podem ser conectados entre si, formando clusters de maior tamanho. Isso pode ser feito gradualmente, sem riscos significativos para o que já está estabelecido.
processos. Hoje já existe uma enorme quantidade de aplicativos para negócios, .
ARM Workstation
Com até 32 GB de RAM por cluster, a primeira node pode ser usada para a versão desktop do SO (como o Ubuntu Desktop 20.04 LTS) e as 3 nodes restantes para tarefas de compilação, teste e depuração, desenvolvimento de soluções cloud native para clusters ARM. Como um nó para CI/CD na infraestrutura periférica ARM em produção.
O cluster Turing V2 com módulos CM4 é arquitetonicamente quase idêntico (a diferença está nas versões menores do ARMv8) ao cluster baseado em instâncias AWS Graviton. O processador dos módulos CM4 utiliza a arquitetura ARMv8, você pode criar imagens e aplicativos para as instâncias Graviton 1 e 2 da AWS, que como se sabe, são muito mais baratas do que as instâncias x86.
Fonte: habr.com
