Cette page a été traduite par l'API Cloud Translation.

Gérer les ressources d'organisation

En tant qu'opérateur d'infrastructure (IO) de Google Distributed Cloud (GDC) air-gapped, vous vérifiez l'état du système, configurez les utilisateurs et les réseaux, et gérez le cycle de vie des systèmes matériels sous-jacents, tels que le calcul, le stockage et la mise en réseau.

Avant de commencer

Pour suivre les instructions de ce document, vous devez disposer des ressources suivantes :

La CLI gdcloud ou la CLI kubectl
Un environnement Linux

Pour obtenir les autorisations nécessaires pour gérer une organisation, demandez à votre administrateur de la sécurité de vous attribuer le rôle Administrateur de l'organisation (organization-admin).

Accéder aux serveurs et les surveiller

Accéder aux serveurs GDC et surveiller leur état pour s'assurer qu'ils sont sécurisés, à jour et fonctionnels.

Pour en savoir plus sur la surveillance des serveurs d'une organisation, consultez la page Interroger et afficher les métriques.

Gérer le cycle de vie d'un serveur

La gestion du cycle de vie des serveurs inclut les fonctionnalités suivantes :

Arrêtez et redémarrez l'appareil.
Reconfiguration.
Mises à jour du micrologiciel du contrôleur de gestion de la carte mère (BMC) et du circuit logique programmable complexe (CPLD).
Mises à jour du système d'exploitation ou des logiciels.
Configurations du système d'exploitation, telles que les paramètres de sécurité.

Les correctifs de sécurité du système d'exploitation de base, les mises à niveau groupées pour le logiciel hôte du serveur et les mises à niveau du micrologiciel du serveur sont effectués régulièrement pendant les périodes de maintenance.

Les intervalles de maintenance incluent les actions suivantes :

Installez les mises à jour de sécurité urgentes du système d'exploitation du serveur.
Mettez à niveau le bundle logiciel hôte sur un ou plusieurs serveurs.
Mettez à niveau le micrologiciel sur un ou plusieurs serveurs.

Ajouter et gérer des serveurs de charge de travail

Pour ajouter des serveurs de charge de travail ou gérer ceux existants, mettez à jour votre ressource personnalisée OrganizationZonalConfig stockée dans le dépôt iac :

Générez la liste des serveurs et des types de serveurs disponibles :

kubectl get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'

La sortie ressemble à ceci :

ag-aa-bm04   o1-standard1-64-gdc-metal   available
ag-ab-bm07   o1-standard1-64-gdc-metal   available
ag-ab-bm11   o1-highmem1-96-gdc-metal    available
ag-ab-bm12   o1-highmem1-96-gdc-metal    available
ag-ab-bm13   o1-highmem1-96-gdc-metal    available
ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
ag-ab-bm16   o1-highgpu1-48-gdc-metal    available

Notez les serveurs disponibles et assurez-vous de n'allouer que ce qui est disponible lorsque vous modifiez les serveurs de charge de travail de votre organisation.

Ouvrez votre fichier YAML de ressource personnalisée OrganizationZonalConfig dans le dépôt iac :
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Remplacez les éléments suivants :
- IAC_REPO_PATH : chemin d'accès au dossier du dépôt iac.
- ORG_NAME : nom de l'organisation.
- ZONE : nom de la zone dans l'univers. Le nom de la zone est dérivé au format suivant : {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Exemple : us-central1-b. Consultez la section "Zone" du questionnaire d'accueil des clients pour obtenir la description des valeurs de l'attribut "Zone".

Mettez à jour la section workloadServers du fichier YAML. Ajoutez des serveurs de charge de travail ou gérez le nombre de serveurs existants pour chaque type :

...
workloadServers:
  o1-highmem1-40-gdc-metal: 1
  o1-standard1-64-gdc-metal: 2
  o1-highmem1-96-gdc-metal: 3
  o1-highmem1-104-gdc-metal: 4
  o1-highmem1-448-gdc-metal: 5
  o1-highgpu1-48-gdc-metal: 6
