Actualización del entorno de ejecución del clúster desde la CLI de Azure

Artículo
03/06/2024

En esta guía se explican los pasos necesarios para instalar la CLI de Azure necesaria, así como las extensiones necesarias para interactuar con Operator Nexus.

Requisitos previos

Se debe instalar la CLI de Azure.
Se requiere la extensión de la CLI networkcloud. Si la extensión networkcloud no está instalada, se puede instalar siguiendo los pasos que se indican aquí.
Acceso a Azure Portal para el clúster de destino que se va a actualizar.
Debe iniciar sesión en la misma suscripción que el clúster de destino a través de az login.
El clúster de destino debe estar en estado en ejecución, todos los nodos del plano de control deben funcionar a la perfección y más del 80 % de los nodos de proceso deben estar en buen estado y en funcionamiento.

Búsqueda de las versiones en tiempo de ejecución disponibles

A través de Azure Portal

Para buscar las versiones del runtime que se puedan actualizar disponibles, vaya al clúster de destino en Azure Portal. En el panel de información general del clúster, vaya a la pestaña Versiones de actualización disponibles.

En ella podemos ver las distintas versiones del clúster que están disponibles actualmente para actualizar. El operador puede seleccionar en la lista las versiones del runtime de destino. Una vez seleccionadas, realice la actualización del clúster.

Con Azure CLI

Las actualizaciones disponibles se pueden recuperar mediante la CLI de Azure:

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

En la salida, puede encontrar la propiedad availableUpgradeVersions y examinar el campo targetClusterVersion:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Si no hay actualizaciones del clúster disponibles, la lista estará vacía.

Actualización del runtime del clúster mediante la CLI

Para realizar una actualización del runtime, use el siguiente comando de la CLI de Azure:

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

La actualización del runtime es un proceso largo. En primer lugar, se actualizan los nodos de administración y, después, se actualizan secuencialmente los nodos de trabajo, bastidor a bastidor. La actualización se considera finalizada cuando el 80 % de los nodos de trabajo por bastidor y el 100 % de los nodos de administración se han actualizado correctamente. Es posible que las cargas de trabajo se vean afectadas si los nodos de trabajo de un bastidor están en proceso de actualización; sin embargo, las cargas de trabajo de los restantes bastidores no se verán afectadas. Se recomienda tener en cuenta la colocación de cargas de trabajo a la luz de este diseño de implementación.

La actualización de todos los nodos tarda varias horas, pero puede tardar aún más si otros procesos, como las actualizaciones de firmware, también forman parte de la operación. Dada la duración del proceso de actualización, se recomienda comprobar periódicamente el estado de detalle del clúster para conocer el estado actual de la actualización. Para comprobar el estado de la actualización, observe el estado detallado del clúster. Esta comprobación se puede realizar desde Azure Portal o desde la CLI de Azure.

Para ver el estado de actualización desde Azure Portal, vaya al recurso de clúster de destino. En la pantalla Información general del clúster, se proporciona el estado detallado, junto con un mensaje de estado detallado.

La actualización del clúster está en curso cuando detailedStatus está establecido en Updating y detailedStatusMessage muestra el progreso de la actualización. Algunos ejemplos de progreso de actualización, que se muestran en detailedStatusMessage, son Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

La actualización del clúster se completa cuando detailedStatus se establece en Running y detailedStatusMessage muestra el mensaje Cluster is up and running.

Para ver el estado de actualización a través de la CLI de Azure, use az networkcloud cluster show.

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

La salida debe ser la información del clúster de destino y también deben estar presentes tanto el estado detallado del clúster como el mensaje de estado detallado. Para obtener información más detallada sobre el progreso de la actualización, se puede consultar el estado del BMM individual en cada bastidor. Encontrará un ejemplo en la sección de referencia de en Roles de máquina BareMetal.

Configuración de los parámetros del umbral de proceso para la actualización en tiempo de ejecución mediante los valores de updateStrategy del clúster

