Documentación de Oracle Cloud Infrastructure

Aplicación de parches y actualización manuales de un sistema Exadata Cloud Infrastructure

En este tema se describen los procedimientos para la aplicación de parches y la actualización de diversos componentes en Exadata Cloud Service al margen de la automatización en la nube.

Para obtener información relacionada con la aplicación de parches y la actualización con dbaascli, consulte "Aplicación de parches en Oracle Database y Oracle Grid Infrastructure mediante dbaascli".

Nota

Para obtener más información sobre cómo lograr un servicio continuo durante las operaciones de aplicación de parches, consulte el documento técnico Application Checklist for Continuous Service for MAA Solutions.

Temas relacionados

Tema principal: Aplicación de parches y actualización de un sistema Exadata Cloud Infrastructure

Aplicación manual de parches en el software de Oracle Database y Oracle Grid Infrastructure

En el horario de verano y en el caso de los parches rutinarios o puntuales, puede que sea necesario aplicar parches en el software de forma manual.

Para aplicar parches rutinarios del software de Oracle Database y Oracle Grid Infrastructure, Oracle recomienda utilizar las funciones que proporciona Oracle Exadata Database Service on Dedicated Infrastructure. Sin embargo, en algunas circunstancias, puede que sea necesario aplicar los parches en el software de Oracle Database o Oracle Grid Infrastructure de forma manual:
  • Aplicación de parches del horario de verano (DST): como no se pueden aplicar de manera sucesiva, los parches de las definiciones del DST de Oracle Database no están incluidos en los juegos de parches rutinarios de Exadata Cloud Infrastructure. Si necesita aplicar parches en las definiciones del DST de Oracle Database, deberá hacerlo manualmente. Consulte My Oracle Support (ID de documento 412160.1).
  • Parches no rutinarios o puntuales: si experimenta un problema que requiere un parche que no está incluido en ningún juego de parches rutinarios, trabaje con los Servicios de Soporte Oracle para identificar y aplicar el parche adecuado.

Para obtener información general sobre la aplicación de parches en Oracle Database, consulte la información relativa a su versión sobre las actualizaciones y los requisitos de los juegos de parches en la Guía de cambio de versión de Oracle Database.

Actualización manual del sistema operativo del cluster de VM en la nube de Exadata

Puede actualizar los sistemas operativos de los nodos de cálculo de Exadata mediante la herramienta patchmgr.

Esta utilidad gestiona la actualización completa de uno o más nodos de cálculo de forma remota, incluida la ejecución de los pasos de prereinicio, reinicio y postreinicio. Puede ejecutar la herramienta desde un nodo de cálculo de Exadata o un servidor que no sea de Exadata que ejecute Oracle Linux. El servidor en el que ejecuta la utilidad se denomina "sistema de control". No se puede usar el sistema de control para actualizarse a sí mismo. Por lo tanto, si el sistema de control es uno de los nodos de cálculo de Exadata de un sistema que va a actualizar, debe ejecutar una operación independiente en un sistema de control diferente para actualizar ese servidor.

En los dos escenarios siguientes se describen los modos habituales de realizar las actualizaciones:

Escenario 1: sistema de control no de Exadata

La forma más sencilla de ejecutar la actualización del sistema de Exadata es utilizar un servidor Oracle Linux independiente para actualizar todos los nodos de cálculo de Exadata del sistema.

Escenario 2: sistema de control de nodos de Exadata

Puede utilizar un nodo de cálculo de Exadata para controlar las actualizaciones de los nodos de cálculo restantes del sistema y, a continuación, utilizar uno de los nodos actualizados para controlar la actualización en el nodo de controlador de Exadata original.

Por ejemplo: si actualiza un sistema de Exadata de medio rack que tiene cuatro nodos de cálculo: node1, node2, node3 y node4. En primer lugar, utilice node1 para controlar las actualizaciones de node2, node3 y node4. A continuación, utilice node2 para controlar la actualización de node1.

El sistema de control requiere que el usuario root tenga acceso SSH a cada nodos de cálculo que actualizará la herramienta.

Tema principal: Aplicación de parches y actualización manuales de un sistema Exadata Cloud Infrastructure

Preparación para las actualizaciones del sistema operativo

Determine la versión de software más reciente disponible y la conectividad al repositorio yum adecuado

Atención:

No instale NetworkManager en la instancia de Exadata Cloud Infrastructure. La instalación de este paquete y el reinicio del sistema ocasionan una pérdida grave de acceso al sistema.
  • Antes de comenzar con las actualizaciones, revise Exadata Cloud Service Software Versions (ID de documento 2333222.1) para determinar la versión de software más reciente y la versión de destino que se van a utilizar.
  • Algunos pasos del proceso de actualización requieren que se especifique un repositorio de YUM. La URL del repositorio de YUM es: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    Los identificadores de región son cadenas de texto que se utilizan para identificar regiones de Oracle Cloud Infrastructure (por ejemplo, us-phoenix-1). Puede encontrar una lista completa de identificadores de región en Regiones.

    Puede ejecutar el siguiente comando curl para determinar la versión más reciente del repositorio de YUM para la región de la instancia de Exadata Cloud Service: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    Este ejemplo devuelve la versión más reciente del repositorio de YUM para la región Oeste de EE. UU. (Phoenix): 
    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
<a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • Para aplicar las actualizaciones del sistema operativo, la VCN del sistema se debe configurar para permitir el acceso al repositorio de YUM. Para obtener más información, consulte Opción 2: gateway de servicio a Object Storage y los repositorios de YUM..

Actualizar el sistema operativo en todos los nodos de cálculo de una instancia de Exadata Cloud Infrastructure

Procedimiento para actualizar todos los nodos de cálculo mediante patchmgr.

En este procedimiento de ejemplo se presupone lo siguiente:

  • El sistema tiene dos nodos de recursos informáticos, node1 y node2.
  • La versión de destino es 18.1.4.0.0.180125.3.
  • Cada uno de los dos nodos se utiliza como sistema de control para la actualización del otro.
  1. Recopile los detalles del entorno.
    1. Utilice SSH para acceder a node1 como root y ejecute el siguiente comando para determinar la versión de Exadata:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Cambie al usuario grid e identifique todos los nodos de cálculo del cluster.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Configure el sistema de control.
    1. Vuelva al usuario root en node1, compruebe si ya existe un par de claves ssh de root (id_rsay id_rsa.pub). De no ser así, genérelo.
      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory
[root@node1 .ssh]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.fraad1client.exadataclientne.oraclevcn.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. Distribuya la clave pública en los nodos de destino y verifique este paso. En este ejemplo, el único nodo de destino es node2.
      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
id_rsa.pub

