SmartNICs na hospedagem: como avaliar corretamente a aceleração de rede

Como enquadrar corretamente os SmartNICs no contexto da hospedagem

O termo SmartNIC não é um nome de produto padronizado de forma uniforme. Por isso, para o planeamento na hospedagem, o que é determinante não é a etiqueta, mas sim a função comprovável no percurso de dados: que pacotes, regras e túneis é que a placa consegue processar, que tarefas permanecem a cargo do anfitrião e que software controla as funções? Uma velocidade elevada da porta não responde a estas questões.

Uma placa de rede clássica fornece, acima de tudo, a ligação Ethernet e suporta funções básicas de descarregamento comuns, como somas de verificação ou segmentação. Uma SmartNIC alarga este âmbito com funções especializadas ou programáveis de encaminhamento de dados. Estas podem incluir regras de fluxo, funções de comutação virtual, SR-IOV, processamento de túneis ou tarefas criptográficas específicas. No entanto, a disponibilidade destas funções depende conjuntamente do modelo, do firmware, dos controladores e da integração com a plataforma.

A DPU tem, regra geral, uma arquitetura mais abrangente: além do ASIC de rede, dispõe de recursos computacionais próprios e pode operar um caminho de dados de infraestrutura separado. A NVIDIA descreve, para o BlueField, um modo DPU, no qual o sistema ARM integrado controla os recursos da NIC e o caminho de dados, bem como um modo NIC, no qual a placa se comporta como um adaptador perante o anfitrião externo. Assim, dependendo do modo de funcionamento, surge também uma área própria de gestão e confiança.

Esta classificação tem consequências práticas para a aquisição e a operação. Uma placa com lógica de cálculo própria não é automaticamente a melhor escolha quando apenas são necessárias transferências básicas simples. Por outro lado, um caminho de infraestrutura externo pode fazer sentido para a separação de clientes ou para funções de segurança, mas exige então manutenção de firmware, conceitos de acesso, monitorização e processos de recuperação para componentes adicionais.

Mesmo uma porta de 100 GbE ou mais rápida não garante qualquer aceleração das regras de firewall, das sobreposições ou da encriptação. Os fatores decisivos são o tamanho dos pacotes, o número de fluxos paralelos, a complexidade das regras e a questão de saber se as ações necessárias podem, de facto, ser implementadas em hardware. Só quando se comprovar que a CPU do servidor constitui um limite no percurso dos dados da rede é que uma lista de funcionalidades se traduz num possível ganho de capacidade.

Como o descarregamento de hardware altera o percurso dos dados

Sem um descarregamento adicional, um pacote chega inicialmente à placa de rede física (NIC) e é, em seguida, processado pelo anfitrião. Dependendo da arquitetura, passa pela pilha de rede do kernel, pela firewall, pela ponte ou pelo switch virtual, pelo encaminhamento e, se for o caso, pelo encapsulamento para uma sobreposição. Só depois disso é que chega a uma VM, a um contentor ou a outra porta física. Cada etapa pode causar consumo de tempo de CPU e filas de espera.

Este percurso torna-se particularmente relevante no caso de muitos pacotes pequenos, de inúmeras ligações de curta duração ou de políticas de clientes extensas. Não é apenas a quantidade de dados transmitidos que sobrecarrega o anfitrião, mas também o processamento repetido de pacotes e fluxos individuais. Por isso, é aceleração de rede não é uma característica geral de um servidor, mas sim um alívio específico de uma rota de dados concretamente identificada.

Em Descarregamento de hardware Os componentes de controlo podem transferir regras de encaminhamento e filtragem válidas para um caminho de dados de hardware. O modelo «switchdev» do Linux descreve, para este efeito, a transferência do caminho de dados de encaminhamento do kernel para um dispositivo de comutação. As regras que são efetivamente aplicadas dependem da placa específica, do seu controlador e da integração de rede a montante.

A documentação do OVS no ramo de desenvolvimento 4.0.90 descreve explicitamente uma secção separada sobre o «Flow Hardware Offload» como experimental. Para esta configuração específica do OVS com DPDK, a documentação distingue entre a descarregamento total de correspondências e ações e o descarregamento parcial, no qual apenas as correspondências são descarregadas. Esta descrição não constitui uma prova de compatibilidade estável e universalmente válida para outras versões do OVS, placas de rede (NICs) ou plataformas.