El siguiente comando de la CLI de Azure se usa para configurar los parámetros del umbral de proceso para que se realice una actualización del runtime:

az networkcloud cluster update --name "<clusterName>" --resource-group "<resourceGroup>" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> wait-time-minutes=<waitTimeBetweenRacks>

Argumentos necesarios:

strategy-type: define la estrategia de actualización. En este caso, "Rack" significa que las actualizaciones se producen bastidor a bastidor. El valor predeterminado es "Rack".
threshold-type: determina cómo se debe evaluar el umbral, aplicado en las unidades definidas por la estrategia. El valor predeterminado es "PercentSuccess".
threshold-value: valor numérico de umbral que se usa para evaluar una actualización. El valor predeterminado es 80.

Argumentos opcionales:

max-unavailable: el número máximo de nodos de trabajo que pueden estar a la vez sin conexión, es decir, el bastidor actualizado. El valor predeterminado es 32767.
wait-time-minutes: retraso o período de espera antes de actualizar un bastidor. El valor predeterminado es 15.

A continuación encontrará un ejemplo de uso del comando:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Si la ejecución del comando ha sido satisfactoria, los valores de updateStrategy especificados se aplicarán al clúster:

  "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    },

Preguntas más frecuentes

Identificación de que la actualización del clúster está detenida o bloqueada

Durante una actualización del runtime, se puede dar el caso de que no avance, pero que el estado detallado refleje que la actualización sigue en curso. Dado que la actualización del runtime puede tardar mucho tiempo en finalizar, actualmente no hay ningún tiempo de espera establecido. Por consiguiente, también es aconsejable comprobar periódicamente tanto los registros como el estado de detalle del clúster para determinar si la actualización está intentando actualizar indefinidamente.

Podemos identificar si es así, es preciso examinar los registros del clúster, el mensaje detallado y el mensaje de estado detallado. Si se ha producido un tiempo de espera, observaríamos que el clúster se está reconciliando sobre lo mismo indefinidamente y, por tanto, no avanza. En ese momento, se recomienda comprobar los registros de clúster o la configuración para ver si hay algún error o si una actualización concreta impide el progreso de la operación.

Si el error es de hardware, no es preciso volver a ejecutar la actualización

Aunque se haya ha producido un error de hardware durante una actualización, la actualización del runtime continúa, siempre que se cumplan los umbrales establecidos para los nodos de proceso y de administración o control. Una vez que la máquina se corrige o se reemplaza, se aprovisiona con el sistema operativo del runtime de la plataforma actual, que contiene la versión de destino del runtime.

Si se produce un error de hardware y no se puede realizar la actualización del runtime porque no se cumplen los umbrales de los nodos de proceso y control, es posible que haya que volver a ejecutar la actualización del runtime, depende de cuándo se haya producido el error y del estado de los servidores individuales en un bastidor. Si un bastidor se actualizó antes de un error, se usaría la versión del runtime actualizada cuando se vuelvan a aprovisionar los nodos. Si la especificación del bastidor no se ha actualizado a la nueva versión del runtime antes del error de hardware, la máquina se aprovisionaría con la versión anterior del runtime. Para realizar la actualización a la nueva versión del runtime, envíe una nueva solicitud de actualización del clúster y solo se actualizarán los nodos con la versión anterior del runtime. Los hosts que se funcionaban correctamente en la acción de actualización anterior no lo harán ahora.

Después de una actualización del runtime, el clúster muestra el estado de aprovisionamiento "Con errores"

Durante una actualización del runtime, el clúster entrará en un estado de Upgrading. En caso de error en la actualización en tiempo de ejecución, por motivos relacionados con los recursos, el clúster pasará a un Failed estado de aprovisionamiento. Este estado podría estar vinculado al ciclo de vida de los componentes relacionados con el clúster (por ejemplo, StorageAppliance) y puede que sea necesario para diagnosticar el error con el soporte técnico de Microsoft.

Share via