こんばんは。今日は、Azure SQL (IaaSのSQL仮想マシン、PaaSのSQL Managed Instance / SQL Databaseの総称）の高可用性（HA）・災害復旧（DR)オプションについて学んだことをまとめておきたいと思います。絶賛SQL Server勉強中のため、理解が正しくない部分もあるかもしれませんが、間違った記載がありましたらご指摘いただけましたら幸いです。
それではまいります。
Contents
HADRとは
こちらに切り出してまとめました。
Azure SQL各サービス規定のSLA（可用性）
まずは、規定の各サービスの可用性についてまとめておきたいと思います。これからご紹介する高可用性オプションを選択することで、これ以上の可用性を実現していくことができます。
| IaaS/PaaS | サービス | SLA |
|---|---|---|
| IaaS | SQL仮想マシン | 95%~99.99%以上 |
| PaaS | Managed Instance | 99.99%以上 |
| PaaS | SQL Database | 99.9%～99.995%以上 |
Azuer SQL仮想マシン （≒Azure VM）のSLA
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines/v1_9/
Azure SQL Managed InstanceのSLA
https://azure.microsoft.com/ja-jp/support/legal/sla/azure-sql-sql-managed-instance/v1_0/
Azure SQL DatabaseのSLA
https://azure.microsoft.com/ja-jp/support/legal/sla/azure-sql-database/v1_6/
IaaS (SQL仮想マシン) の高可用性オプション
はじめに、Azure VM上でSQL Serverを運用するオプションである、SQL仮想マシンの高可用性オプションです。
| 機能 | 保護対象 |
|---|---|
| Always On フェールオーバー クラスター インスタンス (FCI) | インスタンス* |
| Always On 可用性グループ (AG) | データベース |
| ログ配布 | データベース |
*インスタンス：SQL Serverのインストール全体（バイナリのほか、ログイン、SQL Server エージェント ジョブ、データベースなど、インスタンス内のすべてのオブジェクトが該当）
加えて、SQL Serverが動作するAzure VM自体の機能として、以下の高可用性オプションも活用できます。
| 機能 | 備考 |
|---|---|
| 可用性セット | |
| 可用性ゾーン | |
| Azure Site Recovery |
Always On フェールオーバークラスターインスタンス（FCI）
Always On 可用性グループ（AG）
ログ配布
高可用性のアーキテクチャパターン
パターン１：Always On 可用性グループ
この方式の特徴：
- 異なる仮想マシン (VM) に複数のコピーを置くことでデータが保護される
- 適切に導入されていれば、目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たし、データの損失が最小限またはゼロで済む
- パッチ適用時の可用性を強化するシナリオに対応する
- 共有記憶域が不要であるため、フェールオーバー クラスター インスタンス (FCI) を使用した場合と比べて単純
- Azure VMの可用性セット、可用性ゾーン機能と組み合わせて、同じAG内で異なる可用性セット、ゾーンにレプリカを配置することで冗長性と可用性を高めることができる
- 可用性ゾーンにデプロイする場合は、Azure Standard Load Balancerをリスナーとして配置する
パターン２：Always On フェールオーバー クラスター インスタンス
この方式の特徴：
- AlwaysOn可用性グループ登場以前に主流だったアーキテクチャ
- HA に関しては、ほとんどの RTO と RPO を満たす。
- FCI は、ネットワーク カードの障害やディスクの障害に対する保護を想定して設計されたが、そのどちらもAzure で発生する可能性は低いためAlwaysOn可用性グループによる対策が一般的
- とはいえ、現在でも有効なソリューションであることに変わりない、以下の点が強化される。
- Azure 共有ディスクなどの機能によって共有記憶域階層が強化される。
- （AGと同様）パッチ適用時の可用性を強化するシナリオに対応する。
パターン３： 複数リージョンまたはハイブリッド Always On 可用性グループ
この方式の特徴：
- 複数リージョンにまたがって、またはハイブリッドに（他クラウドやオンプレミスのSQL Serverと）AGを構成している点がパターン１と異なる
- このため、単一リージョン、クラウドの障害に対しても冗長にできる
- 十分に実績のある方式
- ただし、前提としてすべてのノードで通信が良好で、AD DSとDNSが利用できる必要がある
こうしたハイブリットネットワークにおけるプラクティスは以下に説明があります。
パターン４：分散可用性グループ
この方式の特徴：
- 分散AGはSQL Server 2016以降かつEnterprise Optionで選択可能なオプション
- パターン１と異なり、複数のAGから構成される
- 片方のAGをハイブリッドに配置することも可能
- グローバルプライマリと呼ばれる片方のAGのプライマリレプリカが、同じAGのセカンダリレプリカと、別AGのプライマリレプリカ（フォワーダーと呼ばれる）に対して同期を行う。別AGのセカンダリレプリカへの同期はフォワーダーが担当する
- AG（WSFC）が複数になることで単一障害点が減り冗長性が増す。
- 拠点間のフェールバックが利用できる。
パターン５：ログ配布
この方式の特徴：
- ディザスターリカバリを実現する最も古い方式（20年以上にわたる実績がある）
- DR の RTO と RPO に関して、ログ配布はほとんどの目標をクリアする
- ログ配布はバックアップと復元に基づいているため、デプロイと管理が容易
- ログ配布には、堅牢でないネットワークへの耐性がある
- ログ配布は、FCI を保護する優れた方法
- データの損失を確実に防ぐウォーム スタンバイへの切り替えが計画されていない限り、データの損失は起こると考えられる
- なのである程度のデータの損失は、たとえ最小限で済むにしても、常に見込んでおく必要がある
パターン６：Azure Site Recovery
この方式の特徴：
- これまでのパターンのSQL Server ベースのディザスター ソリューションの導入に消極的な場合のオプションになる
- これまでのパターンの方が一般に RPO が短いため、データベース管理者からは好まれる傾向にある
- Azure Site Recovery は SQL Server 以外とも連携する
- Azure Site Recovery は RTO を満たし、場合によっては RPO も満たすことができる
上記を含めたより詳細な記述が、以下にもありますので参考にできるかと思います。
PaaS (Azure Managed Instance / SQL Database)の高可用性オプション
| 機能 | Managed Instance | SQL Database |
|---|---|---|
| ローカル冗長（規定） | 〇 | 〇 |
| ゾーン冗長 | 〇 | 〇 |
| アクティブGeoレプリケーション | × | 〇 |
| 自動フェールオーバーグループ | 〇 | 〇 |
コメントを残す