Esta página se ha traducido con Cloud Translation API.

Realizar una actualización en un despliegue multizona

En un despliegue multizona, las zonas se actualizan de una en una y de forma independiente. No hay una orquestación global de las actualizaciones en todas las zonas. Un IO debe realizar una actualización en cada zona de la organización a la que quiera actualizar a una nueva versión. Por lo tanto, las organizaciones de diferentes zonas pueden tener versiones distintas en un momento dado.

El orden de actualización que se indica en esta página consiste en actualizar la organización raíz y todas las organizaciones de inquilino de una zona antes de pasar a otra. Los recursos globales se actualizan al final, después de que se hayan actualizado todas las zonas.

En esta página se describen los pasos que hay que seguir para llevar a cabo una actualización de Google Distributed Cloud (GDC) con air gap multizona. Para ello, se proporciona la siguiente información:

Acceso necesario y formas de obtenerlo.
Qué herramientas necesitas.
Qué pasos debes seguir antes de realizar una actualización.
Cómo y en qué orden realizar las actualizaciones de los distintos componentes de Distributed Cloud.

En la siguiente lista se definen los componentes de una actualización:

Versión de destino: usa la misma versión de destino para todas las zonas.

De uno en uno: actualiza las zonas de una en una. Antes de activar una actualización en una zona, asegúrese de que no se esté ejecutando ninguna actualización en otras zonas.

Recursos globales: se definen como recursos de Kubernetes desplegados en el kube-apiserver global, a diferencia de los recursos de zona, que tienen una copia por zona. Los recursos globales siguen un ciclo de vida diferente. Ten en cuenta que solo se deben actualizar una vez al final.

Preparar

Las URLs se proporcionan para acceder fuera de tu entorno aislado.

Antes de iniciar una actualización, debes tener lo siguiente:

La ruta del archivo kubeconfig que ha obtenido ejecutando gdcloud auth login en el clúster de administrador raíz.

Importante: Debes tener la ruta kubeconfig para poder continuar.
Los nuevos artefactos de lanzamiento, descargados y transferidos de forma segura a tu máquina. Sigue los pasos que se indican en el artículo Enviar los artefactos al registro de contenedores.
Una máquina host para ejecutar las actualizaciones manuales, con un archivo de clúster de administrador raíz kubeconfig en la máquina.
Se han solucionado los problemas conocidos de la versión anterior antes de iniciar la actualización. En concreto, para actualizar desde la versión 1.13.1, asegúrate de que se hayan solucionado los siguientes problemas:
- VMs with no space left on device

Generar un informe de cumplimiento

El informe de cumplimiento muestra las organizaciones que:

ya no tienen asistencia
Faltan parches de seguridad críticos

La generación de informes de cumplimiento es un paso opcional y requiere un IO autenticado que tenga organization-admin role. Para generar el informe, ejecuta el siguiente comando:

  gdcloud system upgrade report-compliance

Para obtener más información sobre los requisitos de preparación, consulta la sección Requisitos previos.

Gestión de Identidades y Accesos

Antes de iniciar una actualización, en cada zona:

Obtén un archivo kubeconfig ejecutando gdcloud auth login en el clúster de administrador raíz y en todos los clústeres de administrador de la organización.
Sigue las instrucciones del manual de procedimientos IAM-R0005 sobre el proceso de acceso y elevación de privilegios para añadir lo siguiente:
1. ClusterRoleBinding con el rol cluster-admin ClusterRole en el clúster de administración raíz de cada zona
2. para que se obtenga acceso de administrador temporal.

Pausar las actualizaciones de recursos globales en todas las zonas

Usa el archivo kubeconfig obtenido para pausar todas las actualizaciones de recursos globales de 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

Actualizar la organización raíz global

A grandes rasgos, para actualizar la organización raíz global se deben seguir estos pasos:

Actualiza la organización raíz en todas las zonas. Cada zona se actualiza de forma individual.

Importante: Empieza la actualización con la zona principal de StorageGrid y, a continuación, repite el proceso con todas las demás zonas de la implementación. Este orden es necesario para que el almacenamiento de objetos funcione correctamente.

Comprueba si la zona actual es la principal. El siguiente comando devuelve "true" en la zona principal y no devuelve nada en las zonas no principales.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Actualiza los componentes que requieren coordinación entre zonas.
Actualiza los recursos del administrador raíz global.

Comprobación previa a la actualización

Actualiza las zonas de una en una. Antes de iniciar una actualización de una organización en una zona, conéctate a todas las demás zonas y ejecuta el siguiente comando para asegurarte de que devuelve el estado "ready" en todas las zonas. Si alguna zona indica que no está lista, no continúes con la actualización. Comprueba la organización de esa zona para diagnosticar el 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. Descarga y copia el paquete de actualización

En estas instrucciones se describe cómo empezar:

Descarga un paquete de actualización en un dispositivo con acceso a Internet para copiarlo en una unidad USB.
Copia el paquete de actualización de la unidad USB en tu entorno aislado.

Para obtener más contexto, consulta Descargar archivos para descargar los detalles de una distribución de Distributed Cloud y Transferir descarga para obtener información sobre el dispositivo de almacenamiento portátil que usas para transferir archivos a tu entorno aislado.

Colabora con tu contacto de Google para decidir si la actualización es para una implementación de Distributed Cloud gestionada por un partner y, por lo tanto, debe usar archivos de lanzamiento del modelo de partner.

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

Descarga el paquete de actualización en tu unidad USB desde un ordenador con acceso a Internet. Usa los detalles de la versión y el resumen que te proporcione tu contacto de Google.
1. Ejecuta gcloud auth login para acceder al segmento de Cloud Storage.
2. Ejecuta la secuencia de comandos con --skip-unzip para obtener el paquete de actualización y la secuencia de comandos de descarga en el directorio actual, 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. Si vas a actualizar el software con archivos de lanzamiento de modelos de partners, sigue las instrucciones para preparar los paquetes de software para la distribución de modelos de partners.
  
  Nota: Salta este paso si no vas a usar archivos de lanzamiento de modelos de partners para la actualización.
Copia tanto la secuencia de comandos de descarga como el directorio gdch en tu unidad USB.
Copia la actualización en el OCIT desde tu unidad USB. Coloca los archivos en un lugar similar, como /home/download/.

Redefine estas variables en el OCIT y extrae la actualización:

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

El descargador habrá descomprimido la versión en gdch/full-release-1.2.0-gdch.243 (por ejemplo, /home/download/gdch/full-release-1.2.0-gdch.243). Asigna esta variable a la ruta completa:
```
export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
```

2. Configurar la actualización del registro de artefactos

Para realizar una actualización correctamente, debes hacer lo siguiente:

Enviar los artefactos al registro de contenedores

Asigna el valor KUBECONFIG al archivo kubeconfig del clúster de administrador raíz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Crea el ClusterRoleBindings necesario:

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

Crea el RoleBindings necesario:

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

Crea RoleBindings necesario para insertar el paquete OCI:

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

La salida tiene este aspecto:

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

