19. Amorçage du cluster d'administrateur racine

Durée estimée : 7 heures

Propriétaire du composant opérationnel : KUB/SERV/OBJ/FILE/PNET

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

Ce guide crée un cluster d'administrateur racine qui sert de plan de contrôle pour le cluster interne et les clusters d'infrastructure de l'organisation.

19.1. Configurer le routage

Vérifiez que la route statique a été ajoutée lors de l'installation du serveur Bootstrapper. Si la route statique est manquante, ajoutez-en une au programme d'amorçage :

DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}

Cette route permet d'accéder au serveur d'API du cluster d'administrateur racine à partir de l'interface du plan de données sur le programme d'amorçage. Pour en savoir plus sur les serveurs d'API dans GDC, consultez Serveurs d'API globaux et zonaux.

19.2. Créer un cluster d'administrateur racine

La commande suivante crée un cluster d'administrateur racine avec trois nœuds de plan de contrôle. Le mode locataire par défaut est le mode multilocataire.

gdcloud system admin-cluster install -v=3 \
  --tenant-mode=multi \
  --root-admin-node-count=3 \
  --generate-admin-yaml \
  --addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
  --addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
  --addon-manager-manifests-set storage.mode=ontap \
  --addon-manager-manifests-set gpuFeature.enabled=true \
  --addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
  --addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
  --addon-manager-manifests-set network.noInternalSubnet=false \
  --addon-manager-manifests-set minStage=FEATURE_THRESHOLD

Remarque : Le paramètre --addon-manager-manifests-set minStage=FEATURE_THRESHOLD n'est pas nécessaire si le seuil de fonctionnalité est production. La valeur FEATURE_THRESHOLD doit être identique à celle définie pour le déploiement global.

La création du cluster d'administrateur racine nécessite un fichier de configuration pour le CR du cluster. La configuration est générée automatiquement par défaut. La configuration de cluster personnalisée est également autorisée en définissant l'indicateur --generate-admin-yaml sur false et en spécifiant --admin-yaml-path pour pointer vers le chemin d'accès de la configuration cible.

Une fois l'installation du cluster d'administrateur racine terminée, le kubeconfig du cluster d'administrateur racine est stocké dans /root/release/root-admin/root-admin-kubeconfig.

Remarque : Le protocole Internet version 6 (IPv6) est disponible par défaut pour le cluster d'administrateur racine une fois l'amorçage terminé.

L'URL de l'interface utilisateur (UI) de l'administrateur utilisateur est imprimée après l'installation du cluster. Mémorisez-le pour l'utiliser dans des opérations ultérieures. Vous pouvez également le récupérer à l'aide de la commande suivante :

gdcloud system admin-cluster describe

19.3. Déployer des composants dans le cluster d'administrateur racine

La commande suivante déploie des modèles de cycle de vie de composants opérationnels sur le cluster d'administrateur racine.

gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config

19.4. Configurer les feature gates pour l'administrateur racine

Avertissement : Suivez les instructions de cette section uniquement si vous avez défini un seuil de niveau de fonctionnalité autre que production.

Si votre seuil de phase de fonctionnalité est différent de production, vous devez mettre à jour vos feature gates en conséquence pour qu'ils correspondent au seuil, en suivant OOPS-P0072.

19.5. Configurer le résolveur de stub sur le programme d'amorçage

Exécutez la commande suivante pour configurer le résolveur stub DNS sur le programme d'amorçage. Ce résolveur de stub est nécessaire pour accéder à la console.

gdcloud system dns install

Cette configuration garantit que tous les noms de domaine de l'organisation peuvent être résolus à partir du programme d'amorçage, comme indiqué dans le schéma suivant :

19.6. Définir les adresses IP iLO

Les étapes suivantes définissent les adresses IP ILO sur static pour les nœuds d'administration.

  ADMIN_NODE=NODE NAME
  RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
  ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
  ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
  BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
  ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
  ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)

  echo Target Server: $ADMIN_NODE
  echo ILO IP: $ILO_IP
  echo ILO Gateway: $ILO_GATEWAY
  echo ILO Username: $ILO_USER
  echo ILO Password: $ILO_PASS

