Esegui un upgrade in un deployment multizona

In un deployment multizona, le zone vengono aggiornate una alla volta e in modo indipendente l'una dall'altra. Non esiste un'orchestrazione globale degli upgrade tra le zone. Un IO deve eseguire un upgrade in ogni zona per l'organizzazione di cui vuole eseguire l'upgrade a una nuova versione. Di conseguenza, le organizzazioni in zone diverse possono utilizzare versioni diverse in un determinato momento.

L'ordine di upgrade descritto in questa pagina prevede l'upgrade dell'organizzazione principale e di tutte le organizzazioni tenant in una zona prima di passare a un'altra zona. Le risorse globali vengono aggiornate alla fine, dopo l'aggiornamento di tutte le zone.

Questa pagina descrive i passaggi per procedere con un upgrade air-gapped multizona di Google Distributed Cloud (GDC) fornendo i seguenti tipi di informazioni:

• Accesso richiesto e modi per ottenerlo.
• Gli strumenti di cui hai bisogno.
• Quali passaggi eseguire prima di eseguire un upgrade.
• Come e in quale sequenza eseguire gli upgrade per i vari componenti di Distributed Cloud.

Importante: se non diversamente indicato, queste istruzioni descrivono come eseguire l'upgrade dal livello di rilascio attuale al livello di rilascio più recente disponibile, ad esempio alla versione 1.x.y. Ad esempio, se lavori con la versione 1.x.0 e queste istruzioni forniscono informazioni sull'upgrade alla versione 1.x.2, non devi eseguire prima l'upgrade alla versione 1.x.1. I componenti che richiedono l'upgrade ai livelli intermedi avranno i requisiti e i dettagli chiaramente indicati nelle rispettive sezioni.

Il seguente elenco definisce ciascuno dei componenti di un upgrade:

Versione di destinazione: utilizza la stessa versione di destinazione per tutte le zone.

Uno alla volta: esegui l'upgrade di una zona alla volta. Prima che venga attivato un upgrade in una zona, assicurati che in nessun'altra zona sia in corso un upgrade.

Risorse globali: definite come risorse Kubernetes di cui è stato eseguito il deployment su kube-apiserver globale, anziché risorse di zona che hanno una copia per zona. Le risorse globali seguono un ciclo di vita diverso. Tieni presente che devono essere aggiornati alla fine, una sola volta.

Preparazione

Gli URL vengono forniti per l'accesso al di fuori dell'ambiente isolato.

Prima di iniziare un upgrade, assicurati di disporre di quanto segue:

• Il percorso del file kubeconfig che hai ottenuto eseguendo gdcloud auth login nel cluster di amministrazione principale.

  Importante: devi avere il percorso kubeconfig prima di poter procedere.

• I nuovi artefatti di rilascio, scaricati e trasferiti in modo sicuro sul tuo computer. Segui i passaggi descritti in Esegui il push degli artefatti nel registro dei container.

• Una macchina host per l'esecuzione degli upgrade manuali, con un file kubeconfig del cluster di amministrazione root sulla macchina.

• Prima di iniziare l'upgrade, vengono risolti tutti i problemi noti relativi alla versione DA cui viene eseguito l'upgrade. Nello specifico, per l'upgrade dalla versione 1.13.1, assicurati che i seguenti problemi siano risolti:

  • VM senza spazio libero sul dispositivo

Generare un report sulla conformità

Il report sulla conformità elenca le organizzazioni che:

• non sono più supportati
• mancano patch di sicurezza critiche

La generazione del report di conformità è un passaggio facoltativo e richiede un IO autenticato che disponga di organization-admin role. Per generare il report, esegui questo comando:

  gdcloud system upgrade report-compliance

Per ulteriori informazioni sui requisiti di preparazione, consulta la sezione Prerequisiti.

Identity and Access Management

Prima di iniziare un upgrade, in ogni zona:

1. Ottieni un file kubeconfig eseguendo gdcloud auth login nel cluster di amministrazione principale e in tutti i cluster di amministrazione dell'organizzazione.

2. Segui le istruzioni nel runbook del processo di accesso e aumento dei privilegi IAM-R0005 per aggiungere:

   1. ClusterRoleBinding con cluster-admin ClusterRole nel cluster di amministrazione principale di ogni zona
   2. cluster di amministrazione dell'organizzazione in modo da ottenere l'accesso amministrativo temporaneo.

Metti in pausa gli upgrade delle risorse globali in tutte le zone

Utilizza il file kubeconfig ottenuto per sospendere tutti gli upgrade delle risorse globali in ogni zona.

# 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

Esegui l'upgrade dell'organizzazione principale globale

L'upgrade dell'organizzazione principale globale a livello generale include i seguenti passaggi:

1. Esegui l'upgrade dell'organizzazione principale in tutte le zone. Ogni zona viene aggiornata singolarmente.

   Importante: inizia l'upgrade con la zona primaria StorageGrid, poi ripeti l'operazione per tutte le altre zone del deployment. Questo ordine è necessario per il corretto funzionamento dell'archiviazione degli oggetti.

   Controlla se la zona attuale è la zona principale. Il seguente comando restituisce "true" nella zona primaria e non restituisce nulla nelle zone non primarie.

   kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
   

2. Esegui l'upgrade dei componenti che richiedono il coordinamento tra zone.

3. Esegui l'upgrade delle risorse di amministratore root globale.

Controllo pre-upgrade

Esegui l'upgrade delle zone una alla volta. Prima di avviare l'upgrade di un'organizzazione in una zona, connettiti a tutte le altre zone ed esegui il seguente comando per assicurarti che restituisca il valore ready in tutte le zone. Se una zona risulta non pronta, non procedere con l'upgrade. Controlla l'organizzazione in quella zona per diagnosticare il problema.

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. Scaricare e copiare il pacchetto di aggiornamento

Queste istruzioni descrivono come iniziare:

• Scarica un pacchetto di aggiornamento su un dispositivo accessibile a internet per copiarlo su un'unità USB.
• Copia il pacchetto di aggiornamento dall'unità USB all'ambiente isolato.

Per ulteriori informazioni, consulta Scaricare i file per scaricare i dettagli di una distribuzione Distributed Cloud e Trasferimento del download per informazioni sul dispositivo di archiviazione portatile che utilizzi per trasferire i file al tuo ambiente air-gap.

1. Collabora con il tuo punto di contatto Google per decidere se l'upgrade riguarda un deployment di Distributed Cloud gestito da un partner, quindi deve utilizzare i file di rilascio del modello del partner.

   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
   

2. Scarica il pacchetto di aggiornamento sull'unità USB da un computer con accesso a internet. Utilizza i dettagli della versione e del digest forniti dal tuo punto di contatto Google.

   1. Esegui gcloud auth login per accedere al bucket Cloud Storage.

   2. Esegui lo script con --skip-unzip per recuperare il pacchetto di aggiornamento e lo script di download nella directory corrente, ad esempio /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. Se esegui l'upgrade con i file di rilascio del modello partner, segui le istruzioni per preparare i pacchetti software per la distribuzione del modello partner.

      Nota: ignora questo passaggio se non utilizzi i file di liberatoria del modello partner per l'upgrade.

3. Copia sia lo script di download sia la directory gdch nell'unità USB.

4. Copia l'aggiornamento sull'OCIT dall'unità USB. Inserisci i file in una posizione simile, ad esempio /home/download/.

5. Ridefinisci queste variabili nell'OCIT ed estrai l'aggiornamento:

   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
   

6. Il downloader avrà decompresso la release in gdch/full-release-1.2.0-gdch.243 (ad es./home/download/gdch/full-release-1.2.0-gdch.243). Assegna questa variabile al percorso completo:

   export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
   

