クラウドで SQL Server の高可用性を確保する方法

[51CTO.com クイック翻訳] クラウド コンピューティングにより、重要なサービスを提供する SQL Server 展開で高可用性 (HA) と災害復旧 (DR) 機能を実現できることをご存知ですか?したがって、Azure、AWS、Google は世界中に最先端の分散データセンターを展開し、さまざまな SLA の形で 99.95% 以上の仮想マシン (VM) 可用性レベルをユーザーに約束しています。もちろん、HA または DR 用の SQL Server 構成には、多くの場合、Windows Server フェールオーバー クラスター (WSFC) のセットアップが含まれます。このタイプのクラスターにより、SQL Server はさまざまなホスト上で自身の高可用性を確保できるだけでなく、さらに重要なことに、SQL Server と対話するさまざまなストレージ デバイス上のデータも非常に高い可用性を確保できます。

[[319009]]

従来の WSFC では、データは通常、ストレージ エリア ネットワーク (SAN) または SMB3 (翻訳者注: Server Message Block は、Web 接続やクライアントとサーバー間の情報通信に使用できるプロトコルです) に保存され、WSFC 内のすべてのサーバー ノードによって共有方式でアクセスされます。ただし、クラウド ストレージは従来の SAN と同じ方法で共有することはできません。この制限を克服するには、サードパーティの方法または Windows ネイティブの方法を使用して、このような共有ストレージの制限を克服する必要があります。

HA番号の意味

HAを数字で表すと、実際にはオンライン保証率が99.99%以上ということになります。データ センターを構築する場合、2 台以上の仮想マシン (VM) を Azure データ センター内の個別のラック (多くの場合、「可用性セット」と呼ばれます) にクラスター化して、少なくとも 1 台の VM が 99.95% の時間で利用可能であることを保証できます。 Azure と AWS では、複数のデータセンター (多くの場合、「可用性ゾーン」と呼ばれます) にわたって VM をクラスター化することもできます。このタイプの SLA では、少なくとも 1 つの VM が 99.99% の時間利用可能になります。

ただし、これらの SLA は VM 自体の可用性を保証するものであり、SQL Server とそのデータの可用性を保証するものではありません。つまり、プライマリ VM に障害が発生し、業務がクラスター内のスタンバイ VM に移行された場合、中断を最小限に抑えてサービスを継続するには、スタンバイ VM が SQL Server の実行を継続し、さまざまな基本データベース ファイルにアクセスできる必要があります。 SQL Server とその基盤となるデータの可用性を確保するには、さらに構成が必要であることがわかります。

クラウドでの可用性の構成

では、SQL Server とクラウド データの高可用性を確保するにはどうすればよいでしょうか?主にネイティブの Windows Server サービス (サードパーティ製品ではなく) を使用している場合は、Windows Server 2016 以降の Enterprise Edition で Storage Spaces Direct を使用するか、SQL Server 2012 以降の Enterprise Edition で AlwaysOn 可用性グループを作成するという 2 つのオプションがあります。

上記の 2 つの方法にはそれぞれ長所と短所があります。記憶域スペース ダイレクト (S2D) は、主にソフトウェアで仮想ストレージ エリア ネットワーク (SAN) を作成し、Windows Server フェールオーバー クラスタリング (WSFC) 内の任意の VM によるアクセスを容易にすることを目的としています。このアプローチは、従来のフェールオーバー クラスターへのクラウドベースのアップグレードのように見えますが、クラスターを可用性セットとして構成する必要があるため、クラスター内のすべての VM が同じデータ センターに存在する必要があります。

極端なケースでは、中断イベントによりデータセンター全体がシャットダウンされ、すべての VM とそこに保存されているデータがオフラインになる可能性があります。このため、S2D 構成では 99.95% を超える可用性は得られません。

さらに、S2D では単一のデータ センターが必要であるため、複数のデータ センターにまたがり、Azure、AWS、さらには Google Cloud Platform リージョンに展開されている SQL Server フェールオーバー クラスター インスタンス (FCI) の高可用性が失われます。

表1: Windows Serverオプションの長所と短所

直接のストレージ スペースとは対照的に、AlwaysOn 可用性グループ (AG) は、地理的に異なるデータ センター間の AG コピーをサポートできます。異なるデータ センターにあるレプリカが適切に構成されると、AG に関連付けられた SLA は 99.99% に上昇します。結局のところ、AG 構成は SQL Server FCI ほど共有ストレージに大きく依存しません。

AG が提供するサービスは、レプリカ間で SQL Server データを自動的に同期できます。つまり、現在アクティブな SQL Server インスタンスに障害が発生した場合、指定されたレプリカ サーバーが引き継ぎ、そのインスタンスにレプリケートされたデータベースの管理を開始します。もちろん、この方法にもいくつかの欠点があります。AG はユーザー定義データベースを複製しますが、Master や MSDB などの主要なシステム データベースは複製しません。これらの主要なシステム データベースには、さまざまなエージェント ジョブ、ログイン名、パスワードなどが含まれています。SQL Server のメイン インスタンスが障害によりオフラインになった場合、これらのデータベースは保護できないことがわかります。また、Microsoft は、100 を超える SQL Server データベースまたは 10 を超える AG で AlwaysOn 可用性グループをテストしていないことにも注意してください。つまり、多数のデータベースを同時に保護する必要がある場合、AG には一定の制限が課される可能性があります。

次世代の共有クラウドストレージ

上記の理由から、クラウドベースのファイル共有が誕生しました。 Windows Server 固有の制限を超えて、高性能なクラウドベースの HA および DR ソリューションを実現できるかどうか、ぜひ知りたいはずです。

私は個人的にこう思います。長期的に見れば、答えは「イエス」です。 AWS は最近、ユーザー企業が Amazon FSx (訳注: Amazon の Windows Server ベースのファイルシステム) を使用して WSFC を構成できると発表しました。 WSFC 内のすべてのノードがファイル共有にアクセスできるため、プライマリノードがオフラインになった場合、別のデータセンターにある場合でも、クラスターは自動的にスタンバイノードにフェイルオーバーし、Amazon FSx ファイル共有に保存されている SQL Server データを引き続き使用します。 Azure はまた、ユーザー企業が Azure のプレミアム ファイル共有を使用して FCI で SQL Server を構成できるとも述べています。これを踏まえると、フェールオーバー クラスタリングのローカル データ センター モードは、徐々にクラウド モードに切り替わっていくと思います。

しかし、短期的には答えはノーかもしれない。その理由は、今日のクラウドベースの共有ファイル製品には重大な欠陥があるためです。既存のクラウド ファイル共有サービスの基本 SLA では、読み取りおよび書き込み操作の可用性を 99.9% しか保証できず、これは高可用性について必要な 99.99% の SLA ベースラインよりもはるかに低いものです。その他の課題については、以下の表に客観的にまとめました。

表2: クラウドベースのファイル共有製品における問題と潜在的な結果

クラウドベースのファイル共有が S2D や AG の効果的な代替手段になると予測できます。近い将来、すべてのクラウド サービス プロバイダーは、このようなソリューションを通じて、SQL Server とその基盤となるデータの可用性に対して 99.99% 以上の SLA を提供できるようになります。待って見てみましょう！

クラウドでの SQL Server の高可用性の確保 (David Bermingham 著)

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。