Na prática, cada declaração de offload deve, portanto, especificar o percurso concreto dos dados: versão do software utilizada, controladores, firmware, campos de correspondência e ações. Um interruptor ativado não prova nem que os fluxos relevantes sejam transferidos, nem que os requisitos de segurança e a semântica da rede continuem a ser cumpridos inalterados. No caso da filtragem de VLAN, por exemplo, o switchdev exige que o hardware cumpra as regras da VLAN de ponte e rejeite os IDs de VLAN não autorizados. O offload é, assim, a implementação técnica das regras existentes, e não um atalho para as contornar.

Em que situações as SmartNICs são úteis na hospedagem

Os SmartNICs revelam-se especialmente úteis em plataformas de virtualização com muitas máquinas virtuais (VM) e decisões de encaminhamento recorrentes. O SR-IOV permite atribuir uma função virtual a uma VM; numa arquitetura switchdev, as interfaces Representor representam funções físicas ou virtuais no sistema operativo. As regras para o tráfego entre estas portas podem, assim, ser implementadas em hardware. No entanto, a utilidade depende das funções necessárias para as máquinas virtuais.

Redes de sobreposição com capacidade para múltiplos clientes e Microsegmentação constituem outro ponto de partida. Quando muitas redes de clientes aplicam repetidamente atribuições de VLAN ou de overlay, regras de controlo de acesso e decisões semelhantes relativas aos fluxos, um percurso de dados de hardware adequado pode aliviar a carga das CPUs dos anfitriões. A condição prévia continua a ser que o número de regras, os campos de correspondência e as ações estejam disponíveis na placa selecionada, juntamente com o controlador, e que a semântica das políticas seja totalmente preservada.

Para a OpenShift Container Platform 4.22, a Red Hat documenta o descarregamento de hardware para nós bare-metal com SmartNIC compatível e o SR-IOV Network Operator ativo. Nesse contexto, apenas são suportadas a comunicação pod-a-pod e a comunicação pod-a-serviço ClusterIP com pods normais; as aplicações DPDK não são compatíveis com esta funcionalidade. Além disso, a vantagem limita-se a segmentos de comunicação cujos nós envolvidos utilizem SmartNICs compatíveis.

No caso de redes de host ou locais encriptadas, o offload IPsec pode assumir tarefas específicas ou todo o processo de encapsulamento, desencapsulamento, encriptação e proteção contra repetição. A NVIDIA documenta vários tipos de descarregamento para este fim, incluindo o descarregamento criptográfico e o descarregamento total. No entanto, isso não implica uma compatibilidade universal: o suporte e os limites de desempenho dependem do modelo, do firmware e do método criptográfico utilizado.

Um servidor de alojamento web simples é, deliberadamente, um contra-exemplo. Se este fornecer, na sua maioria, respostas HTTP poucas mas de grande dimensão e não apresentar carga de CPU no percurso dos pacotes, pode ser mais adequado um servidor mais especializado hardware de servidor apenas geram custos operacionais adicionais. Em primeiro lugar, deve esclarecer-se se a causa do estrangulamento reside na aplicação, na base de dados, na memória ou na rede. As SmartNICs não são uma boa opção para substituir este diagnóstico.

Comparar os casos de utilização do ponto de vista técnico

A decisão sobre se uma SmartNIC faz sentido não depende da velocidade nominal da porta, mas sim do percurso concreto dos dados. A sua utilização é particularmente justificada quando muitas regras recorrentes, um elevado número de fluxos ou funções de overlay e de segurança ocupam constantemente o tempo da CPU do anfitrião. A vantagem mantém-se dependente do percurso: Uma secção acelerada só beneficia as ligações que são efetivamente estabelecidas através de hardware compatível e regras suportadas.

No caso das plataformas de virtualização, SR-IOV Uma abordagem típica: as funções virtuais são atribuídas a uma VM, enquanto as interfaces Representor no sistema operativo mapeiam as portas dessas funções. Desta forma, é possível implementar em hardware as regras de reencaminhamento entre portas virtuais e físicas numa arquitetura orientada para switchdev. No entanto, isto não substitui a verificação de se a separação de clientes pretendida e o modelo operacional são mantidos.

O Kubernetes é o oposto de uma promessa genérica de aceleração. Para a integração documentada com o OpenShift 4.22, aplicam-se determinados percursos de tráfego suportados, nós SmartNIC compatíveis e requisitos de carga de trabalho. Se um nó com capacidade de offload comunicar com um nó normal, este último processa a sua parte no kernel, limitando assim o percurso total. Por conseguinte, uma implementação deve, em primeiro lugar, ter em conta um conjunto de nós delimitado e vias de comunicação reais.

