Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Éteindre et rallumer l'appareil

Cette page explique comment arrêter et allumer l'appliance isolée Google Distributed Cloud (GDC). Par exemple, pour déplacer l'appareil vers un nouvel emplacement.

Vous pouvez utiliser l'appliance isolée GDC dans des emplacements opérationnels temporaires, où il est nécessaire d'arrêter l'appareil pour le transporter entre les emplacements. Vous devrez peut-être également restaurer l'appareil après une panne de courant, car il peut être alimenté par des générateurs dans des environnements difficiles.

Avant de commencer

Assurez-vous d'arrêter toutes les charges de travail avant de continuer. Google ne peut pas garantir ce qui se passera si des charges de travail sont actives lors d'un arrêt.

Prérequis

Vous pouvez exécuter ce runbook sur un ordinateur portable ou une station de travail connectée au réseau de l'appliance sous air gap Google Distributed Cloud (GDC). Vous pouvez également connecter un ordinateur portable ou une station de travail à un commutateur en suivant la procédure décrite dans Connecter l'appareil.
Assurez-vous d'avoir accès au fichier kubeconfig du cluster root-admin.
Définissez la variable d'environnement KUBECONFIG appropriée en exécutant export KUBECONFIG=PATH_TO_KUBECONFIG.
Assurez-vous de disposer de la clé et du certificat SSH.

Éteindre les lames

Obtenez des informations sur les nœuds en exécutant kubectl get nodes -A -o wide.

Mettez en pause la synchronisation BareMetalHost en exécutant la commande suivante pour tous les nœuds un par un. Remplacez NODE_NAME par les noms de nœuds obtenus à l'étape précédente :

kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwrite

Le résultat peut ressembler à cet exemple :

