15. Bootstrap du stockage d'objets

Durée estimée : 7 heures

Propriétaire du composant utilisable : OBJ

Profil de compétences : ingénieur de déploiement

Remarque : Toutes les configurations de Google Distributed Cloud (GDC) air-gapped ne sont pas fournies avec un système StorageGRID. Une instance Distributed Cloud avec StorageGRID comporte un rack contenant des appareils StorageGRID dont les numéros de modèle commencent par SG. Les appareils AFF ONTAP ne sont pas couverts dans cette section.

15.1. Configuration réseau requise

Reportez-vous à l'image suivante pour obtenir un schéma de câblage des SG1000 et SG6060 permettant de configurer les réseaux GRID, Admin et Client :

15.1.1. SG1000 du nœud d'administration

Vous devez disposer d'au moins deux nœuds d'administration dans SG1000.

Pour chaque nœud d'administrateur, vous devez disposer d'un total de quatre adresses IP, soit une adresse dans chacun des éléments suivants :

• Réseau BMC.
• Réseau administrateur.
• Réseau client.
• Grid Network.

Vous devez disposer de trois sous-réseaux pour les éléments suivants :

• Réseau administrateur.
• Réseau BMC.

Le réseau client et le réseau de grille, ainsi que chaque sous-réseau, doivent avoir un masque de sous-réseau d'au plus 30 bits.

15.1.2. Nœuds de stockage SG6060 et SG6000

Vous devez disposer d'au moins trois nœuds de stockage pour les modèles SG6060 et SG6000.

Pour chaque nœud de stockage, vous devez disposer d'un total de cinq adresses IP, une adresse pour chacun des éléments suivants :

• BMC Network(mgmt).
• Réseau d'administration(gestion).
• Grid Network.
• Réseau du contrôleur de stockage (gestion). Remarque : Le réseau du contrôleur de stockage doit comporter deux adresses IP.

Vous devez disposer de deux sous-réseaux pour chacun des éléments suivants :

• Réseau BMC.
• Réseau administrateur.
• Réseau de contrôleurs de stockage.
• Grid Network.

Le tableau suivant indique le nombre d'adresses IP pour les nœuds d'administration et de stockage :

Nombre d'adresses IP nécessaires	Réseau administrateur	Réseau client	Grid Network
Nœud d'administration	2	1	1
Nœud de stockage	4	0	1

Vous devez disposer des trois sous-réseaux suivants :

• Réseau administrateur.
• Réseau client.
• Grid Network.

Chaque sous-réseau doit avoir un masque de sous-réseau d'au plus 30 bits.

15.1.3. Détails du réseau

15.1.3.1. Réseau du plan de gestion Distributed Cloud :

Le réseau de gestion hors bande (OOB) du cloud distribué contient le réseau du contrôleur de gestion de la carte mère (BMC) du stockage d'objets et le réseau d'administration. Le réseau se connecte à mgmtsw.

Vous devez disposer de l'adresse IP BMC OOB sur chacun des éléments suivants :

• SG1000
• SG6000

Vous devez disposer de l'adresse IP de gestion hors bande sur chacun des éléments suivants :

• SG1000
• SG6000
• SG6060

15.1.3.2. Réseau du plan de données Distributed Cloud

Le réseau du plan de données comprend le LIF client StorageGRID (SG1000) d'objet externe et le réseau client dans NetApp.

Remarque : Si vous ne l'avez pas encore fait, suivez les instructions de la section Créer cellconfig pour regrouper les fichiers cellconfig générés dans un seul fichier.

• Suivez les étapes ci-dessous pour identifier SubnetClaim sur chacun des éléments suivants :

  • Point de terminaison de l'API S3 :
  1. Dans le fichier cellconfig, recherchez external-objectstorage-client-lif-subnet.
  2. Identifiez le SubnetClaim correspondant qui spécifie l'adresse IP CIDR/de passerelle attribuée.

  • Points de terminaison de l'appliance réseau SG1000 :

    1. Dans le fichier cellconfig, recherchez objectstorage-admin-nodes-lif-subnet.
    2. Identifiez le SubnetClaim correspondant qui spécifie l'adresse IP CIDR/de passerelle attribuée.