2. Configura l'upgrade di Artifact Registry

Per eseguire correttamente un upgrade, devi completare le seguenti operazioni:

Esegui il push degli artefatti nel container registry

1. Imposta KUBECONFIG sul file kubeconfig per il cluster di amministrazione principale.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   

2. Crea il ClusterRoleBindings necessario:

   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
   

3. Crea il RoleBindings necessario:

   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
   

4. Crea RoleBindings necessari per eseguire il push del pacchetto OCI:

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

   L'output è simile al seguente:

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

5. Segui le istruzioni riportate in Ridimensionare lo spazio di archiviazione di Artifact Registry per eseguire le seguenti operazioni:

   1. Controlla l'utilizzo dello spazio di archiviazione di Artifact Registry in un cluster di amministrazione e verifica che ci sia spazio sufficiente per gli artefatti che vuoi eseguire il push.
   2. Se devi aumentare lo spazio disponibile, segui i passaggi descritti in Ridimensionare lo spazio di archiviazione di Artifact Registry.

6. Configura le impostazioni di Docker:

   cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
   

   Nota: assicurati sempre che questo file binario sia presente prima di eseguire load-oci.

7. Configura Docker in modo che consideri attendibile il bundle truststore.

   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
   

8. Carica gli artefatti nel registro degli artefatti nel cluster di amministrazione principale:

   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
   

   Sostituisci quanto segue:

   • VERSION: la versione di rilascio di Distributed Cloud. Ad esempio, 1.x.y-gdch.z.
   • KUBECONFIG_PATH: il percorso del file kubeconfig che hai ottenuto eseguendo gdcloud auth login nel cluster di amministrazione principale.
   • PACKAGE_VALIDATION_ROOT_CERT_PATH: il percorso del certificato radice di convalida del pacchetto. Devi utilizzare il percorso predefinito ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt. L'inclusione di questo percorso convalida i certificati delle chiavi di rilascio utilizzati per la convalida dei pacchetti.

   Se il comando è andato a buon fine, l'output finale sarà simile a questo esempio:

   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
   

   Se l'output non corrisponde a questo esempio, segui questi passaggi per risolvere i problemi più comuni:

   • Se l'output include il messaggio Package validation root certificate requires upgrade!, esegui la rotazione del certificato radice seguendo i passaggi descritti in Eseguire la rotazione del certificato di convalida del pacchetto.
   • Se load-oci non va a buon fine, esegui di nuovo l'operazione. Se l'errore persiste, controlla le altre soluzioni offerte in questo elenco.
   • Se l'output include il messaggio Error: unable to create k8sclient: Unauthorized, devi eseguire nuovamente l'autenticazione. Ripeti il passaggio di preparazione per verificare il file kubeconfig o esegui il comando ${ARTIFACTS_ROOT}/gdcloud auth login e riprova l'operazione load-oci.
   • Se l'output include il messaggio UNAUTHORIZED: unauthorized to access repository, non disponi delle autorizzazioni necessarie per eseguire il comando load-oci. Riassegna questo problema per ottenere i ruoli necessari per eseguire questo comando oppure chiedi a un utente che dispone dei ruoli richiesti di eseguire questo comando per tuo conto.

9. Per l'upgrade con i file di rilascio del modello partner SOLO, segui le istruzioni per caricare i pacchetti software per la distribuzione del modello partner.

10. Verifica che l'oggetto ReleaseMetadata per la nuova versione si trovi nel cluster di amministrazione principale:

    kubectl get releasemetadata.artifact.private.gdc.goog VERSION
    

    Sostituisci VERSION con la versione di rilascio di Distributed Cloud. Ad esempio, 1.x.y-gdch.z.

    Output di esempio:

    NAME             AGE
    1.x.y-gdch.z     2m
    

11. Verifica che la nuova versione sia presente nell'elenco degli upgrade disponibili per l'organizzazione principale da aggiornare:

    ROOT_NAME=root
    kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
    

    Ad esempio, per 1.x.y-gdch.z, ci aspettiamo il seguente output:

    ["1.x.y-gdch.z"]
    

Dopo l'upgrade dell'organizzazione principale a una nuova versione, questa diventa disponibile per gli upgrade per un'organizzazione tenant.

3. Esegui l'upgrade dell'organizzazione principale

3.1. Pre-upgrade

1. Imposta KUBECONFIG sul file kubeconfig per il cluster di amministrazione principale.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   

2. Crea il ClusterRoleBindings necessario:

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

3. Verifica che l'organizzazione principale sia in stato integro, come indicato dalla risposta True:

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

   Output di esempio:

   True
   

4. Segui le istruzioni del runbook HSM-P0003 per riavviare tutti gli HSM.

3.2. Eseguire upgrade automatici dell'organizzazione principale

L'upgrade deve essere sottoposto alla procedura IaC. L'upgrade viene attivato aggiornando il campo della versione nell'oggetto OrganizationZonalConfig corrispondente dell'organizzazione nella zona.

Importante: prima di iniziare l'upgrade, controlla se il file OrganizationZonalConfig esiste nel repository IaC in iac/infrastructure/global/orgs/root per l'organizzazione principale e la zona corrente. In caso contrario, segui queste istruzioni per crearlo.

1. Aggiorna la versione nel file YAML OrganizationZonalConfig. Elimina la sezione spec.capacities.workloadServers nel file, se presente.

   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
   

2. Esegui lo staging e il commit delle modifiche al file.

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

3. Crea una richiesta di unione.

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

All'avvio dell'upgrade, viene creato un oggetto OrganizationUpgrade. Verifica che l'oggetto radice OrganizationUpgrade sia stato creato nel cluster di amministrazione radice nella zona.

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

Se non viene trovato OrganizationUpgrade, segui il runbook IAC-R0001 per la risoluzione dei problemi.

3.3. Controlli post-upgrade

1. Verifica i risultati dell'upgrade:

   1. Controlla l'oggetto Organization per l'organizzazione principale. Verifica che la condizione di stato READY sia True:

      kubectl -n gpc-system get organization root
      

      Output di esempio:

      NAME   READY
      root   True
      

   2. Verifica che Organization.Status.Version mostri la stringa esatta 1.x.y-gdch.z:

      kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
      

      Output di esempio per la verifica:

      1.13.3-gdch.5548
      

2. Controlla la presenza di errori nei sottocomponenti nell'organizzazione principale:

   1. Controlla i sottocomponenti che mostrano lo stato ReconciliationError o Reconciling. Indirizza kubeconfig a 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)"'
      

   2. Per gli errori, controlla le note di rilascio e i problemi noti per una soluzione alternativa , altrimenti contatta Distributed Cloud per la risoluzione dei problemi.

3. Se il controllo preflight o postflight è stato ignorato, rimuovi le annotazioni al termine dell'upgrade:

   Esempi:

   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-
   

Completa l'upgrade dell'organizzazione principale in tutte le zone

Una volta completato l'upgrade in una zona, ti consigliamo di verificare che la zona funzioni ancora correttamente prima di procedere con l'upgrade della zona successiva.

Ripeti i passaggi da 1 a 3 per l'organizzazione principale nelle altre zone. Quando tutte le zone hanno eseguito l'upgrade dell'organizzazione principale, procedi con i passaggi successivi.

4. Esegui l'upgrade delle risorse globali

Le risorse globali devono trovarsi nella versione più bassa di tutte le zone. Avvia la procedura di upgrade delle risorse globali connettendoti alla zona di ancoraggio ed eseguendo i seguenti comandi.

# 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

