Introduction
Ce document décrit la procédure de dépannage des problèmes de haute disponibilité dans le gestionnaire de cluster CNDP (Cloud Native Deployment Platform).
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Infrastructure Cisco Subscriber Microservices (SMI)
- Architecture 5G CNDP ou SMI-Bare-metal (BM)
- DRBD (Distributed Replicated Block Device)
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- SMI 2020.02.2.35
- Kubernetes v1.21.0
- DRBD 8.9.10
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Qu'est-ce que SMI ?
Cisco SMI est une pile en couches de technologies et de normes cloud qui permettent l'utilisation d'applications basées sur les microservices à partir des unités commerciales Cisco Mobility, Cable et Broadband Network Gateway (BNG), qui ont toutes des fonctions de gestion des abonnés similaires et des exigences similaires en matière de data store.
Attributs :
- La pile de nuages de couches (technologies et normes) pour fournir des déploiements de haut en bas et pour s'adapter à l'infrastructure de nuage utilisateur actuelle.
- Environnement d'exécution commun partagé par toutes les applications pour les fonctions autres que les applications (stockage de données, déploiement, configuration, télémétrie, alarme). Cela garantit une interaction et une expérience cohérentes pour tous les points de contact et d'intégration des utilisateurs.
- Les applications et les environnements d'exécution communs sont déployés dans des conteneurs de microservices et connectés à un maillage de service intelligent.
- API exposée pour le déploiement, la configuration et la gestion, afin de permettre l'automatisation.
Qu'est-ce que SMI-BM ou CNDP ?
Cisco SMI-BM ou CNDP est une plate-forme sans système d'exploitation organisée qui fournit l'infrastructure nécessaire au déploiement des fonctions de réseau virtuel (VNF) et des fonctions natives du cloud (CNF), qui permettent aux unités commerciales Cisco Mobility, Cable et BNG.
Attributs :
- BM qui élimine les frais généraux liés à Virtualized Infrastructure Manager (VIM).
- Performances améliorées :
- Plus de coeurs pour l'application
- Exécution plus rapide des applications
- Workflow de déploiement automatisé, intégré à Network Services Orchestrator (NSO) Core Function Packet (CFP)
- Pile organisée pour déployer les fonctions réseau Cisco 5G (NF)
- Guide de commande et de déploiement simplifié
Qu'est-ce qu'un SMI Cluster Manager ?
Un gestionnaire de cluster est un système à deux noeuds keepalived cluster utilisé comme point initial pour le déploiement du cluster du plan de contrôle et du plan utilisateur. Il exécute un cluster Kubernetes à noeud unique et un ensemble de POD qui sont responsables de la configuration complète du cluster. Seul le gestionnaire de cluster principal est actif et le secondaire prend le relais uniquement en cas de panne ou arrêté manuellement pour maintenance.
Qu'est-ce que DRBD ?
Le DRBD est utilisé pour accroître la disponibilité des données. Il s'agit d'un composant logiciel open source basé sur Linux qui facilite le remplacement des systèmes de stockage partagés par un miroir en réseau. En bref, vous pouvez dire qu'il s'agit d'un « miroir Raid 1 basé sur le réseau pour les données ».
Problème
Le gestionnaire de cluster est hébergé dans un cluster à 2 noeuds avec DRBD (Distributed Replicated Block Device) et keepalived. La HA peut se briser et elle peut également passer à un état de scission cérébrale. Cette procédure permet de récupérer le cluster endommagé. L'état souhaité de la haute disponibilité du gestionnaire de cluster est le suivant : cluster manager1 (CM1) est primaire et cluster manager2 (CM2) est secondaire. Ici, CM1 est la victime du dédoublement du cerveau.
Procédure de maintenance
Connectez-vous au gestionnaire de cluster et vérifiez l'état du cluster DRBD.
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%
Dans ce scénario, CM2 est principal et le cluster est en mode autonome. CM1 est actuellement secondaire et wait for connection province.
Voici l'état correct du 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 –
Déplacez le VIP CM vers CM-1 de CM-2 et faites de CM-1 le principal (le VIP du gestionnaire de cluster est 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
Identifiez la ressource DRBD (partagée sur le réseau) :
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
Consultez le fichier de configuration DRBD pour obtenir les détails sur les ressources :
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;
Effectuez maintenant une restauration DRBD :
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
Début keepalived sur les deux MC. VRRP avec l'aide de keepalived sélectionne CM-1 comme principal, en fonction de la ressource principale connectée /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
Vérifiez l'état DRBD sur CM-1 et CM-2. Il doit maintenant être transformé en l'état de cluster correct.
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 est monté uniquement sur le noeud principal.
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
Commentaires