Bekannte Probleme mit Google Distributed Cloud mit Air Gap-Appliance 1.0.x

Monitoring

Kein Upstream-Fehler beim Zugriff auf das Grafana-Dashboard nach dem Neustart des Geräts

Versionen: 1.0

Symptome: Die Grafana-Benutzeroberfläche ist nach dem Herunterfahren des Geräts nicht mehr erreichbar. Dieses Problem tritt auf, wenn die CPU in den Cortex-Pods überlastet ist.

Problemumgehung:

  1. Pausieren Sie den Abgleich der Unterkomponenten für mon-cortex in der Steuerungsebene:

    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=true
    
  2. Entfernen Sie die vorhandenen Cortex-Pods, indem Sie die Replikatzahl in der Steuerungsebene auf 0 reduzieren. Diese Aktion ist erforderlich, da ein Pod cortex-1, der sich in einem fehlerhaften Zustand befindet, in diesem Zustand verbleibt und nicht neu gestartet wird. Wenn Sie die Pods neu starten möchten, reduzieren Sie die Replikatzahl auf 0:

    kubectl scale statefulset cortex --replicas=0 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
    
  3. Erhöhen Sie die Anzahl der Cortex-Replikate auf 7.

    kubectl scale statefulset cortex --replicas=7 -n mon-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig
    

Die No healthy upstream error verschwindet.

Speicher

OTS-VM wird nach einem unsauberen Herunterfahren nicht automatisch neu gestartet

Versionen: 1.0.x

Symptome: Nach einem nicht ordnungsgemäßen Herunterfahren, z. B. bei einem Stromausfall, wird die OTS-VM möglicherweise nicht automatisch neu gestartet. Rufen Sie sowohl bm01 als auch bm02 auf und prüfen Sie den VM-Status:

[root@aa-ah-bm01 ~]# virsh list --all
 Id   Name              State
----------------------------------
 -    aa-ah-stge01-01   shut off

Prüfen Sie lsblk. Wenn es so aussieht:

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

Führen Sie dann cat /proc/mdstat aus. Wenn sich das RAID5-Array im active (auto-read-only)-Modus befindet, liegt das am nicht ordnungsgemäßen Herunterfahren oder am Stromausfall. mdadm erkennt, dass die Superblöcke des Arrays auf einen unvollständigen Schreibvorgang hinweisen oder das Array nicht ordnungsgemäß beendet wurde. Um die Datenintegrität zu gewährleisten, wird das Array als resync=PENDING markiert und oft im auto-read-only-Modus hochgefahren.

Problemumgehung:

  1. Starten Sie die RAID-Resynchronisierung und ‑Wiederherstellung:

    sudo mdadm --readwrite /dev/NAME
    

    Ersetzen Sie NAME durch den Namen des RAID-Geräts, z. B. md127. Prüfen Sie, ob sich das RAID5-Array im Modus active befindet:

    [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>
    
  2. Prüfen Sie die LUKS-Konfiguration in der Datei /etc/crypttab, die so aussehen sollte:

    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,discard
    

    Diese Datei enthält den Speicherort der Schlüsseldatei für luksrd5 und luksnvram.

  3. Rufen Sie den udev-Namen für RAID 5 ab:

    cd /dev/md
    ls | grep rd5
    
  4. Rufen Sie den udev-Namen von NVRAM ab:

    NVRAM=$(blkid -o device | while read -r device; do
      if blkid "$device" | grep -q 'PARTLABEL=".*OTS.*"'; then
        echo "$device"
        break
      fi
    done)
    echo $NVRAM
    
  5. Öffnen Sie die LUKS-Geräte mit den Namen luksrd5 und luksnvram, die von OTS verwendet werden:

    cryptsetup luksOpen /dev/md/<raid5 udev name> luksrd5 --key-file <luksrd5 keyfile>
    cryptsetup luksOpen /dev/<nvram udev name> luksnvram --key-file <luksnvram keyfile>
    
  6. Der Befehl lsblk gibt etwa Folgendes aus:

    [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 crypt
    
  7. Starten Sie die 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   running
    
  8. Wiederholen Sie die Schritte sowohl in bm01 als auch in bm02. Warten Sie einige Minuten, melden Sie sich im OTS-Cluster an und prüfen Sie, ob der Cluster fehlerfrei ist:

    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.