L'operazione potrebbe richiedere alcuni minuti. Verifica il completamento degli upgrade delle risorse globali eseguendo i seguenti comandi. Il comando non deve segnalare alcun errore.

Importante: la verifica deve essere eseguita solo nella zona di ancoraggio. Il resto delle zone dovrebbe essere messo in pausa e lo stato potrebbe non essere aggiornato.

# 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. Upgrade dei componenti tra zone

In un universo multizona GDC, determinati componenti operativi richiedono il coordinamento tra le zone per completare gli upgrade.

In questo passaggio viene eseguito l'upgrade dei seguenti componenti operabili.

Ambito	Componenti azionabili
Infrastruttura	IAC
Infrastruttura	SIEM

Per eseguire l'upgrade del componente operabile IAC, segui il runbook IAC-R0016.

Per eseguire l'upgrade del componente SIEM utilizzabile, segui il runbook SIEM-G0008.

6. Upgrade manuale per la subnet Anycast

Nota :questo passaggio si applica solo quando esegui l'upgrade dell'organizzazione principale globale dalla versione 1.14.3.

Esegui questo script per aggiungere le etichette necessarie alle subnet anycast nel server API root 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 "$@"

Dopo l'esecuzione corretta dello script, ripristina la soluzione alternativa manuale anycast se è stata applicata in precedenza.

7. Upgrade manuale per SyncServer

In questo passaggio viene eseguito l'upgrade dei seguenti componenti operabili.

Ambito	Componenti azionabili
Infrastruttura	NTP

Questo upgrade del firmware non ha dipendenze da altri passaggi e può essere eseguito in qualsiasi momento.

Il cluster ha un solo SyncServer, quindi non può operare in modalità ad alta disponibilità. L'upgrade causerà l'indisponibilità di SyncServer per un periodo di tempo. Il cluster continuerà a tenere il tempo utilizzando i propri orologi meno precisi, il che non avrà effetti evidenti.

È consigliabile completare questa procedura in una sola volta (non lasciarla durante la notte o nel fine settimana) per evitare la deriva temporale.

7.1. Procedura di upgrade di SyncServer

I seguenti comandi devono essere eseguiti dalla directory di release del pacchetto di aggiornamento estratto.

1. Individua il firmware più recente da estrarre:

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

   Il nome file contiene la versione del firmware.

   Output di esempio:

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

2. Copia solo i nomi dei file e assegnali a queste variabili:

   export SYNCSERVER_VERSION=syncserver:5.1.2
   

3. Estrai il firmware dall'immagine OCI:

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

4. Estrai il firmware:

   tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
   

   Nella directory di output devi vedere un file *.dat e un file *updater.zip.

5. Segui il runbook NTP-P0002 - Accesso all'interfaccia utente di SyncServer.

   1. Vai a Guida -> Informazioni -> Versione software. Se il software installato è uguale o successivo al firmware fornito, il firmware non deve essere aggiornato e i passaggi successivi possono essere saltati.

   2. Vai ad Amministrazione -> Upgrade nell'interfaccia utente di SyncServer. Carica syncserver_s650_license.dat in Authorization File e syncserver_s650_updater.zip in Upgrade File. Poi fai clic su Installa.

   

Eseguire l'upgrade di un'organizzazione tenant globale

L'upgrade di un'organizzazione tenant globale a livello generale include i seguenti passaggi:

1. Esegui l'upgrade dell'organizzazione tenant in tutte le zone. Ogni zona viene aggiornata singolarmente.

   Importante: inizia l'upgrade con la zona primaria StorageGrid, poi ripeti l'operazione per tutte le altre zone del deployment. Questo ordine è necessario per il corretto funzionamento dell'archiviazione degli oggetti.

   Controlla se la zona attuale è la zona principale. Il seguente comando restituisce "true" nella zona primaria e non restituisce nulla nelle zone non primarie.

   kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
   

2. Esegui l'upgrade delle risorse dell'organizzazione tenant globale.

Controllo pre-upgrade

Esegui l'upgrade delle zone una alla volta. Prima di avviare l'upgrade di un'organizzazione in una zona, connettiti a tutte le altre zone ed esegui il seguente comando per assicurarti che restituisca il valore ready in tutte le zone. Se una zona risulta non pronta, non procedere con l'upgrade. Controlla l'organizzazione in quella zona per diagnosticare il problema.

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

Assicurati che tutti i cluster siano in esecuzione e che tutti i pool di nodi siano nello stato pronto. In caso contrario, correggili prima di iniziare l'upgrade.

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. Eseguire l'upgrade di un'organizzazione tenant

Questo passaggio esegue l'upgrade della versione di Kubernetes, degli addon e dei componenti operabili sui cluster del management plane in un'organizzazione tenant: cluster org-admin, di sistema e di servizio.

La durata complessiva dell'upgrade dipende dal numero di fasi dell'upgrade. L'upgrade automatico dell'organizzazione tenant può essere interruttivo e richiede un periodo di manutenzione.

Nota: l'upgrade di un'organizzazione tenant a una versione secondaria inferiore a quella dell'organizzazione principale non è supportato.

1.1. preparazione

Per configurare i periodi di manutenzione, segui la procedura descritta in Configurare i periodi di manutenzione per l'upgrade dell'organizzazione tenant.

Le istruzioni per avviare l'upgrade di un'organizzazione tenant vengono fornite per l'utilizzo dei comandi kubectl CLI o dei comandi Infrastructure as Code (IaC). Per utilizzare i comandi IaC, configura prima IaC:

• Configurazione di Infrastructure as Code (IaC).

• Configura l'infrastruttura come codice.

  Per utilizzare nomos per verificare lo stato come riferimento nei passaggi basati su IaC come opzione, devi aver installato lo strumento a riga di comando nomos. Per ottenere le istruzioni di installazione e utilizzo di nomos, visita https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command da un computer con accesso a internet.

Importante: se IaC è abilitato, devi eseguire l'upgrade utilizzando IaC.

IaC

Imposta il clusterrolebinding prima di iniziare l'upgrade dell'organizzazione tenant utilizzando IAC

1. Vai alla directory iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
2. Vai alla directory IO già creata. Se la directory non esiste, creane una nuova.

3. Aggiungi un file YAML per assegnare il ruolo del cluster io-organization-admin all'IO. Ad esempio:

   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
   

4. Aggiorna kustomatization.yaml per includere il nuovo file creato. Se il kustomatization.yaml non esiste, crea un nuovo file:

   kind: Kustomization
   metadata:
     name: org-1-admin-kustomization
   resources:
   - FILE_NAME.yaml
   

5. Invia le modifiche in IAC

kubectl

Imposta clusterrolebinding prima di avviare l'upgrade dell'organizzazione tenant utilizzando kubectl

1. Imposta KUBECONFIG sul file kubeconfig per il cluster di amministrazione principale.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
   

2. Crea il ClusterRoleBindings necessario:

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

3. Prima di completare l'upgrade da una versione precedente di Distributed Cloud alla versione 1.13.x+, segui le istruzioni del runbook BIL-R0014 per generare manualmente una fattura per i costi di questo mese dall'inizio del mese all'inizio della data odierna. Perderai i dati di costo creati durante la procedura di upgrade dell'organizzazione Distributed Cloud.

1.2. Avvia l'upgrade

L'upgrade dell'organizzazione tenant viene attivato anche tramite IaC aggiornando il campo della versione nell'oggetto OrganizationZonalConfig corrispondente dell'organizzazione nella zona. Di seguito sono riportati i dettagli:

1. Aggiorna la versione nel file 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
   

2. Esegui lo staging e il commit delle modifiche al file.

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

3. Crea una richiesta di unione.

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

