IaaS の高可用性とディザスター リカバリー ソリューションを調べる
Azure for IaaS にデプロイできる機能には、さまざまな組み合わせがあります。 このセクションでは、Azure での SQL Server の高可用性とディザスター リカバリー (HADR) アーキテクチャの 5 つの一般的な例について説明します。
単一リージョンにおける高可用性の例 1 – 「Always On」可用性グループ
高可用性のみが必要で、ディザスター リカバリーが必要でない場合は、SQL Server を使用している場所に関係なく、(可用性グループ) AG の構成は最もユビキタスな方法の 1 つです。 次の図は、1 つのリージョンで考えられる 1 つの AG の例です。
このアーキテクチャを検討する価値があるのはなぜですか?
このアーキテクチャでは、異なる仮想マシン (VM) に複数のコピーを含めることでデータを保護します。
このアーキテクチャを使用すると、目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たすことができます。適切に実装されている場合、データ損失が最小限to-no されます。
このアーキテクチャでは、アプリケーションがプライマリ レプリカとセカンダリ レプリカの両方にアクセスするための、標準化された簡単な方法が提供されます。
このアーキテクチャでは、修正プログラムの適用シナリオ中の可用性が向上します。
このアーキテクチャでは共有ストレージは必要ないため、フェールオーバー クラスター インスタンス (FCI) を使用する場合よりも複雑性が低くなります。
単一リージョンの高可用性の例 2 - Always On フェールオーバー クラスター インスタンス
AG が導入されるまで、FCI は SQL Server の高可用性を実装するための最も一般的な方法でした。 ただし、FCI は、物理デプロイが優先されたときに設計されました。 仮想化された世界では、VM に問題が発生することはまれであるため、FCI は物理ハードウェアと同じように多くの保護を提供しません。 FCI は、ネットワーク カードの障害やディスクの障害などに対する保護を目的として設計されており、どちらも Azure では発生しない可能性があります。
しかし、FCI には Azure に場所があります。 これらは機能し、何が何であり、提供されていないかについて適切な期待を持っている限り、FCI は完全に受け入れ可能なソリューションです。 次の図は、記憶域スペース ダイレクトを使用する場合の FCI 展開の概要を示しています。
このアーキテクチャを検討する価値があるのはなぜですか?
FCI は引き続き一般的な可用性ソリューションです。
共有ストレージのストーリーは、Azure 共有ディスクなどの機能で改善されています。
このアーキテクチャは、HA のほとんどの RTO と RPO を満たします (DR は処理されません)。
このアーキテクチャは、アプリケーションが SQL Server のクラスター化されたインスタンスにアクセスするための、標準化された簡単な方法を提供します。
このアーキテクチャでは、修正プログラムの適用シナリオ中の可用性が向上します。
ディザスター リカバリーの例 1 - マルチリージョンまたはハイブリッド Always On 可用性グループ
AG を使用している場合、1 つのオプションとして、複数の Azure リージョン間で AG を構成するか、ハイブリッド アーキテクチャとして構成することもできます。 つまり、レプリカを含むすべてのノードが同じ WSFC に参加します。 これは、特にハイブリッド構成の場合は、ネットワーク接続が良好であることを前提としています。 最大の考慮事項の 1 つは、WSFC の監視リソースです。 このアーキテクチャでは、AD DS と DNS をすべてのリージョンで使用でき、これがハイブリッド ソリューションである場合はオンプレミスでも使用できる必要があります。 次の図は、2 つの場所で構成された 1 つの AG が Windows Server を使用している様子を示しています。
このアーキテクチャを検討する価値があるのはなぜですか?
このアーキテクチャは実証済みのソリューションです。これは、現在、AG トポロジに 2 つのデータ センターがあることと同じ意味です。
このアーキテクチャは、SQL Server の Standard エディションと Enterprise エディションで動作します。
AG は当然、データの余分なコピーで冗長性を提供します。
このアーキテクチャでは、HA と D/R の両方を提供する 1 つの機能を使用します
ディザスター リカバリーの例 2 – 分散型可用性グループ
分散 AG は、SQL Server 2016 で導入された Enterprise Edition のみの機能です。 従来の AG とは異なります。 前の例で説明したように、すべてのノードが 1 つの AG に参加するレプリカを含む 1 つの基になる WSFC を持つ代わりに、分散 AG は複数の AG で構成されます。 読み取り/書き込みデータベースを含むプライマリ レプリカは、グローバル プライマリと呼ばれます。 第 2 の AG におけるプライマリは "フォワーダー" と呼ばれ、その AG のセカンダリ レプリカを同期された状態に保ちます。これは実質的に AG の AG です。
このアーキテクチャでは、クォーラムなどの扱いが容易になります。それぞれのクラスターで独自にクォーラムが維持され、それぞれが独自のミラーリング監視機構を備えることになるためです。 分散 AG は、すべてのリソースに Azure を使用しているか、ハイブリッド アーキテクチャを使用しているかに関係なく機能します。
次の図は、分散 AG 構成の例を示しています。 WSFC は 2 つあります。 それぞれが異なる Azure リージョンにあるか、1 つがオンプレミスで、もう一方が Azure にあるとします。 各 WSFC には、2 つのレプリカから成る AG があります。 AG 1 のグローバル プライマリは、AG 1 のセカンダリ レプリカを同期された状態に維持すると共に、AG 2 のプライマリであるフォワーダーも同期状態にします。 そのレプリカは、AG 2 のセカンダリ レプリカの同期を維持します。
このアーキテクチャを検討する価値があるのはなぜですか?
このアーキテクチャでは、すべてのノードが通信を失った場合に WSFC が単一障害点として分離されます
このアーキテクチャでは、1 つのプライマリがすべてのセカンダリ レプリカを同期しているわけではありません。
このアーキテクチャでは、ある場所から別の場所へのフェールバックを提供できます。
ディザスター リカバリーの例 3 - ログ配布
ログ配布は、SQL Server のディザスター リカバリーを構成するための最も古い HADR メソッドの 1 つです。 説明したように、測定単位はトランザクション ログバックアップです。 データ損失が発生しないようにウォーム スタンバイへの切り替えが計画されていない限り、データ損失が発生する可能性が最も高くなります。 ディザスター リカバリーに関しては、最小限であってもデータ損失を想定することが常に最善です。 次の図は、ログ配布トポロジの例を示しています。
このアーキテクチャを検討する価値があるのはなぜですか?
ログ配布は、20 年以上前から試用されてきた機能です
ログ配布は、バックアップと復元に基づいているため、デプロイと管理が簡単です。
ログ送信は、堅牢でないネットワークを許容します。
ログ配布は、DR のほとんどの RTO と RPO の目標を満たしています。
ログ配布は、FCI を保護するための優れた方法です。
ディザスター リカバリーの例 4 – Azure Site Recovery
SQL Server ベースのディザスター ソリューションを実装したくない場合、Azure Site Recovery は潜在的なオプションです。 ただし、ほとんどのデータプロフェッショナルは、一般的に RPO が低くなるため、データベース中心のアプローチを好みます。
次の図は、Azure Portal で Azure Site Recovery のレプリケーションを構成する場所を示しています。
このアーキテクチャを検討する価値があるのはなぜですか?
Azure Site Recovery は、SQL Server 以上の機能を備えています。
Azure Site Recovery は RTO と場合によっては RPO を満たす場合があります。
Azure Site Recovery は、Azure プラットフォームの一部として提供されます。