A importância da segmentação de rede para fábricas de IA

Dentro de um cluster de IA, podemos segmentar logicamente os recursos com um contexto de locatário, permitindo cotas de locatário, limites de consumo de recursos, segurança do sistema host e controle de acesso baseado em função de gerenciamento (RBAC). No entanto, os contextos dos locatários não são expostos com os serviços básicos de rede que fornecem entrada e saída de tráfego do cluster de IA com o restante da rede da fábrica de IA. Sem esse contexto, a base da segurança cibernética no data center, a segmentação da rede é cega. Métodos típicos para expor os contextos de locatários necessários roubam significativamente a fábrica de IA de computação de alto valor ou tornam os caminhos de rede lentos abaixo dos limites necessários para latência de serviço, largura de banda ou simultaneidade.  Enfrentamos falsas escolhas entre utilizar eficientemente recursos de fábrica de IA de alto valor e integrar adequadamente os inquilinos à rede.

Em infraestruturas de nuvem pública, projetos de rede multilocatários orquestrados são a base de todos os serviços em uma região de nuvem e são implementados com nuvens privadas virtuais (VPC). Essa segmentação de rede virtualizada é essencial para segurança e medição de recursos. Os provedores de nuvem pública mantêm essa função com equipes de desenvolvedores de software de rede e hardware de rede especializado, incluindo SmartNICs e unidades de processamento de dados (DPUs). Os clusters de fábrica de IA em nuvens públicas são projetados para aproveitar a orquestração da rede VPC da infraestrutura subjacente. O custo para manter VPCs é bastante substancial, mas é essencial para o modelo de negócios de nuvem pública.  

Surge a pergunta: Como uma organização maximiza seu investimento em fábrica de IA e agenda dinamicamente GPUs e computação sem o mesmo nível de investimento de um provedor de nuvem pública?

A primeira parada da indústria nessa jornada foi usar a virtualização de servidores para criar máquinas virtuais (VMs). As VMs utilizam passagem de hardware para se conectar a redes de data centers segmentadas. Basta colocar todas as máquinas virtuais nas mesmas VLANs e continuaremos com as operações normalmente se estivermos preocupados apenas com um único locatário em um único cluster de IA.

As VMs também podem abordar a segmentação de GPU, pois os fornecedores de GPU oferecem suporte a maneiras de subdividir dispositivos de GPU em conjuntos de núcleos e memória e, em seguida, atribuí-los a máquinas virtuais específicas. No entanto, a segmentação de dispositivos GPU não é dinâmica e requer a reinicialização da VM. Além disso, esse design limita a capacidade de criar um pool de recursos de GPU que podem ser medidos em muitos locatários. Essas são desvantagens significativas dessa solução.

O que acontece com nossos clusters de fábricas de IA quando eles não conseguem mais atender a um único inquilino? O problema muda para o data center. Em clusters de fábrica de IA, por padrão, todo o tráfego de rede que sai para o data center tem o endereço de rede de origem traduzido (SNATed) para um endereço IP de nó de cluster individual que a carga de trabalho em contêiner que emite a solicitação de rede está executando, mascarando efetivamente a verdadeira origem. O tráfego é então originado de um segmento de rede no qual esse nó foi implantado. Para um cluster multilocatário, isso significa que perdemos o contexto do locatário e obtemos um fluxo misto de tráfego de saída de vários locatários que é impossível de classificar, proteger, solucionar problemas ou auditar.

As fábricas de IA devem planejar uma solução de rede rica em recursos, programável, segura e de baixa latência, que seja escalável tanto em largura de banda quanto em simultaneidade. Os contextos de locatário na Camada 2 (por exemplo, VLANs, VxLAN) e Camada 3 (por exemplo, sub-redes, interfaces IPSEC) devem ser apresentados de dentro de um cluster para a rede de fábrica de IA. Métricas de observabilidade, logs e ferramentas de depuração devem estar disponíveis para o NetOps.

Tradicionalmente, muitas dessas soluções de visibilidade e locação de application são fornecidas pelo F5 BIG-IP . O F5 BIG-IP Container Ingress Services (CIS) descobre dinamicamente os serviços do Kubernetes e os expõe aos data centers como servidores virtuais, um objeto de configuração com o qual os administradores do BIG-IP estarão familiarizados ao configurá-los para apresentar servidores físicos e máquinas virtuais. Embora o BIG-IP forneça muitos dos requisitos que buscamos em uma solução, ele não gerencia o tráfego de saída do cluster de IA para a rede da fábrica de IA, o que é necessário para manter a segmentação.

Para resolver esse problema, projetamos o F5 BIG-IP Next para Kubernetes , uma solução para clusters de computação multilocatários criada sobre nossa plataforma de última geração BIG-IP Next.

O BIG-IP Next para Kubernetes é completamente gerenciado pelo plano de controle do Kubernetes e oferece suporte à autenticação de gerenciamento do Kubernetes, RBAC para todos os recursos declarados, reconhece a locação do Kubernetes por meio de namespaces para oferecer suporte à segmentação de rede necessária para tráfego de entrada e saída. Isso é essencial para arquiteturas que priorizam a orquestração, como fábricas de IA.

O BIG-IP Next para Kubernetes fornece uma maneira simplificada para o NetOps declarar os mapeamentos entre namespaces do Kubernetes e segmentos de rede. O peering de rota dinâmico entre a rede de fábrica de IA e as instâncias do BIG-IP Next usa uma sintaxe de configuração de rota familiar. As equipes de NetOps têm a capacidade única de solucionar problemas com segurança em fluxos de rede ao vivo para entrada e saída de cluster. As equipes de SecOps ganham listas de controle de acesso (ACLs) de firewall de entrada e saída por locatário do cluster, negação de serviço distribuída (DDoS) e recursos de IPS.

Para as equipes de engenharia de plataforma, o BIG-IP Next para Kubernetes alivia os recursos de computação ao descarregar funções de rede, como processamento de tráfego de entrada e saída de dados, bem como NAT de origem e firewall. Isso ajuda com os custos operacionais, ao mesmo tempo em que mantém os serviços disponíveis e eficientes.

O BIG-IP Next para Kubernetes também oferece suporte à Kubernetes Gateway API, a primeira API de entrada da comunidade modelada para funções organizacionais específicas em NetOps, engenharia de plataforma, DevOps e MLOps. Por meio da API Gateway, o BIG-IP Next para Kubernetes estende serviços de entrada de rota HTTP(S) típicos baseados em porta de Camada 4 ou Camada 7 para um conjunto para DevOps/MLOps, ou seja, TCPRoute, UDPRoute, HTTPRoute, TLSRoute e GRPCRoute, todos controlados pela mesma automação de CI/CD nas principais estruturas de IA.

Do ponto de vista de gerenciamento, o BIG-IP Next para Kubernetes mantém NetOps, SecOps, engenharia de plataforma, DevOps e MLOps trabalhando juntos de forma eficaz por meio de declarações de API do Kubernetes. É tudo o que você espera do BIG-IP, mas pela lente do Kubernetes e com suporte à segmentação de rede.

Unidades de processamento de dados (DPU) ganharam força exponencial dentro das fábricas de IA. Definido em uma postagem anterior do blog em nossa série sobre fábrica de IA , uma DPU é um processador programável projetado para lidar com grandes movimentações e processamentos de dados por meio de aceleração de hardware na taxa de linha de rede. Por meio da inovação de produtos na F5 e da colaboração com a NVIDIA, lançamos o BIG-IP Next para Kubernetes para descarregar fluxos de dados para tráfego de entrada e saída, ao mesmo tempo em que oferecemos suporte à segmentação de rede, bem como funções de segurança por meio da implantação nas DPUs NVIDIA BlueField-3 usando as APIs DOCA da NVIDIA. Isso maximiza o investimento em uma fábrica de IA ao garantir que os clusters de IA sejam “alimentados por dados”.