Esta página foi traduzida pela API Cloud Translation.

Fazer um upgrade em uma implantação multizonal

Em uma implantação multizonal, as zonas são atualizadas uma a uma e de forma independente. Não há uma orquestração global de upgrades em todas as zonas. Um IO precisa fazer um upgrade em todas as zonas da organização que quer atualizar para uma nova versão. Como resultado, as organizações em zonas diferentes podem estar em versões diferentes em um determinado momento.

A ordem de upgrade descrita nesta página é para fazer upgrade da organização raiz e de todas as organizações locatárias em uma zona antes de passar para outra. Os recursos globais são atualizados no final, depois que todas as zonas são atualizadas.

Esta página descreve as etapas para fazer um upgrade com isolamento físico do Google Distributed Cloud (GDC) multizonal fornecendo os seguintes tipos de informações:

Acesso necessário e como obtê-lo.
Quais ferramentas você precisa.
Etapas a seguir antes de fazer um upgrade.
Como e em qual sequência realizar upgrades de vários componentes do Distributed Cloud.

A lista a seguir define cada um dos componentes de um upgrade:

Versão de destino: use a mesma versão de destino para todas as zonas.

Uma por vez: faça upgrade de uma zona por vez. Antes de acionar um upgrade em uma zona, verifique se nenhuma outra zona está executando um upgrade.

Recursos globais: definidos como recursos do Kubernetes implantados no kube-apiserver global, em vez de recursos zonais que têm uma cópia por zona. Os recursos globais seguem um ciclo de vida diferente. Eles precisam ser atualizados apenas uma vez, no final.

Preparação

Os URLs são fornecidos para acesso fora do ambiente isolado.

Antes de iniciar um upgrade, confira se você tem o seguinte:

O caminho para o arquivo kubeconfig que você obteve ao executar gdcloud auth login no cluster de administrador raiz.

Importante: você precisa ter o caminho kubeconfig antes de continuar.
Os novos artefatos de lançamento baixados e transferidos com segurança para sua máquina. Siga as etapas em Enviar os artefatos para o Container Registry.
Uma máquina host para executar os upgrades manuais, com um arquivo kubeconfig do cluster de administrador raiz na máquina.
Todos os problemas conhecidos da versão DE origem são resolvidos antes de iniciar o upgrade. Especificamente para o upgrade da versão 1.13.1, verifique se os seguintes problemas foram resolvidos:
- VMs sem espaço livre no dispositivo

Gerar relatório de compliance

O relatório de compliance lista as organizações que:

estão sem suporte
perder patches de segurança críticos;

A geração de relatórios de compliance é uma etapa opcional e exige um IO autenticado com organization-admin role. Para gerar o relatório, execute o comando a seguir:

  gdcloud system upgrade report-compliance

Para mais informações sobre os requisitos de preparação, consulte a seção Pré-requisitos.

Identity and Access Management

Antes de iniciar um upgrade, em cada zona:

Execute gdcloud auth login no cluster de administrador raiz e em todos os clusters de administrador da organização para conseguir um arquivo kubeconfig.
Siga as instruções no runbook do processo de elevação de acesso e privilégios IAM-R0005 para adicionar:
1. ClusterRoleBinding com o ClusterRole de administrador do cluster em cada cluster de administrador raiz da zona.
2. clusters de administrador da organização para que o acesso administrativo temporário seja obtido.

Pausar os upgrades de recursos globais em todas as zonas

Use o arquivo kubeconfig obtido para pausar todos os upgrades de recursos globais em cada 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

Fazer upgrade da organização raiz global

A atualização da organização raiz global em um nível alto inclui as seguintes etapas:

Faça upgrade da organização raiz em todas as zonas. Cada zona é atualizada individualmente.

Importante: comece o upgrade com a zona principal do StorageGrid e repita para todas as outras zonas na implantação. Essa ordem é necessária para que o armazenamento de objetos funcione corretamente.

Verifique se a zona atual é a principal. O comando a seguir retorna "true" na zona principal e não retorna nada em zonas não principais.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Faça upgrade dos componentes que exigem coordenação entre zonas.
Faça upgrade dos recursos de administrador raiz global.

Verificação antes do upgrade

Faça upgrade de uma zona por vez. Antes de iniciar um upgrade de uma organização em uma zona, conecte-se a todas as outras zonas e execute o seguinte comando para garantir que ele retorne "pronto" em todas as zonas. Se alguma zona informar que não está pronta, não prossiga com o upgrade. Verifique a organização nessa zona para diagnosticar o 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. Baixar e copiar o pacote de atualização

Estas instruções descrevem como começar:

Baixe um pacote de atualização em um dispositivo com acesso à Internet para copiar em um pen drive USB.
Copie o pacote de atualização da unidade USB para o ambiente isolado.

Para mais contexto, consulte Fazer o download de arquivos para baixar os detalhes de uma distribuição do Distributed Cloud e Transferir o download para informações sobre o dispositivo de armazenamento portátil usado para transferir arquivos para seu ambiente isolado.

Trabalhe com seu ponto de contato do Google para decidir se o upgrade é para uma implantação do Distributed Cloud operada por um parceiro e, portanto, deve usar arquivos de lançamento do modelo de parceiro.

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

Baixe o pacote de atualização no seu drive USB em uma máquina com acesso à Internet. Use os detalhes da versão e do resumo fornecidos pelo seu contato principal do Google.
1. Execute gcloud auth login para acessar o bucket do Cloud Storage.
2. Execute o script com --skip-unzip para buscar o pacote de atualização e o script de download para o diretório atual, como /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 você estiver fazendo upgrade com arquivos de lançamento de modelo de parceiro, siga as instruções para preparar os pacotes de software para distribuição de modelo de parceiro.
  
  Observação: pule esta etapa se você não estiver usando arquivos de lançamento de modelo de parceiro para fazer upgrade.
Copie o script de download e o diretório gdch para o pen drive.
Copie a atualização para o OCIT do seu drive USB. Coloque os arquivos em um local semelhante, como /home/download/.

Redefina essas variáveis no OCIT e extraia a atualização:

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

O downloader terá descompactado a versão em gdch/full-release-1.2.0-gdch.243 (por exemplo, /home/download/gdch/full-release-1.2.0-gdch.243). Atribua essa variável ao caminho completo:
```
export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
```

2. Configurar o upgrade do Artifact Registry

Para realizar um upgrade, você precisa fazer o seguinte:

Envie os artefatos para o registro de contêineres

Defina KUBECONFIG como o arquivo kubeconfig do cluster de administrador raiz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Crie o ClusterRoleBindings necessário:

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

