Amazon EFSとSUSEで実現、SAP Content Serverの高可用性構成

はじめに

2020年初め、SAPはSAP Business Suite 7コアアプリケーションのメインストリーム保守を2027年末まで延長し、その後2030年末までオプションで延長保守を行うことを発表しました。詳細はこちらをご確認下さい。今回の発表により、保守期限を迎える従来のデータセンターからAWSへのSAPシステムをの移行を検討しているお客様は、多くの選択肢ができました。SAP S/4HANAへのマイグレーション/アップグレードの代わりに、既存のSAP Business Suite 7システムをそのままAWS上で利用することができます。このオプションでは、お客様はコアとなるSAPアプリケーションや関連システムに、AWSインフラストラクチャが提供する高い冗長性と可用性を確保したいと考えています。

SAP Content Serverはそのようなアプリケーションの一つで、SAP Business Suite 7と緊密に統合されています。SAP Content Serverはスタンドアロンのコンポーネントであり、あらゆる形式、あらゆる内容の大量の電子ドキュメントを保存することができます。ドキュメントは、1 つまたは複数の MaxDB インスタンスまたはファイルシステムに保存することができます。SAP Content Server に保存される電子ドキュメントの一般的な例としては、売上請求書、発注書、給与明細書、電子メール、アーキテクチャー図などがあります。SAP Content Server が保持するデータは非常に重要です。このように、顧客は回復力があり、可用性の高いセットアップをこのコンポーネントに要求しています。

このブログ記事では、Amazon Elastic File System (EFS)を使用してAWS上のMaxDBバージョン7.9でSAP Content Server 7.53の高可用性設定を行う手順を紹介します。このブログではSUSE High Availability Extensionツールセットを使用していますが、Red Hat Enterprise Linuxベースのシステムでも同様の設定が可能です。また、SAP Content Serverのリポジトリとして、MaxDB Databaseをファイルシステムに置き換えることも可能です。

SAP Content ServerのSLAとAWS上のOLTPシステムのSLAを一致させるためには、SAP Content Serverのアーキテクチャを理解する必要があります。これには、SPOF (Single Point Of Failure)を特定し、アベイラビリティゾーンに分散した回復力のあるシステムを構築することが含まれます。SAP Content Serverは、アプリケーション層とストレージ層で構成されています。このブログでは、ストレージ層としてSAP MaxDBデータベースを使用しています。アプリケーション層はSAPのsapcontrolサービスで管理しています。SUSE High Availability Extension（HAE）を利用することで、アプリケーション層とストレージ層の両方のリソースを管理し、自動化された高可用性ソリューションを構築することができます。

対象範囲

このドキュメントでは、AWS上のSAP MaxDB 7.9データベース上で動作するSAP Content Server 7.53(以降)のクラスタリソース管理レイヤをEFSファイルシステムとオーバーレイIP構成を使用して設定する方法を中心に説明します。SUSE High Availabilityクラスタのクラスタ通信層の設定については、こちらのブログの項目6.1.1～6.1.3を参照してください。今回のブログでは、これらの手順は既に実行済みであることを前提とします。

前提条件

SAPソリューションの高可用性セットアップは、技術的に複雑な作業であり、実際のクラスタ構成の前に満たすべき多くの前提条件があります。このブログ記事では、SUSE HAクラスタソリューションの通信レイヤの設定に関する一般的な概念を理解していることを前提としています。概念と要件を詳細に理解するために、このブログを参照することをお勧めします。今回のブログの目的のために、SAPシステムのインストールに着手するための前提条件を以下に示します。

