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

Effectuer une mise à niveau dans un déploiement multizone

Dans un déploiement multizone, les zones sont mises à niveau une par une et indépendamment les unes des autres. Il n'existe pas d'orchestration globale des mises à niveau entre les zones. Un IO doit effectuer une mise à niveau dans chaque zone pour l'organisation qu'il souhaite mettre à niveau vers une nouvelle version. Par conséquent, les organisations situées dans différentes zones peuvent utiliser des versions différentes à un moment donné.

L'ordre de mise à niveau décrit sur cette page consiste à mettre à niveau l'organisation racine ainsi que toutes les organisations locataires d'une zone avant de passer à une autre zone. Les ressources globales sont mises à niveau à la fin, une fois que toutes les zones ont été mises à niveau.

Cette page décrit les étapes à suivre pour effectuer une mise à niveau Google Distributed Cloud (GDC) multizone en mode isolé. Elle fournit les types d'informations suivants :

Accès requis et comment l'obtenir
les outils dont vous avez besoin.
Les étapes à suivre avant d'effectuer une mise à niveau.
Comment et dans quel ordre effectuer les mises à niveau pour les différents composants Distributed Cloud.

La liste suivante définit chacun des composants d'une mise à niveau :

Version cible : utilisez la même version cible pour toutes les zones.

Une zone à la fois : mettez à niveau une zone à la fois. Avant de déclencher une mise à niveau dans une zone, assurez-vous qu'aucune autre zone n'est en cours de mise à niveau.

Ressources globales : ressources Kubernetes déployées sur le kube-apiserver global, par opposition aux ressources zonales qui ont une copie par zone. Les ressources globales suivent un cycle de vie différent. Notez qu'ils ne doivent être mis à niveau qu'une seule fois, à la fin.

Préparer

Les URL sont fournies pour accéder à l'extérieur de votre environnement isolé.

Avant de commencer une mise à niveau, assurez-vous de disposer des éléments suivants :

Le chemin d'accès au fichier kubeconfig que vous avez obtenu en exécutant gdcloud auth login sur le cluster d'administrateur racine.

Important : Vous devez disposer du chemin d'accès kubeconfig pour pouvoir continuer.
Les nouveaux artefacts de version, téléchargés et transférés de manière sécurisée sur votre machine. Suivez les étapes décrites dans Envoyer les artefacts au registre de conteneurs.
Une machine hôte pour exécuter les mises à niveau manuelles, avec un fichier kubeconfig de cluster d'administrateur racine sur la machine.
Tous les problèmes connus liés à la version DE DÉPART sont résolus avant de commencer la mise à niveau. Si vous effectuez une mise à niveau depuis la version 1.13.1, assurez-vous que les problèmes suivants sont résolus :
- VM sans espace disponible sur l'appareil

Générer un rapport de conformité

Le rapport sur la conformité liste les organisations qui :

ne sont plus prises en charge.
manquer des correctifs de sécurité critiques ;

La génération du rapport de conformité est une étape facultative. Elle nécessite un OI authentifié disposant de organization-admin role. Pour générer le rapport, exécutez la commande suivante :

  gdcloud system upgrade report-compliance

Pour en savoir plus sur les conditions de préparation, consultez la section Conditions préalables.

Identity and Access Management

Avant de commencer une mise à niveau, dans chaque zone :

Obtenez un fichier kubeconfig en exécutant gdcloud auth login sur le cluster d'administrateur racine et sur tous les clusters d'administrateur de l'organisation.
Suivez les instructions du runbook sur la procédure d'accès et d'élévation des privilèges IAM-R0005 pour ajouter :
1. ClusterRoleBinding avec le ClusterRole cluster-admin dans le cluster d'administrateur racine de chaque zone
2. org pour obtenir un accès administrateur temporaire.

Suspendre les mises à niveau des ressources mondiales dans toutes les zones

Utilisez le fichier kubeconfig obtenu pour suspendre toutes les mises à niveau des ressources globales dans chaque zone.

# Pause upgrades to global root admin resources.
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ROOT_ADMIN_KUBECONFIG

# Pause upgrades to global org admin resources.
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ORG_MGMT_API_KUBECONFIG

Mettre à niveau l'organisation racine globale

La mise à niveau de l'organisation racine globale comprend les étapes suivantes :

Mettez à niveau l'organisation racine dans toutes les zones. Chaque zone est mise à niveau individuellement.

Important : Commencez la mise à niveau par la zone principale StorageGrid, puis répétez l'opération pour toutes les autres zones du déploiement. Cet ordre est nécessaire pour que le stockage d'objets fonctionne correctement.

Vérifiez si la zone actuelle est la zone principale. La commande suivante renvoie "true" dans la zone principale et ne renvoie rien dans les zones non principales.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Mettez à niveau les composants qui nécessitent une coordination entre les zones.
Mettez à niveau les ressources d'administrateur racine global.

Vérification préalable à la mise à niveau

Mettez à niveau les zones une par une. Avant de commencer la mise à niveau d'une organisation dans une zone, connectez-vous à toutes les autres zones et exécutez la commande suivante pour vous assurer qu'elle renvoie "ready" (prêt) dans toutes les zones. Si une zone indique qu'elle n'est pas prête, ne procédez pas à la mise à niveau. Vérifiez l'organisation dans cette zone pour diagnostiquer le problème.

ORG_NAME=root

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

1. Télécharger et copier le package de mise à jour

Voici comment commencer :

Téléchargez un package de mise à jour sur un appareil ayant accès à Internet pour le copier sur une clé USB.
Copiez le package de mise à jour de la clé USB vers votre environnement isolé.

Pour plus de contexte, consultez Télécharger des fichiers pour télécharger les détails d'une distribution Distributed Cloud et Transférer le téléchargement pour en savoir plus sur le périphérique de stockage portable que vous utilisez pour transférer des fichiers vers votre environnement isolé.

Contactez votre point de contact Google pour déterminer si la mise à niveau concerne un déploiement Distributed Cloud géré par un partenaire et si vous devez donc utiliser les fichiers de version du modèle partenaire.

PARTNER_OPERATED="IS_PARTNER_OPERATED"
if [[ ${PARTNER_OPERATED:?} == "true" ]]; then
  RELEASE_SUFFIX="_partner"
  export GCS_BUCKET=private-cloud-release-partner
else
  RELEASE_SUFFIX=""
  export GCS_BUCKET=private-cloud-release
fi

Téléchargez le package de mise à jour sur votre clé USB depuis un ordinateur connecté à Internet. Utilisez les informations sur la version et le résumé fournies par votre contact Google.
1. Exécutez gcloud auth login pour accéder au bucket Cloud Storage.
2. Exécutez le script avec --skip-unzip pour récupérer le package de mise à jour et le script de téléchargement dans le répertoire actuel, par exemple /home/download.
```
VERSION=VERSION
DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
gcloud storage cp "gs://${GCS_BUCKET:-private-cloud-release}/$VERSION/$DOWNLOADER*" .
   PUBLIC_KEY=$(cat <<-PUBEND
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
-----END PUBLIC KEY-----
PUBEND
)
echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-unzip
```
3. Si vous effectuez une mise à niveau avec des fichiers de version de modèle partenaire, suivez les instructions pour préparer les packages logiciels pour la distribution de modèles partenaires.
  
  Remarque : Ignorez cette étape si vous n'utilisez pas de fichiers de version de modèle partenaire pour la mise à niveau.
Copiez le script de téléchargement et le répertoire gdch sur votre clé USB.
Copiez la mise à jour sur l'OCIT depuis votre clé USB. Placez les fichiers dans un emplacement similaire, par exemple /home/download/.

Redéfinissez ces variables sur l'OCIT et extrayez la mise à jour :

cd /root
VERSION=VERSION
DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
PUBLIC_KEY=$(cat <<-PUBEND
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
-----END PUBLIC KEY-----
PUBEND
)
echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-download

Le programme de téléchargement aura décompressé la version dans gdch/full-release-1.2.0-gdch.243 (par exemple, /home/download/gdch/full-release-1.2.0-gdch.243). Attribuez cette variable au chemin d'accès complet :
```
export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
```

2. Configurer la mise à niveau d'Artifact Registry

Pour effectuer une mise à niveau, vous devez procéder comme suit :

Transférer les artefacts vers le registre de conteneurs

Définissez KUBECONFIG sur le fichier kubeconfig du cluster d'administrateur racine.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Créez les ClusterRoleBindings nécessaires :

kubectl create clusterrolebinding io-upgrade-admin --clusterrole=upgrade-admin-dc --user=USER_EMAIL

kubectl create clusterrolebinding io-upgrade-debugger --clusterrole=upgrade-debugger --user=USER_EMAIL

Créez les RoleBindings nécessaires :

kubectl create rolebinding io-system-artifact-management-secrets-admin --role=system-artifact-management-secrets-admin --user=USER_EMAIL -n anthos-creds

kubectl create rolebinding io-system-artifact-management-admin --role=system-artifact-management-admin --user=USER_EMAIL -n gpc-system

kubectl create rolebinding io-dnssuffix-viewer --role=dnssuffix-viewer --user=USER_EMAIL -n gpc-system

Créez RoleBindings pour envoyer le bundle OCI :

kubectl create rolebinding infrastructure-operator-sar-harbor-admin --user=gdch-infra-operator-USER_EMAIL --role=sar-harbor-admin -n gpc-system

Le résultat ressemble à ceci :

rolebinding.rbac.authorization.k8s.io/infrastructure-operator-sar-harbor-admin created

Suivez les instructions de la section Redimensionner l'espace de stockage Artifact Registry pour effectuer les opérations suivantes :
1. Vérifiez l'utilisation du stockage d'Artifact Registry dans un cluster d'administrateur et assurez-vous qu'il y a suffisamment d'espace pour les artefacts que vous souhaitez transférer.
2. Si vous avez besoin d'augmenter l'espace disponible, suivez les étapes décrites dans Redimensionner l'espace de stockage Artifact Registry.
Configurez les configurations Docker :
```
cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
```
Remarque : Assurez-vous toujours que ce binaire est en place avant d'exécuter load-oci.

Configurez Docker pour qu'il approuve le bundle du magasin de confiance.

REGISTRY=$(kubectl get harborcluster harbor -n harbor-system -o jsonpath='{.spec.externalURL}' 2>/dev/null);
if [[ -z "$REGISTRY" ]]; then echo "Harbor external URL not found" >&2; exit 1; fi;

HOST=$(echo "$REGISTRY" | sed 's#https://##');
if [[ -z "$HOST" ]]; then echo "Invalid registry URL" >&2; exit 1; fi;

