De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft de stapsgewijze implementatie van CPNR op OpenStack Cisco Virtualized Infrastructure Manager (CVIM) met behulp van SR-IOV en Active-Backup bonding.
Cisco raadt kennis van de volgende onderwerpen aan:
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
In het huidige netwerklandschap spelen Virtual Network Functions (VNF's) een cruciale rol bij het mogelijk maken van flexibele, schaalbare en efficiënte netwerkservices. Voor VNF's die een krachtige netwerkconnectiviteit vereisen, is SR-IOV een veelgebruikte technologie. Met SR-IOV kunnen VNF's de virtuele switch van de hypervisor omzeilen en rechtstreeks toegang krijgen tot de bronnen van de Physical Network Interface Controller (NIC), waardoor de latentie wordt verminderd en de doorvoer wordt verhoogd.
Voordat u doorgaat met de implementatie, moet u ervoor zorgen dat aan deze vereisten wordt voldaan.
Intel XL710 en E810CQDA2 NIC-kaarten worden vaak gebruikt voor hoogwaardige SR-IOV-netwerken. Voer de volgende stappen uit om het NIC-kaartmodel op de host te controleren:
Voer deze opdracht uit om een lijst te maken van de apparaten voor randapparaatverbindingen (PCI's) die zijn gekoppeld aan netwerkcontrollers:
lspci | grep -i ethernet
Voorbeeld uitvoer:
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)
Als de NIC Intel XL710 is, ziet u Ethernet-controller XL710 in de uitvoer.
Als de NIC Intel E810CQDA2 is, ziet u Ethernet-controller E810-Cin de uitvoer.
Om het gebruikte NIC-stuurprogramma te controleren, voert u het volgende uit:
ethtool -i
Voorbeeld van uitvoer voor XL710:
driver: i40e
version: 2.13.10
Voorbeeld van uitvoer voor E810CQDA2:
driver: ice
version: 1.7.12
Zorg ervoor dat de driverversie overeenkomt met de compatibiliteitsmatrix voor uw OpenStack- en Linux-distributie.
Zorg ervoor dat SR-IOV is ingeschakeld in het BIOS/UEFI van de server.
Intel VT-d of AMD-Vi moet zijn ingeschakeld voor PCI-doorvoer en SR-IOV-functionaliteit.
Zorg ervoor dat OpenStack-services zoals Nova, Neutron, Glance en Keystone zijn geïnstalleerd en geconfigureerd.
Neutron moet zowel OpenSwitch (OVS) voor orkestratie-/beheernetwerken als SR-IOV voor applicatie-/servicenetwerken ondersteunen.
De compute nodes moeten worden geconfigureerd om SR-IOV te ondersteunen, waarbij virtuele functies (VF's) op de NIC's zijn gemaakt.
Het CPNR VNF-image moet SR-IOV-interfaces ondersteunen en de benodigde stuurprogramma's bevatten.
Zorg ervoor dat het CPNR VNF-image beschikbaar is in OpenStack Glance.
Zorg voor toegang tot de OpenStack CLI voor het maken van netwerken, smaken en het starten van de VNF.
Root- of beheerderstoegang voor het configureren van netwerken op de Linux-host en binnen de VNF.
SRIOV
Hier is een voorbeeld van Cisco Elastic Services Controller (ESC) XML, waarin de implementatie van een virtuele machine (VM) wordt aangetoond met behulp van SR-IOV-netwerken (met type>direct</type>) voor een tenant met de naam test-tenant en een VM met de naam sriov-vm-1. Dit omvat meerdere interfaces, waaronder SR-IOV (directe) interfaces:
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> onder <interface> maakt SR-IOV (PCI-passthrough) voor die NIC mogelijk.
Elke SR-IOV-interface heeft zijn eigen netwerk en subnet.
U kunt IPv4/IPv6 koppelen in <adressen> als dat nodig is.
Voorbeeld van Day0-bestand om de Cisco ESC XML door te geven:
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==
CPNR is een vitale Virtual Network Function (VNF) die IP Address Management (IPAM), DHCP en Domain Name Server (DNS)-services biedt voor netwerken van ondernemingen en serviceproviders. Het implementeren van CPNR als een VNF in OpenStack vereist een zorgvuldige planning, vooral bij het gebruik van SR-IOV-poorten, cross-NUMA-configuraties en een Active-Backup-verbindingsinterface voor redundantie en prestaties.
In dit artikel wordt het stapsgewijze proces voor de implementatie van de CPNR VNF op OpenStack uitgelegd. Het omvat:
Cross-NUMA Bewustzijn:
Active Backup-binding:
OpenStack Networking:
NUMA is een geheugenarchitectuur waarbij elke CPU (en zijn lokale geheugen en apparaten) is gegroepeerd in een NUMA-node. In OpenStack zorgt NUMA-bewuste plaatsing ervoor dat VNF's optimaal worden toegewezen aan bronnen op dezelfde NUMA-node om de latentie te minimaliseren en de prestaties te maximaliseren.
SR-IOV NIC's zijn NUMA-lokaal:
Beperking van de Single-NUMA-modus:
De CPNR VNF vereist toegang tot:
In deze implementatie vereist de CPNR VNF toegang tot SR-IOV NIC's van zowel NUMA 0 (sriov0) als NUMA 1 (sriov1) om redundantie en hoge beschikbaarheid te bieden. Om dit te bereiken:
Conntrack is een Linuxkernelfunctie die wordt gebruikt om netwerkverbindingen te volgen, met name voor Network Address Translation (NAT) en firewallregels. Voor op OVS gebaseerde poorten in OpenStack wordt contrack gebruikt om de verbindingsstatus te beheren en de regels voor beveiligingsgroepen af te dwingen.
Contraktabel:
Standaardlimiet:
Gevolgen voor OVS-poorten:
Grootte van Contrasttabel vergroten:
sysctl net.netfilter.nf_conntrack_max
sysctl -w net.netfilter.nf_conntrack_max=262144
echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
Gebruik van Contrack controleren:
Contactstatistieken controleren:cat /proc/sys/net/netfilter/nf_conntrack_count
Regels voor beveiligingsgroepen optimaliseren:
Verminder het aantal regels dat wordt toegepast op OVS-poorten om de overhead van het netwerk tot een minimum te beperken.SR-IOV poorten omzeilen de OVS datapath en Linux kernel functies zoals contrack. Hiermee wordt de overhead voor het bijhouden van verbindingen volledig verwijderd.
In tegenstelling tot OVS-poorten, die beperkt zijn door de grootte van de aanmeldtabel (nf_conntrack_max), kunnen SR-IOV-poorten een vrijwel onbeperkt aantal verbindingen aan.
Door pakketverwerking te offloaden naar de NIC-hardware, elimineren SR-IOV-poorten de latentie die wordt geïntroduceerd door op software gebaseerde contactverwerking.
De Active-Backup-bindingsmodus is bijzonder geschikt voor deze implementatie vanwege de eenvoud, fouttolerantie en compatibiliteit met SR-IOV-interfaces. Dit is waarom:
De Active Backup-modus werkt onafhankelijk van de onderliggende switches of hardware. De failover-logica bevindt zich volledig in de Linux-kernel, waardoor deze zeer draagbaar en veelzijdig is.
SR-IOV VF's zijn gekoppeld aan specifieke fysieke NIC's en NUMA-knooppunten. Door de Active-Backup-modus te gebruiken, kunt u VF's van verschillende NUMA-knooppunten combineren tot één logische bindingsinterface (bond0). Dit zorgt voor een hoge beschikbaarheid en maakt efficiënt gebruik van NUMA-middelen.
De Active-Backup-modus is een van de eenvoudigste en meest gebruikte modi in Linux-bonding. Het is ontworpen om een hoge beschikbaarheid te bieden door ervoor te zorgen dat het verkeer naadloos blijft stromen, zelfs als een van de gekoppelde interfaces uitvalt. Dit is een uitgebreide uitleg van hoe de Active-Backup-modus werkt, de belangrijkste kenmerken en voordelen.
Een bindingsinterface in Linux combineert twee of meer netwerkinterfaces in één logische interface. Deze logische interface, aangeduid als de binding (bijvoorbeeld bond0), wordt gebruikt om te voorzien:
In de Active-Backup-modus wordt slechts één interface (de zogenaamde actieve interface) op een gegeven moment gebruikt om verkeer te verzenden en te ontvangen. De andere interface(s) blijven in de stand-bymodus. Als de actieve interface uitvalt, wordt een van de standby-interfaces gepromoveerd naar de actieve status en wordt het verkeer automatisch omgeleid naar de nieuwe actieve interface.
Eén actieve interface:
Automatische failover:
Failback-ondersteuning:
Zodra de mislukte interface is hersteld, kan deze automatisch opnieuw actief worden (indien geconfigureerd om dit te doen) of in de stand-bymodus blijven, afhankelijk van de verbindingsconfiguratie.Geen eisen aan de Switch:
Monitoring:
de
parameter imimon
(Media Independent Interface Monitor).Actieve interface:
Monitoring:
Linkfout op actieve interface:
Als de actieve interface (eth2) uitvalt (bijvoorbeeld kabel losgekoppeld, NIC-hardwarefout of link down), detecteert de binding de fout onmiddellijk met behulp van minimale ARP-bewaking.Automatische failover:
Failover-tijdigheid:
Het failover-proces verloopt vrijwel onmiddellijk (meestal binnen enkele milliseconden, afhankelijk van het minimuminterval).Herstel van mislukte interface:
Verkeerscontinuïteit:
Failback is naadloos en zorgt ervoor dat de doorlopende verkeersstromen niet worden verstoord.De Active Backup-modus is bijzonder geschikt voor SR-IOV-interfaces omdat:
Voorbeeld:
De CPNR VNF vereist de volgende vier netwerken:
Stapsgewijze implementatie:
Orchestratienetwerk:
openstack network create --provider-network-type vxlan orchestration-network
Beheernetwerk:
openstack network create --provider-network-type vxlan management-network
Orchestratie-subnet:
openstack subnet create --network orchestration-network \
--subnet-range 192.168.100.0/24 orchestration-subnet
Subnet beheer:
openstack subnet create --network management-network \
--subnet-range 10.10.10.0/24 management-subnet
SR-IOV-netwerk 1:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov0 --provider-segment 101 sriov-network-1
SR-IOV-netwerk 2:
openstack network create --provider-network-type vlan \
--provider-physical-network sriov1 --provider-segment 102 sriov-network-2
Om ervoor te zorgen dat de VNF toegang heeft tot SR-IOV NIC's van beide NUMA-knooppunten, kunt u een smaak creëren met cross-NUMA-ondersteuning:
openstack flavor create --ram 8192 --vcpus 4 --disk 40 cross-numa-flavor
NUMA-specifieke eigenschappen instellen:
openstack flavor set cross-numa-flavor \
--property hw:numa_nodes=2 \
--property hw:cpu_policy=dedicated \
--property hw:mem_page_size=large
Nadat u de VNF hebt gestart, configureert u de bindingsinterface voor SR-IOV-poorten (eth2 en eth3) op de VNF.
Maak een bond-interface (bond0) in de Active-Backup-modus:
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
Start de netwerkservice opnieuw op om de configuratie toe te passen:
systemctl restart network
Controleer na het implementeren van de VNF de functionaliteit met behulp van de volgende stappen:
Controleer of de VNF-instantie actief is:
openstack server show cpnr-instance
Zorg ervoor dat de status ACTIEF is.
Ping Test: Controleer of de VNF over alle netwerken kan communiceren:
ping
ping
Bond-interface:
Bevestig dat bond0 actief is:
cat /proc/net/bonding/bond0
Zoeken naar:
Zorg ervoor dat de VNF middelen gebruikt van beide NUMA-knooppunten:
nova show --human | grep numa
Controle en probleemoplossing: gebruik tools zoals cpdumpandethtool om de SR-IOV-interfaces te bewaken.
Beveiliging: Beheer de toegang tot het fysieke netwerk zorgvuldig en handhaaf strikte isolatie tussen huurders.
Schaalvergroting: plan fysieke NIC-capaciteit bij het schalen van SR-IOV-implementaties, aangezien het aantal beschikbare VF's wordt beperkt door de NIC-hardware.
Als de implementatie niet werkt zoals verwacht, raadpleegt u de volgende stappen voor probleemoplossing:
dmesg | grep -i "SR-IOV"
lspci | grep Ethernet
Als de VNF geen toegang heeft tot beide NIC's, moet u ervoor zorgen dat de modus voor cross-NUMA is ingeschakeld:
openstack flavor show cross-numa-flavor
cat /proc/net/bonding/bond0
systemctl restart network
openstack port list --server cpnr-instance
ip addr show
Voor de implementatie van CPNR VNF op OpenStack met SR-IOV-poorten is cross-NUMA-modus vereist om de VNF in staat te stellen verbinding te maken met NIC's van beide NUMA-knooppunten. Dit is van essentieel belang omdat OpenStack VNF's in single-NUMA-modus beperkt tot alleen toegang tot bronnen (NIC's, CPU's, geheugen) binnen de NUMA-node waar de VNF wordt gestart. De combinatie van de cross-NUMA-modus met Active Backup-binding zorgt voor hoge beschikbaarheid, fouttolerantie en efficiënt gebruik van bronnen, waardoor deze implementatie zeer veerkrachtig en krachtig is.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
10-Jul-2025
|
Eerste vrijgave |