• • Admin Access：AWSアカウントは以下の権限があること
    • クラスタソリューションやネットワークファイルシステム(NFS)などで必要なポートを許可するためのセキュリティグループの作成/変更
    • SAP Content Server と SAP MaxDB データベースを実行するための Amazon EFS ファイルシステムを作成/マウント
    • セカンダリノードを作成するためにAmazon Machine Images（AMI）を作成して起動
    • オーバーレイIPを追加するためのルートテーブルの変更
    • クラスタの代わりにAWSリソースを管理できるように、EC2インスタンスのIAMポリシーとロールを作成
    • クラスタ固有のタグ名とインスタンスのホスト名を値として、EC2インスタンス用の新しいタグを作成
    • クラスタインスタンスのソース/デスティネーションチェックの無効化
    • オーバーレイIPを使用して Content Server HTTPエンドポイントに接続するための、ネットワークロードバランサーのプロビジョニング
    • Route53 A レコードを変更するためのオプションのアクセス
  • Amazon EFS: AWSのクラウドサービスやオンプレミスのリソースで使用するための、シンプルでスケーラブルなフルマネージドの弾力性のあるNFSファイルシステムを提供します。SAP Note 2772496にあるように、SAP Content ServerのSAP MaxDBデータベースをホストするストレージ層としてEFSを利用することができます。このサービスは、拡張性、可用性、耐久性に優れた設計となっています。Amazon EFSファイルシステムは、AWSリージョン内の複数のアベイラビリティゾーンにまたがってデータやメタデータを保存します。EFSのこれらの属性により、MaxDBデータベースのスタンバイを設定するための複雑なデータレプリケーションの要件を排除することができます。EFSベースのファイルシステムのスループット容量はプロビジョニング容量に依存するため、共有可能なSAP Content ServerインスタンスとMaxDBストレージファイルシステムをすべてマウントするために単一のEFSを使用しました。

    # mount efs-dns-name: /temp
    # mkdir -p /temp/sapdb /temp/sapmnt /temp/SYS /temp/sapdata /temp/saplog /temp/C00
    # umount /temp

  • オーバーレイIP：オーバーレイIPとは、Amazon Virtual Private Cloud（VPC）内のネットワークトラフィックを、そのサブネットやアベイラビリティゾーンの配置に関係なくEC2インスタンスにリダイレクトできるようにする概念です。これは、現在のVPCのCIDR範囲に含まれない静的なIPアドレスを使用して、VPCのルートテーブルを使用してトラフィックをルーティングします。SUSE HA extension for AWSは、フェイルオーバーシナリオでvpcルーティングテーブルを動的に変更できるリソースを提供します。次のコマンドを使用して、両クラスタノードのeth0インタフェースにオーバーレイIPを追加します。

    # ip address add OVERLAY-IP dev eth0

ソリューションアーキテクチャ

本ブログで取り上げている高可用性アーキテクチャ図を以下に示します。

SAP Content Serverのアプリケーション層とデータベース層は、同じEC2インスタンスにインストールされます。クラスタ内のセカンダリノードは、プライマリのEC2インスタンスのAMIバックアップを使用して、同じAWSリージョン内の別のアベイラビリティゾーンで起動します。これらのEC2インスタンスは、SUSE Linux Enterprise Server (SLES) for SAP ApplicationのAWS Marketplace AMIで起動されます。このAMIには、SUSE High Availability Extension Setがプリインストールされています。現在のアーキテクチャでは、EBSボリュームはルートファイルシステムのみに使用されていることに注意してください。

SAP Content Serverのインストール手順

SAP Note 2786364 では、SAP Content Server と SAP MaxDB データベースのダウンロード、インストール、アップデートの詳細な手順を説明しています。SAP Content Server は、シングルノードサーバとしてインストールされます。プライマリノードをインストールする前に、必要なファイルシステムがすべて適切にマウントされていることを確認してください。これらのファイルシステムの作成には EFS を使用しているため、以下のコマンドを使用してマウントポイントを作成します。

# mkdir -p /usr/sap /usr/sap/CSX /usr/sap/CSX/SYS /usr/sap/CSX/C00 /sapmnt /sapdb /sapdb/data /sapdb/log

SAPプロファイル、バイナリ、MaxDBデータベースバイナリのファイルシステムは、以下のようにfstabエントリを使用してマウントすることができます。

efs-dns-name:SYS /usr/sap/CSX/SYS nfs4 rw,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0
efs-dns-name:sapmnt /sapmnt nfs4 rw,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0
efs-dns-name:sapdb /sapdb nfs4 rw,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0

前の引数は例であることにご注意ください。オプションの包括的なリストについては、推奨される NFS マウントオプションを参照してください。以下のコマンドを使用して、SAP Content Server インスタンスと SAP MaxDB データベースストレージファイルシステムを (手動で) マウントします。

# mount -t efs-dns-name:sapdata /sapdb/data
# mount -t efs-dns-name:saplog /sapdb/log
# mount -t efs-dns-name:C00 /usr/sap/CSX/C00

これらのマウントポイントはクラスタによって管理されるため、fstab でハードコードする必要はありません。

SAP Content Server がそれぞれの SAP MaxDB データベースと共にプライマリノードにインストールされたら、AMI バックアップを作成し、セカンダリノードを計画されたセカンダリアベイラビリティゾーンに構築します。fstab エントリは、基本的なファイルシステムをマウントできるようにする必要があります。

