O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve a implantação passo a passo da CPNR no OpenStack Cisco Virtualized Infrastructure Manager (CVIM) usando SR-IOV e vinculação de backup ativo.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando
No cenário de rede atual, as Funções de Rede Virtual (VNFs) desempenham um papel fundamental na habilitação de serviços de rede ágeis, escaláveis e eficientes. Para VNFs que exigem conectividade de rede de alto desempenho, o SR-IOV é uma tecnologia comumente usada. O SR-IOV permite que as VNFs ignorem o switch virtual do hipervisor e acessem diretamente os recursos da placa de rede (NIC) física, reduzindo assim a latência e aumentando o throughput.
Antes de prosseguir com a implantação, verifique se esses pré-requisitos foram atendidos.
As placas de rede Intel XL710 e E810CQDA2 são comumente usadas para redes SR-IOV de alto desempenho. Para verificar o modelo da placa de rede no host, consulte estas etapas:
Execute este comando para listar os dispositivos PCI (Peripheral Component Interconnect) relacionados às controladoras de rede:
lspci | grep -i ethernet
Exemplo de saída:
81:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
82:00.0 Ethernet controller: Intel Corporation Ethernet Controller E810-C for QSFP (rev 03)
Se a placa de rede for Intel XL710, você poderá ver Ethernet Controller XL710 na saída.
Se a placa de rede for Intel E810CQDA2, você poderá ver Ethernet Controller E810-Cna saída.
Para verificar o driver da placa de rede em uso, execute:
ethtool -i
Exemplo de saída para XL710:
driver: i40e
version: 2.13.10
Exemplo de saída para E810CQDA2:
driver: ice
version: 1.7.12
Verifique se a versão do driver corresponde à matriz de compatibilidade para a distribuição do OpenStack e do Linux.
Verifique se o SR-IOV está habilitado no BIOS/UEFI dos servidores.
O Intel VT-d ou AMD-Vi deve ser habilitado para a funcionalidade de passagem de PCI e SR-IOV.
Verifique se os serviços do OpenStack, como Nova, Neutron, Glance e Keystone, estão instalados e configurados.
A Neutron deve suportar Openvswitch (OVS) para redes de orquestração/gerenciamento e SR-IOV para redes de aplicativos/serviços.
Os nós de computação devem ser configurados para suportar SR-IOV, com Funções Virtuais (VFs) criadas nas placas de rede.
A imagem CPNR VNF deve suportar interfaces SR-IOV e incluir os drivers necessários.
Verifique se a imagem CPNR VNF está disponível no OpenStack Glance.
Garanta acesso à CLI do OpenStack para criar redes, variações e iniciar o VNF.
Acesso de raiz ou administrativo para configurar a rede no host Linux e dentro do VNF.
SRIOV
Aqui está um exemplo de XML do Cisco Elastic Services Controller (ESC), demonstrando a implantação da Máquina Virtual (VM) usando a rede SR-IOV (com tipo>direto</tipo>) para um locatário chamado test-tenant e uma VM chamada sriov-vm-1. Isso inclui várias interfaces, incluindo interfaces SR-IOV (diretas):
test-tenant
true
false
sriov-vm-deployment
sriov-vm-1-group
vim1
default
sriov-image
custom-flavor
300
30
REBOOT_ONLY
0
mgmt-net
192.168.10.101
1
direct
sriov-net-1
0
sriov-subnet-1
10.10.10.10
2
direct
sriov-net-2
0
sriov-subnet-2
10.10.20.10
1
1
false
--user-data
file://tmp/init/sriov-vm-1.cfg
type>direct</type> em <interface> habilita o SR-IOV (passagem PCI) para essa placa de rede.
Cada interface SR-IOV tem sua própria rede e sub-rede.
Você pode associar IPv4/IPv6 em <endereços> conforme necessário.
Arquivo de exemplo Day0 para transmitir o XML do Cisco ESC:
Content-Type: multipart/mixed; boundary="===============2678395050260980330=="
MIME-Version: 1.0`
--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-boothook; charset="us-ascii"
#cloud-boothook
#!/bin/bash
if [ ! -f /etc/cloud/cloud.cfg.orig ]; then
cp /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.orig
cp /etc/cloud/cloud.cfg.norootpasswd /etc/cloud/cloud.cfg
fi
--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-config; charset="us-ascii"
#cloud-config
hostname: cpnr
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7pf8gvOWH/Zv8iAlTv6LWEiPGA3B6t96G6LwTHF6iXOqQxyIUkg8IkqZ6wNwxsDV8DYESOzFGp//aXO6wZDtoawMExe9sNEx0qVOt/ueP3IYQ8731fNJwFtWQsCQTM7VQjpcg5/d6eMxQ8zvmiIYo2huwfclE+zLdihjL/Y6v4HK760u/DQ+OaEIgqTgrwePJK5Db/gMDf+oXI9KvNxDb2vtxzroX0APEnZ9JX+Ic0JGWTkD4smMkTdWsjaqDYXqW6SUsyCc4Bf9tHL5Irr1AgUR4hEbLnbk6NlIqWrgVeI5CQVMMFpWqV0o2hyDz2rMA7tbBeYzD/ynslQAerU7DmBRb1FDVh79+JeaCNIM8EpwbCUKHT6CQAjPK8cYBieO1yEHKjHyFTsZgpvdi4rVMP+Qsvab+J5RPPcJeKj7o8KIrtyyESXbLNcZv1uGwZ8nLZKfZQSJP04HUkRKoQJ/JoMvMurEKG/cJ1VtocV4AJiRHj+367D3uzrKd6eHYlM9oD+zpPeJ1P1J2TDPUp2K7GcKCrItn9blSGo/n/+gYBO793QjSdkmc/Ag4TEVhUfG17l0WlSvAw4L0csMlYBAGGqKAUEEx3BJGYNJ851bj23m6JBe83OVWGRWrDIIE+G14/tx8qYXDaFxFUFPb2zj+gmDXq80hYpv++/yFtTocbw== cpnr@INVITN14SLM1BULD01CO
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAmkQGCZUrYqkZ0C0J9t7mF9La9zYOqfzzFkk1wWtPga+aANOaFgjqbjj+VlBdd3zJy1p6BMWZhaZIcOh0+knCisJArcHM3HlurQZXO45zHtBcm7tB1FQ0W1HI9GbvJ+IPIe7kpPme/socd5ytTx0ZkYtlcRDDZuxTwYY4P4/vpnzXuwPS2dfcfQscubj6MkSlx4JHhc/hkDsmtJUipkWEungE/UsldjQzkj8oJorymYHQXE/czNxwzCGizK1YinhebeHFcmHd6Jcqd5oZZWnmkGKGeW6o0ddSFI5NmwzHd5RzwjztU2nqmiyOA8mu7YkCm6X82uhACwQlfY0pGRpTVkIhlf+tKDwKQRuwpcbR1ZUHmli0zi5QZtbzc31aLNlUPpR21BptS4GSfbKJaMOaDUClfe8rGk+9GCgm6wnZiT+SMa4/wEA9NILlwobrwHxVsb/kFlFKXg0aPkdvmqWPNcd09vF50enrs0aXFsqCyl6CPMJpZtGAgckvX8iU2bCJkxzD9F4rAu2D/FNb8KG5cbw7uptiwB4yoek6Q36NyxHYYJyOGiV4oQJ02T9MRPkvjLf7ASx9HA25nG+J4CZXWkuV7XYX1N5DFvOg/kwA7xMPyNgTEkblTRpIcfXU2PCWYSZcn1vYmsazf2uVCY+mjfLcvi85c/1mLnUGikiovQ== admin@invitn14slm1escx01co
runcmd:
- /usr/sbin/useradd FMLVL1 -d /home/FMLVL1 -s /bin/bash -g users; (/bin/echo changeme; /bin/echo changeme) | /usr/bin/passwd FMLVL1
- nmcli con add type ethernet con-name eth0 ifname eth0 ip4 10.xx.xx.xx/24
- nmcli con add type ethernet con-name eth1 ifname eth1 ip4 172.xx.xx.xx/23
- nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=1000,fail_over_mac=1" ipv4.addresses 'xx.xx.xx.xx/29' ipv4.gateway 'xx.xx.xx.xx' ipv4.method manual ipv6.addresses '2402:xxxx:xx:0025::5/64' ipv6.gateway '2402:xxxx:xx:0025::1' ipv6.method manual
- nmcli connection add type ethernet ifname ens6 master bond0
- nmcli connection add type ethernet ifname ens7 master bond0
- nmcli con up eth0
- nmcli con up eth1
- nmcli con up bond-slave-ens6
- nmcli con up bond-slave-ens7
- nmcli con down bond0
- nmcli con up bond0
- nmcli connection reload
- hostnamectl set-hostname CPNRDNS01CO
--===============2678395050260980330==
A CPNR é uma função de rede virtual (VNF) vital que fornece gerenciamento de endereços IP (IPAM), DHCP e serviços de servidor de nome de domínio (DNS) para redes corporativas e de provedores de serviços. A implantação da CPNR como uma VNF no OpenStack requer um planejamento cuidadoso, especialmente ao utilizar portas SR-IOV, configurações cross-NUMA e uma interface de ligação de backup ativo para redundância e desempenho.
Este artigo explica o processo passo a passo para implantar o CPNR VNF no OpenStack. Ele inclui:
Reconhecimento de Cross-NUMA:
Vinculação de backup ativo:
Rede OpenStack:
NUMA é uma arquitetura de memória onde cada CPU (e sua memória local e dispositivos) é agrupada em um nó NUMA. No OpenStack, o posicionamento com reconhecimento de NUMA garante que os VNFs sejam atribuídos de forma ideal aos recursos no mesmo nó NUMA para minimizar a latência e maximizar o desempenho.
As placas de rede SR-IOV são NUMA-Local:
Limitação de Modo NUMA Único:
O CPNR VNF requer acesso a:
Nesta instalação, o CPNR VNF requer acesso a NICs SR-IOV de NUMA 0 (sriov0) e NUMA 1 (sriov1) para fornecer redundância e alta disponibilidade. Para isso:
Conntrack é um recurso do kernel do Linux usado para rastrear conexões de rede, particularmente para NAT (Network Address Translation Conversão de Endereço de Rede) e regras de firewall. Para portas baseadas em OVS no OpenStack, o contrtrack é usado para gerenciar o estado da conexão e aplicar regras de grupos de segurança.
Tabela Contrack:
Limite padrão:
Impacto nas portas OVS:
Aumentar Tamanho da Tabela de Controle de Conversão:
sysctl net.netfilter.nf_conntrack_max
sysctl -w net.netfilter.nf_conntrack_max=262144
echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
Monitorar Uso do Controle de Controle:
Verifique as estatísticas do controle de contexto:cat /proc/sys/net/netfilter/nf_conntrack_count
Otimizar Regras do Grupo de Segurança:
Reduza o número de regras aplicadas às portas OVS para minimizar a sobrecarga do controle de contorno.As portas SR-IOV ignoram o caminho de dados OVS e os recursos do kernel do Linux como conntrack. Isso remove completamente a sobrecarga de rastreamento de conexão.
Ao contrário das portas OVS, que são limitadas pelo tamanho da tabela de controle (nf_conntrack_max), as portas SR-IOV podem lidar com um número praticamente ilimitado de conexões.
Ao descarregar o processamento de pacotes para o hardware da placa de rede, as portas SR-IOV eliminam a latência introduzida pelo processamento de controle baseado em software.
O modo de vinculação de backup ativo é particularmente adequado para essa implantação devido à sua simplicidade, tolerância a falhas e compatibilidade com interfaces SR-IOV. Veja por quê:
O modo de backup ativo funciona independentemente dos switches físicos subjacentes ou do hardware. A lógica de failover reside inteiramente no kernel do Linux, tornando-o altamente portátil e versátil.
Os VFs de SR-IOV estão vinculados a NICs físicas e nós NUMA específicos. Usando o modo de backup ativo, você pode combinar VFs de diferentes nós NUMA em uma única interface de ligação lógica (bond0). Isso garante alta disponibilidade, ao mesmo tempo em que faz uso eficiente dos recursos NUMA.
O modo de backup ativo é um dos modos mais simples e mais amplamente usados na vinculação com o Linux. Ele foi projetado para fornecer alta disponibilidade, garantindo que o tráfego continue a fluir sem interrupções, mesmo se uma das interfaces vinculadas falhar. Esta é uma explicação detalhada de como o modo Ative-Backup funciona, suas características principais e suas vantagens.
Uma interface de ligação no Linux combina duas ou mais interfaces de rede em uma única interface lógica. Essa interface lógica, conhecida como ligação (por exemplo, ligação0), é usada para fornecer:
No modo Ative-Backup, apenas uma interface (chamada de interface ativa) é usada em um determinado momento para transmitir e receber tráfego. A(s) outra(s) interface(s) permanece(m) em modo standby. Se a interface ativa falhar, uma das interfaces em standby será promovida para o status ativo e o tráfego será automaticamente redirecionado para a nova interface ativa.
Interface única ativa:
Failover automático:
Suporte a failback:
Quando a interface com falha for restaurada, ela poderá se tornar ativa automaticamente novamente (se configurada para fazer isso) ou permanecer no modo de espera, dependendo da configuração de vinculação.Sem requisitos de switch:
Monitoramento:
imon
(Media Independent Interface Monitor).Interface ativa:
Monitoramento:
Falha de link na interface ativa:
Se a interface ativa (eth2) falhar (por exemplo, cabo desconectado, falha de hardware da placa de rede ou link inativo), a conexão detectará imediatamente a falha usando monitor miniimonor ARP.Failover automático:
Tempestividade de failover:
O processo de failover é quase instantâneo (normalmente em alguns milissegundos, dependendo do intervalo de meia hora).Restauração da interface com falha:
Continuidade de tráfego:
O failback é perfeito, garantindo que não haja interrupção nos fluxos de tráfego em andamento.O modo de backup ativo é particularmente adequado para interfaces SR-IOV porque:
Por exemplo:
A CPNR VNF requer estas quatro redes:
Implantação passo a passo:
Rede de orquestração:
openstack network create --provider-network-type vxlan orchestration-network
Rede de gerenciamento:
openstack network create --provider-network-type vxlan management-network
Sub-rede de orquestração:
openstack subnet create --network orchestration-network \
--subnet-range 192.168.100.0/24 orchestration-subnet
Sub-rede de gerenciamento:
openstack subnet create --network management-network \
--subnet-range 10.10.10.0/24 management-subnet
Rede 1 SR-IOV:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov0 --provider-segment 101 sriov-network-1
Rede SR-IOV 2:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov1 --provider-segment 102 sriov-network-2
Para garantir que o VNF possa acessar as placas de rede SR-IOV de ambos os nós NUMA, crie um tipo com suporte a cross-NUMA:
openstack flavor create --ram 8192 --vcpus 4 --disk 40 cross-numa-flavor
Definir propriedades específicas de NUMA:
openstack flavor set cross-numa-flavor \
--property hw:numa_nodes=2 \
--property hw:cpu_policy=dedicated \
--property hw:mem_page_size=large
Depois de iniciar o VNF, configure a interface de ligação para portas SR-IOV (eth2 e eth3) no VNF.
Crie uma interface de vínculo (bond0) no modo de Backup Ativo:
vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=static
ONBOOT=yes
BONDING_OPTS="mode=active-backup miimon=100"
IPADDR=172.16.1.10
NETMASK=255.255.255.0
GATEWAY=172.16.1.1
eth2:
vi /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
ONBOOT=yes
MASTER=bond0
SLAVE=yes
eth3:
vi /etc/sysconfig/network-scripts/ifcfg-eth3
DEVICE=eth3
ONBOOT=yes
MASTER=bond0
SLAVE=yes
Reinicie o serviço de rede para aplicar a configuração:
systemctl restart network
Após implementar o VNF, verifique sua funcionalidade usando estas etapas:
Verifique se a instância do VNF está ativa:
openstack server show cpnr-instance
Verifique se o status é ATIVE.
Teste de ping: Verifique se o VNF pode se comunicar por todas as redes:
ping
ping
Interface de ligação:
Confirme se bond0 está ativo:
cat /proc/net/bonding/bond0
Procure:
Verifique se o VNF está usando recursos de ambos os nós NUMA:
nova show --human | grep numa
Monitoramento e solução de problemas: Use ferramentas como cpdumpandethtoolpara monitorar as interfaces SR-IOV.
Segurança: Gerencie cuidadosamente o acesso à rede física e aplique o isolamento estrito entre os usuários.
Dimensionamento: Planeje a capacidade física da placa de rede ao escalar implantações de SR-IOV, pois o número de VFs disponíveis é limitado pelo hardware da placa de rede.
Se a implantação não funcionar como esperado, consulte estas etapas de Troubleshooting:
dmesg | grep -i "SR-IOV"
lspci | grep Ethernet
Se o VNF não puder acessar ambas as NICs, verifique se o modo cross-NUMA está habilitado:
openstack flavor show cross-numa-flavor
cat /proc/net/bonding/bond0
systemctl restart network
openstack port list --server cpnr-instance
ip addr show
A implantação de CPNR VNF no OpenStack com portas SR-IOV requer o modo cross-NUMA para permitir que o VNF se conecte a NICs de ambos os nós NUMA. Isso é essencial porque o OpenStack restringe VNFs no modo de NUMA único para acessar apenas recursos (NICs, CPUs, memória) dentro do nó NUMA onde o VNF é iniciado. A combinação do modo cross-NUMA com a vinculação de backup ativo garante alta disponibilidade, tolerância a falhas e utilização eficiente de recursos, tornando essa implantação altamente resiliente e eficiente.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
10-Jul-2025 |
Versão inicial |