Effectuer une expansion dynamique

Cette page décrit le processus d'expansion dynamique de votre système en intégrant davantage de ressources de stockage et de calcul. Des instructions sont fournies pour les types d'expansion suivants :

Extension horizontale de la baie de serveurs : ajoute une baie à la zone. Ce rack inclut des nœuds de calcul, une console, des commutateurs top-of-rack (ToR) et des commutateurs de gestion (MGMT).
Expansion verticale des serveurs : ajoute des blocs d'expansion de serveur dans les racks qui comportent des emplacements d'expansion vides.
Extension verticale du stockage de fichiers et de blocs : ajoute des nœuds de stockage dans des racks qui comportent des emplacements d'extension vides dans un cluster de stockage existant. Les nœuds de stockage associés au même commutateur de stockage font partie du même cluster.

Pour en savoir plus sur les différents types d'expansion dynamique, consultez Présentation de l'expansion dynamique.

Avant de commencer

Avant de modifier la zone, vous devez disposer des éléments suivants :

Effectuez une inspection matérielle et validez-la avec l'OEM . Suivez les instructions de la section Inspection des racks.
Suivez la procédure de génération de KUBECONFIG pour générer le KUBECONFIG du nœud du plan de contrôle du cluster d'administrateur. Utilisez le fichier de configuration KUBECONFIG généré pour toutes les étapes kubectl de ce guide.
Vérifiez que la version actuelle de Google Distributed Cloud (GDC) sous air gap sur le cluster racine est au moins la version 1.13.1 :
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
Téléchargez le fichier tar GDC. Pour en savoir plus, consultez Télécharger des fichiers.
Préparez le micrologiciel des nouveaux appareils :
1. Les dispositifs de commutation de paquets dans le matériel GDC. Pour en savoir plus, consultez Boutons bascule.
2. Mettez à jour le stockage de fichiers et de blocs ONTAP en suivant les instructions de la section Mise à niveau manuelle d'ONTAP.
Validez l'état du système GDCH à l'aide de gdcloud system doctor. Si la commande gdcloud system doctor n'est pas disponible, utilisez la méthode alternative décrite dans Vérification de l'installation réseau.

Effectuer une expansion horizontale des racks de serveurs

Ajoutez un rack composé de nœuds de calcul, de la console, et de commutateurs ToR et de gestion à la zone via une extension horizontale du rack de serveurs. Les étapes décrites dans cette section concernent un seul rack. Si vous avez plusieurs racks, appliquez ces étapes à chacun d'eux.

Effectuer des opérations de réinitialisation

Vous devez réinitialiser de manière sécurisée les équipements suivants :

Effectuez une réinitialisation sécurisée du serveur de la console série. Contactez Google pour obtenir ces instructions, car chaque déploiement peut avoir des consoles série différentes.
Effectuez une réinitialisation sécurisée de l'unité de distribution d'alimentation (PDU) Raritan :
1. Branchez le câble USB-b à l'unité de distribution d'alimentation Raritan depuis le contrôleur système.
2. Dans la console série locale, rétablissez les paramètres par défaut de l'unité de distribution d'alimentation à l'aide de la commande reset factorydefaults.
3. La PDU est désormais définie sur admin/legrand.
Effectuez une réinitialisation sécurisée, mettez à jour le micrologiciel et réinitialisez les commutateurs ToR et MGMT sur PowerOn Auto Provisioning (POAP) en suivant les instructions de la section Effacement sécurisé.
Connectez-vous à chaque serveur et effectuez l'effacement sécurisé manuellement.

Préparer les artefacts

Suivez ces étapes pour appliquer les fichiers de configuration et les ressources personnalisées nécessaires :

Générez le fichier YAML ZonalExpansion, les ressources matérielles CustomResources et SubcomponentOverride à l'aide de la commande gdcloud system assets add :

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Remplacez FILE_PATH pour chacun des fichiers utilisés. Notez que ce chemin d'accès peut être différent si chaque fichier se trouve à un emplacement différent.

La ressource personnalisée ZonalExpansion suit tous les objets ajoutés et indique l'état de tous les objets.

Suivez les conseils ci-dessous lorsque vous examinez le fichier YAML ZonalExpansion :

Le champ name doit être descriptif, par exemple az-ae-expansion.
Le champ assets doit inclure tous les nouveaux appareils dans le nouveau rack d'extension.

Voici un exemple de ressource ZonalExpansion :

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Utilisez un outil IAC (Infrastructure as Code) pour appliquer la ressource personnalisée ZonalExpansion. Pour en savoir plus, consultez Configurer l'Infrastructure as Code. Vous pouvez également suivre le runbook IAM-R0004 et utiliser kubectl pour ce faire.
Vérifiez que les ressources ZonalExpansion et NonCompliantDeviceSet ont été créées :
1. Vérifiez l'état de la ressource ZonalExpansion :
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  La vérification préliminaire devrait échouer à ce stade pour la raison suivante : ReasonAssetsNotExisted.
2. La ressource NonCompliantDeviceSet doit exister avec un nom commençant par le préfixe noncompliantassets-.
3. La liste des composants doit être identique au champ assets de la ressource personnalisée ZonalExpansion.
Suivez les instructions de la page OLT-R0003 pour mettre à jour les composants.
Connectez les commutateurs ToR et MGMT du nouveau rack au commutateur d'agrégation du rack existant.
Connectez physiquement les commutateurs aux racks de base.

