Supervisión
Error de upstream incorrecto al acceder al panel de control de Grafana después de reiniciar el dispositivo
Versiones: 1.0
Síntomas: no se puede acceder a la interfaz de Grafana después de apagar el dispositivo. Este problema se produce cuando la CPU está sobrecargada en los pods de Cortex.
Solución:
Pausa la conciliación de subcomponentes de
mon-cortexen el plano de gestión: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=trueElimina los pods de Cortex reduciendo el número de réplicas a 0 en el plano de control. Esta acción es necesaria porque, si un pod
cortex-1está en mal estado, sigue en ese estado y no se reinicia. Para reiniciar los pods, reduce el número de réplicas a 0:kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfigAumenta el número de réplicas de Cortex a 7.
kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
El No healthy upstream error desaparece.
Almacenamiento
La VM de OTS no se reinicia automáticamente después de un apagado incorrecto
Versiones: 1.0.x
Síntomas: Después de un apagado incorrecto, como un corte de corriente, es posible que la VM de OTS no se reinicie automáticamente al reiniciar. Ve a bm01 y bm02, y comprueba el estado de la VM:
[root@aa-ah-bm01 ~]# virsh list --all
Id Name State
----------------------------------
- aa-ah-stge01-01 shut off
Consulta lsblk. Si tiene un aspecto similar a este:
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
A continuación, haz cat /proc/mdstat. Si la matriz RAID 5 está en modo active (auto-read-only), se debe a un apagado incorrecto o a un corte de corriente. mdadm detecta que los superbloques de la matriz indican que la escritura está incompleta o que la matriz no se ha detenido correctamente. Para asegurar la integridad de los datos, marca la matriz como resync=PENDING y, a menudo, la muestra en modo auto-read-only.
Solución:
Inicia la resincronización y la recuperación de la RAID:
sudo mdadm --readwrite /dev/NAMESustituye NAME por el nombre del dispositivo RAID, como
md127. Asegúrate de que la matriz RAID 5 esté en modoactive:[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>Comprueba la configuración de LUKS en el archivo
/etc/crypttab, que tiene un aspecto similar al de este ejemplo: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,discardEste archivo contiene la ubicación del archivo de claves de
luksrd5yluksnvram.Obtén el nombre de udev de raid5:
cd /dev/md ls | grep rd5Obtén el nombre de udev de nvram:
NVRAM=$(blkid -o device | while read -r device; do if blkid "$device" | grep -q 'PARTLABEL=".*OTS.*"'; then echo "$device" break fi done) echo $NVRAMAbre los dispositivos LUKS llamados
luksrd5yluksnvram, que usa OTS:cryptsetup luksOpen /dev/md/<raid5 udev name> luksrd5 --key-file <luksrd5 keyfile> cryptsetup luksOpen /dev/<nvram udev name> luksnvram --key-file <luksnvram keyfile>El comando
lsblkimprime algo parecido a este ejemplo:[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 cryptInicia 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 runningRepite los pasos en
bm01ybm02. Espera unos minutos, inicia sesión en el clúster de OTS y comprueba que el clúster esté en buen estado: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.