No caso de redes de host ou locais encriptadas, estes termos devem ser utilizados com especial precisão. As variantes documentadas do IPsec variam, consoante a plataforma, desde o «Crypto-Offload» até ao «Full Offload» para encapsulamento, desencapsulamento, encriptação e proteção contra repetição. Daí não decorre qualquer garantia geral de débito: o modelo, o firmware, os algoritmos utilizados e as limitações específicas do produto determinam qual o processamento que é efetivamente externalizado.

Verificar a compatibilidade antes da implementação

A aquisição começa com um levantamento da situação atual, sem alterações, e não com a ativação de opções de offload. Registe o modelo exato da placa, incluindo o PCI-ID, a versão do firmware, os controladores e o kernel. Além disso, é necessário conhecer o modo eSwitch, bem como a versão e a configuração do Open vSwitch, OVN, hipervisor ou plataforma Kubernetes, uma vez que a capacidade da placa, por si só, não garante uma integração completa do software.

A semântica de regra necessária deve estar disponível antecipadamente sob a forma de descrição do caminho de dados: por exemplo, atribuição de VLAN, IPv4 ou IPv6, TCP ou UDP, tipo de túnel, alteração de cabeçalho, reencaminhamento ou rejeição. A documentação experimental do OVS 4.0.90 demonstra, no que diz respeito à sua configuração DPDK, que a ausência de ações de hardware pode conduzir a um descarregamento parcial. Daí decorre que, para qualquer outra versão ou plataforma, se trata apenas de uma tarefa de verificação, não constituindo qualquer garantia quanto ao seu âmbito funcional.

As matrizes de plataforma são Certificados de compatibilidade específicos para cada versão, sem fazer afirmações gerais sobre uma família de placas de rede. O OpenShift 4.22 especifica placas de rede concretas para a sua integração de descarregamento de hardware, incluindo a BlueField-2 no modo ConnectX-6. Daí não se pode deduzir o suporte a outro firmware, nem a outro modo de DPU, nem a uma distribuição diferente. Por isso, documente separadamente cada combinação de hardware, firmware, controlador e versão da plataforma.

No caso do switchdev do Linux, é também fundamental que o hardware respeite a semântica da rede de software. No caso da filtragem de VLAN, por exemplo, um switch que realiza o offload deve respeitar as regras de VLAN da ponte e rejeitar os IDs de VLAN não autorizados. Este requisito demonstra por que razão as listas de funções e a política de segurança devem ser verificadas em conjunto: a aceleração não pode criar uma segmentação de rede diferente.

Comparar o SmartNIC com a CPU e o software

Uma SmartNIC é apenas uma das várias opções quando o processamento de rede está limitado. Em primeiro lugar, vale a pena verificar se uma maior capacidade da CPU, um número adequado de filas, RSS, distribuição de IRQ ou ajuste do kernel já resolvem o estrangulamento. Para compreender melhor os SoftIRQs, as filas e a distribuição de interrupções, consulte o artigo sobre Rendimento da CPU e da rede no alojamento princípios adicionais. Sem a comprovação de um estrangulamento na rede, a necessidade de hardware especializado adicional permanece uma suposição.

O DPDK e o AF_XDP podem encurtar os percursos de software nas CPUs do anfitrião, mas cada um requer um planeamento específico da arquitetura e da CPU. A afirmação relativa ao polling contínuo não pode ser aplicada de forma generalizada a ambas as abordagens: Na documentação do OVS-DPDK relativa à configuração descrita, um thread faz o polling contínuo dos dispositivos DPDK, ocupando, ao fazê-lo, um núcleo da CPU na totalidade. A mapeamento NUMA, o isolamento de núcleos e as versões específicas do OVS e do DPDK continuam, portanto, a fazer parte do projeto.

Mesmo uma placa de rede clássica de servidor pode proporcionar descarregamento de carga suficiente para somas de verificação, segmentação ou funcionalidades específicas de túneis. Esta opção é adequada quando não são necessárias regras extensas de switch virtual, segregação de clientes ou percursos de dados de segurança implementados em hardware. As SmartNICs tornam-se especialmente viáveis quando as funções exigidas vão além dessas características básicas e são recorrentes a longo prazo.

O conceito de capacidade é simples, mas importante: se, num host, os núcleos da CPU estiverem a ser sobrecarregados pelo processamento de pacotes e se for possível descarregar totalmente uma parte representativa desses pacotes, poderá surgir margem de manobra na CPU. No entanto, essa margem só conta como capacidade utilizável se não houver um estrangulamento a seguir causado pela aplicação, pela memória, pelo armazenamento ou por um plano de contingência de software. Não se trata de uma dedução direta da taxa de ligação ou do preço da placa.