Amazon EFS の構成とパフォーマンスに関する考慮事項

Amazon EFSを作成する際に、お客様は必要なパフォーマンスモードとスループットモードを、お客様の要件に基づいて選択することができます。バーストスループットモードでは、Amazon EFS上のスループットは、標準ストレージクラスのファイルシステムのサイズに比例してスケーリングされます。

例えば、このブログを書いている時点で、汎用パフォーマンスモードとバーストスループットモードを使用した1024GiBのEFSでは、50MiB/sのベースラインスループットと100MiB/sのバーストアグリゲートスループットが、最大バースト持続時間720分/日で提供されます。また、Amazon EFS Performanceのページでは、いくつかの有用なEFSパフォーマンスのヒントを見つけることができます。

HA 構成のステップ

前提条件のセクションで述べたように、クラスタのCorosync通信層の設定が完了すると、Corosync設定ファイルが正常に作成され、以下のコマンドを使用して、両方のノードからクラスタの状態を確認できるようになるはずです。

# crm status

ここでは、以下の手順で MaxDB データベース上で動作する SAP Content Server HA を設定することができます。

1. クラスタをメンテナンスモードに設定します。

   # crm configure property maintenance-mode="true"

2. クラスタベースをファイルで定義します。

   property cib-bootstrap-options: \
       stonith-enabled="true" \
       stonith-action="off" \
       stonith-timeout="600s"
   rsc_defaults rsc-options: \
           resource-stickiness=1 \
           migration-threshold=3
   op_defaults op-options: \
           timeout=600 \
           record-pending=true
   
   # crm configure load update crm-bs.txt

3. STONITHリソースを定義します。
   • EC2インスタンスのタグを<anykey>と値<hostname>で更新します。このブログでは「ペースメーカー」というタグキーを使用しています。
   • AWSプロファイルを<anyname>で定義し、以下の設定を行います。このブログでは、”cluster “を持つプロファイルを使用しています。

     [profile cluster]
     region = <your region>
     output = text

   • AWS固有のstoneithリソースの定義は、ws-stoneith.txtにあります。

     primitive res_AWS_STONITH stonith:external/ec2 \
     op start interval=0 timeout=180 \
     op stop interval=0 timeout=180 \
     op monitor interval=120 timeout=60 \
     params tag=pacemaker profile=cluster

   • STONITHリソース定義をクラスタにロードします。

     # crm configure load update aws-stonith.txt

4. コンテンツサーバのクラスタリソースを設定します。(ここで使用するファイル名 aws_cs.txt)

   primitive rsc_fs_CSX_C00 Filesystem \
   params device="<efs-id>.efs.<your-region>.amazonaws.com:/C00" directory="/usr/sap/CSX/C00" \
   fstype="nfs4" \
   options="rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=200s timeout=40s
   primitive rsc_sap_CSX_C00 SAPInstance \
   operations $id=rsc_sap_CSX_C00-operations \
   op monitor interval=120 timeout=60 on-fail=restart \
   params InstanceName=CSX_C00_sapcontentserv \
   START_PROFILE="/usr/sap/CSX/SYS/profile/CSX_C00_sapcontentserv" \
   AUTOMATIC_RECOVER=false \
   MONITOR_SERVICES="sapcs" \
   meta resource-stickiness=5000 failure-timeout=60 \
   migration-threshold=1 priority=10
   
   group grp_CSX_C00 \
   rsc_fs_CSX_C00 rsc_sap_CSX_C00 \
   meta resource-stickiness=3000
   SAP Content Server クラスタリソース構成をクラスタにロードします。

   # crm configure load update aws_cs.txt
   

5. SAP Host エージェントで制御できるように SAP MaxDB を準備します。
   • DB ファイルシステムのマウント (Content Server のインストール手順を参照)
     を使用してEC2インスタンスにオーバーレイIPを追加します。

     # ip address add <OVERLAY-IP> dev eth0

   • SAP Note 2018919 – SAP MaxDB/SAPHostagent に従います。SetDatabaseProperty関数として接続情報を設定し、SAP MaxDBデータベースにアクセスするようにSAP HostAgentを設定します。

     #/usr/sap/hostctrl/exe/saphostctrl -host <virtualhostname> \
     -user sapadm <password> -dbname <CSX> -dbtype ada \
     -function SetDatabaseProperty DBCredentials=SET \
     -dboption User=SUPERDBA -dboption Password=<password>

   • プライマリノードからOIPとDBマウントポイントをデタッチします。セカンダリノードで以前に使用した手順を繰り返します。