Crie o RoleBindings necessário:

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

Crie RoleBindings necessário para enviar o pacote OCI:

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

A saída será semelhante a esta:

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

Siga as instruções em Redimensionar o armazenamento do Artifact Registry para fazer o seguinte:
1. Verifique o uso de armazenamento do Artifact Registry em um cluster de administrador e confira se há espaço suficiente para os artefatos que você quer enviar.
2. Se você precisar aumentar o espaço disponível, siga as etapas em Redimensionar o armazenamento do Artifact Registry.
Configure as configurações do Docker:
```
cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
```
Observação: sempre verifique se esse binário está no lugar antes de executar load-oci.

Configure o Docker para confiar no pacote do repositório de confiança.

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

Carregue os artefatos no registro de artefatos no cluster de administrador raiz:

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

Substitua:

VERSION: a versão do lançamento do Distributed Cloud. Por exemplo, 1.x.y-gdch.z.
KUBECONFIG_PATH: o caminho para o arquivo kubeconfig que você obteve ao executar gdcloud auth login no cluster de administrador raiz.
PACKAGE_VALIDATION_ROOT_CERT_PATH: o caminho para o certificado raiz de validação de pacote. Use o caminho padrão ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt. A inclusão desse caminho valida os certificados de chave de lançamento usados pela validação de pacotes.

Se o comando for bem-sucedido, a saída no final será semelhante a este exemplo:

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 a saída não for parecida com este exemplo, siga estas etapas para resolver os problemas mais comuns:

Se a saída incluir a mensagem Package validation root certificate requires upgrade!, faça a rotação do certificado raiz seguindo as etapas detalhadas em Fazer a rotação do certificado de validação de pacote.
Se load-oci falhar, execute a operação novamente. Se o erro persistir, confira as outras soluções oferecidas nesta lista.
Se a saída incluir a mensagem Error: unable to create k8sclient: Unauthorized, autentique-se novamente. Repita a etapa de preparação para verificar o arquivo kubeconfig ou execute o comando ${ARTIFACTS_ROOT}/gdcloud auth login e tente novamente a operação load-oci.
Se a saída incluir a mensagem UNAUTHORIZED: unauthorized to access repository, você não terá as permissões necessárias para executar o comando load-oci. Escalone o problema para receber as funções necessárias para executar esse comando ou peça para um usuário com as funções necessárias executar o comando em seu nome.

Para fazer upgrade SOMENTE com arquivos de lançamento de modelo de parceiro, siga as instruções para carregar os pacotes de software para distribuição de modelo de parceiro.
Verifique se o objeto ReleaseMetadata da nova versão está no cluster de administrador raiz:
```
kubectl get releasemetadata.artifact.private.gdc.goog VERSION
```
Substitua VERSION pela versão de lançamento do Distributed Cloud. Por exemplo, 1.x.y-gdch.z.

Exemplo de saída:
```
NAME             AGE
1.x.y-gdch.z     2m
```
Verifique se a nova versão está na lista de upgrades disponíveis para a organização raiz que será atualizada:
```
ROOT_NAME=root
kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
```
Por exemplo, 1.x.y-gdch.z, esperamos a seguinte saída:
```
["1.x.y-gdch.z"]
```

Depois que a organização raiz é atualizada para uma nova versão, essa versão fica disponível para upgrades em uma organização locatária.

3. Fazer upgrade da organização raiz

3.1. Pré-upgrade

Defina KUBECONFIG como o arquivo kubeconfig do cluster de administrador raiz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Crie o ClusterRoleBindings necessário:

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

Verifique se a organização raiz está em um estado íntegro, indicado pela resposta True:

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

Exemplo de saída:

True

Siga as instruções no runbook HSM-P0003 para reiniciar todos os HSMs.

3.2. Fazer upgrades automáticos da organização raiz

O upgrade precisa passar pelo processo de IaC. O upgrade é acionado atualizando o campo "version" no objeto OrganizationZonalConfig correspondente da organização na zona.

Atualize a versão no arquivo YAML OrganizationZonalConfig. Exclua a seção spec.capacities.workloadServers do arquivo, se ela existir.

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

Organize e faça commit das mudanças no arquivo.

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Crie uma solicitação de mesclagem.

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

Quando o upgrade começa, um objeto OrganizationUpgrade é criado. Verifique se o objeto OrganizationUpgrade raiz foi criado no cluster de administrador raiz na zona.

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

Se o OrganizationUpgrade não for encontrado, siga o runbook IAC-R0001 para resolver o problema.

3.3. Verificações pós-upgrade

Verifique os resultados do upgrade:
1. Verifique o objeto Organization da organização raiz. Verifique se a condição de status READY é True:
```
kubectl -n gpc-system get organization root
```
  Exemplo de saída:
```
NAME   READY
root   True
```
2. Verifique se Organization.Status.Version mostra a string exata 1.x.y-gdch.z:
```
kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
```
  Exemplo de saída para verificação:
```
1.13.3-gdch.5548
```

Verifique se há falhas de subcomponentes na organização raiz:

Verifique os subcomponentes que mostram o status ReconciliationError ou Reconciling. Aponte o kubeconfig para 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)"'

Para erros, confira as notas da versão e os problemas conhecidos para encontrar uma solução alternativa. Caso contrário , entre em contato com o Distributed Cloud para solucionar problemas.

Se a verificação de simulação ou pós-voo foi ignorada, remova as anotações após a conclusão do upgrade:

Exemplos:

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-

Concluir o upgrade da organização raiz em todas as zonas

Depois que um upgrade é concluído em uma zona, é recomendável verificar se ela ainda está funcionando corretamente antes de fazer upgrade da próxima zona.

Repita as etapas de 1 a 3 para a organização raiz nas outras zonas. Quando todas as zonas tiverem a organização raiz atualizada, siga para as próximas etapas.

4. Fazer upgrade dos recursos globais

Os recursos globais precisam estar na versão mais baixa de todas as zonas. Inicie o processo de upgrade do recurso global conectando-se à zona de ancoragem e executando os seguintes comandos.

# 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

Esse processo pode levar alguns minutos. Execute os comandos a seguir para verificar a conclusão dos upgrades de recursos globais. Nenhuma falha deve ser informada pelo comando.

# 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. Upgrades de componentes entre zonas

Em um universo multizona do GDC, alguns componentes operáveis exigem coordenação entre zonas para concluir os upgrades.

Os seguintes componentes operáveis são atualizados nesta etapa.

Escopo	Componentes operáveis
Infraestrutura	IAC
Infraestrutura	SIEM