Amorçage complet du serveur

Cette phase est principalement automatisée, mais certaines étapes sont nécessaires. Vous devez surveiller la progression de l'amorçage et gérer les éventuels cas d'échec :

Le contrôleur lance automatiquement la procédure d'amorçage une fois la condition PreflightCheck=True remplie.
Vérifiez que la condition NetworkBootstrapSucceed=True est publiée dans la ressource personnalisée ZonalExpansion. Cette condition se trouve à l'emplacement ZonalExpansion.Status.PNETBootstrapStatus.
Vérifiez que les commutateurs ont été supprimés de la liste NonCompliantDeviceSet :
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Remplacez EXPANSION_NAME par le nom de la ressource personnalisée d'expansion zonale.

Vérifiez que les options ne figurent pas dans le champ Spec.Assets du fichier YAML renvoyé. Cette suppression permet à GDC de mettre à jour les LCA du réseau pour autoriser d'autres procédures d'amorçage des appliances. Les deux LCA réseau mises à jour sont quarantine-mgmt-switch-acl et quarantine-data-switch-acl.

Listez toutes les adresses IP du contrôleur de gestion de la carte mère (BMC) pour le serveur et vérifiez que les adresses IP iLO sont attribuées à la nouvelle machine bare metal et que l'amorçage peut démarrer :

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

Exemple de résultat :

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

GDC amorce les serveurs en parallèle pour effectuer l'effacement sécurisé, la vérification, la mise à jour des paramètres du BIOS et d'autres procédures d'amorçage.

Vérifiez que la condition ServerBootstrapSucceeded=True est publiée dans la ressource personnalisée ZonalExpansion. Cette condition se trouve à l'emplacement ZonalExpansion.Status.SERVBootstrapStatus :
- L'état de l'hôte Bare Metal du serveur passe à Available ou Provisioned une fois l'amorçage réussi.
- Au niveau de verbosité 4 de la CLI, vous voyez des journaux tels que "Not all servers in the ZonalExpansion are bootstrapped" avec une liste des serveurs qui ne sont pas encore prêts.

Vérifiez que les serveurs ont bien été supprimés de la liste NonCompliantDeviceSet :

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

Vérifiez que la condition ExpansionSucceeded=True est publiée dans la ressource personnalisée ZonalExpansion. Cette condition se trouve à l'emplacement ZonalExpansion.Status.Conditions.

Vérifiez que la liste NonCompliantDeviceSet a été supprimée :

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

Résultat attendu :

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

Développer verticalement le serveur

Ajoutez des blocs d'extension de serveur dans les racks qui comportent des emplacements d'extension vides, grâce à une extension de serveur verticale. La plupart des instructions pour cette expansion sont similaires à celles de l'expansion de calcul horizontale. Pour étendre un rack de serveurs vertical, procédez comme suit :

Installez physiquement le bloc de serveurs standard qui occupe six nœuds de capacité ou le bloc de serveurs GPU qui consomme trois nœuds de capacité. Vous pouvez ajouter plusieurs blocs par rack. Avertissement : Ne branchez pas de câbles sur les commutateurs mgmtsw ou aggsw. Pour en savoir plus, consultez Boutons bascule.
Ne branchez aucun câble, à l'exception de celui de l'alimentation. Cette étape permet au processus de mise sous tension du serveur de vérifier que le serveur n'est pas hors connexion à l'arrivée.

Générez le fichier YAML ZonalExpansion et la ressource SubcomponentOverride matérielle à l'aide de la commande gdcloud system assets add :

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Remplacez FILE_PATH pour chacun des fichiers utilisés. Notez que ce chemin d'accès peut être différent si chaque fichier se trouve à un emplacement différent.

Suivez les conseils ci-dessous lorsque vous examinez le fichier YAML ZonalExpansion :

Le champ name doit être descriptif, par exemple az-ae-expansion.
Le champ assets doit inclure tous les nouveaux appareils dans le nouveau rack d'extension.

Voici un exemple de ressource ZonalExpansion :

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Appliquez la ressource personnalisée ZonalExpansion que vous venez de créer au cluster.
Vérifiez que les ressources ZonalExpansion et NonCompliantDeviceSet ont été créées :
1. Vérifiez l'état de la ressource ZonalExpansion. La vérification préliminaire devrait échouer à ce stade pour la raison suivante : ReasonAssetsNotExisted.
2. La ressource NonCompliantDeviceSet doit exister avec un nom commençant par le préfixe noncompliantassets-.
3. La liste des composants doit être identique au champ assets de la ressource personnalisée ZonalExpansion.
Suivez les instructions de la page OLT-R0003 pour mettre à jour les composants.
Vérifiez que l'ACL de l'option de mise en quarantaine est en cours d'exécution en suivant le runbook OLT-R0001.
Branchez les câbles des serveurs si ce n'est pas déjà fait. Suivez le fichier de câblage fourni par Hewlett Packard Enterprise (HPE).
Vérifiez que le processus d'amorçage du serveur démarre et se termine correctement. Pour en savoir plus, consultez Bootstrap complet du serveur.

