高可用性とディザスター リカバリーのオプションについて説明する

  • 12 分

Azure Platform には、組み込みの高可用性以外に、VM と一部の PaaS ワークロードの可用性を高めるための 2 つのオプションが用意されています。 Availability Zones と可用性セットを使用すると、計画メンテナンス アクティビティと可能性のあるハードウェア障害から、ワークロードが保護されます。

高可用性オプション

ほとんどの SQL Server 高可用性ソリューションは、Azure 仮想マシン (VM) で使用できます。 Azure のみのソリューションでは、HADR システム全体が Azure で実行されます。 ハイブリッド構成では、ソリューションの一部が Azure で実行され、その他の部分が組織内のオンプレミスで実行されます。 Azure 環境は柔軟性が高いので、SQL Server データベース システムの予算や HADR 要件に応じて、部分的に、または完全に Azure に移動できます。

可用性ゾーン

Availability Zones は、リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータ センターで構成されています。 Availability Zones がサポートされている Azure リージョン内では、VM の作成時に Available Zones を使用することを選択するときに、仮想マシンを配置するゾーンを指定できます。 サポートされている各 Azure リージョン内には 3 つの Availability Zones があります。 複数の VM を異なるゾーンにデプロイすると、Availability Zones によりデータ センターの障害に対する高可用性が提供されます。 また、それらを使用すると、Microsoft は、特定の時点で 1 つのゾーンのみを更新することにより、各リージョン内で (更新ドメインと呼ばれるグループ化を使用して) メンテナンスを実行することもできます。 リージョン内の 3 つのゾーンに、仮想マシン エコシステムを分散させることができます。 Availability Zones を Azure 仮想マシンと組み合わせて利用すると、アップタイムがフォー ナイン (99.99%) に上昇し、これは 1 年あたり最大 52.60 分のダウンタイムに相当します。 Availability Zones がサポートされている Azure リージョンについては、docs.microsoft.com をご覧ください。 リージョンで Availability Zones を利用でき、アプリケーションでゾーン間の最小待機時間をサポートできる場合、Availability Zones により最高レベルの可用性がアプリケーションに提供されます。

Azure Availability Zones

上の図では、可用性ゾーンの構成を確認できます。 可用性ゾーンを使用してリージョンに VM をデプロイするときは、ゾーン 1、2、3 にデプロイするオプションが表示されます。 これらのゾーンは物理データ センターの論理的な表現であって、あるサブスクリプションでゾーン 1 にデプロイして、別のサブスクリプションでもゾーン 1 にデプロイしたからといって、それが同じデータ センターを表すという意味ではありません。

可用性セット

可用性セットは Availability Zones に似ていますが、リージョン内のデータ センター間にワークロードが分散されるのではなく、データ センター内のサーバーとラックにワークロードが分散される点が異なります。 Azure のほとんどすべてのワークロードは仮想であるため、可用性セットを使用することで、Always On 可用性グループのメンバーが含まれる 2 つの VM が同じ物理ホスト上で実行されないことが保証されます。 可用性セットにより最大 99.95% の可用性を実現でき、Availability Zones を使用できないリージョンの場合、またはゾーン内の待機時間を許容できないアプリケーションの場合に、使用する必要があります。

Always On 可用性グループ (AG)

Always On 可用性グループは、Azure 仮想マシンで実行されている 2 つ以上 (最大 9 つ) の SQL Server インスタンスの間、またはオンプレミスのデータセンターと Azure の間に実装できます。 可用性グループ内のデータベース トランザクションは、プライマリ レプリカにコミットされた後、すべてのセカンダリ レプリカに同期的または非同期的に送信されます。 サーバー間の物理的な距離 (つまり、同じ Azure リージョンに存在するかどうか) により、どちらの可用性モードを選択する必要があるかが決まります。 一般に、ワークロードの待機時間を最小限に抑える必要がある場合、またはセカンダリ レプリカが地理的に離れた場所にある場合は、非同期可用性モードが推奨されます。 レプリカが同じ Azure リージョン内にあり、アプリケーションが一定レベルの待機時間に耐えられる場合は、同期コミット モードを検討する必要があります。 同期モードの場合、アプリケーションの続行を許可する前に、各トランザクションを 1 つ以上のセカンダリに確実にコミットできます。 1 つの可用性グループで同期と非同期の両方の可用性モードをサポートできるため、Always On 可用性グループを使用すると高可用性とディザスター リカバリーの両方を実現できます。 可用性グループのフェールオーバーの単位は、インスタンス全体ではなく、データベースのグループです。

ディザスター リカバリーの目的で Always On 可用性グループも使用できます。 Azure リージョン間でデータベースのレプリカを最大 9 個まで実装し、分散型可用性グループを使用してこのアーキテクチャをさらに拡張できます。 可用性グループにより、データベースの実行可能なコピーが、プライマリ リージョンの範囲外の別の場所に存在することが保証されます。 そうすることで、自然災害や人災から、データ エコシステムを確実に保護することができます。

Always On 可用性グループの構成

上の図は、Windows Server フェールオーバー クラスターで実行されている Always On 可用性グループを論理的に示したものです。 1 つのプライマリ レプリカと 4 つのセカンダリ レプリカがあります。 このシナリオでは、5 つのレプリカすべてを同期にすることも、同期レプリカと非同期レプリカの組み合わせにすることもできます。 フェールオーバーの単位はデータベースのグループであり、インスタンスではないことに注意してください。 フェールオーバー クラスター インスタンスからは、インスタンス レベルの HA は提供されますが、ディザスター リカバリーは提供されません。

SQL Server フェールオーバー クラスター インスタンス

インスタンス全体を保護する必要がある場合は、SQL Server フェールオーバー クラスター インスタンス (FCI) を使用して、1 つのリージョン内のインスタンス全体に高可用性を提供できます。 可用性グループやログ配布などの他の機能と組み合わせない限り、FCI でディザスター リカバリーを実現することはできません。 FCI には共有ストレージも必要であり、共有ファイル ストレージを使用するか、Windows Server の記憶域スペース ダイレクトを使用することにより、Azure でそれを提供できます。

FCI で必要な共有ストレージによりデプロイの複雑さが増すため、Azure ワークロードの新しいデプロイには、可用性グループが推奨されるソリューションです。 ただし、オンプレミスのソリューションからの移行では、アプリケーションのサポートに FCI が必要になる場合があります。

ディザスター リカバリーのオプション

Azure Platform により既定で 99.9% のアップタイムが提供されますが、それでも障害が発生し、アプリケーションのアップタイムに影響を与える可能性があります。 どのような種類でも移行を実行するときは、適切なディザスター リカバリー プランを用意しておくことが重要です。 Azure には、障害発生時に仮想マシン上の SQL Server を確実に保護するための方法がいくつか用意されています。 この保護には、2 つのコンポーネントがあります。 1 つ目として、バックアップと Azure Site Recovery のための geo レプリケーションス トレージのような Azure Platform のオプションがあります。これは、すべてのワークロードを対象とする包括的なディザスター リカバリー ソリューションです。 2 つ目として、可用性グループやバックアップなどの SQL Server 固有のオファリングがあります。

SQL Server のネイティブ バックアップ

バックアップは、すべてのデータベース管理者の生命線と見なされ、それはクラウド ソリューションを使用する場合もまったく同じです。 Azure 仮想マシン上の SQL Server については、バックアップを実行する時期と格納場所を細かく制御できます。 SQL エージェント ジョブを使用して、Azure Blob Storage にリンクされた URL に直接バックアップできます。 Azure には、geo 冗長ストレージ (GRS) または読み取りアクセス geo 冗長ストレージ (RA-GRS) を使用して、バックアップ ファイルが地理的範囲全体で安全に保管されるようにするためのオプションが用意されています。

さらに、Azure SQL VM サービス プロバイダーの一部として、バックアップをプラットフォームで自動的に管理することができます。

SQL Server 用の Azure Backup

Azure Backup ソリューションを使用するには、仮想マシンにエージェントをインストールする必要があります。 その後、エージェントにより、SQL Server データベースの自動バックアップを管理する Azure サービスとの通信が行われます。 また、Azure Backup によって提供される中央の場所を使用して、バックアップの管理と監視を行い、指定された RPO と RTO のメトリックを確実に満たすたこともできます。

SQL Server 用 Azure Backup のアーキテクチャ

上で示されているように、Azure Backup ソリューションは包括的なエンタープライズ バックアップ ソリューションであり、長期のデータ保持、自動管理、データ保護の強化が提供されます。 このオプションを使用すると、独自のバックアップを実行するだけの場合や、SQL Server 用の Azure リソース プロバイダーを使用する場合よりコストは高くなりますが、より完全なバックアップ機能セットが提供されます。

Azure Site Recovery

Azure Site Recovery は、Azure 仮想マシンのブロック レベルのレプリケーションを実行する低コストのソリューションです。 このサービスには、ディザスター リカバリー戦略をテストおよび検証する機能など、さまざまなオプションが用意されています。 このソリューションは、トランザクション データベースの仮想マシンより、ステートレスな環境 (Web サーバーなど) で使用するのに適しています。

Azure Site Recovery は SQL Server での使用がサポートされていますが、より高い復旧ポイントを設定する必要があり、これは損失の可能性を意味することに注意してください。 この場合、RTO は実質的に RPO になります。

Azure Site Recovery のアーキテクチャ

  1. VM は Azure Site Recovery に登録されます
  2. データは継続的にキャッシュにレプリケートされます
  3. キャッシュは対象のストレージ アカウントにレプリケートされます
  4. フェールオーバー中に、仮想マシンがターゲット環境に追加されます