baremetalhost.metal3.io/**-**-bm01 annotated
baremetalhost.metal3.io/**-**-bm02 annotated
baremetalhost.metal3.io/**-**-bm03 annotated

Obtenez les identifiants ONTAP Select (OTS). Vous avez besoin de ces identifiants pour éteindre les nœuds OTS ultérieurement.

Exécutez la commande suivante pour identifier l'adresse IP de gestion OTS répertoriée dans la colonne MGMTIP (Management IP) :

 export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig

 kubectl get storagecluster -n gpc-system

Exécutez les commandes suivantes pour récupérer le mot de passe administrateur OTS :

 export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

 # Find the secret name
 SECRET_NAME=$(kubectl get secrets -n gpc-system -o name | grep 'ontap-.*-stge01-credential')

 # Decode the password from that secret
 OTS_PASSWORD=$(kubectl get $SECRET_NAME -n gpc-system -o jsonpath='{.data.netapp_password}' | base64 --decode)

 echo $OTS_PASSWORD

Enregistrez l'adresse IP et le mot de passe de gestion OTS.

Confinez tous les nœuds un par un :

kubectl cordon NODE_NAME

Le résultat peut ressembler à cet exemple :

node/**-**-bm01 cordoned
node/**-**-bm02 cordoned
node/**-**-bm03 cordoned

Éteignez les nœuds ONTAP Select (OTS).

Établissez une connexion SSH au cluster OTS à l'aide de l'adresse IP de gestion et du mot de passe administrateur que vous avez récupérés :

 ssh admin@<ots-management-ip>

Éteignez les nœuds OTS (VM). En voici un exemple :

 bn-aa-stge01::> cluster show
 Node                  Health  Eligibility
 --------------------- ------- ------------
 bn-aa-stge01-01       true    true
 bn-aa-stge01-02       true    true

 bn-aa-stge01::> set diag

 Warning: These diagnostic commands are for use by NetApp personnel only.
 Do you want to continue? {y|n}: y

 bn-aa-stge01::> system node halt -node *

Pour déterminer le nœud leader et les nœuds suiveurs etcd, exécutez cette étape un par un pour tous les nœuds :

Recherchez les adresses IP cibles pour SSH en notant les valeurs de la colonne INTERNAL-IP du résultat de kubectl get nodes -A -o wide. Établissez une connexion SSH :
```
ssh root@INTERNAL-IP
```

Pour déterminer si le nœud actuel est un leader ou un suiveur etcd, exécutez la commande suivante dans le terminal SSH :

ETCDCTL_API=3 etcdctl \
    --cacert /etc/kubernetes/pki/etcd/ca.crt \
    --cert /etc/kubernetes/pki/etcd/server.crt \
    --key /etc/kubernetes/pki/etcd/server.key \
    --write-out=table endpoint status

Faites attention au champ IS LEADER.

Le résultat peut ressembler à cet exemple pour le nœud leader etcd :

[root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
>      --cacert /etc/kubernetes/pki/etcd/ca.crt \
>      --cert /etc/kubernetes/pki/etcd/server.crt \
>      --key /etc/kubernetes/pki/etcd/server.key \
>      --write-out=table endpoint status
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
|    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ************** | **************** | 3.4.30-gke.1 |  162 MB |      true |      false |      3641 |   12957958 |           12957958 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

Le résultat peut ressembler à cet exemple pour les deux nœuds suiveurs etcd :

[root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
>      --cacert /etc/kubernetes/pki/etcd/ca.crt \
>      --cert /etc/kubernetes/pki/etcd/server.crt \
>      --key /etc/kubernetes/pki/etcd/server.key \
>      --write-out=table endpoint status
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
|    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ************** | **************** | 3.4.30-gke.1 |  163 MB |     false |      false |      3641 |   12957404 |           12957404 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

Notez l'état du leader et du suiveur etcd des nœuds.

Videz les deux nœuds suiveurs etcd. Ne videz pas le nœud leader etcd.

kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-eviction

Le résultat peut ressembler à ceci :

node/**-**-bm01 already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-krj2z, kube-system/etcd-defrag-xh469, kube-system/ipam-controller-manager-2f4dz, kube-system/istio-cni-node-cgqv4, kube-system/kube-proxy-5mwf2, kube-system/localpv-mn2jh, kube-system/metallb-speaker-6l7sv, mon-system/mon-node-exporter-backend-nd8mp, netapp-trident/netapp-trident-node-linux-rrlmd, obs-system/anthos-audit-logs-forwarder-tpfqv, obs-system/anthos-log-forwarder-npjh4, obs-system/kube-control-plane-metrics-proxy-wp8nh, obs-system/log-failure-detector-crbnv, obs-system/oplogs-forwarder-sqwvj, vm-system/macvtap-v9pgp, vm-system/virt-handler-86khx
pod/grafana-0 deleted
pod/capi-kubeadm-bootstrap-controller-manager-1.30.400-gke.136lvgtf deleted
pod/grafana-0 deleted
pod/grafana-proxy-server-86d8fc4758-mkc4f deleted
.
.
.

node/**-**-bm02 already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-v75jz, kube-system/etcd-defrag-t5jnc, kube-system/ipam-controller-manager-5958m, kube-system/istio-cni-node-ggv4c, kube-system/kube-proxy-r6x46, kube-system/localpv-g56xc, kube-system/metallb-speaker-tmw72, mon-system/mon-node-exporter-backend-9rs7k, netapp-trident/netapp-trident-node-linux-9jmfp, obs-system/anthos-audit-logs-forwarder-bwns9, obs-system/anthos-log-forwarder-lbskj, obs-system/kube-control-plane-metrics-proxy-grthl, obs-system/log-failure-detector-dzh4v, obs-system/oplogs-forwarder-vdn7z, vm-system/macvtap-mjwtc, vm-system/virt-handler-dlqvv
pod/vai-web-plugin-backend-5dfd6d6597-nxxgn
pod/vai-web-plugin-frontend-6b5468968b-mrr7g
pod/grafana-proxy-server-64b759fbf6-b8pl8
pod/iam-bundledidp-backend-0
.
.
.

Arrêtez progressivement les deux nœuds suiveurs etcd. Suivez l'étape suivante un par un pour les deux nœuds.
Désactivez NODE_NAME à l'aide d'iLO :
1. Récupérez le nom d'utilisateur pour iLO :
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode
```
2. Récupérez le mot de passe pour iLO :
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode
```
3. Récupérez l'adresse BMC-IP pour NODE_NAME à partir des valeurs de la colonne BMC-IP :
```
kubectl get servers -A
```
4. Accédez à l'adresse BMC-IP obtenue à l'étape précédente et connectez-vous en saisissant le nom d'utilisateur et le mot de passe obtenus.
5. Pointez sur le premier bouton de la ligne supérieure. Il devrait afficher Power: ON. Cliquez dessus. Un menu déroulant s'affiche. Cliquez sur le premier élément intitulé Momentary Press. La couleur du bouton passe du vert à l'orange, ce qui signifie que le nœud est en cours d'arrêt. Attendez que la couleur du bouton passe au jaune, indiquant que la machine est éteinte. Cela prendra quelques minutes.
Une fois les deux nœuds suiveurs etcd arrêtés, répétez l'étape 7 pour le nœud leader etcd.

Retirer les YubiKeys pour le transport

Si vous devez transporter le système une fois l'installation terminée, retirez les YubiKeys et transportez-les séparément. Assurez-vous de les étiqueter vous-même.

Allumer et connecter

En cas de perte de puissance inattendue, par exemple en cas d'arrêt forcé, l'appareil se rallume automatiquement. Dans ce cas, vous devez commencer à l'étape 7, en ignorant les étapes 1 à 6. Après une perte de puissance inattendue, vous pouvez perdre des données, même après le redémarrage.

Plan d'action

Insérez les YubiKeys dans chaque nœud.
Branchez la machine de l'appliance isolée GDC et appuyez sur le bouton d'alimentation du nœud **-**-bm03 pour démarrer le serveur médiateur OTS.
Une fois le nœud **-**-bm03 disponible, vérifiez que le serveur médiateur OTS est actif en vérifiant l'état des services du sous-système cible SCSI (SCST). Ce service doit afficher Active: active (running) :
```
sudo systemctl status scst.service
```
Appuyez sur le bouton d'alimentation des deux nœuds restants dans n'importe quel ordre.
Une fois les nœuds allumés, attendez quelques minutes que le plan de contrôle se connecte. kubectl peut se connecter au plan de contrôle en moins de 30 minutes.
Obtenez les noms des nœuds en exécutant kubectl get nodes -A.
Supprimez le confinement de chaque nœud pour activer la planification :
```
kubectl uncordon `NODE_NAME`
```

Reprenez la synchronisation des hôtes Bare Metal pour chaque nœud :

kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwrite

Vérifiez l'état des nœuds à l'aide de kubectl get nodes -A.

Si tous les nœuds sont à l'état Ready, attendez deux heures que le processus de rapprochement se termine. Le résultat peut ressembler à ceci :

NAME         STATUS     ROLES           AGE     VERSION
**-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm03   Ready      control-plane   4d13h   v1.30.6-gke.300

Dans ce cas, aucune autre action n'est nécessaire.

Sinon, si un ou plusieurs nœuds sont à l'état "NotReady", redémarrez certains services pour préparer le cluster. Le résultat peut ressembler à ceci :

NAME         STATUS     ROLES           AGE     VERSION
**-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm03   NotReady   control-plane   4d13h   v1.30.6-gke.300

Dans ce cas, notez le nom du nœud qui n'est pas prêt et passez aux étapes suivantes.

Établissez une connexion SSH au nœud NotReady. Les adresses IP cibles de SSH sont des valeurs de la colonne INTERNAL-IP du résultat de kubectl get nodes -A -o wide :
```
ssh root@INTERNAL-IP
```
Redémarrez les services containerd et kubelet sur le nœud NotReady. Les commandes suivantes doivent être exécutées sur les nœuds, pas sur l'ordinateur portable ou la station de travail du client connecté à l'appliance isolée Google Distributed Cloud (GDC) :
```
systemctl stop containerd
systemctl daemon-reload
systemctl restart containerd
systemctl stop kubelet
systemctl start kubelet
```

Pour vérifier l'état des services containerd et kubelet, exécutez les commandes suivantes sur le nœud NotReady :

systemctl status kubelet
systemctl status containerd