[root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
[root@node2 ~]# date
Wed Feb 28 03:33:45 UTC 2018
    3. En el nodo de destino (node2 en el ejemplo), agregue la clave pública de root de node1 al archivo authorized_keys de root.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Descargue dbserver.patch.zip como p21634633_12*_Linux-x86-64.zip en el sistema de control (node1, en este ejemplo) y descomprímalo. Consulte dbnodeupdate.sh y dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr (ID de documento 1553103.1) para obtener información sobre los archivos de este .zip.
      [root@node1 patch]# mkdir /root/patch
[root@node1 patch]# cd /root/patch
[root@node1 patch]# unzip p21634633_181400_Linux-x86-64.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
   creating: dbserver_patch_5.180228.2/ibdiagtools/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
  inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
 extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
  inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
   creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
  inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
   creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
  inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
  inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
  inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
  inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
  inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
   creating: dbserver_patch_5.180228.2/linux.db.rpms/
  inflating: dbserver_patch_5.180228.2/md5sum_files.lst
  inflating: dbserver_patch_5.180228.2/patchmgr
  inflating: dbserver_patch_5.180228.2/xcp
  inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
  inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
  inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
  inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
  inflating: dbserver_patch_5.180228.2/exadata.img.env
  inflating: dbserver_patch_5.180228.2/README.txt
  inflating: dbserver_patch_5.180228.2/exadataLogger.pm
  inflating: dbserver_patch_5.180228.2/patch_bug_26678971
  inflating: dbserver_patch_5.180228.2/dcli
  inflating: dbserver_patch_5.180228.2/patchReport.py
 extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
   creating: dbserver_patch_5.180228.2/plugins/
  inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
  inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
  inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
  inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
  inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
  inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
  inflating: dbserver_patch_5.180228.2/patchmgr_functions
  inflating: dbserver_patch_5.180228.2/exadata.img.hw
  inflating: dbserver_patch_5.180228.2/libxcp.so.1
  inflating: dbserver_patch_5.180228.2/imageLogger
  inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
  inflating: dbserver_patch_5.180228.2/fwverify
    5. Cree el archivo dbs_group que contiene la lista de nodos de cálculo que se van a actualizar. Incluya los nodos enumerados después de ejecutar el comando olsnodes en el paso 1 a excepción del nodo del sistema de control. En este ejemplo, dbs_group solo debe incluir node2.
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. Ejecute una operación de comprobación previa de parches.
    Nota

    Debe ejecutar la operación de comprobación previa con la opción -nomodify_at_prereq para evitar cambios en el sistema que podrían afectar a la copia de seguridad que se realiza en el siguiente paso. De lo contrario, es posible que la copia de seguridad no pueda revertir el sistema a su estado original, en caso necesario. 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    La salida debe ser similar al siguiente ejemplo: 
    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -nomodify_at_prereq

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. Realice una copia de seguridad del sistema actual.
    Nota

    Esta es la etapa adecuada para realizar la copia de seguridad, antes de que se realicen modificaciones en el sistema. 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    La salida debe ser similar al siguiente ejemplo: 
    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. Elimine todos los RPM personalizados de los nodos de cálculo de destino que se actualizarán. Los RPM personalizados se notifican en los resultados de la comprobación previa. Se incluyen los RPM que se instalaron manualmente después de aprovisionar el sistema.
    • Si va a actualizar el sistema desde la versión 12.1.2.3.4.170111 y los resultados de la comprobación previa incluyen krb5-workstation-1.10.3-57.el6.x86_64, elimínelo. (Este elemento se considera un RPM personalizado para esta versión.)
    • No elimine exadata-sun-vm-computenode-exact ni oracle-ofed-release-guest. Estos dos RPM se gestionan automáticamente durante el proceso de actualización.
  6. Ejecute el comando nohup para realizar la actualización.
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    La salida debe ser similar al siguiente ejemplo:
    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -allow_active_network_mounts &

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************

2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. Una vez completada la operación de actualización, compruebe la versión del núcleo en el nodo de cálculo que se ha actualizado.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. Si el sistema de control es un nodo de cálculo que se tiene que actualizar (como en este ejemplo), repita los pasos del 2 al 7 de este procedimiento utilizando un nodo de cálculo actualizado como sistema de control para actualizar el nodo de cálculo restante. En este ejemplo de actualización, debe utilizar node2 para actualizar node1.
  9. En cada nodo de cálculo, ejecute el comando uptrack-install como usuario root para instalar las actualizaciones de ksplice disponibles.
    uptrack-install --all -y

Instalación de paquetes adicionales del sistema operativo

Revise estas directrices antes de instalar paquetes adicionales del sistema operativo para Oracle Exadata Database Service on Dedicated Infrastructure.

Puede instalar y actualizar los paquetes del sistema operativo en Oracle Exadata Database Service on Dedicated Infrastructure siempre que no modifique el núcleo o los paquetes específicos de InfiniBand. Sin embargo, el soporte técnico de Oracle, incluida la instalación, las pruebas, la certificación y la resolución de errores, no se aplica a ningún software que instale que no sea de Oracle.

Tenga en cuenta también que, si agrega o actualiza paquetes por separado de una actualización de software de Oracle Exadata, estas adiciones o actualizaciones de paquetes pueden generar problemas al aplicar una actualización de software de Oracle Exadata. Estos problemas se pueden producir porque los paquetes de software adicionales agregan nuevas dependencias que pueden interrumpir una actualización de Oracle Exadata. Por este motivo, Oracle recomienda minimizar la personalización.

Si instala paquetes adicionales, Oracle recomienda automatizar la eliminación y reinstalación de dichos paquetes mediante scripts. Después de una actualización de Oracle Exadata, si instala paquetes adicionales, verifique que los paquetes adicionales siguen siendo compatibles y que todavía necesita estos paquetes.

Para obtener más información, consulte la Guía de mantenimiento de Oracle Exadata Database Machine.

Actualización de herramientas en una instancia de Exadata Cloud Infrastructure

Las herramientas específicas de la nube se utilizan en las máquinas virtuales de invitado de Exadata Cloud Infrastructure para operaciones locales, incluidos los comandos dbaascli.

Oracle actualiza automáticamente las herramientas en la nube cuando hay nuevas versiones disponibles. Si es necesario, puede seguir los pasos de Actualización de las herramientas en la nube mediante dbaascli para asegurarse de tener la versión más reciente de las herramientas en la nube en todas las máquinas virtuales del cluster de VM.