DIR="/etc/docker/certs.d/$HOST"; FILE="$DIR/ca.crt"; mkdir -p "$DIR"; chmod 755 "$DIR";
if [[ ! -f "$FILE" ]]; then
   CERT=$(kubectl get secret trust-store-internal-only -n istio-system -o jsonpath='{.data.ca\.crt}' 2>/dev/null);
   if [[ -z "$CERT" ]]; then echo "Certificate secret not found" >&2;
   exit 1;
   fi;
   echo "$CERT" | base64 -d > "$FILE"; chmod 644 "$FILE";
else echo "Certificate $FILE already exists"; fi

Chargez les artefacts dans le registre d'artefacts du cluster d'administrateur racine :

export VERSION=VERSION
export KUBECONFIG=KUBECONFIG_PATH
export ARTIFACTS_ROOT=/home/download/gdch/full-release-VERSION
export PACKAGE_VALIDATION_ROOT_CERT=PACKAGE_VALIDATION_ROOT_CERT_PATH

${ARTIFACTS_ROOT}/gdcloud auth configure-docker
${ARTIFACTS_ROOT}/gdcloud system container-registry load-oci ${ARTIFACTS_ROOT}/oci --pv-root-cert-path=PACKAGE_VALIDATION_ROOT_CERT_PATH --kubeconfig=KUBECONFIG_PATH --use-ip-port=true --show-progress=false

Remplacez les éléments suivants :

VERSION : version de la version Distributed Cloud. Exemple :1.x.y-gdch.z
KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig que vous avez obtenu en exécutant gdcloud auth login dans le cluster d'administrateur racine.
PACKAGE_VALIDATION_ROOT_CERT_PATH : chemin d'accès au certificat racine de validation du package. Vous devez utiliser le chemin d'accès par défaut ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt. L'inclusion de ce chemin d'accès valide les certificats de clé de version utilisés pour la validation des packages.

Si la commande a réussi, le résultat final doit ressembler à cet exemple :

I0911 04:05:01.755927 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bg4ck, starting time: 04:05:01.                                                  │·······
I0911 04:05:02.002637 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 246.689693ms                                              │·······
I0911 04:05:02.002723 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.039545 3463529 monitor.go:44] Created after 36.820059ms.                                                                                                         │·······
I0911 04:05:02.039599 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.045964 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 6.360571ms                                                │·······
I0911 04:05:02.045997 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.077418 3463529 monitor.go:44] Created after 31.408176ms.                                                                                                         │·······
I0911 04:05:02.077464 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.239086 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 161.610475ms                                              │·······
I0911 04:05:02.239138 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.248366 3463529 monitor.go:44] Created after 9.220575ms.                                                                                                          │·······
I0911 04:05:02.248415 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.532191 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 283.756574ms                                              │·······
I0911 04:05:02.532236 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.544529 3463529 monitor.go:44] Created after 12.282657ms.                                                                                                         │·······
I0911 04:05:02.544579 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.641252 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 96.652179ms                                               │·······
I0911 04:05:02.641332 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.645509 3463529 monitor.go:44] Created after 4.169293ms.                                                                                                          │·······
I0911 04:05:02.645575 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.839587 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.004999ms                                              │·······
I0911 04:05:02.839639 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.844001 3463529 monitor.go:44] Created after 4.361378ms.                                                                                                          │·······
I0911 04:05:02.844034 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
I0911 04:05:03.041615 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 197.567981ms                                              │·······
I0911 04:05:03.041675 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
I0911 04:05:03.047192 3463529 monitor.go:44] Created after 5.499407ms.                                                                                                          │·······
I0911 04:05:03.047292 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
I0911 04:05:03.241688 3463529 monitor.go:100] [76/76] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.395913ms

Si votre résultat ne ressemble pas à cet exemple, suivez ces étapes pour résoudre les problèmes les plus courants :

Si votre résultat inclut le message Package validation root certificate requires upgrade!, faites la rotation du certificat racine en suivant les étapes décrites dans Faire la rotation du certificat de validation du package.
Si load-oci échoue, exécutez à nouveau l'opération. Si l'erreur persiste, consultez les autres solutions proposées dans cette liste.
Si votre résultat inclut le message Error: unable to create k8sclient: Unauthorized, vous devez vous authentifier de nouveau. Répétez l'étape de préparation pour vérifier le fichier kubeconfig ou exécutez la commande ${ARTIFACTS_ROOT}/gdcloud auth login et réessayez l'opération load-oci.
Si votre résultat inclut le message UNAUTHORIZED: unauthorized to access repository, cela signifie que vous ne disposez pas des autorisations requises pour exécuter la commande load-oci. Escaladez ce problème pour obtenir les rôles nécessaires à l'exécution de cette commande, ou demandez à un utilisateur disposant des rôles requis d'exécuter cette commande en votre nom.

Pour la mise à niveau avec les fichiers de version du modèle partenaire UNIQUEMENT, suivez les instructions pour charger les packages logiciels pour la distribution du modèle partenaire.
Vérifiez que l'objet ReleaseMetadata pour la nouvelle version est dans le cluster d'administrateur racine :
```
kubectl get releasemetadata.artifact.private.gdc.goog VERSION
```
Remplacez VERSION par la version de Distributed Cloud. Exemple :1.x.y-gdch.z

Exemple de résultat :
```
NAME             AGE
1.x.y-gdch.z     2m
```
Vérifiez que la nouvelle version figure dans la liste des mises à niveau disponibles pour l'organisation racine à mettre à niveau :
```
ROOT_NAME=root
kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
```
Par exemple, pour 1.x.y-gdch.z, nous attendons le résultat suivant :
```
["1.x.y-gdch.z"]
```

Une fois l'organisation racine mise à niveau vers une nouvelle version, celle-ci devient disponible pour la mise à niveau d'une organisation locataire.

3. Mettre à niveau l'organisation racine

3.1. Avant la migration

Définissez KUBECONFIG sur le fichier kubeconfig du cluster d'administrateur racine.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Créez les ClusterRoleBindings nécessaires :

kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL

Vérifiez que l'organisation racine est en bon état, comme indiqué par la réponse True :

kubectl get organization -n gpc-system root \
    -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}{"\n"}'

Exemple de résultat :

True

Suivez les instructions du runbook HSM-P0003 pour redémarrer tous les HSM.

3.2. Effectuer des mises à niveau automatiques de l'organisation racine

La mise à niveau doit suivre le processus IaC. La mise à niveau est déclenchée en mettant à jour le champ de version dans l'objet OrganizationZonalConfig correspondant de l'organisation dans la zone.

Mettez à jour la version dans le fichier YAML OrganizationZonalConfig. Supprimez la section spec.capacities.workloadServers du fichier, le cas échéant.

ORG_NAME=root
ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/${ORG_NAME}/${ORG_NAME}-${ZONE}.yaml

Préproduisez et validez les modifications apportées au fichier.
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Créez une requête de fusion.

git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch

Lorsqu'une mise à niveau démarre, un objet OrganizationUpgrade est créé. Vérifiez que l'objet OrganizationUpgrade racine a été créé dans le cluster d'administrateur racine de la zone.

kubectl get -n gpc-system organizationupgrade root -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Si le OrganizationUpgrade n'est pas trouvé, suivez le runbook IAC-R0001 pour résoudre le problème.

3.3. Vérifications après la mise à niveau

Vérifiez les résultats de la mise à niveau :
1. Recherchez l'objet Organization pour l'organisation racine. Vérifiez que l'état READY est défini sur True :
```
kubectl -n gpc-system get organization root
```
  Exemple de résultat :
```
NAME   READY
root   True
```
2. Vérifiez que Organization.Status.Version affiche la chaîne exacte 1.x.y-gdch.z :
```
kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
```
  Exemple de résultat pour la validation :
```
1.13.3-gdch.5548
```

Recherchez les échecs de sous-composants dans l'organisation racine :

Recherchez les sous-composants dont l'état est ReconciliationError ou Reconciling. Faites pointer le fichier kubeconfig sur ROOT_ADMIN_KUBECONFIG :

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export CLUSTER_NAMESPACE=root
echo "Subcomponents with failures"
kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") | select(.status.featureDisabled != true) |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
echo "Subcomponents still reconciling"
kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select(.status.featureDisabled != true) | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

En cas d'erreur, consultez les notes de version et les problèmes connus pour trouver une solution de contournement. Sinon , contactez Distributed Cloud pour obtenir de l'aide.

Si la vérification préliminaire ou post-mise à niveau a été ignorée, supprimez les annotations une fois la mise à niveau terminée :

Exemples :

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check-

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check-

Terminer la mise à niveau de l'organisation racine dans toutes les zones

Une fois la mise à niveau terminée dans une zone, nous vous recommandons de vérifier que la zone fonctionne toujours correctement avant de passer à la mise à niveau de la zone suivante.

Répétez les étapes 1 à 3 pour l'organisation racine dans les autres zones. Lorsque l'organisation racine de toutes les zones a été mise à niveau, passez aux étapes suivantes.

4. Mettre à niveau les ressources globales

Les ressources globales doivent être dans la version la plus basse de toutes les zones. Lancez le processus de mise à niveau des ressources globales en vous connectant à la zone d'ancrage et en exécutant les commandes suivantes.

# Annotate appropriate versions for all the operable components.
MAP=$(kubectl get kubeapiserver root-admin -n root -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); KEY=${SPLIT[0]}; VALUE=${SPLIT[1]}
   echo "Annotating global KubeAPIServer with ${KEY}: ${VALUE}"
   kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite ${KEY}=${VALUE} --kubeconfig ROOT_ADMIN_KUBECONFIG
done

# Trigger the global resource upgrade on global root admin.
kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ROOT_ADMIN_KUBECONFIG
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ROOT_ADMIN_KUBECONFIG

Ce processus peut prendre quelques minutes. Vérifiez que les mises à niveau des ressources globales sont terminées en exécutant les commandes suivantes. Aucun échec ne doit être signalé par la commande.

# Verify that Components are all successfully rolled out on global root admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ROOT_ADMIN_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ROOT_ADMIN_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

5. Mises à niveau des composants interzones

Dans un univers multizone GDC, certains composants opérationnels nécessitent une coordination entre les zones pour effectuer leurs mises à niveau.

Les composants opérationnels suivants sont mis à niveau lors de cette étape.

Champ d'application	Composants actionnables
Infrastructure	IAC
Infrastructure	SIEM

Pour mettre à niveau le composant exploitable IAC, suivez le runbook IAC-R0016.

Pour mettre à niveau le composant SIEM, suivez le runbook SIEM-G0008.

6. Mise à niveau manuelle pour le sous-réseau Anycast

Exécutez le script suivant pour ajouter les libellés nécessaires aux sous-réseaux anycast dans le serveur d'API racine globale :

#!/bin/bash