Vérifiez que les informations précédentes sont correctes, en fonction des informations du cluster. Exécutez la commande suivante si les informations précédentes sont exactes.

1. Désactivez DHCP.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'
   

   Résultat attendu :

   MessageId: iLO.2.15.ResetRequired

2. Configurez l'adresse IP et la passerelle.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .
   

   Résultat attendu :

   MessageId: Base.1.4.Success

3. Réinitialisez iLO Manager.

   curl -k -u ${ILO_USER}:${ILO_PASS}  -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .
   

   Résultat attendu :

   MessageId: iLO.2.15.ResetInProgress

4. Vérifiez que les paramètres Ethernet ont été appliqués. Si la réponse est bloquée, cela signifie que la réinitialisation n'est pas terminée. Annulez la commande curl en cours, puis attendez 20 secondes et réessayez.

   curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
   

Vérifiez que l'opération a réussi en vous assurant que le code de retour HTTP de chaque étape correspond au résultat attendu.

Répétez les étapes précédentes pour tous les nœuds d'administrateur racine présents dans le cluster.

19.7. Établir une connectivité sous air gap entre le réseau OI et Google Distributed Cloud (GDC)

Cette section explique comment provisionner des fichiers de configuration pour les réseaux Operations Suite Infrastructure (OI) et Distributed Cloud afin d'établir la connectivité.

Ces étapes nécessitent d'accéder à certains fichiers Distributed Cloud et d'être connecté au cluster d'administrateur racine de l'instance Distributed Cloud pour récupérer les informations sur le réseau d'exécution.

Important : Si vous n'avez pas utilisé le programme d'amorçage Distributed Cloud, vous aurez peut-être besoin de l'aide d'un ingénieur de déploiement Distributed Cloud pour accéder au programme d'amorçage et vous assurer d'avoir accès à l'API Kubernetes du cluster d'administration racine.

19.7.1. Avant de commencer

À ce stade du processus de déploiement, les conditions suivantes doivent être remplies :

1. Les deux commutateurs OIR sont câblés, alimentés, mis à niveau vers la version appropriée et ont des configurations de base et ACL appliquées.

2. Les deux pare-feu OIF sont câblés, mis sous tension, mis à niveau vers la version appropriée, activés pour le mode FIPS-CC et la configuration de base est appliquée.

3. Pour que le provisionnement de la connectivité Distributed Cloud soit complet, l'instance Distributed Cloud doit avoir terminé l'amorçage réseau et avoir quitté le cluster kind pour passer au cluster d'administrateur racine.

Important : Vous devez toujours effectuer les étapes nécessitant l'utilisation des fichiers cellcfg, même si l'étape 3 n'est pas encore entièrement terminée, mais que le fichier cellcfg est disponible. Cela permet de configurer les commutateurs et de les préparer à la connectivité Distributed Cloud. Une fois le cluster opérationnel et entièrement prêt, une étape supplémentaire est nécessaire pour générer et appliquer les règles de sécurité du pare-feu.

19.7.2. Préparer l'environnement

Préparez l'environnement pour les étapes suivantes en rassemblant les informations ci-dessous et en définissant les variables d'environnement.

Vous pouvez connecter l'OI de deux manières : localement ou à distance. Une connexion locale connecte OI à Distributed Cloud directement à l'aide de connexions par fibre optique entre les racks d'un même centre de données. Une connexion à distance se connecte à un autre emplacement à l'aide d'un transport longue distance. Cette spécification peut être fournie dans le fichier interconnect.yaml, qui est nécessaire pour provisionner les configurations d'interconnexion Distributed Cloud. Ce fichier contient toutes les informations nécessaires pour configurer les interconnexions GDC.

19.7.2.1. Spécification YAML de l'interconnexion

