Supervisión
No se produjo ningún error de upstream en buen estado al acceder al panel de Grafana después de reiniciar el dispositivo
Versiones: 1.0
Síntomas: No se puede acceder a la IU de Grafana después de apagar el dispositivo. Este problema se produce cuando la CPU está sobrecargada en los Pods de Cortex.
Solución alternativa:
Pausa la conciliación del subcomponente para
mon-cortexen el plano de administració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=trueQuita los Pods de Cortex existentes disminuyendo el recuento de réplicas a 0 en el plano de control. Esta acción es necesaria porque, si un pod
cortex-1está en mal estado, permanece en ese estado y no se reinicia. Para reiniciar los Pods, disminuye el recuento de réplicas a 0:kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfigAumenta el recuento de réplicas de Cortex a 7.
kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
Desaparece el No healthy upstream error.
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 cierre incorrecto, como una pérdida de energía, es posible que la VM de OTS no se reinicie automáticamente después del reinicio. Ve a bm01 y bm02, y verifica el estado de la VM:
[root@aa-ah-bm01 ~]# virsh list --all
Id Name State
----------------------------------
- aa-ah-stge01-01 shut off
Verifica lsblk. Si se ve así:
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
luego, haz cat /proc/mdstat. Si el array raid5 está en modo active (auto-read-only), esto se debe a un apagado incorrecto o a una pérdida de energía. mdadm detecta que los superbloques del array indican una escritura incompleta o que el array no se detuvo correctamente. Para garantizar la integridad de los datos, marca el array como resync=PENDING y, a menudo, lo muestra en el modo auto-read-only.
Solución alternativa:
Inicia la recuperación y la resincronización de la incursión:
sudo mdadm --readwrite /dev/NAMEReemplaza NAME por el nombre del dispositivo RAID, como
md127. Asegúrate de que el array raid5 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>Verifica la configuración de LUKS en el archivo
/etc/crypttab, que se ve como 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 para
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 similar 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, accede al clúster de OTS y asegúrate de que 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.