迁移 App Engine 使用 Google Cloud Load Balancer 导致约 1 小时的停机时间

Question

我在 App Engine 上有一个具有自定义域和 Google 提供的 SSL 证书的实例，但现在我需要在其前面放置一个 Google Cloud Load Balancer。

我按照此处的说明进行操作（进行了调整以针对 App Engine 而不是 Cloud Run 执行此操作）： https: //cloud.google.com/load-balancing/docs/https/setting-up-https-serverless

我首先执行了该指南中的步骤，然后更新了 GoDaddy 中的 DNS 记录以指向负载均衡器的 IP。

问题是，在我更新 GoDaddy DNS 记录以指向负载均衡器的 IP 后，花了将近一个小时才再次可访问。当尝试通过浏览器或代码访问该网站时，我收到 SSL 错误。

核心问题似乎是负载均衡器的 SSL 证书停留在的状态，PROVISIONING并且域停留在的状态FAILED_NOT_VISIBLE，对此文档说：

该网域的 DNS 记录无法解析为 Google Cloud 负载均衡器的 IP 地址。要解决此问题，请更新 DNS A/AAAA 记录以指向负载均衡器的 IP 地址。

这些文档是这样说的PROVISIONING：

Google Cloud 正在与证书颁发机构合作颁发证书。配置 Google 管理的证书最多可能需要 60 分钟

我仍然需要对我的生产项目执行此操作。也许如果我交换步骤的顺序（在创建 SSL 证书之前将 DNS 记录指向 IP）？

如果我能在更新 DNS 记录以指向负载均衡器的 IP 之前获得 SSL 证书，似乎就好了，但更新 DNS 似乎是 SSL 证书启动的先决条件。

这很有趣，因为我已经通过 App Engine 自定义域设置从 google 获得了这些域的 SSL 证书。我希望这些可以重新用于负载均衡器。

Answer 1

您是否创建了新的 DNS 资源记录或更改了现有的 DNS 资源记录？

如果您在创建资源记录之前尝试解析该记录，则 DNS 服务器将返回NXDOMAIN，这称为“否定响应”。否定响应由 DNS 解析器缓存。

如果您更改了现有资源记录，那么 TTL 是多少？

DNS 解析器使用各种策略来决定缓存 DNS 资源记录的时间。其中一个因素是 TTL。

首先创建/更新DNS资源记录

通过首先创建 DNS 资源记录，验证尝试时不会返回 NXDOMAIN，这将减少您必须等待清除否定响应缓存的时间。您的域的权威 DNS 服务器通常有两到四台服务器。当创建新的资源记录时，服务器需要时间来创建 SLAVES 并将其与 MASTER 同步。这个时间通常只有一两分钟。

刷新公共 Google DNS 服务器

如果您有过时（已更改）且 TTL 值较长的 DNS 资源记录，请刷新 Google 公共 DNS 服务器。此操作不是即时的，计划等待五分钟才能完成操作。

我可以做些什么来避免/最大限度地减少这一小时的停机时间？

您无法直接更改配置时间。如果遵循上述几点，配置时间将会减少。根据我的经验，SSL 证书配置通常需要 10 分钟。

Google 负载均衡器在进行更改后需要时间进行更新。该时间各不相同，但通常为五到十分钟。这次是在证书配置之外。您的网站在此期间可能不可用。

DNS 服务器的更改不是即时的。您的域的 DNS 服务器需要时间来更新，Internet 上的 DNS 解析器缓存资源记录、客户端系统缓存记录等。在更改 DNS 服务器之前创建计划。更改可能需要 24 到 72 小时才能在全球范围内传播。