# Description:
# This script ensures that specific Subnet resources in Kubernetes have the
# correct label applied. This is necessary for anycast features to function correctly.
#
# The script is idempotent and can be run multiple times safely.
# It requires the path to a valid global root kubeconfig file as a command-line argument.

# --- Configuration ---
set -o nounset

# The names of the Subnet resources to update.
readonly SUBNET_NAMES=(
  "infra-vpc-anycast-cidr"
  "data-global-anycast-cidr"
  "admin-global-anycast-cidr"
)

# The label that will be applied to the subnets.
readonly LABEL_KEY="ipam.gdc.goog/usage"
readonly LABEL_VALUE="global-anycast-root-range"

# The Kubernetes resource type for the subnets.
readonly SUBNET_RESOURCE_TYPE="subnets"

# Timeout for kubectl commands in seconds.
readonly KUBECTL_TIMEOUT="30s"

log_error() {
  echo "[ERROR] $(date +'%Y-%m-%dT%H:%M:%S%z'): $*" >&2
}

main() {
  # --- Argument Validation ---
  if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <path-to-kubeconfig-file>"
    echo "Example: $0 /root/release/root-admin/global-root-admin-kubeconfig"
    exit 1
  fi

  local KUBECONFIG_PATH="$1"

  if [[ ! -f "${KUBECONFIG_PATH}" ]]; then
      log_error "Kubeconfig file not found at: ${KUBECONFIG_PATH}"
      exit 1
  fi

  if ! command -v kubectl &> /dev/null; then
    log_error "kubectl command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  if ! command -v timeout &> /dev/null; then
    log_error "timeout command not found. Please ensure 'coreutils' is installed."
    exit 1
  fi

  if ! command -v jq &> /dev/null; then
    log_error "jq command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  echo "Starting Subnet labeling process using kubeconfig: ${KUBECONFIG_PATH}"

  # --- Pre-flight Check and Data Fetch ---
  echo "Verifying access and fetching all Subnet resources (timeout in ${KUBECTL_TIMEOUT})..."
  local all_subnets_json

  if ! all_subnets_json=$(timeout "${KUBECTL_TIMEOUT}" kubectl get --kubeconfig="${KUBECONFIG_PATH}" "${SUBNET_RESOURCE_TYPE}" --all-namespaces -o json 2>/dev/null); then
      log_error "Failed to list Subnet resources. The command timed out or returned an error. Please check cluster connectivity and permissions."
      exit 1
  fi

  if [[ -z "${all_subnets_json}" ]] || [[ $(jq '.items | length' <<< "${all_subnets_json}") -eq 0 ]]; then
      echo "No subnet resources found in the cluster. Exiting."
      exit 0
  fi
  echo "Access verified. Processing subnets..."

  local processed_count=0
  local found_count=0
  local subnet_regex
  subnet_regex=$(printf "|%s" "${SUBNET_NAMES[@]}")
  subnet_regex="^(${subnet_regex:1})$"

  # jq query to output: namespace  name  label_value (or null)
  echo "${all_subnets_json}" | jq -r ".items[] | [.metadata.namespace, .metadata.name, (.metadata.labels | .[\"${LABEL_KEY}\"] // \"\")] | @tsv" |
  while IFS=$'\t' read -r namespace name current_value; do
    if [[ -z "${name}" ]]; then continue; fi

    if [[ ! "${name}" =~ ${subnet_regex} ]]; then
        continue
    fi

    ((found_count++))
    echo "Found target subnet: '${name}' in namespace '${namespace}'"

    if [[ "${current_value}" == "${LABEL_VALUE}" ]]; then
        echo "  - Subnet already has the correct label. Skipping."
        ((processed_count++))
        continue
    fi

    echo "  - Applying label '${LABEL_KEY}=${LABEL_VALUE}'..."
    if ! timeout "${KUBECTL_TIMEOUT}" kubectl label --kubeconfig="${KUBECONFIG_PATH}" --namespace="${namespace}" "${SUBNET_RESOURCE_TYPE}" "${name}" "${LABEL_KEY}=${LABEL_VALUE}" --overwrite > /dev/null; then
        log_error "Failed to apply label to subnet '${name}' in namespace '${namespace}'. The command timed out or returned an error."
    else
        echo "  - Successfully labeled subnet."
        ((processed_count++))
    fi
  done

  # --- Final Summary ---
  echo "---"
  if [[ ${found_count} -eq 0 ]]; then
    echo "No target anycast subnets were found in the cluster."
  else
    echo "Finished processing. Found ${found_count} and validated ${processed_count} target subnet(s)."
  fi

  echo "Subnet labeling process completed."
}

# Execute the main function with command-line arguments.
main "$@"

Une fois le script exécuté, rétablissez la solution de contournement Anycast manuel si elle a été appliquée précédemment.

7. Mise à niveau manuelle pour SyncServer

Les composants opérationnels suivants sont mis à niveau lors de cette étape.

Champ d'application	Composants actionnables
Infrastructure	NTP

Cette mise à niveau du micrologiciel ne dépend d'aucune autre étape et peut être effectuée à tout moment.

Le cluster ne comporte qu'un seul SyncServer. Il ne peut donc pas fonctionner en mode haute disponibilité. La mise à niveau rendra le SyncServer indisponible pendant un certain temps. Le cluster continuera à utiliser ses propres horloges, moins précises, sans que cela ait d'effet notable.

Il est recommandé de terminer ce processus en une seule fois (et non de le laisser inachevé pendant la nuit ou un week-end) pour éviter toute dérive temporelle.

7.1. Processus de mise à niveau de SyncServer

Les commandes suivantes doivent être exécutées à partir du répertoire de version du package de mise à jour extrait.

Recherchez le dernier micrologiciel à extraire :

${ARTIFACTS_ROOT}/gdcloud artifacts tree ${ARTIFACTS_ROOT}/oci/ | grep syncserver | grep -v .sig$

Le nom du fichier contient la version du micrologiciel.

Exemple de résultat :

│   ├── gdch-syncserver-firmware/syncserver:5.1.2

Copiez uniquement les noms de fichiers et attribuez-les à ces variables :
```
export SYNCSERVER_VERSION=syncserver:5.1.2
```

Extrayez le micrologiciel de l'image OCI :

${ARTIFACTS_ROOT}/gdcloud artifacts extract ${ARTIFACTS_ROOT}/oci syncserver_firmware --image-name=gdch-syncserver-firmware/${SYNCSERVER_VERSION:?}

Extrayez le micrologiciel :
```
tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
```
Vous devriez voir un fichier *.dat et un fichier *updater.zip dans le répertoire de sortie.
Suivez le runbook NTP-P0002 : accédez à l'interface utilisateur SyncServer.
1. Accédez à Aide > À propos > Version du logiciel. Si le logiciel installé est identique ou postérieur au micrologiciel fourni, il n'est pas nécessaire de mettre à jour le micrologiciel et vous pouvez ignorer les étapes suivantes.
2. Accédez à Admin > Upgrade (Admin > Mise à niveau) dans l'interface utilisateur SyncServer. Importez syncserver_s650_license.dat dans Authorization File et syncserver_s650_updater.zip dans Upgrade File. Cliquez ensuite sur "Installer".

Mettre à niveau une organisation locataire globale

La mise à niveau d'une organisation locataire mondiale comprend les étapes suivantes :

Mettez à niveau l'organisation locataire dans toutes les zones. Chaque zone est mise à niveau individuellement.

Important : Commencez la mise à niveau par la zone principale StorageGrid, puis répétez l'opération pour toutes les autres zones du déploiement. Cet ordre est nécessaire pour que le stockage d'objets fonctionne correctement.

Vérifiez si la zone actuelle est la zone principale. La commande suivante renvoie "true" dans la zone principale et ne renvoie rien dans les zones non principales.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Mettez à niveau les ressources de l'organisation locataire globale.

Vérification préalable à la mise à niveau

ORG_NAME=ORG_NAME

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

Assurez-vous que tous les clusters sont en cours d'exécution et que tous les pools de nœuds sont prêts. Si ce n'est pas le cas, corrigez-les avant de commencer la mise à niveau.

ORG_NAME=ORG_NAME
kubectl get nodepools -n ${ORG_NAME} --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE   NAME                                        READY
# org1        admin-control-plane-node-pool               True
# org1        data-plane-pool-o2-standard1-96-gdc-metal   True

kubectl get cluster -n mks-system --kubeconfig ORG_MGMT_API_KUBECONFIG
# Example output
# NAME                    STATE     K8S VERSION
# g-org1-perimeter        Running   1.30.6-gke.300
# g-org1-shared-service   Running   1.30.6-gke.300

kubectl get nodepool -A --kubeconfig ORG_INFRA_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE                       NAME                                                     READY
# g-org1-perimeter-cluster        control-plane-node-pool                                  True
# g-org1-perimeter-cluster        perimeter-admin-node-pool                                True
# g-org1-perimeter-cluster        perimeter-data-node-pool                                 True
# g-org1-shared-service-cluster   control-plane-node-pool                                  True
# g-org1-shared-service-cluster   dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   True
# g-org1-shared-service-cluster   shared-service-default-worker                            True

1. Mettre à niveau une organisation locataire

Cette étape met à niveau la version de Kubernetes, les modules complémentaires et les composants opérationnels sur les clusters du plan de gestion d'une organisation locataire (clusters org-admin, système et de service).

La durée globale de la mise à niveau dépend du nombre d'étapes qu'elle comporte. La mise à niveau automatique de l'organisation locataire peut être perturbante et nécessite un intervalle de maintenance.

1.1. Préparation

Pour configurer des intervalles de maintenance, suivez la procédure décrite dans Configurer des intervalles de maintenance pour la mise à niveau de l'organisation locataire.

Les instructions pour lancer la mise à niveau d'une organisation locataire sont fournies pour l'utilisation des commandes de la CLI kubectl ou des commandes Infrastructure as Code (IaC). Pour utiliser les commandes IaC, configurez d'abord IaC :

Configuration de l'infrastructure en tant que code
Configurer l'infrastructure en tant que code

Pour utiliser nomos afin de vérifier l'état, comme indiqué dans les étapes basées sur l'IaC, vous devez avoir installé l'outil de ligne de commande nomos. Pour obtenir des instructions sur l'installation et l'utilisation de nomos, accédez à https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command depuis un ordinateur connecté à Internet.

IaC

Définir le clusterrolebinding avant de commencer la mise à niveau de l'organisation locataire à l'aide d'IAC

Accédez au répertoire iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
Accédez au répertoire IO déjà créé. Si le répertoire n'existe pas, créez-en un.

Ajoutez un fichier YAML pour attribuer le rôle de cluster io-organization-admin à l'IO. Exemple :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: iac-binding-$USER-io-organization-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: io-organization-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: USER_EMAIL

