高可用性とディザスタリカバリを理解する DNS Services

高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。サービスについては、可用性はサービスレベル契約で定義されています。可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。高可用性の主な目的は、IT インフラストラクチャー内の潜在的な障害点を除去することです。ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。これには、インストールされたシステムの重要なデータを安全な場所にコピーして保存する手順と、そのデータを復旧して正常な動作を復元する手順が含まれる。

DNS Services は、スタンダードプランでサービスレベル目標（SLO）を満たすように設計されています。 DNS Services は可用性の高いグローバルサービスであり、耐障害性を高めるために障害ドメインを分けて設計されている。制御プレーンはゾーン障害と地域障害の両方に強く、その障害はデータプレーンには影響しない。データ・プレーンは少なくともゾーン障害に強く、その障害はコントロール・プレーンには影響しない。

DNS Services の展開地域とデータセンターのロケーションの詳細については、ロケーション別のサービスとインフラの可用性を参照してください。

高可用性アーキテクチャ

コントロール・プレーン

IBM Cloud® DNS Services はグローバルに利用可能な（GA）サービスである。 DNSコンフィギュレーション用のパブリックAPIエンドポイントは、 IBM Cloud の2つのマルチゾーン・リージョンフォールトトレランスを向上させるために、複数のゾーンの物理的な場所にまたがるリージョン。（MZR）に配置されたグローバルなロードバランサーを介して利用可能で、高い可用性を保証している。これらの地域はダラスとワシントンDCである。あるリージョンで障害が発生した場合、グローバルロードバランサーはAPIトラフィックを自動的に他のリージョンにルーティングする。たとえば、ダラス地域が利用できない場合、リクエストは他の利用可能な地域（この場合はワシントンDC）にリダイレクトされる。

グローバル障害が発生した場合、制御プレーンはリソースのデータ損失を減らすことに重点を置いて復旧される。したがって、顧客はディザスタリカバリの計画も立てるべきである。

コントロールプレーンはユーザー主導の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)

データプレーン・カスタム・リゾルバー

カスタム・リゾルバは、ゾーンをまたがるサブネット上に設定されたゾーン・オブジェクト（カスタム・リゾルバの場所）で構成される地域オブジェクトである。ベスト・プラクティスは、高可用性を確保するために、カスタム・リゾルバーを複数のサブネットにデプロイすることです。 3 つのアベイラビリティー・ゾーンすべてにデプロイすることをお勧めします。

地域に障害が発生した場合、データプレーンのこの側面は、コントロールプレーンで表現され、永続化されたリソースの状態に復元される。

高可用性機能

DNS Services は以下の高可用性機能をサポートしている：

HA機能 DNS Services
特長	説明	考慮事項
カスタム・リゾルバ・ロケーション	カスタムリゾルバの配置場所を管理する。	ゾーン故障に対する回復力を高めるだけだ。

ITインフラ内のさまざまなレベル、およびDNSクラスタのさまざまなコンポーネントで高可用性を実現できます。お客様に適した可用性のレベルは、ビジネス要件、顧客とのサービス・レベル・アグリーメント（SLA）、およびお客様が費やすリソースなど、いくつかの要因によって決まります。

クラスタに設定する可用性のレベルは、 IBM Cloud の高可用性 SLA 条件の適用範囲に影響します。

サービス・レベル目標（SLO）は、 IBM Cloud サービスが満たすように設計された設計ポイントを定義する。 IBM Cloud® DNS Services は、以下の可用性目標を満たすように設計されている。

のSLO DNS Services
可用性目標	ターゲット値
可用性 %	99.999%

SLOは保証ではなく、 IBM、目標を達成できなかったからといって単位を発行することはない。約束した SLA を満たせなかった場合に発行されるコミットメントとクレジットについては、SLA を参照してください。すべてのSLOの概要については、 IBM Cloud サービスレベル目標を参照のこと。

各リージョンおよびデータ・センターでのサービスの提供状況について詳しくは、ロケーション別のサービスおよびインフラストラクチャーの提供状況を参照してください。

IBM Cloud の高可用性とディザスタリカバリの基準については、 IBM Cloud How ensure high availability and disaster recovery をご覧ください。

災害復旧アーキテクチャ

DNS設定の外部記録を維持することは、災害時に DNS Services。バックアップとリストアの両方のプロセスは、スクリプトとディザスタリカバリ機能の表にあるエクスポートとインポートのプロセスを使用して自動化することができます。 DNS Services Terraformをサポートしており、ロケーションとパフォーマンスをパラメータ化してワークロードを定義するのに使用できる。顧客は IBM Cloud Schematics、Terraformスクリプトを構築・管理することができる。Terraformスクリプトは、災害時にリソースを利用可能な場所にリカバリするために使用できる。

ディザスターリカバリー機能

IBM Cloud® DNS Services は、以下のディザスタリカバリ機能をサポートしている：

特長	説明	考慮事項
DNSリソースレコードのエクスポート	ダッシュボードからゾーンのDNSレコードをテキストファイルにエクスポートします。	一度に1つのゾーンの DNSレコードだけをエクスポートする。ロードバランサやその他の DNS レコード以外のデータはエクスポートしません。
DNSリソースレコードのインポート	テキストファイル上のDNSレコードをダッシュボードからゾーンにインポートする。	DNSレコードをインポートする前にゾーンを再作成する必要があります。
真実の外部ソース	DNSゾーン、許可されたネットワーク、DNSリソースレコード、カスタムリゾルバ、カスタムリゾルバ転送ルールなど、Terraformスクリプト、シェルスクリプト、プログラムなど、顧客が管理する設定ファイルに取り込まれる。	お客様は、スクリプトまたはプログラムを作成し、災害時に使用できるように設定を永続化する必要があります。
バックアップとリストア	お客様が作成されたスクリプトを使用して、サービスインスタンスをバックアップします。	お客様はスクリプトを作成し、バックアップコピーをリカバリ時に使用できる場所に保存する必要があります。

DRの計画

お客様には、災害時にDNSサーバーの設定データを復旧する責任があります。ディザスターリカバリープランを確実に構築し、以下のような障害シナリオと解決策を検討する必要がある：

DRシナリオ DNS Services
失敗	解決方法
:NONE.	カスタムリゾルバについては、複数のロケーションに展開することで緩和 DNSサーバーについては、利用可能な最も近いアベイラビリティゾーンでクエリに応答することで緩和。
地域的な失敗	1つのアベイラビリティゾーンが復旧するまで、カスタムリゾルバが停止。 DNSサーバーでは、最も近い利用可能なリージョンからクエリーに応答することで緩和される。
データ破損	外部の真実のソースからサービス構成を復元する。

HAとDRの責任

HAとDRのプランを継続的にテストするのは、あなたの責任です。

ネットワーク接続の中断や短時間のサービス利用不能が発生する可能性があります。アプリケーションの高可用性を維持するために、アプリケーションのソースコードにクライアント可用性再試行ロジックが含まれていることを確認するのは、あなたの責任です。

各特徴に関連する以下のチェックリストを、計画の作成と実践に役立ててください。

カスタム・リゾルバー
- DNS ゾーンとリソース・レコード・データが正確であることを確認してください。
- DNSゾーンとリソースレコードのバックアップを定期的に取る。
- 高可用性を実現するには、カスタムリゾルバを最低2カ所で構成する。ベストプラクティスは、各アベイラビリティゾーンに1カ所ずつ設置することである。
- 複数のカスタム・リゾルバ・ロケーションを持つセカンダリー・ゾーンの正しい高可用性を確保するには、オンプレミス・リゾルバを構成して、作成されたすべてのカスタム・リゾルバ・ロケーションへのゾーン転送を許可する。

IBM Cloud DNS Services に関するお客様と IBM Cloud との間の責任の所有権について詳しくは、 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 DNS Services
サービスの要素	RPO	RTO
コントロール・プレーン	0	< 60秒未満
データ・プレーン	0	< 60秒未満
カスタム・リゾルバー	0	< 60秒未満
データベース・リカバリー	24 時間	8時間

IBM、サービス・インスタンスをリストアできない場合は、ディザスタ・リカバリ・アーキテクチャの説明に従ってサービスをリストアする必要があります。

IBM サービスの維持方法

すべてのアップグレードは、リカバリプランとロールバックプロセスを含む、 IBM サービスのベストプラクティスに従います。定期的なメンテナンスにより短時間の中断が発生する可能性があるが、クライアントの可用性再試行ロジックにより緩和される。 IBM は、不具合の最初の兆候でアップデートを元に戻します。

IBM は、計画されたすべてのメンテナンス活動について事前に通知する。変更が業務量に影響すると予想される場合、 IBM、公式通知を通じてこれを伝えます。メンテナンス、サービスアナウンス、その他の最新情報は、モニタリングの通知とステータスのページをご覧ください。