Para fazer upgrade do componente operável da IAC, siga o runbook IAC-R0016.

Para fazer upgrade do componente operacional do SIEM, siga o runbook SIEM-G0008.

6. Upgrade manual para sub-rede Anycast

Execute o script a seguir para adicionar os rótulos necessários às sub-redes anycast no servidor de API raiz global:

#!/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 "$@"

Depois que o script for executado, reverta a solução alternativa de anycast manual se ela tiver sido aplicada antes.

7. Upgrade manual do SyncServer

Os seguintes componentes operáveis são atualizados nesta etapa.

Escopo	Componentes operáveis
Infraestrutura	NTP

Essa atualização de firmware não depende de outras etapas e pode ser feita a qualquer momento.

O cluster tem apenas um SyncServer, então não pode operar no modo de alta disponibilidade. O upgrade vai deixar o SyncServer indisponível por um período. O cluster vai continuar marcando o tempo usando os próprios relógios menos precisos, o que não terá efeitos perceptíveis.

Recomendamos que esse processo seja concluído de uma só vez (não deixe para a noite ou para o fim de semana) para evitar o desvio de tempo.

7.1. Processo de upgrade do SyncServer

Os comandos a seguir precisam ser executados no diretório de lançamento do pacote de atualização extraído.

Encontre o firmware mais recente para extração:

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

O nome do arquivo contém a versão do firmware.

Exemplo de saída:

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

Copie apenas os nomes dos arquivos e atribua-os a estas variáveis:
```
export SYNCSERVER_VERSION=syncserver:5.1.2
```

Extraia o firmware da imagem OCI:

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

Extraia o firmware:
```
tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
```
Você vai encontrar um arquivo *.dat e um *updater.zip no diretório de saída.
Siga o runbook NTP-P0002: acessar a interface do SyncServer.
1. Acesse Ajuda -> Sobre -> Versão do software. Se o software instalado for igual ou mais recente que o firmware fornecido, não será necessário atualizar o firmware, e as próximas etapas poderão ser ignoradas.
2. Acesse Admin -> Upgrade na interface do SyncServer. Envie syncserver_s650_license.dat em Authorization File e syncserver_s650_updater.zip em Upgrade File. Em seguida, clique em "Instalar".

Fazer upgrade de uma organização de locatário global

A atualização de uma organização global de locatário em um nível alto inclui as seguintes etapas:

Faça upgrade da organização do locatário em todas as zonas. Cada zona é atualizada individualmente.

Importante: comece o upgrade com a zona principal do StorageGrid e repita para todas as outras zonas na implantação. Essa ordem é necessária para que o armazenamento de objetos funcione corretamente.

Verifique se a zona atual é a principal. O comando a seguir retorna "true" na zona principal e não retorna nada em zonas não principais.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Fazer upgrade dos recursos globais da organização do locatário.

Verificação antes do upgrade

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

Verifique se todos os clusters estão em execução e se todos os pools de nós estão prontos. Se não, corrija-os antes de iniciar o 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. Fazer upgrade de uma organização de locatário

Esta etapa atualiza a versão do Kubernetes, os complementos e os componentes operacionais nos clusters do plano de gerenciamento em uma organização locatária: clusters org-admin, de sistema e de serviço.

A duração geral do upgrade depende do número de etapas. O upgrade automático da organização do locatário pode ser prejudicial e exige uma janela de manutenção.

1.1. Preparação

Para configurar janelas de manutenção, siga as instruções em Configurar janelas de manutenção para upgrade da organização do locatário.

As instruções para iniciar um upgrade da organização do locatário são fornecidas para usar comandos da CLI kubectl ou da infraestrutura como código (IaC). Para usar os comandos de IaC, configure a IaC primeiro:

Configuração da infraestrutura como código.
Configure a infraestrutura como código.

Para usar o nomos e verificar o status, conforme referenciado nas etapas baseadas em IaC, é necessário ter a ferramenta de linha de comando nomos instalada. Para conferir as instruções de instalação e uso do nomos, acesse https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command em um computador com acesso à Internet.

IaC

Definir o clusterrolebinding antes de iniciar o upgrade da organização do locatário usando a IAC

Acesse o diretório iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
Acesse o diretório IO que já foi criado. Se o diretório não existir, crie um.

Adicione um arquivo YAML para atribuir a função de cluster io-organization-admin ao IO. Exemplo:

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

Atualize o kustomatization.yaml para incluir o novo arquivo criado. Se o kustomatization.yaml não existir, crie um novo arquivo:
```
kind: Kustomization
metadata:
  name: org-1-admin-kustomization
resources:
- FILE_NAME.yaml
```
Enviar as mudanças no IAC

kubectl

Defina o clusterrolebinding antes de iniciar o upgrade da organização do locatário usando kubectl

Defina KUBECONFIG como o arquivo kubeconfig do cluster de administrador raiz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
```

Crie o ClusterRoleBindings necessário:

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

Antes de concluir um upgrade de uma versão anterior do Distributed Cloud para 1.13.x ou mais recente, siga as instruções no runbook BIL-R0014 para gerar manualmente uma fatura dos custos deste mês desde o início até o início da data de hoje. Você vai perder os dados de custo criados durante o processo de upgrade da organização do Distributed Cloud.

1.2. Iniciar o upgrade

O upgrade da organização do locatário também é acionado pela IaC ao atualizar o campo de versão no objeto OrganizationZonalConfig correspondente da organização na zona. Confira os detalhes:

Atualize a versão no arquivo 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

Organize e faça commit das mudanças no arquivo.

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Crie uma solicitação de mesclagem.

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

Se o upgrade for iniciado, um objeto OrganizationUpgrade será criado. Verifique se o objeto OrganizationUpgrade foi criado no cluster de administrador raiz na zona.

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

Se o OrganizationUpgrade não for encontrado, siga o runbook IAC-R0001 para resolver o problema.

1.3. Fazer upgrade

O upgrade é realizado quando ele tem um timeWindow que se enquadra na janela de manutenção especificada por um usuário administrador, também chamado de PA. Confira o timeWindow programado:

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

Confira a seguir uma resposta típica ao comando anterior:

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"

No exemplo anterior, a programação do upgrade para 1.8.1-gdch.0 é entre "2022-08-28T00:00:00Z" e "2022-08-28T04:00:00Z".

Quando o upgrade começa, um objeto OrganizationUpgrade é criado, mostrado como kind: OrganizationUpgrade no exemplo de saída anterior.

kind: OrganizationUpgrade

Monitore o status geral do upgrade usando o objeto de upgrade correspondente, anexando o comando da etapa 1 com -w. Por exemplo, para consultar continuamente ORG_NAME sobre o status do upgrade, execute o seguinte:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
```
As etapas do upgrade e o status delas podem ser vistos usando o seguinte:
```
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'
```
A etapa Succeeded se refere ao status geral do upgrade. A etapa Expired é usada para indicar que o upgrade passou do horário programado original. Todos os outros estágios se referem às etapas do upgrade em andamento. O status True se refere às etapas concluídas, e o status Unknown se refere à etapa atual do upgrade.