Attribut	Description	Exemple
zones [ ] map	Informations sur la cellule Distributed Cloud à laquelle le déploiement OI doit se connecter. Pour vous connecter à une liste de cellules Distributed Cloud, spécifiez une liste de zones avec des informations sur chaque cellule Distributed Cloud dans chaque zone. Options de zone	Exemple : zones: - zoneName: kb - uplinkSpeed: 10 localInstanceIDs: 2 remoteInstanceIDs: - 1 - cellCfg: path/to/cellcfg - zoneName: ah - uplinkSpeed: 100 localInstanceIDs: 3 - cellCfg: path/to/cellcfg

19.7.2.2. Options de zone

Contient des informations sur une cellule Distributed Cloud dans le fichier interconnect.yaml :

Attribut	Description	Utilisation
zoneName string	Abréviation de la cellule Distributed Cloud à laquelle le déploiement OI doit se connecter.	zones: - zoneName: kb
uplinkSpeed uint32	(Facultatif) Indique la vitesse de connexion en liaison montante (10 ou 100).	Valeurs :10, 100 Valeur par défaut : 10 uplinkSpeed: 100
localInstance int	Le InstanceID du site de déploiement OI à partir du fichier ocit.yaml. Une connexion locale relie le site Operations Suite Infrastructure Core Rack (OIR) à Distributed Cloud directement à l'aide de connexions fibre optique entre les racks d'un même centre de données.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) du site de déploiement OI à partir du fichier ocit.yaml Une connexion à distance se connecte à un ou plusieurs emplacements différents à l'aide d'un transport longue distance. Une liste de valeurs remoteInstance peut être fournie, de sorte que les configurations de tous les sites OIR sont générées pour se connecter aux cellules Distributed Cloud données.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

S'il s'agit d'une connexion locale, configurez le fichier interconnect.yaml comme suit :

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    cellCfg: /path/to/cellcfg

S'il s'agit d'une connexion à distance, configurez le fichier interconnect.yaml comme suit :

zones:
  - zoneName: ah
    uplinkSpeed: 100
      remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Pour les déploiements OI multisites, spécifiez le fichier interconnect.yaml comme suit :

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Avertissement : Suivez ces étapes et utilisez les chemins d'accès complets appropriés, sinon la commande ne s'exécutera pas correctement.

19.7.3. Générer des configurations de commutateurs

Ces étapes génèrent des configurations de correctifs à appliquer aux périphériques réseau afin de provisionner la connectivité à Distributed Cloud.

occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml

Cela génère les fichiers de configuration suivants pour chaque site :

Fichier(s) de configuration	Appareil	Fonction
occoresw101.incremental	occoresw101	Configuration permettant de corriger l'appareil pour la connectivité à l'instance Distributed Cloud
occoresw101.acl	occoresw101	Configuration permettant de corriger les LCA pour l'application du trafic avec les réseaux Distributed Cloud.
occoresw102.incremental	occoresw102	Configuration permettant de corriger l'appareil pour la connectivité à l'instance Distributed Cloud
occoresw102.acl	occoresw102	Configuration permettant de corriger les LCA pour l'application du trafic avec les réseaux Distributed Cloud.
ocsw101.incremental	ocs1w01	Configuration permettant de corriger l'appareil pour la connectivité à l'instance Distributed Cloud
ocsw101.acl	ocsw101	Configuration permettant de corriger les LCA pour l'application du trafic avec les réseaux Distributed Cloud.
ocsw102.incremental	ocsw102	Configuration permettant de corriger l'appareil pour la connectivité à l'instance Distributed Cloud
ocsw102.acl	ocsw102	Configuration permettant de corriger les LCA pour l'application du trafic avec les réseaux Distributed Cloud.

Remarque : Pour les déploiements Operations Suite Infrastructure (OI) multisites, une configuration est générée pour chaque site mentionné dans le fichier interconnect.yaml. Identifiez les fichiers générés pour chaque site à l'aide de InstanceID. Les fichiers générés ont un préfixe au format suivant : <segment_type><device_type><InstanceID><device_id>

19.7.4. Générer des stratégies de pare-feu

Pour générer les règles de pare-feu, occonfigtool doit accéder à l'API Kubernetes pour le cluster d'administrateur racine. Assurez-vous que la variable d'environnement KUBECONFIG est définie sur root-admin-kubeconfig :

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml

Générez les règles de pare-feu en exécutant la commande suivante :

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Fichier(s) de configuration	Appareil	Fonction
firewall-rules.base	occorefw01	Configuration permettant de corriger l'appareil pour la connectivité à l'instance Distributed Cloud

19.7.5. Appliquer des configurations

À l'aide des fichiers de sortie, appliquez la configuration aux périphériques réseau respectifs en suivant la même procédure que celle de l'étape précédente pour les commutateurs et les pare-feu.

19.8. Mettre à jour les ressources RoutePolicy Distributed Cloud

Distributed Cloud utilise des règles de routage pour déterminer les réseaux qui peuvent être annoncés dans la table de routage.

Lorsque nous ajoutons OI en tant que réseau externe, nous devons mettre à jour les CR RoutePolicy pour qu'ils s'attendent aux nouveaux réseaux.

Pour ce faire, vous devez accéder à root-admin-cluster à l'aide de kubectl. Assurez-vous que la variable KUBECONFIG appropriée est définie :

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

Pour confirmer, procédez comme suit :

kubectl get routepolicy -n gpc-system

Vous devriez obtenir un résultat semblable à celui-ci :

NAME                                     AGE
customerpeering-routepolicy              19d
datacenter-routepolicy                   19d
mgmtnetworkoperationcenter-routepolicy   19d
networkoperationcenter-routepolicy       19d

Pour ces étapes, nous nous concentrerons sur networkoperationcenter-routepolicy et mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Corriger les règles de routage du réseau de données

À partir de ocinfo.opscenter.local.txt, récupérez les sous-réseaux suivants (y compris le réseau et la longueur du préfixe).

Remarque : Pour un déploiement OI multisite, répétez cette étape pour tous les sites. Utilisez les sous-réseaux du fichier ocinfo.opscenter.local.txt pour les sites listés.

• OCCORE-SERVERS, utilisé dans l'exemple suivant comme $OCCORE_SERVERS_NET
• OC-WORKSTATIONS, utilisé dans l'exemple suivant comme $OC_WORKSTATIONS_NET

Utilisez ces valeurs pour ajuster les règles de routage en renseignant les variables suivantes :

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Exemple :

export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24

Une fois les variables d'environnement définies, exécutez les commandes kubectl suivantes :

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_SERVERS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Exemple de résultat :

routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched

19.8.1.2. Règles de routage réseau pour la gestion des correctifs

À partir de ocinfo.opscenter.local.txt, récupérez les sous-réseaux suivants (y compris le réseau et la longueur du préfixe).

Remarque : Pour les déploiements OI multisites, répétez cette étape pour tous les sites. Utilisez les sous-réseaux des fichiers ocinfo.opscenter.local.txt de la liste des sites.

• OCCORE-JUMPHOSTS, utilisé dans l'exemple suivant comme $OCCORE_JUMPHOSTS_NET
• OCCORE-ILOS, utilisé dans l'exemple suivant comme $OCCORE_ILOS_NET

Utilisez ces valeurs pour ajuster les règles de routage en renseignant les variables suivantes :

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Exemple :

export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27

Une fois les variables d'environnement définies, exécutez les commandes kubectl suivantes :

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_ILOS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Exemple de résultat :

routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched

19.9. Valider la connectivité réseau OI Distributed Cloud

Important : Suivez les étapes de validation décrites dans Établir la connectivité du réseau OI et de Distributed Cloud avant de valider les connexions Distributed Cloud. Notez que si les configurations incremental effectuées à l'étape précédente ont déjà été appliquées, les validations de cette étape peuvent ne pas correspondre précisément.

À ce stade du déploiement, les conditions suivantes doivent être remplies :

• occoresw101 et occoresw102 sont configurés avec les fichiers de configuration base, acl, incremental et incremental-acl.
• ocsw101 et ocsw102 sont configurés avec les fichiers de configuration base, acl, incremental et incremental-acl.
• occorefw101 et occoref102 sont configurés avec les fichiers de configuration base et firewall-rules.base.
• Les liaisons montantes entre le centre de données et le centre d'opérations sont connectées et opérationnelles.
• Les liaisons montantes physiques entre les composants Distributed Cloud sont vérifiées.

