Implementeer DNS VNF met SRIOV-netwerk op Openstack CVIM - Configuratievoorbeeld voor Prime Network Registrar (DNS)

Inleiding

Dit document beschrijft de stapsgewijze implementatie van CPNR op OpenStack Cisco Virtualized Infrastructure Manager (CVIM) met behulp van SR-IOV en Active-Backup bonding.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Kennis van OpenStack en Single Root Input/Output Virtualization (SR-IOV) concepten
• Werkende kennis van Cisco Virtual Interface Manager (VIM) en Cisco Elastic Services Controller en Linux-opdrachten en netwerken

Gebruikte componenten

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.

Achtergrondinformatie

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 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 fysieke netwerkinterfacecontrollerbronnen (NIC's), waardoor de latentie wordt verminderd en de doorvoer wordt verhoogd.

Configuratie

Zorg ervoor dat aan deze voorwaarden is voldaan voordat u doorgaat met de implementatie.

1. Hardwarevereisten

• NIC's die geschikt zijn voor SR-IOV:
  • Ten minste twee voor SR-IOV geschikte fysieke NIC's met SR-IOV ingeschakeld in de BIOS/Unified Extensible Firmware Interface (UEFI).
  • Voorbeeld: sriov0 toegewezen aan knooppunt 0 voor niet-uniforme geheugentoegang (NUMA) en sriov1 toegewezen aan NUMA-knooppunt 1.

• NUMA-bewuste hosts:
  • Compute nodes moeten NUMA-architectuur ondersteunen.
  • NUMA-ondersteuning moet zijn ingeschakeld in het BIOS/UEFI van de host.

2. Intel NIC-kaarten identificeren

Intel XL710- en E810CQDA2-NIC-kaarten worden vaak gebruikt voor krachtige SR-IOV-netwerken. Ga als volgt te werk om het NIC-kaartmodel op de host te verifiëren:

Stap 1. LSPCI gebruiken, opdracht

Voer deze opdracht uit om een lijst op te stellen van apparaten met een PCI (Peripheral Component Interconnect) die gerelateerd zijn 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)

Stap 2. XL710 verifiëren

Als de NIC Intel XL710 is, ziet u de uitgang van de Ethernet Controller XL710.

Stap 3. E810CQDA2 verifiëren

Als de NIC Intel E810CQDA2 is, kunt u de Ethernet-controller E810-C in de uitvoer zien.

Stap 4. Ondersteuning voor stuurprogramma's bevestigen

Voer het volgende uit om het NIC-stuurprogramma te controleren:

ethtool -i <NIC_INTERFACE_NAME>

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.

3. BIOS/UEFI-configuratie

• SR-IOV inschakelen:

Zorg ervoor dat SR-IOV is ingeschakeld in het BIOS/UEFI van de server.

• Virtualisatietechnologie inschakelen voor gerichte I/O (VT-d)/AMD-Vi:

Intel VT-d of AMD-Vi moet ingeschakeld zijn voor PCI-doorvoer en SR-IOV-functionaliteit.

4. OpenStack instellen

• Core OpenStack-services:

Zorg ervoor dat OpenStack-services zoals Nova, Neutron, Glance en Keystone zijn geïnstalleerd en geconfigureerd.

• Neutronenconfiguratie:

Neutron moet zowel OpenSwitch (OVS) voor orkestratie-/beheernetwerken als SR-IOV voor applicatie-/servicenetwerken ondersteunen.

• SR-IOV-configuratie:

De compute nodes moeten zodanig zijn geconfigureerd dat ze SR-IOV ondersteunen, waarbij Virtual Functions (VF's) op de NIC's zijn gemaakt.

5. VNF-image van Cisco Prime Network Registrar (CPNR)

• Compatibiliteit met VNF-images:

De CPNR VNF-afbeelding moet SR-IOV-interfaces ondersteunen en de nodige stuurprogramma's bevatten.

• Uploaden naar Glance:

Zorg ervoor dat de CPNR VNF-afbeelding beschikbaar is in OpenStack Glance.

6. Administratieve toegang

• OpenStack CLI:

Zorg voor toegang tot de OpenStack CLI voor het maken van netwerken, smaken en het starten van de VNF.

• Hoofdmap- of beheerdersrechten:

Root- of beheerderstoegang om netwerken te configureren op de Linux-host en binnen de VNF.

Overzicht architectuur

VNF-netwerkinterfaceconnectiviteitsdiagram

stroomdiagram

SRIOV

voorbeeldconfiguraties

Hier is een voorbeeld van Cisco Elastic Services Controller (ESC) XML, waarin de implementatie van virtuele machines (VM) wordt aangetoond met behulp van SR-IOV-netwerken (met type>direct</type>) voor een tenant met de naam testtenant en een VM met de naam sriov-vm-1. Dit omvat meerdere interfaces, waaronder SR-IOV (directe) interfaces:

<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
    <tenants>
        <tenant>
            <name>test-tenant</name>
            <managed_resource>true</managed_resource>
            <vim_mapping>false</vim_mapping>
            <deployments>
                <deployment>
                    <name>sriov-vm-deployment</name>
                    <vm_group>
                        <name>sriov-vm-1-group</name>
                        <locator>
                            <vim_id>vim1</vim_id>
                            <vim_project>default</vim_project>
                        </locator>
                        <image>sriov-image</image>
                        <flavor>custom-flavor</flavor>
                        <bootup_time>300</bootup_time>
                        <recovery_wait_time>30</recovery_wait_time>
                        <recovery_policy>
                            <action_on_recovery>REBOOT_ONLY</action_on_recovery>
                        </recovery_policy>
                        <interfaces>
                            <!-- Management Interface -->
                            <interface>
                                <nicid>0</nicid>
                                <network>mgmt-net</network>
                                <ip_address>192.x.x.x</ip_address>
                            </interface>

                            <!-- SR-IOV Interface 1 -->
                            <interface>
                                <nicid>1</nicid>
                                <type>direct</type>
                                <network>sriov-net-1</network>
                                <addresses>
                                    <address>
                                        <address_id>0</address_id>
                                        <subnet>sriov-subnet-1</subnet>
                                        <ip_address>10.x.x.x</ip_address>
                                    </address>
                                </addresses>
                            </interface>

                            <!-- SR-IOV Interface 2 -->
                            <interface>
                                <nicid>2</nicid>
                                <type>direct</type>
                                <network>sriov-net-2</network>
                                <addresses>
                                    <address>
                                        <address_id>0</address_id>
                                        <subnet>sriov-subnet-2</subnet>
                                        <ip_address>10.y.y.y</ip_address>
                                    </address>
                                </addresses>
                            </interface>
                        </interfaces>
                        <scaling>
                            <min_active>1</min_active>
                            <max_active>1</max_active>
                            <elastic>false</elastic>
                        </scaling>
                        <config_data>
                            <configuration>
                                <dst>--user-data</dst>
                                <file>file://tmp/init/sriov-vm-1.cfg</file>
                            </configuration>
                        </config_data>
                    </vm_group>
                </deployment>
            </deployments>
        </tenant>
    </tenants>
</esc_datamodel>

Belangrijkste punten

• type>direct</type> onder <interface> maakt SR-IOV (PCI-doorvoer) voor die NIC mogelijk.

• Elke SR-IOV-interface heeft zijn eigen netwerk en subnet.

• U kunt IPv4/IPv6 koppelen in <adressen> indien nodig.

Voorbeeld van een 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 TEST1KEYAAAAB3NzaC1yc2EAAAADAQABAAACAQC7pf8gvOWH/Zv8iAlTv6LWEiPGA3B6t96G6LwTHF6iXOqQxyIUkg8IkqZ6wNwx6CQAjPK8cYBieO1yEHKjHyFTsZgpvdi4rVMP+Qsvab+J5RPPcJeKj7o8KIrtyyESXbLNcZv1uGwZ8nLZKfZQSJP04HUkRKoQJ/JoMvMurEKG/cJ1VtocV4AJiRHj+367D3uzrKd6eHYlM9oD+zpPeJ1P1J2TDPUp2K7GcKCrItn9blSGo/n/+gYBO793QjSdkmc/Ag4TEVhUfG17l0WlSvAw4L0csMlYBAGGqKAUEEx3BJGYNJ851bj23m6JBe83OVWGRWrDIIE+G14/tx8qYXDaFxFUFPb2zj+gmDXq80hYpv++/yFtTocbw== cpnrtest@Testescx01co
 - ssh-rsa TEST2KEYAAAAB3NzaC1yc2EAAAADAQABAAACAQDAmkQGCZUrYqkZ0C0J9t7mF9La9zYOqfzzFkk1wWtPga+aANOaFgjqbjj+VlBdi5QZtbzc31aLNlUPpR21BptS4GSfbKJaMOaDUClfe8rGk+9GCgm6wnZiT+SMa4/wEA9NILlwobrwHxVsb/kFlFKXg0aPkdvmqWPNcd09vF50enrs0aXFsqCyl6CPMJpZtGAgckvX8iU2bCJkxzD9F4rAu2D/FNb8KG5cbw7uptiwB4yoek6Q36NyxHYYJyOGiV4oQJ02T9MRPkvjLf7ASx9HA25nG+J4CZXWkuV7XYX1N5DFvOg/kwA7xMPyNgTEkblTRpIcfXU2PCWYSZcn1vYmsazf2uVCY+mjfLcvi85c/1mLnUGikiovQ== test@Testescx01co
runcmd:
 - /usr/sbin/useradd Test1 -d /home/Test1 -s /bin/bash -g users; (/bin/echo changeme; /bin/echo changeme) | /usr/bin/passwd Test1
 - 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 CPNRDNSTEST

--===============2678395050260980330==

CPNR-VNF implementeren met SR-IOV-poorten en Active-Backup Bond-interface op OpenStack

CPNR is een vitale Virtual Network Function (VNF) die IP Address Management (IPAM), DHCP en Domain Name Server (DNS)-services biedt voor netwerken van bedrijven en serviceproviders. Het implementeren van CPNR als VNF in OpenStack vereist 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:

• De cross-NUMA-modus configureren, wat essentieel is voor toegang tot SR-IOV-NIC's vanaf meerdere NUMA-knooppunten.
• De Active Backup-verbinding instellen, waardoor hoge beschikbaarheid wordt gegarandeerd zonder dat configuraties aan de switch nodig zijn.
• OpenStack-netwerken, smaken en Glance configureren.
• IP-adresplanning, configuratie van Linux-netwerken met ifcfg-bestanden en implementatie van de VNF met Cisco ESC.

Belangrijkste kenmerken van de implementatie

1. Cross-NUMA-bewustzijn:

   • De CPNR VNF omvat NUMA-knooppunten voor toegang tot SR-IOV-NIC's (sriov0 op NUMA 0 en sriov1 op NUMA 1).
   • Cross-NUMA-modus is vereist omdat OpenStack in de single-NUMA-modus alleen een VNF toestaat verbinding te maken met NIC's die zich fysiek bevinden op dezelfde NUMA-node waar de VNF wordt gestart. Door de modus voor meerdere NUMA's in te schakelen, kan de VNF gebruikmaken van NIC's en bronnen van beide NUMA-knooppunten.
     
     

2. Actieve back-upbinding:

   • Er wordt een bond0-interface gemaakt met SR-IOV-NIC's (eth2 van sriov0 en eth3 van sriov1δ).
   • De actieve back-upmodus zorgt voor redundantie en fouttolerantie zonder dat configuraties aan de switch vereist zijn.
     
     

3. OpenStack-netwerken:

   • Orchestratie- en beheernetwerken: op OpenSwitch gebaseerd voor beheer en administratief verkeer.
   • Applicatie-/servicenetwerken: SR-IOV-gebaseerd voor high-performance verkeer.

Waarom Cross-NUMA-modus vereist is

1. NUMA-Aware Networking in OpenStack

NUMA is een geheugenarchitectuur waarbij elke CPU (en het lokale geheugen en apparaten) is gegroepeerd in een NUMA-knooppunt. In OpenStack zorgt NUMA-bewuste plaatsing ervoor dat VNF's optimaal worden toegewezen aan bronnen op dezelfde NUMA-node om latentie te minimaliseren en prestaties te maximaliseren.

• SR-IOV-NIC's zijn NUMA-lokaal:

  • Elke fysieke NIC is gekoppeld aan een specifieke NUMA-node. Voorbeeld:
    • sriov0 is verbonden met NUMA-knooppunt 0.
    • sriov1 is verbonden met NUMA-knooppunt 1.

• Beperking van de single-NUMA-modus:

  • Wanneer een VNF wordt gestart in de single-NUMA-modus, staat OpenStack alleen toe dat de VNF verbinding maakt met NIC's die lokaal zijn voor de NUMA-node waar de VNF wordt gestart. Dit betekent:
    • Als de VNF wordt gestart op NUMA 0, kan deze alleen verbinding maken met NIC's op sriov0.
    • Als de VNF wordt gestart op NUMA 1, kan deze alleen verbinding maken met NIC's op sriov1.

2. Waarom is de NUMA-modus nodig?

De CPNR VNF vereist toegang tot:

• Orchestratienetwerk (OpenSwitch, NUMA-agnostisch)
• Beheernetwerk (OpenSwitch, NUMA-agnostisch)
• SR-IOV-netwerk 1: Verbonden met sriov0 (NUMA-knooppunt 0)
• SR-IOV-netwerk 2: Verbonden met sriov1 (NUMA-knooppunt 1).

Bij 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:

• De VNF moet worden gestart in de cross-NUMA-modus, waarmee OpenStack CPU, geheugen en NIC's van meerdere NUMA-knooppunten kan toewijzen.
• Dit zorgt ervoor dat de VNF verbinding kan maken met NIC's op sriov0 en sriov1, waardoor het gebruik van beide SR-IOV-poorten in een Active-Backup-verbindingsconfiguratie mogelijk is.

Contrack-groottebeperking voor OVS-poorten

Wat is Contrack?

Contrack is een Linux-kernel-functie die wordt gebruikt om netwerkverbindingen te volgen, met name voor Network Address Translation (NAT) en firewallregels. Voor OVS-gebaseerde poorten in OpenStack wordt contrack gebruikt om de verbindingsstatus te beheren en beveiligingsgroepregels af te dwingen.

Hoe Contrack OVS-poorten beïnvloedt

1. conctracktabel:

   • Elke actieve verbinding verbruikt een vermelding in de conctracktabel.
   • De grootte van de conctracktabel wordt beperkt door de parameter nf_conctrack_max.
     
     

2. Standaardlimiet:

   • Standaard is de grootte van de conctracktabel 65536 items. Voor werkbelastingen met hoge verbindingssnelheden (bijvoorbeeld VNF's met veel gelijktijdige stromen) kan deze limiet snel worden uitgeput, wat resulteert in gevallen pakketten.
     
     

3. Impact op OVS-poorten:

   • Als de aansluittafel vol is, vallen nieuwe verbindingen weg, wat ernstige gevolgen kan hebben voor de VNF-prestaties.
   • Dit is met name relevant voor de Orchestration and Management-netwerken, die OVS-poorten gebruiken.

Hoe te Contrack beperkingen te beperken

1. De grootte van de conctrack-tabel vergroten:

   • De huidige limiet bekijken:
     
     

     sysctl net.netfilter.nf_conntrack_max
     

   • Verhoog de limiet:
     
     

     sysctl -w net.netfilter.nf_conntrack_max=262144
     

   • Maak de verandering blijvend:
     
     

     echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
     

2. Gebruik van monitor Contrack:

   Controleer de contractstatistieken:
   
   

   cat /proc/sys/net/netfilter/nf_conntrack_count
   

3. Beveiligingsgroepregels optimaliseren:

   Verminder het aantal regels dat wordt toegepast op OVS-poorten om de overheadkosten voor verbindingen tot een minimum te beperken.

Hoe SR-IOV problemen oplost

1. Elimineert Contrack afhankelijkheid

SR-IOV-poorten omzeilen de OVS-datapath en Linux-kernel-functies zoals conctrack. Hiermee wordt de overhead voor het volgen van verbindingen volledig verwijderd.

2. Hogere schaalbaarheid

In tegenstelling tot OVS-poorten, die beperkt zijn door de grootte van de conctracktabel (nf_contrack_max), kunnen SR-IOV-poorten een vrijwel onbeperkt aantal verbindingen aan.

3. Verminderde latentie

Door pakketverwerking te offloaden naar de NIC-hardware, elimineren SR-IOV-poorten de latentie die wordt geïntroduceerd door softwaregebaseerde contractverwerking.

Waarom Active-Backup Mode is gekozen voor SR-IOV-poorten op CPNR VM

De Active Backup-verbindingsmodus is bijzonder geschikt voor deze implementatie vanwege de eenvoud, fouttolerantie en compatibiliteit met SR-IOV-interfaces. Hier is waarom:

1. Redundantie zonder complexiteit

• Actieve back-upmodus: slechts één interface (de actieve interface) verzendt en ontvangt verkeer op een bepaald moment. De andere interface(s) blijven in de stand-bymodus.
• Als de actieve interface uitvalt (bijvoorbeeld als gevolg van een verbindingsfout of hardwareprobleem), switch de koppeling automatisch naar een stand-byinterface. Dit zorgt voor continue netwerkconnectiviteit zonder handmatige interventie.

2. Geen verbindingsaggregatiegroep (LAG) vereist

• In tegenstelling tot andere verbindingsmodi (bijvoorbeeld 802.3ad of balance-alb), vereist de Active-Backup-modus geen LACP (Link Aggregation Control Protocol) of configuraties aan de switch.
• Dit is vooral belangrijk voor SR-IOV-poorten, omdat SR-IOV-VF's doorgaans geen LACP- of LAG-configuraties ondersteunen.

3. Naadloze failover

• Failover is vrijwel onmiddellijk, met minimale verstoring van het verkeer.
• Wanneer de actieve interface uitvalt, bevordert de binding onmiddellijk een standby-interface naar de actieve status.

4. Onafhankelijkheid van hardware

De Active-Backup-modus werkt onafhankelijk van de onderliggende fysieke switches of hardware. De failover-logica bevindt zich volledig in de Linux-kernel, waardoor deze zeer draagbaar en veelzijdig is.

5. Geoptimaliseerd voor SR-IOV

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 een enkele logische bindingsinterface (bond0). Dit zorgt voor een hoge beschikbaarheid en een efficiënt gebruik van de NUMA-middelen.

Active-Backup-modus is een van de eenvoudigste en meest gebruikte modi in Linux-binding. 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.

Wat is een Linux Bond Interface?

Een bindingsinterface in Linux combineert twee of meer netwerkinterfaces tot één logische interface. Deze logische interface, aangeduid als de binding (bijvoorbeeld bond0), wordt gebruikt om:

• Redundantie: zorgen voor een hoge beschikbaarheid van netwerkconnectiviteit.
• Prestatieverbetering: In andere modi (bijvoorbeeld balance-rr of 802.3ad) kan het ook bandbreedte aggregeren.

Hoe werkt de actieve back-upmodus?

In de Active-Backup-modus wordt slechts één interface (de actieve interface genoemd) op een bepaald 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.

Belangrijkste kenmerken van de actieve back-upmodus

1. Eén actieve interface:

   • Op een gegeven moment is slechts één fysieke interface in de binding actief voor het verzenden en ontvangen van verkeer.
   • Standby-interfaces zijn volledig passief, tenzij er een failover optreedt.
     
     

2. Automatische failover:

   • Als de actieve interface uitvalt (bijvoorbeeld als gevolg van een hardwareprobleem, kabelonderbreking of koppelingsstoring), switch de koppeling automatisch naar een stand-byinterface.
   • Failover is naadloos en vereist geen handmatige interventie.
     
     

3. Failback-ondersteuning:

   Zodra de mislukte interface is hersteld, kan deze automatisch weer actief worden (indien geconfigureerd om dit te doen) of in de standby-modus blijven, afhankelijk van de verbindingsconfiguratie.
   
   

4. Geen eisen aan de Switch:

   • In tegenstelling tot andere verbindingsmodi (bijvoorbeeld 802.3ad of balance-rr) vereist de Active-Backup-modus geen speciale configuratie op de fysieke switches (bijvoorbeeld LAG of LACP).
   • Dit maakt het ideaal voor scenario's waarbij configuratie aan de switch niet mogelijk is of wanneer SR-IOV-virtualfuncties worden gekoppeld, die geen ondersteuning bieden voor LAG.
     
     

5. Monitoring:

   • De bond bewaakt continu de gezondheid van alle lidinterfaces met behulp van de miimon (Media Independent Interface Monitor) parameter.
   • Als er een link-storing wordt gedetecteerd, switch de band onmiddellijk naar een gezonde stand-by-interface.

Hoe verkeer stroomt in de actieve back-upmodus

normale werking

1. Actieve interface:

   • Verkeer stroomt uitsluitend door de actieve interface (bijvoorbeeld eth2 in een binding van eth2 en eth3).
   • De standby-interface (eth3) blijft inactief en verzendt of ontvangt geen verkeer.
     
     

2. Monitoring:

   • De bond controleert periodiek de status van alle lidinterfaces. Dit wordt gedaan met behulp van:
     • miimon: controleert de verbindingsstatus van elke interface met een configureerbaar interval (bijvoorbeeld elke 100 ms).
     • Controle van adresresolutie protocol (ARP) (optioneel): verzendt ARP-verzoeken om ervoor te zorgen dat de actieve interface bereikbaar is.

failoverscenario

1. Koppelingsfout op actieve interface:

   Als de actieve interface (eth2) uitvalt (bijvoorbeeld kabel losgekoppeld, NIC-hardwarefout of koppeling naar beneden), detecteert de binding de storing onmiddellijk met behulp van minimon- of ARP-bewaking.
   
   

2. Automatische failover:

   • De switches worden gekoppeld aan de stand-byinterface (eth3), die de nieuwe actieve interface wordt.
   • Verkeer wordt omgeleid via de nieuwe actieve interface zonder handmatige tussenkomst.
     
     

3. Tijdigheid failover:

   Het failoverproces is vrijwel onmiddellijk (meestal binnen een paar milliseconden, afhankelijk van het minimale interval).

Failback-scenario

1. Herstel van mislukte interface:

   • Wanneer de eerder mislukte interface (eth2) wordt hersteld, kan deze:
     • Reclaim de actieve rol automatisch terug (indien geconfigureerd).
     • Blijf in de standby-modus (standaardgedrag).
       
       

2. Verkeerscontinuïteit:

   Failback is naadloos en zorgt ervoor dat de doorlopende verkeersstromen niet worden verstoord.

Use Case: Active-Backup Bonding met SR-IOV-poorten

De Active-Backup-modus is bijzonder geschikt voor SR-IOV-interfaces omdat:

• SR-IOV VF's ondersteunen doorgaans geen verbindingsaggregatieprotocollen zoals LACP.
• De binding in de Active-Backup-modus kan redundantie bieden zonder configuratie aan de switch.

Voorbeeld:

• eth2 wordt toegewezen aan een SR-IOV VF op sriov0 (NUMA-knooppunt 0).
• eth3 wordt in kaart gebracht met een SR-IOV VF op sriov1 (NUMA-knooppunt 1).
• De binding (bond0) combineert deze interfaces en zorgt voor naadloze failover tussen SR-IOV VF's.

Stap 1. OpenStack-netwerken

De CPNR VNF vereist de volgende vier netwerken:

1. Orchestratienetwerk: voor controle- en orkestratieverkeer (op basis van Openvswitch).
2. Netwerkbeheer: voor administratieve toegang (op OpenSwitch gebaseerd).
3. SR-IOV-netwerk 1: Toepassings-/serviceverkeer op sriov0.
4. SR-IOV-netwerk 2: Toepassings-/serviceverkeer op sriov1.

Dit is de stap-voor-stap implementatie:

Stap 1.1. OpenSwitch-netwerken maken

• Orchestratienetwerk:
  
  

  openstack network create --provider-network-type vxlan orchestration-network

• Beheernetwerk:
  
  

  openstack network create --provider-network-type vxlan management-network

Stap 1.2. Subnetten voor OpenSwitch-netwerken maken

• Subnet orkestratie:
  
  

  openstack subnet create --network orchestration-network \
  --subnet-range 192.xx.xx.0/24 orchestration-subnet

• Subnet beheer:
  
  

  openstack subnet create --network management-network \
  --subnet-range 10.x.x.0/24 management-subnet

Stap 1.3. SR-IOV-netwerken maken

• 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

Stap 2. OpenStack-smaken

Stap 2.1. Creëer een Cross-NUMA smaak

Om ervoor te zorgen dat de VNF toegang heeft tot SR-IOV-NIC's van beide NUMA-knooppunten, creëert u een smaak met cross-NUMA-ondersteuning:

openstack flavor create --ram 8192 --vcpus 4 --disk 40 cross-numa-flavor

Stap 2.2. NUMA-eigenschappen configureren

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

Stap 3. Verbinding configureren in actieve back-upmodus

Nadat u de VNF hebt gestart, configureert u de verbindingsinterface voor SR-IOV-poorten (eth2 en eth3) op de VNF.

Stap 3.1. Bond-interfaceconfiguratie

Maak een verbindingsinterface (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.xx.xx.10
NETMASK=255.xx.xx.0
GATEWAY=172.xx.xx.1

Stap 3.2. Slave-interfaces configureren

• 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

Stap 3.3. Configuratie toepassen

Start de netwerkservice opnieuw om de configuratie toe te passen:

systemctl restart network

Verifiëren

Controleer na het implementeren van de VNF de functionaliteit met behulp van de volgende stappen:

1. VNF-status controleren

Controleer of de VNF-instantie actief is:

openstack server show cpnr-instance

Zorg ervoor dat de status ACTIEF is.

2. Controleer de netwerkconnectiviteit

• Pingtest: controleer of de VNF via alle netwerken kan communiceren:

ping <IP_ADDRESS_OF_ORCHESTRATION_NETWORK>
ping <IP_ADDRESS_OF_MANAGEMENT_NETWORK>

• Bond-interface:

  • Bevestig dat bond0 actief is:
    
    

    cat /proc/net/bonding/bond0
    

    Zoeken naar:

    • Actieve slaaf: Geeft de actieve interface aan.
    • Slave Interface: Bevestigt dat zowel eth2 als eth3 deel uitmaken van de obligatie.
      
      

3. Controleer NUMA-plaatsing

Zorg ervoor dat de VNF middelen van beide NUMA-knooppunten gebruikt:

nova show <INSTANCE_ID> --human | grep numa

best practices

• Controle en probleemoplossing: gebruik hulpmiddelen zoals tcpdump en ethtool om de SR-IOV-interfaces te bewaken.

• Beveiliging: Beheer de toegang tot het fysieke netwerk zorgvuldig en zorg voor een strikte isolatie tussen huurders.

• Schalen: plan voor fysieke NIC-capaciteit bij het schalen van SR-IOV-implementaties, omdat het aantal beschikbare VF's wordt beperkt door de NIC-hardware.

Problemen oplossen

Als de implementatie niet werkt zoals verwacht, raadpleegt u de volgende stappen voor probleemoplossing:

1. Controleer de SR-IOV-configuratie

• Controleer of SR-IOV is ingeschakeld in het BIOS:
  
  

  dmesg | grep -i "SR-IOV"
  

• Bevestig dat er VF's zijn gemaakt op NIC's:
  
  

  lspci | grep Ethernet
  

2. Controleer NUMA-plaatsing

Als de VNF geen toegang heeft tot beide NIC's, zorg er dan voor dat de cross-NUMA-modus is ingeschakeld:

• Controleer de NUMA-eigenschappen van de smaak:
  
  

  openstack flavor show cross-numa-flavor
  

3. Uitgiften van obligatie-interfaces

• Controleer de obligatiestatus:
  
  

  cat /proc/net/bonding/bond0
  

• Als de obligatie niet functioneert:
  • Zorg ervoor dat de slave-interfaces (eth2 en eth3) correct zijn geconfigureerd als onderdeel van de binding.
  • Start de netwerkservice opnieuw op:
    
    

    systemctl restart network
    

4. Problemen met netwerkconnectiviteit

• Controleer de OpenStack-poortbindingen:
  
  

  openstack port list --server cpnr-instance
  

• Controleer op de juiste IP-configuratie binnen de VNF:
  
  

  ip addr show
  

Conclusie

Voor het implementeren van CPNR VNF op OpenStack met SR-IOV-poorten is de 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 de 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 cross-NUMA-modus met Active-Backup-bonding zorgt voor hoge beschikbaarheid, fouttolerantie en efficiënt gebruik van bronnen, waardoor deze implementatie zeer veerkrachtig en krachtig is.