Se uma verificação de simulação falhar e você tiver certeza de que essa falha é um falso positivo, substitua e pule as opções de verificação de simulação:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check=ok
```
Se uma verificação de pós-condição falhar, e você tiver certeza de que a falha é um falso positivo, substitua e pule as verificações de pós-condição:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check=ok
```
Se a IAC foi usada para fazer upgrade da organização do locatário e o status organizationupgrade mostra "Succeeded" (Concluído), mas Organization para a organização do locatário não está no estado "Ready" (Pronto), aplique a solução alternativa a seguir.

Adicione esta anotação: configmanagement.gke.io/managed: disabled usando IAC à organização. O status do monitor Organization está "Pronto".

O upgrade da organização vai para a próxima etapa, e o status do serviço ou nó será concluído:

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

A atualização da organização pode levar 15 minutos para continuar.

1.4. Verificações pós-upgrade

Verifique o objeto Organization da organização. A condição READY precisa aparecer como True.
```
kubectl -n gpc-system get organization ORG_NAME
```
Exemplo de saída:
```
NAME   READY
org-1  True
```
Verifique Organization.Status.Version. Ela precisa mostrar a string exata da versão de destino:
```
kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
```
Exemplo de saída:
```
1.13.3-gdch.5548
```
Importante: se você acionou uma atualização não programada usando a anotação para ignorar uma janela de manutenção, reverta para usar janelas de tempo programadas.

Reverta a anotação para ignorar as janelas de manutenção:
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
    "upgrade.private.gdc.goog/ignore-maintenance-window-" \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG
```

Verifique se há falhas de subcomponentes na organização do locatário atualizada :

Verifique os subcomponentes que mostram o status ReconciliationError ou Reconciling. Aponte o kubeconfig para 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)"'

Para erros, confira as notas da versão e os problemas conhecidos para encontrar uma solução alternativa. Caso contrário, entre em contato com o Distributed Cloud para solucionar problemas.

Se a verificação de simulação ou pós-voo foi ignorada, remova as anotações após a conclusão do upgrade:

Exemplos:

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. Iniciar um upgrade não programado

Acione um upgrade instantâneo de locatário-organização fora de um maintenanceWindow se você tiver uma necessidade urgente, como um requisito de patch de segurança urgente. Isso só é necessário na organização do locatário, já que a organização raiz já aciona o upgrade instantaneamente.

Execute este comando usando o administrador raiz kubeconfig. O recurso personalizado da organização que você precisa anotar está presente apenas no cluster root-admin. Você não agenda um período para esse processo.

Adicione um patch à organização spec/version para a organização do locatário:

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

Inicie um tenant-org upgrade instantâneo aplicando a anotação ignore-maintenance-window e reiniciando organizationupgrade.

Observação: se o upgrade gerar um erro, aplique o mesmo comando mais de uma vez.

Monitore o status do upgrade:

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

Faça verificações pós-upgrade.

Quando o upgrade urgente for concluído, volte a usar as janelas de tempo programadas:

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

2. Upgrade de DNS

2.1 Criar zonas de encaminhamento

Exporte kubeconfig para o cluster de administrador raiz:

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

Configure o OCIT_DOMAIN usando uma zona de encaminhamento. Substitua OCIT_DOMAIN pelo nome de domínio do OCIT e os endpoints pelos endereços IP do OC DNS:

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

A saída será semelhante a este exemplo:

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

Se as mudanças não forem aplicadas, reinicie a implantação:
```
kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
```
Essa mudança de DNS é propagada para todos os clusters no GDC.

Com o kubeconfig do administrador raiz, valide se a resolução de domínio do OCIT está funcionando conforme o esperado:

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

Exporte kubeconfig para o cluster de administrador da organização:
```
export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
```

Aplique o kubeconfig do administrador da organização e valide se a resolução de domínio do OCIT está funcionando conforme o esperado:

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

2.2 Ativar o resolvedor recursivo

Ative o resolvedor recursivo no cluster de administrador da organização apenas para organizações v1 seguindo as etapas no runbook DNS-R0027.

Concluir o upgrade da organização do locatário em todas as zonas

Depois que um upgrade é concluído em uma zona, é recomendável verificar se ela ainda está funcionando corretamente antes de fazer upgrade da próxima zona.

Repita as etapas 1 e 2 para a organização do locatário nas demais zonas. Quando todas as zonas tiverem a organização do locatário atualizada, siga para as próximas etapas.

3. Fazer upgrade dos recursos globais

Os recursos globais precisam estar na versão mais baixa de todas as zonas. Inicie o processo de upgrade do recurso global conectando-se à zona de ancoragem e executando os seguintes comandos.

# 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

Esse processo pode levar alguns minutos. Execute os comandos a seguir para verificar a conclusão dos upgrades de recursos globais. Nenhuma falha deve ser informada pelo comando.

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

4. Fazer upgrade do Tenable SC

Execute o GDCH doctor para determinar se um upgrade é necessário:

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

Se o validador tenable_sc_upgrade_readiness falhar, a imagem precisará ser atualizada. Siga estas etapas para fazer upgrade do Tenable SC na organização de serviços do OI:

Confira o nome da máquina virtual:

 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)

Marque o runningState da máquina virtual como 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"}}'

Desinstale o gráfico do Helm atual da 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:?}

Faça uma nova configuração do Tenable SC seguindo Instalar o Tenable.SC.

Limpeza pós-upgrade

Remova os recursos ClusterRoleBinding criados na seção Identity and Access Management.

Configurar janelas de manutenção para upgrade da organização do locatário

Para fazer upgrade de uma organização locatária (org), verifique se você tem as funções corretas de leitor e administrador, conforme detalhado nas páginas Descrições de papéis predefinidos e Definições de papéis para projetos para fazer login na interface de linha de comando (CLI) kubectl e na interface do usuário (UI) do console. Se você não tiver essas permissões, siga as instruções na página Conceder acesso aos recursos do projeto para conceder ou solicitar que elas sejam concedidas a você.

Para configurar a janela de manutenção, você precisa ter as funções necessárias. Verifique se você tem os seguintes papéis predefinidos atribuídos:

Administrador de upgrade da organização
Leitor de upgrade da organização Observação: não é possível fazer upgrade de uma organização locatária para uma versão secundária inferior à da organização raiz.

Por padrão, há um MaintenanceWindow para upgrades secundários e um MaintenanceWindow para upgrades de patch. As atualizações secundárias melhoram a função ou fazem mudanças na revisão anterior, que é um upgrade de pacote, por exemplo, para corrigir bugs. Os upgrades de patch resolvem problemas ou vulnerabilidades específicas. Configure o patch padrão MaintenanceWindow para iniciar upgrades de patch de acordo com um cronograma definido.

Para configurar a janela de manutenção, use a CLI e os comandos kubectl para modificar os campos RRULE e TimeWindow dos recursos MaintenanceWindow. Isso programa seus upgrades. Para informações sobre RRULE, acesse https://pkg.go.dev/github.com/teambition/rrule-go.

Para usar os comandos da CLI kubectl, clique na guia kubectl. Para conferir instruções baseadas na UI, clique na guia "Console".

Console

Faça login na interface da organização.
Edite o cronograma da janela de manutenção. Acesse a guia Manutenção e clique em Editar.

Importante: se você for um usuário administrativo, precisará do papel Administrador de upgrade da organização para editar o MaintenanceWindow e do papel Leitor de upgrade da organização para ver os upgrades programados:

Figura 1. Janela de manutenção
A tela Editar janelas de manutenção é aberta. Use a janela para reconfigurar as janelas de tempo Patch e Minor:

Figura 2. Reconfigurar as atualizações secundárias e de patch

Observação: o campo Recorrência para Versão secundária indica a primeira, segunda, terceira, quarta ou última instância do Dia especificado. Quando um mês tem apenas quatro instâncias de um determinado dia, a última e a quarta são equivalentes.
Especifique ou edite a Versão do patch, o Horário de início e a Duração, além do dia da semana.

Edite a Versão secundária, o Horário de início, a Duração, a Recorrência e o Dia.

Figura 3. Salvar a reconfiguração
Clique em Salvar para aplicar as alterações.
Se as mudanças salvas afetarem a recorrência, por exemplo, se você implementou uma mudança no dia da semana ou no mês, uma caixa de diálogo vai aparecer. Para confirmar as mudanças, clique em CONTINUAR.

Figura 4. Clique em Continuar
O exemplo a seguir mostra os upgrades programados atualizados com base nas mudanças de configuração. Observe o link Ignorar ao lado de cada status pendente. Use isso para pular um upgrade pendente programado.

Figura 5. Visualização de upgrades de programação, com uma opção de ignorar para cada

kubectl

Faça login na kubectl CLI. Localize essas instruções na guia da CLI. Verifique se você tem o acesso correto ao cluster de administrador da organização antes de continuar.

É possível modificar três campos no MaintenanceWindow para configurar o timeWindow em que o upgrade da organização do locatário ocorre. Os comandos a seguir mostram uma modificação na janela de manutenção de upgrade de patch. A modificação de upgrades secundários é semelhante.

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

Os horários de início e término, /spec/timeWindow/start e /spec/timeWindow/end, respectivamente, precisam ter uma data/mês/ano que ocorreu no passado. O período é calculado com base nos valores inseridos.

Aloque pelo menos a duração mínima mostrada para cada um dos tipos de upgrade. É possível alocar uma duração maior, conforme indicado nas seguintes recomendações:

Upgrades secundários: exigem pelo menos 12 horas em um período de 32 dias.
Atualizações de patch: exigem pelo menos 48 horas em um período de 32 dias, com um ou mais blocos de tempo. Embora o console mostre uma especificação de janela mínima de 4 horas, o Google recomenda que você aloque pelo menos 6 horas para cada bloco de tempo.

Importante: talvez a atualização do patch não leve 6 horas, mas o Google recomenda essa alocação de período para considerar processos longos.

Upgrade manual do pacote de operações Infrastructure Core

Esse processo de upgrade se aplica apenas à atualização da versão 1.13.x para a 1.14.3.

Verifique se todas as contas locais e de domínio gerenciado estão ativadas com senhas válidas. Contas em um estado ruim podem causar erros nesse processo.

Realizar pontos de verificação de VM e backups de diretório

Faça checkpoints da VM.

No host BM01, abra um console do PS como Administrador.

Execute o seguinte comando para cada host do Hyper-V no 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
}

Mantenha a janela do PowerShell aberta para as próximas etapas.

Ativar caminhos de arquivo longos

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

Faça backup da unidade H:\operations_center. (Essa ação permite reverter o upgrade.)
```
  Rename-Item -Path H:\operations_center -NewName operations_center_backup
```
Faça backup dos diretórios de configuração em CONFIG1. Esse backup fornece uma referência ao criar a nova configuração config.ps1.
1. No host BM01, use o protocolo de área de trabalho remota (RDP) para se conectar ao endereço IP da VM CONFIG1 e faça login com uma conta de administrador do sistema. Exemplo: mstsc /v 192.168.100.99
2. Abra um console do PS com Executar como administrador.
  - Criar a pasta de backup
```
mkdir c:\config1_backup
```
  - Backup C:\dsc
```
Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
```
  - Backup C:\config
```
Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
```
  - Faça backup de C:\operations_center
```
Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
```
  - Verifique se os caminhos longos de arquivos estão ativados
```
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
```

Carregar software de terceiros

Execute as tarefas no software de terceiros.

Fazer upgrade das máquinas virtuais atuais

Consiga o diretório de instalação.
1. Faça o download do pacote de componentes do OIC seguindo as instruções da seção Fazer o download de arquivos.
  
  Observação: se o ambiente estiver isolado, copie o arquivo *.tar.gz para um pen drive e faça a transferência.
2. No host BM01, extraia o diretório operations_center do arquivo prod_IT_component_bundle.tar.gz baixado.
  
  Observação: a execução de tar.exe no Windows extrai para o diretório de trabalho atual. Copie o arquivo para a unidade H antes de extrair.
```
Set-Location H:
tar -zxvf prod_IT_component_bundle.tar.gz
```
  A extração do arquivo .tar cria uma pasta release na raiz de H:
3. Mova operations_center para a raiz de H:
```
Move-Item -Path H:\release\operations_center -Destination H:\
```
Atualizar config.ps1 com dados específicos do site

O arquivo de configuração config.ps1 fornece todas as informações necessárias para criar e configurar o ambiente da infraestrutura da Suite de operações (OI, na sigla em inglês). Para atualizar o arquivo de configuração, colete todas as informações a seguir. O backup do config.ps1 atual é uma boa referência para proteger a substituição não intencional das configurações atuais. Importante: não continue até que config.ps1esteja concluído e correto.
- A saída da configuração de rede da ferramenta occonfigtool, especialmente o arquivo ocinfo.common.opscenter.local.txt. Os nomes de rede, por exemplo, OCCORE-SERVERS mencionados nas etapas a seguir fazem referência à coluna Name desse documento.
- O nome de domínio e o endereço IP do servidor DNS de cada célula do GDC gerenciada por essa OI. Esses dados estão disponíveis nas saídas do Questionário de admissão de clientes (CIQ).
Faça todas as mudanças no host BM01 como Administrator.
Copie o código de exemplo de configuração correto para o tipo de implantação:
1. Copie H:\operations_center\dsc\config.example.ps1 para H:\operations_center\config\config.ps1.
Usando o VSCode ou o PowerShell ISE, valide e atualize os valores em config.ps1.
1. Se o OIC for implantado como multissite:
  1. Encontrar comentários marcados como ### Multi-Site:
  2. Execute as ações descritas nos comentários encontrados.
2. Atualize HardwareVersion, a menos que o padrão (3.0) esteja correto.
3. Atualize PrimarySiteCode, a menos que o padrão (DC1) esteja correto.
4. O código do site é usado em muitos nomes. Pesquise e substitua todas as instâncias de DC1 pelo código do site correto. Use uma pesquisa que não diferencia maiúsculas de minúsculas. Revise cada mudança, já que algumas podem não ser necessárias. Por exemplo, se o código do site for AB1, o nome do host DC1-DC1 precisará mudar para AB1-DC1, não AB1-AB1.
5. Atualize DnsDomain se o padrão não estiver correto. Se esse valor for alterado, pesquise e substitua opscenter.local em todo o arquivo config.ps1. Há vários locais em que esse padrão é codificado.
6. Atualize os objetos em DnsConditionalForwarder com informações específicas do site. É necessário ter pelo menos um objeto de encaminhamento. Remova exemplos desnecessários.
  
  Essa etapa pode ser realizada no WSL em CONFIG1 se a CLI gdcloud e kubectl estiver instalada.
  
  Para extrair informações específicas do site do cluster de administrador raiz, use:
```
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: o nome de domínio DNS da célula do GDC. Por exemplo, dns.delegatedSubdomain em ciq.yaml.
  2. Master: uma lista de IPs de servidores DNS (geralmente apenas um). Procure em cellcfg o tipo DNSReservation. Se a célula do GDC estiver implantada, procure no namespace dns-system do cluster de administração raiz o EXTERNAL-IP do serviço gpc-coredns-external-udp e o FQDN da célula bert.sesame.street.
  3. Em implantações em vários sites, há um objeto de tabela hash por célula.
7. Não mude o conteúdo dos objetos Users, Groups e GroupPolicy.
8. Atualize DNSServers para conter os dois endereços IP atribuídos aos controladores de domínio primário e secundário, como <SITE>-DC1 e <SITE>-DC2.
9. Atualize NTPServers para ser uma lista dos endereços IP do SyncServer dos recursos personalizados TimeServer do administrador raiz. Você pode buscar esse conjunto de endereços IP usando:
```
kubectl get timeserver -A -o json | jq '.items[].address'
```
  Formate esses endereços IP em NTPServers, conforme mostrado no exemplo a seguir:
```
NtpServers = @(
  '10.251.80.2',
  '10.251.80.3',
  '10.251.80.4',
  '10.251.80.5'
)
```
10. Atualize o valor padrão SubnetPrefix, ou seja, 24, com o valor do prefixo da sub-rede fornecido pelo cliente para a sub-rede OCCORE-SERVERS, se necessário.
11. Atualize o valor padrão de DefaultGateway com o gateway padrão fornecido pelo cliente para a sub-rede OCCORE-SERVERS.
12. Encontre e atualize o valor padrão WorkstationCider com o valor fornecido pelo cliente para a sub-rede OC-WORKSTATIONS na notação CIDR IPv4.
13. Atualize o valor WorkstationAllowRemote para $true se o cliente permitir o acesso remoto às estações de trabalho.
14. Localize e substitua o prefixo de sub-rede de exemplo 172.21.0. pelo prefixo de sub-rede OCCORE-SERVERS fornecido pelo cliente.
15. Localize e substitua o prefixo de sub-rede de exemplo 172.21.2. pelo prefixo de sub-rede OCCORE-JUMPHOSTS fornecido pelo cliente.
16. Localize e substitua o prefixo de sub-rede de exemplo 172.21.32. pelo prefixo de sub-rede OC-WORKSTATIONS fornecido pelo cliente.
17. Encontre e substitua o exemplo de mensagem do dia legalnoticecaption valor de Pref caption pela legenda fornecida pelo cliente.
18. Localize e substitua o valor da mensagem do dia de exemplo legalnoticetext de Pref text pelo texto fornecido pelo cliente.
19. Valide cada objeto "node" e atualize, se necessário.
  1. NodeName: confira se o nome do host está correto. Alguns nomes são usados em vários lugares, por exemplo, controladores de domínio. Se você mudar um nome aqui, verifique se ele precisa ser alterado em outro lugar na configuração.
  2. IPv4Addr: precisa ser o endereço IP do host. O último octeto geralmente pode ser deixado como está. Alguns deles podem ter sido atualizados durante a pesquisa e substituição de rede feitas nas etapas anteriores.
  3. HyperVHost: esse valor precisa ser o endereço IP do servidor Hyper-V que hospeda essa VM. É possível encontrar o endereço IP de cada servidor BM?? na seção "Servidores Hyper-V" da configuração. Não mude a atribuição do host do Hyper-V nesse campo, porque nem todos os hosts do Hyper-V podem oferecer suporte a todos os tipos de VM. Mude apenas o nome do host do Hyper-V para o endereço IP correspondente.
20. Valide os detalhes da segunda interface de rede em todos os nós com Role=jumphost. Use os detalhes da sub-rede OCCORE-JUMPHOSTS para essa interface. Verificação:
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
21. Atualize a estrofe específica do ADFS no nó em que Role=adfs.
  
  Aviso: NÃO edite nenhuma parte da configuração do ADFS, exceto conforme indicado. Durante um upgrade, a configuração do ADFS atual é mantida.
  1. Encontre a linha Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust"
  2. Substitua as três ocorrências de opscenter.local após esta linha pelo seu domínio DNS.
22. Atualize os escopos de DHCP para corresponder ao plano de IP do cliente, conforme necessário. Para cada escopo, valide se os seguintes valores estão corretos. Os nomes nos escopos correspondem aos nomes usados no plano de rede ocinfo.common.opscenter.local.txt. Portanto, use o seguinte na validação:
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
23. Confirme se os valores correspondem aos valores em config1.ps1 com backup.
24. Salve o arquivo.

PREPARAÇÃO DA VM CONFIG1

A preparação de CONFIG1 é realizada em BM01. Todos os outros upgrades ocorrem durante o login na VM CONFIG1.

Copie o diretório operations_center para a VM CONFIG1.

No host BM01, abra um console do PS como Administrador.
Copie operations_center para preparar os arquivos necessários para a máquina virtual (VM) CONFIG1.

Observação: Copy-ConfigHostFiles.ps1 não é usado aqui porque o ambiente está operacional. A cópia SMB economiza horas de tempo de cópia.
```
# 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
```
Desativar a sincronização de horário do Hyper-V
1. Faça login no host BM01 como administrador.
2. Abra o PowerShell no Windows como administrador e execute o seguinte comando:
Importante: no próximo snippet de código, substitua <var>config1_vm_name</var> pelo nome da VM CONFIG1, por exemplo, DC1-CONFIG1.
```
# Disabling Hyper-V Time Sync
Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
```
Preparo e validação da VM CONFIG1
1. No host BM01, faça login na VM CONFIG1 com sua conta -SA. Conecte-se ao endereço IP da VM usando a Área de trabalho remota (RDP). Exemplo: mstsc /v 192.168.100.99
2. Abra uma janela do PowerShell usando o menu "Executar como outro usuário" para executar como o usuário Marvin.
3. Na nova janela do PowerShell, inicie uma sessão administrativa:
```
Start -Verb runas -FilePath powershell.exe
```
  Feche a janela anterior do PowerShell e deixe a janela do administrador aberta.
4. Verifique se a janela administrativa do PowerShell está sendo executada como Marvin.
```
whoami
```
5. Organize os arquivos que foram preparados do host BM01.
```
Move-Item -Path c:\operations_center -Destination c:\release
C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
```
6. Valide se c:\dsc e c:\config existem.
7. Copiar arquivos de credenciais e certificados do 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. Criar os dados do MECM necessários para compilar MOFs
```
C:\dsc\Build-MecmFiles.ps1
```
9. Valide se o ambiente de build está pronto executando Build-Mof.ps1, que gera arquivos MOF para todas as máquinas de OI.
```
C:\dsc\Build-Mof.ps1
```

Preencher variáveis de credenciais

Essas variáveis são usadas em todo o processo de upgrade. Preencha-os uma vez na janela do Marvin PowerShell aberta como administrador.

. '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
}

Verifique se o DSC está em execução e se os servidores estão acessíveis.

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

Resolva problemas de conectividade.

Se New-CimSession falhar, verifique se o valor de NodeName está correto em config.ps1. Confirme também se o servidor está on-line e acessível.

O erro vai começar com Get-CimSession: WinRM cannot process the request.

Fazer upgrade dos controladores de domínio

Faça login em CONFIG1 e faça upgrade do controlador de domínio principal.

Preencha as variáveis, remova os GPOs antigos e vincule os novos.

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

Desvincule os objetos de política de grupo. Eles serão vinculados ao final do upgrade.

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

Faça upgrade do controlador de domínio principal.

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

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

Validar a sincronização de tempo com o SyncServer
Faça login em DC1 usando o RDP como um administrador de domínio.
1. Abra uma janela do Powershell como administrador.
2. Execute o comando a seguir para validar a configuração de hora.
```
w32tm /query /status /verbose
```

Execute os comandos a seguir para testar a resincronização de tempo:

 # Testing time resyncronization
 w32tm /resync

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

Revalide se a configuração de hora está correta e não tem erros.

Importante: verifique se Last Sync Error: é 0 e se Time to Last Good Sync Time: foi atualizado. Isso leva menos de um minuto se você executou o comando imediatamente após a sincronização, por exemplo.
```
 w32tm /query /status /verbose
```
Aviso: se erros forem detectados ou w32tm /resync falhar, PARE. Escalone para a engenharia de OI antes de continuar, já que há um alto risco de bloquear a implantação de OI, a menos que os serviços de tempo estejam totalmente funcionais.

Faça upgrade do segundo controlador de domínio.
1. Use a janela do PowerShell CONFIG1 para executar o script a seguir.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
```

Valide a replicação do Active Directory.

Quando o segundo DC estiver funcionando, execute os seguintes comandos em um dos controladores de domínio para validar a replicação do Active Directory:

repadmin /replsummary

A saída será parecida com esta:

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

Fazer upgrade de CA-ISSUING1 e CA-WEB

Use o terminal do PowerShell em CONFIG1 para fazer upgrade do CA-ISSUING1.

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

Use o terminal do PowerShell em CONFIG1 para fazer upgrade do CA-WEB.

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

Validar o upgrade

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

Fazer upgrade de CA-ROOT1

Use o terminal do PowerShell em CONFIG1

Ligue o 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

Atualize 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
```
Observação: se ocorrer um erro de autenticação, faça login no servidor CA-ROOT1 como caadmin. Abra o PowerShell como administrador. Digite winrm qc e pressione "Enter". Aceite as mudanças com um y. Saia de CA-ROOT1 e tente de novo.
Se o CA_ROOT1 não tiver reiniciado após o script anterior, reinicie-o manualmente.
Valide o upgrade.
```
  $ca_root | ForEach-Object {
  $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
  Get-DscConfigurationStatus -CimSession $session}
```
Importante: use w32tm para verificar se a VM está sincronizando com o host <SITE>-DC1. Execute este comando em um shell administrativo como administrador local em CA-ROOT.

Verifique se a configuração Peer é <SITE>-DC1.<DNSDOMAIN> e se State é Active.

Não continue se a hora não estiver sincronizada corretamente.

  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)

Desligue o CA-Root.

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

Fazer upgrade do ADFS

Use o terminal do PowerShell em CONFIG1

Faça upgrade da 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}

Faça upgrade dos jumphosts.

Use o terminal do PowerShell em CONFIG1

Crie uma matriz de Jumphosts.

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

Faça upgrade dos jump hosts.

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

Valide o upgrade.

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

Faça upgrade dos servidores de arquivos.

Use o terminal do PowerShell em CONFIG1

Crie uma matriz que contenha os servidores de arquivos.

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

Faça upgrade dos servidores de arquivos.

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

Valide o upgrade.

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

Faça upgrade dos servidores DHCP.

Use o terminal do PowerShell em CONFIG1