Remarque : Pour les déploiements Operations Suite Infrastructure (OI) multisites, les fichiers de configuration sont générés et appliqués pour chaque site.

Si l'une des conditions précédentes n'est pas vraie, le résultat suivant peut différer considérablement en fonction de l'état actuel et ne produira probablement pas le comportement attendu en production.

19.9.1. Résultat attendu

Les extraits suivants montrent le résultat d'un environnement fonctionnel connu des commandes suivantes :

• show ip bgp summary vrf all
• show ip bgp vrf all
• show ip route vrf all
• show lldp neighbors

Remarque : Ajoutez | no-more à la fin de chaque commande pour éviter la pagination. Par exemple, show ip bgp vrf all | no-more.

Ces extraits peuvent servir de comparaison avec un environnement de production utilisant les mêmes commandes.

19.9.2. Validations des clés

Voici les principaux éléments à rechercher dans les sorties suivantes :

• Aucune session BGP n'est à l'état Idle, Active ou Closing.
• Toutes les sessions BGP affichent une valeur State/PrxRcd supérieure à 0.
• Toutes les sessions BGP affichent un minuteur Up/Down qui augmente en continu.
• Le préfixe externalCIDR du cloud distribué (disponible dans le CIQ) est présent dans les tables de routage et les tables BGP des VRF GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS et OCCORE-SERVERS.
• Le oobManagementCIDRs du cloud distribué (disponible dans le CIQ) est présent dans les tables de routage et les tables BGP des VRF GDCH-MGMT, GDCH-MGMT-TRANSIT et HW-INFRA.

19.9.3. OCCORESW

Le tableau suivant indique le résultat attendu sur chaque occore switch pour les interconnexions Distributed Cloud. Vous devez effectuer toutes les validations réseau avant de passer à cette étape. Les voisins et les routes BGP mentionnés ici doivent être présents en plus de ceux mentionnés précédemment. Validez la sortie sur tous les commutateurs.

VRF	Voisin BGP	Routes attendues reçues du voisin BGP	Routes attendues annoncées au voisin BGP
GDCH-DATA-TRANSIT	AGGSW01	Adresse récapitulative agrégée avec le sous-réseau /19 pour la cellule Distributed Cloud	Préfixe OCCORE-SERVERS Préfixe OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Adresse récapitulative agrégée avec le sous-réseau /19 pour la cellule Distributed Cloud	Préfixe OCCORE-SERVERS Préfixe OC-WORKSTATION
GDCH-DATA-TRANSIT	Session BGP en épingle à cheveux utilisant OCCOREFW vers OC-DATA VRF	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule Distributed Cloud
OC-DATA	Session BGP OCSW01	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule Distributed Cloud
OC-DATA	Session BGP OCSW02	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule Distributed Cloud
OC-DATA	Session BGP OCCORESW	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Adresses récapitulatives agrégées (avec le sous-réseau /24) de l'ensemble du réseau de gestion OOB GDCH	Préfixe OCCORE-JUMPHOSTS Préfixe OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Adresses récapitulatives agrégées (avec le sous-réseau /24) de l'ensemble du réseau de gestion OOB du cloud distribué	Préfixe OCCORE-JUMPHOSTS Préfixe OCCORE-ILOS
GDCH-MGMT-TRANSIT	Session BGP en épingle à cheveux utilisant OCCOREFW vers VRF HW-INFRA	Adresses récapitulatives agrégées (avec le sous-réseau /24) de l'ensemble du réseau de gestion OOB du cloud distribué

19.9.4. OCSW

Le tableau suivant indique le résultat attendu sur chaque oc switch après l'exécution de la procédure d'interconnexion Distributed Cloud. Vous devez effectuer toutes les validations réseau avant de passer à cette étape. Les voisins et les routes BGP mentionnés ici doivent être présents en plus de ceux mentionnés précédemment. Validez la sortie sur tous les commutateurs.