• Points de terminaison de l'appliance réseau de grille SG6060 :

  1. Dans le fichier cellconfig, recherchez objectstorage-storage-nodes-lif-subnet.
  2. Identifiez le SubnetClaim correspondant qui spécifie l'adresse IP CIDR/de passerelle attribuée.

15.2. Préparation

15.2.1. Recueillir des informations

Temps estimé : 5 à 10 minutes

Avant de poursuivre cette section, assurez-vous que l'amorçage et la configuration du réseau sont terminés pour l'instance Distributed Cloud, et que l'opérateur a accès au fichier cellconfig le plus précis ou le plus récent disponible, ou à l'amorçage.

15.2.1.1. Collecter des informations sur les périphériques de stockage

Les instances Distributed Cloud suivent une convention d'appellation fixe pour identifier les appareils dans les racks. Plus précisément, aux périphériques de stockage d'objets suivants :

• Nœud d'administration(SG1000) : <cell>-<rack>-objsadm[node-number]. Par exemple, af-ae-objsadm01 représente un nœud d'administrateur.
• Nœud du contrôleur de calcul du stockage (SG6000-CN) : <cell>-<rack>-objs[node-number]. Exemple : af-ae-objs01.
• Baie de contrôleur de stockage(E2860) : <cell>-<rack>-objs[node-number]-s1. Exemple : af-ae-objs01-s1
• Contrôleurs de nœuds de stockage(SG6060) : <cell>-<rack>-objs[node-number]-s1-[controller number]. Par exemple, af-ae-objs01-s1-01 et af-ae-objs01-s1-02.

15.2.1.2. Collecter les informations sur le réseau du plan de gestion

Lors de l'amorçage et de la configuration du réseau, l'opérateur doit créer un sous-réseau pour le plan de gestion. Le système de stockage d'objets nécessite les informations suivantes lors du processus d'amorçage :

1. Sous-réseau de gestion.
2. Adresse IP de la passerelle de gestion.
3. 16 adresses IP réservées dans le sous-réseau de gestion, deux adresses IP pour chaque nœud d'administration et quatre adresses IP pour chaque nœud de stockage.

Recherchez l'adresse IP de la passerelle de gestion à partir de SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. Les <cell> et <rack> sont identiques à ceux identifiés à l'étape "Collecter des informations sur les périphériques de stockage". Par exemple : af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Stockez la valeur de la commande dans MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Collecter des informations sur le réseau du plan de données

Avant de continuer, assurez-vous d'avoir provisionné trois sous-réseaux pour le système de stockage d'objets lors de l'amorçage et de la configuration du réseau.

Vérifiez si les sous-réseaux suivants existent :

• objectstorage-admin-nodes-lif-subnet
• objectstorage-storage-nodes-lif-subnet
• external-objectstorage-client-lif-subnet

Exécutez la commande suivante avec les noms des SubnetClaim :

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Le résultat suivant s'affiche :

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Vérifiez si les champs suivants sont présents :

1. VLAN
2. READY: True
3. VLANREADY: True

15.2.1.4. Collecter des informations sur les dépendances

Le système de stockage d'objets repose sur les services et l'infrastructure de base suivants dans Distributed Cloud :

• NTP
• Modules de sécurité matériels (HSM)
• DNS

15.2.1.5. Mettre à jour les champs À REMPLIR

Recherchez les valeurs TO-BE-FILLED dans le fichier obj-cellobj.yaml et mettez-les à jour.

Exécutez la commande suivante pour vous assurer que la valeur n'existe pas dans le fichier YAML :

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Réseau de gestion de la configuration via une connexion locale

Durée estimée : 30 à 45 minutes

Cette sous-section configure le réseau de gestion pour chaque nœud d'appliance StorageGRID. Une fois le réseau de gestion configuré, les nœuds StorageGRID sont accessibles depuis le programme d'amorçage à l'aide de l'adresse IP du réseau de gestion.

