Monitoraggio
Nessun errore upstream integro durante l'accesso alla dashboard Grafana dopo il riavvio del dispositivo
Versioni: 1.0
Sintomi: l'interfaccia utente di Grafana non è raggiungibile dopo lo spegnimento del dispositivo. Questo problema si verifica quando la CPU è sovraccarica nei pod Cortex.
Soluzione:
Metti in pausa la riconciliazione dei sottocomponenti per
mon-cortexnel piano di gestione:export SUBCOMPONENT_NAME=mon-cortex export SUBCOMPONENT_NAMESPACE=root kubectl annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" --kubeconfig=/root/release/root-admin/kube-admin-remote-kubeconfig lcm.private.gdc.goog/paused=trueRimuovi i pod Cortex esistenti diminuendo il conteggio delle repliche a 0 nel control plane. Questa azione è necessaria perché se un pod
cortex-1è in uno stato non corretto, rimane in questo stato e non viene riavviato. Per riavviare i pod, riduci il numero di repliche a 0:kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfigAumenta il conteggio delle repliche di Cortex a 7.
kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
No healthy upstream error scompare.
Archiviazione
La VM OTS non si riavvia automaticamente dopo l'arresto anomalo
Versioni: 1.0.x
Sintomi: dopo un arresto anomalo, ad esempio un'interruzione dell'alimentazione, la VM OTS potrebbe
non riavviarsi automaticamente al riavvio. Vai a bm01 e bm02 e controlla
lo stato della VM:
[root@aa-ah-bm01 ~]# virsh list --all
Id Name State
----------------------------------
- aa-ah-stge01-01 shut off
Controlla lsblk. Se ha un aspetto simile a questo:
nvme0n1 259:0 0 3.5T 0 disk
└─md127 9:127 0 10.5T 0 raid5
nvme3n1 259:1 0 3.5T 0 disk
└─md127 9:127 0 10.5T 0 raid5
nvme2n1 259:2 0 3.5T 0 disk
└─md127 9:127 0 10.5T 0 raid5
nvme1n1 259:3 0 3.5T 0 disk
└─md127 9:127 0 10.5T 0 raid5
poi esegui cat /proc/mdstat. Se l'array raid5 è in modalità active (auto-read-only),
ciò è dovuto all'arresto anomalo o all'interruzione dell'alimentazione. mdadm rileva che i
superblock dell'array indicano una scrittura incompleta o che l'array non è stato
arrestato correttamente. Per garantire l'integrità dei dati, contrassegna l'array come
resync=PENDING e spesso lo porta in modalità auto-read-only.
Soluzione:
Avvia la risincronizzazione e il ripristino del RAID:
sudo mdadm --readwrite /dev/NAMESostituisci NAME con il nome del dispositivo RAID, ad esempio
md127. Assicurati che l'array RAID5 sia in modalitàactive:[root@aa-ah-bm01 ~]# cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md126 : active raid1 nvme5n1[0] nvme4n1[1] 937692352 blocks super 1.0 [2/2] [UU] bitmap: 7/7 pages [28KB], 65536KB chunk md127 : active raid5 nvme3n1[2] nvme2n1[4] nvme1n1[1] nvme0n1[0] 11251817472 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/28 pages [0KB], 65536KB chunk unused devices: <none>Controlla la configurazione LUKS nel file
/etc/crypttab, che ha l'aspetto di questo esempio:luksroot UUID=45297124-672d-4c03-9805-de94b545e959 none luks,discard luksrd5 UUID=b10724fe-2b17-423c-8078-d62410738f8a /etc/luks/rd5.keyfile luks,discard luksnvram UUID=12694ec9-1d1c-41a3-af2e-8f5bbc1ddca4 /etc/luks/md126p73.keyfile luks,discardQuesto file contiene la posizione del file di chiavi per
luksrd5eluksnvram.Ottieni il nome udev di raid5:
cd /dev/md ls | grep rd5Ottieni il nome udev di nvram:
NVRAM=$(blkid -o device | while read -r device; do if blkid "$device" | grep -q 'PARTLABEL=".*OTS.*"'; then echo "$device" break fi done) echo $NVRAMApri i dispositivi LUKS denominati
luksrd5eluksnvram, utilizzati da OTS:cryptsetup luksOpen /dev/md/<raid5 udev name> luksrd5 --key-file <luksrd5 keyfile> cryptsetup luksOpen /dev/<nvram udev name> luksnvram --key-file <luksnvram keyfile>Il comando
lsblkstampa un output simile a questo esempio:[root@aa-ah-bm02 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 3.5T 0 disk └─md127 9:127 0 10.5T 0 raid5 └─luksrd5 253:9 0 10.5T 0 crypt ├─data_pool-aa--ah--stge01--1_sdotconfig.iso 253:10 0 4M 0 lvm ├─data_pool-aa--ah--stge01--1_coredisk 253:11 0 120G 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_1 253:12 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_2 253:13 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_root_1 253:14 0 68G 0 lvm └─data_pool-aa--ah--stge01--1_root_2 253:15 0 68G 0 lvm nvme1n1 259:1 0 3.5T 0 disk └─md127 9:127 0 10.5T 0 raid5 └─luksrd5 253:9 0 10.5T 0 crypt ├─data_pool-aa--ah--stge01--1_sdotconfig.iso 253:10 0 4M 0 lvm ├─data_pool-aa--ah--stge01--1_coredisk 253:11 0 120G 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_1 253:12 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_2 253:13 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_root_1 253:14 0 68G 0 lvm └─data_pool-aa--ah--stge01--1_root_2 253:15 0 68G 0 lvm nvme2n1 259:2 0 3.5T 0 disk └─md127 9:127 0 10.5T 0 raid5 └─luksrd5 253:9 0 10.5T 0 crypt ├─data_pool-aa--ah--stge01--1_sdotconfig.iso 253:10 0 4M 0 lvm ├─data_pool-aa--ah--stge01--1_coredisk 253:11 0 120G 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_1 253:12 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_2 253:13 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_root_1 253:14 0 68G 0 lvm └─data_pool-aa--ah--stge01--1_root_2 253:15 0 68G 0 lvm nvme3n1 259:3 0 3.5T 0 disk └─md127 9:127 0 10.5T 0 raid5 └─luksrd5 253:9 0 10.5T 0 crypt ├─data_pool-aa--ah--stge01--1_sdotconfig.iso 253:10 0 4M 0 lvm ├─data_pool-aa--ah--stge01--1_coredisk 253:11 0 120G 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_1 253:12 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_data_pool_2 253:13 0 5.1T 0 lvm ├─data_pool-aa--ah--stge01--1_root_1 253:14 0 68G 0 lvm └─data_pool-aa--ah--stge01--1_root_2 253:15 0 68G 0 lvm nvme4n1 259:4 0 894.3G 0 disk └─md126 9:126 0 894.3G 0 raid1 ├─md126p1 259:13 0 99M 0 md /boot/efi ├─md126p2 259:14 0 1000M 0 md /boot ├─md126p3 259:15 0 4M 0 md ├─md126p4 259:16 0 1M 0 md ├─md126p5 259:17 0 873.1G 0 md │ └─luksroot 253:0 0 873.1G 0 crypt │ ├─rocky-rl--root 253:1 0 190.1G 0 lvm / │ ├─rocky-rl--swap 253:2 0 2G 0 lvm │ ├─rocky-rl--tmp 253:3 0 17.5G 0 lvm /tmp │ ├─rocky-rl--var 253:4 0 523.9G 0 lvm /var │ ├─rocky-rl--home 253:5 0 17.5G 0 lvm /home │ ├─rocky-rl--var_tmp 253:6 0 17.5G 0 lvm /var/tmp │ ├─rocky-rl--var_log 253:7 0 87.3G 0 lvm /var/log │ └─rocky-rl--var_log_audit 253:8 0 17.5G 0 lvm /var/log/audit ├─md126p6 259:18 0 64.2M 0 md └─md126p73 259:19 0 20G 0 md └─luksnvram 253:16 0 20G 0 crypt nvme5n1 259:5 0 894.3G 0 disk └─md126 9:126 0 894.3G 0 raid1 ├─md126p1 259:13 0 99M 0 md /boot/efi ├─md126p2 259:14 0 1000M 0 md /boot ├─md126p3 259:15 0 4M 0 md ├─md126p4 259:16 0 1M 0 md ├─md126p5 259:17 0 873.1G 0 md │ └─luksroot 253:0 0 873.1G 0 crypt │ ├─rocky-rl--root 253:1 0 190.1G 0 lvm / │ ├─rocky-rl--swap 253:2 0 2G 0 lvm │ ├─rocky-rl--tmp 253:3 0 17.5G 0 lvm /tmp │ ├─rocky-rl--var 253:4 0 523.9G 0 lvm /var │ ├─rocky-rl--home 253:5 0 17.5G 0 lvm /home │ ├─rocky-rl--var_tmp 253:6 0 17.5G 0 lvm /var/tmp │ ├─rocky-rl--var_log 253:7 0 87.3G 0 lvm /var/log │ └─rocky-rl--var_log_audit 253:8 0 17.5G 0 lvm /var/log/audit ├─md126p6 259:18 0 64.2M 0 md └─md126p73 259:19 0 20G 0 md └─luksnvram 253:16 0 20G 0 cryptAvvia la VM:
[root@aa-ah-bm01 ~]# virsh start aa-ah-stge01-01 Domain 'aa-ah-stge01-01' started [root@aa-ah-bm01 ~]# virsh list --all Id Name State --------------------------------- 1 aa-ah-stge01-01 runningRipeti i passaggi sia in
bm01che inbm02. Attendi qualche minuto e accedi al cluster OTS e assicurati che sia integro:aa-ah-stge01::> cluster show Node Health Eligibility --------------------- ------- ------------ aa-ah-stge01-01 true true aa-ah-stge01-02 true true 2 entries were displayed. aa-ah-stge01::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- aa-ah-stge01-01 aa-ah-stge01- true Connected to aa-ah-stge01-02 02 aa-ah-stge01-02 aa-ah-stge01- true Connected to aa-ah-stge01-01 01 2 entries were displayed.