Se viene avviato l'upgrade, viene creato un oggetto OrganizationUpgrade. Verifica che l'oggetto OrganizationUpgrade sia stato creato nel cluster di amministrazione principale nella zona.

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

Se non viene trovato OrganizationUpgrade, segui il runbook IAC-R0001 per la risoluzione dei problemi.

1.3. Esegui l'upgrade

1. L'upgrade viene eseguito quando ha un timeWindow che rientra nel periodo di manutenzione specificato da un utente amministratore, chiamato anche PA. Visualizza l'timeWindow programmato:

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

   Di seguito è riportata una risposta tipica al comando precedente:

   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"
   

   Nell'esempio precedente, la pianificazione dell'upgrade a 1.8.1-gdch.0 è tra "2022-08-28T00:00:00Z" e "2022-08-28T04:00:00Z".

   All'avvio dell'upgrade, viene creato un oggetto OrganizationUpgrade, mostrato come kind: OrganizationUpgrade nell'esempio di output precedente.

   kind: OrganizationUpgrade
   

2. Monitora lo stato generale dell'upgrade utilizzando l'oggetto di upgrade corrispondente, aggiungendo il comando del passaggio 1 con -w. Ad esempio, per eseguire query continue su ORG_NAME per lo stato dell'upgrade, esegui il comando seguente:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
   

3. Le fasi dell'upgrade e il relativo stato possono essere visualizzati utilizzando quanto segue:

   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'
   

   La fase Succeeded si riferisce allo stato generale dell'upgrade. La fase Expired viene utilizzata per indicare che l'upgrade è successivo all'ora pianificata originale. Tutte le altre fasi si riferiscono ai passaggi dell'upgrade in corso. Stato True si riferisce ai passaggi completati, mentre Stato Unknown si riferisce al passaggio attuale dell'upgrade.

   Se un controllo preflight non è riuscito e hai la certezza che si tratti di un falso positivo, esegui l'override e salta le opzioni di controllo preflight:

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

   Se un controllo post-volo non è andato a buon fine e sei certo che si tratti di un falso positivo, esegui l'override e salta i controlli post-volo:

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

4. Se IAC è stato utilizzato per l'upgrade dell'organizzazione tenant e lo stato organizationupgrade mostra Riuscito e Organization per l'organizzazione tenant non è nello stato Pronto, applica la seguente soluzione alternativa.

   Aggiungi questa annotazione: configmanagement.gke.io/managed: disabled using IAC all'organizzazione. Il monitoraggio dello stato di Organization è in stato Pronto.

5. L'upgrade dell'organizzazione dovrebbe ora procedere alla fase successiva e lo stato del servizio o del nodo sarà completato:

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

   L'avanzamento dell'upgrade dell'organizzazione può richiedere 15 minuti.

1.4. Controlli post-upgrade

1. Controlla l'oggetto Organization per l'organizzazione. La condizione READY deve essere visualizzata come True.

   kubectl -n gpc-system get organization ORG_NAME
   

   Output di esempio:

   NAME   READY
   org-1  True
   

2. Controlla Organization.Status.Version. Deve mostrare la stringa esatta della versione di destinazione:

   kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
   

   Output di esempio:

   1.13.3-gdch.5548
   

   Importante: se hai attivato un aggiornamento non pianificato utilizzando l'annotazione per ignorare un periodo di manutenzione, devi ripristinarlo per utilizzare i periodi di tempo pianificati.

   Per ripristinare l'annotazione in modo da ignorare i periodi di manutenzione:

   kubectl annotate organization ORG_NAME -n=gpc-system  \
       "upgrade.private.gdc.goog/ignore-maintenance-window-" \
       --kubeconfig=ROOT_ADMIN_KUBECONFIG
   

3. Controlla la presenza di errori nei sottocomponenti nell'organizzazione tenant aggiornata :

   1. Controlla i sottocomponenti che mostrano lo stato ReconciliationError o Reconciling. Indirizza kubeconfig a 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)"'
      

   2. Per gli errori, consulta le note di rilascio e i problemi noti per una soluzione alternativa, altrimenti contatta Distributed Cloud per la risoluzione dei problemi.

4. Se il controllo preflight o postflight è stato ignorato, rimuovi le annotazioni al termine dell'upgrade:

   Esempi:

   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. Avviare un upgrade non pianificato

Importante: questa sezione descrive come avviare un upgrade al di fuori di una periodo di manutenzione pianificata. Prima di procedere, assicurati di aver completato la sezione Avvia un upgrade pianificato. Qui sono riportati anche i passaggi per ripristinare l'intervallo di tempo della finestra di manutenzione al termine dell'operazione.

Attiva un upgrade istantaneo dell'organizzazione tenant al di fuori di un maintenanceWindow se hai un'esigenza urgente, ad esempio un requisito urgente di patch di sicurezza. Questa operazione è necessaria solo nell'organizzazione tenant, poiché l'organizzazione principale attiva già l'upgrade istantaneamente.

Esegui questo comando utilizzando l'amministratore root kubeconfig. La risorsa personalizzata dell'organizzazione che devi annotare è presente solo nel cluster root-admin. Non pianifichi una finestra temporale per questo processo.

1. Applica una patch all'organizzazione spec/version per l'organizzazione tenant:

   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
   

2. Avvia un tenant-org upgrade istantaneo applicando l'annotazione ignore-maintenance-window e riavviando organizationupgrade.

   Nota: se l'upgrade genera un errore, applica lo stesso comando più di una volta.

3. Monitora lo stato dell'upgrade:

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

4. Esegui i controlli post-upgrade.

5. Al termine dell'upgrade urgente, torna a utilizzare le finestre temporali pianificate:

   kubectl annotate organization ORG_NAME -n=gpc-system  \
         "upgrade.private.gdc.goog/ignore-maintenance-window-" \
         --kubeconfig=ROOT_ADMIN_KUBECONFIG
   

   Nota: se l'upgrade del DNS non va a buon fine, consulta DNS R0006 per risolvere il problema.

2. Aggiornamento DNS

2.1 Crea zone di inoltro

1. Esporta kubeconfig per il cluster di amministrazione root:

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

2. Configura OCIT_DOMAIN utilizzando una zona di inoltro. Sostituisci OCIT_DOMAIN con il nome di dominio OCIT e gli endpoint con gli indirizzi 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
   

   L'output è simile al seguente esempio:

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

3. Se le modifiche non vengono applicate, riavvia il deployment:

   kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
   

   Questa modifica del DNS viene propagata a tutti i cluster in GDC.

4. Con il file kubeconfig dell'amministratore principale, verifica che la risoluzione del dominio OCIT funzioni come previsto:

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

5. Esporta kubeconfig per il cluster di amministrazione dell'organizzazione:

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

6. Applica il file kubeconfig dell'amministratore dell'organizzazione e verifica che la risoluzione del dominio OCIT funzioni come previsto:

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

2.2 Attiva il resolver ricorsivo

Abilita il resolver ricorsivo nel cluster di amministrazione dell'organizzazione solo per le organizzazioni v1 seguendo i passaggi descritti nel runbook DNS-R0027.

Termina l'upgrade dell'organizzazione tenant in tutte le zone

Una volta completato l'upgrade in una zona, ti consigliamo di verificare che la zona funzioni ancora correttamente prima di procedere con l'upgrade della zona successiva.

Ripeti i passaggi 1 e 2 per l'organizzazione tenant nelle altre zone. Quando tutte le zone hanno eseguito l'upgrade dell'organizzazione tenant, procedi con i passaggi successivi.

3. Esegui l'upgrade delle risorse globali

Le risorse globali devono trovarsi nella versione più bassa di tutte le zone. Avvia la procedura di upgrade delle risorse globali connettendoti alla zona di ancoraggio ed eseguendo i seguenti comandi.