Sigue las instrucciones de Cambiar el tamaño del almacenamiento de Artifact Registry para hacer lo siguiente:
1. Comprueba el uso del almacenamiento de Artifact Registry en un clúster de administrador y verifica que haya suficiente espacio para los artefactos que quieras enviar.
2. Si necesitas aumentar el espacio disponible, sigue los pasos que se indican en Cambiar el tamaño del almacenamiento de Artifact Registry.
Configura las configuraciones de Docker:
```
cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
```
Nota: Asegúrate siempre de que este archivo binario esté en su sitio antes de ejecutar load-oci.

Configura Docker para que confíe en el paquete trust-store.

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

Carga los artefactos en el registro de artefactos del clúster de administrador raíz:

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

Haz los cambios siguientes:

VERSION: la versión de lanzamiento de Distributed Cloud. Por ejemplo, 1.x.y-gdch.z.
KUBECONFIG_PATH: la ruta al archivo kubeconfig que has obtenido ejecutando gdcloud auth login en el clúster de administrador raíz.
PACKAGE_VALIDATION_ROOT_CERT_PATH: la ruta al certificado raíz de validación del paquete. Debes usar la ruta predeterminada ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt. La inclusión de esta ruta valida los certificados de clave de lanzamiento que se usan en la validación de paquetes.

Si el comando se ha ejecutado correctamente, el resultado final será similar al de este ejemplo:

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

Si el resultado no se parece a este ejemplo, sigue estos pasos para solucionar los problemas más habituales:

Si en el resultado se incluye el mensaje Package validation root certificate requires upgrade!, rota el certificado raíz siguiendo los pasos que se detallan en Rotar el certificado de validación del paquete.
Si load-oci falla, vuelve a ejecutar la operación. Si el error persiste, consulta las otras soluciones que se ofrecen en esta lista.
Si el resultado incluye el mensaje Error: unable to create k8sclient: Unauthorized, debes volver a autenticarte. Repite el paso de preparación para verificar el archivo kubeconfig o ejecuta el comando ${ARTIFACTS_ROOT}/gdcloud auth login y vuelve a intentar la operación load-oci.
Si en el resultado aparece el mensaje UNAUTHORIZED: unauthorized to access repository, significa que no tienes los permisos necesarios para ejecutar el comando load-oci. Deriva este problema para obtener los roles necesarios para ejecutar este comando o pide a un usuario que tenga los roles necesarios que lo ejecute en tu nombre.

Si quieres actualizar el software con archivos de lanzamiento de modelos de partners ÚNICAMENTE, sigue las instrucciones para cargar los paquetes de software para la distribución de modelos de partners.
Verifica que el objeto ReleaseMetadata de la nueva versión esté en el clúster de administrador raíz:
```
kubectl get releasemetadata.artifact.private.gdc.goog VERSION
```
Sustituye VERSION por la versión de lanzamiento de Distributed Cloud. Por ejemplo, 1.x.y-gdch.z.

Ejemplo:
```
NAME             AGE
1.x.y-gdch.z     2m
```
Comprueba que la nueva versión esté en la lista de actualizaciones disponibles de la organización raíz que se va a actualizar:
```
ROOT_NAME=root
kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
```
Por ejemplo, 1.x.y-gdch.z, esperamos el siguiente resultado:
```
["1.x.y-gdch.z"]
```

Una vez que la organización raíz se haya actualizado a una nueva versión, esa versión estará disponible para las actualizaciones de una organización de arrendatario.

3. Actualizar la organización raíz

3.1. Antes de la actualización

Asigna el valor KUBECONFIG al archivo kubeconfig del clúster de administrador raíz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Crea el ClusterRoleBindings necesario:

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

Verifica que la organización raíz esté en buen estado. Para ello, comprueba que la respuesta sea True:

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

Ejemplo:

True

Sigue las instrucciones del runbook HSM-P0003 para reiniciar todos los HSMs.

3.2. Realizar actualizaciones automáticas de la organización raíz

La actualización debe pasar por el proceso de IaC. La actualización se activa al actualizar el campo de versión del objeto OrganizationZonalConfig correspondiente de la organización en la zona.

Actualiza la versión en el archivo OrganizationZonalConfig YAML. Elimina la sección spec.capacities.workloadServers del archivo, si existe.

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

Añade y confirma los cambios del archivo.

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Crea una solicitud de combinación.

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

Cuando se inicia la actualización, se crea un objeto OrganizationUpgrade. Verifica que el objeto raíz OrganizationUpgrade se haya creado en el clúster de administrador raíz de la zona.

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

Si no se encuentra el OrganizationUpgrade, sigue el manual de procedimientos IAC-R0001 para solucionar el problema.

3.3. Comprobaciones posteriores a la actualización

Verifica los resultados de la actualización:
1. Comprueba el objeto Organization de la organización raíz. Comprueba que la condición de estado READY sea True:
```
kubectl -n gpc-system get organization root
```
  Ejemplo:
```
NAME   READY
root   True
```
2. Comprueba que Organization.Status.Version muestre la cadena exacta 1.x.y-gdch.z:
```
kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
```
  Ejemplo de resultado de la verificación:
```
1.13.3-gdch.5548
```

Comprueba si hay errores en los subcomponentes de la organización raíz:

Comprueba los subcomponentes que muestran el estado ReconciliationError o Reconciling. Dirige el kubeconfig a ROOT_ADMIN_KUBECONFIG:

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

Si se producen errores, consulta las notas de la versión y los problemas conocidos para encontrar una solución alternativa. De lo contrario , ponte en contacto con Distributed Cloud para obtener ayuda.

Si se ha omitido la comprobación previa o posterior al vuelo, elimina las anotaciones una vez que se haya completado la actualización:

Ejemplos:

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-

Finalizar la actualización de la organización raíz en todas las zonas

Una vez que se haya completado la actualización en una zona, te recomendamos que compruebes que la zona sigue funcionando correctamente antes de actualizar la siguiente.

Repite los pasos del 1 al 3 para la organización raíz en el resto de las zonas. Cuando se haya actualizado la organización raíz de todas las zonas, continúa con los pasos siguientes.

4. Actualizar recursos globales

Los recursos globales deben estar en la versión más antigua de todas las zonas. Inicia el proceso de actualización de recursos globales conectándote a la zona de acoplamiento y ejecutando los siguientes 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

Este proceso puede tardar unos minutos. Verifica que se han completado las actualizaciones de recursos globales ejecutando los siguientes comandos. El comando no debería devolver ningún error.

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

En un universo multizona de GDC, algunos componentes operativos requieren coordinación entre zonas para completar sus actualizaciones.

En este paso se actualizan los siguientes componentes operativos.

Ámbito	Componentes accionables
Infraestructura	IAC
Infraestructura	SIEM

Para actualizar el componente operable de IAC, sigue el runbook IAC-R0016.

Para actualizar el componente operativo de SIEM, sigue el runbook SIEM-G0008.

6. Actualización manual de la subred Anycast

Ejecuta la siguiente secuencia de comandos para añadir las etiquetas necesarias a las subredes de Anycast en el servidor de la API raíz 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 "$@"

Una vez que el script se haya ejecutado correctamente, revierte la solución alternativa de Anycast manual si se ha aplicado anteriormente.

7. Actualización manual de SyncServer

En este paso se actualizan los siguientes componentes operativos.

Ámbito	Componentes accionables
Infraestructura	NTP

Esta actualización de firmware no depende de ningún otro paso y se puede realizar en cualquier momento.

El clúster solo tiene un SyncServer, por lo que no puede funcionar en modo de alta disponibilidad. La actualización provocará que SyncServer no esté disponible durante un periodo. El clúster seguirá sincronizando la hora con sus propios relojes, que son menos precisos, pero esto no tendrá ningún efecto notable.

Es recomendable completar este proceso de una sola vez (no dejarlo para el día siguiente o para el fin de semana) para evitar que se produzcan desfases.

7.1. Proceso de actualización de SyncServer

Los siguientes comandos deben ejecutarse desde el directorio de lanzamiento del paquete de actualización extraído.

Busca el firmware más reciente para extraerlo:

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

El nombre del archivo contiene la versión del firmware.

Ejemplo:

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

Copia solo los nombres de los archivos y asígnalos a estas variables:
```
export SYNCSERVER_VERSION=syncserver:5.1.2
```

Extrae el firmware de la imagen OCI:

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

Extrae el firmware:
```
tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
```
Debe haber un archivo *.dat y un archivo *updater.zip en el directorio de salida.
Sigue el manual de operaciones NTP-P0002 - Acceder a la interfaz de usuario de SyncServer.
1. Vaya a Ayuda -> Información -> Versión de software. Si el software instalado es igual o posterior al firmware proporcionado, no es necesario actualizar el firmware y se pueden omitir los pasos siguientes.
2. En la interfaz de usuario de SyncServer, vaya a Administrar -> Actualizar. Sube syncserver_s650_license.dat en Authorization File y syncserver_s650_updater.zip en Upgrade File. A continuación, haz clic en Instalar.

Actualizar una organización de cliente global

A grandes rasgos, para actualizar una organización de inquilino global, debes seguir estos pasos:

Actualiza la organización de inquilinos en todas las zonas. Cada zona se actualiza de forma individual.

Importante: Empieza la actualización con la zona principal de StorageGrid y, a continuación, repite el proceso con todas las demás zonas de la implementación. Este orden es necesario para que el almacenamiento de objetos funcione correctamente.

Comprueba si la zona actual es la principal. El siguiente comando devuelve "true" en la zona principal y no devuelve nada en las zonas no principales.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Actualiza los recursos de la organización del cliente global.

Comprobación previa a la actualización

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

Asegúrate de que todos los clústeres estén en el estado "Running" (En ejecución) y de que todos los grupos de nodos estén en el estado "Ready" (Listo). Si no es así, corrígelos antes de iniciar la actualización.

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. Actualizar una organización de cliente

En este paso se actualiza la versión de Kubernetes, los complementos y los componentes operativos de los clústeres del plano de gestión de una organización de arrendatario (clústeres de administrador de la organización, del sistema y de servicio).

La duración total de la actualización depende del número de fases que tenga. La actualización automática de la organización de inquilinos puede ser perjudicial y requiere una ventana de mantenimiento.

1.1. Preparación

Para configurar las ventanas de mantenimiento, consulta el artículo Configurar ventanas de mantenimiento para la actualización de la organización de inquilinos.

Se proporcionan instrucciones para iniciar una actualización de una organización de arrendatario mediante comandos de la CLI o comandos de infraestructura como código (IaC).kubectl Para usar los comandos de IaC, primero debes configurar IaC:

Configuración de la infraestructura como código.
Configura la infraestructura como código.

Para usar nomos y verificar el estado como se indica en los pasos basados en IaC, debes tener instalada la herramienta de línea de comandos nomos. Para obtener instrucciones sobre la instalación y el uso de nomos, visita https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command desde un ordenador con acceso a Internet.

IaC

Define el clusterrolebinding antes de iniciar la actualización de la organización de inquilinos mediante IAC

Ve al directorio iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
Ve al directorio IO que ya se ha creado. Si el directorio no existe, crea uno.

Añade un archivo YAML para asignar el rol de clúster io-organization-admin a la entrada/salida. Por ejemplo:

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

Actualiza el kustomatization.yaml para incluir el nuevo archivo creado. Si el archivo kustomatization.yaml no existe, crea uno:
```
kind: Kustomization
metadata:
  name: org-1-admin-kustomization
resources:
- FILE_NAME.yaml
```
Enviar los cambios en IAC

kubectl

Define el clusterrolebinding antes de iniciar la actualización de la organización de inquilinos con kubectl

Asigna el valor KUBECONFIG al archivo kubeconfig del clúster de administrador raíz.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
```

Crea el ClusterRoleBindings necesario:

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

Antes de completar una actualización de una versión anterior de Distributed Cloud a la 1.13.x o una posterior, sigue las instrucciones del runbook BIL-R0014 para generar manualmente una factura de los costes de este mes desde el principio del mes hasta el principio del día actual. Perderá los datos de costes creados durante el proceso de actualización de la organización de Distributed Cloud.

1.2. Iniciar la actualización

La actualización de la organización de inquilinos también se activa a través de IaC. Para ello, se actualiza el campo de versión del objeto OrganizationZonalConfig correspondiente de la organización en la zona. A continuación, te indicamos los detalles:

Actualiza la versión en el archivo OrganizationZonalConfig YAML.

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

Añade y confirma los cambios del archivo.

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Crea una solicitud de combinación.

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

Si se inicia la actualización, se crea un objeto OrganizationUpgrade. Verifica que el objeto OrganizationUpgrade se haya creado en el clúster de administrador raíz de la zona.

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

Si no se encuentra el OrganizationUpgrade, sigue el manual de procedimientos IAC-R0001 para solucionar el problema.

1.3. Actualizar

La actualización se realiza cuando tiene un timeWindow que se encuentra dentro de la ventana de mantenimiento que especifica un usuario administrador, también llamado PA. Para ver la timeWindow programada, sigue estos pasos:

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

A continuación se muestra una respuesta típica al 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"

En el ejemplo anterior, la programación de la actualización a 1.8.1-gdch.0 es entre "2022-08-28T00:00:00Z" y "2022-08-28T04:00:00Z".

Cuando se inicia la actualización, se crea un objeto OrganizationUpgrade, que se muestra como kind: OrganizationUpgrade en el ejemplo de salida anterior.

kind: OrganizationUpgrade

Supervisa el estado general de la actualización con el objeto de actualización correspondiente. Para ello, añade -w al comando del paso 1. Por ejemplo, para consultar continuamente ORG_NAME sobre el estado de la actualización, ejecuta lo siguiente:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
```
Para ver las fases de la actualización y su estado, puedes usar lo siguiente:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o jsonpath='{.status.conditions}' | \
jq -r '["Stage", "Status", "Reason", "Message"], ["---", "---", "---", "---"], (.[] | [.type, .status, .reason, .message]) | @tsv' | column -ts $'\t'
```
La fase Succeeded hace referencia al estado general de la actualización. La fase Expired se usa para indicar que la actualización ha superado la hora programada originalmente. El resto de las fases hacen referencia a los pasos de la actualización en curso. El estado True hace referencia a los pasos completados y el estado Unknown, al paso actual de la actualización.

Si una comprobación previa ha fallado y estás seguro de que se trata de un falso positivo, anula y salta las opciones de comprobación previa:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check=ok
```
Si una comprobación posterior ha fallado y estás seguro de que se trata de un falso positivo, anula y omite las comprobaciones posteriores:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check=ok
```
Si se ha usado IAC para actualizar la organización de inquilinos y el estado de organizationupgrade es "Succeeded" (Correcto) y el de Organization no es "Ready" (Listo), aplica la siguiente solución alternativa.

Añade esta anotación: configmanagement.gke.io/managed: disabled using IAC a la organización. El estado de la monitorización Organization es "Listo".

La actualización de la organización debería pasar a la siguiente fase y el estado del servicio o del nodo debería ser "Completado":

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

La actualización de la organización puede tardar 15 minutos en continuar.

1.4. Comprobaciones posteriores a la actualización

Comprueba el objeto Organization de la organización. El atributo de estado READY debe ser True.
```
kubectl -n gpc-system get organization ORG_NAME
```
Ejemplo:
```
NAME   READY
org-1  True
```
Consulta Organization.Status.Version. Debe mostrar la cadena exacta de la versión de destino:
```
kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
```
Ejemplo:
```
1.13.3-gdch.5548
```
Importante: Si has activado una actualización no programada usando la anotación para ignorar una ventana de mantenimiento, debes revertirla para usar ventanas de tiempo programadas.

Para revertir la anotación e ignorar las ventanas de mantenimiento, sigue estos pasos:
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
    "upgrade.private.gdc.goog/ignore-maintenance-window-" \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG
```

Comprueba si hay errores en los subcomponentes de la organización del arrendatario actualizada :

Comprueba los subcomponentes que muestren el estado ReconciliationError o Reconciling. Dirige el kubeconfig a ORG_MGMT_API_KUBECONFIG:

export KUBECONFIG=ORG_MGMT_API_KUBECONFIG

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

Si se producen errores, consulta las notas de la versión y los problemas conocidos para encontrar una solución alternativa. De lo contrario, ponte en contacto con Distributed Cloud para solucionar el problema.

Si se ha omitido la comprobación previa o posterior al vuelo, elimina las anotaciones una vez que se haya completado la actualización:

Ejemplos:

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 una actualización no programada

Activa una actualización instantánea de la organización de inquilinos fuera de un maintenanceWindow si tienes una necesidad urgente, como un parche de seguridad urgente. Esto solo es necesario en la organización de inquilino, ya que la organización raíz ya activa la actualización al instante.

Ejecuta este comando con el administrador raíz kubeconfig. El recurso personalizado de organización que debes anotar solo está presente en el clúster root-admin. No tienes que programar un periodo para este proceso.

Aplica un parche a la organización spec/version de la organización de inquilino:

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

Inicia una tenant-org upgrade instantánea aplicando la anotación ignore-maintenance-window y reiniciando organizationupgrade.

Nota: Si la actualización genera un error, aplica el mismo comando más de una vez.

Monitoriza el estado de la actualización:

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

Realiza las comprobaciones posteriores a la actualización.

Cuando se haya completado la actualización urgente, vuelve a usar los periodos programados:

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

2. Actualización de DNS

2.1 Crear zonas de reenvío

Exporta kubeconfig para el clúster de administrador raíz:

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

Configura el OCIT_DOMAIN mediante una zona directa. Sustituye OCIT_DOMAIN por el nombre de dominio de OCIT y los endpoints por las direcciones IP de DNS de OC:

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

La salida tiene este aspecto:

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

Si los cambios no se aplican, reinicia la implementación:
```
kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
```
Este cambio de DNS se propaga a todos los clústeres de GDC.

Con el archivo kubeconfig del administrador raíz, comprueba que la resolución del dominio OCIT funciona correctamente:

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

Exporta kubeconfig del clúster de administrador de la organización:
```
export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
```

Aplica el archivo kubeconfig del administrador de la organización y comprueba que la resolución del dominio OCIT funciona correctamente:

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

2.2 Habilita el resolvedor recursivo

Habilita el resolvedor recursivo en el clúster de administrador de la organización solo para las organizaciones de la versión 1. Para ello, sigue los pasos que se indican en el manual de operaciones DNS-R0027.

Finalizar la actualización de la organización de inquilinos en todas las zonas

Una vez que se haya completado la actualización en una zona, te recomendamos que compruebes que la zona sigue funcionando correctamente antes de actualizar la siguiente.

Repite los pasos 1 y 2 para la organización de inquilinos en el resto de las zonas. Cuando se haya actualizado la organización de inquilino de todas las zonas, continúa con los pasos siguientes.

3. Actualizar recursos globales

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

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

Este proceso puede tardar unos minutos. Verifica que se han completado las actualizaciones de recursos globales ejecutando los siguientes comandos. El comando no debería devolver ningún error.

# 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. Actualizar Tenable SC

Ejecuta GDCH doctor para determinar si es necesario actualizarlo:

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

Si el validador tenable_sc_upgrade_readiness no funciona, la imagen debe actualizarse. Sigue estos pasos para actualizar Tenable SC en la organización de servicios de OI:

Obtén el nombre de la 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)

Marca el runningState de la 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"}}'

Desinstala el gráfico de Helm de la VM:

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

Realiza una configuración nueva de Tenable SC siguiendo las instrucciones de Instalar Tenable.SC.

Limpieza posterior a la actualización

Elimina los recursos de ClusterRoleBinding creados en la sección Gestión de identidades y accesos.

Configurar ventanas de mantenimiento para la actualización de la organización de inquilino

Para actualizar una organización de arrendatario, comprueba que tienes asignados los roles de lector y administrador correctos, tal como se detalla en las páginas Descripciones de roles predefinidos y Definiciones de roles de proyectos, para iniciar sesión en la interfaz de línea de comandos (CLI) kubectl y en la interfaz de usuario (IU) de la consola. Si no los tienes, sigue las instrucciones de la página Conceder acceso a recursos de proyectos para concederlos o solicitar que se te concedan.

Para configurar la ventana de mantenimiento, debes tener los roles necesarios. Asegúrate de que tienes asignados los siguientes roles predefinidos:

Administrador de actualización de la organización
Lector de actualización de la organización Nota: No se admite la actualización de una organización de inquilino a una versión secundaria inferior a la de la organización raíz.

De forma predeterminada, hay un MaintenanceWindow para las actualizaciones menores y otro para las actualizaciones de parche.MaintenanceWindow Las actualizaciones menores mejoran las funciones o hacen cambios en la revisión anterior, que es una actualización de paquetes (por ejemplo, para corregir errores). Las actualizaciones de parches solucionan problemas o vulnerabilidades específicos. Configura el parche predeterminado MaintenanceWindow para iniciar las actualizaciones de parches según una programación definida.

Para configurar la ventana de mantenimiento, usa la CLI y los comandos kubectl para modificar los campos RRULE y TimeWindow de los recursos MaintenanceWindow. De esta forma, se programarán las actualizaciones. Para obtener información sobre RRULE, visita https://pkg.go.dev/github.com/teambition/rrule-go.

Para usar los comandos de la CLI de kubectl, haz clic en la pestaña kubectl. Para ver las instrucciones basadas en la interfaz de usuario, haz clic en la pestaña Consola.

Consola

Inicia sesión en la interfaz de usuario de la organización.
Edita la programación de la ventana de mantenimiento. Vaya a la pestaña Mantenimiento y haga clic en Editar.

Importante: Si eres un usuario administrativo, necesitas el rol Administrador de actualización de la organización para editar MaintenanceWindow y el rol Lector de actualización de la organización para ver las actualizaciones programadas:

Imagen 1. Ventana de mantenimiento
Se abrirá la pantalla Editar ventanas de mantenimiento. Usa la ventana para reconfigurar los intervalos de tiempo Parche y Menor:

Imagen 2. Reconfigurar los parches y las actualizaciones menores

Nota: El campo Recurrencia de Versión secundaria indica la primera, segunda, tercera, cuarta o última instancia del Día especificado. Cuando un mes solo tiene cuatro instancias de un día concreto, la última y la cuarta son equivalentes.
Especifica o edita la versión del parche, la hora de inicio y la duración, así como el día de la semana.

Edita la hora de inicio, la duración, la periodicidad y el día de la versión secundaria.

Imagen 3. Guardar la reconfiguración
Haz clic en Guardar para aplicar los cambios.
Si los cambios guardados afectan a la periodicidad (por ejemplo, si has cambiado el día de la semana o el mes), verás un cuadro de diálogo. Para confirmar los cambios, haz clic en CONTINUAR.

Imagen 4. Haz clic en Continuar.
En el ejemplo siguiente se muestran las actualizaciones programadas actualizadas en función de los cambios que hayas realizado en la configuración. Verá el enlace Saltar junto a cada estado pendiente. Úsalo para saltar una actualización pendiente programada.

Imagen 5. Vista de las actualizaciones programadas, con una opción para omitir cada una

kubectl

Inicia sesión en la CLI de kubectl. Busca estas instrucciones en la pestaña CLI. Asegúrate de que tienes el acceso correcto al clúster de administrador de la organización antes de continuar.

Puede modificar tres campos en el MaintenanceWindow para configurar el timeWindow en el que se produce la actualización de la organización del arrendatario. Los siguientes comandos muestran una modificación en la ventana de mantenimiento de actualización de parches. La modificación de las actualizaciones menores es similar.

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

La hora de inicio y la hora de finalización, /spec/timeWindow/start y /spec/timeWindow/end, respectivamente, deben tener una fecha (día, mes y año) que haya tenido lugar en el pasado. La ventana temporal se calcula en función de los valores que introduzcas.

Asigna al menos la duración mínima que se muestra para cada uno de los tipos de actualización. Puedes asignar una duración mayor, tal como se indica en las siguientes recomendaciones:

Actualizaciones menores: requieren al menos 12 horas en un periodo de 32 días.
Actualizaciones de parches: requieren al menos 48 horas en un periodo de 32 días, con uno o varios bloques de tiempo. Aunque la consola muestra una ventana de 4 horas como mínimo, Google recomienda que asignes al menos 6 horas a cada bloque de tiempo.

Importante: Es posible que la actualización del parche no tarde 6 horas, pero Google recomienda asignar este periodo para tener en cuenta los procesos de parche largos.

Actualización manual de la infraestructura principal de Operations Suite

Este proceso de actualización solo se aplica a la actualización de la versión 1.13.x a la 1.14.3.

Asegúrate de que todas las cuentas de dominio y locales gestionadas tengan contraseñas que no hayan caducado. Si las cuentas no están en buen estado, pueden producirse errores en este proceso.

Realizar puntos de control de máquinas virtuales y copias de seguridad de directorios

Realiza puntos de control de la máquina virtual.

En el host BM01, abre una consola de PS como Administrador.

Ejecuta el siguiente comando en cada host de Hyper-V del clúster.

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

Mantén abierta la ventana de PowerShell para seguir con los pasos siguientes.

Habilitar rutas de archivo largas

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

Crea una copia de seguridad de la unidad H:\operations_center. (Esta acción permite revertir la actualización).
```
  Rename-Item -Path H:\operations_center -NewName operations_center_backup
```
Directorios de configuración de copia de seguridad en CONFIG1. Esta copia de seguridad proporciona una referencia al crear la nueva configuración config.ps1.
1. En el host BM01, usa el protocolo de escritorio remoto (RDP) para conectarte a la dirección IP de la VM CONFIG1 e inicia sesión con una cuenta de administrador del sistema. Ejemplo: mstsc /v 192.168.100.99
2. Abre una consola de PS con la opción Ejecutar como administrador.
  - Crear la carpeta de copia de seguridad
```
mkdir c:\config1_backup
```
  - Copia de seguridad de C:\dsc
```
Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
```
  - Copia de seguridad de C:\config
```
Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
```
  - Copia de seguridad de C:\operations_center
```
Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
```
  - Asegurarse de que las rutas de archivo largas estén habilitadas
```
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
```

Cargar software de terceros

Realiza las tareas en software de terceros.

Actualizar máquinas virtuales

Obtén el directorio de instalación.
1. Descarga el paquete de componentes de OIC siguiendo las instrucciones de la sección Descargar archivos.
  
  Nota: Si tu entorno está aislado, tendrás que copiar el archivo *.tar.gz en una unidad USB para transferirlo.
2. En el host BM01, extrae el directorio operations_center del archivo prod_IT_component_bundle.tar.gz descargado.
  
  Nota: Al ejecutar tar.exe en Windows, los archivos se extraen en el directorio de trabajo actual. Copia el archivo en la unidad H antes de extraerlo.
```
Set-Location H:
tar -zxvf prod_IT_component_bundle.tar.gz
```
  Al extraer el archivo TAR, se debería crear una carpeta release en la raíz de H:.
3. Mover operations_center a la raíz de H:
```
Move-Item -Path H:\release\operations_center -Destination H:\
```
Actualiza config.ps1 con datos específicos del sitio

El archivo de configuración config.ps1 proporciona toda la información necesaria para crear y configurar el entorno de infraestructura de Operations Suite (OI). Para actualizar el archivo de configuración, debe recopilar toda la información siguiente. La copia de seguridad del archivo config.ps1 es una buena referencia para evitar que se sobrescriban los ajustes por error. Importante: No continúes hasta que config.ps1 se haya completado correctamente.
- El resultado de la configuración de red de la herramienta occonfigtool, especialmente el archivo ocinfo.common.opscenter.local.txt. Los nombres de las redes, como OCCORE-SERVERS que se mencionan en los pasos siguientes, hacen referencia a la columna Name de ese documento.
- El nombre de dominio y la dirección IP del servidor DNS de cada celda de GDC que gestiona este OI. Estos datos están disponibles en los resultados del cuestionario de información del cliente (CIQ).
Haz todos los cambios en el host BM01 como Administrator.
Copia el código de ejemplo de configuración correcto para el tipo de implementación:
1. Copia H:\operations_center\dsc\config.example.ps1 en H:\operations_center\config\config.ps1.
Con VSCode o Powershell ISE, valida y actualiza los valores de config.ps1.
1. Si OIC se implementa como multisitio:
  1. Buscar comentarios etiquetados como ### Multi-Site:
  2. Realiza las acciones descritas en los comentarios que has encontrado.
2. Actualiza HardwareVersion a menos que el valor predeterminado (3.0) sea correcto.
3. Actualiza PrimarySiteCode a menos que el valor predeterminado (DC1) sea correcto.
4. El código de sitio se usa en muchos nombres. Busca y sustituye todas las instancias de DC1 por el código de sitio correcto. Utiliza la búsqueda sin distinguir entre mayúsculas y minúsculas. Revisa cada cambio, ya que puede que algunos no sean necesarios. Por ejemplo, si el código de sitio es AB1, el nombre de host DC1-DC1 debe cambiar a AB1-DC1, no a AB1-AB1.
5. Actualiza DnsDomain si el valor predeterminado no es correcto. Si se cambia este valor, busca y sustituye opscenter.local en todo el archivo config.ps1. Hay varias ubicaciones en las que ese valor predeterminado está codificado.
6. Actualiza los objetos de DnsConditionalForwarder con información específica del sitio. Debe haber al menos un objeto de reenvío. Elimina los ejemplos innecesarios.
  
  Este paso se puede realizar en WSL en CONFIG1 si se ha instalado la CLI gdcloud y kubectl.
  
  Para obtener información específica de un sitio del clúster de administrador raíz, usa lo siguiente:
```
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: nombre de dominio DNS de la celda de GDC. Por ejemplo, dns.delegatedSubdomain en ciq.yaml.
  2. Master: una lista de IPs de servidores DNS (normalmente, solo una). Busca en cellcfg el tipo DNSReservation. Si se ha desplegado la celda de GDC, busca en el espacio de nombres dns-system del clúster de administración raíz la dirección IP EXTERNA del servicio gpc-coredns-external-udp y el nombre de dominio completo de la celda: bert.sesame.street.
  3. En las implementaciones multisitio, hay un objeto de tabla hash por celda.
7. No cambies el contenido de los objetos Users, Groups y GroupPolicy.
8. Actualiza DNSServers para que contenga las dos direcciones IP asignadas a los controladores de dominio principal y secundario, como <SITE>-DC1 y <SITE>-DC2.
9. Actualiza NTPServers para que sea una lista de las direcciones IP de SyncServer de los recursos personalizados TimeServer del administrador raíz. Puedes obtener este conjunto de direcciones IP mediante lo siguiente:
```
kubectl get timeserver -A -o json | jq '.items[].address'
```
  Debes dar formato a estas direcciones IP en NTPServers, tal como se muestra en el siguiente ejemplo:
```
NtpServers = @(
  '10.251.80.2',
  '10.251.80.3',
  '10.251.80.4',
  '10.251.80.5'
)
```
10. Actualiza el valor predeterminado de SubnetPrefix, es decir, 24, con el valor del prefijo de subred proporcionado por el cliente para la subred OCCORE-SERVERS si es necesario.
11. Actualiza el valor predeterminado de DefaultGateway con la puerta de enlace predeterminada proporcionada por el cliente para la subred OCCORE-SERVERS.
12. Busque y actualice el valor predeterminado de WorkstationCider con el valor proporcionado por el cliente para la subred OC-WORKSTATIONS en la notación CIDR de IPv4.
13. Actualiza el valor de WorkstationAllowRemote a $true si el cliente ha aceptado permitir el acceso remoto a sus estaciones de trabajo.
14. Busca y sustituye el prefijo de subred de ejemplo 172.21.0. por el prefijo de subred OCCORE-SERVERS proporcionado por el cliente.
15. Busca y sustituye el prefijo de subred de ejemplo 172.21.2. por el prefijo de subred OCCORE-JUMPHOSTS proporcionado por el cliente.
16. Busca y sustituye el prefijo de subred de ejemplo 172.21.32. por el prefijo de subred OC-WORKSTATIONS proporcionado por el cliente.
17. Busca y sustituye el mensaje del día de ejemplo legalnoticecaption con el valor Pref caption por el texto proporcionado por el cliente.
18. Busca y sustituye el valor del mensaje del día de ejemplo legalnoticetext de Pref text por el texto que te haya proporcionado el cliente.
19. Valida cada objeto "node" y actualízalo si es necesario.
  1. NodeName: asegúrate de que el nombre de host sea correcto. Algunos nombres se usan en muchos lugares, como los controladores de dominio. Si cambias un nombre aquí, comprueba si es necesario cambiarlo en otro lugar de la configuración.
  2. IPv4Addr: debe ser la dirección IP del host. Normalmente, el último octeto no se debe cambiar. Es posible que algunos se hayan actualizado durante la búsqueda y sustitución de la red que se ha realizado en pasos anteriores.
  3. HyperVHost: este valor debe ser la dirección IP del servidor Hyper-V que aloja esta máquina virtual. Puedes obtener la dirección IP de cada servidor BM?? en la sección "Servidores Hyper-V" de la configuración. No cambies la asignación del host de Hyper-V en este campo, ya que no todos los hosts de Hyper-V pueden admitir todos los tipos de VM. Solo tienes que cambiar el nombre de host de Hyper-V por su dirección IP correspondiente.
20. Valida los detalles de la segunda interfaz de red en todos los nodos con Role=jumphost. Usa los detalles de la subred OCCORE-JUMPHOSTS para esta interfaz. Marca las opciones siguientes:
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
21. Actualiza la estrofa específica de ADFS en el nodo donde Role=adfs.
  
  Advertencia: NO edite ninguna parte de la configuración de ADFS, a menos que se le indique. Durante una actualización, se mantiene la configuración de ADFS.
  1. Busca la línea Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust"
  2. Sustituye las tres instancias de opscenter.local que aparecen después de esta línea por tu dominio DNS.
22. Actualiza los ámbitos de DHCP para que coincidan con el plan de IP del cliente según sea necesario. En cada ámbito, comprueba que los siguientes valores sean correctos. Los nombres de los ámbitos coinciden con los nombres utilizados en el plan de red ocinfo.common.opscenter.local.txt, por lo que debe usar lo siguiente en la validación:
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
23. Confirma que los valores coinciden con los valores de la copia de seguridad config1.ps1.
24. Asegúrate de guardar el archivo.

Preparación de la VM CONFIG1

La preparación de CONFIG1 se lleva a cabo en BM01. El resto de las actualizaciones se realizan mientras se ha iniciado sesión en la máquina virtual CONFIG1.

Copia el directorio operations_center en la VM CONFIG1.
1. En el host BM01, abre una consola de PS como Administrador.
2. Copia operations_center para organizar los archivos que necesita la máquina virtual CONFIG1.
  
  Nota: Copy-ConfigHostFiles.ps1 no se usa aquí porque el entorno está operativo. La copia SMB ahorra horas de tiempo de copia.
```
# Change name to match your config host
$config = "DC1-CONFIG1"
# Stage files for CONFIG1 VM
Copy-Item  -Path H:\operations_center -Destination "\\$config\c$\" -Recurse -Force
```
3. Inhabilitar la sincronización de hora de Hyper-V
  1. Inicia sesión en el host BM01 como administrador.
  2. Abre PowerShell en Windows como administrador y ejecuta el siguiente comando:
  Importante: En el siguiente fragmento de código, sustituya <var>config1_vm_name</var> por el nombre de la VM CONFIG1. Por ejemplo, DC1-CONFIG1.
```
# Disabling Hyper-V Time Sync
Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
```
4. Preparación y validación de la máquina virtual CONFIG1
  1. En el host BM01, inicia sesión en la VM CONFIG1 con tu cuenta -SA. Conéctate a la dirección IP de la VM mediante Escritorio Remoto (RDP). Ejemplo: mstsc /v 192.168.100.99
  2. Abre una ventana de PowerShell con el menú "Ejecutar como otro usuario" para ejecutarla como usuario de Marvin.
  3. En la nueva ventana de PowerShell, inicia una sesión administrativa:
```
Start -Verb runas -FilePath powershell.exe
```
    Cierra la ventana anterior de PowerShell y deja abierta la ventana de administrador.
  4. Comprueba que la ventana administrativa de PowerShell se está ejecutando como Marvin.
```
whoami
```
  5. Coloca los archivos que se hayan almacenado provisionalmente desde el host BM01.
```
Move-Item -Path c:\operations_center -Destination c:\release
C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
```
  6. Valida que c:\dsc y c:\config existan.
  7. Copiar archivos de credenciales y certificados de la copia de seguridad
```
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. Compilar los datos de MECM necesarios para compilar los MOFs
```
C:\dsc\Build-MecmFiles.ps1
```
  9. Valida que el entorno de compilación esté listo ejecutando Build-Mof.ps1, que genera archivos MOF para todos los equipos de OI.
```
C:\dsc\Build-Mof.ps1
```
5. Rellenar variables de credenciales
  
  Estas variables se usan a lo largo del proceso de actualización. Rellénalos una vez en la ventana de Marvin Powershell que se ha abierto 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
}
```
6. Verifica que DSC se esté ejecutando y que se pueda acceder a los servidores.
```
$role = 'domain_controller'
$ca = 'ca_root'
$dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
$non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}

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

$non_dcs | ForEach-Object {
Write-Output "Checking $($_.NodeName)"
$session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}
```
  Nota: Es posible que algunos nodos muestren el estado Failure o devuelvan un error The Consistency Check or Pull cmdlet is in progress. No hay ningún problema siempre que se pueda acceder al nodo.

Soluciona problemas de conectividad.

Si New-CimSession falla, comprueba que el valor de NodeName sea correcto en config.ps1. También debes confirmar que el servidor esté online y accesible.

El error empezará por Get-CimSession: WinRM cannot process the request.

Actualizar controladores de dominio

Mientras tienes la sesión iniciada en CONFIG1, actualiza el controlador de dominio principal.

Rellena las variables, elimina los objetos de directiva de grupo antiguos y vincula los nuevos.
```
$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
}
```
Desvincula los objetos de directiva de grupo. Se vincularán al final de la actualización.
```
$gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'Yes'", "LinkEnabled: 'No'")
$gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
```
Actualiza el controlador de dominio principal.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
```
Nota: Los errores Copy-Item : An item with the specified name already exists. son habituales durante Installing PowerShell modules on host y se pueden ignorar en las actualizaciones de nodos.
Advertencia: Se ha detectado un problema que afecta a la copia de archivos en los controladores de dominio debido a las restricciones de longitud de la ruta. Si se produce un error durante Update-RemoteHost, como a file that already exists on the target destination durante Copying files for the ... role to host, ejecuta estos comandos. De lo contrario, continúa con el siguiente paso.
```
New-PSDrive -Name DC1 -PsProvider FileSystem -Root "\\$($DC1.NodeName)\c$" -Credential $da_creds
Invoke-Command -ComputerName $DC1.NodeName -Credential $da_creds -Scriptblock {Remove-DscConfigurationDocument -Stage Current,Pending}
Remove-Item -Path DC1:\config\domain_controller\site_gpos -Recurse -Force
Remove-Item -Path DC1:\config\domain_controller\site_gpos_source -Recurse -Force
Copy-Item -Path C:\config\domain_controller\ -Destination DC1:\config\ -Verbose -Force -Recurse
C:\dsc\Build-Mof.ps1 -Computername $DC1.NodeName
Start-DscConfiguration -ComputerName $DC1.NodeName -Path 'c:\config\mofs' -Credential $da_creds -Verbose -Wait -Force
Remove-PsDrive -Name DC1
```
1. Validar la sincronización de la hora con SyncServer
2. Inicia sesión en DC1 mediante RDP como administrador de dominio.
  1. Abre una ventana de Powershell como administrador.
  2. Ejecuta el siguiente comando para validar la configuración de la hora.
```
w32tm /query /status /verbose
```
Importante: Asegúrate de que Last Sync Error: sea 0 y que Source coincida con una de las direcciones IP NtpServers configuradas en las instrucciones para actualizar los servidores NTP.
1. Ejecuta los siguientes comandos para probar la resincronización de la hora:
```
 # Testing time resyncronization
 w32tm /resync
```
```
 # Desired output
 Sending resync command to local computer
 The command completed successfully.
```
2. Vuelve a comprobar que la configuración de la hora sea correcta y no contenga errores.
  
  Importante: Asegúrate de que Last Sync Error: esté 0 y que Time to Last Good Sync Time: se haya actualizado (debería tardar menos de un minuto si lo has ejecutado inmediatamente después de la sincronización, por ejemplo).
```
 w32tm /query /status /verbose
```
  Advertencia: Si se detectan errores o w32tm /resync falla, DETÉN el proceso. Deriva el caso al equipo de ingeniería de OI antes de continuar, ya que hay un alto riesgo de bloquear la implementación de OI a menos que los servicios de tiempo funcionen correctamente.
Actualiza el segundo controlador de dominio.
1. Usa la ventana de PowerShell CONFIG1 que ya tienes abierta para ejecutar la siguiente secuencia de comandos.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
```

Valida la replicación de Active Directory.

Una vez que el segundo controlador de dominio esté activo y operativo, ejecuta los siguientes comandos desde uno de los controladores de dominio para validar la replicación de Active Directory:

repadmin /replsummary

La salida debe ser similar a la siguiente:

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

Actualizar CA-ISSUING1 y CA-WEB

Usa el terminal de PowerShell que ya tienes en CONFIG1 para actualizar CA-ISSUING1.

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

Usa el terminal de PowerShell que ya tienes en CONFIG1 para actualizar CA-WEB.

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

Validar la actualización

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

Actualizar CA-ROOT1

Usa el terminal de PowerShell que ya tienes en CONFIG1

Enciende 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

Actualiza CA-ROOT1.
```
  $caroot_cred = Get-GeccoCredential -Name "$($ca_root.NodeName)\caadmin" -CredStore "c:\config\creds"
  c:\dsc\Update-RemoteHost.ps1 -Computername $ca_root.NodeName -RemoteHost $ca_root.Ipv4Addr -Credential $caroot_cred
```
Nota: Si se produce un error de autenticación, inicia sesión en el servidor CA-ROOT1 como caadmin. Abre PowerShell como administrador. Escribe winrm qc y pulsa Intro. Acepta los cambios con y. Cierra la sesión de CA-ROOT1 y vuelve a intentarlo.
Si CA_ROOT1 no se ha reiniciado después de ejecutar la secuencia de comandos anterior, reinícialo manualmente.
Valida la actualización.
```
  $ca_root | ForEach-Object {
  $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
  Get-DscConfigurationStatus -CimSession $session}
```
Importante: Usa w32tm para verificar que la VM se está sincronizando con el host <SITE>-DC1. Ejecuta este comando en un shell administrativo como administrador local en CA-ROOT.

Comprueba que el ajuste Peer esté <SITE>-DC1.<DNSDOMAIN> y que State sea Active.

No continúes si la hora no se ha sincronizado correctamente.

  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)

Apaga la CA-Root.

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

Actualizar ADFS

Usa el terminal de PowerShell que ya tienes en CONFIG1

Actualiza la máquina virtual de 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}

Actualiza Jumphosts.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz de Jumphosts.

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

Actualiza los jumphosts.

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

Valida la actualización.

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

Actualiza Fileservers.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz que contenga los servidores de archivos.

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

Actualiza los servidores de archivos.

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

Valida la actualización.

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

Actualiza los servidores DHCP.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Actualiza DHCP1.

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

Valida la actualización.

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

Actualiza DHCP2.

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

Valida la actualización.

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

Actualiza los servidores de Userlock.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz de PowerShell que contenga los servidores de Userlock.

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

Elimina los archivos de marcador de la configuración 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" }

Actualiza el servidor Userlock principal.

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

Actualiza el servidor de copia de seguridad de UserLock.

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

Valida las actualizaciones.

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

Actualiza los servidores de Nessus.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz de PowerShell que contenga los servidores de Nessus.

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

Actualiza los servidores de Nessus.

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

Valida la actualización.

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

Actualiza los servidores Hyper-V.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz de PowerShell que contenga los servidores de Hyper-V.

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

Actualiza los servidores Hyper-V.
```
  $hyper | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
```
Advertencia: Si se reinicia BM01, se reiniciará CONFIG1. Cuando esté disponible, inicia sesión, abre PowerShell como Marvin y eleva los privilegios. A continuación, ejecuta el paso Config1 prep 1.e. para volver a cargar las variables. Vuelve a iniciar la actualización de Hyper-V.

Valida la actualización.

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

Actualizar Herramientas

Usa el terminal de PowerShell que ya tienes en CONFIG1

Crea una matriz de PowerShell que contenga los servidores de Toolbox.

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

Crear una unidad adicional en el 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
     }}}

Comprueba que en el resultado se muestren dos discos asignados a la VM. Ejemplo:

  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

Actualiza los servidores de Toolbox.

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

Valida la actualización.

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

Usa la terminal de PowerShell que ya tengas en `CONFIG1` para validar la actualización.

Verifica que DSC se esté ejecutando sin errores.

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

Actualizar las VMs de Splunk

En la ventana de PowerShell de CONFIG1, configura y ejecuta la configuración de DSC:

Introduce el código de sitio. Ejemplo: "DC1"

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

Configura el reenviador pesado:

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

Configura el indexador 1:

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

Configura el indexador 2:

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

Configura el indexador 3:

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

Configura el gestor:

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

Configura el buscador:

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

En la ventana de PowerShell de CONFIG1, haz lo siguiente:

  $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

Sigue SIEM-G0006 para definir la Pass4SymmKey global y SIEM-G0007 para adjuntar cada zona a Splunk en OIC.

Actualizar el host CONFIG1

En la ventana de PowerShell de CONFIG1, haz lo siguiente:

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

Si el ordenador se reinicia, vuelve a iniciar sesión y vuelve a iniciar PowerShell como Marvin. Después, obtén privilegios de administrador. Rellene las variables necesarias para las secciones siguientes.
```
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 MCM no es un componente actualizable, la única opción es eliminar los hosts de MCM y volver a implementarlo.

Asegúrese de que el software de MCM actual se ha hidratado siguiendo las instrucciones del IT-T0023.
El procedimiento para volver a desplegar se describe en IT-R0019.

Eliminar puntos de control de una máquina virtual

Una vez que se hayan completado las actualizaciones, se deben eliminar los puntos de control. Los puntos de control pueden provocar un uso excesivo del disco con el tiempo. Solo debes conservarlos si es necesario restaurar un punto de control debido a un error en la actualización.

Usa el terminal de PowerShell que ya tienes en CONFIG1

Elimina los puntos de control de la máquina virtual.

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

Volver a habilitar los objetos de directiva de grupo en el dominio

Usa el terminal de PowerShell que ya tienes en CONFIG1

Cambiar la configuración del rol de controlador de dominio para habilitar los enlaces en los GPOs gestionados

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

Actualiza el controlador de dominio con el rol ObjectOwner:

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

Contactar con el equipo de Google

Consulta la página Solicitar asistencia para saber cómo ponerte en contacto con Google y obtener más ayuda.

Realizar una actualización en un despliegue multizona Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Preparar

Generar un informe de cumplimiento

Gestión de Identidades y Accesos

Pausar las actualizaciones de recursos globales en todas las zonas

Actualizar la organización raíz global

Comprobación previa a la actualización

1. Descarga y copia el paquete de actualización

2. Configurar la actualización del registro de artefactos

Enviar los artefactos al registro de contenedores

3. Actualizar la organización raíz

3.1. Antes de la actualización

3.2. Realizar actualizaciones automáticas de la organización raíz

3.3. Comprobaciones posteriores a la actualización

Finalizar la actualización de la organización raíz en todas las zonas

4. Actualizar recursos globales

5. Actualizaciones de componentes entre zonas

6. Actualización manual de la subred Anycast

7. Actualización manual de SyncServer

7.1. Proceso de actualización de SyncServer

Actualizar una organización de cliente global

Comprobación previa a la actualización

1. Actualizar una organización de cliente

1.1. Preparación

IaC

kubectl

1.2. Iniciar la actualización

1.3. Actualizar

1.4. Comprobaciones posteriores a la actualización

1.5. Iniciar una actualización no programada

2. Actualización de DNS

2.1 Crear zonas de reenvío

2.2 Habilita el resolvedor recursivo

Finalizar la actualización de la organización de inquilinos en todas las zonas

3. Actualizar recursos globales

4. Actualizar Tenable SC

Limpieza posterior a la actualización

Configurar ventanas de mantenimiento para la actualización de la organización de inquilino

Consola

kubectl

Actualización manual de la infraestructura principal de Operations Suite

Realizar puntos de control de máquinas virtuales y copias de seguridad de directorios

Cargar software de terceros

Actualizar máquinas virtuales

Preparación de la VM CONFIG1

Soluciona problemas de conectividad.

Actualizar controladores de dominio

Actualizar CA-ISSUING1 y CA-WEB

Actualizar CA-ROOT1

Actualizar ADFS

Actualiza Jumphosts.

Actualiza Fileservers.

Actualiza los servidores DHCP.

Actualiza los servidores de Userlock.

Actualiza los servidores de Nessus.

Actualiza los servidores Hyper-V.

Actualizar Herramientas

Usa la terminal de PowerShell que ya tengas en CONFIG1 para validar la actualización.

Actualizar las VMs de Splunk

Actualizar el host CONFIG1

Microsoft Configuration Manager (MCM)

Eliminar puntos de control de una máquina virtual

Volver a habilitar los objetos de directiva de grupo en el dominio

Contactar con el equipo de Google

Realizar una actualización en un despliegue multizona

Usa la terminal de PowerShell que ya tengas en `CONFIG1` para validar la actualización.