Mettez à jour le fichier kustomatization.yaml pour inclure le nouveau fichier créé. Si le fichier kustomatization.yaml n'existe pas, créez-en un :
```
kind: Kustomization
metadata:
  name: org-1-admin-kustomization
resources:
- FILE_NAME.yaml
```
Envoyer les modifications dans IAC

kubectl

Définissez le clusterrolebinding avant de commencer la mise à niveau de l'organisation locataire à l'aide de kubectl.

Définissez KUBECONFIG sur le fichier kubeconfig du cluster d'administrateur racine.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
```

Créez les ClusterRoleBindings nécessaires :

kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL`

Avant de passer d'une version antérieure de Distributed Cloud à la version 1.13.x ou ultérieure, suivez les instructions du runbook BIL-R0014 pour générer manuellement une facture pour les coûts de ce mois, du début du mois au début de la date du jour. Vous perdrez les données de coût créées lors du processus de mise à niveau de l'organisation Distributed Cloud.

1.2. Lancer la mise à niveau

La mise à niveau de l'organisation locataire est également déclenchée par l'IaC en mettant à jour le champ de version dans l'objet OrganizationZonalConfig correspondant de l'organisation dans la zone. Voici les détails :

Mettez à jour la version dans le fichier YAML OrganizationZonalConfig.

ORG_NAME=ORG_NAME
ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/root/${ORG_NAME}-${ZONE}.yaml

Préproduisez et validez les modifications apportées au fichier.
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Créez une requête de fusion.

git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch

Si la mise à niveau est lancée, un objet OrganizationUpgrade est créé. Vérifiez que l'objet OrganizationUpgrade a été créé dans le cluster d'administrateur racine de la zone.

kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Si le OrganizationUpgrade n'est pas trouvé, suivez le runbook IAC-R0001 pour résoudre le problème.

1.3. Mettre à niveau

La mise à niveau s'effectue lorsque son timeWindow se situe dans l'intervalle de maintenance spécifié par un utilisateur administrateur, également appelé PA. Affichez l'timeWindow programmé :

kubectl -n gpc-system get organizationupgrade ORG_NAME -o yaml

Voici une réponse typique à la commande précédente :

apiVersion: upgrade.private.gdc.goog/v1alpha1
kind: OrganizationUpgrade
metadata:
  creationTimestamp: "2022-08-22T01:09:03Z"
  generation: 1
  name: org-1
  namespace: gpc-system
  ownerReferences:
  - apiVersion: resourcemanager.gdc.goog/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Organization
    name: org-1
    uid: 6998cfc1-bee4-4f6d-baf2-9c0a90ef93bb
  resourceVersion: "1214182"
  uid: 1affc1df-b9ac-4343-8e61-18736781a990
spec:
  currentVersion: 1.8.0-gdch.476
  organizationRef:
    name: org-1
  targetVersion: 1.8.1-gdch.0
  timeWindow:
    end: "2022-08-28T04:00:00Z"
    start: "2022-08-28T00:00:00Z"

Dans l'exemple précédent, la mise à niveau vers 1.8.1-gdch.0 est prévue entre le "2022-08-28T00:00:00Z" et le "2022-08-28T04:00:00Z".

Lorsque la mise à niveau commence, un objet OrganizationUpgrade est créé et s'affiche sous la forme kind: OrganizationUpgrade dans l'exemple de sortie précédent.

kind: OrganizationUpgrade

Surveillez l'état général de la mise à niveau à l'aide de l'objet de mise à niveau correspondant, en ajoutant la commande de l'étape 1 avec -w. Par exemple, pour interroger en continu ORG_NAME sur l'état de la mise à niveau, exécutez la commande suivante :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
```
Vous pouvez consulter les étapes de la mise à niveau et leur état à l'aide des éléments suivants :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o jsonpath='{.status.conditions}' | \
jq -r '["Stage", "Status", "Reason", "Message"], ["---", "---", "---", "---"], (.[] | [.type, .status, .reason, .message]) | @tsv' | column -ts $'\t'
```
L'étape Succeeded fait référence à l'état global de la mise à niveau. L'étape Expired indique que la migration a dépassé le délai initialement prévu. Toutes les autres étapes font référence aux étapes de la mise à niveau en cours. L'état True fait référence aux étapes terminées, tandis que l'état Unknown fait référence à l'étape actuelle de la mise à niveau.

Si une vérification préliminaire a échoué et que vous êtes certain qu'il s'agit d'un faux positif, remplacez et ignorez les options de vérification préliminaire :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check=ok
```
Si un post-contrôle a échoué et que vous êtes certain qu'il s'agit d'un faux positif, remplacez et ignorez les post-contrôles :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check=ok
```
Si l'IAC a été utilisée pour mettre à niveau l'organisation locataire et que l'état organizationupgrade indique "Réussie" et que Organization pour l'organisation locataire n'est pas à l'état "Prêt", appliquez la solution de contournement suivante.

Ajoutez l'annotation suivante : configmanagement.gke.io/managed: disabled à l'aide d'IAC à l'organisation. L'état du Organization de surveillance est "Ready" (Prêt).

La mise à niveau de l'organisation devrait maintenant passer à l'étape suivante, et l'état du service ou du nœud sera "Terminé" :

Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

La mise à niveau de l'organisation peut prendre 15 minutes.

1.4. Vérifications après la mise à niveau

Vérifiez l'objet Organization pour l'organisation. La condition READY doit être définie sur True.
```
kubectl -n gpc-system get organization ORG_NAME
```
Exemple de résultat :
```
NAME   READY
org-1  True
```
Consultez Organization.Status.Version. Il doit afficher la chaîne exacte de la version cible :
```
kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
```
Exemple de résultat :
```
1.13.3-gdch.5548
```
Important : Si vous avez déclenché une mise à jour non planifiée en utilisant l'annotation pour ignorer un intervalle de maintenance, vous devez la rétablir pour utiliser des intervalles de temps planifiés.

Rétablissez l'annotation pour ignorer les intervalles de maintenance :
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
    "upgrade.private.gdc.goog/ignore-maintenance-window-" \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG
```

Recherchez les échecs de sous-composants dans l'organisation locataire mise à niveau :

Recherchez les sous-composants dont l'état est ReconciliationError ou Reconciling. Faites pointer le fichier kubeconfig sur ORG_MGMT_API_KUBECONFIG :

export KUBECONFIG=ORG_MGMT_API_KUBECONFIG

echo "Subcomponents with failures"
kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
echo "Subcomponents still reconciling"
kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

En cas d'erreur, consultez les notes de version et les problèmes connus pour trouver une solution de contournement. Sinon, contactez Distributed Cloud pour obtenir de l'aide.

Si la vérification préliminaire ou post-mise à niveau a été ignorée, supprimez les annotations une fois la mise à niveau terminée :

Exemples :

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check-

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check-

1.5. Lancer une mise à niveau non programmée

Déclenchez une mise à niveau instantanée de l'organisation locataire en dehors d'un maintenanceWindow si vous avez un besoin urgent, comme une mise à jour de sécurité urgente. Cette opération n'est nécessaire que dans l'organisation locataire, car l'organisation racine déclenche déjà la mise à niveau instantanément.

Exécutez cette commande à l'aide de l'administrateur racine kubeconfig. La ressource personnalisée de l'organisation que vous devez annoter n'est présente que dans le cluster root-admin. Vous ne planifiez pas de plage horaire pour ce processus.

Corrigez l'organisation spec/version pour l'organisation locataire :

export VERSION=$(kubectl get releasemetadata -ojson | jq -r '.items[] | select(.metadata.name | contains("1.13.3")) | .metadata.name')
echo $VERSION

# Example output
# 1.13.3-gdch.5548

kubectl patch -n gpc-system organization ORG_NAME --type='json' \
  -p='[{"op":"replace","path":"/spec/version","value":"'${VERSION}'"}]' \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG

Lancez un tenant-org upgrade instantané en appliquant l'annotation ignore-maintenance-window et en redémarrant organizationupgrade.

Remarque : Si la mise à niveau génère une erreur, appliquez la même commande plusieurs fois.

Surveillez l'état de la mise à niveau :

# kubectl -n gpc-system get organizationupgrade org-1 -o yaml

Effectuez les vérifications post-mise à niveau.
Une fois la mise à niveau urgente terminée, revenez aux créneaux horaires planifiés :
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
      "upgrade.private.gdc.goog/ignore-maintenance-window-" \
      --kubeconfig=ROOT_ADMIN_KUBECONFIG
```
Remarque : Si la mise à niveau du DNS échoue, consultez DNS R0006 pour résoudre le problème.

2. Mise à niveau du DNS

2.1 Créer des zones de transfert

Exportez kubeconfig pour le cluster d'administrateur racine :

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

Configurez OCIT_DOMAIN à l'aide d'une zone de transfert. Remplacez OCIT_DOMAIN par votre nom de domaine OCIT et les points de terminaison par les adresses IP DNS OC :

kubectl apply -f - <<EOF
apiVersion: network.private.gdc.goog/v1alpha1
kind: DNSZone
metadata:
  namespace: dns-system
  name: ocit-domain
spec:
  domainName: OCIT_DOMAIN
  forwardingConfig:
    # Set to OC DNS IPs (the AD domain controllers)
    endpoints:
      - 192.0.2.0
      - 192.0.2.1
    replicateToTenantOrg: true
EOF

Le résultat ressemble à cet exemple :

dnszone.network.private.gdc.goog/ocit-domain created

Si les modifications ne sont pas appliquées, redémarrez le déploiement :
```
kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
```
Cette modification du DNS se propage à tous les clusters du GDC.

Avec le fichier kubeconfig de l'administrateur racine, vérifiez que la résolution du domaine OCIT fonctionne comme prévu :

NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-forwarder-udp | \
  awk '/[0-9]\./ {print $4}')
dig +short @${NAMESERVER} fs.OCIT_DOMAIN

Exportez kubeconfig pour le cluster d'administrateur de l'organisation :
```
export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
```

Appliquez le fichier kubeconfig de l'administrateur de l'organisation et vérifiez que la résolution du domaine OCIT fonctionne comme prévu :

NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-infra-forwarder | \
  awk '/[0-9]\./ {print $4}')
dig +short @${NAMESERVER} fs.OCIT_DOMAIN

2.2 Activer le résolveur récursif

Activez le résolveur récursif dans le cluster d'administrateur de l'organisation pour les organisations v1 uniquement, en suivant les étapes du runbook DNS-R0027.

Terminer la mise à niveau de l'organisation locataire dans toutes les zones

Une fois la mise à niveau terminée dans une zone, nous vous recommandons de vérifier que la zone fonctionne toujours correctement avant de passer à la mise à niveau de la zone suivante.

Répétez les étapes 1 et 2 pour l'organisation locataire dans les autres zones. Lorsque l'organisation locataire de toutes les zones a été mise à niveau, passez aux étapes suivantes.

