设置运行状况检查和自动修复

代管实例组 (MIG) 通过主动保持虚拟机 (VM) 实例可用(即处于 RUNNING 状态)来维护应用的高可用性。如果代管实例停止运行,但状态更改不是由 MIG 发起的,MIG 会自动重新创建该实例。另一方面,如果 MIG 有意停止处于 RUNNING 状态的实例(例如,当自动扩缩器删除实例时),则 MIG 不会重新创建该实例。

不是由 MIG 发起的实例状态更改包括:

但是,依靠实例的状态来确定应用运行状况可能不够。例如,检查实例是否处于 RUNNING 状态并不会检测应用故障,例如冻结,过载或崩溃。

如需进一步提高应用的可用性以及验证应用是否能正常响应,可以为 MIG 配置自动修复政策。

自动修复政策依赖于基于应用的运行状况检查来验证应用是否按预期响应。与仅验证虚拟机是否处于 RUNNING 状态相比,检查应用是否响应可以获得更加精准的结果。

如果自动修复程序确定应用没有响应,则 MIG 会自动重新创建该虚拟机。对于抢占式虚拟机,该组会在必要的资源变得再次可用时重新创建虚拟机。

自动修复行为

自动修复功能使用用于创建虚拟机的原始实例模板(不一定是 MIG 中的当前实例模板)重新创建运行状况不佳的虚拟机。例如,如果虚拟机原先是使用 instance-template-a 创建的,然后您更新 MIG 以在 OPPORTUNISTIC 模式下使用 instance-template-b,则自动修复仍会使用 instance-template-a 重新创建该虚拟机。这是因为自动修复的重新创建操作不是用户启动的,所以 Compute Engine 不会假定虚拟机应该使用新模板。如果要应用新模板,请参阅更改 MIG 的实例模板

在任何给定时间,并发自动修复的虚拟机数量都比 MIG 的规模小。这可确保即使出现以下情况,实例组仍可以持续运行一部分虚拟机:自动修复政策不适合工作负载,防火墙规则配置错误,或者某些网络连接或基础架构问题导致系统将运行状况良好的虚拟机错误地识别为运行状况不佳。但是,如果区域级 MIG 只有一个虚拟机,或者地区级 MIG 在每个区域只有一个虚拟机,则自动修复会在这些虚拟机运行状况不佳时重新创建它们。

自动修复不会在虚拟机的初始化期间重新创建虚拟机。如需了解详情,请参阅 autoHealingPolicies[].initialDelaySec 属性。此设置会延迟自动修复功能检查该虚拟机的时间,以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentActionVERIFYING 时开始计时。

首次将运行状况检查附加到代管实例组时,可能需要 30 分钟才能开始进行监控。

自动修复和磁盘

在基于模板重新创建虚拟机时,自动修复程序会以不同方式处理不同类型的磁盘。在尝试重新创建虚拟机时,某些磁盘配置可能会导致自动修复程序失败。

磁盘类型 autodelete 在自动修复操作期间的行为
新的永久性磁盘 true 如实例模板中所指定的那样重新创建磁盘。重新创建磁盘及其虚拟机时,原来写入该磁盘的所有数据都将丢失。
新的永久性磁盘 false 在自动修复程序重新创建虚拟机时保留并重新连接磁盘。
现有的永久性磁盘 true 旧磁盘已删除。虚拟机重新创建失败,因为 Compute Engine 无法将已删除的磁盘重新挂接到虚拟机。
现有的永久性磁盘 false 如实例模板中所指定的那样重新附加旧磁盘。磁盘上的数据会保留。但是,对于现有的读写磁盘,MIG 最多只能有一个虚拟机,因为单个永久性磁盘无法以读写模式挂接到多个虚拟机。
新的本地 SSD 如实例模板中所指定的那样重新创建磁盘。在重新创建或删除虚拟机时,本地 SSD 上的数据将丢失。

自动修复程序不会重新挂接实例模板中未指定的磁盘,例如在创建虚拟机后手动挂接到该虚拟机的磁盘。

要保留写入磁盘的重要数据,请采取一些预防措施,例如:

如果您的虚拟机具有要保留的重要设置,Google 还建议您在实例模板中使用自定义映像。自定义映像包含您需要的任何自定义设置。在实例模板中指定自定义映像时,MIG 会使用包含所需自定义设置的自定义映像重新创建虚拟机。