Por isso, compare as alternativas com base no mesmo perfil de carga: tamanhos dos pacotes, taxa de ligação, número de regras, túneis, encriptação e pico de carga previsto. Ao fazê-lo, analise as percentagens de CPU do percurso dos dados separadamente do trabalho da aplicação e verifique quais os fluxos que realmente são processados em hardware. Um Limitação da CPU A passagem por uma firewall, uma rede overlay ou um encaminhamento virtual constitui um motivo válido para avaliação; uma carga elevada do sistema em geral não o é.

Tornar visível o offload durante o funcionamento

Após a implementação, não basta considerar uma opção de descarregamento como ativa. Uma demonstração de funcionamento fiável associa o Estado do fluxo com os contadores da placa, as taxas de perda e de erros, a utilização da CPU, bem como um perfil de carga semelhante ao tráfego futuro. Só em conjunto é que estes dados revelam se os fluxos relevantes são efetivamente processados no hardware ou se o anfitrião continua a suportar a parte decisiva do percurso dos dados.

Para efeitos de comparação, os operadores devem considerar os mesmos tamanhos de pacotes, protocolos, número de ligações e diretrizes, tanto antes como depois de uma alteração. A taxa de transferência em gigabits, por si só, pode facilmente ocultar um estrangulamento no caso de pacotes pequenos ou de muitos fluxos paralelos. Igualmente importantes são a latência, o tempo de CPU por anfitrião envolvido, a carga de Softirq, as perdas na fila e a distribuição do tráfego pelos nós e portas.

Os comandos seguintes não alteram nenhuma configuração. A primeira consulta tem em conta tanto os dispositivos PCI que aparecem como «Ethernet controller» como aqueles que aparecem como «Network controller». ethtool -k apresenta as funcionalidades de offload disponibilizadas ou ativadas no Netdev, mas não comprova de forma exaustiva nem o eSwitch, nem o SmartNIC, nem o offload de fluxos. As restantes saídas são também dados de inventário e configuração, não constituindo prova de uma regra específica totalmente transferida.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

No caso do Open vSwitch, é importante distinguir, em particular, entre a aceleração por hardware configurada e o resultado observado. A documentação de desenvolvimento do OVS 4.0.90 classifica a sua descarregamento de fluxo por hardware como experimental e descreve o descarregamento total ou parcial apenas para esta configuração do OVS com DPDK. Para o funcionamento em produção, é, por isso, necessário avaliar as informações de fluxo e os contadores de hardware em conjunto com os contadores de software do anfitrião.

O monitorização requer, além disso, uma referência temporal. Um teste breve pode confirmar regras, enquanto um perfil próximo da produção pode, posteriormente, desencadear capacidades de tabelas, percursos de registo pouco frequentes ou reconfigurações. Por isso, faz sentido registar valores normais e anomalias por modelo de placa, firmware, controlador e versão da plataforma. Desta forma, após as atualizações, é possível verificar se o Percurso dos dados ou se apenas a carga observada se alterou.

Na integração com o OpenShift 4.22, a visão deve, além disso, abranger todo o percurso de comunicação. O suporte documentado para descarregamento de hardware aplica-se apenas a determinadas cargas de trabalho e tipos de comunicação. Se um nó compatível comunicar com um nó sem um SmartNIC adequado, este último processa a sua parte no kernel; os pontos de medição num único anfitrião podem, então, apresentar uma imagem incompleta do percurso de ponta a ponta.

Padrões típicos de falhas e percursos de recaída

O erro mais comum é transferência incompleta. Um fluxo pode ser identificado no hardware com base em características simples, mas, no caso de uma ação não suportada, tem de regressar parcial ou totalmente ao caminho do software. A documentação experimental do OVS 4.0.90 descreve esta descarga parcial para a sua configuração DPDK. Não se trata de uma afirmação geral aplicável a todas as instalações do OVS, mas ilustra o ponto de verificação necessário em cada integração específica.

O diagnóstico começa ao longo do percurso efetivo: porta de entrada, função virtual ou representador, regra de switch, processamento de túnel ou de política e carga de trabalho de destino. Se os contadores a montante e a jusante de uma etapa não corresponderem de forma plausível, isso constitui um motivo para verificar as correspondências, as ações e o fallback. Uma funcionalidade ativada não substitui esta atribuição, uma vez que a capacidade do mapa não abrange todas as combinações de regras desejadas.

Os clusters heterogéneos tornam a comparação mais difícil. No OpenShift 4.22, o descarregamento de hardware só ocorre se os pods e serviços envolvidos estiverem atribuídos a nós com SmartNIC compatível. Se um caminho deste tipo encontrar um nó normal, o seu processamento é efetuado no kernel, o que limita a comunicação global. Por conseguinte, um único nó acelerado não ocupa um caminho de cluster totalmente acelerado.

