高可用性とディザスター リカバリーのオプションを考察する
仮想マシン (VM) 向けのソリューションの構想を練るには、まず、IaaS ベースのデプロイで選択できる可用性オプションを把握しておく必要があります。
サービスとしてのインフラストラクチャとサービスとしてのプラットフォームの比較
可用性に関しては、IaaS と PaaS のどちらを選ぶかで違いが出てきます。 IaaS では仮想マシンが提供されます。つまり、SQL Server をインストールしたオペレーティング システムが存在します。 SQL Server を担当するグループや管理者が、高可用性とディザスター リカバリー (HADR) ソリューションを選択でき、その構成を細かく制御することができます。
Azure SQL Database などの PaaS ベースのデプロイでは、HADR ソリューションは機能に組み込まれており、多くの場合、必要な作業は、それを有効にすることだけです。 構成できるオプションはごく限られています。
こうした違いから、IaaS と PaaS のどちらを選択するかで、HADR ソリューションの最終的な設計が大きく変わる場合があります。
Azure 仮想マシンにおける SQL Server の HADR 機能
IaaS を使用している場合は、SQL Server に備わっている機能を使用して可用性を高めることができます。 一部のケースでは、Azure レベルの機能と組み合わせて、可用性をさらに高めることができます。
SQL Server に用意されている機能を次の表に示します。
| 機能名 | 保護 |
|---|---|
| Always On フェールオーバー クラスター インスタンス (FCI) | インスタンス |
| Always On 可用性グループ (AG) | データベース |
| ログ配布 | データベース |
SQL Server のインスタンスとは、SQL Server のインストール全体をいいます。バイナリのほか、ログイン、SQL Server エージェント ジョブ、データベースなど、インスタンス内のすべてのオブジェクトが該当します。 インスタンスレベルの保護とは、インスタンス全体が可用性機能で考慮されることを意味します。
SQL Server のデータベースには、エンド ユーザーとアプリケーションによって使用されるデータが含まれています。 SQL Server が使用するシステム データベースのほか、エンド ユーザーが使用するデータベース、アプリケーションが使用するデータベースもあります。 SQL Server のインスタンスは常に、それ自身のシステム データベースを保有します。 データベースレベルの保護とは、そのデータベースに存在するあらゆるデータ、またはユーザー データベースとアプリケーション データベースのトランザクション ログにキャプチャされるものすべてが、可用性機能の対象として考慮されることを意味します。 データベースの外部に存在するものや、トランザクション ログにキャプチャされないもの (SQL Server エージェント ジョブ、リンク サーバーなど) は、計画フェールオーバーや計画外のフェールオーバー イベントが発生した場合に宛先サーバーがプライマリのように機能できるよう手動で扱う必要があります。
FCI と AG はどちらも、基になるクラスターのメカニズムを必要とします。 Windows Server 上で実行される SQL Server 環境では Windows Server フェールオーバー クラスター (WSFC) が、また Linux では Pacemaker がそれに該当します。
AlwaysOn フェールオーバー クラスター インスタンス
FCI は、SQL Server のインストール時に構成されます。 SQL Server のスタンドアロン インスタンスを FCI に変換することはできません。 FCI には、クラスターに参加する基になるサーバー (ノード) とは異なる IP アドレスと一意の名前が割り当てられます。 名前と IP アドレスは、基になるクラスターのメカニズムとも異なっている必要があります。 アプリケーションとエンド ユーザーは、FCI の一意の名前を使用してアクセスすることになります。 このように抽象化されているので、インスタンスがどこで実行されているかをアプリケーションが意識する必要はありません。 Azure ベースの FCI とオンプレミスの FCI の大きな違いの 1 つは、Azure では、内部ロード バランサー (ILB) が必要である点です。 アプリケーションとエンド ユーザーが FCI の一意の名前に対して確実に接続できるようにするために ILB が使用されます。
FCI がクラスター内の別のノードにフェールオーバーすると、それが手動により開始されたものであれ、何かの問題が原因で発生したものであれ、インスタンス全体が別のノードで再起動されます。 つまり、このフェールオーバー プロセスでは SQL Server が完全に停止されてから起動されます。 FCI に接続されているアプリケーションとエンド ユーザーはフェールオーバー中に切断され、その中断を処理して回復する能力を備えたアプリケーションだけが自動的に再接続できます。
別のノードでの起動時に、インスタンスには回復プロセスが適用されます。 FCI は障害発生時点まで整合性が確保されるため、厳密にはデータの損失は発生しませんが、ロールバックを必要とするトランザクションがあれば、回復の過程でロールバックを実行する必要があります。 前述のように、これはインスタンスレベルの保護であるため、必要なものはすべて (ログイン、SQL Server エージェント ジョブなど) 復元されます。データベースの準備が整ったら、通常どおりに業務を継続することができます。
FCI はデータベースのコピーを 1 つ必要としますが、それが単一障害点にもなります。 別のノードからデータベースにアクセスできるようにするには、なんらかの形態の共有記憶域が必要となります。 Windows Server ベースのアーキテクチャでは、Azure Premium ファイル共有、iSCSI、Azure 共有ディスク、記憶域スペース ダイレクト (S2D) のほか、サポートされるサードパーティのソリューション (SIOS DataKeeper など) を用いてそれを実現できます。 Standard Edition の SQL Server を使用した FCI で使用できるノードは 2 つまでとなります。 FCI では、他にも Active Directory Domain Services (AD DS) とドメイン ネーム サービス (DNS) を使用する必要があります。つまり、FCI が機能するためには、Azure 内のどこかに AD DS と DNS が導入されている必要があります。
Windows Server 2016 以降を使用している場合、FCI から記憶域レプリカを使用して、FCI 用のネイティブのディザスター リカバリー ソリューションを作成できます。ログ配布や AG といった他の機能を使用する必要はありません。
Always On 可用性グループ
AG は SQL Server 2012 Enterprise Edition で導入されましたが、SQL Server 2016 以降では、Standard Edition でも導入されています。 Standard Edition では、AG に含めることのできるデータベースが 1 つであるのに対し、Enterprise Edition では、複数のデータベースを AG に含めることができます。 AG はいくつか FCI と似ている部分もありますが、多くの点で両者は異なります。
FCI と AG の最大の違いは、AG で提供されるのはデータベースレベルの保護であるという点です。 プライマリ レプリカは、AG に参加しているインスタンスのうち、読み取り/書き込みデータベースを含んでいるインスタンスです。 セカンダリ レプリカは、プライマリが同期状態を維持するためにログの転送を通じてトランザクションを送信する際の宛先となる場所です。 プライマリ レプリカからのデータ移動は、同期または非同期で行うことができます。 セカンダリ レプリカ上のデータベースは "読み込み中" 状態になっています。つまり、トランザクションを受信することはできますが、レプリカがプライマリに切り替わるまでは、完全に書き込み可能なコピーになることはできません。 Standard Edition の AG に含めることができるレプリカは最大 2 つ (プライマリ × 1、セカンダリ × 1) であるのに対し、Enterprise Edition では最大 9 つのレプリカがサポートされます (プライマリ × 1、セカンダリ × 8)。 セカンダリ レプリカは、データベースのバックアップから初期化されるほか、SQL Server 2016 以降では、"自動シード処理" という機能を使用できるようになりました。 自動シード処理は、ログ ストリームの転送を使用した処理です。構成済みのエンドポイントを使用して、可用性グループの各データベースのセカンダリ レプリカにバックアップがストリーム配信されます。
AG は、リスナーを使用して抽象化を実現します。 リスナーは、FCI に割り当てられた一意の名前のように機能します。他のどの要素 (WSFC、ノードなど) とも異なる固有の名前と IP アドレスがリスナーには割り当てられます。 また、リスナーは ILB を必要とし、停止と起動はリスナーを介して行われます。 アプリケーションとエンド ユーザーは接続にリスナーを使用できますが、FCI とは異なり、リスナーの使用は任意であり、必ずしも使用する必要はありません。 インスタンスに直接接続することもできます。 Enterprise Edition では、必要に応じて読み取り専用アクセスで使用するようにセカンダリ レプリカを構成したり、データベース整合性確認 (DBCC) やバックアップなど、他の機能にセカンダリ レプリカを使用したりすることができます。
AG は、FCI と比べてフェールオーバー時間が短くて済むため、それがユーザーの関心を引く理由の 1 つとなっています。 AG は共有記憶域を必要としませんが、レプリカごとにデータのコピーが 1 つ存在するため、データベースのコピーの総数が増え、全体的なストレージ コストが大きくなります。 ストレージは、各レプリカのローカルに存在します。 たとえば、プライマリ レプリカにおけるデータベースのデータ占有領域が 1 TB である場合、各レプリカも同じだけの領域を占有します。 レプリカが 5 つあれば、当然、5 TB の領域が必要になります。
他の SQL Server インスタンスを新しいプライマリ レプリカにする必要が生じた場合には、データベースの外部に存在するオブジェクトや、データベースのトランザクション ログにキャプチャされないオブジェクトは、そのインスタンスに手動で作成し、その構成要素とする必要があります。 手動対応することになるオブジェクトとしては、SQL Server エージェント ジョブ、インスタンスレベルのログイン、リンク サーバーなどがあります。 AG で包含データベースを使用できる場合、または Windows 認証を使用できる場合、アクセスが簡素化されます。
高可用性アーキテクチャの導入に際して課題に直面する組織は少なくありませんが、Azure プラットフォームに備わっている高可用性や、Azure SQL Managed Instance などの PaaS ソリューションで得られる高可用性で済む場合もあります。 Azure プラットフォーム ソリューションに注目する前に、知っておくべき SQL Server 機能がもう 1 つあります。それはログ配布です。
ログ配布
ログ配布は、SQL Server の黎明期から存在していた機能です。 バックアップ、コピー、復元に基づく機能であり、SQL Server の HADR を実現する最も単純な方法です。 ログ配布は主にディザスター リカバリーに使用されますが、ローカルの可用性を高めるために使用することもできます。
AG と同様、ログ配布によって得られるのはデータベースレベルの保護です。つまり、SQL Server エージェント ジョブ、リンク サーバー、インスタンスレベルのログインなどは自分で対応する必要があります。ネイティブでは抽象化が提供されないため、ログ配布に参加する別のサーバーへの切り替えは、名前の変更に耐えられることが求められます。 それが不可能である場合でも、DNS エイリアスなどの方法があります。ネットワーク層で DNS エイリアスを構成することによって、名前変更の問題の軽減を図ることができます。
ログ配布メカニズムは単純です。まず、プライマリ サーバーにあるソース データベースの完全バックアップを作成し、別のインスタンス (セカンダリ サーバーまたはウォーム スタンバイと呼ばれます) 上で、それを "読み込み中" 状態 (STANDBY または NORECOVERY) で復元します。 このデータベースの新しいコピーは、セカンダリ データベースと呼ばれます。 その後、SQL Server に組み込まれた自動のプロセスによって、プライマリ データベースのトランザクション ログが自動的にバックアップされ、そのバックアップがスタンバイ サーバーにコピーされて、最後にそこで復元されます。
SQL Server の HADR 機能が、IaaS の可用性を向上させる唯一の方法ではありません。 Azure には、他にも検討すべきいくつかの機能があります。