こんにちは。
サイオステクノロジー國政です。プリセールスを担当しています。
今回は、弊社が提唱するソリューションである、SANLees ClustersをMicrosoft Azure上で構成した後の運用についていくつか考察してみます。
Contents
SANLess Clusters とは?
サーバーをHAクラスター構成にする場合、LifeKeeperなどのソフトウェアを利用します。Windows Server 2008R2以降、Microsoft Server製品には、WSFC (Windows Server Failover Cluster) といったクラスター機能が標準で搭載されています。
マイクロソフト:フェールオーバー クラスタリング概要
WSFCを構成する為の概要を確認した所、「記憶域にはSAS, FC, FcoE, iSCSIに適応した」とありますので、基本的にはSANストレージが必要である事が読み取れます。
さて、ここで一つの疑問が沸きます。HAクラスターを構成するのに、高価なSANストレージ（共有ディスク）は必要でしょうか? この問いには様々な観点があると思いますが、答えはNoではないでしょうか。
なぜならば、共有ストレージ1台では単一障害点（SPOF）の問題が付きまといます。また、昨今クラウドファーストといった風潮も定着してきましたが、クラウド上では原則として従来の環境で構築してきたような共有ディスク構成のHAクラスターを一般的なパブリッククラウド上で再現する事は困難です。
これらの問題に対して様々な技術検証を重ねた結果、共有ディスクを利用せずローカルディスク同士をミラーリングする手法でWSFC構成において共有ディスクとして機能するDataKeeper for Windows Cluster Editionが、Microsoft社の正式なサポート環境として認定されています。
弊社ではWSFCとDataKeeperの構成をSANなしクラスター、SANLess Clustersとして利用促進活動を続けています。
SIOS SANLess Clusters ソリューション紹介
Microsoft Azure上でのSANLess Clusters構成
SANLess Clustersはオンプレミスでも仮想環境でも、もちろんクラウド環境でも構築できます。今回はAzure上で以下の構成で環境を構築してみます。
構成のポイント
- Azure東日本リージョンに AD1台、SQLDB2台を配置
- 東日本サイト内でWSFCを構成
- SQLServerはVersion 2014のStandard Editionを利用（Always On可用性グループは利用しない)
- DataKeeper for Windows Cluster EditionにてSQLServerで利用するデータ領域をレプリケーションする
- ILBは利用しない
- WSFC構成なので、SQLDB01に障害が発生した場合はSQLDB02でサービスが引き継がれる
- Azureはリソースマネージャ版で構成
上記構成で運用を行う場合、次に考える事はデータのバックアップや、東日本リージョンに大規模障害が発生した場合にサービス停止に陥る可能性の排除が必要です。つまり、バックアップやリージョンを超えた何らかの対策が必要になります。
これらの対策を行おうと考えた場合、インターネット検索で “Azure Backup”などのキーワードで検索すると、さまざまな情報が閲覧できます。例えば、オンプレミス環境からAzureへのバックアップや、ファイルの復元、サイトの復元など、用途によって様々な手法がある事がわかります。
その中からAzure上で完結するいくつかの手法から「Azure Backup」と「Site Recovery」の2つについて、当該構成で有効であるかどうか考察してみたいと思います。
「Azure Backup」を使った東日本リージョンでのバックアップ
- 初めにRecovery Serviceコンテナーを作成します。これは、BackupとSite Recoveryの両方で使う箱のようなものです。必ずバックアップを取得するリージョン内で（この場合は東日本リージョン）作成します。
- 次に [+バックアップ] をクリックし、バックアップの設定を行います。このAzure Backupはオンプレtoクラウドのバックアップ設定、仮想マシンだけでなくファイル単位での取得も可能です。このあたりは実際の設定箇所にてご確認ください。設定内容:ワークロードはどこで実行されていますか? ⇒Azure
何をバックアップしますか? ⇒仮想マシン - 次にバックアップポリシーを選択します。初期設定では、毎日21:30に作成して30日保持する設定となっています。
- バックアップ対象の仮想マシンを選択します。（今回は対象3台にチェックをいれます）
- 設定が終わるとバックアップの有効化が青く表示されますので、有効化します。
- バックアップ自体の設定は終わっていますが、初回バックアップがまだですので警告が表示されています。
- 初回バックアップを3台のマシンに対して行います。
- 初回バックアップは、adで31分、SQLDBの各サーバーで41分ほど要しています。
![２．次に [+バックアップ] をクリックし、バックアップの設定を行います](https://i0.wp.com/bcblog.sios.jp/wp-content/uploads/2017/08/SANLessonAzure4.png?ssl=1)
「Azure Backup」を使った東日本リージョンでのリストア
復元用の仮想マシン名、リソースグループ、仮想ネットワーク、サブネット、ストレージアカウントを設定しOKを押下します。
同様に3台分マシンを復元します。
復元された3台について詳細確認を行います。
※Restore-adを先に起動しているが、WSFCは動作していない。
※DataKeeperで共有されているはずのE:も同期を保留したまま停止しています。
単純な復元では元の環境に戻りませんでした。その原因を探っていきます。
バックアップ元サーバーで固定されていたはずのIPアドレス(10.0.0.100)がDHCPに変更されて復元されます。
ネットワーク周りを再設定する事でWSFC/DKCE/SQLの復元は実施されます。
SANLess Clustersとして復元しました。この検証によってSANLess Clusters構成を復元するにあたっての注意点や動作についての考察点などを記載します。
- 復元は、仮想マシンを新規で作成する手順となります。その新規で作成される仮想マシンにVSSから設定を書き戻します。
- ネットワーク周りはDHCPで起動されるので、手動による変更が必要です。その時に元の仮想サーバーが存在する場合、元の仮想サーバーのIPアドレスを一旦違うものに変更してから復元先へ割り当てる必要があります。
- リストアにかかる時間は、バックアップ取得にかかった時間より少し長くかかります。
- バックアップポリシーを確認すると、バックアップの単位（頻度)は日か週単位です。
参考:Azureサポートチームのブログにも記事の掲載があります。
Japan Azure Technical Support Engineers’ Blog
まとめ
SANLess Clustersの環境をバックアップする事を考えた際は以下の点を考慮して、多少の手間と多少の時間、最大24時間前までのデータで差分が生じる事を容認できる場合には、良いソリューションだと思います。
| 手軽さ | Azureに標準で搭載されている機能なので手軽 |
| 費用 | インスタンスが50GB以下\510円+利用したストレージ料金が最小費用 |
| 復旧時間 | データ量にもよるが、1時間～2時間ほどは必要か |
| 復旧作業 | リストア後にネットワーク体系の変更を行う必要がある |
| 設定留意点 | 日単位もしくは週単位でしかジョブ設定できない。 |
| 制限事項 | 1TB以上のディスクを持つVMはAzure Backupのサポート対象外 |
| その他利点 | オンプレto Azureなどバックアップの対象は多様。中身としてはVSS オンラインでバックアップが可能。別途バックアップソフトの必要なし。 ファイル/フォルダ単位での復元も可能（今回の検証対象外) |
次回のブログ後編では、もう一つの手法「Site Recovery」のSANLess Clusters環境での有用性について考察します。
