Azure Virtual Machines に使用される Azure の高可用性とディザスター リカバリー機能について説明する
Azure には、IaaS デプロイの可用性強化に使用される主要なオプションが 3 つ用意されています。
可用性セット
可用性ゾーン
Azure Site Recovery
この 3 つのオプションはいずれも仮想マシン (VM) に対して外部であり、その内部でどのようなワークロードが実行されているかわかりません。
可用性セット
可用性セットは、単一データ センター内の単一障害点や Azure 関連のメンテナンスへの備えとして稼働時間を確保するものです。 Azure プラットフォームに導入された最初の可用性機能の 1 つで、実質上、VM のアンチアフィニティ ルールと考えることができます。 つまり、可用性セット内またはログ配布ペア内に 2 つの SQL Server VM が存在するとき、それらは決して同じ物理サーバー上では実行されないことが保証されます。
基盤となる Azure インフラストラクチャに対する更新をどちらもサポートするように、可用性セットは分離されて異なる障害ドメイン、異なる更新ドメインに配置されます。 障害ドメインは、データ センター内で、同じ電源とネットワークを使用する一連のサーバーです。以下の画像に FD 0、FD 1、FD 2 で示したように、データ センターには最大 3 つの障害ドメインを置くことができます。 更新ドメイン (下図 UD) は、同時に再起動できる基盤となる物理ハードウェアと仮想マシンのグループを表します。 異なる更新ドメインを使用することで分離が保証されます。
可用性セットとゾーンはゲスト内の障害 (OS や RDBMS のクラッシュなど) は保護しません。そのため、RTO と RPO を満たすために、AG や FCI といったソリューションを別途導入する必要があります。 可用性セットと可用性ゾーンはどちらも、データセンターの障害や物理ハードウェアの障害、ネットワークの障害、停電など、Azure レベルの環境の問題から生じる影響の範囲を制限する目的で設計されています。
多層アプリケーションでは、その各層を別々の可用性セットに配置する必要があります。 たとえば、仮に SQL Server バックエンドと Active Directory Domain Services (AD DS) を使用する Web アプリケーションを構築する場合、それぞれの層 (Web、データベース、AD DS) ごとに可用性セットを作成することになるでしょう。
可用性セットが IaaS VM を分離する唯一の方法ではありません。 Azure に Availability Zones も用意されていますが、この 2 つを組み合わせることはできません。 選択できるのは、どちらか一方のみです。
可用性ゾーン
可用性ゾーンが想定しているのは、Azure のデータ センターレベルの障害です。 各 Azure リージョンは多くのデータ センターから成っていて、それぞれのデータ センターが低遅延のネットワーク接続で結ばれています。 可用性ゾーンをサポートするリージョンに VM リソースをデプロイするとき、それらのリソースのデプロイ先としてゾーン 1、ゾーン 2、ゾーン 3 のいずれかを選択できます。 ゾーンは、Azure リージョン内の一意の物理的な場所、つまりデータ センターです。
ゾーン番号は論理的な表現です。 たとえば 2 人の Azure サブスクライバーがどちらも、それぞれのサブスクリプションで VM をゾーン 1 にデプロイしたとしても、それらの VM が物理的に同じ Azure データ センターに存在するとは限りません。 また、ゾーン デプロイでは、距離に起因する待ち時間が多少増える可能性があります。 パフォーマンス目標を確実に達成するために、VM 間の待ち時間をテストする必要があります。 ほとんどの場合、ラウンドトリップ待ち時間は 1 ミリ秒未満であり、可用性グループなどの機能における同期データの移動に耐えます。 可用性ゾーンには Azure SQL Database をデプロイすることもできます。
Azure Site Recovery
Azure Site Recovery は VM の可用性向上を Azure レベルで実現し、SQL Server をホストする VM にも対応します。 Azure Site Recovery は、異なる Azure リージョン間で VM をレプリケートすることで、その VM のディザスター リカバリー ソリューションとなります。 前述のように、この機能は、SQL Server が VM で実行されていることを認識せず、トランザクションについての情報も一切把握しません。 Azure Site Recovery で RTO を満たすことは可能ですが、SQL Server 内のどこにデータがあるかは考慮されないので、RPO を満たすことはできません。 Azure Site Recovery について毎月公表される RTO は 2 時間です。 データベース プロフェッショナルの間では多くの場合、データベースに基づく手法を使ったディザスター リカバリーの方が好まれますが、RTO と RPO のニーズを満たすのであれば、Azure Site Recovery を効果的に活用することができます。