瞭解高可用性和災難復原的 DNS Services
高可用性服務或工作負載承受故障並根據某些預先定義的服務等級繼續提供處理能力的能力。 對於服務而言，可用性是在服務等級協議中定義的。 可用性包括計劃內和計劃外的事件，例如維護、故障和災難。 (HA) 是指服務在發生意外故障時仍能維持運作和存取的能力。 高可用性的主要目的是消除 IT 基礎架構中的潛在故障點。 災難復原服務或工作負載從罕見的重大事故和大規模故障（如服務中斷）中恢復的能力。 這包括影響整個區域的實體災難、資料庫損毀或對工作負載有貢獻的服務遺失。 其影響超出了高可用性設計的處理能力。是將服務實例還原到工作狀態的過程。 它包括複製已安裝系統的重要資料並將其儲存於安全位置，以及復原資料以恢復正常操作的程序。
DNS Services 是為了達到 服務水準目標(SLO) 而設計的標準計劃。 DNS Services 是高度可用的全球服務，以獨立的故障域架構，以加強復原能力。 控制平面對於區域和區域故障都具有彈性，其故障不會影響資料平面。 資料平面至少對區域故障具有彈性，其故障不會影響控制平面。
如需有關 DNS Services 部署區域和資料中心位置的詳細資訊，請參閱 依位置劃分的服務和基礎結構可用性。
高可用性架構
控制平面
IBM Cloud® DNS Services 是全球可用 (GA) 服務。 其 DNS 設定的公共 API 端點可透過部署在 IBM Cloud 的兩個 多區域分散在多個區域中實體位置的區域，以提高容錯能力。 (MZR) 的全球負載平衡器來使用，以確保高可用性。 這些地區是達拉斯和華盛頓特區。 如果其中一個區域發生故障，全局負載平衡器會自動將 API 流量路由到另一個區域。 例如，如果達拉斯地區不可用，請求會被重定向到其他可用的地理區域 - 本例中為華盛頓特區。
在發生全局故障時，控制平面會以減少資源的資料遺失為重點進行還原。 因此，客戶也應該為災難復原做好規劃。
控制平面處理使用者啟動的 DNS 配置請求，而資料平面則處理虛擬私有雲 (VPC) 的名稱解析請求。
資料平面 DNS 伺服器
DNS 伺服器 分佈在全球多個 MZR，並使用任意播送 IP 位址來優化延遲和確保高可用性。 如果可用區域或整個區域發生中斷，DNS 查詢會自動路由到最近的可用區域或區域。 DNS 資料會複製到下列區域，以支援延遲最佳化和高可用性：
- 達拉斯 (us-south)
- 華盛頓，D.C. (us-east)
- 倫敦 (eu-gb)
- 馬德里 (eu-es)
- 法蘭克福 (eu-de)
- 大阪 (jp-osa)
- 東京 (jp-tok)
- 多倫多 (ca-tor)
- 雪梨 (au-syd)
- 聖保羅 (br-sao)
資料平面自訂解析器
自訂解析器是由配置在跨區域子網路上的區域物件 (自訂解析器位置) 所組成的區域物件。 最佳作法是將自訂解析器部署至多個子網路，以確保高可用性。 建議您在所有三個可用性區域中部署。
當出現區域故障時，資料平面的這一方面會還原為控制平面所代表和持久化的資源狀態。
高可用性功能
DNS Services 支援下列高可用性功能：
| 特性 | 說明 | 考量 |
|---|---|---|
| 自訂解析器位置 | 管理自訂解析器的部署位置。 | 只會增加區域故障的復原能力。 |
您可以在 IT 基礎架構內的不同層級，以及 DNS 群組的不同元件之間，達到高可用性。 適合您的可用性等級取決於幾個因素，包括您的業務需求、與客戶訂定的服務等級協定 (SLA)，以及您願意耗費的資源。
您為群集設定的可用性等級，會影響 IBM Cloud 高可用性 SLA 條款 的涵蓋範圍。
服務層級目標 (SLO) 定義了 IBM Cloud 服務在設計上要符合的設計點。IBM Cloud® DNS Services 在設計上要符合下列可用性目標。
| 可用性目標 | 目標值 |
|---|---|
| 可用性百分比 | 99.999% |
SLO 並非保證書，IBM 不會因未達到目標而給予學分。 請參閱 SLA 中的承諾以及因未能滿足任何承諾的 SLA 而發放的信用。 如需所有 SLO 的摘要，請參閱 IBM Cloud 服務層級目標。
如需更多關於區域和資料中心內服務可用性的資訊，請參閱 依地點劃分的服務和基礎結構可用性。
請參閱 IBM Cloud 如何確保高可用性和災難復原，以瞭解 IBM Cloud 中的高可用性和災難復原標準。
災難復原架構
維護 DNS 組態的外部記錄對於在發生災難時復原 DNS Services 非常重要。 備份和還原程序都可以使用腳本以及 災難復原功能 表中的匯出和匯入程序自動進行。 DNS Services 支持 Terraform，它可用于定义具有参数化位置和性能的工作负载。 客戶可使用 IBM Cloud Schematics 建置和管理 Terraform 指令碼，進而在災難發生時用於在可用位置復原資源。
災難復原功能
IBM Cloud® DNS Services 支援下列災難復原功能：
| 特性 | 說明 | 考量 |
|---|---|---|
| 匯出 DNS 資源記錄 | 透過儀表板將區域的 DNS 記錄匯出到文字檔。 | 一次只匯出一個區域的 DNS 記錄。 不會匯出負載平衡器或其他非 DNS 記錄資料。 |
| 匯入 DNS 資源記錄 | 透過儀表板將文字檔上的 DNS 記錄匯入區域。 | 需要在匯入 DNS 記錄前重新建立區域。 |
| 外部真相來源 | DNS 區域、允許的網路、DNS 資源記錄、自訂解析器、自訂解析器轉送規則，以及更多擷取於 Terraform 腳本、shell 腳本或程式等客戶管理的組態檔案。 | 客戶必須建立腳本或程式，並將組態保留在災難發生時可以使用的地方。 |
| 備份及還原 | 使用客戶撰寫的腳本備份服務實例。 | 客戶必須建立腳本，並將備份複本保留在復原時可以使用的地方。 |
DR 規劃
身為客戶，您有責任在發生災難時復原 DNS 伺服器組態資料。 您應該確保建立災難復原計畫，並考慮下列故障情況和解決方案：
| 失敗 | 解決方法 |
|---|---|
| 區域故障 | 透過部署到多個地點來緩解自訂解析器的問題 透過由最近的可用區回答查詢來緩解 DNS 伺服器的問題。 |
| 區域失敗 | 自訂解析器停機，直到一個可用性區域恢復為止。 對 DNS 伺服器而言，可透過由最近的可用區域回答查詢來緩解。 |
| 資料毀損 | 從外部真實來源還原服務組態。 |
您對 HA 和 DR 的責任
您有責任持續測試您的 HA 和 DR 計劃。
網路連線中斷和服務短暫無法使用的情況可能會發生。 您有責任確保應用程式原始碼包含 用戶端可用性重試邏輯，以維持應用程式的高可用性。
使用下列與每個特徵相關的核對表來幫助您建立和實踐您的計劃。
- 自訂解析器
如需更多關於您與 IBM Cloud 之間對 IBM Cloud DNS Services 的責任所有權的資訊，請參閱 使用 IBM Cloud DNS Services 時瞭解您的責任。
變更管理
變更管理包括任務，例如組態變更和刪除。
授予使用者和程序 Identity and Access Management (IAM) 角色和動作最少的工作權限。 如需詳細資訊，請參閱 如何防止意外刪除服務？
管理變革的最佳做法還包括：
- 透過維護變更日誌來計劃和記錄對 DNS Services 組態所做的任何修改。
- 在執行重大變更之前，建立關鍵組態的備份。
- 將影響較大的變更安排在人流較少的時段，並通知受影響的團隊。
- 監控您的 DNS Services 健康狀況和指標，以確保一切運作符合預期。
IBM 如何協助確保災難復原
IBM® 如果發生災難，，採取特定的復原行動。IBM Cloud® DNS Services
IBM 如何從區域故障中復原
IBM Cloud 有業務連續性企業能夠根據預先定義的服務水準合約，承受中斷並正常運作關鍵任務服務而不中斷。計劃，可在發生災難時於數小時內恢復服務。 您必須負責資料備份及相關內容的復原。
DNS Services 提供保護您的資料和恢復服務功能的機制。 業務連續性計畫已到位，以實現服務的目標 復原點目標在災難復原規劃中，還原資料的時間以時間 (秒、分、小時) 計算，從已復原的實體開始，到災難發生點為止。 (RPO) 和 復原時間目標在災難復原規劃中，災難發生後，業務程序恢復的時間長度。 (RTO)。 下表概述了 DNS Services 的目標。
| 服務要素 | RPO | RTO |
|---|---|---|
| 控制平面 | 0 | < 60 秒 |
| 資料平面 | 0 | < 60 秒 |
| 自訂解析器 | 0 | < 60 秒 |
| 資料庫回復 | 24 小時 | 8 小時 |
如果 IBM 無法還原服務實例，則必須按照 災難復原架構 中所述的方式還原服務。
如需更多關於區域和資料中心內服務可用性的資訊，請參閱 依地點劃分的服務和基礎結構可用性。
IBM 如何維護服務
所有升級都遵循 IBM 服務最佳實務，包括恢復計劃和回滾流程。 定期維護可能會造成短暫中斷，但 客戶端可用性重試邏輯 可減緩中斷情況。 IBM 會在缺陷出現的第一時間恢復更新。
IBM 預先通知所有計劃中的維護活動。 如果預期變更會影響您的工作量，IBM 會透過正式通知告知。 若要隨時更新維護、服務公告及其他更新，請參閱「監控通知與狀態」頁面。