Freigeben über

WSFC、ILB、サードパーティの SIOS DataKeeper を利用した可用性の高いファイル共有

  • Artikel

このポストは、11 月 11 日に投稿された High Availability for a file share using WSFC, ILB and 3rd-party Software SIOS Datakeeper の翻訳です。

Windows の「共有ディスク フェールオーバー クラスター」は、Microsoft Azure Virtual Machines ではまだサポートされていませんが、SIOS DataKeeper というサードパーティ製ソフトウェア (https://us.sios.com/products/datakeeper-cluster/ (英語)) を代わりに使用することができます。

この記事では、具体的な使用例として、可用性の高いファイル共有を実現する方法についてご説明します。セットアップに必要な情報は、すべて基本的にインターネットから入手できます。この記事は、包括的な情報提供のみを目的としています。詳細に入る前に、このアプローチの概要をご説明します。

図 1

テスト用ソリューションのセットアップのポイントは、次のとおりです。

  • ドメイン コントローラー VM 1 台と、フェールオーバー クラスターとなる VM 2 台を用意する必要があります。
  • この記事では、ドメイン コントローラーに高可用性を実装する方法については説明しません。クラスターを含むエンドツーエンド ソリューションではなく、ファイル共有のみに焦点を当てます。
  • 読者の理解を助けるため、ドメイン コントローラー VM 上の単純なファイル共有監視がクラスターのクォーラム構成として使用されているものとします。先ほど述べたように、DC VM は高可用性を実装していません。したがって、DC VM が停止するとファイル共有監視はオフになります。
  • 3 台の VM はすべて同じ Azure VNET 上にあります。ただし、ドメイン コントローラー VM と 2 台のクラスター ノード VM は、それぞれ別々の Cloud Services を使用しています。これは、クラウド サービス レベルで実行される Internal Load Balancer の構成をはっきり分離するためです。
  • ファイル共有の高可用性を確保するには、両方のクラスター ノードを Azure 内の同じ可用性セットに配置し、Azure のメンテナンス時などに両方の VM が同時にダウンするのを防ぐ必要があります。
  • 2 台のクラスター ノード VM 間の共有ディスク フェールオーバー クラスターの構成には、WSFC を使用します。これにより、最終的に可用性の高いファイル共有を実現することができます。
  • Azure Internal Load Balancer (ILB) を使用すると、フェールオーバー クラスター上に作成されたファイル サーバー ロールの仮想名でファイル共有にアクセスすることができます。
  • ファイル サーバー ロールの IP アドレスは、ILB の IP アドレスに置き換えられます。

 

Azure Virtual Machines では、オンプレミスの Hyper-V 環境のように共有ディスクを利用することができません。この場合、どのようにしてソリューションを機能させるのでしょうか? その答えが SIOS DataKeeper です。

図 2

SIOS DataKeeper を使用すると、同期レプリケーションにより、2 つのボリューム (VM に接続されたデータ ディスク) 間にミラーを作成できます。

  • SIOS DataKeeper は、2 つのボリューム (Azure データ ディスク) 間にミラーを作成すると、このミラーをストレージとしてクラスター構成に追加します。
  • クラスター フェールオーバー マネージャーは、このストレージを共有ディスクとして認識します。
  • 先ほど述べたように、ILB を使用するとファイル サーバー ロール名を使用してファイル共有にアクセスすることができます。この場合、常にアクティブ クラスター ノードにルーティングされます。

 

前提条件

  • Windows Server 2012 R2 ですべてのテストを実施しました。
  • SIOS DataKeeper のバージョンは 8.2 でした。
  • SIOS DataKeeper のインストールには、.NET Framework 3.5 が必要です。筆者がテストを実施した時点では、.NET Framework 3.5 の更新プログラムに問題が発生していたため、関連するサポート技術情報 (https://support2.microsoft.com/kb/3005628) に従って exe ファイルをダウンロードし、実行する必要がありました。ただし、最新のテスト報告によると、10 月にリリースされた最新版の WS2012 R2 Azure ギャラリー イメージでは、この問題は解決されている模様です。
  • .NET Framework 3.5 のインストール時には、VNET 上で VM が稼働していないようにします。これについてはインターネット上のいくつかの記事でも取り上げられていますが、ソース ファイルの検索と DNS 設定に関する問題です。回避策として、VM に DNS エントリ 8.8.8.8 を追加する方法があります。さらに、以下の 2 つの記事で報告されているように、バグ修正の必要な問題が発生する場合もあります。
    https://blogs.technet.com/b/askcore/archive/2013/01/14/error-in-failover-cluster-manager-after-install-of-kb2750149.aspx (英語)
    https://support.microsoft.com/kb/2804526 (機械翻訳)
  • 筆者が実施した社内テストでは、.NET Framework 3.5 とこのセクションの 3 番目の項目の修正プログラムをインストールした場所に、独自の OS WS2012 R2 イメージを作成しました。他の 2 つのバグ修正は不要または適用外でした。こちらの記事 (https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-capture-image-windows-server/) の手順に従って個人用 OS イメージを作成し、このイメージからすべてのテスト用 VM を作成しました。バグ修正が不要な場合は、標準の Azure ギャラリーの OS イメージを使用してかまいません。
  • テスト環境では、専用の VNET を使用しました。ILB を正常に機能させるためには、適切な方法で VNET を作成する必要があります。以前は VNET をアフィニティ グループと関連付ける必要がありましたが、これは要件ではなくなりました (https://msdn.microsoft.com/ja-jp/library/azure/jj156085.aspx)。ILB を設定するには、新しいリージョン タイプが必要です。新規作成した VNET であれば、何も問題はありません。
  • ポータル経由で VNET を作成するときは、ロケーション (Azure リージョン) を入力する必要があります。既存の古い VNET 向けに、ネットワーク構成を変更して VNET の設定をアフィニティ グループからリージョンへ変更するオプションが用意されています。筆者がテストしたところ、VNET 内に VM がある状態でこの設定変更を行うことはできませんでした。そこで、すべてのディスクを保持したまま VM を削除し、VM 構成をエクスポートした後、インポートし直しました。この構成の変更については、次の記事を参照してください。
    https://blogs.msdn.com/b/windowsazurej/archive/2014/05/21/blog-regional-virtual-networks.aspx
  • 次に、それぞれ別々の Cloud Services を利用しているドメイン コントローラー VM と 2 台のクラスター ノード VM のセットアップを行いました。これはクリーン セットアップです。ILB は Cloud Services ごとに構成されるため、ILB の構成に関連する副次的な影響の副作用は一切発生しません。
  • SIOS から、このプロセスについて手順を追って説明するガイドも提供されています。WS 2012 を使用する場合の手順 (WS 2012 R2 にも適用可能) については、次の URL を参照してください。
    https://clusteringformeremortals.com/2012/12/31/windows-server-2012-clustering-step-by-step/ (英語)
    https://docs.us.sios.com/WindowsSPS/8.0/DKCE/AllDKCETechDocs/index.htm#DataKeeper/User_Guide.htm%3FTocPath%3DUser_Guide%7C_____0 (英語)

 

次のような画面が表示されます。

図 3

概要のセクションで説明したように、ドメイン コントローラー VM が作成されています。DNS と AD のエントリから、次のことがわかります。

  • クラスター ノード 1 VM の名前は “fsha-cln1” (“fsha” は “file share high availability” の略) です。
  • クラスター ノード 2 VM の名前は “fsha-cln2” です。
  • ドメイン コントローラー VM の名前は “fsha-dc” です。
  • ドメイン名は “fshadomain.com” です。
  • クラスター名は “fshacl” です。
  • クラスター内のファイル サーバー ロールの名前は “fshafsrole” です。

 

図 4

  • SIOS DataKeeper のジョブから “fshajob” という名前のミラーが作成されました。
  • このミラーは、2 台のクラスター ノード VM 間に、ボリューム S: (Azure VM に接続された 5 GB のデータ ディスク) の同期レプリケーションを定義します。
  • DataKeeper 画面を見ると、現在はクラスター ノード 1 がプライマリ (ソース) で、クラスター ノード 2 がセカンダリ (ターゲット) となっていることがわかります。

 

図 5

  • クラスター ノード 1 のファイル システムを確認すると、ボリューム S: 上にファイル共有が存在することがわかります。
  • このファイル共有に高可用性を持たせる必要があります。

 

図 6

  • フェールオーバー クラスター マネージャー内に DataKeeper ボリュームが表示されており、ファイル サーバー ロールの作成が可能です。
  • ファイル サーバー ロール内の [Shares] タブに、図 5 のファイル エクスプローラー レベルで表示されていたファイル共有があります。

 

図 7

  • 2 つ目のクラスター ノードを確認すると、複製されたボリューム S: は、ファイル エクスプローラー レベルで表示することは可能ですが、アクセスはできないことがわかります。
  • SIOS DataKeeper により、複製されたボリュームは、現在の所有者ノード上でしかアクセスできないようになっています。

 

図 8

  • クラスター ロール内に作成されたファイル共有には、仮想名 “\\fshafsrole\fsha_share” を使用してドメイン コントローラーからアクセスできます。

 

図 9

  • ファイル サーバー ロールを、クラスター ノード 1 からクラスター ノード 2 へ手動でフェールオーバーします。

 

図 10

  • 2 つ目のノード (Azure VM fsha-cln2) 上のフェールオーバー クラスター マネージャーから、所有者ノードが fsha-cln2 に変更されたことがわかります。
  • SIOS DataKeeper により、ソース サーバーとターゲット サーバーが切り替わっています。
  • それまではアクセスできなかった、2 つ目のノードのファイル エクスプローラー レベルのファイル共有にアクセスできるようになっています。
  • ドメイン コントローラー VM からのアクセスも可能です。

 

図 11

  • フェールオーバー クラスター マネージャー内のファイル サーバー ロールを右クリックして、ファイル共有アクセスに適切な権限を設定します。

 

図 12

  • 概要のセクションで述べたように、DataKeeper のミラーをフェールオーバー クラスターの共有ディスクのように使用するだけでは不十分です。
  • ファイル サーバー ロールの名前を使用してファイル共有にアクセスするには、もう 1 つ回避策を用意する必要があります。
  • 具体的には、Azure Internal Load Balancer (ILB) を使用します。
  • スクリーンショットでは、クラスター ノードの Cloud Services 上に “ilbfsha” という名前の ILB が作成されています。
  • この ILB の IP アドレスは 10.0.0.99 です。

 

図 13

  • フェールオーバー マネージャーの [Resources] タブで、ファイル サーバー ロールの IP アドレスが ILB の IP アドレスと同じ 10.0.0.99 であることをご確認ください。
  • これは、最終的に全体の設定を機能させるための「技」です。ファイル サーバー ロールは、もともとは別の IP アドレスで作成されていました。
  • この IP アドレスは、PowerShell コマンドにより、ILB の IP アドレスで置き換えられました。PS コマンドの例については、以下の ILB 構成のセクションを参照してください。このアドレスの置換は、フェールオーバー マネージャーの GUI で実行できる単純な IP アドレスの変更とは異なります。

 

図 14

  • PS コマンド “get-azureendpoint” によって、ILB に関連付けられたクラスター ノード 1 とクラスター ノード 2 に、2 つのエンドポイントが作成されたことがわかります。
  • ローカル ポートは 443 と 445 で、プローブ ポートは 59999 です。

 

ILB 構成

ドメイン コントローラー VM や Azure 上のフェールオーバー クラスターのセットアップと同じく、Azure Internal Load Balancer (ILB) の構成方法に関する情報はインターネットで見つかります。ILB を使用した可用性の高いファイル共有の構成要件は、SQL Server AlwaysOn の要件と同じです。下記のリンクを参照してください。

Azure Cloud Services に ILB を追加したり、Azure PowerShell を使用してエンドポイント 443 と 445 を VM に追加したりする手順は、SQL Server AlwaysOn の構成とまったく同じで、簡単です。注意が必要なのは、ファイル サーバー ロールの IP アドレスの設定です。テスト環境では、ファイル サーバー ロールは最初、10.0.0.100 という IP アドレスで作成されました。これは、最終的に ILB の IP アドレス 10.0.0.99 で置き換えられます。この処理は、SQL AlwaysOn グループ リスナーに関する下記のブログ記事で説明されているとおり、set-clusterparameter コマンドによって行われます。以下は、ファイル共有のテスト環境における実行例です。

オンプレミスで Azure PowerShell を使用してコマンドを実行します。

 $probeport="59999"
add-azureInternalLoadBalancer -internalloadbalancername ilbfsha -ServiceName fsha-cscl -Subnetname Subnet-1 -StaticVnetIPaddress 10.0.0.99
Get-AzureVM -ServiceName fsha-cscl -Name fsha-cln1 | Add-AzureEndpoint -Name "fsep1" -LBSetName "ilbsetfsha" -Protocol tcp -LocalPort 443 -PublicPort 443 -ProbePort $ProbePort -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName ilbfsha | Update-AzureVM
Get-AzureVM -ServiceName fsha-cscl -Name fsha-cln1 | Add-AzureEndpoint -Name "fsep2" -LBSetName "ilbsetfsha2" -Protocol tcp -LocalPort 445 -PublicPort 445 -ProbePort $ProbePort -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName ilbfsha | Update-AzureVM
Get-AzureVM -ServiceName fsha-cscl -Name fsha-cln2 | Add-AzureEndpoint -Name "fsep1" -LBSetName "ilbsetfsha" -Protocol tcp -LocalPort 443 -PublicPort 443 -ProbePort $ProbePort -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName ilbfsha | Update-AzureVM
Get-AzureVM -ServiceName fsha-cscl -Name fsha-cln2 | Add-AzureEndpoint -Name "fsep2" -LBSetName "ilbsetfsha2" -Protocol tcp -LocalPort 445 -PublicPort 445 -ProbePort $ProbePort -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName ilbfsha | Update-AzureVM

上記の ILB の設定に続いて、クラスター ノード VM 内で PowerShell を使用してコマンドを実行します。

 $ProbePort="59999"
$fileserverresource = get-clusterresource | Where-Object { ($_.name -like "IP*10.0.0.100*" ) }
$fileserverresource | set-clusterparameter -Multiple @{"Address"="10.0.0.99";"ProbePort"=$ProbePort;"Subnetmask"="255.255.255.255";"Network"="Cluster Network 1";"OverrideAddressMatch"=1;"EnableDhcp"=0}

Azure ILB 構成については、以下のリンクを参照してください。

https://blogs.msdn.com/b/windowsazurej/archive/2014/05/26/blog-internal-load-balancing.aspx

https://blogs.msdn.com/b/windowsazurej/archive/2014/10/16/blog-sql-server-alwayson-and-ilb.aspx

https://blogs.msdn.com/b/sqlalwayson/archive/2013/08/06/availability-group-listener-in-windows-azure-now-supported-and-scripts-for-cloud-only-configuration.aspx (英語)

 

その他の情報

  • SIOS ホームページ: https://www.sios.com/us/
  • Azure PowerShell によるテスト環境でのテスト セットアップ

 

テスト環境のセットアップを簡素化するため、Azure PS スクリプトを作成しました。このスクリプトは、ドメイン コントローラー VM や 2 つのクラスター ノード VM の作成、ドメインへの参加などに役立ちますが、マイクロソフト公式のユーティリティではありません。重要なのはプログラミングの方法でもセキュリティでもなく、SIOS DataKeeper の機能のテストですので、SIOS DataKeeper をインストールするまでのすべての手順をできる限り自動化することを目的としています。いくつか解決の必要な問題が発生していたため、情報と PS コードを共有します。

SIOS DataKeeper プロジェクト全体は、Azure Virtual Machines 上の SAP HA に関連付けられています。Azure PS のサンプルについては、およそ 2 週間以内に Microsoft SAP Engineering チーム ブログ「Running SAP Applications on the Microsoft Platform (英語)」で公開する予定です。