VRF	Voisin BGP	Routes attendues reçues du voisin BGP
OC-DATA	Session BGP OCCORESW01	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule GDCH
OC-DATA	Session BGP OCCORESW02	Adresse récapitulative agrégée (avec le sous-réseau /19) pour la cellule GDCH

L'extrait de code de la commande de sortie est disponible dans la commande Distributed Cloud validations show.

Remarque : La section suivante traite de la validation des déploiements multisites. Vous pouvez ignorer cette section si votre déploiement n'est pas multisite.

19.9.5. Validations du déploiement de l'OI multisite

La section suivante explique comment valider les déploiements multisites avec plusieurs cellules Distributed Cloud interconnectées. À ce stade, la topologie avec deux sites se présente comme suit :

• Les connexions bleues montrent le site 1 connecté aux cellules 01 et 02 du Distributed Cloud.
• Les connexions rouges indiquent que le site 2 est connecté aux cellules 01 et 02 de Distributed Cloud.
• Les connexions vertes indiquent l'interconnexion entre le site 1 et le site 2.

Pour tous les sites sur tous les commutateurs, vous devez suivre les étapes décrites dans ces sections.

1. Validations du réseau
2. Validations multisites du réseau.
3. Validations Network Distributed Cloud

19.10. Effectuer les dernières étapes pour le réseau OI

À ce stade, toutes les configurations doivent avoir été générées et appliquées à tous les appareils.

Les listes d'accès au réseau sont désormais dans un état qui autorise des flux spécifiques attendus, mais qui comporte également une règle par défaut autorisant tout le trafic.

Vous devez maintenant confier le déploiement aux opérations. La suite opérationnelle varie en fonction, en implémentation et en services fournis entre les clients. Par conséquent, ses exigences en termes de trafic varient.

Une fois que les opérations ont accepté le déploiement, il leur incombe de parcourir les LCA et de sécuriser entièrement les flux de trafic réseau.

Des runbooks opérationnels sont fournis pour effectuer ces tâches.

19.11. Mettre à niveau le stockage d'objets

Lors de l'amorçage du stockage d'objets, les nœuds ont été installés avec la dernière version mineure compatible de StorageGRID. Toutefois, il peut être nécessaire de mettre à jour la version cible vers la dernière version du correctif.

Déterminez la version cible de StorageGRID à partir des métadonnées de la version à l'aide de la commande suivante :

kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'

Si la version actuelle de StorageGRID n'est pas la version cible, effectuez une mise à niveau du stockage d'objets vers la version cible.

19.12. Problèmes potentiels

Important : Vous pouvez rencontrer ces problèmes lors de l'installation de la version 1.9.x de Distributed Cloud.

19.12.1. La machine virtuelle de stockage ne se réconcilie pas

TL;DR : La machine virtuelle de stockage n'est pas prête lors de la création du cluster d'administrateur racine.

Problème : Après avoir créé le cluster d'administrateur racine, la ressource Storage Virtual Machine ne se réconcilie pas et affiche un événement d'avertissement tel que :

StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF

Ce problème peut être dû à une mauvaise configuration du cluster de stockage qui empêche l'utilisation du protocole SSL pour des raisons de sécurité.

Solution :

Connectez-vous à la console série ou au cluster de stockage à l'aide de SSH, puis exécutez la commande suivante :

security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01

Une fois la connexion établie, la ressource Storage Virtual Machine peut être réconciliée.

19.12.2. Échec de l'amorçage lors de l'installation du certificat TLS du serveur de pare-feu

Vous pouvez rencontrer un échec TLSServerCertification lors de l'exécution de la tâche d'amorçage du plan de contrôle de l'administrateur racine décrite à l'étape 20.

Solution :

Pour réessayer d'installer le certificat du serveur de pare-feu, reportez-vous aux instructions figurant dans le manuel d'entretien du service d'E/S FW-R1008. Une fois l'installation terminée, utilisez la commande gdcloud avec la commande --start-phase pour poursuivre l'amorçage de l'administrateur racine.