Transforme a capacidade de GPU em um negócio de Kubernetes gerenciado
Neoclouds que oferecem Kubernetes gerenciado e GPU como serviço precisam que cada locatário esteja isolado na rede, com seu próprio caminho controlado de entrada e saída e a garantia de que nenhum outro locatário possa acessá-lo. A F5 oferece isso e muito mais.
A primeira pergunta dos clientes corporativos é como seus ambientes são isolados
Uma neocloud que vai além da infraestrutura bare metal assume as funções de rede que antes eram implementadas pelos próprios locatários: isolamento entre clientes, controle do tráfego de entrada e saída, proteção por firewall e logs que comprovam tudo isso. Proxies de código aberto e scripts colocam o primeiro cluster em operação, mas cada novo locatário exige uma nova implementação. A F5 fornece essa camada como um componente com suporte da F5 Application Delivery and Security Platform.
Isole os tenants na rede
Domínios de roteamento por tenant com EVPN-VXLAN e VRFs, não apenas namespaces e rótulos.
Controle o que entra e sai
Controle de tráfego de entrada e saída por tenant, com endereços de origem estáveis e um firewall na borda dos nós.
Libere núcleos do host para comercialização
No modo DPU, o número de núcleos utilizados no host caiu de 12 para 2 em testes validados pelo The Tolly Group.
Comece com os servidores que você já tem
Funciona em CPUs padrão do host; adicione DPUs BlueField quando os núcleos do host forem mais valiosos.
Como a F5 ajuda as neoclouds a vender mais do que horas de GPU
Isolamento de locatários
Namespaces e políticas de rede separam os tenants dentro do Kubernetes, mas eles ainda compartilham a rede subjacente, e as equipes de segurança corporativa sabem disso. O BIG-IP Next for Kubernetes associa cada tenant ao seu próprio domínio de roteamento usando BGP EVPN-VXLAN com VRFs, de modo que o tráfego de cada tenant entra e sai do cluster por meio de sua própria VRF. Adicionar um tenant passa a ser uma questão de configuração, em vez de exigir uma nova implantação, e a equipe de plataforma opera uma única camada, em vez de um proxy, um roteador e um firewall por cliente.
Explore soluções de rede para KubernetesPRODUTO
BIG-IP Next for Kubernetes
Isolamento de tenants no nível de rede e políticas por tenant na borda do cluster.
PRODUTO
BIG-IP Next for Kubernetes implantado em DPUs NVIDIA BlueField
Aplicação de políticas de isolamento de tenants na DPU, separada do sistema operacional do host.
Entrada, saída e firewall
Cada tenant precisa de controle sobre o tráfego de entrada e saída. O BIG-IP Next for Kubernetes oferece entrada por tenant por meio da Kubernetes Gateway API, saída com endereços de origem estáveis por tenant que os sistemas externos podem incluir em listas de permissões e um firewall na borda do nó com um fluxo de logs para cada tenant. Por padrão, o tráfego de saída dos pods usa o endereço do nó, o que impede os sistemas externos de distinguir os tenants. Com a F5, os tenants têm os controles que suas equipes de segurança exigem, e o provedor tem evidências para apresentar a elas.
Explore soluções de rede para KubernetesPRODUTO
BIG-IP Next for Kubernetes
Isolamento de tenants no nível de rede e políticas por tenant na borda do cluster.
PRODUTO
NGINX Gateway Fabric
Implementação da Gateway API para o tráfego de aplicações dentro dos clusters de tenants.
Núcleos de host voltam a gerar receita
Em um servidor padrão, as funções de rede, criptografia e aplicação de políticas são executadas em núcleos da CPU do host que nunca são faturados. Quando implantado em DPUs NVIDIA BlueField no modo DPU, o BIG-IP Next for Kubernetes transfere esse caminho de dados para a DPU. Em testes validados pelo The Tolly Group, o número de núcleos do host utilizados caiu de 12 para 2 por servidor, em medições realizadas com um modelo pequeno. Na escala de um rack, essa é uma capacidade que você pode vender em vez de consumir. Comece no host e migre para a DPU quando esses núcleos valerem mais como capacidade disponível para venda.
Leia o relatório da TollyPRODUTO
BIG-IP Next for Kubernetes implantado em DPUs NVIDIA BlueField
Aplicação de políticas de tenant na DPU, separada do sistema operacional do host.
PRODUTO
BIG-IP Next for Kubernetes
Isolamento de tenants no nível de rede e políticas por tenant no perímetro do cluster.
Abasteça e proteja a fábrica
Os tenants de treinamento buscam dados no armazenamento de objetos em diferentes sites e nuvens, e uma interrupção no fluxo de dados deixa suas GPUs ociosas, com o tempo correndo por sua conta. Endpoints públicos de inferência e APIs de tenants ficam expostos à internet, e uma sobrecarga pode custar caro. O F5 BIG-IP balanceia e protege os caminhos de dados S3 até as GPUs e oferece proteção contra DDoS, recursos de firewall e direcionamento global de tráfego no perímetro da fábrica, em hardware desenvolvido para a escala dos provedores de serviços.
Explore a entrega de dados para IAPRODUTO
BIG-IP LTM
Balanceamento de carga e failover entre endpoints de armazenamento S3.
PRODUTO
BIG-IP DNS
Direcionamento global de usuários e tráfego de dados entre sites.
PRODUTO
BIG-IP DNS
Direcionamento global de usuários e tráfego de dados entre sites.
PRODUTO
BIG-IP DNS
Direcionamento global de usuários e tráfego de dados entre sites.
PRODUTO
BIG-IP DNS
Direcionamento global de usuários e tráfego de dados entre sites.
PRODUTO
BIG-IP DNS
Direcionamento global de usuários e tráfego de dados entre sites.
Recursos
Arquiteturas de referência
ARQUITETURA DE REFERÊNCIA
Rede de uso comum entre NVIDIA Cloud Partner e F5 BIG-IP Next for Kubernetes
ARQUITETURA DE REFERÊNCIA
Explore a arquitetura de referência de IA
Relatórios
Visão geral das soluções
VISÃO GERAL DA SOLUÇÃO
Potencializando serviços de GPUaaS e inferência de IA com a F5 e a NVIDIA
VISÃO GERAL DA SOLUÇÃO
Acelerando e otimizando a rede para infraestrutura de IA
Perguntas frequentes
Uma neocloud é um provedor de nuvem estruturado em torno da capacidade de GPUs para IA, em vez de computação de uso geral. A maioria começou alugando servidores GPU bare metal por hora e agora está adicionando Kubernetes gerenciado, GPU como serviço e, em alguns casos, serviços de inferência, para que os clientes corporativos tenham uma plataforma em vez de apenas servidores. Essa mudança aumenta o potencial de receita por hora de GPU e eleva as expectativas dos clientes em relação à infraestrutura de rede subjacente.
O isolamento funciona em camadas. Namespaces e controle de acesso baseado em funções delimitam o que cada tenant gerencia, e clusters virtuais adicionam um plano de controle por tenant. O isolamento no nível de rede, normalmente com EVPN-VXLAN e uma VRF dedicada por tenant, mantém o tráfego de cada tenant em seu próprio domínio de roteamento ao entrar e sair do cluster. As políticas de entrada, saída e firewall por tenant na borda do cluster, por sua vez, determinam o que cada tenant pode acessar.
No modelo bare metal, são alugados servidores inteiros, e o cliente fornece e opera sua própria pilha de software. GPU como serviço e Kubernetes gerenciado acrescentam uma plataforma sobre essa infraestrutura: agendamento, redes, isolamento entre clientes, tráfego de entrada e saída e suporte. O provedor assume mais responsabilidades e pode cobrar mais por hora de GPU, e os clientes corporativos esperam cada vez mais contar com essa plataforma, em vez de apenas servidores.
Dê a cada tenant seu próprio caminho de saída. O tráfego de saída por tenant com endereços de origem estáveis permite que sistemas externos incluam um tenant em listas de permissões com base no endereço, evita que o tráfego de um tenant pareça vir de outro e facilita o registro e a auditoria das conexões de saída por destino. As políticas de rede do Kubernetes ajudam, mas atuam no nível de pods e blocos de IP dentro do cluster.
Não. O BIG-IP Next for Kubernetes é executado em CPUs padrão do host, onde também funcionam o isolamento de tenants e o tráfego de entrada e saída. As DPUs NVIDIA BlueField transferem o processamento do tráfego para fora do host e aplicam políticas fora do sistema operacional do host, o que passa a valer a pena à medida que o número de tenants aumenta e os núcleos do host se tornam mais valiosos como capacidade comercializável. Os resultados medidos no modo DPU não se aplicam a implantações em hosts.