Configurar una comprobación del estado y una reparación automática basadas en aplicaciones

En este documento se describe cómo configurar una comprobación de estado basada en aplicaciones para reparar automáticamente las VMs de un grupo de instancias gestionado (MIG). También se describe cómo hacer lo siguiente: usar una comprobación del estado sin reparación automática, quitar una comprobación del estado, ver la política de reparación automática y comprobar el estado de cada VM.

Puedes configurar una comprobación de estado basada en aplicaciones para verificar que tu aplicación en una VM responde según lo esperado. Si la comprobación del estado que configures detecta que tu aplicación en una VM no responde, el MIG marcará esa VM como incorrecta y la reparará de forma predeterminada. Reparar una VM basándose en una comprobación de estado basada en aplicaciones se denomina reparación automática.

También puedes desactivar la reparación automática en un MIG para poder usar una comprobación del estado sin activar las reparaciones de las VMs en mal estado.

Para obtener más información sobre las reparaciones en un MIG, consulta Acerca de la reparación de VMs para lograr una alta disponibilidad.

Antes de empezar

  • Si aún no lo has hecho, configura la autenticación. La autenticación verifica tu identidad para acceder a Google Cloud servicios y APIs. Para ejecutar código o ejemplos desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando: 

      gcloud init

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    2. Set a default region and zone.

    Terraform

    Para usar las muestras de Terraform de esta página en un entorno de desarrollo local, instala e inicializa la CLI de gcloud y, a continuación, configura las credenciales predeterminadas de la aplicación con tus credenciales de usuario.

      Instala Google Cloud CLI.

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

      If you're using a local shell, then create local authentication credentials for your user account: 

      gcloud auth application-default login

      You don't need to do this if you're using Cloud Shell.

      If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

    Para obtener más información, consulta Set up authentication for a local development environment.

    REST

    Para usar las muestras de la API REST de esta página en un entorno de desarrollo local, debes usar las credenciales que proporciones a la CLI de gcloud.

      Instala Google Cloud CLI.

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    Para obtener más información, consulta el artículo Autenticarse para usar REST de la documentación sobre autenticación de Google Cloud .

Precios

Cuando configuras una comprobación de estado basada en aplicaciones, cada vez que cambia el estado de una máquina virtual, Compute Engine escribe de forma predeterminada una entrada de registro en Cloud Logging. Cloud Logging ofrece una asignación gratuita al mes a partir de la cual el precio de Logging se calcula en función del volumen de datos. Para evitar costes, puedes inhabilitar los registros de cambios de estado de salud.

Configurar una comprobación del estado y una reparación automática basadas en aplicaciones

Para configurar una comprobación del estado basada en aplicaciones y la reparación automática en un MIG, debes hacer lo siguiente:

  1. Crea una comprobación del estado si aún no lo has hecho.
  2. Configura una política de recuperación automática en el MIG para aplicar la comprobación del estado.

Crear una comprobación del estado

Puedes aplicar una sola comprobación de estado a un máximo de 50 grupos de instancias gestionados. Si tienes más de 50 grupos, crea varias comprobaciones del estado.

En el siguiente ejemplo se muestra cómo crear una comprobación de estado para la reparación automática. Puedes crear una comprobación del estado regional o global para la reparación automática de las MIGs. En este ejemplo, se crea una comprobación del estado global que busca una respuesta del servidor web en el puerto 80. Para permitir que las sondas de comprobación del estado lleguen al servidor web, configura una regla de cortafuegos.

Consola

  1. Crea una comprobación del estado para la reparación automática que sea más conservadora que una comprobación del estado de balanceo de carga.

    Por ejemplo, puedes crear una comprobación del estado que busque una respuesta en el puerto 80 y que pueda tolerar algunos errores antes de marcar las VMs como UNHEALTHY y provocar que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si la comprobación de estado se completa correctamente una vez. La VM se marca como en mal estado si la comprobación del estado devuelve un resultado negativo 3 veces consecutivas.

    1. En la Google Cloud consola, ve a la página Crear una comprobación del estado.

      Ir a Crear una comprobación del estado

    2. Asigna un nombre a la comprobación del estado, como example-check.

    3. Selecciona un ámbito. Puedes seleccionar Regional o Global. En este ejemplo, selecciona Global.

    4. En Protocolo, asegúrate de que esté seleccionado HTTP.

    5. En Puerto, escribe 80.

    6. En la sección Criterios de salud, proporcione los siguientes valores:

      1. En Intervalo de comprobación, escribe 5.
      2. En Tiempo de espera, introduce 5.
      3. Define un umbral de buen estado para determinar cuántas comprobaciones del estado correctas consecutivas deben devolverse para que una VM en mal estado se marque como en buen estado. En este ejemplo, introduzca 1.
      4. Define un umbral de mal estado para determinar cuántas comprobaciones del estado incorrectas consecutivas deben devolverse para que una VM en buen estado se marque como en mal estado. En este ejemplo, introduzca 3.

    7. Haz clic en Crear para crear la comprobación del estado.

  2. Crea una regla de cortafuegos para permitir que las sondas de comprobación del estado se conecten a tu aplicación.

    Las exploraciones de comprobación del estado proceden de direcciones de los intervalos 130.211.0.0/22 y 35.191.0.0/16, por lo que debes asegurarte de que las reglas del cortafuegos de tu red permitan que se conecten. En este ejemplo, el MIG usa la red default y sus VMs están escuchando en el puerto 80. Si el puerto 80 aún no está abierto en la red predeterminada, crea una regla de cortafuegos.

    1. En la Google Cloud consola, ve a la página Políticas de cortafuegos.

      Ir a Políticas de cortafuegos

    2. Haz clic en Crear regla de cortafuegos.

    3. Introduce un nombre para la regla de cortafuegos. Por ejemplo, allow-health-check.

    4. En Red, selecciona la red default.

    5. En Objetivos, selecciona All instances in the network.

    6. En Filtro de origen, selecciona IPv4 ranges.

    7. En Intervalos de IPv4 de origen, introduce 130.211.0.0/22 y 35.191.0.0/16.

    8. En Protocolos y puertos, selecciona Protocolos y puertos especificados y haz lo siguiente:

      1. Selecciona TCP.
      2. En el campo Puertos, introduce 80.

    9. Haz clic en Crear.

gcloud

  1. Crea una comprobación del estado para la reparación automática que sea más conservadora que una comprobación del estado de balanceo de carga.

    Por ejemplo, puedes crear una comprobación del estado que busque una respuesta en el puerto 80 y que pueda tolerar algunos errores antes de marcar las VMs como UNHEALTHY y provocar que se vuelvan a crear. En este ejemplo, la VM se marca como en buen estado si devuelve una respuesta correcta. La VM se marca como en mal estado si devuelve un error 3 veces consecutivas. El siguiente comando crea una comprobación del estado global.

    gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global

  2. Crea una regla de cortafuegos para permitir que las sondas de comprobación del estado se conecten a tu aplicación.

    Las peticiones de comprobación del estado proceden de direcciones de los intervalos 130.211.0.0/22 y 35.191.0.0/16, por lo que debes asegurarte de que las reglas de tu cortafuegos permitan que se conecten. En este ejemplo, el MIG usa la red default y sus VMs escuchan en el puerto 80. Si el puerto 80 aún no está abierto en la red predeterminada, crea una regla de cortafuegos.

    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

Terraform

  1. Crea una comprobación del estado con el recurso google_compute_http_health_check.

    Por ejemplo, puedes crear una comprobación del estado que busque una respuesta en el puerto 80 y que pueda tolerar algunos errores antes de marcar las VMs como UNHEALTHY y provocar que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si devuelve una respuesta correcta una vez. La VM se marca como en mal estado si devuelve un error 3 veces consecutivas. La siguiente solicitud crea una comprobación del estado global.

    resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}

  2. Crea un cortafuegos con el recurso google_compute_firewall.

    Las peticiones de comprobación del estado proceden de direcciones de los intervalos 130.211.0.0/22 y 35.191.0.0/16, así que asegúrate de que tus reglas de cortafuegos permitan que se conecten. En este ejemplo, el MIG usa la red default y sus VMs están escuchando en el puerto 80. Si el puerto 80 aún no está abierto en la red predeterminada, crea una regla de cortafuegos.

    resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}

Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.

REST

  1. Crea una comprobación del estado para la reparación automática que sea más conservadora que una comprobación del estado de balanceo de carga.

    Por ejemplo, puedes crear una comprobación del estado que busque una respuesta en el puerto 80 y que pueda tolerar algunos errores antes de marcar las VMs como UNHEALTHY y provocar que se vuelvan a crear. En este ejemplo, una VM se marca como en buen estado si devuelve una respuesta correcta una vez. La VM se marca como en mal estado si devuelve un error 3 veces consecutivas. La siguiente solicitud crea una comprobación del estado global.

    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 cortafuegos para permitir que las sondas de comprobación del estado se conecten a tu aplicación.

    Las peticiones de comprobación del estado proceden de direcciones de los intervalos 130.211.0.0/22 y 35.191.0.0/16, así que asegúrate de que tus reglas de cortafuegos permitan que se conecten. En este ejemplo, el MIG usa la red default y sus VMs están escuchando en el puerto 80. Si el puerto 80 aún no está abierto en la red predeterminada, crea una regla de cortafuegos.

    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"
  }
 ]
}

    Sustituye PROJECT_ID por el ID de tu proyecto.

Configurar una política de recuperación automática en un MIG

En un MIG, solo puedes configurar una política de reparación automática para aplicar una comprobación del estado.

Antes de configurar una política de reparación automática, si aún no tienes una comprobación de estado, crea una. Puedes usar una comprobación de estado regional o global para la reparación automática en MIGs. Una comprobación del estado regional reduce las dependencias entre regiones y ayuda a conseguir la residencia de datos, mientras que una comprobación del estado global es útil si quieres usar la misma comprobación del estado para MIGs de varias regiones.

Si quieres evitar que se active la reparación automática por error al configurar una nueva comprobación de estado o quieres usar una comprobación de estado sin reparación automática, consulta Configurar una comprobación de estado sin reparación automática. También puedes desactivar la reparación automática después de configurar una comprobación de estado en el MIG.

Para configurar una política de recuperación automática, selecciona una de las siguientes opciones:

Consola

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

    Ir a Grupos de instancias

  2. En la columna Nombre de la lista, haga clic en el nombre del MIG en el que quiera aplicar la comprobación de estado.

  3. Haz clic en Editar para modificar este MIG.

  4. Haga clic en Ciclo de vida de la instancia y reparación automática para desplegar la sección.

    1. En la sección Autorreparación, en Comprobación del estado, seleccione una comprobación del estado global o regional.
    2. En Retraso inicial, usa el valor predeterminado o modifícalo según sea necesario.

      El retraso inicial es el número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de retardo inicial de una VM, la MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, indica que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la VM cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. En la consola, el valor predeterminado es 300 segundos.

  5. Haz clic en Guardar para aplicar los cambios.

gcloud

Para configurar la política de recuperación automática en un MIG, usa el comando update. Por ejemplo, usa el siguiente comando para configurar una política de reparación automática en un MIG zonal:

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Para configurar la política de recuperación automática al crear un MIG, usa el comando create. Por ejemplo, usa el siguiente comando para configurar la política de recuperación automática al crear un MIG zonal:

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Haz los cambios siguientes:

  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • SIZE: número de VMs del grupo.
  • INSTANCE_TEMPLATE_URL: la URL de la plantilla de instancia que quieres usar para crear VMs en el MIG. La URL puede contener el ID o el nombre de la plantilla de instancia. Especifica uno de los siguientes valores:
    • En el caso de una plantilla de instancia regional, haz lo siguiente: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • En el caso de una plantilla de instancia global, haz lo siguiente: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: URL parcial de la comprobación de estado que quieras configurar para la reparación automática. Por ejemplo:
    • Comprobación del estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Comprobación del estado global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de demora inicial de una VM, el MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, significa que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la máquina virtual cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. El valor predeterminado es 0.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de los grupos de instancias gestionados regionales, usa la marca --region.

Terraform

Para configurar una política de recuperación automática en un MIG, usa el auto_healing_policies bloque.

En el siguiente ejemplo se configura una política de reparación automática en un MIG zonal. Para obtener más información sobre el recurso utilizado en el ejemplo, consulta google_compute_instance_group_manager. Para una MIG regional, usa el recurso google_compute_region_instance_group_manager.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.

REST

Para configurar la política de recuperación automática en un MIG, usa el método patch de la siguiente manera:

Por ejemplo, haz la siguiente llamada para configurar la reparación automática en un MIG zonal:

  PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
  {
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

Para configurar la política de recuperación automática al crear un MIG, utiliza el método insert de la siguiente manera:

Por ejemplo, haz la siguiente llamada para configurar la política de reparación automática al crear un MIG zonal:

  POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
  {
    "name": "MIG_NAME",
    "targetSize": SIZE,
    "instanceTemplate": "INSTANCE_TEMPLATE_URL",
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

Haz los cambios siguientes:

  • PROJECT_ID: tu ID de proyecto.
  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • SIZE: número de VMs del grupo.
  • INSTANCE_TEMPLATE_URL: la URL de la plantilla de instancia que quieres usar para crear VMs en el MIG. La URL puede contener el ID o el nombre de la plantilla de instancia. Especifica uno de los siguientes valores:
    • En el caso de una plantilla de instancia regional, haz lo siguiente: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • En el caso de una plantilla de instancia global, haz lo siguiente: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: URL parcial de la comprobación de estado que quieras configurar para la reparación automática. Por ejemplo:
    • Comprobación del estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Comprobación del estado global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de demora inicial de una VM, el MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, significa que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la máquina virtual cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. El valor predeterminado es 0.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de un MIG regional, usa regions/REGION en la URL.

Una vez que se haya completado la configuración de la reparación automática, pueden pasar 10 minutos antes de que esta empiece a monitorizar las VMs del grupo. Una vez que se inicia la monitorización, Compute Engine empieza a marcar las VMs como activas (o las vuelve a crear) en función de la configuración de recuperación automática. Por ejemplo, si configuras un retraso inicial de 5 minutos, un intervalo de comprobación del estado de 1 minuto y un umbral de buen estado de 1 comprobación, la cronología será la siguiente:

  • Retraso de 10 minutos antes de que la reparación automática empiece a monitorizar las VMs del grupo
  • + 5 minutos por el retraso inicial configurado
  • + 1 minuto para el intervalo de comprobación * umbral de buen estado (60 s * 1)
  • = 16 minutos antes de que la VM se marque como correcta o se vuelva a crear

Configurar una comprobación del estado sin reparación automática

Puedes desactivar la reparación automática en un MIG y usar la comprobación de estado configurada para monitorizar el estado de tu aplicación o implementar tu propia lógica de reparación. Desactivar la reparación automática en un MIG no afecta al funcionamiento de la comprobación del estado. La comprobación del estado sigue comprobando la aplicación y proporciona los estados de salud de la VM. Sin embargo, el MIG ya no reparará las VMs que no estén en buen estado.

Para configurar una comprobación del estado sin reparación automática, selecciona una de las siguientes opciones.

Consola

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

    Ir a Grupos de instancias

  2. En la columna Nombre de la lista, haga clic en el nombre del MIG en el que quiera aplicar la comprobación de estado.

  3. Haz clic en Editar para modificar este MIG.

  4. Haga clic en Ciclo de vida de la instancia y reparación automática para desplegar la sección.

    1. En la sección Autorreparación, en Comprobación del estado, seleccione una comprobación del estado global o regional.
    2. En Retraso inicial, usa el valor predeterminado o modifícalo según sea necesario.

      El retraso inicial es el número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de retardo inicial de una VM, la MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, indica que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la VM cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. En la consola, el valor predeterminado es 300 segundos.

    1. En la lista Al fallar la comprobación del estado, selecciona Ninguna acción.

  5. Haz clic en Guardar para aplicar los cambios.

gcloud

Para configurar una comprobación de estado sin reparación automática, cuando especifiques la configuración de la comprobación de estado, también debes asignar el valor do-nothing a la marca --action-on-vm-failed-health-check de la siguiente manera:

  • En un MIG, usa el comando beta update.

    Por ejemplo, usa el siguiente comando en un MIG zonal:

    gcloud beta compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

  • Cuando crees un MIG, usa el comando beta create.

    Por ejemplo, usa el siguiente comando al crear un MIG zonal:

    gcloud beta compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

Haz los cambios siguientes:

  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • SIZE: número de VMs del grupo.
  • INSTANCE_TEMPLATE_URL: la URL de la plantilla de instancia que quieres usar para crear VMs en el MIG. La URL puede contener el ID o el nombre de la plantilla de instancia. Especifica uno de los siguientes valores:
    • En el caso de una plantilla de instancia regional, haz lo siguiente: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • En el caso de una plantilla de instancia global, haz lo siguiente: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: URL parcial de la comprobación de estado que quieras configurar para la reparación automática. Por ejemplo:
    • Comprobación del estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Comprobación del estado global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de demora inicial de una VM, el MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, significa que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la máquina virtual cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. El valor predeterminado es 0.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de los grupos de instancias gestionados regionales, usa la marca --region.

REST

Para configurar una comprobación de estado sin reparación automática, cuando especifiques la configuración de la comprobación de estado, también debes definir el campo onFailedHealthCheck en DO_NOTHING de la siguiente manera:

  • En un MIG, usa el método beta patch de la siguiente manera:

    Por ejemplo, haz la siguiente llamada en un MIG zonal:

    PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

  • Cuando crees un MIG, usa el método beta insert de la siguiente manera:

    Por ejemplo, haz la siguiente llamada al crear un MIG zonal:

    POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL",
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

Haz los cambios siguientes:

  • PROJECT_ID: tu ID de proyecto.
  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • SIZE: número de VMs del grupo.
  • INSTANCE_TEMPLATE_URL: la URL de la plantilla de instancia que quieres usar para crear VMs en el MIG. La URL puede contener el ID o el nombre de la plantilla de instancia. Especifica uno de los siguientes valores:
    • En el caso de una plantilla de instancia regional, haz lo siguiente: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • En el caso de una plantilla de instancia global, haz lo siguiente: INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL: URL parcial de la comprobación de estado que quieras configurar para la reparación automática. Por ejemplo:
    • Comprobación del estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • Comprobación del estado global: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: número de segundos que tarda una máquina virtual nueva en inicializarse y ejecutar su secuencia de comandos de inicio. Durante el periodo de demora inicial de una VM, el MIG ignora las comprobaciones del estado fallidas porque la VM puede estar en el proceso de inicio. De esta forma, se evita que el MIG vuelva a crear una VM prematuramente. Si la comprobación del estado recibe una respuesta correcta durante el retraso inicial, significa que el proceso de inicio se ha completado y que la VM está lista. El temporizador de retardo inicial se inicia cuando el campo currentAction de la máquina virtual cambia a VERIFYING. El valor del retraso inicial debe estar entre 0 y 3600 segundos. El valor predeterminado es 0.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de un MIG regional, usa regions/REGION en la URL.

Después de configurar la comprobación del estado, puedes monitorizar los estados de salud de la VM para confirmar que la comprobación del estado funciona correctamente. Si quieres que el MIG repare las máquinas virtuales que no estén en buen estado, puedes activar la reparación automática.

Eliminar una comprobación del estado

Para eliminar una comprobación de estado configurada en una política de reparación automática, sigue estos pasos:

Consola

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

    Ir a Grupos de instancias

  2. Haga clic en el nombre del MIG del que quiera quitar la comprobación de estado.

  3. Haz clic en Editar para modificar este MIG.

  4. Haga clic en Ciclo de vida de la instancia y reparación automática para desplegar la sección.

  5. En la sección Autorreparación, en Comprobación del estado, selecciona Ninguna comprobación del estado.

  6. Haz clic en Guardar para aplicar los cambios.

gcloud

Para eliminar la configuración de comprobación de estado de una política de recuperación automática, en el comando update, usa la marca --clear-autohealing de la siguiente manera:

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

Sustituye MIG_NAME por el nombre de un MIG.

REST

Para eliminar la configuración de comprobación de estado de una política de reparación automática, asigna un valor vacío a la política de reparación automática.

Por ejemplo, para eliminar una comprobación del estado de un MIG zonal, haz la siguiente solicitud:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

Haz los cambios siguientes:

  • PROJECT_ID: tu ID de proyecto.
  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de los grupos de instancias gestionados regionales, usa regions/REGION.

Ver la política de reparación automática de un MIG

Para ver la política de reparación automática de un MIG, sigue estos pasos:

Consola

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

    Ir a Grupos de instancias

  2. Haga clic en el nombre del MIG del que quiera ver la política de recuperación automática.

  3. Ve a la pestaña Detalles.

    En la sección Ciclo de vida de la instancia de VM se muestra la comprobación del estado y el retraso inicial configurado en la política de reparación automática.

gcloud

Para ver la política de reparación automática de un MIG, usa el siguiente comando:

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

Sustituye MIG_NAME por el nombre de un MIG.

A continuación, se muestra un ejemplo de resultado: 

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

Para ver la política de reparación automática de un MIG, utiliza los métodos REST de la siguiente manera:

Por ejemplo, haz la siguiente solicitud para ver la política de reparación automática de un MIG zonal:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

En el cuerpo de la respuesta, busca el objeto autoHealingPolicies[].

A continuación se muestra un ejemplo de respuesta:

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

Haz los cambios siguientes:

  • PROJECT_ID: tu ID de proyecto.
  • MIG_NAME: Nombre del MIG en el que quieres configurar la reparación automática.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de los grupos de instancias gestionados regionales, usa regions/REGION.

Comprobar el estado

Después de configurar una comprobación del estado basada en aplicaciones en un MIG, puedes verificar que una VM se está ejecutando y que su aplicación responde de las siguientes formas:

Comprobar si las VMs están en buen estado

Si has configurado una comprobación de estado basada en aplicaciones en tu MIG, puedes consultar el estado de cada instancia gestionada.

Inspecciona los estados de salud de tus instancias gestionadas para hacer lo siguiente:

  • Identifica las máquinas virtuales que no están en buen estado y que no se están reparando. Es posible que una VM no se repare inmediatamente aunque se haya diagnosticado como no operativa en las siguientes situaciones:
    • La VM aún se está iniciando y no ha transcurrido el tiempo de retraso inicial.
    • Se está reparando una parte importante de las instancias en mal estado. El MIG retrasa la reparación automática para asegurarse de que el grupo siga ejecutando un subconjunto de instancias.
  • Detecta errores de configuración de comprobaciones del estado. Por ejemplo, puedes detectar reglas de cortafuegos mal configuradas o un endpoint de comprobación del estado de la aplicación no válido si la instancia informa de un estado de TIMEOUT.
  • Para determinar el valor del retraso inicial que se va a configurar, mide el tiempo que transcurre entre el momento en que la VM pasa a un RUNNING estado y el momento en que pasa a un estado de HEALTHY. Puedes medir este intervalo consultando el método list-instances o observando el tiempo entre la operación instances.insert y la primera señal correcta recibida.

Usa la consola, la herramienta de línea de comandos gcloud o REST para ver los estados de salud.

Consola

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

    Ve a Grupos de instancias.

  2. En la columna Nombre de la lista, haga clic en el nombre del MIG que quiera examinar. Se abrirá una página con las propiedades del grupo de instancias y una lista de las VMs que incluye.

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

gcloud

Usa el subcomando list-instances.

gcloud compute instance-groups managed list-instances MIG_NAME
    --zone ZONE

El comando devuelve un resultado similar al siguiente. El campo HEALTH_STATE muestra el estado de cada máquina virtual.

NAME: igm-with-hc-fvz6
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

NAME: igm-with-hc-gtz3
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

Haz los cambios siguientes:

  • MIG_NAME: el nombre del MIG.
  • ZONE: la zona en la que se encuentra el MIG. En el caso de los grupos de instancias gestionados regionales, usa --region REGION.

REST

En el caso de un MIG regional, crea una solicitud POST al método listManagedInstances:

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

En el caso de un MIG de zona, usa el método listManagedInstances del MIG de zona:

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

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

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/sproject-id/zones/zone/instances/igm-with-hc-fvz6",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6159431761228150698",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-fvz6"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/igm-with-hc-gtz3",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6622324799312181783",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-gtz3"
    }
  ]
}

Estados de salud

Están disponibles los siguientes estados de salud de la VM:

  • HEALTHY: Se puede acceder a la VM, se puede establecer una conexión con el endpoint de comprobación del estado de la aplicación y la respuesta se ajusta a los requisitos definidos por la comprobación del estado.
  • DRAINING: la VM está drenando. Las conexiones que ya existen con la VM aún pueden completarse, pero se rechazan las nuevas.
  • UNHEALTHY: Se puede acceder a la VM, pero no cumple los requisitos definidos por la comprobación del estado.
  • TIMEOUT: No se puede acceder a la VM, no se puede establecer una conexión con el endpoint de comprobación del estado de la aplicación o el servidor de una VM no responde en el tiempo de espera especificado. Por ejemplo, esto puede deberse a que las reglas de firewall están mal configuradas o a que la aplicación del servidor de una máquina virtual está sobrecargada.
  • UNKNOWN: el sistema de comprobación del estado no tiene en cuenta la VM o su estado no se conoce en este momento. El monitorizado de las nuevas VMs de un MIG puede tardar 10 minutos en empezar.

Las nuevas máquinas virtuales devuelven el estado UNHEALTHY hasta que el sistema de comprobación de estado las verifica.

Si se repara una VM, depende de su estado de salud:

  • Si una VM tiene el estado de salud UNHEALTHY o TIMEOUT y ha superado el periodo de inicialización, la MIG intenta repararla inmediatamente.
  • Si una VM tiene el estado de salud UNKNOWN, el MIG no la reparará inmediatamente. De esta forma, se evita la reparación innecesaria de una VM cuya señal de comprobación del estado no está disponible temporalmente.

Los intentos de reparación automática se pueden retrasar en los siguientes casos:

  • Una VM sigue en mal estado después de varias reparaciones consecutivas.
  • Una parte importante del total de las VMs del grupo no está en buen estado.

Queremos conocer tus casos prácticos, los problemas que has tenido o tus comentarios sobre los valores del estado de salud de las VMs. Puedes enviar tus comentarios a nuestro equipo a través de la dirección mig-discuss@google.com.

Consultar las acciones actuales en las máquinas virtuales

Cuando un MIG está creando una instancia de VM, asigna el valor CREATING al campo de solo lectura currentAction de esa instancia. Si se adjunta una política de reparación automática al grupo, después de crear y ejecutar la VM, el MIG asigna el valor VERIFYING a la acción actual de la instancia y el comprobador de estado empieza a sondear la aplicación de la VM. Si la aplicación supera esta comprobación de estado inicial en el tiempo que tarda en iniciarse, se verifica la máquina virtual y el MIG cambia el campo currentAction de la máquina virtual a NONE.

Para consultar las acciones actuales de las máquinas virtuales, consulta Ver las acciones actuales de las máquinas virtuales.

Comprobar si el MIG es estable

A nivel de grupo, Compute Engine rellena un campo de solo lectura llamado status que contiene una marca isStable.

Si todas las VMs del grupo están en ejecución y en buen estado (es decir, el campo currentAction de cada instancia gestionada tiene el valor NONE), el MIG asigna el valor true al campo status.isStable. Recuerda que la estabilidad de un MIG depende de las configuraciones del grupo que no sean la política de reparación automática. Por ejemplo, si tu grupo se autoescala y se está escalando hacia dentro o hacia fuera, el MIG asigna el valor false al campo status.isStable debido a la operación de autoescalado.

Para comprobar los valores del campo status.isStable de tu MIG, consulta Comprobar si un MIG es estable.

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

Puedes usar la CLI de gcloud o la API REST 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 de recuperación automática de 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

REST

En el caso de las MIGs regionales, envía una solicitud GET al recurso regionOperations e incluye un filtro para acotar la lista de resultados a eventos compute.instances.repair.*.

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

En el caso de los MIGs zonales, usa el recurso zoneOperations.

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

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

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

Qué hace que una comprobación del estado de recuperación automática sea buena

Las comprobaciones del estado que se usan para la reparación automática deben ser conservadoras para que no eliminen y vuelvan a crear tus instancias de forma preventiva. Si una comprobación del estado de la reparación automática es demasiado agresiva, es posible que la reparación automática confunda las instancias ocupadas con las instancias fallidas y las reinicie innecesariamente, lo que reducirá la disponibilidad.

  • unhealthy-threshold. Debe ser superior a 1. Lo ideal es que este valor sea 3 o más. De esta forma, se protege frente a fallos poco frecuentes, como la pérdida de paquetes de red.
  • healthy-threshold. Un valor de 2 es suficiente para la mayoría de las aplicaciones.
  • timeout. Asigna a este valor de tiempo una cantidad generosa (cinco veces o más que el tiempo de respuesta esperado). De esta forma, se evitan 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 debe ser demasiado largo ni demasiado corto). Cuando un valor es demasiado largo, no se detecta una instancia fallida con la suficiente antelación. Si un valor es demasiado corto, las instancias y la red pueden estar muy ocupadas, dado el gran número de sondeos de comprobación de estado que se envían cada segundo.

Siguientes pasos