目次
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が同一ノードで稼働することはないようです。
- カテゴリー