# 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

L'operazione potrebbe richiedere alcuni minuti. Verifica il completamento degli upgrade delle risorse globali eseguendo i seguenti comandi. Il comando non deve segnalare alcun errore.

Importante: la verifica deve essere eseguita solo nella zona di ancoraggio. Il resto delle zone dovrebbe essere messo in pausa e lo stato potrebbe non essere aggiornato.

# 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."

Nota: i sottocomponenti con il nome back-lancer-agent-user-cp nel server API di gestione nello stato ReconciliationError devono essere eliminati manualmente per attivare i backup nei cluster utente o condivisi.

4. Esegui l'upgrade di Tenable SC

1. Esegui GDCH doctor per determinare se è necessario un upgrade:

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

2. Nel caso in cui il validatore tenable_sc_upgrade_readiness non riesca a eseguire l'upgrade dell'immagine, segui questi passaggi per eseguire l'upgrade di Tenable SC nell'organizzazione dei servizi OI:

   1. Recupera il nome della macchina virtuale:

       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)
      

   2. Contrassegna il runningState della macchina virtuale come 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"}}'
      

   3. Disinstalla il grafico Helm esistente per 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:?}
      

   4. Esegui una nuova configurazione di Tenable SC seguendo la procedura descritta in Installare Tenable.SC.

Pulizia post-upgrade

Rimuovi le risorse ClusterRoleBinding create nella sezione Identity and Access Management.

Configurare i periodi di manutenzione per l'upgrade dell'organizzazione tenant

Per eseguire l'upgrade di un'organizzazione tenant, verifica di aver assegnato i ruoli di visualizzatore e amministratore corretti, come descritto nelle pagine Descrizioni dei ruoli predefiniti e Definizioni dei ruoli per i progetti per accedere all'interfaccia a riga di comando (CLI) kubectl e all'interfaccia utente (UI) della console. Se non le hai, segui le istruzioni riportate nella pagina Concedere l'accesso alle risorse del progetto per concederle o richiedere che ti vengano concesse.

Per configurare il periodo di manutenzione, devi disporre dei ruoli necessari. Assicurati di avere assegnati i seguenti ruoli predefiniti:

• Amministratore dell'upgrade dell'organizzazione
• Visualizzatore upgrade organizzazione Nota: l'upgrade di un'organizzazione tenant a una versione secondaria inferiore a quella dell'organizzazione principale non è supportato.

Per impostazione predefinita, è presente un MaintenanceWindow per gli upgrade secondari e un MaintenanceWindow per gli upgrade patch. Gli upgrade secondari migliorano la funzione o apportano modifiche rispetto alla revisione precedente, che è un upgrade del pacchetto, ad esempio per correggere bug. Gli upgrade delle patch risolvono problemi o vulnerabilità specifici. Configura la patch predefinita MaintenanceWindow per avviare gli upgrade delle patch in base a una pianificazione definita.

Per configurare la periodo di manutenzione, utilizza i comandi CLI e kubectl per modificare i campi RRULE e TimeWindow delle risorse MaintenanceWindow. In questo modo, gli upgrade vengono pianificati. Per informazioni su RRULE visita https://pkg.go.dev/github.com/teambition/rrule-go.

Per utilizzare i comandi CLI kubectl, fai clic sulla scheda kubectl. Per visualizzare le istruzioni basate sulla UI, fai clic sulla scheda Console.

Console

1. Accedi all'interfaccia utente dell'organizzazione.

2. Modifica la pianificazione del periodo di manutenzione. Vai alla scheda Manutenzione e fai clic su Modifica.

   Importante: se sei un utente amministrativo, devi disporre del ruolo Amministratore dell'upgrade dell'organizzazione per modificare MaintenanceWindow e del ruolo Visualizzatore dell'upgrade dell'organizzazione per visualizzare gli upgrade pianificati:

   

   Figura 1. Periodo di manutenzione

3. Viene visualizzata la schermata Modifica i periodi di manutenzione. Utilizza la finestra per riconfigurare le finestre temporali Patch e Minor:

   

   Figura 2. Riconfigura la patch e gli aggiornamenti secondari

   Nota: il campo Ricorrenza per Versione secondaria indica la prima, la seconda, la terza, la quarta o l'ultima istanza del Giorno specificato. Quando un mese ha solo quattro istanze di un determinato giorno, l'ultima e la quarta sono equivalenti.

4. Specifica o modifica la Versione patch, l'Ora di inizio e la Durata, nonché il giorno della settimana.

   Modifica Versione secondaria, Ora di inizio, Durata, Ricorrenza e Giorno.

   
   

   Figura 3. Salvare la riconfigurazione

5. Fai clic su Salva per applicare le modifiche.

6. Se le modifiche salvate influiscono sulla ricorrenza, ad esempio se hai implementato una modifica al giorno della settimana o al mese, viene visualizzata una finestra di dialogo. Per confermare le modifiche, fai clic su CONTINUA.
   

   

   Immagine 4. Fai clic su Continua

7. L'esempio seguente mostra gli upgrade pianificati aggiornati in base alle modifiche alla configurazione. Nota il link Salta accanto a ogni stato in attesa. Utilizza questa opzione per ignorare un upgrade in attesa pianificato.

   
   Figura 5. Visualizzazione degli upgrade pianificati, con un'opzione di salto per ciascuno
   

kubectl

1. Accedi alla kubectl CLI. Trova queste istruzioni nella scheda CLI. Prima di procedere, assicurati di disporre dell'accesso corretto al cluster di amministrazione dell'organizzazione.

2. Puoi modificare tre campi in MaintenanceWindow per configurare timeWindow in cui viene eseguito l'upgrade dell'organizzazione tenant. I seguenti comandi mostrano una modifica alla periodo di manutenzione per l'upgrade delle patch. La modifica degli upgrade secondari è simile.

   # 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}'"}]'
   

   L'ora di inizio e l'ora di fine, /spec/timeWindow/start e /spec/timeWindow/end, rispettivamente, devono avere ciascuna una data/mese/anno che si sia verificata in passato. La finestra temporale viene calcolata in base ai valori inseriti.

Alloca almeno la durata minima mostrata per ciascun tipo di upgrade. Puoi allocare una durata maggiore come indicato nei seguenti consigli:

• Aggiornamenti secondari: richiedono almeno 12 ore in una finestra temporale continua di 32 giorni.

• Upgrade delle patch: richiedono almeno 48 ore in una finestra temporale continua di 32 giorni, con uno o più blocchi di tempo. Sebbene la console mostri una specifica di finestra temporale minima di 4 ore, Google consiglia di allocare almeno 6 ore per ogni blocco temporale.

  Importante: l'upgrade della patch potrebbe non richiedere 6 ore, ma Google consiglia questa allocazione del blocco di tempo per tenere conto di eventuali processi di patch lunghi.

Upgrade manuale di Operations Suite Infrastructure Core

Questa procedura di upgrade si applica solo all'upgrade dalla versione 1.13.x alla 1.14.3.

Assicurati che tutti gli account locali e di dominio gestiti siano attivi con password non scadute. Gli account non in regola potrebbero causare errori in questo processo.

Eseguire i checkpoint delle VM e i backup delle directory

1. Esegui checkpoint della VM.

   1. Sull'host BM01, apri una console PS come amministratore.

   2. Esegui questo comando per ogni host Hyper-V nel 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
      }
      

      Tieni aperta la finestra di PowerShell per i passaggi successivi.

2. Attivare i percorsi dei file lunghi

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

