Actualizar las implementaciones de Omnissa Access Control Plane

En este tema se describe el procedimiento recomendado para actualizar una implementación existente de Omnissa Access basada en Omnissa Access Control Plane. Abarca la actualización de los paquetes del sistema operativo, el paquete de activos del plano de control, los servicios de Access y la máquina virtual de arranque.

Importante: Estas instrucciones de actualización no son aplicables a la actualización de las versiones 2412 o anteriores.

Requisitos

• Ejecute todos los comandos desde la máquina virtual de arranque, salvo que se indique lo contrario.
• La implementación existente debe estar en buen estado. Ejecute wso healthcheck y wso access check-service-readiness para confirmar el estado del sistema antes de comenzar.
• El paquete de activos sin conexión para la versión de destino debe estar descargado y disponible en la máquina virtual de arranque.
• El RPM de seguridad del sistema operativo debe estar descargado y disponible en la máquina virtual de arranque, si esta actualización incluye actualizaciones de paquetes del sistema operativo.

Flujo de trabajo de actualización

Una actualización consta de las siguientes fases:

1. Fase 1: Configurar el repositorio local para las actualizaciones del sistema operativo (solo cuando se requieran actualizaciones de paquetes del sistema operativo).
2. Fase 2: Descargar y configurar el nuevo paquete de activos del plano de control.
3. Fase 3: Actualizar el plano de control, incluyendo opcionalmente las actualizaciones de paquetes del sistema operativo.
4. Fase 4: Actualizar los servicios de Access y validar el estado de los servicios.
5. Fase 5: Si se ha aplicado la fase 1, actualizar el sistema operativo de la máquina virtual de arranque.

Fase 1: Configurar el repositorio local para las actualizaciones del sistema operativo

Notas:

• Si esta actualización no incluye actualizaciones de los paquetes del sistema operativo, pase a la Fase 2: Configurar el nuevo paquete de activos.

• Si va a implementar su propio AlmaLinux 9.6, la Fase 1 no es aplicable. Pase a la Fase 2: Configurar el nuevo paquete de activos.

Procedimiento:

1. Ejecute el script de actualización del repositorio de DNF en la máquina virtual de arranque:

   sh /usr/local/sbin/update-dnf-repo.sh /root/security-rpms.tar.gz
   

2. Establezca las siguientes variables en el shell para usarlas en el resto de los pasos:

   export WORKDIR="/root/<cluster_name>"
   export BOOTSTRAP_IP="<bootstrap-node-ip>"
   export TARGETS="general_compute_linux:general_compute_access_linux"
   export ASSET_DIR="${WORKDIR}/assets-<version>"
   

3. Habilite el repositorio local en la máquina virtual de arranque y prepare su certificado de CA para distribuirlo a los nodos del clúster:

   sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/localrepo.repo
   mkdir -p ${WORKDIR}/access/localrepo_ca_path
   cp -f /etc/nginx/localrepo-certs/root-ca.crt \
     ${WORKDIR}/access/localrepo_ca_path/root-ca.crt
   

4. Envíe la configuración del repositorio local a los nodos del clúster:

   1. Cree el directorio de certificados en los nodos del clúster:

      wso control-plane ansible -- -b -m file \
        -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \
        "${TARGETS}"
      

   2. Copie el certificado de CA raíz en los nodos del clúster:

      wso control-plane ansible -- -b -m copy \
        -a "src=/workdir/access/localrepo_ca_path/root-ca.crt dest=/etc/nginx/localrepo-certs/root-ca.crt owner=root group=root mode=0644 force=yes" \
        "${TARGETS}"
      

   3. Configure los nodos del clúster para que apunten al repositorio HTTPS de arranque:

      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=baseurl value=https://${BOOTSTRAP_IP}/" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslverify value=1" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslcacert value=/etc/nginx/localrepo-certs/root-ca.crt" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=enabled value=1" \
        "${TARGETS}"
      

   4. Recompile la memoria caché de DNF en los nodos del clúster solo desde el repositorio local. Este paso debe repetirse si está aplicando varias actualizaciones sobre la versión publicada.

      wso control-plane ansible -- -b -m shell \
        -a "dnf clean all && rm -rf /var/cache/dnf/* && dnf --refresh makecache --disablerepo='*' --enablerepo=localrepo && dnf --refresh --disablerepo='*' --enablerepo=localrepo list available" \
        "${TARGETS}"
      

Fase 2: Configurar el nuevo paquete de activos

Procedimiento:

1. Cree un directorio para el nuevo paquete de activos y descárguelo:

   mkdir -p ${ASSET_DIR}
   cd ${ASSET_DIR}
   # Copy the target release asset bundle to this location ${ASSET_DIR}
   

   Importante: Descargue el paquete de activos correspondiente a su versión de destino. No reutilice un paquete de una versión anterior.

2. Extraiga el paquete y agregue la CLI a la ruta:

   # Ensure that you are in ${ASSET_DIR} before you unzip the asset bundle
   unzip asset-bundle.zip
   cp cli-distribution/linux/wso /usr/bin/
   cp: overwrite '/usr/bin/wso'? y # It will prompt for overwrite
   wso eula
   Do you agree to these terms ? [y/n]: y
   

3. Configure la CLI para que use el nuevo paquete:

   cd ${WORKDIR}
   wso configure ${ASSET_DIR}
   

Fase 3: Actualizar el plano de control

Procedimiento:

1. Implemente el plano de control con el nuevo paquete de activos. Incluya -u si esta actualización también actualizará los paquetes del sistema operativo en los nodos del clúster:

   #  To update without OS packages update
   nohup wso cp deploy &
   # To update with OS packages update
   nohup wso cp deploy  -u &
   

2. Verifique la implementación:

   wso version
   wso healthcheck
   

3. Si implementó con -u, desbloquee el clúster:

   Nota: Puede omitir este paso si implementó sin -u

   wso cp unseal
   

Fase 4: Actualizar los servicios de Access

Procedimiento:

1. Sincronice la configuración de Access para la actualización:

   wso access update-config set
   

2. Si existe un directorio services en el directorio de trabajo procedente de una sustitución manual anterior, muévalo para que la implementación utilice las imágenes del nuevo paquete:

   mv ${WORKDIR}/services to ${WORKDIR}/services.bk
   

3. Implemente todos los servicios de Access:

   nohup wso services deploy --type full &
   

4. Compruebe el estado de los servicios:

   wso access check-service-readiness
   

5. Una vez que todos los servicios indiquen que funcionan correctamente, salga del modo de actualización:

   wso access update-config reset
   

6. Elimine los activos de la versión anterior:

   wso cp reset-assets
   

Fase 5: Actualizar el sistema operativo de la máquina virtual de arranque

Realice esta fase únicamente una vez que la actualización del clúster se haya completado correctamente. Esta fase no requiere ningún tiempo de inactividad del clúster. Podrá realizar las operaciones del clúster una vez que haya completado la fase 4.

Para esta fase, elija entre realizar una actualización local o sustituir la máquina virtual.

Actualización local

1. Actualice los paquetes y reinicie la máquina virtual de arranque:

   dnf update -y
   reboot
   

2. Una vez que la máquina virtual de arranque vuelva a estar operativa, compruebe el clúster:

   wso healthcheck
   wso access check-service-readiness
   

Reemplazar la máquina virtual

Utilice esta opción cuando desee implementar una nueva máquina virtual de arranque a partir del último archivo OVA de Omnissa, en lugar de aplicar parches a la máquina virtual de arranque existente. Se recomienda este método para actualizaciones importantes del sistema operativo.

Paso 1: Crear un paquete de migración desde la máquina virtual de arranque existente

cd /root/<cluster_name>

tar czpvf /root/<cluster_name>-migration-$(date +%Y%m%d).tar.gz \
  profile.yml \
  logging \
  telegraf_plugin \
  ansible_extra_vars.yml \
  access \
  cp-cluster \
  additional_env_vars.env \
  deploy_services.log \
  deployment-config.yml

Paso 2: Copiar el paquete de migración en la nueva máquina virtual de arranque

scp /root/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/

Paso 3: Restaurar la configuración en la nueva máquina virtual de arranque

mkdir -p /root/<cluster_name>
cd /root/<cluster_name>

tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz

La nueva máquina virtual de arranque ahora contiene la misma configuración de implementación que la máquina virtual de arranque anterior.

Paso 4: Configurar el paquete de activos

Copie el paquete de activos utilizado con la máquina virtual de arranque existente en la nueva máquina virtual de arranque y, a continuación, ejecute los pasos que se indican a continuación.

mkdir -p assets
cd assets
# COPY asset bundle at this path.
unzip asset-bundle.zip
cp cli-distribution/linux/wso /usr/bin/
wso eula
wso configure /root/<cluster_name>/assets/
cd ..

Paso 5: Validar la nueva máquina virtual de arranque

wso version
wso healthcheck
wso access check-service-readiness

Compruebe que la versión de la CLI, la versión de la imagen del plano de control, la versión de la imagen del CPS, el estado del clúster y la disponibilidad de los servicios de Access sean correctos. Todos los servicios de Access deben tener el estado READY.