Azure上でのシステム冗長化のポイントは、共有ストレージの課題解決にあり

  • このエントリーをはてなブックマークに追加

Azure上でのシステム冗長化のポイントは、共有ストレージの課題解決にあり | Azure相談センターブログtest

Windows Serverを使ったシステムの可用性の高め方として従来のオンプレミス環境ではWindows Serverに搭載されるWSFC(Windows Server Failover Clustering)の機能やHyper-Vを利用した構成により可用性を高める事が一般的とされてきました。

これらの方法は、冗長化された2つのWindows Serverに接続する共有ストレージ(SANストレージ)が必要となっております。昨今、これらのシステムをAzureへ移行したいというお話が増えておりますが、この構成をAzure上で組もうとすると、大きな問題に直面いたします。それは、Azure上のでは、データ領域であるディスクにあたる部分のVirtual Hard Disk(VHD)1つに対して、複数のVM(仮想マシン)をアタッチさせることができないという点です。オンプレミス環境でWindows Serverの冗長化構成を運用している多くのユーザーは、Azureへ移行しようとする際、少なからずこの「共有ストレージの課題」について解決策を見出す必要があります。

図1:オンプレミス環境とAzure環境での構成の違い

図1:オンプレミス環境とAzure環境での構成の違い

共有ストレージの課題における2つの解決方法

先に結論から述べると、Azure上でのこの共有ストレージの課題における解決方法は2つあります。

解決策① Windows Serverの持つストレージ統合機能S2Dを使う方法
解決策② サードパーティ製のデータレプリケーションソフトを使う方法

それぞれにメリット/デメリットはありますので、利用シーンの多いSQL ServerをAzure上で冗長化することを仮定して、それぞれどのような方法で、どのようなメリットデメリットがあるかをご紹介いたします。

解決策①S2Dを使う方法

まずそもそもS2Dとは何かについて説明いたします。
S2Dは、Storage Space Directの略で日本語では「記憶域スペースダイレクト」といいます。Windows Server 2016から追加された新機能です。フェールオーバークラスターに参加するノードのローカルディスクを、1つの共有ボリュームとして構成することを可能にする機能です。これにより、複数のVHDを1つの共有ボリュームとして構成できるため、共有ストレージのような冗長化を構成することができます。これによりAzure上での「共有ストレージの課題」を解決することができます。

図2:S2Dの概念図 出典 日本マイクロソフト社「Windows Server 2016 で実現する Hyper Converged Infrastructure実践ガイド」第1.0版

図2:S2Dの概念図 出典 日本マイクロソフト社「Windows Server 2016 で実現する Hyper Converged Infrastructure実践ガイド」第1.0版

ただし、S2Dには以下の要件があるため、現行システムがこれらの要件にあてはまっていることを確かめる必要があります。

1.Windows Serverのバージョン要件
Windows Server 2016以降のバージョンで利用できます。

2.SQL Serverのバージョン要件
SQL Serverも2016以降のバージョンで利用できます。

3.ストレージとしての要件
Azureでは従来のSANストレージを使う事ができません。また、SSDのVHD2台とそれとは別に4台のVHDをVMにアタッチする必要があります。

4.ネットワークの要件
信頼性の高い高帯域幅、低遅延なネットワークで各ホストを結ぶ必要があり、10Gbps以上のネットワークが推奨です。

このように、Windwos Server標準の機能で利用できるため、後述する解決策②よりもコストメリットがある反面、ストレージ、ネットワークに求める要件が高く、Azure上での利用には技術的なハードルが高いです。 では、もうひとつの解決策をみてみましょう。

解決策②データレプリケーションソフトを使う方法

Azure上の「共有ストレージの課題」を解決するもう一つの方法は、Windwos Server Failover Clustering機能と連携する、サードパーティ製のデータレプリケーションソフトを使うやり方です。具体的には、サイオステクノロジー社のデータレプリケーションソフト「DataKeeper」を使います。DataKeeperで、Azure上の2つのVHDを同期させつつ、あたかも共有ストレージが存在するかのようにWindows Serverに認識させ、障害発生時に稼働系から待機系への切換えを実現する方法です。

図3 データレプリケーションソフトDataKeeperを使った構成例

図3 データレプリケーションソフトDataKeeperを使った構成例

この方法は、稼働系と待機系のシステムをVHD含めてシンプルに切換えることができ、オンプレミス環境で多くのユーザーが使っている、Windows Server Failover Clusteringの運用を変える必要がない点が大きなメリットです。
一方で、サードパーティ製ソフトDataKeeperのライセンス費用が必要になる点は、Windows Serverの標準機能だけで解決可能な解決策①よりもコスト的に劣ってしまいます。しかしながら、S2Dにて記載しました、バージョン、ストレージ、ネットワークの要件に比べると、以下のとおりだいぶハードルが低くなっております。

1.Windows Serverのバージョン要件
Windows Server 2008R2以降のバージョンで利用可能です。

2.SQL Serverのバージョン要件
SQL Server 2008以降のバージョンで利用可能です。

3.ストレージとしての要件
SANストレージを利用可能です。

4.ネットワークの要件
100Mbps以上のネットワークが推奨です。

まとめ

ここまでに説明してきました、解決策①と②のメリットデメリットを表にまとめると以下のとおりとなります。

表:Azure上の「共有ストレージの課題」解決策の比較

表:Azure上の「共有ストレージの課題」解決策の比較

コスト面はS2Dが、技術面はレプリケーションソフトの利用が優位であることが分かります。よって、現状システムの状況とAzureへ移行後の運用変化などを総合的に判断し、どちらかの選択肢をとって頂くとオンプレミス環境と同程度の可用性を確保することができます。

SQL Server 2008の延長サポート終了をきっかけに、とりあえず2008のままAzureへ移行し、サポートの延命措置を受けようと考えるユーザーが昨年より増えてきました。その中で、止められないシステムをどうやってAzure上で冗長化するか、という視点でインターネット上の事例や構成例を調べる方もやはり増えております。「Azure」「SQL Server」というキーワードで検索するとS2Dをストレージとする記事が多く見つかりますが、前述のとおり、S2Dを使うためにはSQL Server 2016以降である必要があり、SQL Server 2008を冗長化する場合は、DataKeeperによる解決策しかありません。
ちなみに、マイクロソフト社が正式に動作認定しているAzure上のWSFCと連携するデータレプリケーションソフトはこのDataKeeperだけです。

サイオステクノロジー社のDataKeeperは、SQL Serverはもちろん、JP1、HULFT、SAPなど、Azure上で多くの冗長化実績があります。ぜひ、Azure上でのシステム冗長化をご検討の方は、DataKeeperによる構成を選択肢に加えてみてはいかがでしょうか。

 

関連資料
Windows Server標準装備のクラスター機能、Windows Server Failover Clusteringについての調査資料や、SQL Server AlwaysOnについての資料をダウンロードいただけます。
1.「Windows Server Failover Clustering に関する調査レポート」
2.「SQL Server AlwaysOn可用性グループの制約とSIOS SANLessClustersの優位性」
資料ダウンロードはこちら

 

評価版ダウンロード
LifeKeeper/DataKeeper/Single Server Protectionの機能を30日間無料でご利用いただくことができます。要件に対応できるかなど、基本的な機能確認にぜひご利用ください。
評価版のお申込み

著者紹介:サイオステクノロジー株式会社 BC事業企画部 ビジネス開発グループGM 國政 充典氏

※本記事は、サイオステクノロジー株式会社より寄稿いただいたものです。

 

PHOTO:月舟さんによる写真ACからの画像