3. Esegui il backup dell'unità H:\operations_center. Questa azione supporta il rollback dell'upgrade.

     Rename-Item -Path H:\operations_center -NewName operations_center_backup
   

4. Esegui il backup delle directory di configurazione su CONFIG1. Questo backup fornisce un riferimento per la creazione della nuova configurazione config.ps1.

   1. Sull'host BM01, utilizza Remote Desktop Protocol (RDP) per connetterti all'indirizzo IP della VM CONFIG1 e accedi con un account amministratore di sistema. Esempio: mstsc /v 192.168.100.99

   2. Apri una console PS con Esegui come amministratore.

      • Crea la cartella di backup

      mkdir c:\config1_backup
      

      • Backup C:\dsc

      Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
      

      • Backup di C:\config

      Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
      

      • Backup C:\operations_center

      Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
      

      • Assicurati che i percorsi dei file lunghi siano abilitati

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

Caricare software di terze parti

Svolgi le attività descritte in software di terze parti.

Esegui l'upgrade delle macchine virtuali esistenti

1. Ottieni la directory di installazione.

   1. Scarica il bundle di componenti OIC seguendo le istruzioni della sezione Scarica file.

      Nota: se il tuo ambiente è isolato, dovrai copiare il file *.tar.gz su un'unità USB per il trasferimento.

   2. Sull'host BM01, estrai la directory operations_center da prod_IT_component_bundle.tar.gz scaricato.

      Nota: l'esecuzione di tar.exe in Windows estrae i file nella directory di lavoro corrente. Copia il file nell'unità H prima di estrarlo.

      Set-Location H:
      tar -zxvf prod_IT_component_bundle.tar.gz
      

      L'estrazione del file TAR dovrebbe creare una cartella release nella radice di H:.

   3. Sposta operations_center nella directory principale di H:

      Move-Item -Path H:\release\operations_center -Destination H:\
      

2. Aggiorna config.ps1 con dati specifici del sito

   Il file di configurazione config.ps1 fornisce tutte le informazioni necessarie per creare e configurare l'ambiente Operations Suite Infrastructure (OI). Per aggiornare il file di configurazione, devi raccogliere tutte le seguenti informazioni. Il backup del file config.ps1 esistente è un buon riferimento per proteggere la sovrascrittura involontaria delle impostazioni esistenti. Importante: non procedere finché config.ps1 non è completato e corretto.

   • L'output della configurazione di rete dello strumento occonfigtool, in particolare il file ocinfo.common.opscenter.local.txt. I nomi di rete, ad esempio OCCORE-SERVERS a cui si fa riferimento nei passaggi seguenti, fanno riferimento alla colonna Name del documento.
   • Il nome di dominio e l'indirizzo IP del server DNS di ogni cella GDC gestita da questo OI. Questi dati sono disponibili negli output del questionario di acquisizione dei clienti (CIQ).

   Apporta tutte le modifiche all'host BM01 come Administrator.

3. Copia il codice di esempio di configurazione corretto per il tipo di deployment:

   1. Copia H:\operations_center\dsc\config.example.ps1 in H:\operations_center\config\config.ps1.

4. Utilizzando VSCode o Powershell ISE, convalida e aggiorna i valori in config.ps1.

   1. Se OIC viene implementato come multi-site:

      1. Trova i commenti con l'etichetta ### Multi-Site:
      2. Esegui le azioni descritte nei commenti che hai trovato.

   2. Aggiorna HardwareVersion a meno che il valore predefinito (3.0) non sia corretto.

   3. Aggiorna PrimarySiteCode a meno che il valore predefinito (DC1) non sia corretto.

   4. Il codice del sito viene utilizzato in molti nomi. Cerca e sostituisci tutte le istanze di DC1 con il codice del sito corretto. Utilizza la ricerca senza distinzione tra maiuscole e minuscole. Esamina ogni modifica, poiché alcune potrebbero non essere necessarie. Ad esempio, se il codice del sito è AB1, il nome host DC1-DC1 deve diventare AB1-DC1, non AB1-AB1.

   5. Aggiorna DnsDomain se il valore predefinito non è corretto. Se questo valore viene modificato, cerca e sostituisci opscenter.local in tutto il file config.ps1. Esistono diverse posizioni in cui questo valore predefinito è codificato in modo permanente.

   6. Aggiorna gli oggetti in DnsConditionalForwarder con informazioni specifiche del sito. Deve essere presente almeno un oggetto di inoltro. Rimuovi gli esempi non necessari.

      Questo passaggio può essere eseguito in WSL su CONFIG1 se è installata l'interfaccia a riga di comando gdcloud e kubectl.

      Per estrarre informazioni specifiche del sito dal cluster di amministrazione principale, utilizza:

      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: il nome di dominio DNS della cella GDC, ad esempio dns.delegatedSubdomain in ciq.yaml.

      2. Master: un elenco di IP del server DNS (di solito uno solo). Cerca in cellcfg il tipo DNSReservation. Se la cella GDC è implementata, cerca nello spazio dei nomi dns-system del cluster di amministrazione root l'EXTERNAL-IP del servizio gpc-coredns-external-udp e l'FQDN della cella bert.sesame.street.

      3. Nelle implementazioni multisede esiste un oggetto hashtable per cella.

   7. Non modificare i contenuti degli oggetti Users, Groups e GroupPolicy.

   8. Aggiorna DNSServers in modo che contenga i due indirizzi IP assegnati ai controller di dominio principale e secondario, ad esempio <SITE>-DC1 e <SITE>-DC2.

   9. Aggiorna NTPServers in modo che sia un elenco degli indirizzi IP di SyncServer dalle risorse personalizzate TimeServer dell'amministratore root. Puoi recuperare questo insieme di indirizzi IP utilizzando:

      kubectl get timeserver -A -o json | jq '.items[].address'
      

      Devi formattare questi indirizzi IP in NTPServers come mostrato nell'esempio seguente:

      NtpServers = @(
        '10.251.80.2',
        '10.251.80.3',
        '10.251.80.4',
        '10.251.80.5'
      )
      

   10. Aggiorna il valore predefinito di SubnetPrefix, ovvero 24, con il valore del prefisso della subnet fornito dal cliente per la subnet OCCORE-SERVERS, se necessario.

   11. Aggiorna il valore predefinito di DefaultGateway con il gateway predefinito fornito dal cliente per la subnet OCCORE-SERVERS.

   12. Trova e aggiorna il valore predefinito di WorkstationCider con il valore fornito dal cliente per la subnet OC-WORKSTATIONS nella notazione CIDR IPv4.

   13. Aggiorna il valore WorkstationAllowRemote a $true se il cliente ha scelto di consentire l'accesso remoto alle proprie workstation

   14. Trova e sostituisci il prefisso di subnet di esempio 172.21.0. con il prefisso di subnet OCCORE-SERVERS fornito dal cliente.

   15. Trova e sostituisci il prefisso della subnet di esempio 172.21.2. con il prefisso della subnet OCCORE-JUMPHOSTS fornito dal cliente.

   16. Trova e sostituisci il prefisso della subnet di esempio 172.21.32. con il prefisso della subnet OC-WORKSTATIONS fornito dal cliente.

   17. Trova e sostituisci il valore del messaggio del giorno di esempio legalnoticecaption di Pref caption con la didascalia fornita dal cliente.

   18. Trova e sostituisci il valore del messaggio del giorno di esempio legalnoticetext di Pref text con il testo fornito dal cliente.

   19. Convalida ogni oggetto "nodo" e aggiornalo, se necessario.

       1. NodeName: assicurati che il nome host sia corretto. Alcuni nomi vengono utilizzati in molti luoghi, ad esempio i controller di dominio. Se modifichi un nome qui, controlla se deve essere modificato altrove nella configurazione.

       2. IPv4Addr: deve essere l'indirizzo IP dell'host. L'ultimo ottetto di solito può essere lasciato così com'è. Alcuni potrebbero essere stati aggiornati durante la ricerca e sostituzione della rete eseguita nei passaggi precedenti.

       3. HyperVHost: questo valore deve essere l'indirizzo IP del server Hyper-V che ospita questa VM. Puoi ottenere l'indirizzo IP per ogni server BM?? nella sezione "Server Hyper-V" della configurazione. Non modificare l'assegnazione dell'host Hyper-V in questo campo, in quanto non tutti gli host Hyper-V possono supportare ogni tipo di VM. Modifica solo il nome host Hyper-V con il relativo indirizzo IP.

   20. Convalida i dettagli della seconda interfaccia di rete su tutti i nodi con Role=jumphost. Utilizza i dettagli della subnet OCCORE-JUMPHOSTS per questa interfaccia. Controllo:

       1. JumphostIPv4Cidr
       2. JumphostDefaultGateway

   21. Aggiorna la sezione specifica di ADFS nel nodo in cui Role=adfs.

       Avviso: NON modificare alcuna parte della configurazione di ADFS, se non come indicato. Durante un upgrade, la configurazione ADFS esistente rimane invariata.
       1. Trova la riga Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust"
       2. Sostituisci le tre occorrenze di opscenter.local dopo questa riga con il tuo dominio DNS

   22. Aggiorna gli ambiti DHCP in modo che corrispondano al piano IP del cliente, se necessario. Per ogni ambito, verifica che i seguenti valori siano corretti. I nomi degli ambiti corrispondono ai nomi utilizzati nel piano di rete ocinfo.common.opscenter.local.txt, quindi utilizza i seguenti nella convalida:

       1. ScopeId
       2. IpStartRange
       3. IpEndRange
       4. Router
       5. SubnetMask

   23. Conferma che i valori corrispondano a quelli in config1.ps1 di cui è stato eseguito il backup

   24. Assicurati di salvare il file.

CONFIG1 VM Preparation

La preparazione di CONFIG1 viene eseguita su BM01. Tutti gli altri upgrade vengono eseguiti durante l'accesso alla VM CONFIG1.

1. Copia la directory operations_center nella VM CONFIG1

   1. Sull'host BM01, apri una console PS come amministratore.

   2. Copia operations_center per preparare i file necessari per la macchina virtuale (VM) CONFIG1.

      Nota: Copy-ConfigHostFiles.ps1 non viene utilizzato qui perché l'ambiente è operativo. La copia SMB consente di risparmiare ore di tempo di copia.

      # 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. Disattivare la sincronizzazione dell'ora di Hyper-V

      1. Accedi all'host BM01 come amministratore.

      2. Apri PowerShell su Windows come amministratore ed esegui il seguente comando:

      Importante :nel seguente snippet di codice sostituisci <var>config1_vm_name</var> con il nome della VM CONFIG1, ad esempio DC1-CONFIG1.

      # Disabling Hyper-V Time Sync
      Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
      

   4. Preparazione e convalida della VM CONFIG1

      1. Dall'host BM01, accedi alla VM CONFIG1 con il tuo account -SA. Connettiti all'indirizzo IP della VM utilizzando Remote Desktop (RDP). Esempio: mstsc /v 192.168.100.99

      2. Apri una finestra PowerShell utilizzando il menu "Esegui come utente diverso" per eseguire l'operazione come utente Marvin.

      3. Nella nuova finestra di PowerShell, avvia una sessione amministrativa:

         Start -Verb runas -FilePath powershell.exe
         

         Chiudi la finestra PowerShell precedente, lasciando aperta la finestra dell'amministratore.

      4. Verifica che la finestra amministrativa di PowerShell sia in esecuzione come Marvin

         whoami
         

      5. Disponi i file di cui è stato eseguito lo staging dall'host BM01.

         Move-Item -Path c:\operations_center -Destination c:\release
         C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
         

      6. Verifica che c:\dsc e c:\config esistano.

      7. Copiare i file di credenziali e certificati dal backup

         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. Crea i dati MECM necessari per compilare i file MOF

         C:\dsc\Build-MecmFiles.ps1
         

      9. Verifica che l'ambiente di compilazione sia pronto eseguendo Build-Mof.ps1, che genera file MOF per tutti i computer OI.

         C:\dsc\Build-Mof.ps1
         

   5. Compila le variabili delle credenziali

      Queste variabili vengono utilizzate durante l'intero processo di upgrade. Compilali una volta nella finestra PowerShell di Marvin aperta come amministratore.

      . '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. Verifica che DSC sia in esecuzione e che i server siano raggiungibili.

      $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}
      

      Nota: alcuni nodi potrebbero mostrare lo stato Failure o generare un errore The Consistency Check or Pull cmdlet is in progress. Va bene purché il nodo sia raggiungibile.

Risolvi i problemi di connettività.

1. Se New-CimSession non va a buon fine, verifica che il valore di NodeName sia corretto in config.ps1. Verifica inoltre che il server sia online e raggiungibile.

   L'errore inizierà con Get-CimSession: WinRM cannot process the request.

Esegui l'upgrade dei controller di dominio

Avviso :durante il processo di upgrade, i criteri di gruppo vengono disattivati, il che può causare il ripristino delle impostazioni predefinite delle workstation. Se l'accesso alla workstation è solo remoto, le workstation potrebbero diventare inaccessibili. Determina in che modo il cliente ha attivato l'accesso remoto sulle workstation. Se proviene da Criteri di gruppo, assicurati che il nome del criterio non abbia il prefisso SITE- o OIC-, in quanto verrà eliminato nei passaggi successivi con questa convenzione di denominazione.