3. Mettre à niveau les ressources globales

# Annotate appropriate versions for all the operable components.
ORG_NAME=ORG_NAME
MAP=$(kubectl get kubeapiserver ${ORG_NAME}-admin -n ${ORG_NAME} -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

# Trigger the global resource upgrade on global org admin.
kubectl annotate kubeapiserver global-org-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ORG_MGMT_API_KUBECONFIG
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ORG_MGMT_API_KUBECONFIG

# Verify that Components are all successfully rolled out on global org admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ORG_MGMT_API_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ORG_MGMT_API_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

Remarque : Les sous-composants portant le nom back-lancer-agent-user-cp dans le serveur de l'API Management à l'état ReconciliationError doivent être supprimés manuellement pour activer les sauvegardes dans les clusters d'utilisateur ou partagés.

4. Mettre à niveau Tenable SC

Exécutez GDCH doctor pour déterminer si une mise à niveau est requise :

  gdcloud system doctor diagnose instance --include-ocs=vuln --root-admin-kubeconfig=${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}

Si le validateur tenable_sc_upgrade_readiness échoue, l'image doit être mise à niveau. Pour mettre à niveau Tenable SC dans l'organisation des services OI, procédez comme suit :

Obtenez le nom de la machine virtuelle :

 VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)

Marquez le runningState de la machine virtuelle comme Stopped :

 kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'

Désinstallez le chart Helm existant pour la VM :

 VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)
 kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'
 helm uninstall tenablesc-vms -n tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}

Configurez Tenable SC en suivant les instructions de la section Installer Tenable.SC.

Nettoyage après la mise à niveau

Supprimez les ressources ClusterRoleBinding créées dans la section Identity and Access Management.

Configurer des intervalles de maintenance pour la mise à niveau de l'organisation locataire

Pour mettre à niveau une organisation locataire, vérifiez que les rôles de lecteur et d'administrateur appropriés vous ont été attribués, comme indiqué sur les pages Descriptions des rôles prédéfinis et Définitions des rôles pour les projets. Vous pourrez ainsi vous connecter à l'interface de ligne de commande (CLI) kubectl et à l'interface utilisateur (UI) de la console. Si vous ne les avez pas, suivez les instructions de la page Accorder l'accès aux ressources du projet pour les accorder ou demander à ce qu'elles vous soient accordées.

Pour configurer votre intervalle de maintenance, vous devez disposer des rôles requis. Assurez-vous que les rôles prédéfinis suivants vous sont attribués :

Administrateur de la mise à niveau de l'organisation
Lecteur de mise à niveau de l'organisation Remarque : Il n'est pas possible de mettre à niveau une organisation locataire vers une version mineure inférieure à celle de l'organisation racine.

Par défaut, il existe un MaintenanceWindow pour les mises à niveau mineures et un MaintenanceWindow pour les mises à niveau correctives. Les mises à niveau mineures améliorent les fonctionnalités ou apportent des modifications par rapport à la révision précédente, ce qui correspond à une mise à niveau du package (par exemple, pour corriger des bugs). Les mises à niveau correctives résolvent des problèmes ou des failles spécifiques. Configurez le correctif par défaut MaintenanceWindow pour lancer les mises à niveau des correctifs selon une planification définie.

Pour configurer la période de maintenance, utilisez les commandes CLI et kubectl pour modifier les champs RRULE et TimeWindow des ressources MaintenanceWindow. Vos mises à niveau sont alors planifiées. Pour en savoir plus sur RRULE, consultez https://pkg.go.dev/github.com/teambition/rrule-go.

Pour utiliser les commandes de la CLI kubectl, cliquez sur l'onglet kubectl. Pour afficher les instructions basées sur l'UI, cliquez sur l'onglet "Console".

Console

Connectez-vous à l'UI de l'organisation.
Modifiez le calendrier de l'intervalle de maintenance. Accédez à l'onglet Maintenance, puis cliquez sur Modifier.

Important : Si vous êtes un utilisateur administratif, vous devez disposer du rôle Administrateur de la mise à niveau de l'organisation pour modifier MaintenanceWindow et du rôle Lecteur de la mise à niveau de l'organisation pour afficher les mises à niveau planifiées :

Figure 1 : Intervalle de maintenance
L'écran Modifier les intervalles de maintenance s'ouvre. Utilisez la fenêtre pour reconfigurer les fenêtres temporelles Patch et Minor :

Figure 2. Reconfigurer les correctifs et les mises à jour mineures

Remarque : Le champ Récurrence pour Version mineure indique la première, la deuxième, la troisième, la quatrième ou la dernière occurrence du Jour spécifié. Lorsqu'un mois ne comporte que quatre occurrences d'un certain jour, la dernière et la quatrième sont équivalentes.
Spécifiez ou modifiez la version du correctif, l'heure de début et la durée, ainsi que le jour de la semaine.

Modifiez l'heure de début, la durée, la récurrence et le jour de la version mineure.

Figure 3. Enregistrer votre reconfiguration
Cliquez sur Enregistrer pour appliquer les modifications.
Si les modifications enregistrées affectent la récurrence (par exemple, si vous avez modifié le jour de la semaine ou le mois), une boîte de dialogue s'affiche. Pour confirmer vos modifications, cliquez sur CONTINUER.

Figure 4. Cliquez sur "Continuer".
L'exemple suivant montre les mises à niveau planifiées mises à jour, en fonction des modifications de configuration. Notez le lien Ignorer à côté de chaque état "En attente". Utilisez cette option pour ignorer une mise à niveau planifiée en attente.

Figure 5 : Affichage des mises à niveau planifiées, avec une option d'ignorance pour chacune

kubectl

Connectez-vous à la CLI kubectl. Retrouvez ces instructions dans l'onglet "CLI". Avant de continuer, assurez-vous de disposer des accès appropriés au cluster d'administrateur de l'organisation.

Vous pouvez modifier trois champs dans MaintenanceWindow pour configurer le timeWindow dans lequel la mise à niveau de l'organisation locataire a lieu. Les commandes suivantes montrent une modification de la période de maintenance de mise à niveau corrective. La modification des mises à niveau mineures est similaire.

# 1. The first change is to the RRULE
# For patch-upgrades to happen, for example, every Thursday instead of Sunday:
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/recurrence","value":"FREQ=WEEKLY;BYDAY=TH"}]'

# 2. Modify the start time of the upgrade in UTC.
export S_TIME = 2022-04-03T04:00:00Z
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/timeWindow/start","value":"'${S_TIME}'"}]'

# 3. Modify the end time of the upgrade in UTC.
export E_TIME = 2022-04-03T04:00:00Z
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/timeWindow/end","value":"'${E_TIME}'"}]'

Les heures de début et de fin, /spec/timeWindow/start et /spec/timeWindow/end respectivement, doivent chacune comporter une date/un mois/une année antérieurs. La période est calculée en fonction des valeurs que vous saisissez.

Allouez au moins la durée minimale indiquée pour chacun des types de mise à niveau. Vous pouvez allouer une durée plus longue, comme indiqué dans les recommandations suivantes :

Mises à niveau mineures : nécessitent au moins 12 heures sur une période glissante de 32 jours.
Mises à niveau des correctifs : nécessitent au moins 48 heures sur une période glissante de 32 jours, avec un ou plusieurs créneaux horaires. Bien que la console indique une durée minimale de quatre heures, Google vous recommande d'allouer au moins six heures à chaque créneau horaire.

Important : La mise à niveau du correctif peut ne pas prendre six heures entières, mais Google recommande d'allouer ce laps de temps pour tenir compte des éventuels processus de correctif longs.

Mise à niveau manuelle de l'infrastructure Operations Suite Core

Cette procédure de mise à niveau ne s'applique qu'à la mise à niveau de la version 1.13.x vers la version 1.14.3.

Assurez-vous que tous les comptes de domaine gérés et locaux sont activés et que leurs mots de passe ne sont pas expirés. Les comptes qui ne sont pas en bon état peuvent entraîner des erreurs lors de ce processus.

Effectuer des points de contrôle de VM et des sauvegardes de répertoire

Effectuez des points de contrôle de VM.

Sur l'hôte BM01, ouvrez une console PS en tant qu'administrateur.

Exécutez la commande suivante pour chaque hôte Hyper-V du cluster.

$servername = "<*hyperv-server-name*>"
Get-VM -CimSession $servername  | ForEach-Object {
$myargs = @{
VMName = $_.Name
SnapshotName = "Checkpoint_$($_.Name)_$(Get-Date -Format 'yyyyMMddHHmmss')"
ComputerName = $servername
}
Checkpoint-VM @myargs
}

Laissez la fenêtre PowerShell ouverte pour les prochaines étapes.

Activer les chemins d'accès longs aux fichiers

  $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
  Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1

Sauvegardez le lecteur H:\operations_center. (Cette action permet de revenir à la version précédente.)
```
  Rename-Item -Path H:\operations_center -NewName operations_center_backup
```
Sauvegardez les répertoires de configuration sur CONFIG1. (Cette sauvegarde sert de référence lors de la création de la nouvelle configuration config.ps1.)
1. Sur l'hôte BM01, utilisez le protocole RDP (Remote Desktop Protocol) pour vous connecter à l'adresse IP de la VM CONFIG1 et connectez-vous avec un compte administrateur système. Exemple : mstsc /v 192.168.100.99
2. Ouvrez une console PS avec l'option Exécuter en tant qu'administrateur.
  - Créer le dossier de sauvegarde
```
mkdir c:\config1_backup
```
  - Sauvegarder C:\dsc
```
Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
```
  - Sauvegarder C:\config
```
Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
```
  - Sauvegarder C:\operations_center
```
Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
```
  - Assurez-vous que les chemins d'accès longs aux fichiers sont activés.
```
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
```

Charger des logiciels tiers

Effectuez les tâches dans le logiciel tiers.

Mettre à niveau les machines virtuelles existantes

Obtenez le répertoire d'installation.
1. Téléchargez le bundle de composants OIC en suivant les instructions de la section Télécharger des fichiers.
  
  Remarque : Si votre environnement est isolé, vous devrez copier le fichier *.tar.gz sur une clé USB pour le transférer.
2. Sur l'hôte BM01, extrayez le répertoire operations_center du fichier prod_IT_component_bundle.tar.gz téléchargé.
  
  Remarque : L'exécution de tar.exe sous Windows extrait les fichiers dans le répertoire de travail actuel. Copiez le fichier sur le lecteur H avant de l'extraire.
```
Set-Location H:
tar -zxvf prod_IT_component_bundle.tar.gz
```
  L'extraction du fichier TAR devrait créer un dossier release à la racine de H:.