设置运行状况检查和自动修复政策

您最多可以为每个 MIG 设置一项自动修复政策。

您可以将单个运行状况检查应用于最多 50 个 MIG。如果您拥有的实例组超过 50 个,请创建多个运行状况检查。

运行状况检查设置示例

以下示例演示了如何对 MIG 使用运行状况检查。在此示例中,您将创建运行状况检查,使其在端口 80 上查找 Web 服务器响应。如需使运行状况检查探测能够访问每个 Web 服务器,请配置防火墙规则。最后,通过设置 MIG 的自动修复政策,将运行状况检查应用于该实例组。

控制台

  1. 为自动修复创建运行状况检查,这种检查比负载平衡运行状况检查更加保守。

    例如,创建一个查找端口 80 响应的运行状况检查,该检查可以容许某些失败操作,然后才会将虚拟机标记为 UNHEALTHY,导致其被重新创建。在本示例中,如果虚拟机成功返回一次,则会被标记为“运行状况良好”。如果连续 3 次未能成功返回,则会被标记为“运行状况不佳”。

    1. 在 Google Cloud Console 中,转到创建运行状况检查页面。

      转到“创建运行状况检查”页面

    2. 为此运行状况检查指定名称,例如 example-check
    3. 对于协议,请确保选中 HTTP
    4. 对于端口,请输入 80
    5. 对于检查间隔,请输入 5
    6. 对于超时,请输入 5
    7. 设置状况良好判断阈值,指定运行状况不佳的虚拟机必须连续多少次返回成功的运行状况检查,才能被标记为运行状况良好。对于此示例,请输入 1
    8. 设置状况不佳判断阈值,指定运行状况良好的虚拟机必须连续多少次返回不成功的运行状况检查,才能被标记为运行状况不佳。对于此示例,请输入 3
    9. 点击创建以创建运行状况检查。
  2. 创建防火墙规则以允许运行状况检查探测连接到您的应用。

    运行状况检查探测请求来自 130.211.0.0/2235.191.0.0/16 范围内的地址,因此请确保您的网络防火墙规则允许运行状况检查进行连接。在本示例中,我们的 MIG 使用的是 default 网络,并且其虚拟机侦听的是端口 80。如果端口 80 尚未在默认网络中打开,请创建防火墙规则。

    1. 在 Google Cloud Platform Console 中,转到创建防火墙规则页面。

      转到“创建防火墙规则”页面

    2. 对于名称,请为防火墙规则输入一个名称,例如 allow-health-check
    3. 对于网络,请选择 default 网络。
    4. 对于来源过滤条件,请选择 IP ranges
    5. 对于来源 IP 地址范围,请输入 130.211.0.0/2235.191.0.0/16
    6. 协议和端口中,选择指定的协议和端口并输入 tcp:80
    7. 点击创建
  3. 为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。

    1. 在 Google Cloud Console 中,转到实例组页面。

      转到“实例组”页面

    2. 在列表的名称列下方,点击要应用运行状况检查的 MIG 的名称。
    3. 点击修改组以修改此 MIG。
    4. 自动修复下方,选择您之前创建的运行状况检查。
    5. 更改或保留初始延迟时间设置。此设置会延迟自动修复功能的初始检查,以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentActionVERIFYING 时开始计时。
    6. 点击保存以应用更改。

gcloud

如需使用本指南中的命令行示例,请安装 gcloud 命令行工具,或使用 Cloud Shell

  1. 为自动修复创建运行状况检查,这种检查比负载平衡运行状况检查更加保守。

    例如,创建一个查找端口 80 响应的运行状况检查,该检查可以容许某些失败操作,然后才会将虚拟机标记为 UNHEALTHY,导致其被重新创建。在本示例中,如果虚拟机成功返回一次,则会被标记为“运行状况良好”。如果连续 3 次未能成功返回,则会被标记为“运行状况不佳”。

    gcloud compute health-checks create http example-check --port 80 \
           --check-interval 30s \
           --healthy-threshold 1 \
           --timeout 10s \
           --unhealthy-threshold 3
  2. 创建防火墙规则以允许运行状况检查探测连接到您的应用。

    运行状况检查探测请求来自 130.211.0.0/2235.191.0.0/16 范围内的地址,因此请确保您的防火墙规则允许运行状况检查进行连接。在本示例中,我们的 MIG 使用的是 default 网络,并且其虚拟机侦听的是端口 80。如果端口 80 尚未在默认网络中打开,请创建防火墙规则。

    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. 为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。

    使用 update 命令将运行状况检查应用于 MIG。

    initial-delay 设置会延迟自动修复功能的初始检查,以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentActionVERIFYING 时开始计时。

    例如:

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

API

如需使用本指南中的 API 示例,请设置 API 访问权限

  1. 为自动修复创建运行状况检查,这种运行状况检查比负载平衡运行状况检查更加保守。

    例如,创建一个查找端口 80 响应的运行状况检查,该检查可以容许某些失败操作,然后才会将虚拟机标记为 UNHEALTHY,导致其被重新创建。在本示例中,如果虚拟机成功返回一次,则会被标记为“运行状况良好”。如果连续 3 次未能成功返回,则会被标记为“运行状况不佳”。

    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. 创建防火墙规则以允许运行状况检查探测连接到您的应用。

    运行状况检查探测请求来自 130.211.0.0/2235.191.0.0/16 范围内的地址,因此请确保您的防火墙规则允许运行状况检查进行连接。在本示例中,我们的 MIG 使用的是 default 网络,并且其虚拟机侦听的是端口 80。如果端口 80 尚未在默认网络中打开,请创建防火墙规则。

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
     "sourceRanges": [
      "130.211.0.0/22",
      "35.191.0.0/16"
     ],
     "allowed": [
      {
       "ports": [
        "80"
       ],
       "IPProtocol": "tcp"
      }
     ]
    }
    
  3. 为地区级或区域级 MIG 组配置自动修复政策以应用运行状况检查。

    自动修复政策是 instanceGroupManager 资源或 regionInstanceGroupManager 资源的一部分。

    您可以使用 insertpatch 方法设置自动修复政策。

    以下示例使用 instanceGroupManagers.patch 方法设置自动修复政策。

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

    initialDelaySec 设置会延迟自动修复功能的初始检查,以避免在虚拟机启动过程中过早地重新创建虚拟机。初始延迟计时器从虚拟机的 currentActionVERIFYING 时开始计时。

    如需关闭基于应用的自动修复,请将自动修复政策设置为空值,即 autoHealingPolicies[]。设置为 autoHealingPolicies[] 以后,MIG 仅重新创建未处于 RUNNING 状态的虚拟机。

    您可以通过读取 instanceGroupManagers.autoHealingPolicies 字段来获取 MIG 的自动修复政策。您可以使用以下某个方法获取 MIG 资源:

实例组创建或运行状况检查配置更新完成后,最多可能要等候 30 分钟,自动修复才会开始监控实例组中的实例。监控开始后,Compute Engine 会开始根据您的自动修复配置将实例标记为运行状况良好(或重新创建实例)。例如,如果您配置的初始延迟时间为 5 分钟,运行状况检查间隔为 1 分钟,并且运行状况阈值为 1 次检查,时间安排会如下所述:

  • 自动修复开始监控实例组中的实例之前 30 分钟的延迟时间
  • + 5 分钟(配置的初始延迟时间)
  • + 1 分钟的检查间隔 * 运行状况阈值(60 秒 * 1)
  • = 将该实例标记为“运行状况良好”或重新创建实例之前,要等待 36 分钟

检查状态

通过检查每个虚拟机的当前运行状况、检查对每个虚拟机的当前操作或检查实例组的状态,您可以验证虚拟机是否已创建以及其应用是否正在响应。

检查虚拟机的运行状况是否良好

如果您为 MIG 配置了自动修复,则可以检查每个代管实例的运行状况。

检查代管实例的运行状况,以便执行以下操作:

  • 识别未自动修复的运行状况不佳的虚拟机。即使虚拟机在以下情况下被诊断为运行状况不佳,也可能无法立即修复:
    • 虚拟机仍在启动,并且其初始延迟时间尚未过去。
    • 很大一部分运行状况不佳的实例目前正在自动修复。自动修复程序延迟进一步自动修复,以确保实例组持续运行一部分实例。
  • 检测运行状况检查配置错误。例如,如果实例报告的运行状况为 TIMEOUT,则您可以检测配置错误的防火墙规则或无效的应用运行状况检查端点。
  • 通过衡量虚拟机转换为 RUNNING 状态的时间点与虚拟机转换为 HEALTHY 运行状况的时间点之间的时长,确定要配置的初始延迟时间值。您可以通过轮询 list-instances 方法来衡量此时间差。

使用控制台gcloud 命令行工具或 API 查看运行状况。

控制台

  1. 在 Google Cloud Console 中,转到实例组页面。

    转到“实例组”页面

  2. 在列表的名称列下方,点击要检查的 MIG 的名称。随即打开的页面中会显示实例组属性以及其中所含的虚拟机列表。

  3. 如果虚拟机运行状况不佳,您可以在运行状况检查状态列中查看其运行状况。

gcloud

使用 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

HEALTH_STATE 列显示每个虚拟机的运行状况。

API

对于地区级 MIG,请构建一个向 listManagedInstances 方法发出的 POST 请求:

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

对于区域级 MIG,请使用区域级 MIG listManagedInstances 方法:

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

请求会返回类似于如下所示的响应,其中包括每个代管实例的 instanceHealth 字段。

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

运行状况

以下虚拟机运行状况可用:

  • HEALTHY:虚拟机可访问,可以建立与应用运行状况检查端点的连接,响应符合运行状况检查定义的要求。
  • DRAINING:虚拟机正在排空。与虚拟机的现有连接有时间完成,但新连接遭到拒绝。
  • UNHEALTHY:虚拟机可访问,但不符合运行状况检查定义的要求。
  • TIMEOUT:虚拟机无法访问:无法建立与应用运行状况检查端点的连接,或者虚拟机上的服务器未在指定超时时间内响应。例如,这可能是由配置错误的防火墙规则或虚拟机上的过载服务器应用造成的。
  • UNKNOWN:运行状况检查系统不知道虚拟机,或者其运行状况目前未知。有可能需要 30 分钟,才会开始监控 MIG 中的新虚拟机。

新虚拟机将返回 UNHEALTHY 状态,直到其经过运行状况检查系统的验证。

是否修复某个虚拟机取决于其运行状况:

  • 如果虚拟机的运行状况为 UNHEALTHYTIMEOUT,并且其初始化期限已过,则自动修复服务会立即尝试对实例进行修复。
  • 如果虚拟机的运行状况为 UNKNOWN,则不会立即进行修复。这是为了防止对运行状况检查信号暂时不可用的虚拟机进行不必要的修复。

如果出现以下情况,自动修复尝试可能会延迟:

  • 连续多次修复后,虚拟机的运行状况仍然不佳。
  • 实例组中存在很大一部分运行状况不佳的虚拟机。

我们希望了解您有关虚拟机运行状况值的使用场景、挑战或反馈。请发送至 mig-discuss@google.com,与我们的团队分享您的反馈。

查看当前对虚拟机的操作

在创建虚拟机的过程中,该实例的 currentActionCREATING。如果实例组附加了自动修复政策,虚拟机一旦创建完成并运行,该实例的 currentAction 将变为 VERIFYING,并且运行状况检查程序将开始探测该虚拟机的应用。如果应用在其启动过程中通过了此初始运行状况检查,则该虚拟机将通过验证且其 currentAction 将变为 NONE

您可以使用 gcloud 命令行工具API 查看代管实例组中每个实例正在执行的 currentAction 以及 status

gcloud

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

gcloud 会返回实例组中的实例列表,以及各实例的状态和当前操作。例如:

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

API

在 API 中,向 regionInstanceGroupManagers.listManagedInstances 方法发出 GET 请求。对于区域代管实例组,请使用 instanceGroupManagers.listManagedInstances 方法。

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

API 会返回该实例组的实例列表,其中包含每个实例的 instanceStatuscurrentAction

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

对于代管实例组中的每个实例,实例的状态均由其 instanceStatus 字段描述。如需查看有效 instanceStatus 字段值的列表,请参阅检查实例的状态

如果实例正在进行某类更改,则系统会在 currentAction 字段中填入以下某一操作,以帮助您跟踪更改进度。否则,currentAction 字段为 NONE

