Pemantauan
Tidak ada error upstream yang sehat saat mengakses dasbor Grafana setelah perangkat di-reboot
Versi: 1.0
Gejala: UI Grafana tidak dapat dijangkau setelah mematikan perangkat. Masalah ini terjadi saat CPU kelebihan beban di pod Cortex.
Solusi:
Jeda rekonsiliasi subkomponen untuk
mon-cortexdi management plane: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=trueHapus pod cortex yang ada dengan mengurangi jumlah replika menjadi 0 di bidang kontrol. Tindakan ini diperlukan karena jika pod
cortex-1dalam kondisi buruk, pod akan terus berada dalam kondisi tersebut dan tidak dimulai ulang. Untuk memulai ulang pod, kurangi jumlah replika menjadi 0:kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfigTingkatkan jumlah replika Cortex menjadi 7.
kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
No healthy upstream error akan hilang.
Penyimpanan
VM OTS tidak dimulai ulang secara otomatis setelah dimatikan secara tidak benar
Versi: 1.0.x
Gejala: Setelah penonaktifan yang tidak benar seperti hilangnya daya, VM OTS mungkin tidak dimulai ulang secara otomatis saat dimulai ulang. Buka bm01 dan bm02, lalu periksa status VM:
[root@aa-ah-bm01 ~]# virsh list --all
Id Name State
----------------------------------
- aa-ah-stge01-01 shut off
Periksa lsblk. Jika tampilannya seperti ini:
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
lalu lakukan cat /proc/mdstat. Jika array raid5 dalam mode active (auto-read-only),
hal ini disebabkan oleh penonaktifan yang tidak benar atau kehilangan daya. mdadm mendeteksi bahwa superblok array menunjukkan penulisan yang tidak lengkap atau array tidak dihentikan dengan benar. Untuk memastikan integritas data, tanda ini menandai array sebagai
resync=PENDING dan sering kali memunculkannya dalam mode auto-read-only.
Solusi:
Mulai sinkronisasi ulang dan pemulihan RAID:
sudo mdadm --readwrite /dev/NAMEGanti NAME dengan nama perangkat RAID, seperti
md127. Pastikan array raid5 dalam modeactive:[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>Periksa konfigurasi LUKS dalam file
/etc/crypttab, yang terlihat seperti contoh ini: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,discardFile ini berisi lokasi file kunci untuk
luksrd5danluksnvram.Dapatkan nama udev raid5:
cd /dev/md ls | grep rd5Dapatkan nama udev nvram:
NVRAM=$(blkid -o device | while read -r device; do if blkid "$device" | grep -q 'PARTLABEL=".*OTS.*"'; then echo "$device" break fi done) echo $NVRAMBuka perangkat LUKS bernama
luksrd5danluksnvram, yang digunakan oleh OTS:cryptsetup luksOpen /dev/md/<raid5 udev name> luksrd5 --key-file <luksrd5 keyfile> cryptsetup luksOpen /dev/<nvram udev name> luksnvram --key-file <luksnvram keyfile>Perintah
lsblkmencetak sesuatu seperti contoh berikut:[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 cryptMemulai 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 runningUlangi langkah-langkah di
bm01danbm02. Tunggu beberapa menit, lalu login ke cluster OTS dan pastikan cluster tersebut dalam kondisi baik: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.