Problemen oplossen met CNDP Cluster Manager HA en herstel

Downloadopties

  • PDF     (321.2 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (85.2 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (73.0 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:24 november 2022
Document-id:218437

Inclusief taalgebruik

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.

Over deze vertaling

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.

    Inleiding

    In dit document wordt de procedure beschreven voor het oplossen van problemen met hoge beschikbaarheid in de CNDP-clustermanager (Cloud Native Implementation Platform).

    Voorwaarden

    Vereisten

    Cisco raadt kennis van de volgende onderwerpen aan:

    • Cisco Subscriber Microservices infrastructuur (SMI)
    • 5G CNDP of SMI-Bare-metal (BM) architectuur
    • DRBD-apparaat (gedistribueerd gerepliceerd blokapparaat)

    Gebruikte componenten

    De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

    • 2020.02.2.35
    • Kubernetes v1.21.0
    • DRBD 8.9.10

    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

    Wat is SMI?

    Cisco SMI is een gelaagde stapel cloudtechnologieën en -standaarden die op microservices gebaseerde toepassingen mogelijk maken van Cisco Mobility, Cable en Broadband Network Gateway (BNG)-bedrijfseenheden - die allemaal dezelfde abonneebeheerfuncties en vergelijkbare datastorevereisten hebben.

    Kenmerken:

    • Layer Cloud Stack (technologieën en standaarden) om top-to-bottom implementaties te bieden en ook geschikt voor de huidige cloud-infrastructuur van gebruikers.
    • Gemeenschappelijke uitvoeringsomgeving gedeeld door alle toepassingen voor niet-toepassingsfuncties (gegevensopslag, implementatie, configureren, telemetrie, alarm). Dit biedt consistente interactie en ervaring voor alle aanraakpunten en integratiepunten.
    • Toepassingen en gemeenschappelijke uitvoeringsomgevingen worden ingezet in microservice containers en verbonden met een intelligente service mesh.
    • Blootgestelde API voor implementatie, configuratie en beheer, om automatisering mogelijk te maken.

    Wat is SMI-BM of CNDP?

    Cisco SMI-BM of CNDP is een kaal-metaalplatform dat de infrastructuur biedt om Virtual Network Functions (VNF) en Cloud-Native Functions (CNF’s) te implementeren, waarmee bedrijfseenheden Cisco Mobility, Cable en BNG mogelijk worden gemaakt.

    Kenmerken:

    • IBM die de overhead in verband met Virtualized Infrastructure Manager (VIM) elimineert.
    • Verbeterde prestaties:
      • Meer kernen voor applicatie
      • Snellere uitvoering van toepassingen
    • Geautomatiseerde implementatieworkflow, geïntegreerd met Network Services Orchestrator (NSO) Core function Packet (CFP)
    • Gecureerde stack om Cisco 5G-netwerkfuncties (NF’s) te implementeren 
    • Vereenvoudigde bestelgids en implementatiegids

    Wat is een SMI Cluster Manager?

    Een clusterbeheerder is een knooppunt van 2 knooppunten keepalived cluster dat als uitgangspunt wordt gebruikt voor zowel de besturingsplane als de gebruikersplantaarnclusterimplementatie. Er wordt een Kubernetes-cluster met één knooppunt en een reeks POD's uitgevoerd die verantwoordelijk zijn voor de gehele clusterconfiguratie. Alleen de primaire clusterbeheerder is actief en de secundaire beheerder neemt alleen het beheer over in geval van een storing of wordt handmatig neergehaald voor onderhoud.

    Wat is DRBD?

    DRBD wordt gebruikt om de beschikbaarheid van gegevens te verhogen. Het is een op Linux gebaseerde open-source softwarecomponent die de vervanging van gedeelde opslagsystemen door een netwerkspiegel vergemakkelijkt. Kortom, je kunt zeggen dat dit een "Network-based Raid 1 spiegel voor de data" is.

    Probleem 

    De clusterbeheerder wordt gehost in een cluster met 2 knooppunten met DRBD (Distributed Replica Block Device) en keepalived. De HA kan breken en het kan ook in een split-brain toestand komen. Deze procedure helpt om de gebroken cluster te herstellen. De gewenste status van clustermanager HA is dat cluster manager1 (CM1) is primair en cluster manager2 (CM2) is secundair. Hier is CM1 het split-brain slachtoffer.

    Procedure voor het onderhoud

    Meld u aan bij de clusterbeheerder en controleer de status van het DRBD-cluster.

    cloud-user@pod-name-cm-1:~$ drbd-overview
     0:data/0  WFConnection Secondary/Unknown UpToDate/DUnknown 

    cloud-user@pod-name-cm-2:~$ drbd-overview
     0:data/0  StandAlone Primary/Unknown UpToDate/DUnknown /mnt/stateful_partition ext4 568G 147G 392G 28%

    In dit scenario is CM2 primair en bevindt het cluster zich in de stand-alone modus. CM1 is momenteel secundair wait for connection toestand.

    Hier is de juiste staat van het cluster:

    cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
    0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
    cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
    0:data/0 Connected Secondary/Primary UpToDate/UpToDate     Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary –

    Verplaats de CM VIP naar CM-1 van CM-2 en maak CM-1 primair (Cluster Manager VIP is 10.x.x.65 

    On CM-2 issue below command
    cloud-user@pod-name-cm-2:~$sudo systemctl restart keepalived 

    On CM-1 issue below command (Make sure that the VIP is now switched over to CM-1)
    cloud-user@pod-name-cm-1:~$ip a s | grep 10.x.x
    inet 10.x.x.70/26 brd 10.x.x.127 scope global vlan1xx         ----> here is the server IP
    inet 10.x.x.65/26 scope global secondary vlan1xx.                 ----> here is the VIP

    Identificeer de DRBD-bron (gedeeld via het netwerk):

    cloud-user@pod-name-deployer-cm-1:/$ cat /etc/fstab
    #/mnt/stateful_partition/data /data none defaults,bind 0 0 ---> /data is the resource
    #/mnt/stateful_partition/home /home none defaults,bind 0 0

    cloud-user@pod-name-deployer-cm-1:/$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 189G 0 189G 0% /dev
    tmpfs 38G 22M 38G 1% /run
    /dev/sda1 9.8G 3.5G 5.9G 37% /
    tmpfs 189G 0 189G 0% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 189G 0 189G 0% /sys/fs/cgroup
    /dev/sda4 71G 1.5G 66G 3% /tmp
    /dev/sda3 71G 11G 57G 16% /var/log
    /dev/drbd0 568G 365G 175G 68% /mnt/stateful_partition -->/dev/drbd0 is the device name
    tmpfs 38G 0 38G 0% /run/user/1000

    cloud-user@pod-name-deployer-cm-1:/$ lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    sda 8:0 0 744.1G 0 disk 
    ├─sda1 8:1 0 10G 0 part /
    ├─sda2 8:2 0 10G 0 part 
    ├─sda3 8:3 0 72.2G 0 part /var/log
    ├─sda4 8:4 0 72.2G 0 part /tmp
    ├─sda5 8:5 0 577.6G 0 part 
    │ └─drbd0 147:0 0 577.5G 0 disk /mnt/stateful_partition ---> /dev/sda5 is used to create drbd0

    Controleer het DRBD-configuratiebestand op de resourcedetails:

    cloud-user@pod-name-deployer-cm-1:/$ cat /etc/drbd.d/data.res 
    resource data {
    protocol C;  --->Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss

    ....
    ....

     device /dev/drbd0;
    disk /dev/disk/by-partlabel/smi-state; --> This translates to /dev/sda5
    meta-disk internal;
    floating 10.192.1.2:7789;
    floating 10.192.1.3:7789;

    Voer nu DRBD herstel uit:

    On CM-2

    cloud-user@pod-name-cm-2:~$ sudo systemctl stop keepalived              ---> stop to avoid VRRP VIP switchover
    cloud-user@pod-name-cm-2:~$ sudo drbdadm disconnect data ---> data is the cluster resource
    cloud-user@pod-name-cm-2:~$ sudo drbdadm secondary data                 ---> Make it secondary manually
    cloud-user@pod-name-cm-2:~$ sudo drbdadm connect --discard-my-data data ---> Force discard of all modifications on the split brain victim
    cloud-user@pod-name-cm-2:~$ drbd-overview status

    On CM-1:
    cloud-user@pod-name-cm-1:~$ sudo systemctl stop keepalived              ---> stop to avoid VRRP VIP switchover
    cloud-user@pod-name-cm-1:~$ sudo drbdadm connect data                   ---> Data will be connected as primary
    cloud-user@pod-name-cm-1:~$ drbd-overview status

    Starten keepalived op beide CM's. VRRP met behulp van keepalived selecteert CM-1 als primair, op basis van de aangesloten primaire bron /data:

    cloud-user@pod-name-cm-1:~$ sudo systemctl start keepalived 
    cloud-user@pod-name-cm-1:~$ sudo systemctl status keepalived 

    cloud-user@pod-name-cm-2:~$ sudo systemctl start keepalived 
    cloud-user@pod-name-cm-2:~$ sudo systemctl status keepalived 

    Controleer de DRBD-status op CM-1 en CM-2. Het moet nu in de juiste clusterstaat zijn getransformeerd.

    cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
    0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
    cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
    0:data/0 Connected Secondary/Primary UpToDate/UpToDate Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary

    /data alleen op het primaire knooppunt is gemonteerd.

    cloud-user@pod-name-deployer-cm-1:~$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 189G 0 189G 0% /dev
    tmpfs 38G 22M 38G 1% /run
    /dev/sda1 9.8G 3.5G 5.9G 37% /
    tmpfs 189G 0 189G 0% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 189G 0 189G 0% /sys/fs/cgroup
    /dev/sda4 71G 1.5G 66G 3% /tmp
    /dev/sda3 71G 11G 57G 16% /var/log
    /dev/drbd0 568G 364G 175G 68% /mnt/stateful_partition
    tmpfs 38G 0 38G 0% /run/user/1000


    cloud-user@pod-name-deployer-cm-secondary:~$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 189G 0 189G 0% /dev
    tmpfs 38G 2.3M 38G 1% /run
    /dev/sda1 9.8G 2.0G 7.3G 22% /
    tmpfs 189G 0 189G 0% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 189G 0 189G 0% /sys/fs/cgroup
    /dev/sda3 71G 9.3G 58G 14% /var/log
    /dev/sda4 71G 53M 67G 1% /tmp
    tmpfs 38G 0 38G 0% /run/user/1000

    Revisiegeschiedenis

    Revisie Publicatiedatum Opmerkingen
    1.0
    24-Nov-2022
    Eerste vrijgave
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Adithian Arathi
      Cisco Technical Leader
    • Krishna Kishore D V
      Cisco Technical Leader

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten