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

---

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

Puedes configurar una verificación de estado basada en la aplicación para comprobar que la aplicación en una VM responda como se espera. Si la verificación de estado que configuras detecta que tu aplicación en una VM no responde, el MIG marca esa VM como en mal estado y la repara. La reparación de una VM basada en una verificación de estado basada en aplicaciones se denomina autohealing.

También puedes desactivar las reparaciones en un MIG para que puedas usar una verificación de estado sin activar la reparación automática.

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

Antes de empezar

• Configura la autenticación si aún no lo hiciste. La autenticación es el proceso mediante el cual se verifica tu identidad para acceder a los servicios y las API de Google Cloud. Para ejecutar código o muestras desde un entorno de desarrollo local, puedes autenticarte en Compute Engine de la siguiente manera.
  

  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. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

     Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
  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 gcloud CLI y, luego, configura las credenciales predeterminadas de la aplicación con tus credenciales de usuario.

  1. Install the Google Cloud CLI.

  2. To initialize the gcloud CLI, run the following command:

     gcloud init

  3. 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.

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

  REST

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

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  Si deseas obtener más información, consulta Autentica para usar REST en la documentación de autenticación de Google Cloud.

Precios

Cuando configuras una verificación de estado basada en la aplicación, cada vez que cambia el estado de una VM, de forma predeterminada, Compute Engine escribe una entrada de registro en Cloud Logging. Cloud Logging proporciona una asignación gratuita por mes, después de la cual el precio de los registros se calcula según el volumen de datos. Para evitar costos, puedes inhabilitar los registros de cambios de estado.

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

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

1. Crea una verificación de estado si aún no lo hiciste.
2. Configura una política de reparación automática en el MIG para aplicar la verificación de estado.

Sugerencia: Usa verificaciones de estado separadas para el balanceo de cargas y la reparación. Las verificaciones de estado del balanceo de cargas detectan VMs que no responden y alejan el tráfico de ellas. Las verificaciones de estado para la reparación automática detectan las VMs en mal estado y las vuelven a crear de forma proactiva, por lo que esta verificación debe ser más conservadora que una verificación de estado del balanceo de cargas. Para obtener más información, consulta Cómo es una verificación de estado de reparación automática buena.

Crear una verificación de estado

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.

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

Permisos necesarios para esta tarea

Para realizar esta tarea, debes tener los siguientes permisos:

• compute.healthChecks.create en el proyecto, si se crea una verificación de estado
• compute.healthChecks.use en la verificación de estado que se usará
• compute.firewalls.create en el proyecto, si se crea un firewall
• compute.networks.updatePolicy en la red, si se crea un firewall

Los permisos están disponibles en las siguientes funciones preconfiguradas.

• compute.networkAdmin para crear verificaciones de estado
• compute.securityAdmin para configurar reglas de firewall que permitan la verificación de estado

Consola

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 la verificación de estado se muestra de forma correcta una vez. La VM se marca como en mal estado si la verificación de estado se muestra de forma incorrecta 3 veces consecutivas.

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

      Ir a Crea una verificación de estado

   2. Nombra la verificación de estado, como example-check.

   3. Elige un permiso. Puedes seleccionar Regional o Global. Para este ejemplo, elige Global.

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

   5. En Puerto, escribe 80.

   6. En la sección Criterios de estado, proporciona los siguientes valores:

      1. En Intervalo de verificación, escribe 5.
      2. En Tiempo de espera, escribe 5.
      3. 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. Escribe 1 para esta instancia.
      4. Establece un umbral de mal estado para 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. Escribe 3 para esta instancia.

   7. 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.

   Precaución: Si las reglas de firewall bloquean los sondeos de verificación de estado, marcan tus instancias como UNHEALTHY porque no pueden conectarse a la app. Esto puede provocar que se vuelvan a crear de forma automática las VMs que podrían estar en buen estado.

   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 de la red permitan la conexión de la verificación de estado. Para este ejemplo, el MIG usa la red default y sus VMs escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

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

      Ir a Políticas de firewall

   2. Haz clic en Crear regla de firewall.

   3. Escribe un Nombre para la regla de firewall. Por ejemplo, allow-health-check

   4. En Red, elige la red default.

   5. En Destinos, elige All instances in the network.

   6. En Filtro de origen, elige IPv4 ranges.

   7. Para Rangos de IPv4 de origen, escribe 130.211.0.0/22 y 35.191.0.0/16.

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

      1. Elige TCP.
      2. En el campo Puertos, escribe 80.

   9. Haz clic en Crear.

gcloud

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 VMs 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. La VM se marca como en mal estado si no se muestra de forma correcta 3 veces consecutivas. El siguiente comando crea una verificación de estado global.

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

   Nota: Usa las verificaciones de estado más recientes, que admiten los protocolos HTTP, HTTPS, TCP y SSL (TLS). Las verificaciones de estado HTTP y HTTPS de Compute Engine heredadas aún funcionan.

2. Crea una regla de firewall para permitir que la verificación de estado sondee la conexión a tu app.

   Precaución: Si las reglas de firewall bloquean los sondeos de verificación de estado, marcan tus instancias como UNHEALTHY porque no pueden conectarse a la app. Esto puede provocar que se vuelvan a crear de forma automática las VMs que podrían estar en buen estado.

   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, el MIG usa la red default y sus VMs 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
   

Terraform

1. Crea una verificación de estado con el recurso google_compute_http_health_check.

   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 VMs 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. La VM se marca como en mal estado si no se muestra de forma correcta 3 veces consecutivas. La siguiente solicitud crea una verificación de 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 firewall con el recurso google_compute_firewall.

   Precaución: Si las reglas de firewall bloquean los sondeos de verificación de estado, marcan tus instancias como UNHEALTHY porque no pueden conectarse a la app. Esto puede provocar que se vuelvan a crear de forma automática las VMs que podrían estar en buen estado.

   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, el MIG usa la red default y sus VMs escuchan en el puerto 80. Si el puerto 80 no está abierto en la red predeterminada, crea una regla de firewall.

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

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

REST

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 VMs 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. La VM se marca como en mal estado si no se muestra de forma correcta 3 veces consecutivas. La siguiente solicitud crea una verificación de 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
   }
   

   Nota: Usa las verificaciones de estado más recientes, que admiten los protocolos HTTP, HTTPS, TCP y SSL (TLS). Las verificaciones de estado HTTP y HTTPS de Compute Engine heredadas aún funcionan.

2. Crea una regla de firewall para permitir que la verificación de estado sondee la conexión a tu app.

   Precaución: Si las reglas de firewall bloquean los sondeos de verificación de estado, marcan tus instancias como UNHEALTHY porque no pueden conectarse a la app. Esto puede provocar que se vuelvan a crear de forma automática las VMs que podrían estar en buen estado.

   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, el MIG usa la red default y sus VMs 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"
     }
    ]
   }
   

   Reemplaza PROJECT_ID por el ID del proyecto.

Configura una política de reparación automática en un MIG

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

Puedes usar una de las siguientes verificaciones de estado regional o global para la reparación automática en MIGs. Las verificaciones de estado regionales reducen las dependencias entre regiones y ayudan a lograr la residencia de los datos. Las verificaciones de estado globales son convenientes si deseas usar la misma verificación de estado para MIGs en varias regiones.

Antes de configurar una política de reparación automática, haz lo siguiente:

• Si aún no tienes una verificación de estado, crea una.
• Si deseas evitar la activación falsa de la reparación automática mientras configuras una verificación de estado nueva, primero debes desactivar las reparaciones en el MIG y, luego, configurar la política de reparación automática.

Permisos necesarios para esta tarea

Para realizar esta tarea, debes tener los siguientes permisos:

• compute.instanceGroupManagers.update en el MIG

Los permisos están disponibles en las siguientes funciones preconfiguradas.

• compute.instanceAdmin.v1 para crear y actualizar políticas de reparación automática en MIG

Consola

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

   Ir a 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 para modificar este MIG.

4. En la sección Ciclo de vida de la instancia de VM, en Reparación automática, elige una Verificación de estado global o regional.

5. Cambia o mantén la configuración de Retraso inicial.

   El retraso inicial es la cantidad de segundos que tarda una VM nueva en inicializar y ejecutar su secuencia de comandos de inicio. Durante el período de retraso inicial de una VM, el MIG ignora las verificaciones de estado fallidas porque la VM puede estar en el proceso de inicio. Esto evita que el MIG vuelva a crear una VM prematuramente. Si la verificación de estado recibe una respuesta en buen estado durante el retraso inicial, indica que el proceso de inicio está completo y que la VM está lista. El temporizador de retraso inicial comienza cuando el campo currentAction de la VM cambia a VERIFYING. El valor de retraso inicial debe ser de entre 0 y 3,600 segundos. En la consola, el valor predeterminado es 300 segundos.

6. Haz clic en Guardar para aplicar los cambios.

gcloud

Nota: El comando set-autohealing está obsoleto y se quitará en el futuro. En su lugar, usa el comando update para un MIG existente y el comando create para un MIG nuevo.

Para configurar la política de reparación automática en un MIG existente, usa el comando update.

Por ejemplo, usa el siguiente comando para configurar la 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 reparación automática cuando creas un MIG, usa el comando create.

Por ejemplo, usa el siguiente comando para configurar la política de reparación automática cuando crees 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

Reemplaza lo siguiente:

• MIG_NAME: El nombre del MIG en el que deseas configurar la reparación automática.
• SIZE: La cantidad de VM en el grupo.
• INSTANCE_TEMPLATE_URL: la URL parcial de la plantilla de instancias que deseas usar para crear las VMs en el grupo. Por ejemplo:
  • Plantilla de instancias regionales: projects/example-project/regions/us-central1/instanceTemplates/example-template.
  • Plantilla de instancias globales: projects/example-project/global/instanceTemplates/example-template.
• HEALTH_CHECK_URL: Es la URL parcial de la verificación de estado que deseas configurar para la reparación automática. Si deseas usar una verificación de estado regional, debes proporcionar la URL parcial de la verificación de estado regional. Por ejemplo:
  • Verificación de estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
  • Verificación de estado global: projects/example-project/global/healthChecks/example-health-check.
• INITIAL_DELAY: Es la cantidad de segundos que tarda una VM nueva en inicializar y ejecutar su secuencia de comandos de inicio. Durante el período de retraso inicial de una VM, el MIG ignora las verificaciones de estado fallidas porque la VM puede estar en el proceso de inicio. Esto evita que el MIG vuelva a crear una VM prematuramente. Si la verificación de estado recibe una respuesta en buen estado durante el retraso inicial, indica que el proceso de inicio está completo y que la VM está lista. El temporizador de retraso inicial comienza cuando el campo currentAction de la VM cambia a VERIFYING. El valor de retraso inicial debe ser de entre 0 y 3600 segundos. El valor predeterminado es 0.
• ZONE: zona en la que se encuentra el MIG. Para un MIG regional, usa la marca --region.

Terraform

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

En el siguiente ejemplo, se configura la política de reparación automática en un MIG zonal. Para obtener más información sobre el recurso usado en la muestra, consulta recurso google_compute_instance_group_manager. Para un MIG regional, usa el método 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
  }
}

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

REST

Nota: Los métodos instanceGroupManagers.setAutohealingPolicies y regionInstanceGroupManager.setAutohealingPolicies no forman parte de la API que suele estar disponible y están obsoletos. En su lugar, usa los métodos patch o insert.

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

• Para un MIG zonal, usa el método instanceGroupManager.patch.
• Para un MIG regional, usa el método regionInstanceGroupManager.patch.

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

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 reparación automática cuando creas un MIG, usa el método insert de la siguiente manera:

• Para un MIG zonal, usa el método instanceGroupManager.insert.
• Para un MIG regional, usa el método regionInstanceGroupManager.insert.

Por ejemplo, realiza la siguiente llamada para configurar la política de reparación automática cuando crees 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
    }
  ],
}

Reemplaza lo siguiente:

• PROJECT_ID: el ID de tu proyecto.
• MIG_NAME: El nombre del MIG en el que deseas configurar la reparación automática.
• SIZE: La cantidad de VM en el grupo.
• INSTANCE_TEMPLATE_URL: la URL parcial de la plantilla de instancias que deseas usar para crear las VMs en el grupo. Por ejemplo:
  • Plantilla de instancias regionales: projects/example-project/regions/us-central1/instanceTemplates/example-template.
  • Plantilla de instancias globales: projects/example-project/global/instanceTemplates/example-template.
• HEALTH_CHECK_URL: Es la URL parcial de la verificación de estado que deseas configurar para la reparación automática. Por ejemplo:
  • Verificación de estado regional: projects/example-project/regions/us-central1/healthChecks/example-health-check.
  • Verificación de estado global: projects/example-project/global/healthChecks/example-health-check.
• INITIAL_DELAY: Es la cantidad de segundos que tarda una VM nueva en inicializar y ejecutar su secuencia de comandos de inicio. Durante el período de retraso inicial de una VM, el MIG ignora las verificaciones de estado fallidas porque la VM puede estar en el proceso de inicio. Esto evita que el MIG vuelva a crear una VM prematuramente. Si la verificación de estado recibe una respuesta en buen estado durante el retraso inicial, indica que el proceso de inicio está completo y que la VM está lista. El temporizador de retraso inicial comienza cuando el campo currentAction de la VM cambia a VERIFYING. El valor de retraso inicial debe ser de entre 0 y 3600 segundos. El valor predeterminado es 0.
• ZONE: zona en la que se encuentra el MIG. Para un MIG regional, usa regions/REGION en la URL.

Una vez que se complete la configuración de la reparación automática, pueden pasar 30 minutos hasta que la reparación automática comience a supervisar las VMs del grupo. Después de que comienza la supervisión, Compute Engine comienza a marcar las VMs 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 VMs 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 VM se marque como en buen estado o se la vuelva a crear

Si desactivaste las reparaciones en el MIG antes de configurar la política de reparación automática, puedes supervisar los estados de la VM para confirmar que la verificación de estado funcione como se espera y, luego, configurar el MIG para reparar las VMs.

Usa una verificación de estado sin reparación automática

Puedes usar la verificación de estado que está configurada en un MIG sin reparación automática si desactivas las reparaciones en el MIG. Esto es útil en situaciones en las que deseas usar la verificación de estado solo para supervisar el estado de la aplicación o cuando deseas implementar tu propia lógica de reparación basada en la verificación de estado.

Precaución: Debes tener cuidado si decides desactivar las reparaciones en un MIG, ya que también se desactiva la reparación automática de las VMs con errores en el MIG.

Para volver a configurar el MIG para reparar las VMs en mal estado, consulta Configura un MIG para reparar las VMs con errores y en mal estado.

Quita una verificación de estado

Puedes quitar una verificación de estado configurada en una política de reparación automática de la siguiente manera:

Consola

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

   Ir a Grupos de instancias

   1. Haz clic en el nombre del MIG del que deseas quitar la verificación de estado.
   2. Haz clic en Editar para modificar este MIG.
   3. En la sección Ciclo de vida de la instancia de VM, en Reparación automática, elige Sin verificación de estado.
   4. Haz clic en Guardar para aplicar los cambios.

gcloud

Para quitar la configuración de verificación de estado en una política de reparació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

Reemplaza MIG_NAME por el nombre de un MIG.

REST

Para quitar la configuración de verificación de estado en una política de reparación automática, establece la política de reparación automática en un valor vacío.

• Para un MIG zonal, usa el método instanceGroupManagers.patch
• Para un MIG regional, usa el método regionInstanceGroupManagers.patch

Por ejemplo, para quitar la verificación de estado en un MIG zonal, realiza la siguiente solicitud:

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

{
  "autoHealingPolicies": [
    {}
  ]
}

Reemplaza lo siguiente:

• PROJECT_ID: el ID de tu proyecto.
• MIG_NAME: El nombre del MIG en el que deseas configurar la reparación automática.
• ZONE: zona en la que se encuentra el MIG. Para un MIG regional, usa regions/REGION.

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

Puedes ver la política de reparación automática de un MIG de la siguiente manera:

Consola

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

   Ir a Grupos de instancias

2. Haz clic en el nombre del MIG del que deseas ver la política de reparación automática.

3. Ve a la pestaña Detalles.

4. En la sección Ciclo de vida de la instancia de VM, el campo Reparación automática muestra la verificación de 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 en un MIG, usa el siguiente comando:

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

Reemplaza MIG_NAME por el nombre de un MIG.

El siguiente es un resultado de muestra:

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 en un MIG, usa los métodos REST de la siguiente manera:

• Para un MIG zonal, usa el método instanceGroupManagers.get
• Para un MIG regional, usa el método regionInstanceGroupManagers.get

Por ejemplo, realiza la siguiente solicitud para ver la política de reparación automática en 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 una respuesta de ejemplo:

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

Reemplaza lo siguiente:

• PROJECT_ID: el ID de tu proyecto.
• MIG_NAME: El nombre del MIG en el que deseas configurar la reparación automática.
• ZONE: zona en la que se encuentra el MIG. Para un MIG regional, usa regions/REGION.

Verifica el estado

Después de configurar una verificación de estado basada en la aplicación en un MIG, puedes verificar que una VM se esté ejecutando y que su aplicación responda de las siguientes maneras:

• Verifica si las VMs están en buen estado
• Verifica las acciones actuales en las VMs
• Comprueba si el MIG es estable

Verifica si las VMs están en buen estado

Si configuraste una verificación de estado basada en la aplicación para tu MIG, puedes revisar el estado de cada instancia administrada.

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

• Identificar las VMs en mal estado que no se están reparando. 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 está en proceso de iniciarse y no ha pasado el retraso inicial.
  • Un porcentaje importante de las instancias en mal estado se está reparando. El MIG demora cualquier reparación automática adicional 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.
• Determina el valor de retraso inicial a configurar midiendo el tiempo que transcurre entre el momento en el que la VM pasa a un estado RUNNING y el momento en el que pasa a un estado HEALTHY. Para medir esta brecha, sondea el método list-instances o puedes observar el tiempo entre la operación instances.insert y el primer indicador de buen estado recibido.

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

Permisos necesarios para esta tarea

Para realizar esta tarea, debes tener los siguientes permisos:

• compute.instanceGroupManagers.get en el MIG

Console

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

   IR A 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.

REST

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, así como 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 ni 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, el MIG no la repara 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. Puedes compartir tus comentarios con nuestro equipo en [e-mail].

Verifica las acciones actuales en las VMs

Cuando un MIG está en un proceso de creación de una instancia de VM, establece el campo currentAction de solo lectura de esa instancia en CREATING. Si se vincula una política de reparación automática al grupo, una vez que se crea y ejecuta la VM, el MIG define la acción actual de la instancia en VERIFYING y 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 demora en iniciarse, la VM se verifica y el MIG cambia el campo currentAction de la VM a NONE.

Para verificar las acciones actuales en las VM, consulta Visualiza las acciones actuales en las VMs.

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 VMs del grupo están en ejecución y en buen estado (es decir, el campo currentAction de cada instancia administrada se establece en NONE), el MIG establece el campo status.isStable en 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á realizando un aumento o una reducción de escala horizontal, entonces el MIG establece el campo status.isStable en false debido a la operación del escalador automático.

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

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

Puedes usar gcloud CLI 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

REST

Para los MIGs regionales, envía una solicitud GET al recurso regionOperations y, luego, incluye un filtro para 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 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 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.

Pasos siguientes

• Prueba el instructivo sobre cómo usar la reparación automática para apps con alta disponibilidad.
• Supervisa los cambios de estado de las VMs.
• Aplica actualizaciones de configuración durante las reparaciones.