3. Déplacez operations_center vers la racine de H :
```
Move-Item -Path H:\release\operations_center -Destination H:\
```
Mettez à jour config.ps1 avec des données spécifiques au site.

Le fichier de configuration config.ps1 fournit toutes les informations nécessaires pour créer et configurer l'environnement Operations Suite Infrastructure (OI). Pour mettre à jour le fichier de configuration, vous devez collecter toutes les informations suivantes. La sauvegarde du fichier config.ps1 existant est une bonne référence pour éviter l'écrasement involontaire des paramètres existants. Important : N'allez pas plus loin tant que config.ps1 n'est pas terminé et correct.
- La configuration réseau générée par l'outil occonfigtool, en particulier le fichier ocinfo.common.opscenter.local.txt. Les noms de réseau, par exemple OCCORE-SERVERS, mentionnés dans les étapes suivantes font référence à la colonne Name de ce document.
- Nom de domaine et adresse IP du serveur DNS de chaque cellule GDC gérée par cette instance d'identité. Ces données sont disponibles dans les résultats du questionnaire d'accueil des clients.
Apportez toutes les modifications sur l'hôte BM01 en tant que Administrator.
Copiez le code d'exemple de configuration approprié pour le type de déploiement :
1. Copiez H:\operations_center\dsc\config.example.ps1 dans H:\operations_center\config\config.ps1.
À l'aide de VSCode ou de PowerShell ISE, validez et mettez à jour les valeurs dans config.ps1.
1. Si OIC est déployé en tant que multisite :
  1. Rechercher les commentaires associés au libellé ### Multi-Site:
  2. Effectuez les actions décrites dans les commentaires que vous avez trouvés.
2. Mettez à jour HardwareVersion, sauf si la valeur par défaut (3.0) est correcte.
3. Mettez à jour PrimarySiteCode, sauf si la valeur par défaut (DC1) est correcte.
4. Le code du site est utilisé dans de nombreux noms. Recherchez et remplacez toutes les instances de DC1 par le code de site correct. Utilisez une recherche non sensible à la casse. Examinez chaque modification, car certaines ne sont peut-être pas nécessaires. Par exemple, si le code du site est AB1, le nom d'hôte DC1-DC1 doit être remplacé par AB1-DC1, et non AB1-AB1.
5. Mettez à jour DnsDomain si la valeur par défaut n'est pas correcte. Si cette valeur est modifiée, recherchez et remplacez opscenter.local dans tout le fichier config.ps1. Cette valeur par défaut est codée en dur à plusieurs endroits.
6. Mettez à jour les objets dans DnsConditionalForwarder avec des informations spécifiques au site. Il doit y avoir au moins un objet de transfert. Supprimez les exemples inutiles.
  
  Cette étape peut être effectuée dans WSL sur CONFIG1 si les CLI gdcloud et kubectl sont installées.
  
  Pour extraire des informations spécifiques à un site à partir du cluster d'administrateur racine, utilisez la commande suivante :
```
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
kubectl get -n dns-system service gpc-coredns-external-udp \
            -o jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'
```
  1. Domain : nom de domaine DNS de la cellule GDC (par exemple, dns.delegatedSubdomain dans ciq.yaml).
  2. Master : liste des adresses IP des serveurs DNS (généralement une seule). Recherchez DNSReservation de type DNSReservation dans cellcfg. Si la cellule GDC est déployée, recherchez l'adresse EXTERNAL-IP du service gpc-coredns-external-udp et le nom de domaine complet (FQDN) de la cellule bert.sesame.street dans l'espace de noms dns-system du cluster d'administration racine.
  3. Dans les déploiements multisites, il existe un objet de table de hachage par cellule.
7. Ne modifiez pas le contenu des objets Users, Groups et GroupPolicy.
8. Mettez à jour DNSServers pour qu'il contienne les deux adresses IP attribuées aux contrôleurs de domaine principal et secondaire, telles que <SITE>-DC1 et <SITE>-DC2.
9. Mettez à jour NTPServers pour qu'il s'agisse d'une liste des adresses IP SyncServer à partir des ressources personnalisées TimeServer de l'administrateur racine. Vous pouvez récupérer cet ensemble d'adresses IP à l'aide de :
```
kubectl get timeserver -A -o json | jq '.items[].address'
```
  Vous devez mettre en forme ces adresses IP dans NTPServers, comme indiqué dans l'exemple suivant :
```
NtpServers = @(
  '10.251.80.2',
  '10.251.80.3',
  '10.251.80.4',
  '10.251.80.5'
)
```
10. Si nécessaire, remplacez la valeur par défaut de SubnetPrefix, à savoir 24, par la valeur du préfixe de sous-réseau fournie par le client pour le sous-réseau OCCORE-SERVERS.
11. Mettez à jour la valeur par défaut de DefaultGateway avec la passerelle par défaut fournie par le client pour le sous-réseau OCCORE-SERVERS.
12. Recherchez et remplacez la valeur par défaut WorkstationCider par la valeur fournie par le client pour le sous-réseau OC-WORKSTATIONS au format CIDR IPv4.
13. Remplacez la valeur WorkstationAllowRemote par $true si le client a choisi d'autoriser l'accès à distance à ses postes de travail.
14. Recherchez et remplacez l'exemple de préfixe de sous-réseau 172.21.0. par le préfixe de sous-réseau OCCORE-SERVERS fourni par le client.
15. Recherchez et remplacez le préfixe de sous-réseau exemple 172.21.2. par le préfixe de sous-réseau OCCORE-JUMPHOSTS fourni par le client.
16. Recherchez et remplacez le préfixe de sous-réseau exemple 172.21.32. par le préfixe de sous-réseau OC-WORKSTATIONS fourni par le client.
17. Recherchez et remplacez la valeur de l'exemple de message du jour legalnoticecaption de Pref caption par la légende fournie par le client.
18. Recherchez et remplacez la valeur de l'exemple de message du jour legalnoticetext de Pref text par le texte fourni par le client.
19. Validez chaque objet "node" et mettez-le à jour si nécessaire.
  1. NodeName : assurez-vous que le nom d'hôte est correct. Certains noms sont utilisés à de nombreux endroits, par exemple les contrôleurs de domaine. Si vous modifiez un nom ici, vérifiez s'il doit être modifié ailleurs dans la configuration.
  2. IPv4Addr : il doit s'agir de l'adresse IP de l'hôte. Il est généralement possible de laisser le dernier octet tel quel. Certains d'entre eux ont peut-être été mis à jour lors de la recherche et du remplacement du réseau effectués lors des étapes précédentes.
  3. HyperVHost : cette valeur doit correspondre à l'adresse IP du serveur Hyper-V qui héberge cette VM. Vous pouvez obtenir l'adresse IP de chaque serveur BM?? dans la section "Serveurs Hyper-V" de la configuration. Ne modifiez pas l'attribution de l'hôte Hyper-V dans ce champ, car tous les hôtes Hyper-V ne peuvent pas prendre en charge tous les types de VM. Remplacez simplement le nom d'hôte Hyper-V par son adresse IP correspondante.
20. Validez les détails de la deuxième interface réseau sur tous les nœuds avec Role=jumphost. Utilisez les détails du sous-réseau OCCORE-JUMPHOSTS pour cette interface. Vérifier :
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
21. Mettez à jour la stanza spécifique à ADFS dans le nœud où Role=adfs.
  
  Avertissement : Ne modifiez aucune partie de la configuration ADFS, sauf indication contraire. Lors d'une mise à niveau, la configuration ADFS existante est conservée.
  1. Recherchez la ligne Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust".
  2. Remplacez les trois occurrences de opscenter.local après cette ligne par votre domaine DNS.
22. Mettez à jour les étendues DHCP pour qu'elles correspondent au plan d'adresses IP du client, si nécessaire. Pour chaque champ d'application, vérifiez que les valeurs suivantes sont correctes. Les noms des niveaux d'accès correspondent à ceux utilisés dans le forfait réseau ocinfo.common.opscenter.local.txt. Utilisez donc les éléments suivants pour la validation :
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
23. Vérifiez que les valeurs correspondent à celles du fichier config1.ps1 sauvegardé.
24. Veillez à enregistrer le fichier.

Préparation de la VM CONFIG1

La préparation de CONFIG1 est effectuée sur BM01. Toutes les autres mises à niveau ont lieu lorsque vous êtes connecté à la VM CONFIG1.

Copiez le répertoire operations_center sur la VM CONFIG1.
1. Sur l'hôte BM01, ouvrez une console PS en tant qu'administrateur.
2. Copiez operations_center pour préparer les fichiers nécessaires à la machine virtuelle (VM) CONFIG1.
  
  Remarque : Copy-ConfigHostFiles.ps1 n'est pas utilisé ici, car l'environnement est opérationnel. La copie SMB permet de gagner des heures de temps de copie.
```
# Change name to match your config host
$config = "DC1-CONFIG1"
# Stage files for CONFIG1 VM
Copy-Item  -Path H:\operations_center -Destination "\\$config\c$\" -Recurse -Force
```
3. Désactiver la synchronisation de l'heure Hyper-V
  1. Connectez-vous à l'hôte BM01 en tant qu'administrateur.
  2. Ouvrez PowerShell sur Windows en tant qu'administrateur et exécutez la commande suivante :
  Important : Dans l'extrait de code suivant, remplacez <var>config1_vm_name</var> par le nom de la VM CONFIG1, par exemple DC1-CONFIG1.
```
# Disabling Hyper-V Time Sync
Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
```
4. Préparation et validation de la VM CONFIG1
  1. À partir de l'hôte BM01, connectez-vous à la VM CONFIG1 avec votre compte -SA. Connectez-vous à l'adresse IP de la VM à l'aide du Bureau à distance (RDP). Exemple : mstsc /v 192.168.100.99
  2. Ouvrez une fenêtre PowerShell à l'aide du menu "Exécuter en tant qu'utilisateur différent" pour l'exécuter en tant qu'utilisateur Marvin.
  3. Dans la nouvelle fenêtre PowerShell, démarrez une session administrative :
```
Start -Verb runas -FilePath powershell.exe
```
    Fermez la fenêtre PowerShell précédente, en laissant la fenêtre administrateur ouverte.
  4. Vérifiez que la fenêtre PowerShell administrative est exécutée en tant que Marvin.
```
whoami
```
  5. Présentez les fichiers qui ont été mis en scène à partir de l'hôte BM01.
```
Move-Item -Path c:\operations_center -Destination c:\release
C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
```
  6. Vérifiez que c:\dsc et c:\config existent.
  7. Copier les fichiers d'identifiants et de certificat à partir de la sauvegarde
```
Copy-Item -Path "C:\config1_backup\config\creds\" -Destination "C:\config\creds\" -Recurse
Copy-Item -Path "C:\config1_backup\config\certs\" -Destination "C:\config\certs\" -Recurse
```
  8. Créer les données MECM requises pour compiler les fichiers MOF
```
C:\dsc\Build-MecmFiles.ps1
```
  9. Validez que l'environnement de compilation est prêt en exécutant Build-Mof.ps1, qui génère des fichiers MOF pour toutes les machines OI.
```
C:\dsc\Build-Mof.ps1
```
5. Renseigner les variables d'identifiants
  
  Ces variables sont utilisées tout au long du processus de mise à niveau. Renseignez-les une seule fois dans la fenêtre Marvin PowerShell ouverte en tant qu'administrateur.
```
. 'c:\config\config.ps1'

$da_creds = (Get-Credential -Message "Provide domain admin credentials")
$sa_creds = (Get-Credential -Message "Provide system admin credentials")

$sa_args = @{
Credential = $sa_creds
SetLcm = $true
RemoveExisting = $true
CopyModules = $true
}

$da_args = @{
Credential = $da_creds
SetLcm = $true
RemoveExisting = $true
CopyModules = $true
}
```
6. Vérifiez que DSC est en cours d'exécution et que les serveurs sont accessibles.
```
$role = 'domain_controller'
$ca = 'ca_root'
$dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
$non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}

$dcs | ForEach-Object {
$session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}

$non_dcs | ForEach-Object {
Write-Output "Checking $($_.NodeName)"
$session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}
```
  Remarque : Certains nœuds peuvent afficher l'état Failure ou générer l'erreur The Consistency Check or Pull cmdlet is in progress. Cela ne pose aucun problème tant que le nœud est accessible.

Résolvez les problèmes de connectivité.

Si New-CimSession échoue, vérifiez que la valeur NodeName est correcte dans config.ps1. Vérifiez également que le serveur est en ligne et accessible.

L'erreur commencera par Get-CimSession: WinRM cannot process the request.

Mettre à niveau les contrôleurs de domaine

Connectez-vous à CONFIG1, puis mettez à niveau le contrôleur de domaine principal.

Renseignez les variables, supprimez les anciens objets de stratégie de groupe et associez les nouveaux.
```
$dc2 = $dcs | Where-Object {$_.NodeName -like "*-DC2"}
$dc1 = $dcs | Where-Object {$_.NodeName -like "*-DC1"}

Invoke-Command -Computername $dc1.NodeName -Credential $da_creds -ScriptBlock {
Remove-DscConfigurationDocument -Stage Current,Pending,Previous
get-gpo -All | Where-Object { $_.DisplayName -like "OIC*" } | Remove-GPO
get-gpo -All | Where-Object { $_.DisplayName -like "SITE*" -and $_.DisplayName -notlike "*SCCM*" } | Remove-GPO
Get-Item "C:\config\domain_controller\oic_gpos"| Remove-Item -Recurse -Force
Get-Item "C:\config\domain_controller\site_gpo*"| Remove-Item -Recurse -Force
}
```
Dissociez les objets de stratégie de groupe. Ils seront associés à la fin de la mise à niveau.
```
$gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'Yes'", "LinkEnabled: 'No'")
$gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
```
Mettez à niveau le contrôleur de domaine principal.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
```
Remarque : Les erreurs Copy-Item : An item with the specified name already exists. sont attendues pendant Installing PowerShell modules on host et peuvent être ignorées lors des mises à jour des nœuds.
Avertissement : Un problème a été détecté et affecte la copie de fichiers vers les contrôleurs de domaine en raison de restrictions de longueur de chemin d'accès. Si une erreur se produit lors de l'exécution de Update-RemoteHost, comme a file that already exists on the target destination pendant Copying files for the ... role to host, exécutez ces commandes. Sinon, passez à l'étape suivante.
```
New-PSDrive -Name DC1 -PsProvider FileSystem -Root "\\$($DC1.NodeName)\c$" -Credential $da_creds
Invoke-Command -ComputerName $DC1.NodeName -Credential $da_creds -Scriptblock {Remove-DscConfigurationDocument -Stage Current,Pending}
Remove-Item -Path DC1:\config\domain_controller\site_gpos -Recurse -Force
Remove-Item -Path DC1:\config\domain_controller\site_gpos_source -Recurse -Force
Copy-Item -Path C:\config\domain_controller\ -Destination DC1:\config\ -Verbose -Force -Recurse
C:\dsc\Build-Mof.ps1 -Computername $DC1.NodeName
Start-DscConfiguration -ComputerName $DC1.NodeName -Path 'c:\config\mofs' -Credential $da_creds -Verbose -Wait -Force
Remove-PsDrive -Name DC1
```
1. Valider la synchronisation horaire avec le serveur SyncServer
2. Connectez-vous à DC1 à l'aide du protocole RDP en tant qu'administrateur de domaine.
  1. Ouvrez une fenêtre Powershell en tant qu'administrateur.
  2. Exécutez la commande suivante pour valider la configuration de l'heure.
```
w32tm /query /status /verbose
```
Important : Assurez-vous que Last Sync Error: est défini sur 0 et que Source correspond à l'une des adresses IP NtpServers configurées dans les instructions Mettre à jour les serveurs NTP.
1. Exécutez les commandes suivantes pour tester la resynchronisation de l'heure :
```
 # Testing time resyncronization
 w32tm /resync
```
```
 # Desired output
 Sending resync command to local computer
 The command completed successfully.
```
2. Revalidez la configuration de l'heure pour vous assurer qu'elle est correcte et ne comporte aucune erreur.
  
  Important : Assurez-vous que Last Sync Error: est 0 et que Time to Last Good Sync Time: a été mis à jour (cela devrait prendre moins d'une minute si vous l'avez exécuté immédiatement après la synchronisation, par exemple).
```
 w32tm /query /status /verbose
```
  Avertissement : Si des erreurs sont détectées ou si w32tm /resync échoue, ARRÊTEZ-VOUS. Escaladez le problème à l'équipe d'ingénierie OI avant de continuer, car il existe un risque élevé de blocage du déploiement OI si les services temporels ne sont pas entièrement fonctionnels.
Mettez à niveau le deuxième contrôleur de domaine.
1. Utilisez la fenêtre PowerShell CONFIG1 existante pour exécuter le script suivant.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
```

Validez la réplication Active Directory.

Une fois le deuxième contrôleur de domaine opérationnel, exécutez les commandes suivantes à partir de l'un des contrôleurs de domaine pour valider la réplication Active Directory :

repadmin /replsummary

Le résultat doit ressembler à ce qui suit :

PS C:\Users\Administrator.OpsCenter> repadmin /replsummary
Replication Summary Start Time: 2023-11-29 19:16:59

Beginning data collection for replication summary, this may take awhile:
......

Source DSA          largest delta    fails/total %%   error
OC1-DC1                   01m:49s    0 /  5    0

Destination DSA     largest delta    fails/total %%   error
OC1-DC2                   01m:49s    0 /  5    0

Mettre à niveau CA-ISSUING1 et CA-WEB

Utilisez le terminal PowerShell existant sur CONFIG1 pour mettre à niveau CA-ISSUING1.

  $ca_iss = $config.AllNodes | Where-Object {$_.role -eq "ca_issuing"}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -ComputerName $ca_iss.NodeName

Utilisez le terminal PowerShell existant sur CONFIG1 pour mettre à niveau CA-WEB.

  $ca_web = $config.AllNodes | Where-Object {$_.role -eq "ca_web"}
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $ca_web.NodeName

Valider la mise à niveau

  $ca_iss,$ca_web | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettre à niveau CA-ROOT1

Utilisez le terminal PowerShell existant sur CONFIG1.

Allumez CA-ROOT1.

  $ca_root = $config.AllNodes | Where-Object {$_.role -eq "ca_root"}
  $session = New-CimSession -ComputerName $ca_root.HyperVHost -Credential $sa_creds
  Start-VM -CimSession $session  -Name $ca_root.NodeName

Mettez à jour CA-ROOT1.
```
  $caroot_cred = Get-GeccoCredential -Name "$($ca_root.NodeName)\caadmin" -CredStore "c:\config\creds"
  c:\dsc\Update-RemoteHost.ps1 -Computername $ca_root.NodeName -RemoteHost $ca_root.Ipv4Addr -Credential $caroot_cred
```
Remarque : En cas d'erreur d'authentification, connectez-vous au serveur CA-ROOT1 en tant que caadmin. Ouvrez PowerShell en tant qu'administrateur. Saisissez winrm qc et appuyez sur Entrée. Acceptez les modifications avec un y. Déconnectez-vous de CA-ROOT1, puis réessayez.
Si CA_ROOT1 n'a pas redémarré après le script précédent, redémarrez-le manuellement.
Validez la mise à niveau.
```
  $ca_root | ForEach-Object {
  $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
  Get-DscConfigurationStatus -CimSession $session}
```
Important : Utilisez w32tm pour vérifier que la VM se synchronise avec l'hôte <SITE>-DC1. Exécutez cette commande dans un shell administratif en tant qu'administrateur local sur CA-ROOT.

Vérifiez que le paramètre Peer est défini sur <SITE>-DC1.<DNSDOMAIN> et que State est défini sur Active.

Ne passez pas à l'étape suivante si l'heure n'est pas correctement synchronisée.

  w32tm /query /peers

  #Peers: 1

  Peer: DC1-DC1.domain.local
  State: Active
  Time Remaining: 31.2997107s
  Mode: 3 (Client)
  Stratum: 1 (primary reference - syncd by radio clock)
  PeerPoll Interval: 6 (64s)
  HostPoll Interval: 6 (64s)

Mettez l'appareil hors tension CA-Root.

  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Stop-VM -CimSession $session  -Name $ca_root.NodeName

Mettre à niveau ADFS

Utilisez le terminal PowerShell existant sur CONFIG1.

Mettez à niveau la VM ADFS1.

  $role = 'adfs'
  $adfs = $config.AllNodes | Where-Object {$_.role -eq $role}

  $adfs | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

  $adfs | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $adfs.NodeName}

1. Validate the upgrade.

  $adfs | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau les jumphosts.

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau de Jumphosts.

  $role = 'jumphost'
  $jumps = $config.AllNodes | Where-Object {$_.role -eq $role}

Mettez à niveau les serveurs relais.

  $jumps | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}

Validez la mise à niveau.

  $jumps | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau Fileservers.

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau contenant les Fileservers.

  $role = 'file'
  $files = $config.AllNodes | Where-Object {$_.role -eq $role}

Mettez à niveau les serveurs de fichiers.

  $files | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}

Validez la mise à niveau.

  $files | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau les serveurs DHCP.

Utilisez le terminal PowerShell existant sur CONFIG1.

Mettez à niveau DHCP1.

  $role = 'dhcp_primary'
  $dhcp1 = $config.AllNodes | Where-Object {$_.role -eq $role}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp1.NodeName