Suivez ces étapes pour tous les appareils ObjectStorage :

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

Pour amorcer les appareils StorageGRID, connectez-vous à chacun d'eux, y compris à deux nœuds d'administration et à trois nœuds de stockage, avec un chariot de crash sur le port 6 du réseau d'administration, puis accédez à https://169.254.0.1:8443 pour configurer les adresses IP d'administration sur le réseau de gestion.

1. Connectez un chariot d'urgence directement au port RJ-45 le plus à droite de l'appliance de services à l'aide d'un câble Ethernet. Les schémas suivants montrent le port 6 pour les nœuds d'administration et de stockage, à titre d'exemple :

   

   

2. Ouvrez un navigateur Web sur le chariot d'urgence.

3. Accédez à https://169.254.0.1:8443 sur chaque machine.

   Remarque : Si vous ne parvenez pas à accéder à la page d'accueil, essayez de modifier le masque de sous-réseau du chariot d'urgence sur 255.255.255.0, puis réessayez. Si vous ne parvenez toujours pas à y accéder via une connexion locale, configurez l'adresse IP du chariot de crash en tant que 169.254.0.2, puis réessayez.

4. Dans la barre de menu de l'outil StorageGRID Appliance Installer, cliquez sur Configure Networking > Link Configuration (Configurer la mise en réseau > Configuration des liens). Vérifiez si le réseau administrateur est activé.

   

5. Pour configurer l'adresse IP du réseau d'administration, sélectionnez Configurer le Mise en réseau > Configuration IP.

