Aproveite ao máximo o MinIO com configurações de rede ideais – veja como

O MinIO pode ser implantado de maneira distribuída, fazendo uso eficiente dos recursos de computação e armazenamento de mais de uma máquina física ou virtual. Pode ser o MinIO executado em um ambiente de nuvem pública ou privada, como Amazon Web Services, Google Cloud Platform, plataforma Azure da Microsoft e muitos outros. O MinIO pode ser implantado em vários tipos de topologias – em produção, recomendamos a implantação Multi-Node Multi-Drive (MNMD). MinIO recomenda replicação de site para fornecer failover de nível BC/DR e suporte de recuperação para sua implantação de site único, que você pode projetar e otimizar para seu caso de uso.

Em uma postagem anterior do blog, já discutimos algumas das práticas recomendadas a serem usadas ao selecionar hardware para sua implantação do MinIO . Abordamos vários aspectos do hardware, desde a escolha da melhor região, a unidade correta, configurações de CPU e memória e até mesmo algumas das configurações de rede recomendadas. Embora tenhamos abordado diversas práticas recomendadas para design de sistemas, sempre podemos ir mais fundo e hoje nos aprofundaremos em alguns dos pontos delicados do design do MinIO para obter o melhor desempenho de unidades e redes.

Nesta postagem do blog, nos aprofundaremos nas configurações de rede com as quais você pode configurar o MinIO para as diferentes estratégias de replicação e topologias de rede que podem ser usadas para garantir que seus dados sejam armazenados e acessados de forma eficiente em várias implantações do MinIO. Você não precisa fazer nenhuma configuração complexa, como configurar NICs Bonded/Dual (o que adiciona sobrecarga adicional).

Estratégias de rede simples

MinIO é um back-end de armazenamento compatível com S3 para serviços nativos da nuvem. Em geral, pensamos no tráfego de rede entre aplicativos e o cluster ou entre nós no cluster. Devido ao tráfego entre nós, é fundamental que a rede entre os nós seja o mais rápida possível. Cada pool consiste em um grupo independente de nós com seus próprios conjuntos de eliminação. O MinIO deve consultar cada pool para determinar o conjunto de eliminação correto para o qual ele direciona as operações de leitura e gravação, de modo que cada pool adicional adicione tráfego entre nós mínimo, mas aumentado, por chamada. O pool que contém o conjunto de eliminação correto responde à operação, permanecendo totalmente transparente para o aplicativo.

Já se foi o tempo em que as empresas podiam sobreviver com NICs de 1 GbE ou 10 GbE. A carga de trabalho empresarial moderna utiliza idealmente NICs de 100 GbE. Dadas as limitações físicas e a sobrecarga do protocolo TCP, espera-se que essas NICs forneçam 80-90% da largura de banda disponível, geralmente em torno de 10 GB/s para NICs de 100 Gbps, até 12 GB/s em redes realmente bem provisionadas. O MinIO não precisa de nenhuma configuração de rede adicional pronta para uso para aproveitar toda a largura de banda enquanto escuta em todas as interfaces. O MinIO pronto para uso oferece suporte à escuta em várias interfaces de rede (NICs).

Você não precisa de nenhuma outra configuração especial para redes MinIO, mas opcionalmente, usando alguns dos princípios básicos de rede que discutimos anteriormente, você pode rotear o tráfego MinIO por meio de uma interface específica.

Neste exemplo, usaremos um sistema operacional Linux para demonstrar, mas os princípios básicos de rede são os mesmos, independentemente do sistema operacional usado. A implementação pode variar um pouco dependendo da configuração da rede, mas isso deve lhe dar uma ideia.

Começaremos primeiro listando a tabela de rotas

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

Se você configurou seus servidores MinIO para estarem dentro do intervalo CIDR 10.56.98.16/28, digamos que um dos endereços IP do nó MinIO seja 10.56.98.21 que será roteado através da interface eth0 porque /28 corresponde à entrada da tabela de rotas para 10.56 .98,0/24.

Mas se você quiser rotear o tráfego MinIO através de eth1 em vez de eth0, precisamos adicionar uma rota específica para o CIDR MinIO para que qualquer tráfego que corresponda a essa sub-rede seja roteado através dessa interface de rede específica.

 $ ip route add 10.56.98.16/28 dev eth1

Depois que a rota for adicionada, vamos listar a tabela de roteamento novamente para ver como fica

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

Agora vemos uma rota para o CIDR /28. Se você executar ping no nó MinIO 10.56.98.21, ele agora será roteado por meio da interface eth1. Isso ocorre porque quando há duas rotas onde /24 se sobrepõe a /28, geralmente a rota com o prefixo mais longo tem preferência (neste caso /28) e terá precedência sobre qualquer outra rota com prefixo mais curto ao rotear o tráfego. Isso é chamado de regra de prefixo de correspondência mais longa.