6. SAP MaxDB データベース用のクラスタリソースを設定します。(ここではファイル名 aws_maxdb.txt を使用)

   primitive rsc_ip_CSX_VIP ocf:suse:aws-vpc-move-ip \
   params ip='192.168.10.10' routing_table=<rtb-xxxxxxxxxxxxxxx> \
   interface=eth0 profile=cluster \
   op start interval=0 timeout=180 \
   op stop interval=0 timeout=180 \
   op monitor interval=60 timeout=60
   primitive rsc_fs1_CSX_SDB Filesystem \
   params device="<efs-id>.efs.<your-region>.amazonaws.com:/sapdata" directory="/sapdb/data" \
   fstype="nfs4" \
   options="rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=200s timeout=40s
   primitive rsc_fs2_CSX_SDB Filesystem \
   params device="<efs-id>.efs.<your-region>.amazonaws.com:/saplog" directory="/sapdb/log" \
   fstype="nfs4" \
   options="rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=200s timeout=40s
   primitive rsc_sapdb_CSX_SDB ocf:heartbeat:SAPDatabase \
   params SID="CSX" DBTYPE="ADA" \
   op monitor interval="120s" timeout="60s" start_delay="180s" \
   op start interval="0" timeout="120s" \
   op stop interval="0" timeout="180s"
   
   group grp_CSX_SDB \
   rsc_ip_CSX_VIP rsc_fs1_CSX_SDB rsc_fs2_CSX_SDB rsc_sapdb_CSX_SDB \
   meta resource-stickiness=3000 \
   meta target-role="Started"

   DBリソースの設定をクラスタにロードします。

   # crm configure load update aws_maxdb.txt

7. コンテンツ サーバーと MaxDB が常に同じクラスタ ノードで起動するように、コロケーションと順序の制約を設定します。コンテンツサーバは常にMaxDBデータベースの後に起動されます。(ここではファイル名のcrm_col.txtを使用しています)

   colocation col_sap_CSX_both INFINITY: grp_CSX_SDB grp_CSX_C00
   order ord_sapdb_first_start Mandatory: rsc_sapdb_CSX_SDB:start rsc_fs_CSX_C00:start rsc_sap_CSX_C00:start sequential="true

8. クラスタを起動し、クラスタの状態を監視します。

   # crm configure property maintenance-mode="false"
   # crm status

   

SAP Content Serverのフェイルオーバーをテストする

1. フェイルオーバーのテスト
   • SAP Content Server を他のノードに手動で移動するには、sapcontrol ユーティリティをアクティブなノードの <sid>adm ユーザとして実行します。

     # sapcontrol -nr 00 -function HAFailoverToNode ""

     

2. SAP Content Server の状態を監視します。
   • Content Server HTTP URL (NLB または Route 53 ベースの URL) を使用しています。
     • フェイルオーバー前
       
     • フェイルオーバー後
       
   • SAPシステムでCSADMINトランザクションコードを使用しています。
     • フェイルオーバー前
       
     • フェイルオーバー後
       
   • SAPシステムでRSCMSTプログラムを使用します。 SAP Note2888195 – コンテンツサーバ 7.53 およびレポート RSCMST
     • フェイルオーバー前
       
     • フェイルオーバー後
       

結論

このブログでは、SUSE High Availability Extension setによって、Amazon EFSの組み込み機能を使用してSAP Content Server 7.53の高可用性アーキテクチャを設定する方法をご紹介しました。Amazon EFSを組み込むことで、このソリューションの複雑さが軽減されます。Amazon EFS内のすべてのファイルとディレクトリは、アベイラビリティゾーン内および複数のアベイラビリティゾーンに冗長的に格納されます。

さあ始めましょう

このブログでは、2つのアベイラビリティゾーンを利用してソリューションを作成しました。お客様はさらにAWSリージョン内のすべてのアベイラビリティゾーンにまたがって高可用性ソリューションをセットアップすることができます。また、SAP MaxDBデータベースを使用する代わりに、SAP Content Serverのストレージ層をAmazon EFSを使用したファイルベースのリポジトリに置き換えることで、ソリューションを簡素化することができます。ご質問は sap-on-aws@amazon.com までご連絡いただくか、aws.com/sap_japan をご覧ください。

翻訳はPartner SA 松本が担当しました。原文はこちらです。