6. Faites défiler la page jusqu'à la section Admin Network (Réseau d'administration), puis dans IP Assignment (Attribution d'adresse IP), sélectionnez Static (Statique) et saisissez les adresses IP de gestion correspondantes, managementIP, pour le nœud. Vous trouverez l'adresse IP de gestion de chaque nœud dans le fichier obj-cellobj.yaml. Exemple :

   • ObjectStorageAdminNode (SG1000) :

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageAdminNode
     metadata:
       creationTimestamp: null
       name: af-ae-objsadm01
     spec:
       network:
         bmcIP: 10.251.188.11/24
         clientIP: 10.251.113.2/28
         dataIP: 10.1.0.66/26
         managementIP: 10.251.188.10/24
       siteName: objectstorage-site
     

   • ObjectStorageStorageNode (SG6000) :

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageStorageNode
     metadata:
       creationTimestamp: null
       name: af-ae-objs01
     spec:
       network:
         bmcIP: 10.251.243.34/24
         controllerAManagementIP: 10.251.243.35/24
         controllerBManagementIP: 10.251.243.36/24
         dataIP: 10.1.0.132/26
         managementIP: 10.251.243.33/24
       siteName: objectstorage-site
     

   Remarque : Configurez la mise en réseau uniquement pour le réseau d'administration. Vous n'avez pas besoin de configurer d'autres adresses IP.

   Définissez la passerelle sur MANAGEMENT_SWITCH_GATEWAY.

   L'exemple d'image suivant montre la configuration de af-ae-objs01 à l'aide de l'adresse IP de gestion allouée dans le fichier obj-cellobj.yaml :

   

7. Cliquez sur Enregistrer et vérifiez si l'adresse IP est mise à jour.

8. Pinguez l'adresse IP de gestion depuis le programme d'amorçage pour vous assurer qu'elle est accessible.

   1. Pinguez l'adresse IP de gestion depuis le programme d'amorçage pour vous assurer qu'elle est accessible.
   2. Une fois que tous les nœuds disposent d'une adresse IP sur le réseau d'administration, accédez à l'interface utilisateur graphique d'installation du nœud StorageGRID à l'aide de son adresse IP de gestion.

Dépannage :

Si un nœud n'est pas pingable :

1. Accédez à l'interface utilisateur d'installation du nœud StorageGRID à l'étape 3 précédente et vérifiez si des erreurs s'affichent dans une bannière de boîte de dialogue. Essayez de résoudre les erreurs. Contactez les ingénieurs si nécessaire.
2. Accédez à Configurer le réseau > Configuration IP. Vérifiez que la section "Admin Network" (Réseau d'administration) est correctement configurée avec l'adresse IP statique et la passerelle appropriées. Parfois, le nœud StorageGRID n'enregistre pas complètement la configuration du réseau de gestion après la confirmation.
3. Répétez les étapes 5 à 8 et vérifiez le réseau du nœud d'administration.

L'accès à l'interface utilisateur graphique d'installation des nœuds StorageGRID sur chaque nœud est nécessaire pour poursuivre l'installation du système de stockage d'objets.

15.2.3. Mettre à niveau StorageGRID

Durée estimée : 1 à 1,5 heure

Important : Vous devez vérifier la version sur chaque nœud de calcul du stockage d'objets. Cela inclut les nœuds d'administration (SG1000) et les nœuds de stockage (SG6060).

Remarque : Vous devez passer à la version d'installation spécifiée si la version actuelle de StorageGRID est supérieure à celle fournie.

Avant de mettre à niveau StorageGRID, vérifiez la version du logiciel StorageGRID. Accédez à Advanced > Upload StorageGRID Software (Avancé > Importer le logiciel StorageGRID). La version actuelle de StorageGRID s'affiche.

Vérifiez la version StorageGRID installée groupée :

gdcloud artifacts tree oci | grep object-storage/os

Le résultat ressemble à ce qui suit :

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

La version est taguée sur l'artefact, dans cet exemple, sous la forme 11.8.0 :

Stockez la valeur de la version dans SG_INSTALL_VERSION.

Vérifiez la version du micrologiciel StorageGRID fourni :

gdcloud artifacts tree oci | grep object-storage/firmware

Le résultat ressemble à ce qui suit :

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

La version est taguée sur l'artefact, dans cet exemple, sous la forme 3.8.1 :

Stockez la valeur de la version dans SG_FIRMWARE_VERSION.

Si la version du nœud n'est pas SG_INSTALL_VERSION, passez aux étapes suivantes pour mettre à niveau ou rétrograder la version installée de StorageGRID. Si la version actuelle est SG_INSTALL_VERSION, passez à la section Mettre à niveau SANtricity.

15.2.3.1. Mettre le micrologiciel à jour

Procédez comme suit pour tous les nœuds StorageGRID :

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

1. Récupérez l'image du micrologiciel à partir du bundle :

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz
   

   Le fichier est disponible dans storagegrid_firmware_install/.

2. Accédez au programme d'installation de l'appliance StorageGRID sur le nœud StorageGRID. Sélectionnez Advanced > Upgrade Firmware (Avancé > Mettre à niveau le micrologiciel). Importez l'image du micrologiciel storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 et la somme de contrôle storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 pour la version du micrologiciel sélectionnée. Une fois les fichiers importés, StorageGRID commence automatiquement à les valider. La validation prend généralement entre cinq et dix minutes.

   

3. Une fois que deux coches vertes s'affichent, cliquez sur Upgrade Inactive Partition (Mettre à niveau la partition inactive).

   

   Après avoir reçu le message Successfully updated the firmware on the inactive partition, assurez-vous que la partition inactive est bien la bonne version en consultant la section Firmware actuel.

   Cliquez deux fois sur Reboot (Redémarrer) et Swap Partitions (Inverser les partitions).

   Remarque : Pendant les processus de redémarrage et d'échange, vous risquez de perdre temporairement la connexion au nœud. Ce processus prend environ 20 à 30 minutes. Si vous ne perdez pas la connexion avec le nœud, vous devrez peut-être cliquer deux fois sur Redémarrer et Échanger les partitions pour vous assurer que la demande est transmise.

4. Une fois le nœud redémarré, répétez les étapes 1 et 2 pour mettre à niveau le micrologiciel de l'autre partition. La partition active est la version choisie, tandis que la partition inactive contient l'ancienne version.

   

15.2.3.2. Mettre à niveau le logiciel StorageGRID

Une fois le micrologiciel de tous les nœuds mis à niveau vers la version appropriée, mettez à niveau le logiciel vers la version sélectionnée sur les deux nœuds d'administration. Il n'est pas nécessaire de mettre à niveau les nœuds de stockage, car ils imitent et extraient le logiciel sur les nœuds d'administration.

Suivez ces instructions sur les nœuds d'administration pour SG1000 :

• af-ae-objsadm01
• af-ae-objsadm02

1. Récupérez l'image d'installation à partir du bundle :

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/os.tar.gz
   

   Les fichiers sont disponibles dans storagegrid_os_install/.

2. Accédez à Advanced > Upload StorageGRID Software (Avancé > Importer le logiciel StorageGRID). Cliquez sur Supprimer pour supprimer le logiciel actuel, puis importez le nouveau package logiciel storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb et la somme de contrôle correspondante storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5, comme indiqué :

   

3. Une fois le logiciel importé, assurez-vous qu'il a été mis à jour vers la version sélectionnée pour le nœud :

   

15.2.4. Mettre à niveau SANtricity

Durée estimée : 1 à 1,5 heure

Important : Vous devez vérifier la version sur chaque SANtricity de stockage d'objets.

Avant de mettre à niveau SANtricity, vérifiez la version du logiciel SANtricity. Accédez à l'interface utilisateur SANtricity, puis cliquez sur Support > UPGRADE CENTER > Begin Upgrade (Assistance > Centre de mise à niveau > Commencer la mise à niveau). La version actuelle de SANtricity s'affiche.

Vérifiez la version de SANtricity installée :

gdcloud artifacts tree oci | grep object-storage/santricity

Le résultat ressemble à ce qui suit :

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

La version est taguée sur l'artefact, dans cet exemple, sous la forme 11.70.5R1.

Stockez la valeur de la version dans SANTRICITY_OS_VERSION.

Si la version de SANtricity est inférieure à SANTRICITY_OS_VERSION, passez aux étapes suivantes pour mettre à niveau la version de l'OS SANtricity. Sinon, passez à Installation.

Important : Si votre version actuelle est antérieure à 11.70.5R1 et que votre version cible est postérieure à 11.70.5R1, vous devez d'abord effectuer une mise à niveau vers cette version.

15.2.4.1. Mettre à niveau SANtricity OS

Suivez ces instructions dans l'interface utilisateur SANtricity pour chaque nœud de stockage :

1. Récupérez l'image d'installation à partir du bundle :

   gdcloud artifacts extract oci santricity \
       --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION
   
   tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz
   

   Le fichier de mise à niveau est disponible dans santricity/SANTRICITY_OS_VERSION/.

2. Accédez à Support > UPGRADE CENTER (Assistance > Centre de mise à niveau). Cliquez sur Begin Upgrade (Lancer la mise à niveau) dans SANtricity OS Software upgrade (Mise à niveau du logiciel SANtricity OS). Sélectionnez le fichier logiciel SANtricity OS en cliquant sur Parcourir. Importez le nouveau package logiciel RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp comme indiqué :

   

3. Cliquez sur Démarrer, puis confirmez que vous souhaitez effectuer l'opération.

4. Une fois la mise à niveau terminée, vérifiez que la version a été mise à jour :

   

15.3. Installation

15.3.1. Créer des secrets

Durée estimée : 15 à 30 minutes

Pour obtenir des valeurs permettant de créer des secrets, utilisez le répertoire cellcfg :

1. Obtenez les noms des objectstoragestoragenodes :

   $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   

   Exemple de résultat :

   # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   ah-ac-objs01
   ah-ac-objs02
   ah-ac-objs03
   

2. Récupérez l'adresse IP du BMC pour le nœud de stockage :

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443
   

3. Connectez-vous au gestionnaire de système SANtricity à partir du lien figurant dans le résultat de la commande précédente. Si vous n'avez pas défini de mot de passe auparavant, créez-en un et connectez-vous :

   

   1. Si vous avez oublié le mot de passe SANtricity, réinitialisez-le via la console série StorageGRID E2860. Pour vous connecter au port série de la baie de disques E2860, les paramètres du terminal sont 115200 8N1.

4. Configurez les adresses du serveur NTP dans le gestionnaire de système SANtricity pour les deux contrôleurs :

   

   1. Récupérer les adresses des serveurs NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      

   2. Sélectionnez Hardware (Matériel) dans SANtricity System Manager.

   3. Si le graphique affiche les lecteurs, cliquez sur Afficher l'arrière de l'étagère. Le graphique change et affiche les contrôleurs au lieu des lecteurs.

   4. Cliquez sur la télécommande que vous souhaitez configurer. Le menu contextuel de la manette s'affiche.

   5. Sélectionnez Configurer le serveur NTP. La boîte de dialogue "Configurer le serveur NTP (Network Time Protocol)" s'ouvre.

   6. Sélectionnez Je souhaite activer NTP sur le contrôleur (A ou B). D'autres sélections s'affichent dans la boîte de dialogue.

   7. Sélectionnez Spécifier manuellement les adresses des serveurs NTP. Saisissez l'adresse du serveur NTP principal en utilisant l'une des adresses IP récupérées par la commande précédente.

   8. Cliquez sur Enregistrer.

5. Mettez à jour les secrets contenant les identifiants SANtricity pour chacun des nœuds de stockage dans le fichier cell.yaml. Si les secrets n'existent pas, ajoutez-les en suivant ce modèle :

   apiVersion: v1
   kind: Secret
   metadata:
     creationTimestamp: null
     name: <STORAGE_NODE_NAME>-santricity
     namespace: gpc-system
   stringData:
     password: 'PASSWORD'
     username: 'admin'
   type: Opaque
   

6. Créez les secrets pour chacun des nœuds de stockage listés à l'étape précédente :

   kubectl create secret generic \
      --namespace=gpc-system STORAGE_NODE_NAME-santricity \
      --from-literal=username=admin \
      --from-literal=password=PASSWORD
   

Validation :

1. Exécutez la commande suivante avec chaque nœud de stockage listé à l'étape précédente. Il affiche le nom d'utilisateur Santricity défini à l'étape précédente. Validez l'administrateur :

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
   

2. Exécutez la commande suivante avec chaque nœud de stockage listé à l'étape précédente. Il affiche le mot de passe Santricity :

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
   

3. Exécutez la commande suivante pour obtenir l'URL de l'interface utilisateur de gestion Santricity. Connectez-vous à Santricity à l'aide du nom d'utilisateur et du mot de passe suivants :

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
   

Dépannage :

Si les secrets ne sont pas trouvés lors de l'exécution de l'étape de validation 1 ou 2, exécutez à nouveau l'étape kubectl create secret.

Si vous ne parvenez pas à vous connecter à l'interface utilisateur de gestion Santricity :

1. Réinitialisez les identifiants administrateur via la console série StorageGRID E2860.
2. Suivez toutes les étapes précédentes, sauf la dernière.

3. Supprimez le secret Santricity existant de chaque nœud :

   kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
   

4. Effectuez la dernière étape pour recréer le secret Santricity.

15.3.2. Amorcer le stockage d'objets

Le processus d'amorçage d'Object Storage varie entre la première zone et les zones qui la rejoignent. Consultez la section correspondante à votre situation.

IMPORTANT : Avant de continuer, vérifiez que la zone d'ancrage a terminé l'amorçage de l'API globale.

15.3.2.1. Amorcer le stockage d'objets dans la première zone

Exécutez la commande suivante pour amorcer le stockage d'objets :

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

Remarque : Omettez l'indicateur --enable-objectstorage-hsm si l'environnement n'est pas amorcé avec un HSM.

Remarque : Si vous amorcez manuellement un environnement antérieur, vous pouvez rencontrer une erreur lorsque vous envoyez une CertificateSigningRequest à Kubernetes, supprimez la CertificateSigningRequest et essayez de la renvoyer. Dans ce cas, résolvez le problème en effectuant une rotation des certificats à partir du HSM. Pour effectuer la rotation, suivez les instructions de HSM Toil 0012, dans la section "Rotate KMIP certificates" (Faire pivoter les certificats KMIP).

15.3.2.2. Amorcer le stockage d'objets dans la zone de jonction

Dépannage :

1. Lorsque les commandes Google Cloud CLI expirent ou renvoient des erreurs, résolvez les problèmes renvoyés.
2. Consultez le pod gpc-system/obj-infra-cluster-cm-backend-controller de connexion pour en savoir plus sur l'erreur.

15.3.2.3. Amorcer le stockage d'objets dans la zone de jonction

Durée estimée : 30 à 60 minutes

L'amorçage d'Object Storage dans une zone en cours d'association nécessite une coordination entre les réconciliateurs Object Storage dans la zone d'ancrage et la zone en cours d'association. Étant donné qu'il n'existe pas de canal de communication sécurisé et contrôlé entre deux zones pour les réconciliateurs lors de l'amorçage, l'IO doit faciliter manuellement la communication sécurisée pour les réconciliateurs Object Storage entre deux zones.

1. Attribuez-vous le rôle prédéfini Administrateur de cluster dans le cluster zonal root-admin et le cluster mondial de la zone d'ancrage. Pour en savoir plus, consultez le runbook IAM.

Vous pouvez également appliquer ces deux liaisons de rôle dans la zone d'ancrage :

Dans l'API globale :

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

Dans le cluster d'administrateur racine :

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

1. Exécutez la commande dans la zone d'ancrage pour obtenir l'adresse IP du serveur DNS, puis notez-la pour une utilisation ultérieure : sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

2. Configurez le résolveur stub DNS de la zone à joindre pour l'associer à la zone d'ancrage :

   1. Désactiver et arrêter systemd-resolved sh systemctl disable systemd-resolved.service --now

   2. Supprimez le fichier resolv.conf s'il existe. sh rm -f /etc/resolv.conf

   3. Écrivez l'adresse IP du serveur DNS de la zone d'ancrage dans le fichier resolv.conf de la zone à joindre. sh vim /etc/resolv.conf Exemple de contenu du fichier /etc/resolv.conf : sh nameserver 10.200.40.0

3. Créez le fichier YAML TokenRequest dans la zone de jonction.

   gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH
   

   Remplacez JOINING_ZONE_NAME par le nom de la zone indiqué dans le questionnaire d'accueil des clients, comme décrit dans la note à la fin de la section.

4. Transférez le fichier YAML TokenRequest vers la zone d'ancrage.

   scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
   

5. Appliquez le fichier YAML TokenRequest au cluster global root-admin dans la zone d'ancrage.

   kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
   

6. Créez un fichier YAML de jeton dans la zone d'ancrage.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
   

7. Transférez le fichier YAML du jeton vers la zone à joindre.

   scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
   

8. Appliquez le fichier YAML du jeton au cluster KIND dans la zone de connexion.

   kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
   

9. Créez le fichier YAML ObjectStorageBootstrap dans la zone d'ancrage.

   gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
   

10. Transférez le fichier YAML ObjectStorageBootstrap vers la zone à joindre.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

11. Appliquez le fichier YAML ObjectStorageBootstrap au cluster KIND dans la zone de jonction.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

12. Amorcez le stockage d'objets dans la zone de connexion.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5
    

    Remarque : Omettez l'indicateur --enable-objectstorage-hsm si l'environnement n'est pas amorcé avec HSM.

Remarque : Si vous amorcez manuellement un environnement antérieur, vous pouvez rencontrer une erreur lorsque vous envoyez une CertificateSigningRequest à Kubernetes, supprimez la CertificateSigningRequest et essayez de la renvoyer. Dans ce cas, résolvez le problème en effectuant une rotation des certificats à partir du HSM. Pour effectuer la rotation, suivez les instructions de HSM Toil 0012, dans la section "Rotate KMIP certificates" (Faire pivoter les certificats KMIP).

Remarque : Il est normal que objectstorageadminnode, objectstoragestoragenode et objectstoragesite ne soient pas à l'état "Prêt" dans le cluster KIND.