迁移 App Engine 使用 Google Cloud Load Balancer 导致大约 1 小时的停机时间 [英] Migrating App Engine use Google Cloud Load Balancer cause ~1hr of downtime
问题描述
我在 App Engine 上有实例，其中包含 Google 提供的自定义域和 SSL 证书，但现在我需要在它前面放置一个 Google Cloud Load Balancer.
I have instances on App Engine with a custom domain and SSL certs provisioned by Google, but now I need to put a Google Cloud Load Balancer in front of it.
我按照此处的说明进行操作(针对 App Engine 而不是 Cloud Run 进行了调整):https://cloud.google.com/load-平衡/docs/https/setting-up-https-serverless
I followed the instructions here (with adjustments to do it for App Engine instead of Cloud Run): https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless
我先执行了该指南中的步骤，然后在 GoDaddy 中更新了我的 DNS 记录以指向负载均衡器的 IP.
I performed the steps in that guide first and then updating my DNS records in GoDaddy to point to the IP of the Load Balancer after.
问题是，在我更新我的 GoDaddy DNS 记录以指向负载均衡器的 IP 之后，我花了将近一个小时才能再次访问.尝试通过浏览器或代码访问该站点时，我遇到了 SSL 错误.
The problem is that it took almost an hour to become reachable again, after I updated my GoDaddy DNS records to point to the Load Balancer's IP. When trying to access the site via browser or code, i was getting SSL errors.
核心问题似乎是负载均衡器的 SSL 证书卡在 PROVISIONING 状态，而域卡在 FAILED_NOT_VISIBLE 状态，因为文档说:
The core issue seems to be that the SSL Cert for the Load Balancer was stuck with a status of PROVISIONING and the domain was stuck with a status of FAILED_NOT_VISIBLE, for which the docs say:
域的 DNS 记录未解析为 Google Cloud 负载平衡器的 IP 地址.要解决此问题，请更新 DNS A/AAAA 记录以指向您的负载平衡器的 IP 地址.
The domain's DNS record doesn't resolve to the IP address of the Google Cloud load balancer. To resolve this issue, update the DNS A/AAAA records to point to your load balancer's IP address.
https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting#domain-status
这些文档是关于 PROVISIONING 的:
And these docs say this about PROVISIONING:
Google Cloud 正在与证书颁发机构合作颁发证书.配置 Google 管理的证书可能会占用到 60 分钟
Google Cloud is working with the Certificate Authority to issue the certificate. Provisioning a Google-managed certificate might take up to 60 minutes
我仍然需要对我的生产项目执行此操作.也许如果我改变步骤的顺序(甚至在创建 SSL 证书之前将 DNS 记录指向 IP)?
I still need to do this to my production project. Maybe if I switch up the order of the steps (point the DNS records to the IP before even creating the SSL certs)?
如果我能在更新 DNS 记录以指向负载均衡器的 IP 之前获得 SSL 证书，这似乎很好，但更新 DNS 似乎是 SSL 证书甚至启动的先决条件.
It seems like it'd be fine if I could get the SSL certs to provision before I update the DNS record to point the Load Balancer's IP, but updating the DNS seems to be a prerequisite for the SSL Cert to even start.
这很有趣，因为我已经通过 App Engine 自定义域设置从谷歌获得了这些域的 SSL 证书.我希望这些可以重用于负载平衡器.
It's funny, because I already have SSL certs for these domains from google via the App Engine Custom Domain settings. I wish those could just get reused for the load balancer instead.
推荐答案
您是否创建了新的 DNS 资源记录或更改了现有的记录?
如果您在创建资源记录之前尝试解析它，DNS 服务器将返回NXDOMAIN，这称为否定响应.否定响应由 DNS 解析器缓存.
If you tried to resolve a resource record before you created it, the DNS server will return NXDOMAIN, which is called a Negative Response. Negative responses are cached by DNS Resolvers.
如果您更改了现有资源记录，TTL 是多少?
DNS 解析器使用各种策略来决定缓存 DNS 资源记录的时间.一个因素是 TTL.
DNS Resolvers use various strategies to decide how long to cache DNS resource records. One factor is the TTL.
首先创建/更新 DNS 资源记录
通过首先创建 DNS 资源记录，NXDOMAIN 将不会在验证尝试时返回，这将减少您必须等待否定响应缓存清除的时间.您域的权威 DNS 服务器通常是两到四台服务器.创建新的资源记录时，服务器需要时间来创建 SLAVES 并将其与 MASTER 同步.这个时间通常只有一两分钟.
By creating the DNS resource record first, NXDOMAIN will not be returned on the validation attempt which will reduce how long you must wait for the negative response cache to clear. Your domain's authoritative DNS server is typically two to four servers. When a new resource record is created, it takes time for the servers to create and synchronize the SLAVES with the MASTER. This time is typically only a minute or two.
刷新公共 Google DNS 服务器
如果您的 DNS 资源记录过时(已更改)且 TTL 值过长，请刷新 Google 公共 DNS 服务器.此操作不是即时操作，计划等待五分钟以完成操作.
If you have stale (changed) DNS resource records with long TTL values, flush the Google public DNS servers. This operation is not instant, plan to wait five minutes for the operation to complete.
我能做些什么来避免/尽量减少这一小时的停机时间?
您不能直接更改配置时间.如果您遵循以上几点，配置时间将会减少.根据我的经验，SSL 证书配置通常需要 10 分钟.
You cannot directly change the provisioning time. If you follow the above points, the provisioning time will be reduced. In my experience, ten minutes is typical for SSL certificate provisioning.
Google 负载均衡器在进行更改后需要时间来更新.这个时间会有所不同，但五到十分钟是典型的.这一次是对证书供应的补充.您的网站在此期间可能无法访问.
Google Load Balancers require time to update after making changes. This time varies, but five to ten minutes is typical. This time is in addition to certificate provisioning. Your site may be unavailable during this time.
DNS 服务器更改不是即时的.您域的 DNS 服务器需要时间来更新、Internet 上的 DNS 解析器缓存资源记录、客户端系统缓存记录等.在更改 DNS 服务器之前制定计划.更改可能需要 24 到 72 小时才能在全球传播.
DNS server changes are not instantaneous. Your domain's DNS servers take time to update, DNS Resolvers on the Internet cache resource records, client systems cache records, etc. Create plans before making changes to DNS servers. Changes can take time as in 24 to 72 hours to propagate globally.
这篇关于迁移 App Engine 使用 Google Cloud Load Balancer 导致大约 1 小时的停机时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