1. Mentre hai eseguito l'accesso a CONFIG1, esegui l'upgrade del domain controller primario.

   Compila le variabili, rimuovi i vecchi oggetti Criteri di gruppo e collega i nuovi oggetti Criteri di gruppo.

   $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
   }
   

   Scollega gli oggetti Criteri di gruppo. Verranno collegati al termine dell'upgrade.

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

   Esegui l'upgrade del domain controller primario.

   .\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
   

   Nota: gli errori Copy-Item : An item with the specified name already exists. sono previsti durante Installing PowerShell modules on host e possono essere ignorati in modo sicuro durante gli aggiornamenti dei nodi.
   Avviso: è stato rilevato un problema che influisce sulla copia dei file nei controller di dominio a causa delle limitazioni della lunghezza del percorso. Se si verifica un errore durante Update-RemoteHost, ad esempio a file that already exists on the target destination durante Copying files for the ... role to host, esegui questi comandi. Altrimenti, vai al passaggio successivo.

   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. Convalida la sincronizzazione dell'ora con SyncServer

   2. Accedi a DC1 utilizzando RDP come amministratore di dominio.

      1. Apri una finestra di Powershell come amministratore.

      2. Esegui questo comando per convalidare la configurazione dell'ora.

         w32tm /query /status /verbose
         

   Importante: assicurati che Last Sync Error: sia 0 e che Source corrisponda a uno degli indirizzi IP NtpServers configurati nelle istruzioni per aggiornare i server NTP.

   1. Esegui i seguenti comandi per testare la risincronizzazione dell'ora:

       # Testing time resyncronization
       w32tm /resync
      

       # Desired output
       Sending resync command to local computer
       The command completed successfully.
      

   2. Rivalida la configurazione dell'ora per assicurarti che sia corretta e non presenti errori.

      Importante: assicurati che Last Sync Error: sia 0 e che Time to Last Good Sync Time: sia aggiornato (dovrebbe essere inferiore a un minuto se l'hai eseguito immediatamente dopo la sincronizzazione, ad esempio).

       w32tm /query /status /verbose
      

      Avviso:se vengono rilevati errori o w32tm /resync non riesce, INTERROMPI. Esegui l'escalation a OI Engineering prima di procedere, poiché esiste un alto rischio di bloccare la distribuzione di OI a meno che i servizi di sincronizzazione dell'ora non siano completamente funzionanti.

2. Esegui l'upgrade del secondo domain controller.

   1. Utilizza la finestra PowerShell CONFIG1 esistente per eseguire il seguente script.

      .\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
      

3. Convalida la replica di Active Directory.

   1. Una volta che il secondo controller di dominio è attivo e operativo, esegui i seguenti comandi da uno dei controller di dominio per convalidare la replica di Active Directory:

      repadmin /replsummary
      

      L'output deve essere simile al seguente:

      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
      

Esegui l'upgrade di CA-ISSUING1 e CA-WEB

Importante: esegui sempre l'upgrade di CA-ISSUING1 prima di CA-WEB1.

1. Utilizza il terminale PowerShell esistente su CONFIG1 per eseguire l'upgrade di CA-ISSUING1.

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

2. Utilizza il terminale PowerShell esistente su CONFIG1 per eseguire l'upgrade di CA-WEB.

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

3. Convalidare l'upgrade

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

Upgrade di CA-ROOT1

Utilizza il terminale PowerShell esistente su CONFIG1

1. Accendi 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
   

2. Aggiorna 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
   

   Nota: se si verifica un errore di autenticazione, accedi al server CA-ROOT1 come caadmin. Apri PowerShell come amministratore. Inserisci winrm qc e premi Invio. Accetta le modifiche con un y. Esci da CA-ROOT1 e riprova.

3. Se CA_ROOT1 non è stato riavviato dopo lo script precedente, riavvialo manualmente.

4. Convalida l'upgrade.

     $ca_root | ForEach-Object {
     $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
     Get-DscConfigurationStatus -CimSession $session}
   

   Importante: utilizza w32tm per verificare che la VM si stia sincronizzando con l'host <SITE>-DC1. Esegui questo comando in una shell amministrativa come amministratore locale su CA-ROOT.

5. Verifica che l'impostazione Peer sia <SITE>-DC1.<DNSDOMAIN> e che State sia Active.

   Non procedere se l'ora non è sincronizzata correttamente.

     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)
   

6. Spegni CA-Root.

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

Esegui l'upgrade di ADFS

Utilizza il terminale PowerShell esistente su CONFIG1

1. Esegui l'upgrade della 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}
   

Esegui l'upgrade dei jumphost.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Crea un array di jump host.

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

2. Esegui l'upgrade degli host di rimbalzo.

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

3. Convalida l'upgrade.

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

Esegui l'upgrade di Fileserver.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Crea un array contenente i file server.

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

2. Esegui l'upgrade dei file server.

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

3. Convalida l'upgrade.

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

Esegui l'upgrade dei server DHCP.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Esegui l'upgrade di DHCP1.

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

2. Convalida l'upgrade.

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

3. Esegui l'upgrade di DHCP2.

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

4. convalidare l'upgrade.

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

Esegui l'upgrade dei server Userlock.

Utilizza il terminale PowerShell esistente su CONFIG1

Nota: l'installazione degli upgrade di Userlock richiede alcuni minuti e potrebbe essere necessario riavviare i server.

1. Crea un array PowerShell contenente i server Userlock.

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

2. Rimuovi i file di marcatore dalla configurazione precedente.

     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" }
   

3. Esegui l'upgrade del server Userlock principale.

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

4. Esegui l'upgrade del server Userlock di backup.

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

5. Convalida gli upgrade.

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

Esegui l'upgrade dei server Nessus.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Crea un array PowerShell contenente i server Nessus.

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

2. Esegui l'upgrade dei server Nessus.

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

3. Convalida l'upgrade.

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

Esegui l'upgrade dei server Hyper-V.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Crea un array PowerShell contenente i server Hyper-V.

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

2. Esegui l'upgrade dei server Hyper-V.

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

   Avviso: se si verifica un riavvio di BM01, CONFIG1 verrà riavviato. Una volta disponibile, accedi, apri PowerShell come Marvin ed esegui l'elevazione dei privilegi, quindi esegui il passaggio Config1 prep 1.e. per ricaricare le variabili. Riavvia l'upgrade di Hyper-V.

3. Convalida l'upgrade.

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

Esegui l'upgrade di Toolbox

Utilizza il terminale PowerShell esistente su CONFIG1

Nota: la versione 1.14 include un'unità aggiuntiva su TOOLBOX1 che deve essere creata prima di aggiornare DSC.

1. Crea un array PowerShell contenente i server Toolbox.

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

2. Crea un'unità aggiuntiva sul server 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
        }}}
   

   Verifica che l'output mostri due dischi assegnati alla VM. Esempio:

     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
   

3. Esegui l'upgrade dei server di Toolbox.

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

4. Convalida l'upgrade.

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

Utilizza il terminale PowerShell esistente su CONFIG1 per convalidare l'upgrade.

1. Verifica che DSC sia in esecuzione senza errori.

      $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}
   

Esegui l'upgrade delle VM Splunk

Avviso: procedi con questo upgrade di OIC Splunk solo in coordinamento con SIEM-G0008. Tutte le istanze Splunk zonali e OIC devono avere la stessa versione secondaria per funzionare correttamente.

1. Dalla finestra di PowerShell su CONFIG1, configura ed esegui la configurazione DSC:

   • Inserisci il codice sito. Esempio: "DC1"

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

   • Configura l'heavy forwarder:

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

   • Configura l'indicizzatore 1:

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

   • Configura l'indicizzatore 2:

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

   • Configura indicizzatore 3:

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

   • Configura il gestore:

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

   • Configura l'head di ricerca:

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

2. Dalla finestra di PowerShell su 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
   

3. Segui SIEM-G0006 per impostare Pass4SymmKey globale e SIEM-G0007 per collegare ogni zona a Splunk in OIC.

Esegui l'upgrade dell'host CONFIG1

1. Dalla finestra di PowerShell su CONFIG1:

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

2. Se il computer si riavvia, accedi di nuovo e avvia di nuovo PowerShell come Marvin, quindi esegui l'elevazione a amministratore. Compila le variabili necessarie per le sezioni successive.

   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)

Avviso: Microsoft Configuration Manager non può essere aggiornato.

Poiché MCM non è un componente aggiornabile, l'unica opzione è eliminare gli host MCM esistenti e ripetere il deployment di MCM.

• Assicurati che il software MCM attuale sia stato idratato in seguito all'IT-T0023.

• La procedura di riesecuzione del deployment è descritta in IT-R0019.

Rimuovere i checkpoint delle VM

Una volta completati gli upgrade, i checkpoint devono essere rimossi. I checkpoint possono comportare un utilizzo eccessivo del disco nel tempo. Conservali solo se è necessario un ripristino al checkpoint a causa di un upgrade non riuscito.

Utilizza il terminale PowerShell esistente su CONFIG1

1. Rimuovi i checkpoint della 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
     }}
   

Riattivare gli oggetti Criteri di gruppo nel dominio

Utilizza il terminale PowerShell esistente su CONFIG1

1. Modifica la configurazione del ruolo del controller di dominio per attivare i link negli oggetti Criteri di gruppo gestiti

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

2. Aggiorna il domain controller con il ruolo ObjectOwner:

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

Contatta il team di Google

Consulta la pagina Richiedi assistenza per scoprire come contattare Google per ulteriore supporto.