將專案遷移至區域性 DNS

本文說明如何將現有專案從全域 DNS 遷移至區域性 DNS。區域性 DNS 可隔離區域內的服務中斷情形，防止執行個體建立和自動修復等重要服務受到影響，進而提升可靠性。

事前準備

• 如果尚未設定驗證，請先完成設定。 驗證可確認您的身分，以便存取 Cloud de Confiance by S3NS 服務和 API。如要從本機開發環境執行程式碼或範例，請選取下列其中一個選項，向 Compute Engine 進行驗證：

  選取這個頁面上您打算如何使用範例的分頁：

  控制台

  使用 Cloud de Confiance 控制台存取 Cloud de Confiance by S3NS 服務和 API 時，無須設定驗證。

  gcloud

  1. 安裝 Google Cloud CLI，然後 使用聯合身分登入 gcloud CLI。登入後，執行下列指令來初始化 Google Cloud CLI：

     gcloud init

• 設定預設地區和區域。

REST

如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

安裝 Google Cloud CLI，然後 使用聯合身分登入 gcloud CLI。

詳情請參閱 Cloud de Confiance 驗證說明文件中的「使用 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 Engine 專案中啟用 Cloud DNS 查詢記錄。您可以利用記錄監控及比較遷移至可用區內部 DNS 前後的內部 DNS 失敗率。Google 建議您在遷移前至少 24 小時啟用 DNS 查詢記錄，建立遷移前基準。

在 DNS 查詢記錄中收集足夠資料後，即可執行區域性 DNS 遷移作業。您可以在遷移期間監控 DNS 解析率，確保遷移作業不會導致 DNS 查詢失敗次數增加。

如要瞭解 DNS 查詢監控的費用，請參閱「Cloud DNS 查詢記錄的定價資訊」。

檢查專案是否預設使用全域 DNS

檢查專案，確認是否需要從全域 DNS 遷移至區域性 DNS。您只需要遷移設為使用全域 DNS 的專案，做為專案內建立任何內部 DNS 名稱的預設值。

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

專案遷移工作檢查清單

請按照下列步驟操作，確保專案順利改用區域性 DNS：

• 檢查不相容的查詢：確認專案中與區域性 DNS 不相容的查詢數量為零。Compute Engine 會評估前 30 天的 DNS 查詢記錄，自動執行這項分析。如果記錄評估結果指出有不相容的查詢，請先按照 Logs Explorer 中的說明解決問題，再繼續操作。
• 查看專案相容性指南：確認環境沒有底層架構依附元件 (例如特定 Linux 作業系統版本)，以免遷移後影響專案。詳情請參閱「專案相容性指南」。
• 改用區域性 DNS：套用設定變更或更新 Terraform 檔案，即可遷移專案。
• 遷移後驗證：切換為使用區域性 DNS 後，請監控應用程式，並確認所有內部 DNS 查詢都能正確解析。

使用查詢分析判斷專案是否已準備好遷移

如要評估專案是否能遷移至可用區 DNS，且不必變更程式碼或全域 DNS 的使用方式， Cloud de Confiance by S3NS 會分析您的 DNS 查詢記錄。這項分析會提供下列指標，指出專案與區域性 DNS 的相容性：

• zonal_dns_ready (相容查詢)：這項指標代表 100 天內可使用區域性 DNS 成功解析的查詢總數。

• zonal_dns_risky (不相容的查詢或遷移後可能失敗的查詢)：這個指標代表無法使用區域性 DNS 解析的查詢總數。這類查詢通常涉及跨區域通訊，或區域解析失敗的其他情境。請務必注意，如果這項指標的值不是零，表示專案尚未準備好進行遷移。您必須先解決這些不相容的查詢，才能改用區域性 DNS。

如要查看這些指標，請使用 Cloud de Confiance 控制台中的 Metrics Explorer。

1. 前往 Cloud de Confiance 控制台的 leaderboard「指標探索器」頁面：

   前往 Metrics Explorer

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

2. 在包含「選取指標」 欄位的工具列右側，按一下「程式碼編輯器」、「MQL」或「PromQL」。

3. 如果查詢輸入欄位不是標題為「PromQL 查詢」，請選取「語言」的「PromQL」。

4. 在查詢輸入欄位中，輸入下列文字 (請務必完全相同)：

   increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])
   

5. 按一下 [Run query] (執行查詢) 按鈕。

   Cloud de Confiance 控制台會顯示這兩項指標 (zonal_dns_ready 和 zonal_dns_risky) 的圖表，以及每個指標在該時間範圍內發出的查詢數量。

   

6. 檢查 zonal_dns_risky 指標的值。

   • 如果值為 0，代表專案已準備好遷移至區域 DNS。您可以遷移專案，詳情請參閱「遷移已準備好使用區域性 DNS 的專案」。
   • 如果值為非零數字 (例如上一個螢幕截圖中顯示的 0.02k)，則在遷移至區域性 DNS 後，部分查詢可能無法運作。專案尚未準備好遷移。 繼續按照「修正不相容的查詢」中的步驟操作。

遷移與區域性 DNS 相容的專案

為專案設定 vmDnsSetting 中繼資料項目，即可為執行個體啟用區域 DNS。

設定這個中繼資料項目後，運算執行個體會：

• 使用搜尋路徑時，只能透過區域 DNS 名稱 (INSTANCE_NAME.ZONE.c.PROJECT_ID.internal) 存取。
• 保留區域和全域搜尋路徑，但全域 DNS 名稱 (不含內部 DNS 名稱中的 ZONE) 則停止運作。
• 只能使用全域 DNS 名稱存取相同區域和專案中的其他執行個體。

操作步驟如下：

1. 使用 Cloud de Confiance 控制台、gcloud CLI 或 REST，變更專案的 vmDnsSetting 中繼資料項目。

   控制台

   1. 如要在專案層級更新設定，請在 Cloud de Confiance 控制台中前往 Compute Engine 的「Metadata」(中繼資料) 頁面。

      前往「Custom metadata」(自訂中繼資料) 頁面

   2. 按一下「Edit」(編輯)edit。

   3. 如果存在值為 VmDnsSetting 的鍵，請將其值變更為 ZonalOnly。

   4. 如果沒有值為 VmDnsSetting 的鍵，請按一下「新增項目」add_box。

      • 在「Key」(金鑰) 欄位中，輸入 VmDnsSetting。
      • 在「Value」(值) 欄位中，輸入 ZonalOnly。

   5. 如要完成修改自訂中繼資料項目，請按一下「儲存」。

   gcloud

   1. 如要更新目前專案的中繼資料設定，請使用 project-info add-metadata 指令。

      gcloud compute project-info add-metadata \
           --metadata vmDnsSetting=ZonalOnly
      

   2. 選用：如要驗證專案的中繼資料設定，請使用下列指令：

      gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
      

      將 PROJECT_ID 替換為要查詢的專案名稱。

   REST

   如要在專案層級更新中繼資料設定，請使用 projects.setCommonInstanceMetadata 方法建構 POST 要求。

   1. 選用：如要執行樂觀鎖定，可以視需要提供指紋。

      指紋是由 Compute Engine 產生的隨機字元字串，指紋會在每次要求後變更；如果您提供的指紋不符，系統便會拒絕您的要求。

      如果您未提供指紋，系統就不會執行一致性檢查，projects.setCommonInstanceMetadata 要求也會成功。如果您使用 instances.setMetadata 方法，則一律需要指紋。

      如要取得專案的目前指紋，請呼叫 project.get 方法。

      GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID
      

      輸出結果會與下列內容相似：

      {
        "name": "myproject",
        "commonInstanceMetadata": {
            "kind": "compute#metadata",
            "fingerprint": "FikclA7UBC0=",
            ...
        }
      }
      

   2. 建構對 projects.setCommonInstanceMetadata 方法的 POST 要求，設定中繼資料鍵/值組合：

      POST https://compute.s3nsapis.fr/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"
   }
   

2. 為專案設定 vmDnsSetting 中繼資料項目後，請更新該專案中每個執行個體的 DHCP 租約。你可以使用下列其中一種方法重新整理租約：

   • 重新啟動執行個體
   • 等待租約到期

   • 執行下列其中一個指令：

     Linux 執行個體

     sudo dhclient -v -r
     

     Windows 執行個體

     ipconfig /renew
     

3. 確認專案使用區域性 DNS。

修正不相容的查詢

如果專案尚未準備好遷移，表示在過去 30 天內，至少有一項 DNS 查詢不相容。不相容的查詢可能具有下列屬性：

• 呼叫其他專案中的運算執行個體。
• 呼叫其他區域的運算執行個體。

不相容的 DNS 查詢可能會導致您無法遷移至區域性 DNS，因此請務必先修正這些查詢，再將專案遷移至區域性 DNS。

如要修正所有不相容的查詢，建議您在查詢中使用來源運算執行個體的區域完整網域名稱 (FQDN)。這種做法可確保專案改用區域性 DNS 後，查詢解析作業不會中斷。

如要解決不相容的查詢，請按照下列步驟操作：

1. 使用 Logs Explorer 存取及查詢專案中所有運算執行個體的全域 DNS 用量。

   前往 Logs Explorer

2. 選取要遷移至區域性 DNS 的專案。

3. 套用資源和記錄名稱篩選器：

   1. 按一下「所有資源」。
   2. 在「選取資源」對話方塊中，選取「VM 執行個體」，然後按一下「套用」。
   3. 在「欄位」面板的「嚴重程度」部分，選取「偵錯」。
   4. 按一下「所有記錄名稱」。

   5. 在「選取記錄檔名稱」對話方塊中，選取「gdnsusage」，然後按一下「套用」。

      替代查詢

      或者，您也可以在查詢欄位中輸入下列內容：

       resource.type='gce_instance'
       log_name='projects/PROJECT_ID/logs/compute.googleapis.com/gdnsusage'
      

4. 在「查詢結果」窗格中，每個查詢都有 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 欄位資訊。

   

5. 使用上一個步驟中取得的 jsonPayload 資訊，判斷要使用哪個 FQDN 手動更新全域 DNS 查詢，改用區域性 DNS，並準備好專案以進行遷移。以下是更新 FQDN 和解決相容性問題最常見的用途：

   • 中繼資料伺服器的內部 DNS 名稱：不需要採取任何行動，因為遷移至區域 DNS 後，傳回的 DNS 名稱會立即變更為區域 FQDN。如果 DNS 名稱已快取，您只需要再發出一次呼叫，即可更新快取值。
   • 用於存取其他區域中 VM 的內部 DNS 名稱：如果應用程式使用不同區域中 VM 的內部 DNS 名稱，您可以修改 DHCP 政策或設定檔，將其他區域納入其中。
   • 硬式編碼全域 FQDN：如果應用程式使用硬式編碼全域 FQDN 名稱做為運算執行個體，您可以更新應用程式中的呼叫，改為使用內部 DNS 名稱或區域 FQDN。您可以透過程式碼變更或 Terraform 中的設定變更進行這項變更。
   • 使用共用虛擬私人雲端網路的服務專案中的 VM：如要解析使用共用虛擬私人雲端網路的服務專案中 VM 的 DNS 名稱，您必須使用 VM 的區域 FQDN。

6. 將全域 DNS 查詢更新為使用可用區 DNS 後，請執行下列操作：

   1. 使用 Logs Explorer 頁面再次查詢全域 DNS 用量。修正所有會封鎖全域 DNS 查詢的問題後，查詢結果中就不會再顯示任何偵錯記錄。

   2. 重新檢查監控指標，確認所有不相容的 DNS 查詢都已移除。

在記錄檔探索工具中查看全域 DNS 記錄

如果專案的查詢不相容於區域性 DNS，記錄檔探索工具主要會顯示專案的全域 DNS 記錄。這些記錄有助於在遷移前找出並分析有問題的查詢。

您也可以使用 Logs Explorer 處理這些不相容的查詢，執行下列操作：

• 建立資訊主頁：以視覺化方式呈現不相容的全域 DNS 查詢模式，深入瞭解應用程式的通訊行為。
• 匯總記錄：分析整個機構的 DNS 記錄，找出更廣泛的趨勢和可能需要改進之處。

檢查區域性 DNS 異動是否影響專案

遷移至區域 DNS 後，請務必確認應用程式和服務仍可正常運作。由於區域 DNS 會變更內部 DNS 名稱的解析方式，如果某些應用程式依賴全域 DNS 名稱，可能會發生問題。

下節將說明如何檢查潛在影響及解決問題：

1. 指令列執行個體通訊

   工作：使用 gcloud CLI 從一個執行個體 Ping 另一個執行個體。

   gcloud compute ssh INSTANCE-A --command "ping INSTANCE-B"
   

   潛在錯誤：「Could not resolve host」(無法解析主機) - 這表示 INSTANCE-A 無法找到 INSTANCE-B 的 IP 位址。

   解決方法：將用於 INSTANCE-B 的主機名稱更新為完整網域名稱 (FQDN)，包括區域名稱： INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

2. Compute Engine 服務內的執行個體通訊

   工作：如果您使用健康狀態檢查來檢查代管執行個體群組 (MIG)，且該群組依賴內部 DNS 名稱，請檢查健康狀態檢查是否通過。

   可能發生的錯誤：「健康狀態檢查失敗」：這表示健康狀態檢查因 DNS 解析問題而無法連上目標。

   解決方法：請確認健康狀態檢查使用目標執行個體的 FQDN，包括區域名稱。

3. 特定應用程式的用途

   許多應用程式會依賴內部 DNS 執行下列工作：

   • 連線至資料庫 (例如 Cloud SQL)

   • 與訊息佇列互動 (例如 Pub/Sub)

   • 潛在錯誤：這些錯誤因應用程式而異，但可能包括：

     • 「無法連線至『SERVICE_NAME』」
     • 「連線逾時」
     • 「No such host is known」(找不到這類主機)

   • 解決方法：檢查應用程式的設定，確認參照服務時使用的是 FQDN (包括區域名稱)。

排解全域 DNS 遷移至區域性 DNS 的程序問題

如果遷移程序發生問題，請參閱疑難排解指南。

還原為使用全域 DNS

如要復原遷移至區域性 DNS 的作業，請將預設內部 DNS 類型改回全域 DNS。您可以在機構、專案、執行個體或容器層級執行這項操作。

將專案還原為使用全域 DNS

如要將專案還原為使用全域 DNS，請完成下列步驟。

1. 在專案的中繼資料中新增以下內容：vmDnsSetting=GlobalDefault。

   如要瞭解如何設定專案中繼資料值，請參閱「設定及移除自訂中繼資料」。

2. 確認專案中的任何執行個體，都沒有將 vmDnsSetting 中繼資料值設為 ZonalOnly。

   gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"
   

   將 INSTANCE_NAME 替換為要檢查的執行個體名稱。

3. 更新每個執行個體上的 DHCP 租約。您可以透過重新啟動執行個體、等待租約到期，或在訪客作業系統中執行下列其中一個指令來更新租約：

   • Linux 執行個體：sudo dhclient -v -r
   • Windows Server 執行個體：ipconfig /renew

將執行個體還原為使用全域 DNS

如要將特定執行個體還原為使用全域 DNS，請完成下列步驟。

1. 更新執行個體的中繼資料，加入 vmDnsSetting=GlobalDefault。

   如要瞭解如何設定 Compute 執行個體中繼資料值，請參閱設定及移除自訂中繼資料。

2. 如要強制變更 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.service
     

   • Debian：

     sudo systemctl restart networking
     

   • 適用於搭載 nmcli 的 Linux 系統：

     sudo nmcli networking off
     sudo nmcli networking on
     

   • Windows 系統：

     ipconfig /renew
     

還原為使用容器的全域 DNS

如果您在 Google Kubernetes Engine 或 App Engine 彈性環境的容器中執行應用程式或工作負載，則在重新啟動容器之前，系統不會自動更新容器設定中的 DNS 設定。如要停用這些容器應用程式的區域 DNS，請完成下列步驟。

1. 在擁有容器和 Compute 執行個體的專案中，將專案中繼資料設定 vmDnsSetting 設為 GlobalDefault。

2. 重新啟動容器，讓 DNS 設定還原成原始狀態。

後續步驟

• 如要瞭解機構、資料夾和專案之間的關係，請參閱Cloud de Confiance by S3NS 資源階層。
• 進一步瞭解 Compute Engine 的內部 DNS。