IaaS の高可用性とディザスター リカバリー ソリューションを考察する
IaaS に関して Azure にデプロイされる機能には、さまざまな組み合わせがあります。 このセクションでは、Azure における SQL Server の HADR (高可用性とディザスター リカバリー) アーキテクチャの一般的な例を 5 つ取り上げます。
単一リージョンの高可用性の例 1 - Always On 可用性グループ
高可用性のみが必要で、ディザスター リカバリーは不要である場合、SQL Server をどこで使用しているかに関係なく、AG (可用性グループ) を構成することが最も一般的な方法の 1 つです。 以下の画像は、単一リージョンにおける一般的な AG の例です。
このアーキテクチャが検討に値する理由
異なる仮想マシン (VM) に複数のコピーを置くことでデータが保護される。
適切に導入されていれば、目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たし、データの損失が最小限またはゼロで済む。
アプリケーションからプライマリ レプリカとセカンダリ レプリカの両方にアクセスするための簡単かつ標準化された方法が用意されている (読み取り専用レプリカなどが使用されている場合)。
パッチ適用時の可用性を強化するシナリオに対応する。
共有記憶域が不要であるため、フェールオーバー クラスター インスタンス (FCI) を使用した場合と比べて単純である。
単一リージョンの高可用性の例 2 - Always On フェールオーバー クラスター インスタンス
AG が導入されるまでは、SQL Server の高可用性を導入する方法として FCI が最も一般的でした。 しかし FCI が設計されたのは、物理的なデプロイが主流の時代です。 仮想化された環境では、FCI で提供される保護の多くが、物理ハードウェアの場合と同じようには提供されません。VM で問題が発生するのはまれであるためです。 FCI は、ネットワーク カードの障害やディスクの障害に対する保護を想定して設計されましたが、そのどちらも、Azure で発生する可能性は低くなっています。
とはいえ、Azure でも FCI を利用する価値はあります。 FCI は役に立ちます。提供されるものとされないものとを正しく理解していれば、しっかり条件にかなったソリューションとなります。 以下の画像は Microsoft のドキュメントから抜粋したもので、記憶域スペース ダイレクトを使用した場合の FCI デプロイの概略図を示しています。
このアーキテクチャが検討に値する理由
FCI は、今もなお広く使われている可用性ソリューションである。
Azure 共有ディスクなどの機能によって共有記憶域階層が強化される。
(DR には対応しないものの) HA に関しては、ほとんどの RTO と RPO を満たす。
アプリケーションから SQL Server のクラスター化されたインスタンスにアクセスするための簡単かつ標準化された方法が用意されている。
パッチ適用時の可用性を強化するシナリオに対応する。
ディザスター リカバリーの例 1 - 複数リージョンまたはハイブリッド Always On 可用性グループ
AG を使用する場合、1 つの選択肢として、複数の Azure リージョンにまたがって (場合によってはハイブリッド アーキテクチャとして) AG を構成することが考えられます。 これは、レプリカを含んでいるすべてのノードが同じ WSFC に参加することを意味します。 当然、ネットワーク接続が良好でなければなりません。ハイブリッド構成となればなおさらです。 最大の考慮事項の 1 つは、WSFC のミラーリング監視リソースでしょう。 このアーキテクチャでは、AD DS と DNS がすべてのリージョンで利用できなければなりません。ハイブリッド ソリューションの場合は、さらにオンプレミスでも AD DS と DNS が利用できる必要があります。 以下の画像は、Windows Server を使用して 2 つの場所にまたがって構成された単一の AG の例です。
このアーキテクチャが検討に値する理由
実績のあるソリューションである。つまり、現在 AG トポロジに 2 つのデータセンターがあることと変わりありません。
Standard Edition および Enterprise Edition の SQL Server と連動する。
AG によりデータの二次的コピーが得られ、必然的に冗長性が確保される。
1 つの機能で HA と DR の両方が提供される。
ディザスター リカバリーの例 2 - 分散可用性グループ
分散 AG は SQL Server 2016 で導入された機能で、Enterprise Edition でのみ利用できます。 従来の AG とは異なります。 前の例では、基盤となる WSFC が 1 つ存在し、1 つの AG に参加するレプリカが、すべてのノードに存在していました。それに対し、分散 AG は複数の AG から成ります。 読み取り/書き込みデータベースを含むプライマリ レプリカは "グローバル プライマリ" と呼ばれます。 第 2 の AG におけるプライマリは "フォワーダー" と呼ばれ、その AG のセカンダリ レプリカを同期された状態に保ちます。これは実質的に AG の AG です。
このアーキテクチャでは、クォーラムなどの扱いが容易になります。それぞれのクラスターで独自にクォーラムが維持され、それぞれが独自のミラーリング監視機構を備えることになるためです。 すべてのリソースに Azure が使用されているか、ハイブリッド アーキテクチャが使用されているかに関係なく、分散 AG は機能します。
以下の画像は、分散 AG 構成の例を示しています。 ここには 2 つの WSFC が存在します。 一方はオンプレミスに、もう一方は Azure にあるなど、それぞれが異なる Azure リージョンにあるとします。 各 WSFC には、2 つのレプリカを含んだ AG が 1 つ存在します。 AG 1 のグローバル プライマリは、AG 1 のセカンダリ レプリカを同期された状態に維持すると共に、AG 2 のプライマリであるフォワーダーも同期状態にします。 このレプリカによって、AG 2 のセカンダリ レプリカが同期されます。
このアーキテクチャが検討に値する理由
WSFC は、すべてのノードの通信が失われたとしても、単一障害点として分離される。
このアーキテクチャでは、すべてのセカンダリ レプリカが 1 つのプライマリによって同期される、ということがない。
拠点間のフェールバックが利用できる。
ディザスター リカバリーの例 3 - ログ配布
ログ配布は、SQL Server のディザスター リカバリーを構成するための最も古い HADR 手法の 1 つです。 前述のように、保護の単位はトランザクション ログ バックアップです。 データの損失を確実に防ぐウォーム スタンバイへの切り替えが計画されていない限り、データの損失は起こると考えられます。 ディザスター リカバリーに関して言えば、ある程度のデータの損失は、たとえ最小限で済むにしても、常に見込んでおくことをお勧めします。 以下の画像は Microsoft のドキュメントから抜粋したもので、ログ配布トポロジの例を示しています。
このアーキテクチャが検討に値する理由
ログ配布は、20 年以上にわたって使用されてきた実績のある機能である。
ログ配布はバックアップと復元に基づいているため、デプロイと管理が容易である。
ログ配布には、堅牢でないネットワークへの耐性がある。
DR の RTO と RPO に関して、ログ配布はほとんどの目標をクリアする。
ログ配布は、FCI を保護する優れた方法である。
ディザスター リカバリーの例 4 - Azure Site Recovery
SQL Server ベースのディザスター ソリューションの導入に消極的なユーザーには、Azure Site Recovery がオプションとして考えられます。 ただし、データベース中心のアプローチの方が一般に RPO が短いため、多くのデータ プロフェッショナルに好まれています。
次の画像は、Microsoft のドキュメントから抜粋したもので、 Azure portal から Azure Site Recovery のレプリケーションを構成する際に使用する画面を示しています。
このアーキテクチャが検討に値する理由
Azure Site Recovery は SQL Server 以外とも連携する。
Azure Site Recovery は RTO を満たし、場合によっては RPO も満たすことができる。
Azure Site Recovery は Azure プラットフォームの一部として提供される。