本記事では、Azure 共有ディスクの概要から使用する上での注意点やメリット、Azure共有ディスクとWSFCと組み合わせた冗長構成の構築手順を紹介します。また、データレプリケーションを使ったソリューションと比較して、コスト、構築工数、対応可能な障害がどう違ってくるのかも解説しています。
1. Azure 共有ディスクとは
Azure 共有ディスクとは、マネージド ディスクを複数の仮想マシン (VM) に同時に接続できるようにする Azure マネージド ディスクの機能です。（過去には Azure Shared Disks と言われていたこともありました。）
いままでのクラウド環境では、接続されたディスクはその仮想サーバーでしか使用することが出来ませんでしたが、Azure 共有ディスクでは複数の仮想サーバーで共有することが可能になります。これにより、クラウド上でのHAクラスターを使用した共有ディスクの利用が簡単に実装できるようになります。
2. Azure 共有ディスクを使用する上での注意点
共有ディスクを有効にできるのはUltra ディスクと Premium SSD のみ
Ultra ディスクと Premium SSD のみ共有ディスクを有効にできます。Ultra ディスクについては、仮想マシン作成時の可用性オプションを『可用性ゾーン』に指定した場合に利用することができます。
※ 可用性ゾーンとは、Azureリージョン内にある物理的に離れたたデータセンターのことです。Azure リージョン内でのデータセンターレベルの障害に対して高可用性を提供するサービスです。
Premium SSDで共有ディスクとして使用可能なサイズはP15(256 GiB)以上です。
※ 最大共有数が2以上のディスクが共有ディスクとして使用できます。
ディスクを同時に共有できるノードの最大数が決まっている
ディスクには、共有できるノードの最大数を表す maxShares 値が定義されています。それぞれの値は以下となっています。
異なる可用性ゾーンで共有することが出来ない
可用性オプションで『可用性ゾーン』を指定した場合、ディスクを共有する仮想マシンは同じ可用性ゾーンを指定している必要があります。
※ 2を選択した場合、他方も2を選択する必要があります。
Azure Backup および Azure Site Recovery は使用できない
フルマネージドのファイル共有は使用できない
Azure 共有ディスクでは、SMB または NFS を使用してアクセスできるフル マネージドのファイルシステムをネイティブに提供していません。 Windows Server Failover Clustering（以下、WSFC) や Pacemaker のような、クラスター ノードの通信と書き込みロックを処理するクラスター マネージャーを使用する必要があります。
制限事項につきましては、以下サイトを参照ください。
https://docs.microsoft.com/ja-jp/azure/virtual-machines/disks-shared
3. 料金と利用メリット
料金
Azure 共有ディスクは特別な料金は発生しません。Managed Disksの価格で利用可能です。
（共有可能なP15以上のディスクをローカルストレージで使用する場合と、共有ディスクとして利用する場合の料金は同額です）
利用料金はリージョンによって異なっていますが、日本リージョンでは月約5,000円から開始できます。
（記事記載時では、P15のディスクは西日本では4,451.76円、★東日本では4,896.72円となっています）
<東日本リージョンの価格例>
※最新の価格は以下サイトから確認できます。
https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/
利用メリット
Azure 共有ディスクを利用する最大のメリットは、利用方法がとても簡単であるということです。データディスク作成時に表示される『共有ディスクを有効にする』のチェックボックスを有効にするだけです。
既存のオンプレミスのクラスター環境をAzueに移行するのに二の足を踏んでいた管理者の方も、もう一度検討するきっかけになるのではないでしょうか。
また、HAクラスターの共有ディスクとして利用する以外にも、ファイルストレージ的な利用も可能です。
4. Azure 共有ディスクを使った構成例
これまでは、Azure上でフェールオーバークラスター構成を構築する場合、『SIOS DataKeeper for Windows Cluster Edition（以下、DKCE）』などのデータレプリケーション製品により、各仮想マシンのローカルストレージをレプリケーションし、同じデータを保持することで実現させていましたが、Azure 共有ディスク を用いることで1つのディスクを複数の仮想マシンで共有することが可能になりました。
※ DKCEはMicrosoft Azure上で正式に動作認定されている製品です。
5.『WSFC + Azure 共有ディスク』を使ったSQLserver冗長構成
Azure上で『WSFC + Azure 共有ディスク』を使用してSQL フェールオーバー クラスター構成を実際に構築してみました。構築手順は以下となります。
《構成内容》
・ADサーバ（Windows Server 2019 ）
※ Windows Server 2016以降では、ワークグループ構成のクラスターを作成できるようになっていますが、今回は同一のActive Directoryドメインに参加して構成します。
・SQL Server①（Windows Server 2019 ）
SQL Server②（Windows Server 2019 ）
WSFCとSQL Server 2019 フェールオーバー クラスターをインストール。
・共有ディスク (Azure 共有ディスク)
2台のSQL Serverの共有ディスク。
① Windows Server 2019 × 3台作成
(ADサーバ、SQL Server①、SQL Server②）
SQL Serverに設定する2台の仮想サーバー作成時に、データ ディスクは共有可能なサイズのディスクを指定します。
共有ディスクは『最大共有数』が２以上の記載があるディスクが対象です。
※SQL Server②は、『既存のディスクの接続』からSQL Server①で作成したデータディスクを接続させます。
② Windows Server 2019 日本語化
Azureから作成するWindows Server イメージは英語版をベースにされているので、日本語で操作したい場合は、言語を別途追加する必要があります。
③ ADサーバー構築
①で作成したWindows Server 2019 サーバー１台に対して『役割と機能の追加』から『Active Directoryドメイン サービス』を追加し、ドメインコントローラーに昇格させます。
④ ドメイン参加
①で作成したWindows Server 2019 の残り2台（SQL Server①、SQL Server②）を③で作成したADドメインに参加させます。
⑤ データディスクの初期化（共有ディスク）
SQL Server①のサーバーマネージャーの『ファイルサービスと記憶域サービス』から共有ディスクに新規ボリュームを作成します。
この後、ウィザードに従い進めていくとディスクを共有している仮想サーバーに共有ディスクが追加されていることが確認できます。
⑥ WSFC構築
各SQL Serverに『役割と機能の追加』から『フェールオーバークラスタリング』を追加します。
続いて、構成の検証を行い、『検証されたノードを使用してクラスターを今すぐ作成する』にチェックを付けます。
クラスター作成ウィザードが開始されるので、指示に従い進めます。
クラスター構成が完了後、共有ディスクをクラスターのディスクに追加します。
⑦ SQLサーバー フェールオーバークラスターのインストール
SQL Server①でSQLのインストーラーを起動し、『SQL Server フェールオーバークラスターの新規インストール』を進めます。
SQL Server②では同様にSQLのインストーラーを起動し、こちらは『SQL Server フェールオーバークラスターにノードを追加』を進めます。
⑧ 確認
簡易的ではありますが、WSFC＋Azure 共有ディスクを使用したSQL Server フェールオーバークラスターの構成が出来上がります。稼働系のサーバーに、共有ディスクがマウントされているのがわかります。
フェールオーバーを実際行ってみましたが、Azure 上で問題なく共有ディスクが稼働系から待機系に引継ぎ、使用できることが確認できました。
《フェールオーバーによる、稼働系と待機系の切り替え》
稼働系の共有ディスクが待機系に移動し、新たな稼働系の共有ディスクになります。
6. DKCEによるレプリケーション構成との比較
Microsoft Azure上で正式に動作認定されているHAクラスターソリューションである、DKCEによる「SANLess Clusters」構成との違いについて確認したいと思います。
《Azure 共有ディスクとDKCEとの比較》
以下２台で構成されたフェールオーバー クラスター環境での比較になります。
【構築工数】
構築の難易度に関しては、どちらの構成も比較的容易に構築可能です。
作業工数の差異はDKCEの場合、『DKCEの設定（ローカルストレージをレプリケーションして共有ディスクとして設定する）』手順が必要になります。
※以降、表中のASDはAzure 共有ディスク (Azure Shared Disks)を、DKCEはDataKeeper for Windows Cluster Editionを指す。
※1 『DKCE設定』はウィザードを進めていけば簡単に設定することが可能です。また、AzureポータルのMarketplaceからDKCEがインストール済の仮想マシンを利用することも可能です。
【コスト】
２台のサーバーを使用したフェールオーバー クラスター環境の場合、『Azure 共有ディスク（ASD）』の構成では、共有ディスク１本の料金、『DKCE』の構成ではディスク2本分の料金＋ライセンス料金が必要になります。
『Azure 共有ディスク（ASD）』では、Premium SSD 256GiB以上のサイズのディスクが必須となりますが、『DKCE』を使用した場合にはStandard HDD やStandard SSD などコストの安いディスクを使用することができるためコストを抑えることができます。
ただ、Premium SSD 256GiB以上のサイズで構成する場合は、『Azure 共有ディスク（ASD）』に比べ、倍の２本のDISKが必要になるので、構成によってはコストが増えることが想定されます。
また、高パフォーマンスが必要な場合、アプリケーションの要件よりも高い IOPS を提供するディスクサイズ、VMサイズを選択する必要があります。どちらの構成でも同じですが高パフォーマンスが必要な場合はVMサイズのコストが増加することも考慮することが必要です。
IOPSは仮想マシンのサイズ選択からそれぞれのVMサイズIOPSの情報を確認することができます。
【対応できる障害の種類】
サーバー障害については、どちらの構成でも違いはありませんが、『Azure 共有ディスク（ASD）』は可用性ゾーンを分けることが出来ません。そのため、データセンター全体に影響する障害の影響を受けてしまいます。
DKCEは異なる可用性ゾーン間で構成することが可能です。
また、DKCEは高可用性向けの『Azure Site Recovery』が利用できるので、リージョン全体に影響する障害にも強い、高可用性のシステムを構築することが可能です。
《Azure Site Recoveryとは》
Azure Site Recoveryは、他のリージョンにレプリケーションをすることが出来ます。これにより、複数障害の発生や、リージョン内での大規模障害が発生した場合、他のレプリケーションされた他のリージョンでサービスを再開させることが出来ます。
※補足情報
『Azure 共有ディスク』を使用した構成でも、『Azure Site Recovery』は設定し、実行することが可能ですが、エラーで終了しますので、ご留意ください。下『Azure Site Recovery』を使用して、西日本リージョンから東日本リージョンにレプリケーションを実際に試した結果です。
《Azure 共有ディスクを使用した仮想サーバーをレプリケーションした結果》
→ エラーとなります。
《DKCEを使用した仮想サーバーをレプリケーションした結果》
→ 成功
7. まとめ
Azure 共有ディスクは非常に簡単に利用できるメリットがありますが、可用性ゾーンを跨いだ利用ができないなどまだ可用性の観点からは十分ではないといえます。
お勧めするケースとしては、以下のような構成を検討している場合です。
- 複数台でディスクを共有する必要がある構成。
- 大容量の共有ディスクが必要な構成。
SLAが非常に重要になるシステムでは、可用性ゾーンを考慮して大規模障害に強いシステム構成が可能な『DKCE』を選択いただくのが良いかと思います。
また、『DKCE』で構成した場合、ディスクのサイズ・種類を柔軟に利用できるのも大きなメリットになるかと思います。
DKCEを使ったクラウド上での構成例や、関連資料のダウンロードはこちらのページをご覧ください。
Linuxの場合はこちら↓
Azure上の冗長化構成で相談したいことや「こういった構成は可能なのか」などわからない点がございましたら、お気軽にお問い合わせください。