Uma configuração inadequada do pod ou da rede também pode impedir o efeito esperado. A Red Hat salienta expressamente, relativamente à funcionalidade do OpenShift 4.22, que o offload de hardware ativado, sem pods devidamente configurados, pode prejudicar o débito do pod. Por conseguinte, os operadores não devem resolver um desvio ativando mais opções, mas sim verificar primeiro a ligação da carga de trabalho, o modo de rede e os fluxos efetivamente alcançados.

A capacidade de regulação e os desvios de firmware pertencem à mesma classe de erros: no caso de muitos clientes, ligações de curta duração ou políticas dinâmicas, o volume de fluxo relevante pode aumentar de forma diferente do esperado. Além disso, um controlador vinculado a uma versão específica ou um firmware diferente pode oferecer funcionalidades diferentes das previstas para a combinação de plataformas. Por isso, os dados de inventário e os contadores devem ser sempre arquivados juntamente com o conjunto de regras específico.

A percurso de recaída controlado permite que o funcionamento seja passível de diagnóstico. Significa que o processamento por software se mantém como alternativa prevista e que as alterações são implementadas gradualmente, com janelas de comparação e critérios de interrupção claros. O «fallback» de software não constitui, por si só, uma avaria, podendo ser o tratamento esperado para ações que o caminho de hardware selecionado não suporta na totalidade.

Tomar decisões realistas em matéria de aquisição e exploração

Uma decisão de aquisição começa pela carga de trabalho, não pela velocidade da porta ou pela designação do produto. O uso de hardware especializado faz sentido nos casos em que se comprove que o processamento recorrente de pacotes consome tempo de CPU: por exemplo, numerosas redes virtuais, conjuntos de políticas estáveis, tráfego de overlay ou um percurso de encriptação definido. Na ausência dessa comprovação, o ajuste da CPU e das filas ou uma placa de rede clássica com descargas básicas adequadas podem ser a solução mais simples.

Em seguida, é necessário que o Certificado de compatibilidade para a combinação específica: modelo de placa e modo de funcionamento, firmware, controladores, kernel, switch virtual ou CNI, bem como as funções de correspondência e ação necessárias. Os aceleradores de infraestrutura programáveis podem, por exemplo, proporcionar o descarregamento de fluxos para funções relacionadas com o estado ou com a sessão; no entanto, isso não significa que todas as SmartNICs ou todas as plataformas ofereçam a mesma função.

A redução esperada da carga da CPU só estará disponível como capacidade quando o processamento de pacotes tiver sido o gargalo e os núcleos que ficaram livres puderem ser utilizados de forma adequada. Se forem, por exemplo, alocados para bases de dados, web workers ou reservas, trata-se de uma decisão de arquitetura, não de um aumento automático de desempenho. O restante equipamento do servidor continua, portanto, a ser determinante; a CPU, a memória RAM e o armazenamento têm de ser adequados à aplicação, tal como a rede. O artigo sobre Hardware de servidor relevante para o desempenho na hospedagem web.

No caso do IPsec, a verificação é particularmente específica: as variantes de offload documentadas vão desde o offload de criptografia até à externalização completa do encapsulamento, desencapsulamento, encriptação e proteção contra repetição. A variante que pode ser utilizada depende do modelo, da geração, do firmware e da configuração de criptografia. As notas específicas do produto podem, além disso, incluir restrições para determinadas gerações ou larguras de banda; estas devem ser incluídas na verificação de aprovação antes da implementação.

Uma DPU alarga a decisão, criando uma área própria de gestão e confiança. No modo BlueField-DPU, o sistema Arm integrado controla os recursos da NIC e o percurso dos dados, em vez de a placa funcionar apenas como adaptador do anfitrião. Isto permite separar as tarefas de infraestrutura do anfitrião, mas exige uma estratégia robusta em termos de direitos de acesso, imagens, atualizações, monitorização e recuperação.

Do ponto de vista económico, não é, portanto, apenas o preço da placa que conta. Em contrapartida, há de considerar a capacidade da CPU do host poupada ou evitada, a vida útil prevista da plataforma, bem como os custos adicionais com certificação, peças de substituição, manutenção do firmware e recuperação de incidentes. Uma SmartNIC faz sentido quando este cálculo se baseia num percurso de dados reproduzível e num ciclo de vida controlável a longo prazo — e não porque o hardware especializado pareça, por princípio, mais rápido.