...

Enregistrez et fermez l'éditeur interactif.
Organisez et validez les modifications apportées au fichier YAML de configuration zonale de votre organisation :
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Transférez la mise à jour vers GitLab :
```
git -c http.sslVerify=false push
```
Attendez que le code soit examiné et fusionné.
Répétez ces étapes avec le même contenu et la même structure de répertoire pour tous les dépôts GitLab de toutes les zones Distributed Cloud du déploiement Distributed Cloud.

Dans le déploiement Distributed Cloud, chaque zone contient des instances GitLab individuelles et déconnectées. Pour chaque ressource globale créée, mise à jour ou supprimée dans GitLab, vous devez valider exactement le même contenu dans les dépôts GitLab de chaque zone. Le pod de réconciliateur racine global s'exécute dans la zone Distributed Cloud principale, définie dans le champ primary de la ressource personnalisée zoneselectionresult dans l'API globale. Le reconciler synchronise les données de la zone principale de GitLab avec l'API globale.

Avertissement : Vous devez synchroniser le dossier global de la zone principale avec GitLab de toutes les autres zones. Si la zone principale est hors service et que vous en sélectionnez une autre, vous risquez d'appliquer ou de supprimer par erreur des ressources globales obsolètes dans l'API globale.

Vérifiez que les serveurs de charge de travail que vous avez attribués sont disponibles :

kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.spec.nodePoolClaimRef.namespace=="org-1")]}{.metadata.name}{"\t"}{.status.provisionReady}{"\n"}{end}'

Si le serveur de charge de travail est défini sur true, il est disponible. Le résultat ressemble à ce qui suit :

zi-aa-bm04      true
zi-aa-bm05      true
zi-aa-bm06      true

Augmenter la capacité de stockage

La quantité de stockage disponible pour chaque organisation dans une zone est définie dans le champ capacities de la ressource OrganizationZonalConfig.

Pour augmenter le quota de ces classes de stockage, mettez à jour la ressource OrganizationZonalConfig dans chaque zone.

Ouvrez votre fichier YAML de ressource personnalisée OrganizationZonalConfig dans le dépôt iac :
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Remplacez les éléments suivants :
- IAC_REPO_PATH : chemin d'accès au dossier du dépôt iac.
- ORG_NAME : nom de l'organisation.
- ZONE : nom de la zone dans l'univers, par exemple us-central1-b. Pour en savoir plus sur les valeurs des attributs de zone, consultez la section Zone du questionnaire d'accueil des clients.
Mettez à jour la section capacities du fichier YAML avec les nouvelles valeurs de quota pour vos types de stockage. Exemple :
```
# Several lines of code are omitted here.
spec:
  capacities:
    storage:
      file-standard: FILE_QUOTA
      block-standard: BLOCK_QUOTA
      object-standard: OBJECT_QUOTA
```
Remplacez les éléments suivants :
- FILE_QUOTA : nouvelle valeur du quota de stockage de fichiers dans la zone, par exemple 10Ti.
- BLOCK_QUOTA : nouvelle valeur du quota pour le stockage par blocs dans la zone, par exemple 10Ti.
- OBJECT_QUOTA : nouvelle valeur du quota pour le stockage d'objets dans la zone, par exemple 10Ti.
Pour en savoir plus sur la définition de votre capacité de stockage dans la ressource OrganizationZonalConfig, consultez la documentation de référence sur TypedResourceCapacities.
Enregistrez et fermez l'éditeur interactif.
Organisez et validez les modifications apportées au fichier YAML de configuration zonale de votre organisation :
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Transférez la mise à jour vers GitLab :
```
git -c http.sslVerify=false push
```
Attendez que le code soit examiné et fusionné.
Répétez ces étapes avec le même contenu et la même structure de répertoire pour tous les dépôts GitLab de toutes les zones GDC du déploiement GDC.