Développer le stockage de fichiers et de blocs verticaux

Ces instructions incluent les étapes nécessaires pour effectuer une expansion verticale ou à un seul rack du nœud de stockage. L'expansion des nœuds de stockage est effectuée lorsque de nouveaux nœuds de stockage ONTAP sont ajoutés pour étendre les capacités de stockage d'un rack existant. Les instructions de câblage pour les nouveaux périphériques de stockage ne sont pas fournies ici. Seules les procédures d'effacement, de mise à niveau et d'ajout de nœuds de stockage à un cluster existant sont décrites.

Configurer l'expansion des nœuds de stockage

Pour préparer le cluster à l'expansion des nœuds de stockage, procédez comme suit :

Suivez la procédure de génération de KUBECONFIG pour générer le KUBECONFIG du nœud du plan de contrôle du cluster d'administrateur. Utilisez le fichier de configuration KUBECONFIG généré pour toutes les étapes kubectl de ce guide :

Appliquez une ressource SubcomponentOverride pour désactiver les réconciliateurs de stockage lors de la configuration initiale de l'expansion des nœuds :

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

Vérifiez que le remplacement a fonctionné et que les réconciliateurs file-storage ont été désactivés :
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Le message suivant doit s'afficher :
```
--enable-reconcilers=
--disable-reconcilers=*
```
Si cet état ne s'affiche pas, attendez plusieurs minutes que la ressource SubcomponentOverride s'applique, puis effectuez à nouveau cette vérification. Si le SubcomponentOverride n'est toujours pas appliqué après quelques minutes, contactez l'assistance technique GDC.

Générez le fichier YAML ZonalExpansion et la ressource matérielle SubcomponentOverride à l'aide de la commande gdcloud system assets add :

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

Appliquez la ressource personnalisée ZonalExpansion que vous venez de créer au cluster.
Vérifiez que les ressources ZonalExpansion et NonCompliantDeviceSet ont été créées :
1. Vérifiez l'état de la ressource ZonalExpansion. La vérification préliminaire devrait échouer à ce stade pour la raison suivante : ReasonAssetsNotExisted.
2. La ressource NonCompliantDeviceSet doit exister avec un nom commençant par le préfixe noncompliantassets-.
3. La liste des composants doit être identique au champ "assets" de la ressource personnalisée ZonalExpansion.
Appliquez les ressources SubcomponentOverride des composants matériels suivants au cluster d'administrateur racine à l'aide des outils IaC.
- file/file-storage.yaml
- inv/inv-core.yaml
Remarque : Le SubcomponentOverride généré n'inclut aucune substitution déjà appliquée au cluster. Capturez les SubcomponentOverride actuels et ajoutez-les aux SubcomponentOverride générés respectifs pour vous assurer qu'aucune substitution n'est perdue.

Vérifiez que les nouveaux nœuds ont été ajoutés au cluster :

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

Les nouvelles ressources personnalisées de nœud devraient s'afficher avec une valeur d'âge plus récente :

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

Utilisez la commande describe pour obtenir des informations sur les deux nœuds, car ils contiennent des informations nécessaires pour les étapes ultérieures.
```
kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system
```
Remplacez NODE_NAME par le nom de chaque nœud créé.

Exemple de résultat :
```
NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d
```

Effectuer la procédure d'expansion des nœuds de stockage

Pour finaliser le processus d'expansion du nœud de stockage, procédez comme suit :

Effectuez une mise à niveau manuelle des nouveaux nœuds de stockage. Pour chaque nœud, suivez les étapes de la section Mise à niveau manuelle d'ONTAP, en diffusant les fichiers à partir du contrôleur système.
Effectuez un effacement sécurisé des nouveaux nœuds de stockage. Pour les nouveaux nœuds ONTAP, suivez la procédure de réinitialisation d'ONTAP.
Initialisez les nouveaux nœuds de stockage. Utilisez les informations des ressources personnalisées StorageNode nouvellement ajoutées et décrites à l'étape précédente. Pour chaque nœud, suivez les étapes décrites dans Initialiser les appliances ONTAP.

Remarque : N'effectuez pas l'étape cellcfg. Utilisez plutôt les valeurs que vous avez notées à l'étape précédente.
Établissez une connexion par câble entre le nouveau nœud et le cluster actuel en suivant Configurer ONTAP.
Suivez les instructions de la section Ajouter de nouveaux nœuds à un cluster existant pour ajouter les nouveaux nœuds au cluster.

Résoudre les problèmes liés à l'expansion dynamique

Utilisez les runbooks suivants du manuel d'entretien pour résoudre les problèmes d'expansion dynamique :

OLT-R0001
OLT-R0002
OLT-R0003