Validez la mise à niveau.

  $dhcp1 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau DHCP2.

  $role = 'dhcp_failover'
  $dhcp2 = $config.AllNodes | Where-Object {$_.role -eq $role}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp2.NodeName

valider la mise à niveau.

  $dhcp2 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau les serveurs Userlock.

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau PowerShell contenant les serveurs Userlock.

  $role = 'userlock_primary'
  $ulock1 = $config.AllNodes | Where-Object {$_.role -eq $role}
  $role = 'userlock_backup'
  $ulock2 = $config.AllNodes | Where-Object {$_.role -eq $role}

Supprimez les fichiers de repères de la configuration précédente.

  Invoke-Command -ComputerName $ulock1.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_primary\ServiceImpersonation.log" }
  Invoke-Command -ComputerName $ulock2.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_backup\ServiceImpersonation.log" }

Mettez à niveau le serveur Userlock principal.

  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock1.NodeName

Mettez à niveau le serveur Userlock de sauvegarde.

  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock2.NodeName

Validez les mises à niveau.

  $ulock1,$ulock2 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau les serveurs Nessus.

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau PowerShell contenant les serveurs Nessus.

  $role = 'nessus_'
  $nessus = $config.AllNodes | Where-Object {$_.role -match $role}

Mettez à niveau les serveurs Nessus.

  $nessus | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}

Validez la mise à niveau.

  $nessus | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettez à niveau les serveurs Hyper-V.

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau PowerShell contenant les serveurs Hyper-V.

  $role = 'hyper_v'
  $hyper = $config.AllNodes | Where-Object {$_.role -eq $role}

Mettez à niveau les serveurs Hyper-V.
```
  $hyper | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
```
Avertissement : Si BM01 redémarre, CONFIG1 redémarrera également. Une fois disponible, connectez-vous, ouvrez PowerShell en tant que Marvin et élevez le niveau d'accès, puis exécutez l'étape Préparation de la configuration 1 1.e. pour recharger les variables. Redémarrez la mise à niveau d'Hyper-V.

Validez la mise à niveau.

  $hyper | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Mettre à niveau les boîtes à outils

Utilisez le terminal PowerShell existant sur CONFIG1.

Créez un tableau PowerShell contenant les serveurs Toolbox.

  $role = 'toolbox'
  $tools = $config.AllNodes | Where-Object {$_.role -eq $role}

Créer un lecteur supplémentaire sur le serveur TOOLBOX1

  $tools | ForEach-Object {
     if ($_.ExtraDiskSize) {
     Invoke-Command -ComputerName $_.HyperVHost -Credential $sa_creds -ScriptBlock {
        $additional_disk_path = Join-Path -Path $using:_.ExtraDiskFolder -ChildPath "$($using:_.NodeName)-2.vhdx"
        New-VHD -Path $additional_disk_path -Dynamic -SizeBytes $using:_.ExtraDiskSize
        Add-VMHardDiskDrive -VMName $using:_.NodeName -Path $additional_disk_path
        Get-VMHardDiskDrive -VMName $using:_.NodeName | select VMName,ControllerLocation,Path
     }}}

Vérifiez que le résultat indique que deux disques sont attribués à la VM. Exemple :

  VMName       ControllerLocation Path
  ------       ------------------ ----
  DC1-TOOLBOX1                  0 H:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1.vhdx
  DC1-TOOLBOX1                  1 Z:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1-2.vhdx

Mettez à niveau les serveurs de la boîte à outils.

  $tools | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}

Validez la mise à niveau.

  $tools | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Utilisez le terminal PowerShell existant sur `CONFIG1` pour valider la mise à niveau.

Vérifiez que DSC s'exécute sans erreur.

   $role = 'domain_controller'
   $ca = 'ca_root'
   $dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
   $non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}

   $dcs | ForEach-Object {
   $session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
   Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}

   $non_dcs | ForEach-Object {
   Write-Output "Checking $($_.NodeName)"
   $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
   Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}

Mettre à niveau les VM Splunk

Dans la fenêtre PowerShell de CONFIG1, configurez et exécutez la configuration DSC :

Saisissez le code du site. Exemple : "DC1"

 $sitecode = Read-Host "Enter your site code"
 Set-Location c:\dsc

Configurez le redirecteur lourd :

 $myargs = @{
 Computername = "$sitecode-HEAVYFWD"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Configurer l'indexeur 1 :

 $myargs = @{
 Computername = "$sitecode-INDEXER1"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Configurer l'indexeur 2 :

 $myargs = @{
 Computername = "$sitecode-INDEXER2"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Configurer l'indexeur 3 :

 $myargs = @{
 Computername = "$sitecode-INDEXER3"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Configurez le gestionnaire :

 $myargs = @{
 Computername = "$sitecode-SPLUNKMGR"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Configurez le search head :

 $myargs = @{
 Computername = "$sitecode-SEARCHHEAD"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Dans la fenêtre Powershell de CONFIG1 :

  $servers = @()
  $config.AllNodes | Where-Object {$_.role -match "splunk_"} | Foreach { $servers += $_.NodeName }
  Invoke-Command -ComputerName $servers -Credential $sa_creds -ScriptBlock {Restart-Service -Name 'Splunkd'} -ErrorAction Continue

Suivez SIEM-G0006 pour définir le Pass4SymmKey global et SIEM-G0007 pour associer chaque zone à Splunk dans OIC.

Mettre à niveau l'hôte CONFIG1

Dans la fenêtre Powershell de CONFIG1 :

Start-DscConfiguration -ComputerName $env:COMPUTERNAME -Path c:\config\mofs -Verbose -Wait -Force

Si l'ordinateur redémarre, reconnectez-vous et redémarrez PowerShell en tant que Marvin, puis passez au niveau administrateur. Renseignez les variables nécessaires pour les sections suivantes.

Set-Location c:\dsc
. c:\config\config.ps1
$da_creds = (Get-Credential -Message "Provide domain admin credentials")
$sa_creds = (Get-Credential -Message "Provide system admin credentials")

Microsoft Configuration Manager (MCM)

Étant donné que MCM n'est pas un composant pouvant être mis à niveau, la seule option consiste à détruire les hôtes MCM existants et à redéployer MCM.

Assurez-vous que le logiciel MCM actuel a été hydraté conformément à IT-T0023.
La procédure de redéploiement est décrite dans IT-R0019.

Supprimer des points de contrôle de VM

Une fois les mises à niveau terminées, les points de contrôle doivent être supprimés. Les points de contrôle peuvent entraîner une utilisation excessive de l'espace disque au fil du temps. Ne les conservez que si une restauration à un point de contrôle est nécessaire en raison d'une mise à niveau ayant échoué.

Utilisez le terminal PowerShell existant sur CONFIG1.

Supprimez les points de contrôle de VM.

  $config.AllNodes | Where-Object {$_.Role -eq "hyper_v"} | Foreach-Object {
  Invoke-Command -ComputerName $_.NodeName -Credential $sa_creds -Scriptblock {
    Get-VM | Get-VMSnapshot | Where-Object {$_.Name -like "Checkpoint_*"} | Remove-VMSnapshot -Verbose
  }}

Réactiver les objets de stratégie de groupe pour le domaine

Utilisez le terminal PowerShell existant sur CONFIG1.

Modifier la configuration du rôle de contrôleur de domaine pour activer les liens sur les GPO gérés

  $gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'No'", "LinkEnabled: 'Yes'")
  $gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force

Mettez à jour le contrôleur de domaine avec le rôle ObjectOwner :

  c:\dsc\Update-RemoteHost.ps1 -Computername $config.AllNodes.DomainConfig.ObjectOwner -Credential $da_creds

Contacter l'équipe Google

Consultez la page Demander de l'aide pour savoir comment contacter Google et obtenir de l'aide.

Effectuer une mise à niveau dans un déploiement multizone Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Préparer

Générer un rapport de conformité

Identity and Access Management

Suspendre les mises à niveau des ressources mondiales dans toutes les zones

Mettre à niveau l'organisation racine globale

Vérification préalable à la mise à niveau

1. Télécharger et copier le package de mise à jour

2. Configurer la mise à niveau d'Artifact Registry

Transférer les artefacts vers le registre de conteneurs

3. Mettre à niveau l'organisation racine

3.1. Avant la migration

3.2. Effectuer des mises à niveau automatiques de l'organisation racine

3.3. Vérifications après la mise à niveau

Terminer la mise à niveau de l'organisation racine dans toutes les zones

4. Mettre à niveau les ressources globales

5. Mises à niveau des composants interzones

6. Mise à niveau manuelle pour le sous-réseau Anycast

7. Mise à niveau manuelle pour SyncServer

7.1. Processus de mise à niveau de SyncServer

Mettre à niveau une organisation locataire globale

Vérification préalable à la mise à niveau

1. Mettre à niveau une organisation locataire

1.1. Préparation

IaC

kubectl

1.2. Lancer la mise à niveau

1.3. Mettre à niveau

1.4. Vérifications après la mise à niveau

1.5. Lancer une mise à niveau non programmée

2. Mise à niveau du DNS

2.1 Créer des zones de transfert

2.2 Activer le résolveur récursif

Terminer la mise à niveau de l'organisation locataire dans toutes les zones

3. Mettre à niveau les ressources globales

4. Mettre à niveau Tenable SC

Nettoyage après la mise à niveau

Configurer des intervalles de maintenance pour la mise à niveau de l'organisation locataire

Console

kubectl

Mise à niveau manuelle de l'infrastructure Operations Suite Core

Effectuer des points de contrôle de VM et des sauvegardes de répertoire

Charger des logiciels tiers

Mettre à niveau les machines virtuelles existantes

Préparation de la VM CONFIG1

Résolvez les problèmes de connectivité.

Mettre à niveau les contrôleurs de domaine

Mettre à niveau CA-ISSUING1 et CA-WEB

Mettre à niveau CA-ROOT1

Mettre à niveau ADFS

Mettez à niveau les jumphosts.

Mettez à niveau Fileservers.

Mettez à niveau les serveurs DHCP.

Mettez à niveau les serveurs Userlock.

Mettez à niveau les serveurs Nessus.

Mettez à niveau les serveurs Hyper-V.

Mettre à niveau les boîtes à outils

Utilisez le terminal PowerShell existant sur CONFIG1 pour valider la mise à niveau.

Mettre à niveau les VM Splunk

Mettre à niveau l'hôte CONFIG1

Microsoft Configuration Manager (MCM)

Supprimer des points de contrôle de VM

Réactiver les objets de stratégie de groupe pour le domaine

Contacter l'équipe Google

Effectuer une mise à niveau dans un déploiement multizone

Utilisez le terminal PowerShell existant sur `CONFIG1` pour valider la mise à niveau.