Você pode verificar se o tráfego de 10.56.98.16/28 está sendo roteado adequadamente se você executar ping em 10.56.98.21 e verificar o tcpdump como abaixo. Você notará que o tráfego da origem 10.56.98.18 está sendo roteado via eth1 para 10.56.98.21.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

Como você pode ver com o MinIO, não há portas ou serviços especiais adicionais necessários para obter a separação do tráfego. O MinIO foi projetado com a simplicidade em mente e estamos sempre pensando em construir versus comprar neste caso, em vez de arquitetar algo complexo como um serviço de gateway. O MinIO aproveita os princípios básicos de rede já disponíveis na camada do sistema operacional para obter o mesmo resultado com o mínimo de sobrecarga possível. possível.

Podemos levar esta ideia um passo adiante. Atualmente, os servidores têm pelo menos 2 interfaces com a opção de adicionar mais. Portanto, em vez de fazer com que o tráfego do aplicativo passe pelas mesmas interfaces do MinIO, você pode fazer com que seu aplicativo também seja executado em um bloco CIDR separado (escolha um bloco apropriado para o tamanho do seu aplicativo). Essa separação garante que o tráfego MinIO para replicação e rebalanceamento não afete o desempenho da aplicação e vice-versa. Ele também oferece a capacidade de monitorar e rastrear o tráfego para garantir que o MinIO sempre tenha a capacidade e a largura de banda necessárias para realizar suas operações sem afetar seu desempenho.

Mas e se você tiver MinIO em diferentes sites ou regiões? Como você pode configurá-lo de forma eficaz para garantir que não haja gargalos de desempenho? Bem, existem vários tipos diferentes de configurações de replicação que o MinIO oferece para alguns dos casos de uso mais rigorosos que existem.

Uma das estratégias de replicação mais prolíficas é a replicação site a site. Isso permite iniciar o MinIO com um único cluster e expandir para um número N conforme a necessidade aumenta. Suponha que você tenha um aplicativo ETL/ELT executado em três sites diferentes. Geralmente, os dados só estão disponíveis numa das regiões e as outras regiões precisam de extrair enormes volumes de dados entre regiões para executar o seu processo. Escusado será dizer que isto não só é altamente ineficiente, como também coloca uma enorme pressão sobre a infra-estrutura de rede e potencialmente causa estrangulamentos para outras aplicações que partilham a WAN.

Em uma configuração de replicação site a site, você grava os dados somente no cluster MinIO no primeiro site. O processo de replicação copiará os dados para outros sites automaticamente. Não há alterações adicionais necessárias na aplicação ETL/ELT. Basta apontar os trabalhos em cada site para seu respectivo cluster MinIO apoiado por um proxy reverso como o Nginx e as leituras serão muito mais rápidas do que seriam na WAN entre regiões, conforme mostrado abaixo.

Mas isso levanta a questão: é possível ajustar ainda mais o tráfego? Digamos que você adicione o arquivo de dados ao site 1 e ele o replicará imediatamente para outros sites, independentemente da hora do dia. Pode ser durante o pico, quando talvez outros trabalhos de ETL/ELT estejam em execução e, simultaneamente, recursos de rede estejam sendo usados para replicar dados que podem não ser usados até o dia seguinte, quando o próximo lote deverá ser executado. O que pode ser feito nesse caso? É aqui que a replicação em lote do MinIO se torna útil. A replicação em lote permite que você escolha o tipo de dados que deseja replicar em um momento específico, é totalmente configurável. Nesse caso, uma tarefa de replicação em lote pode ser configurada para ser executada fora do horário de expediente, quando o tráfego é menor. Como os tempos de acesso aos aplicativos podem variar ao longo do dia, da semana e até do mês, é aqui que o monitoramento do tráfego de rede do MinIO se torna útil para que você possa configurar seu trabalho em lote para ser executado exatamente no momento certo. Você pode implantar sites peer em diferentes racks, data centers ou regiões geográficas para oferecer suporte a funções como BC/DR ou desempenho de leitura/gravação geolocal em um armazenamento de objetos MinIO distribuído globalmente.

Pensamentos finais

Para recapitular, a arquitetura de rede do MinIO é uma das mais simples e diretas que existem. Em vez de reinventar a roda, o MinIO usa noções básicas de rede para alcançar paridade com alguns dos outros armazenamentos de dados com configuração complexa de rede e gateway que é quase impossível de depurar. Não importa quantas vezes você depure o mesmo problema, parecerá que é a primeira vez que você o encontra devido à natureza ofuscada da arquitetura. Em vez disso, o MinIO concentra-se em abstrações de nível superior que aliviam o desenvolvedor do aplicativo de ter que manter a replicação de dados e se concentram no armazenamento e processamento dos dados.

Como de costume, se você tiver alguma dúvida sobre a configuração da rede MinIO ou como configurá-la, entre em contato conosco no Slack ou, melhor ainda, inscreva-se para a assinatura da SUBNET !