Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

Wat is SMI?

Wat is SMI-BM of CNDP?

Wat is een SMI Cluster Manager?

Wat is DRBD?

Probleem

Procedure voor het onderhoud

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