Monitorização
Nenhum erro upstream saudável ao aceder ao painel de controlo do Grafana após o reinício do dispositivo
Versões: 1.0
Sintomas: a IU do Grafana não está acessível após o encerramento do dispositivo. Este problema ocorre quando a CPU está sobrecarregada nos pods do Cortex.
Solução alternativa:
Pause a conciliação de subcomponentes para
mon-cortexno plano de gestão: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=trueRemova os pods do Cortex existentes diminuindo a contagem de réplicas para 0 no plano de controlo. Esta ação é necessária porque, se um pod
cortex-1estiver num estado incorreto, permanece nesse estado e não é reiniciado. Para reiniciar os pods, diminua o número de réplicas para 0:kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfigAumente a contagem de réplicas do Cortex para 7.
kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
O No healthy upstream error desaparece.
Armazenamento
A VM do OTS não é reiniciada automaticamente após um encerramento não elegante
Versões: 1.0.x
Sintomas: após um encerramento incorreto, como uma perda de energia, a VM do OTS pode não reiniciar automaticamente após o reinício. Aceda a bm01 e bm02 e verifique o estado da VM:
[root@aa-ah-bm01 ~]# virsh list --all
Id Name State
----------------------------------
- aa-ah-stge01-01 shut off
Verifique lsblk. Se tiver um aspeto semelhante 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
Em seguida, faça cat /proc/mdstat. Se a matriz RAID5 estiver no modo active (auto-read-only), isto deve-se ao encerramento incorreto ou à perda de energia. mdadm deteta que os superblocos da matriz indicam uma gravação incompleta ou que a matriz não foi
parada corretamente. Para garantir a integridade dos dados, marca a matriz como resync=PENDING e, muitas vezes, apresenta-a no modo auto-read-only.
Solução alternativa:
Inicie a ressincronização e a recuperação do RAID:
sudo mdadm --readwrite /dev/NAMESubstitua NAME pelo nome do dispositivo RAID, como
md127. Certifique-se de que a matriz RAID5 está no 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>Verifique a configuração do LUKS no ficheiro
/etc/crypttab, que se assemelha ao seguinte exemplo: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 ficheiro contém a localização do ficheiro de chave para
luksrd5eluksnvram.Obtenha o nome do udev do raid5:
cd /dev/md ls | grep rd5Obtenha o nome do udev do nvram:
NVRAM=$(blkid -o device | while read -r device; do if blkid "$device" | grep -q 'PARTLABEL=".*OTS.*"'; then echo "$device" break fi done) echo $NVRAMAbra os dispositivos LUKS denominados
luksrd5eluksnvram, que são usados pelo OTS:cryptsetup luksOpen /dev/md/<raid5 udev name> luksrd5 --key-file <luksrd5 keyfile> cryptsetup luksOpen /dev/<nvram udev name> luksnvram --key-file <luksnvram keyfile>O comando
lsblkimprime algo semelhante a este exemplo:[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 cryptInicie a 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 runningRepita os passos em
bm01ebm02. Aguarde alguns minutos e inicie sessão no cluster OTS. Em seguida, certifique-se de que o cluster está em bom 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.