Faça upgrade do DHCP1.

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

Valide o upgrade.

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

Faça upgrade do DHCP2.

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

valide o upgrade.

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

Faça upgrade dos servidores do UserLock.

Use o terminal do PowerShell em CONFIG1

Crie uma matriz do PowerShell que contenha os servidores do UserLock.

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

Remova os arquivos de marcador da configuração anterior.

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

Faça upgrade do servidor UserLock principal.

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

Faça upgrade do servidor Userlock de backup.

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

Valide os upgrades.

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

Faça upgrade dos servidores Nessus.

Use o terminal do PowerShell em CONFIG1

Crie uma matriz do PowerShell que contenha os servidores do Nessus.

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

Faça upgrade dos servidores do Nessus.

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

Valide o upgrade.

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

Faça upgrade dos servidores Hyper-V.

Use o terminal do PowerShell em CONFIG1

Crie uma matriz do PowerShell que contenha os servidores Hyper-V.

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

Faça upgrade dos servidores Hyper-V.
```
  $hyper | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
```
Aviso: se ocorrer uma reinicialização do BM01, o CONFIG1 será reinicializado. Quando estiver disponível, faça login, abra o PowerShell como Marvin e eleve o nível.Em seguida, execute a etapa Preparação da Config1 1.e para recarregar as variáveis. Inicie o upgrade do Hyper-V novamente.

Valide o upgrade.

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

Fazer upgrade das caixas de ferramentas

Use o terminal do PowerShell em CONFIG1

Crie uma matriz do PowerShell que contenha os servidores da caixa de ferramentas.

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

Criar uma unidade adicional no servidor 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
     }}}

Verifique se a saída mostra dois discos atribuídos à VM. Exemplo:

  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

Faça upgrade dos servidores da caixa de ferramentas.

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

Valide o upgrade.

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

Use o terminal do PowerShell atual em `CONFIG1` para validar o upgrade.

Verifique se o DSC está sendo executado sem erros.

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

Fazer upgrade das VMs do Splunk

Na janela do PowerShell em CONFIG1, configure e execute a configuração do DSC:

Insira o código do site. Exemplo: "DC1"

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

Configure o encaminhador pesado:

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

Configurar o indexador 1:

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

Configure o indexador 2:

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

Configure o indexador 3:

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

Configure o gerente:

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

Configure o searchhead:

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

Na janela do PowerShell em 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

Siga SIEM-G0006 para definir o Pass4SymmKey global e SIEM-G0007 para anexar cada zona ao Splunk no OIC.

Fazer upgrade do host CONFIG1

Na janela do PowerShell em CONFIG1:

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

Se o computador for reiniciado, faça login novamente e inicie o PowerShell como Marvin e eleve para administrador. Preencha as variáveis necessárias para as próximas seções.

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)

Como o MCM não é um componente atualizável, a única opção é destruir os hosts do MCM atuais e reimplantar o MCM.

Verifique se o software atual do MCM foi hidratado seguindo IT-T0023.
O procedimento de reimplementação está descrito em IT-R0019.

Remover checkpoints de VM

Depois que os upgrades forem concluídos, os pontos de verificação deverão ser removidos. Os pontos de verificação podem resultar em uso excessivo de disco ao longo do tempo. Mantenha-os apenas se for necessário restaurar para o checkpoint devido a uma falha no upgrade.

Use o terminal do PowerShell em CONFIG1

Remova os pontos de verificação da 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
  }}

Reativar objetos de política de grupo no domínio

Use o terminal do PowerShell em CONFIG1

Mudar a configuração da função do controlador de domínio para ativar links em GPOs gerenciados

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

Atualize o controlador de domínio com a função ObjectOwner:

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

Entre em contato com a equipe do Google

Consulte a página Solicitar suporte para saber como entrar em contato com o Google e receber mais ajuda.

Fazer um upgrade em uma implantação multizonal Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Preparação

Gerar relatório de compliance

Identity and Access Management

Pausar os upgrades de recursos globais em todas as zonas

Fazer upgrade da organização raiz global

Verificação antes do upgrade

1. Baixar e copiar o pacote de atualização

2. Configurar o upgrade do Artifact Registry

Envie os artefatos para o registro de contêineres

3. Fazer upgrade da organização raiz

3.1. Pré-upgrade

3.2. Fazer upgrades automáticos da organização raiz

3.3. Verificações pós-upgrade

Concluir o upgrade da organização raiz em todas as zonas

4. Fazer upgrade dos recursos globais

5. Upgrades de componentes entre zonas

6. Upgrade manual para sub-rede Anycast

7. Upgrade manual do SyncServer

7.1. Processo de upgrade do SyncServer

Fazer upgrade de uma organização de locatário global

Verificação antes do upgrade

1. Fazer upgrade de uma organização de locatário

1.1. Preparação

IaC

kubectl

1.2. Iniciar o upgrade

1.3. Fazer upgrade

1.4. Verificações pós-upgrade

1.5. Iniciar um upgrade não programado

2. Upgrade de DNS

2.1 Criar zonas de encaminhamento

2.2 Ativar o resolvedor recursivo

Concluir o upgrade da organização do locatário em todas as zonas

3. Fazer upgrade dos recursos globais

4. Fazer upgrade do Tenable SC

Limpeza pós-upgrade

Configurar janelas de manutenção para upgrade da organização do locatário

Console

kubectl

Upgrade manual do pacote de operações Infrastructure Core

Realizar pontos de verificação de VM e backups de diretório

Carregar software de terceiros

Fazer upgrade das máquinas virtuais atuais

PREPARAÇÃO DA VM CONFIG1

Resolva problemas de conectividade.

Fazer upgrade dos controladores de domínio

Fazer upgrade de CA-ISSUING1 e CA-WEB

Fazer upgrade de CA-ROOT1

Fazer upgrade do ADFS

Faça upgrade dos jumphosts.

Faça upgrade dos servidores de arquivos.

Faça upgrade dos servidores DHCP.

Faça upgrade dos servidores do UserLock.

Faça upgrade dos servidores Nessus.

Faça upgrade dos servidores Hyper-V.

Fazer upgrade das caixas de ferramentas

Use o terminal do PowerShell atual em CONFIG1 para validar o upgrade.

Fazer upgrade das VMs do Splunk

Fazer upgrade do host CONFIG1

Microsoft Configuration Manager (MCM)

Remover checkpoints de VM

Reativar objetos de política de grupo no domínio

Entre em contato com a equipe do Google

Fazer um upgrade em uma implantação multizonal

Use o terminal do PowerShell atual em `CONFIG1` para validar o upgrade.