Configura la verificación de estado y la reparación automática para instancias en los MIG

Para mejorar la disponibilidad de tu app y verificar que responda, puedes configurar una política de reparación automática para tu grupo de instancias administrado (MIG).

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

Si el reparador automático determina que una app no responde, el grupo de instancias administrado vuelve a crear esa instancia de forma automática. En el caso de las instancias interrumpibles, el grupo vuelve a crear la instancia cuando los recursos necesarios vuelven a estar disponibles.

Comportamiento de la reparación automática

La reparación automática vuelve a crear instancias en mal estado con la plantilla de instancias original que se usó para crear la instancia de máquina virtual (VM) (no siempre es la plantilla de instancias actual en el grupo de instancias administrado). Por ejemplo, si se creó una instancia de VM con instance-template-a y, luego, se actualiza el grupo de instancias administrado para usar instance-template-b en modo OPPORTUNISTIC, la reparación automática aún usará instance-template-a para volver a crear la instancia. 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 instancia de VM debería usar la plantilla nueva. Si quieres aplicar una plantilla nueva, consulta la sección sobre cómo cambiar la plantilla de instancias de un grupo de instancias administrado.

En un momento determinado, la cantidad de instancias reparadas de forma automática en simultáneo es menor que el tamaño del grupo de instancias administrado. Esto garantiza que el grupo continuará la ejecución de un subconjunto de instancias 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 conectividad de red o de infraestructura que identifiquen de forma errónea una instancia en buen estado como en mal estado. Sin embargo, si un grupo de instancias administrado zonal solo tiene una instancia o un grupo de instancias administrado regional solo tiene una instancia por zona, la reparación automática vuelve a crear estas instancias cuando están en mal estado.

La reparación automática no vuelve a crear una instancia durante el período de inicialización de esa instancia. Para obtener más información, consulta 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 instancia si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando la instancia tiene una currentAction de VERIFYING.

Reparación automática y discos

Cuando se vuelve a crear una instancia basada en su plantilla, la reparación automática maneja diferentes tipos de discos de manera diferente. Algunas configuraciones de disco pueden causar una falla en la reparación automática cuando intenta volver a crear una instancia administrada.

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 instancia.
Disco persistente nuevo false Se conserva el disco y se vuelve a conectar cuando la reparación automática vuelve a crear la instancia.
Disco persistente existente true Se borra el disco antiguo. La recreación de instancia de VM falla porque Compute Engine vuelve a conectar un disco borrado en la instancia.
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 grupo de instancias administrado puede tener solo una VM porque no se puede conectar un disco persistente a varias instancias 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. Se perderán los datos en el SSD local cuando la instancia se vuelva a crear o se borre.

La reparación automática no vuelve a adjuntar los discos que no se especificaron en la plantilla de la instancia, como los discos que adjuntaste 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:

  • Crea instantáneas del disco persistente con regularidad.

  • Exporta los datos a otra fuente, como Cloud Storage.

Si tus instancias tienen alguna configuración importante que deseas conservar, Google también recomienda que uses una imagen personalizada en tu plantilla de instancias. Una imagen personalizada contiene cualquier configuración personalizada que necesites. Cuando especificas una imagen personalizada en tu plantilla de instancias, el grupo de instancias administrado (MIG) vuelve a crear las instancias 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, como máximo, una política de reparación automática por grupo de instancias administrado.

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

Ejemplo de configuración de verificación de estado

En el siguiente ejemplo, se muestra cómo usar una verificación de estado en un grupo de instancias administrado. 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 grupo de instancias administrado 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 instancias como UNHEALTHY y deban volver a crearse. En este ejemplo, una instancia se marca 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. Dirígete a la página Crear una verificación de estado en GCP Console.

      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 en buen estado para determinar la cantidad de verificaciones correctas consecutivas que debe haber hasta que una instancia en mal estado se marque en buen estado. Ingresa 1 para esta instancia.
    8. Establece un umbral en mal estado para determinar la cantidad de verificaciones incorrectas consecutivas que debe haber hasta que una instancia en buen estado se marque 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. En este ejemplo, el grupo de instancias administrado usa la red default y sus instancias escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

    1. Dirígete a la página Crear una regla de firewall en GCP Console.

      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/22 y 35.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 grupo de instancias administrado regional o zonal.

    1. Dirígete a la página Grupos de instancias en GCP Console.

      Ir a la página Grupos de instancias

    2. En la columna Nombre de la lista, haz clic en el nombre del grupo de instancias donde quieres aplicar la verificación de estado.
    3. Haz clic en Editar grupo para modificar este grupo de instancias administrado.
    4. En Reparación automática, selecciona la verificación de estado que creaste anteriormente.
    5. Cambia o mantiene la configuración 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 instancia si esta está en proceso de inicio. El temporizador de retraso inicial comienza cuando la currentAction de la instancia es VERIFYING.
    6. Haz clic en Guardar para aplicar los cambios.

    Pueden transcurrir 15 minutos hasta que la reparación automática comience a supervisar las instancias en el grupo.

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 instancias como UNHEALTHY y deban volver a crearse. En este ejemplo, una instancia se marca 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/22 y 35.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 grupo de instancias administrado usa la red default y sus instancias 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 grupo de instancias administrado regional o zonal.

    Usa el comando update para aplicar la verificación de estado en el grupo de instancias administrado.

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

    Por ejemplo:

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

    Pueden transcurrir 15 minutos hasta que la reparación automática comience a supervisar las instancias en el grupo.

API

Para usar los ejemplos de 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 instancias como UNHEALTHY y deban volver a crearse. En este ejemplo, una instancia se marca 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://www.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/22 y 35.191.0.0/16, así que asegúrate de que las reglas de firewall permitan la conexión de la verificación de estado. En este ejemplo, el grupo de instancias administrado usa la red default y sus instancias escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

    POST https://www.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 grupo de instancias administrado 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://www.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

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

    Pueden transcurrir 15 minutos hasta que la reparación automática comience a supervisar las instancias en el grupo.

    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 grupo de instancias administrado solo vuelve a crear instancias que no estén en el estado RUNNING.

    Puedes obtener la política de reparación automática de un grupo de instancias administrado mediante la lectura del campo instanceGroupManagers.autoHealingPolicies. Puedes obtener un recurso de grupo de instancias administrado con uno de los siguientes métodos:

Verifica el estado

Puedes verificar que una instancia se creó y que su aplicación responde si inspeccionas la acción actual en cada instancia o si verificas el estado del grupo.

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

Acciones actuales en las instancias

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

Para ver la currentAction en ejecución y el status de cada instancia en un grupo de instancias administrado, puedes usar 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           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 POST al método regionInstanceGroupManagers.listManagedInstances. Para un grupo de instancias administrado zonal, usa el método instanceGroupManagers.listManagedInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

La API muestra una lista de las instancias del grupo que incluye los valores instanceStatus y currentAction de cada una.

{
 "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 se describe mediante su campo instanceStatus. Para ver una lista de los valores válidos del campo instanceStatus, consulta la sección sobre cómo comprobar 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 posibles valores 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 borró y se la 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.

Cuando una instancia se actualiza de forma correcta, su campo instanceStatus refleja su estado actual.

Estado del grupo

En el nivel de grupo, Compute Engine propaga un campo de solo lectura llamado status que contiene una marca isStable. Para acceder a esta marca, usa la herramienta de gcloud o la API.

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

Se puede verificar que un grupo de instancias administrado esté en ejecución y en buen estado si se comprueba el valor del campo status.isStable del recurso instanceGroupManagers o regionInstanceGroupManagers asociado.

El valor status.isStable establecido en false indica que los cambios están activos, pendientes o que el grupo de instancias administrado está en modificación.

El estado status.isStable establecido en true indica los siguientes estados:

  • Ninguna de las instancias en el grupo de instancias administrado está experimentando algún tipo de cambio y la currentAction para todas es NONE.
  • No hay cambios pendientes para las instancias en el grupo de instancias administrado.
  • El grupo de instancias administrado en sí no se está modificando.

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.

También puedes usar el comando gcloud beta compute instance-groups managed wait-until con la marca --stable para esperar hasta que status.isStable se establezca en true en el grupo:

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

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 grupos de instancias administrados regionales, envía una solicitud GET al recurso regionOperations y, luego, incluye un filtro para extender el alcance de la lista de salida a los eventos compute.instances.repair.*.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Para grupos de instancias administrados zonales, usa el recurso zoneOoperations.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Si deseas 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://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/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 apps.
  • 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.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine