Configura la verificación de estado y la reparación automática

Los grupos de instancias administrados (MIG) mantienen la alta disponibilidad de las aplicaciones, ya que mantienen las instancias de máquina virtual (VM) disponibles de forma proactiva, es decir, en el estado RUNNING. Si una instancia administrada deja de ejecutarse, pero el MIG no inició el cambio de estado, el MIG recrea esa instancia de forma automática. Por otro lado, si el MIG detiene una instancia que tenía el estado RUNNING de forma intencional (por ejemplo, cuando un escalador automático borra una instancia) el MIG no vuelve a crearla.

Dentro de los cambios del estado de la instancia que el MIG no inicia, se incluyen los siguientes:

Sin embargo, es posible que depender del estado de una instancia para determinar el estado de la aplicación no sea suficiente. Por ejemplo, una verificación para determinar si una instancia está en el estado RUNNING no detecta errores de la aplicación, como el bloqueo, la sobrecarga o fallas.

A fin de mejorar aún más la disponibilidad de tu aplicación y verificar que responda, puedes configurar una política de reparación automática para tu MIG.

Una política de reparación automática se basa en una verificación de estado de la aplicación para comprobar que una aplicación responde según lo esperado. Verificar que una aplicación responda es más preciso que verificar que una VM esté en estado RUNNING.

Si el reparador automático determina que una aplicación no responde, el MIG vuelve a crear esa VM de forma automática. En una VM interrumpible, el grupo vuelve a crear la VM cuando los recursos necesarios vuelven a estar disponibles.

Comportamiento de la reparación automática

La reparación automática recrea las VM en mal estado con la plantilla de instancia original que se usó para crear la VM (no necesariamente la plantilla de instancia actual en el MIG). Por ejemplo, si se creó una VM con instance-template-a y, luego, actualizas el MIG a fin de usar instance-template-b en modo OPPORTUNISTIC, la reparación automática aún usa instance-template-a para volver a crear la VM. Esto se debe a que a las creaciones nuevas de la reparación automática no las inicia el usuario, por lo que Compute Engine no supone que la VM tiene que usar la plantilla nueva. Si deseas aplicar una plantilla nueva, consulta Cambia la plantilla de instancia de un MIG.

En todo momento, la cantidad de VM reparadas de forma automática es menor que el tamaño del MIG. Esto garantiza que el grupo siga ejecutando un subconjunto de VM incluso si, por ejemplo, la política de reparación automática no se ajusta a la carga de trabajo, las reglas de firewall están mal configuradas o hay problemas de infraestructura o conectividad de red que identifiquen de forma errónea que una VM en buen estado está en mal estado. Sin embargo, si un MIG zonal tiene solo una VM o un MIG regional tiene solo una VM por zona, la reparación automática vuelve a crear estas VM cuando están en mal estado.

La reparación automática no vuelve a crear una VM durante el período de inicialización de esa VM. Para obtener más información, consulte la propiedad autoHealingPolicies[].initialDelaySec. La configuración retrasa la reparación automática para que no se lleve a cabo la verificación y la recreación prematura de la VM si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando el valor currentAction de la VM es VERIFYING.

Cuando vincules por primera vez una verificación de estado a un grupo de instancias administrado, pueden pasar hasta 30 minutos antes de que comience la supervisión.

Reparación automática y discos

Cuando se vuelve a crear una VM en función de su plantilla, la reparación automática maneja los distintos tipos de discos de manera diferente. Algunos parámetros de configuración de disco pueden causar una falla en la reparación automática cuando se intenta volver a crear una VM.

Tipo de disco autodelete Comportamiento durante una operación de reparación automática
Disco persistente nuevo true Se vuelve a crear el disco según lo especificado en la plantilla de la instancia. Se perderá cualquier dato escrito en ese disco cuando se vuelva a crear el disco y su VM.
Disco persistente nuevo false Se conserva el disco y se lo vuelve a conectar cuando la reparación automática vuelve a crear la VM.
Disco persistente existente true Se borra el disco antiguo. La recreación de VM falla porque Compute Engine no puede volver a conectar un disco borrado en la VM.
Disco persistente existente false Se vuelve a conectar el disco antiguo según lo especificado en la plantilla de instancias. Se conservan los datos en el disco. Sin embargo, para los discos de lectura y escritura existentes, un MIG puede tener solo una VM porque no se puede conectar un disco persistente a varias VM en modo de lectura y escritura.
Disco SSD local nuevo N/A Se vuelve a crear el disco según lo especificado en la plantilla de la instancia. Los datos en un SSD local se pierden cuando se vuelve a crear o se borra una VM.

La reparación automática no vuelve a conectar los discos que no se especificaron en la plantilla de la instancia, como los discos que conectaste a una VM de forma manual luego de que se creó la VM.

Para conservar los datos importantes escritos en un disco, toma las siguientes precauciones:

Si tus VM tienen parámetros de configuración importantes que deseas conservar, Google también recomienda que uses una imagen personalizada en tu plantilla de instancia. Una imagen personalizada contiene cualquier configuración personalizada que necesites. Cuando especificas una imagen personalizada en tu plantilla de instancia, el MIG vuelve a crear las VM con la imagen personalizada que contiene la configuración personalizada que necesitas.

Configura una verificación de estado y una política de reparación automática

Puedes establecer un máximo de una política de reparación automática por MIG.

Puedes aplicar una sola verificación de estado a un máximo de 50 MIG. Si tienes más de 50 grupos, debes crear varias verificaciones de estado.

Ejemplo de configuración de una verificación de estado

En el siguiente ejemplo, se muestra cómo usar una verificación de estado en un MIG. En este ejemplo, se crea una verificación de estado que busca una respuesta del servidor web en el puerto 80. Para que los sondeos de verificación de estado lleguen a cada servidor web, debes configurar una regla de firewall. Por último, debes aplicar la verificación de estado al MIG mediante la configuración de la política de reparación automática del grupo.

Console

  1. Crea una verificación de estado para la reparación automática, que es más conservadora que la verificación de estado del balanceo de cargas.

    Por ejemplo, crea una verificación de estado que busque una respuesta en el puerto 80 y que pueda tolerar algunas fallas antes de marcar las VM como UNHEALTHY y hacer que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si se muestra de forma correcta una vez. Se marca en mal estado si no se muestra de forma correcta 3 veces consecutivas.

    1. En Google Cloud Platform Console, ve a la página Crear una verificación de estado.

      Ir a la página Crear una verificación de estado

    2. Nombra la verificación de estado, como example-check.
    3. En Protocolo, asegúrate de que esté seleccionado HTTP.
    4. En Puerto, ingresa 80.
    5. En Intervalo de verificación, ingresa 5.
    6. En Tiempo de espera, ingresa 5.
    7. Establece un umbral de buen estado para determinar la cantidad de verificaciones de estado correctas consecutivas que se deben mostrar hasta que una VM en mal estado pase a considerarse en buen estado. Ingresa 1 para esta instancia.
    8. Establece un umbral de mal estado a fin de determinar la cantidad de verificaciones de estado incorrectas consecutivas que se deben mostrar para que una VM en buen estado pase a considerarse en mal estado. Ingresa 3 para esta instancia.
    9. Haz clic en Crear para crear una verificación de estado.
  2. Crea una regla de firewall para permitir que la verificación de estado sondee la conexión a tu app.

    Los sondeos de la verificación de estado provienen de direcciones en los rangos 130.211.0.0/2235.191.0.0/16, así que asegúrate de que las reglas de firewall de la red permitan la conexión de la verificación de estado. Para este ejemplo, nuestro MIG usa la red default y sus VM escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

    1. En Google Cloud Console, ve a la página Crear una regla de firewall.

      Ir a la página Crear una regla de firewall

    2. En Nombre, ingresa un nombre para la regla de firewall. Por ejemplo, allow-health-check.
    3. En Red, selecciona la red default.
    4. En Filtro de origen, selecciona IP ranges.
    5. En Rangos de IP de origen, ingresa 130.211.0.0/2235.191.0.0/16.
    6. En Protocolos y puertos, selecciona Protocolos y puertos especificados y luego, ingresa tcp:80.
    7. Haz clic en Crear.
  3. Aplica la verificación de estado mediante la configuración de una política de reparación automática para el MIG regional o zonal.

    1. En Google Cloud Console, ve a la página Grupos de instancias.

      Ir a la página Grupos de instancias

    2. En la columna Nombre de la lista, haz clic en el nombre del MIG en el que deseas aplicar la verificación de estado.
    3. Haz clic en Editar grupo para modificar este MIG.
    4. En Reparación automática, selecciona la verificación de estado que creaste antes.
    5. Cambia o mantén la configuración de Retraso inicial. Esta configuración retrasa la reparación automática para que no se lleve a cabo una potencial recreación prematura de la VM si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando el valor currentAction de la VM es VERIFYING.
    6. Haz clic en Guardar para aplicar los cambios.

gcloud

Para usar los ejemplos de la línea de comandos de esta guía, instala la herramienta de línea de comandos de gcloud o usa un Cloud Shell.

  1. Crea una verificación de estado para la reparación automática, que es más conservadora que la verificación de estado del balanceo de cargas.

    Por ejemplo, crea una verificación de estado que busque una respuesta en el puerto 80 y que pueda tolerar algunas fallas antes de marcar las VM como UNHEALTHY y hacer que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si se muestra de forma correcta una vez. Se marca en mal estado si no se muestra de forma correcta 3 veces consecutivas.

    gcloud compute health-checks create http example-check --port 80 \
           --check-interval 30s \
           --healthy-threshold 1 \
           --timeout 10s \
           --unhealthy-threshold 3
  2. Crea una regla de firewall para permitir que la verificación de estado sondee la conexión a tu app.

    Los sondeos de la verificación de estado provienen de direcciones en los rangos 130.211.0.0/2235.191.0.0/16, así que asegúrate de que las reglas de firewall permitan la conexión de la verificación de estado. Para este ejemplo, nuestro MIG usa la red default y sus VM escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

    gcloud compute firewall-rules create allow-health-check \
            --allow tcp:80 \
            --source-ranges 130.211.0.0/22,35.191.0.0/16 \
            --network default
  3. Aplica la verificación de estado mediante la configuración de una política de reparación automática para el MIG regional o zonal.

    Usa el comando update para aplicar la verificación de estado al MIG.

    La configuración de initial-delay retrasa la reparación automática para que no se lleve a cabo una potencial recreación prematura de la VM si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando el valor currentAction de la VM es VERIFYING.

    Por ejemplo:

    gcloud compute instance-groups managed update my-mig \
            --health-check example-check \
            --initial-delay 300 \
            --zone us-east1-b

API

Para usar los ejemplos de la API en esta guía, configura el acceso a la API.

  1. Crea una verificación de estado para la reparación automática, que es más conservadora que la verificación de estado del balanceo de cargas.

    Por ejemplo, crea una verificación de estado que busque una respuesta en el puerto 80 y que pueda tolerar algunas fallas antes de marcar las VM como UNHEALTHY y hacer que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si se muestra de forma correcta una vez. Se marca en mal estado si no se muestra de forma correcta 3 veces consecutivas.

    POST https://compute.googleapis.com/compute/v1/projects/project-id/global/healthChecks
    
    {
     "name": "example-check",
     "type": "http",
     "port": 80,
     "checkIntervalSec": 30,
     "healthyThreshold": 1,
     "timeoutSec": 10,
     "unhealthyThreshold": 3
    }
    
  2. Crea una regla de firewall para permitir que la verificación de estado sondee la conexión a tu app.

    Los sondeos de la verificación de estado provienen de direcciones en los rangos 130.211.0.0/2235.191.0.0/16, así que asegúrate de que las reglas de firewall permitan la conexión de la verificación de estado. Para este ejemplo, nuestro MIG usa la red default y sus VM escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
     "sourceRanges": [
      "130.211.0.0/22",
      "35.191.0.0/16"
     ],
     "allowed": [
      {
       "ports": [
        "80"
       ],
       "IPProtocol": "tcp"
      }
     ]
    }
    
  3. Aplica la verificación de estado mediante la configuración de una política de reparación automática para el MIG regional o zonal.

    Una política de reparación automática es parte de los recursos instanceGroupManager o regionInstanceGroupManager.

    Puedes configurar una política de reparación automática con los métodos insert o patch.

    En el siguiente ejemplo, se configura una política de reparación automática con el método instanceGroupManagers.patch.

    PATCH https://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    La configuración de initialDelaySec retrasa la reparación automática para que no se lleve a cabo una potencial recreación prematura de la VM si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando el valor currentAction de la VM es VERIFYING.

    Para desactivar la reparación automática de la aplicación, configura la política de reparación automática con un valor vacío, autoHealingPolicies[]. Con autoHealingPolicies[], el MIG solo vuelve a crear las VM que no están en un estado RUNNING.

    Puedes obtener la política de reparación automática de un MIG si lees el campo instanceGroupManagers.autoHealingPolicies. Puedes obtener un recurso de MIG con uno de los siguientes métodos:

Una vez que se complete la actualización de la configuración de verificación de estado o creación de grupos, pueden pasar 30 minutos hasta que la reparación automática comience a supervisar las instancias del grupo. Una vez que comienza la supervisión, Compute Engine comienza a marcar las instancias como en buen estado (o bien las vuelve a crear) según tu configuración de reparación automática. Por ejemplo, si configuras un retraso inicial de 5 minutos, un intervalo de verificación de estado de 1 minuto y un umbral de buen estado de 1 verificación, el cronograma se verá de la siguiente manera:

  • Retraso de 30 minutos antes de que la reparación automática comience a supervisar las instancias del grupo
  • + 5 minutos para el retraso inicial configurado
  • + 1 minuto para el * umbral de buen estado del intervalo de verificación (60s * 1)
  • = 36 minutos antes de que la instancia se marque como en buen estado o se la vuelva a crear

Verifica el estado

Para verificar que se cree una VM y que su aplicación responda, inspecciona el estado actual de cada VM, verifica la acción actual en cada VM o verifica el estado del grupo.

Verifica si las VM están en buen estado

Si configuraste la reparación automática para el MIG, puedes revisar el estado de cada instancia administrada.

Inspecciona los estados de la instancia administrada para hacer lo siguiente:

  • Identificar las VM en mal estado que no se reparan de forma automática. Es posible que una VM no se repare de inmediato, incluso si se diagnosticó que está en mal estado en las siguientes situaciones:
    • La VM aún se está iniciando y no pasó el retraso inicial.
    • Un porcentaje importante de las instancias en mal estado está siendo reparado de forma automática. La reparación automática se retrasa para garantizar que el grupo no deje de ejecutar un subconjunto de instancias.
  • Detectar errores de configuración de verificación de estado. Por ejemplo, puedes detectar reglas de firewall mal configuradas o un extremo de verificación de estado de aplicación no válido si la instancia informa un estado de TIMEOUT.
  • Determinar el valor de retraso inicial a configurar mediante la medición del tiempo que transcurre entre el momento en el que la VM pasa a unestado RUNNING y el momento en el que pasa a un estado HEALTHY. Puedes realizar esta medición con un sondeo del método list-instances.

Usa console, la herramienta de línea de comandos de gcloud o la API para ver los estados.

Console

  1. En Google Cloud Console, ve a la página Grupos de instancias.

    Ir a la página Grupos de instancias.

  2. En la columna Nombre de la lista, haz clic en el nombre del MIG que deseas examinar. Se abrirá una página con las propiedades del grupo de instancias y una lista de las VM incluidas en el grupo.

  3. Si una VM no está en buen estado, puedes ver su estado en la columna Estado de verificación de estado.

gcloud

Use el subcomando list-instances.

gcloud compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

En la columna HEALTH_STATE, se muestra el estado de cada VM.

API

Para un MIG regional, crea una solicitud POST al método listManagedInstances:

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group/listManagedInstances

Para un MIG zonal, usa el método listManagedInstances de MIG zonal:

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances

La solicitud muestra una respuesta similar a la siguiente, que incluye un campo instanceHealth para cada instancia administrada.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

Estados

Los siguientes estados de VM están disponibles:

  • HEALTHY: Se puede acceder a la VM, se puede establecer una conexión con el extremo de verificación de estado de la aplicación, y la respuesta cumple con los requisitos definidos por la verificación de estado.
  • DRAINING: La VM se está purgando. Las conexiones existentes a la VM tienen tiempo para completarse, pero las conexiones nuevas se rechazan.
  • UNHEALTHY: Se puede acceder a la VM, pero no cumple con los requisitos definidos por la verificación de estado.
  • TIMEOUT: No se puede acceder a la VM, no se puede establecer una conexión con el extremo de verificación de estado de la aplicación o el servidor de una VM no responde dentro del tiempo de espera especificado. Por ejemplo, esto puede deberse a reglas de firewall mal configuradas o una aplicación de servidor sobrecargada en una VM.
  • UNKNOWN: El sistema de verificación de estado no conoce la VM o su estado en este momento. La supervisión puede tomar 30 minutos en comenzar en las VM nuevas de un MIG.

Las VM nuevas muestran un estado UNHEALTHY hasta que el sistema de verificación de estado las verifica.

La reparación de una VM depende de su estado:

  • Si una VM tiene un estado UNHEALTHY o TIMEOUT y ya pasó su período de inicialización, el servicio de reparación automática intentará repararla de inmediato.
  • Si una VM tiene un estado UNKNOWN, no se reparará de inmediato. De este modo, se evita la reparación innecesaria de una VM para la que la señal de verificación de estado no está disponible por el momento.

Los intentos de reparación automática pueden retrasarse si sucede lo siguiente:

  • Una VM permanece en mal estado después de varias reparaciones consecutivas.
  • Existe un porcentaje significativo de VM en mal estado en el grupo.

Queremos conocer tus casos prácticos, desafíos o comentarios relacionados con los valores de estado de las VM. Comparte tus comentarios con nuestro equipo en mig-discuss@google.com.

Visualiza las acciones actuales en las VM

Cuando una VM está en proceso de creación, el valor de currentAction de esa instancia es CREATING. Si se vincula una política de reparación automática al grupo, una vez que se crea y ejecuta la VM, la instancia pasa a tener el valor VERIFYING para currentActiony el verificador de estado comienza a sondear la aplicación de la VM. Si la aplicación pasa esta verificación de estado inicial dentro del tiempo que toma en iniciarse, la VM se verifica y su currentAction cambia a NONE.

Puedes ver la currentAction que se está realizando y el status de cada instancia en un grupo de instancias administrado con la herramienta de línea de comandos de gcloud o la API.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud muestra una lista de instancias en el grupo de instancias y sus respectivos estados y acciones actuales. Por ejemplo:

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

En la API, realiza una solicitud GET al método regionInstanceGroupManagers.listManagedInstances. Para un grupo de instancias administrado zonal, usa el método instanceGroupManagers.listManagedInstances.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

La API muestra una lista de instancias dentro del grupo, incluido el instanceStatus y la currentAction de cada instancia.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  }
 ]
}

Para cada instancia en un grupo de instancias administrado, el estado de la instancia se describe mediante su campo instanceStatus. Para ver una lista de los valores del campo instanceStatus válidos, consulta Verifica el estado de una instancia.

Si la instancia experimenta algún tipo de cambio, el campo currentAction se propaga con una de las siguientes acciones para ayudarte a realizar un seguimiento del progreso del cambio. De lo contrario, el campo currentAction es NONE.

Los valores posibles de currentAction son los siguientes:

  • ABANDONING: la instancia se está quitando del grupo de instancias administrado.
  • CREATING: la instancia está en proceso de creación.
  • CREATING_WITHOUT_RETRIES: la instancia se está creando sin reintentos; si la instancia no se crea en el primer intento, el grupo de instancias administrado no intenta volver a reemplazar la instancia.
  • DELETING: La instancia está en proceso de eliminación.
  • RECREATING: La instancia se está reemplazando.
  • REFRESHING: La instancia se está quitando de sus grupos de destino actuales y se está agregando de nuevo a la lista de grupos de destino actuales (esta lista puede ser igual o diferente a la de los grupos de destino existentes).
  • RESTARTING. la instancia está en proceso de reinicio con los métodos stop y start.
  • VERIFYING: la instancia se creó y está en proceso de verificación.
  • NONE: No hay ninguna acción en ejecución en la instancia.

Comprueba si el MIG es estable

En el nivel de grupo, Compute Engine propaga un campo de solo lectura llamado status que contiene una marca isStable.

Si todas las VM del grupo están en ejecución y en buen estado (es decir, el valor de currentAction de cada instancia administrada es NONE), este valor se ve así status.isStable==true. Recuerda que la estabilidad de un MIG depende de los parámetros de configuración de grupo más allá de la política de reparación automática. Por ejemplo, si tu grupo tiene ajuste de escala automático y si está escalando de forma horizontal o vertical, entonces isStable==false debido a la operación del escalador automático.

Para comprobar si un grupo de instancias administrado está en ejecución y en buen estado, verifica el valor del campo status.isStable.

gcloud

Usa el comando describe del grupo de instancias:

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

La herramienta de gcloud muestra información detallada sobre el grupo de instancias, incluido el campo status.isStable.

Para pausar una secuencia de comandos hasta que el grupo se encuentre estable, usa el comando wait-until con la marca --stable. Por ejemplo:

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

El comando vuelve después de que status.isStable se configura como true para el grupo.

API

Para un MIG zonal, realiza una solicitud POST al método instanceGroupManagers.get:

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

Para un grupo de instancias administrado regional, reemplaza zones/zone por regions/region:

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/get

La API muestra información detallada sobre el grupo de instancias, incluido el campo status.isStable.

status.isStable configurado como false indica que los cambios están activos, pendientes o que el grupo de instancias administrado se está modificando.

status.isStable configurado como true indica lo siguiente:

  • Ninguna de las instancias del grupo de instancias administrado se somete a ningún tipo de cambio y la currentAction para todas las instancias es NONE.
  • No hay cambios pendientes para las instancias en el grupo de instancias administrado.
  • No se modifica el grupo de instancias administrado en sí.

Los grupos de instancias administrados se pueden modificar de varias maneras. Por ejemplo:

  • Realizas una solicitud para implementar una plantilla de instancias nueva.
  • Realizas una solicitud para crear, borrar, cambiar el tamaño o actualizar las instancias en el grupo.
  • Un escalador automático solicita cambiar el tamaño del grupo.
  • Un recurso de reparación automática reemplaza una o más instancias en mal estado en el grupo de instancias administrado.
  • En un grupo de instancias administrado regional, se redistribuyen algunas de las instancias.

Cuando todas las acciones se completan, el valor status.isStable se vuelve a establecer en true para ese grupo de instancias administrado.

Visualiza el historial de operaciones de reparación automática

Puedes usar la herramienta de gcloud o la API para ver los eventos de reparación automática anteriores.

gcloud

Usa el comando gcloud compute operations list con un filtro para ver solo los eventos de reparación automática en tu proyecto.

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

Para obtener más información sobre una operación de reparación específica, usa el comando describe. Por ejemplo:

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

API

Para los MIG regionales, envía una solicitud GET al recurso regionOperations y, luego, incluye un filtro a fin de definir el alcance de la lista de salida a los eventos compute.instances.repair.*.

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Para los MIG zonales, usa el recurso zoneOoperations.

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

A fin de obtener más información sobre una operación de reparación específica, envía una solicitud GET para esa operación específica. Por ejemplo:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

Características de una buena verificación de estado de reparación automática

Las verificaciones de estado que se usan en la reparación automática deben ser conservadoras para que no borren ni vuelvan a crear tus instancias de manera preventiva. Cuando una verificación de estado de reparación automática es demasiado agresiva, la reparación automática puede confundir las instancias ocupadas con instancias con errores y reiniciarlas sin necesidad, lo que reduce la disponibilidad.

  • unhealthy-threshold: Debe ser mayor que 1. Lo ideal es que este valor sea 3 o más. Esto brinda protección contra errores poco frecuentes, como una pérdida de paquetes de red.
  • healthy-threshold: un valor de 2 es suficiente para la mayoría de las aplicaciones.
  • timeout: establece este valor de tiempo en una cantidad generosa (cinco veces mayor que el tiempo de respuesta esperado o más). Esto brinda protección contra retrasos inesperados, como instancias ocupadas o una conexión de red lenta.
  • check-interval: este valor debe estar entre 1 segundo y el doble del tiempo de espera (no muy largo ni muy corto). Cuando un valor es demasiado largo, las instancias con errores no se detectan a tiempo. Cuando un valor es demasiado corto, las instancias y la red pueden quedar muy ocupadas, debido a la gran cantidad de sondas de verificación de estado que se envían cada segundo.

Próximos pasos