可能的 currentAction 值如下:

  • ABANDONING:正在将该实例从代管实例组中移除。
  • CREATING:该实例正在创建中。
  • CREATING_WITHOUT_RETRIES:正在创建该实例,且不会重试;如果第一次尝试并未创建该实例,则代管实例组将不会再次尝试替换该实例。
  • DELETING:该实例正在被删除。
  • RECREATING:该实例正在被替换。
  • REFRESHING:该实例正从其当前目标池中移除,并正在被读取到当前目标池列表中(此列表与现有目标池可能相同,也可能不同)。
  • RESTARTING:正在使用 stopstart 方法重启该实例。
  • VERIFYING:该实例已创建并且正在接受验证。
  • NONE:当前并未对该实例执行任何操作。

验证 MIG 是否处于稳定状态

在组级别,Compute Engine 会填充一个名为 status 的只读字段,该字段包含 isStable 标志。

如果实例组中的所有虚拟机都在运行且运行状况良好(即每个代管实例的 currentAction 均为 NONE),状态值将显示为 status.isStable==true。请注意,MIG 的稳定性取决于自动修复政策之外的实例组配置;举例来说,如果您的实例组采用自动扩缩机制,并且当前正在缩减或横向扩容,那么由于自动扩缩器操作的关系,状态值将显示为 isStable==false

如需验证代管实例组是否正在运行且运行状况良好,检查 status.isStable 字段的值即可。

gcloud

使用实例组 describe 命令:

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

gcloud 工具会返回有关实例组的详细信息,其中包括 status.isStable 字段。

如需暂停脚本直至实例组稳定,请将 wait-until 命令与 --stable 标志结合使用。例如:

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

该命令会在实例组的 status.isStable 设置为 true 后返回。

API

对于地区级 MIG,请向 instanceGroupManagers.get 方法发出 POST 请求:

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

对于地区代管实例组,请将 zones/zone 替换为 regions/region

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

API 会返回有关实例组的详细信息,其中包括 status.isStable 字段。

status.isStable 设置为 false 时,表示表示正在更改、正在等待更改或者正在修改代管实例组本身。

status.isStable 设置为 true 时,则表示以下含义:

  • 代管实例组中的任何实例都未在进行任何类型的更改,并且所有实例的 currentAction 均为 NONE
  • 代管实例组中的实例没有任何待处理的更改。
  • 代管实例组本身未在进行修改。

有多种途径可导致对代管实例组的修改。例如:

  • 发出发布新实例模板的请求。
  • 发出创建、删除、调整或更新实例组中实例的请求。
  • 通过自动扩缩程序请求调整实例组的大小。
  • 通过自动修复程序资源替换代管实例组中一个或多个运行状况不佳的实例。
  • 重新分配地区代管实例组中的部分实例。

完成所有操作后,该代管实例组的 status.isStable 会立即重新设置为 true

查看历史自动修复操作

您可以使用 gcloud 工具或 API 查看过去的自动修复事件。

gcloud

gcloud compute operations list 命令和过滤条件搭配使用可以仅查看项目中自动修复的相应修复事件。

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

如需详细了解特定修复操作,请使用 describe 命令。例如:

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

API

对于地区级 MIG,请向 regionOperations 资源提交 GET 请求并添加一个过滤条件,以将输出列表范围限定为 compute.instances.repair.* 事件。

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

对于区域级 MIG,请使用 zoneOoperations 资源。

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

如需详细了解特定修复操作,请针对该特定操作提交 GET 请求。例如:

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

良好的自动修复运行状况检查需要具备哪些特点

自动修复运行状况检查应该比较保守,以免在不必要时删除并重新创建实例。如果为自动修复功能设置的运行状况检查过于严格,则自动修复程序可能会将繁忙的实例误认为故障实例,并且不必要地重启它们,从而降低可用性。

  • unhealthy-threshold。此值应大于 1。最好将此值设置为 3 或更大。这样可以防止在发生网络数据包丢失等罕见故障时误判。
  • healthy-threshold。对于大多数应用来说,将此值设置为 2 就足够了。
  • timeout。请将此时间值设置为一个较大的值(预期响应时间的五倍或更长时间)。这样可以防止在出现意外延迟(例如实例繁忙或网络拥堵造成的延迟)时误判。
  • check-interval。此值应介于 1 秒到超时的两倍之间(不要太长,也不要太短)。如果设置的时间太长,就不能及时发现故障实例。如果设置的时间太短,实例和网络可能会因运行状况检查每秒发送大量探测而变得非常繁忙。

后续步骤