BeeX Technical Blog

  • 672
  • Keisuke

SAP S/4HANAでAmazon FSxを使ったWindowsクラスター構成(WSFC)を試してみた

Windows Serverで運用しているお客様は、S/4HANAに移行後もAPサーバをLinuxにすることなくWindows Serverを使うことが多いと思います。AWS EC2でSAPシステムをWSFC構成にしようとすると、共有ストレージが問題になっていました。

Amazon FSx for Windows ファイルサーバーは、完全マネージド型のネイティブ Microsoft Windows ファイルシステムですが、SAP環境 (/sapmnt, /usr/sap/<SID>, /usr/sap/trans) でも利用できるようになりました。

2772496 – AWS File Systems EFS and FSx for SAP Solutions

本Blogでも、SoftNASを使って共有ストレージを作成することでWSFCクラスター環境を実現する方法や、SIOS DataKeeper for Windows Cluster Editionのリアルタイムレプリケーション(複製)機能とWSFCのフェイルオーバー機能を組み合わせて実現する方法を掲載しています。

今回の検証は、共有ストレージとしてAmazon FSxを利用します。今までも問題となっていたWindowsファイルサーバがサービス提供されているため、シンプルにWSFC構成にすることができます。

検証ですが、S/4HANA1809を構築します。DBはHANA DBとなりますが、WSFC部分のみの検証のため、DBとPAS部分は割愛します。

OSはWindows Server 2019にしようとしたのですが検証時点でFSxではサポートされていないため、Windows Server 2016にしました。

#試しに、Windows Server 2019からFSxにアクセスしてみましたが問題なくアクセスできました。

FSxの用途ですが、WSFCのQuorum(FileShareWitness)とSAPGlobalHost(sapmnt)に利用します。今回は1つのFSxにしましたがそれぞれ、別のFSxでも可能です。

作業ステップは下記の通りです。

Step1. AWS Managed Microsoft AD作成

Step2. EC2インスタンス作成、ADに登録

Step3. FSx for Windows File Server ファイルシステム作成

Step4. /sapmntの作成

Step5. WSFCを構築

Step6. SWPM: First Cluster Nodeの実行

Step7. SWPM: Additional Cluster Nodeの実行

Step1. AWS Managed Microsoft AD作成

FSxを利用するためにはAWS Managed Microsoft ADが必要です。既存環境にADがあって、そちらを利用したい場合はAWS Manged Microsoft ADを作成し、既存環境のADと信頼関係を設定します。

 

Step2. EC2インスタンス作成、ADに登録

通常と同じようにEC2インスタンスを作成します。作成時に”ドメイン結合ディレクトリ”で先ほど作成したディレクトリサービスを選んでおくと作成と同時にADに登録されるので便利です。

 

Step3. FSx for Windows File Server ファイルシステム作成

FSxのファイルシステムを作成します。最後のサマリにファイルシステム作成後の変更可否が出てます。意外なことに、容量の変更とスループットの変更は後からできませんのでご注意ください。指定できる容量は300GB~となっています。利用した分だけ課金されるので大きめに作っておきましょう。

 

数分でファイルシステムが作成されます。”File system ID”がファイルサーバのホスト名になります。実際にはfs-12345678901234567のような20文字になっています。このままではSAPのホスト名要件の13文字を超えてしまいます。

 

調べてみると、FSxファイルシステムのホスト名はAWS Managed Microsoft AD上のDNSで管理されていました。DNS Managerで見てみると、実際のホストはamznfsxから始まるホストで、File System IDはAliasだということがわかりました。同様に”MyFSx”というAliasを定義します。(ここがSAPGlobalHostになります)

Step4.  /sapmntの作成

デフォルトでは、共有ディレクトリはShareしかないので、sapmntを作成します。Computer Managementでファイルサーバのホストにアクセスして共有フォルダsapmntを作成します。

 

Step5. WSFCを構築

Failover Cluster Managerでクラスタを構築しますが、詳細は割愛します。

shareの下にQuorumディレクトリを作り、File Share Witnessにしました。

Step6. SWPM: First Cluster Nodeの実行

SWPMメニューのHigh-Availability System > First Cluster Nodeを実行していきます。

Cluster Share Configrationでは、File Share Clusterを選択します。

ASCSとERSそれぞれの仮想ホスト名を入力します。今までERSは各ノードのローカルにありましたが、クラスタ化されています。S/4HANA1809以降、Enqueue ServerはデフォルトでStandalone Enqueue Server 2になっています。それに伴い、Enqueue ReplicatorもEnqueue Replicator2となり、冗長化構成も変更になったようです。

File Share Host NameにはFSxファイルシステムのホスト名(Alias)を入力します。

SWPM実行後、SAP Management Consoleでプロセスを見ると、確かにEnqueue Server 2/ Enqueue Replicator 2になっていることが確認できます。

通常、この後は、Database Instanceの作成を行いますが、今回は割愛します。

Step7. SWPM: Additional Cluster Nodeの実行

SWPMメニューのHigh-Availability System > Additional Cluster Nodeを実行していきます。ここは、Step6で入力した内容と一緒のため割愛します。

さらにクラスターノードを追加する場合はこのステップを実行します。今回は3ノード構成のため、2回実施します。

完成

完成したクラスタリソースが下記です。

 

ERSはエンキューテーブルをレプリケーションするため、ASCSインスタンスとは別のノードで起動しないと意味がありません。

各ロールのプロパティで優先ノードを定義し、ASCSはNodeA → NodeB → NodeC、ERSはNodeC → NodeB → NodeAの順にフェイルオーバーするように設定します。

ちなみに、SWPMがクラスタ作成時に、SAP_<SID>_Affinityの名称でAnti-Affinityの設定をしています。そのため、上記設定をしていない場合でもFailover先としてASCSとERSが同一ノードで稼働することはないようです。