本文說明如何將現有專案從全域 DNS 遷移至可用區 DNS。區域性 DNS 可隔離區域內的服務中斷情形,避免執行個體建立和自動修復等重要服務受到影響,進而提升可靠性。
事前準備
-
如果尚未設定驗證,請先完成設定。
驗證可確認您的身分,以便存取 Google Cloud 服務和 API。如要從本機開發環境執行程式碼或範例,您可以選取下列其中一個選項,向 Compute Engine 進行驗證:
請根據您打算如何使用本頁範例,選取對應的分頁標籤:
控制台
使用 Google Cloud 控制台存取 Google Cloud 服務和 API 時,不需要設定驗證。
gcloud
-
安裝 Google Cloud CLI。 完成後,執行下列指令來初始化 Google Cloud CLI:
gcloud init若您採用的是外部識別資訊提供者 (IdP),請先 使用聯合身分登入 gcloud CLI。
-
- 設定預設區域和可用區。
REST
如要在本機開發環境中使用本頁的 REST API 範例,請使用您提供給 gcloud CLI 的憑證。
安裝 Google Cloud CLI。
如果您使用外部識別資訊提供者 (IdP),請先 使用聯合身分登入 gcloud CLI。
詳情請參閱 Google Cloud 驗證說明文件中的「使用 REST 進行驗證」。
必要的角色
如要取得將專案遷移至區域性 DNS 所需的權限,請要求管理員授予您下列 IAM 角色:
-
將專案遷移至使用區域性 DNS:
專案的專案編輯者 (
roles/resourcemanager.projectEditor) -
將專案中的 Compute Engine 執行個體遷移至分區 DNS:
專案中的「Compute 執行個體管理員 (v1)」 (
roles/compute.instanceAdmin.v1) -
如果運算執行個體使用服務帳戶,則為:
服務帳戶或專案的服務帳戶使用者 (
roles/iam.serviceAccountUser)
如要進一步瞭解如何授予角色,請參閱「管理專案、資料夾和組織的存取權」。
這些預先定義的角色具備將專案遷移至區域性 DNS 的權限。如要查看確切的必要權限,請展開「Required permissions」(必要權限) 部分:
所需權限
必須具備下列權限,才能將專案遷移至區域性 DNS:
-
檢查全域 DNS 名稱和運算執行個體中繼資料:
compute.projects.get -
設定運算執行個體的中繼資料:
compute.instances.setMetadata -
設定專案範圍的中繼資料:
compute.projects.setCommonInstanceMetadata -
如果運算執行個體使用服務帳戶,則:
iam.serviceAccounts.actAs
設定 DNS 查詢失敗的監控
最佳做法是在遷移至區域 DNS 前,先在 Compute Engine 專案中啟用 Cloud DNS 查詢記錄。您可以利用記錄監控及比較遷移至可用區內部 DNS 前後的內部 DNS 失敗率。Google 建議您在遷移前至少 24 小時啟用 DNS 查詢記錄,建立遷移前的基準。
在 DNS 查詢記錄中收集足夠的資料後,即可執行區域性 DNS 遷移作業。您可以在遷移期間監控 DNS 解析率,確保遷移作業不會導致 DNS 查詢失敗次數增加。
如要瞭解 DNS 查詢監控費用,請參閱「Cloud DNS 查詢記錄定價資訊」。
檢查專案是否預設使用全域 DNS
檢查專案,確認是否需要從全域 DNS 遷移至可用區 DNS。您只需要遷移已設定為使用全域 DNS 做為專案內建立的任何內部 DNS 名稱預設值的專案。
控制台
前往 Google Cloud 控制台的 Compute Engine「Metadata」(中繼資料) 頁面。
在「中繼資料」分頁中,查看
VmDnsSetting設定 (如有)。指派的值會指出專案是否預設使用全域 DNS。GlobalDefault:專案已啟用全域 DNS。ZonalOnly:專案已啟用區域性 DNS。 這項專案不需要遷移。
如果沒有列出
VmDnsSetting中繼資料設定,請確認貴機構是否預設使用全域 DNS。
gcloud
執行下列 gcloud CLI 指令,檢查 vmDnsSetting 的值。
gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
將 PROJECT_ID 替換為專案名稱。
傳回的值會指出專案是否預設使用全域 DNS。
GLOBAL_DEFAULT:專案已啟用全域 DNS。ZONAL_ONLY:專案已啟用區域性 DNS。這項專案不需要遷移。
REST
使用 projects.get 方法檢查 vmDnsSetting 的值。這個範例使用 fields 查詢參數,只納入您要查看的欄位。
GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting
將 PROJECT_ID 替換為專案 ID。
vmDnsSetting 的值表示專案是否預設使用全域 DNS。
GLOBAL_DEFAULT:專案已啟用全域 DNS。ZONAL_ONLY:專案已啟用區域性 DNS。這個專案不需要遷移。
專案遷移檢查清單
請按照下列步驟操作,確保專案順利改用區域性 DNS:
- 檢查不相容的查詢:確認專案中與區域性 DNS 不相容的查詢數量為零。Compute Engine 會評估前 30 天的 DNS 查詢記錄,自動執行這項分析。如果記錄評估結果指出有不相容的查詢,請先按照 Logs Explorer 中的說明解決問題,再繼續操作。
- 查看專案相容性指南:確認環境沒有基礎架構依附元件 (例如特定 Linux 作業系統版本),以免遷移後影響專案。詳情請參閱專案相容性指南。
- 改用區域性 DNS:套用設定變更 或更新 Terraform 檔案,以遷移專案。
- 遷移後驗證:改用區域性 DNS 後,請監控應用程式,並確認所有內部 DNS 查詢都能正確解析。
使用查詢分析判斷專案的遷移準備度
為評估專案是否能遷移至可用區 DNS,而不需變更程式碼或全域 DNS 的使用方式, Google Cloud 會分析您的 DNS 查詢記錄。這項分析會提供下列指標,指出專案與可用區 DNS 的相容性:
zonal_dns_ready(相容的查詢):這項指標代表 100 天內可使用區域性 DNS 成功解析的查詢總數。zonal_dns_risky(不相容的查詢或遷移後可能失敗的查詢):這項指標代表無法使用區域性 DNS 解析的查詢總數。這類查詢通常涉及跨區域通訊或其他區域解析失敗的情況。請務必注意,如果這項指標的值不為零,表示專案尚未準備好遷移。您必須先解決這些不相容的查詢,才能切換至可用區 DNS。
如要查看這些指標,請使用 Google Cloud 控制台中的 Metrics Explorer。
-
前往 Google Cloud 控制台的 leaderboard「指標探索器」頁面:
如果您是使用搜尋列尋找這個頁面,請選取子標題為「Monitoring」的結果。
在包含「選取指標」欄位的工具列右側,按一下「程式碼編輯器」、「MQL」或「PromQL」。
如果查詢輸入欄位不是標題為「PromQL 查詢」,請選取「語言」的「PromQL」。
在查詢輸入欄位中,輸入下列文字 (請務必完全相同):
increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])按一下 [Run query] (執行查詢) 按鈕。
Google Cloud 控制台會顯示這兩項指標 (
zonal_dns_ready和zonal_dns_risky) 的圖表,以及每項指標在該時間範圍內發出的查詢數量。
檢查
zonal_dns_risky指標的值。- 如果值為
0,表示專案已準備好遷移至可用區 DNS。您可以遷移專案,詳情請參閱「遷移已準備好使用區域性 DNS 的專案」。 - 如果值為非零數字 (例如上一個螢幕截圖中的
0.02k),則在遷移至區域 DNS 後,部分查詢可能無法運作。專案尚未準備好遷移。繼續按照「修正不相容的查詢」中的步驟操作。
- 如果值為
遷移與區域性 DNS 相容的專案
如要為執行個體啟用區域性 DNS,請為專案設定 vmDnsSetting 中繼資料項目。
設定這項中繼資料項目後,運算執行個體會:
- 使用搜尋路徑時,只能透過分區 DNS 名稱 (
INSTANCE_NAME.ZONE.c.PROJECT_ID.internal) 存取。 - 保留區域和全域搜尋路徑,但不再使用全域 DNS 名稱,因為全域 DNS 名稱不包含內部 DNS 名稱的 ZONE。
- 只能使用全域 DNS 名稱存取相同區域和專案中的其他執行個體。
操作步驟如下:
使用 Google Cloud 控制台、gcloud CLI 或 REST,變更專案的
vmDnsSetting中繼資料項目。控制台
如要在專案層級更新設定,請前往 Google Cloud 控制台的 Compute Engine「Metadata」(中繼資料) 頁面。
按一下「Edit」(編輯)。
如果存在值為
VmDnsSetting的鍵,請將其值變更為ZonalOnly。如果沒有值為
VmDnsSetting的鍵,請按一下 「Add item」(新增項目)。- 在「Key」(金鑰) 欄位中輸入
vmDnsSetting。 - 在「值」欄位中輸入
ZonalOnly。
- 在「Key」(金鑰) 欄位中輸入
如要完成修改自訂中繼資料項目,請按一下「Save」(儲存)。
gcloud
如要更新目前專案的中繼資料設定,請使用
project-info add-metadata指令。gcloud compute project-info add-metadata \ --metadata vmDnsSetting=ZonalOnly選用:如要驗證專案的中繼資料設定,請使用下列指令:
gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"將 PROJECT_ID 替換為要查詢的專案名稱。
REST
如要更新專案層級的中繼資料設定,請使用 projects.setCommonInstanceMetadata 方法建構
POST要求。選用:如要執行樂觀鎖定,可以視需要提供指紋。
指紋是由 Compute Engine 產生的隨機字元字串。每次要求後指紋都會變更,如果提供的指紋不符,系統就會拒絕要求。
如未提供指紋,系統就不會執行一致性檢查,且
projects.setCommonInstanceMetadata要求會成功。如果您使用instances.setMetadata方法,則一律需要指紋。如要取得專案目前的指紋,請呼叫
project.get方法。GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
輸出結果會與下列內容相似:
{ "name": "myproject", "commonInstanceMetadata": { "kind": "compute#metadata", "fingerprint": "FikclA7UBC0=", ... } }建構對
projects.setCommonInstanceMetadata方法的POST要求,設定中繼資料鍵/值組合:POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata { "fingerprint": "FikclA7UBC0=", "items": [ { "key": "vmDnsSetting", "value": "ZonalOnly" } ] }將
PROJECT_ID替換為專案 ID。
Terraform
如要使用 Terraform 更新專案的中繼資料設定,請在設定中加入下列
google_compute_project_metadata_item資源區塊:resource "google_compute_project_metadata_item" "vmdnssetting" { key = "VmDnsSetting" project = "MyProject" value = "ZonalOnly" }為專案設定
vmDnsSetting中繼資料項目後,請重新整理該專案中每個執行個體的 DHCP 租用期。你可以使用下列其中一種方法重新整理租約:- 重新啟動執行個體
- 等待租約到期
執行下列其中一個指令:
Linux 執行個體
sudo dhclient -v -rWindows 執行個體
ipconfig /renew
修正不相容的查詢
如果專案尚未準備好遷移,表示在過去 30 天內,至少有一項 DNS 查詢不相容。不相容的查詢可能具有下列屬性:
- 呼叫其他專案中的運算執行個體。
- 呼叫其他區域的運算執行個體。
不相容的 DNS 查詢可能會導致您無法遷移至區域性 DNS,因此請務必先修正這些查詢,再將專案遷移至區域性 DNS。
如要修正所有不相容的查詢,建議您在查詢中使用來源運算執行個體的可用區完整網域名稱 (FQDN)。這樣一來,將專案遷移至使用區域性 DNS 後,查詢解析作業就不會中斷。
如要解決不相容的查詢,請按照下列步驟操作:
使用 Logs Explorer 存取及查詢專案中所有運算執行個體的全域 DNS 用量。
選取要改用可用區 DNS 的專案。
套用資源和記錄檔名稱篩選器:
- 按一下「所有資源」。
- 在「選取資源」對話方塊中,選取「VM 執行個體」,然後按一下「套用」。
- 在「欄位」面板的「嚴重程度」部分,選取「偵錯」。
- 按一下「所有記錄名稱」。
在「選取記錄檔名稱」對話方塊中,選取「gdnsusage」,然後按一下「套用」。
替代查詢
或者,您可以在查詢欄位中輸入下列內容:
resource.type='gce_instance' log_name='projects/PROJECT_ID/logs/compute.googleapis.com/gdnsusage'
在「查詢結果」窗格中,每項查詢都有
jsonPayload欄位。每個jsonPayload欄位都包含下列資訊:- 來源運算執行個體名稱、專案 ID 和可用區名稱。
- 目的地運算執行個體名稱、專案 ID 和可用區名稱。
偵錯訊息,提供如何更新無法使用區域性 DNS 名稱解析的全域 DNS 查詢資訊。這些查詢會阻礙遷移作業,請務必偵錯並修正。
"To use Zonal DNS, update the Global DNS query sent from the source VM INSTANCE_NAME.c.PROJECT_ID.internal to the following zonal FQDN: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal"
查詢計數,顯示來源運算執行個體當天傳送至目的地運算執行個體的遷移作業封鎖查詢數量。
下方的螢幕截圖顯示 Logs Explorer 控制台頁面中的
jsonPayload欄位資訊。
使用上一個步驟中取得的
jsonPayload資訊,判斷要使用哪個 FQDN 手動更新全域 DNS 查詢,改用可用區 DNS,並準備好專案以進行遷移。更新 FQDN 和解決相容性問題最常見的用途如下:- 中繼資料伺服器的內部 DNS 名稱:遷移至可用區 DNS 後,傳回的 DNS 名稱會立即變更為可用區 FQDN,因此您不需採取任何行動。如果 DNS 名稱已快取,您只需要再發出一次呼叫,即可更新快取值。
- 用於存取其他區域中 VM 的內部 DNS 名稱:如果您有應用程式使用不同區域中 VM 的內部 DNS 名稱,可以修改 DHCP 政策或設定檔,加入其他區域的區域。
- 硬式編碼全域 FQDN:如果應用程式使用硬式編碼全域 FQDN 名稱來識別運算執行個體,您可以更新應用程式中的呼叫,改用內部 DNS 名稱或可用區 FQDN。您可以透過程式碼變更或 Terraform 中的設定變更進行這項變更。
- 使用 Shared VPC 網路的服務專案中的 VM:如要解析使用 Shared VPC 網路的服務專案中 VM 的 DNS 名稱,必須使用 VM 的區域 FQDN。
將全域 DNS 查詢更新為使用區域性 DNS 後,請執行下列操作:
使用「Logs Explorer」頁面再次查詢全域 DNS 用量。修正所有封鎖的全域 DNS 查詢後,查詢結果中就不會顯示任何偵錯記錄檔。
重新檢查監控指標,確認所有不相容的 DNS 查詢都已移除。
在 Logs Explorer 中查看全域 DNS 記錄
Logs Explorer 主要會顯示專案的全域 DNS 記錄,其中包含與區域性 DNS 不相容的查詢。這些記錄有助於在遷移前找出並分析有問題的查詢。
您也可以在 Logs Explorer 中,對這些不相容的查詢執行下列操作:
檢查改用區域性 DNS 是否會影響專案
遷移至區域 DNS 後,請務必確認應用程式和服務仍可正常運作。由於區域 DNS 會改變內部 DNS 名稱的解析方式,如果某些應用程式依賴全域 DNS 名稱,可能會發生問題。
以下各節說明如何檢查潛在影響及解決方法:
指令列執行個體通訊
工作:使用 gcloud CLI 從一個執行個體 Ping 另一個執行個體。
gcloud compute ssh INSTANCE-A --command "ping INSTANCE-B"潛在錯誤:「無法解析主機」:這表示
INSTANCE-A找不到INSTANCE-B的 IP 位址。解決方法:將用於
INSTANCE-B的主機名稱更新為完整網域名稱 (FQDN),包括區域名稱:INSTANCE_NAME.ZONE.c.PROJECT_ID.internalCompute Engine 服務內的執行個體通訊
工作:如果您為代管執行個體群組 (MIG) 使用健康狀態檢查,且該群組依賴內部 DNS 名稱,請檢查健康狀態檢查是否通過。
潛在錯誤:「健康狀態檢查失敗」:這表示健康狀態檢查因 DNS 解析問題而無法連線至目標。
解決方法:確認健康狀態檢查使用目標執行個體的 FQDN,包括可用區名稱。
特定應用程式的用途
許多應用程式都依賴內部 DNS 執行下列工作:
- 連線至資料庫 (例如 Cloud SQL)
與訊息佇列互動 (例如 Pub/Sub)
潛在錯誤:這些錯誤會因應用程式而異,但可能包括:
- 「無法連線至『SERVICE_NAME』」
- 「連線逾時」
- 「No such host is known」(找不到這類主機)
解決方法:檢查應用程式的設定,確保參照服務時使用 FQDN (包括區域名稱)。
排解從全域 DNS 遷移至區域性 DNS 的程序問題
如果遷移程序發生問題,請參閱疑難排解指南。
還原為使用全域 DNS
如要復原遷移至區域性 DNS 的作業,請將預設內部 DNS 類型改回全域 DNS。您可以在組織、專案、執行個體或容器層級執行這項操作。
將專案改回使用全域 DNS
如要將專案還原為使用全域 DNS,請完成下列步驟。
將下列內容新增至專案的中繼資料:
vmDnsSetting=GlobalDefault。如要瞭解如何設定專案中繼資料值,請參閱「設定及移除自訂中繼資料」。
確認專案中的任何執行個體都沒有將
vmDnsSetting中繼資料值設為ZonalOnly。gcloud compute instances describe INSTANCE_NAME --flatten="metadata.items[]"將 INSTANCE_NAME 替換為要檢查的執行個體名稱。
在每個執行個體上重新整理 DHCP 租約。如要重新整理租約,可以重新啟動執行個體、等待租約到期,或在客體作業系統中執行下列任一指令:
- Linux 執行個體:
sudo dhclient -v -r - Windows Server 執行個體:
ipconfig /renew
- Linux 執行個體:
還原執行個體的全域 DNS
如要將特定執行個體還原為使用全域 DNS,請完成下列步驟。
更新執行個體的中繼資料,加入
vmDnsSetting=GlobalDefault。如要瞭解如何設定運算執行個體中繼資料值,請參閱「設定及移除自訂中繼資料」。
如要強制變更 DNS 設定,請使用下列任一指令重新啟動執行個體的網路:
如果是 Container-Optimized OS 或 Ubuntu:
sudo systemctl restart systemd-networkd如果是 CentOS、RedHat EL、Fedora CoreOS 或 Rocky Linux:
sudo systemctl restart network或
sudo systemctl restart NetworkManager.serviceDebian:
sudo systemctl restart networking如果是 Linux 系統,請使用
nmcli:sudo nmcli networking off sudo nmcli networking onWindows 系統:
ipconfig /renew
改回使用容器的全域 DNS
如果您在容器、Google Kubernetes Engine 或 App Engine 彈性環境中執行應用程式或工作負載,容器設定中的 DNS 設定可能不會自動更新,直到您重新啟動容器為止。如要停用這些容器應用程式的可用區 DNS,請完成下列步驟。
在擁有容器和運算執行個體的專案中,將專案中繼資料設定
vmDnsSetting設為GlobalDefault。重新啟動容器,將 DNS 設定還原為原始狀態。
後續步驟
- 如要瞭解機構、資料夾和專案之間的關係,請參閱Google Cloud 資源階層。
- 進一步瞭解 Compute Engine 的內部 DNS。