Amazon Web Services (AWS) での SAP Netweaver ASCS/ERS ENSA1 の設定
目次
- 1.概要
- 2.要件
- 3.必要な AWS 設定
- 4.SAP Netweaver をインストールする
- 5.ペースメーカーをインストールする
- 6.クラスター設定をテストする
- 7.再起動後のクラスターの自動起動を有効にする
1. 概要
1.1.はじめに
SAP NetWeaver ベースのシステム (SAP ERP、SAP CRM など) はビジネスプロセスで重要なロールを果たしているため、SAP NetWeaver ベースのシステムの可用性が高いことが重要です。クラスタリングの基本的な考え方は非常に単純です。単一の大きなマシンがすべての負荷とリスクを負担するわけではありません。むしろ、障害が発生したサービスまたはマシンの即時完全な代替品として、1 つ以上のマシンが自動的にドロップされます。最良の場合、この交換プロセスはシステムのユーザーに中断を引き起こしません。
1.2.対象者
このドキュメントは、RHEL HA アドオンまたはその他のクラスタリングソリューションを使用して高可用性ソリューションをセットアップした経験を持つ、SAP、Red Hat、AWS の認定またはトレーニングを受けた管理者およびコンサルタントを対象としています。ソフトウェアと追加ドキュメントをダウンロードするには、SAP Service Marketplace と Red Hat Customer Portal の両方にアクセスする必要があります。
1.3.コンセプト
このドキュメントでは、SAP と Red Hat の両方、特に AWS で確立された高可用性のガイドラインに準拠する 2 ノードクラスターソリューションをセットアップする方法について説明します。これは、RHEL HA アドオンを備えた Red Hat Enterprise Linux 7.5 以降上の SAP NetWeaver に基づいています。このドキュメントで説明されているリファレンスアーキテクチャーは、SAP High Availability Interface 認定 NW-HA-CLU 7.50 のテストを受けています。この文書は認証取得後に更新されます。
アプリケーション層では、エンキューサーバーのロックテーブルが最も重要な部分です。これを保護するために、SAP はロックテーブルのバックアップコピーを保持するエンキューレプリケーションサーバー (ERS) を開発しました。(A)SCS がノード 1 で実行されている間、ERS は常に、現在のエンキューテーブルのコピーをノード 2 に維持する必要があります。システムが (A)SCS をノード 2 にフェイルオーバーする必要がある場合、まずノード 2 で起動し、次に ERS をシャットダウンし、その共有メモリーセグメントを引き継ぎ、それによって最新のエンキューテーブルを取得します。テーブルが新しいプライマリーエンキューテーブルになります。ERS は、ノード 1 が使用可能になると開始されます。
SAP HA-Interface 認定で義務付けられているこのドキュメントは、(A)SCS と ERS の高可用性に焦点を当てており、どちらもクラスターソフトウェアによって制御されます。通常モードでは、クラスターは ERS と (A)SCS が常に異なるノードで実行されるようにします。フェイルオーバーが発生した場合、(A)SCS は ERS をフォローする必要があります。(A) SCS は、ERS が実行されているノードに切り替える必要があります。(A)SCS は複製されたエンキューテーブルを ERS から引き継ぐ必要があるため、クラスターは、(A)SCS の起動時に ERS がすでに実行されていることを確認する必要があります。
上記の概念はスタンドアロンエンキューサーバー 1 (ENSA1) として知られており、ABAP 1709 以前で利用できます。ABAP 1809 以降のデフォルトのインストールとなっているスタンドアロンエンキューサーバー 2 (ENSA2) については、Amazon Web Services (AWS) での SAP S/4 ASCS/ERS ENSA2 の設定を 確認してください。
1.4.リソース: スタンドアロンとマスター/スレーブ
Pacemaker で (A)SCS および ERS リソースを設定するには、マスター/スレーブとスタンドアロンの 2 つのアプローチがあります。マスター/スレーブアプローチは、すべての RHEL 7 マイナーリリースですでにサポートされています。スタンドアロンアプローチは、RHEL 7.5 以降でサポートされています。
新しいデプロイメントでは、次の理由からスタンドアロンが推奨されます。
- 現在の SAP HA インターフェイス認定の要件を満たしています。
- 新しい Standalone Enqueue Server 2 (ENSA2) 設定と互換性があります。
- (A) SCS/ERS インスタンスは独立して起動および停止可能
- (A) SCS/ERS インスタンスディレクトリーはクラスターの一部として管理できます。
この記事では、SAPinstance スタンドアロンアプローチの設定手順の概要を説明します。SAPInstance マスター/スレーブ設定の手順については、kabse 記事 マスター/スレーブ SAPInstance リソースを使用した Pacemaker クラスターの SAP Netweaver を参照してください。
1.5.サポートポリシー
参照先: RHEL High Availability クラスターのサポートポリシー - クラスター内の SAP Netweaver の管理
Amazon Web Services に固有の部分に注意してください。
2.要件
2.1.サブスクリプション
サブスクリプション、カーネル、パッチレベルを両方のノードで同一に保つことが重要です。
AWS で RHEL For SAP Solutions サブスクリプションを利用するには、Pay As You Go (PAYG) または Bring Your Own Subscription (BYOS) の 2 つの方法があります。
2.1.1.従量課金制 - HA および US を備えた RHEL for SAP
AWS Marketplace の 高可用性および更新サービスを備えた RHEL for SAP の AMI イメージを使用して、RHEL インスタンスを起動できます。
2.1.2.Bring Your Own Subscription - SAP ソリューション向け Red Hat Enterprise Linux
RHEL for SAP Solutions サブスクリプションをオンプレミスから AWS に移植するには、Red Hat Cloud Access プログラムに登録し、未使用の RHEL for SAP Solutions サブスクリプションを持っている必要があります。
この kbase 記事 に従って、システムを SAP ソリューション用 RHEL の更新サービスにサブスクライブしてください。
注: AWS に移行された 1 つの未使用のサブスクリプションは、2 つの RHEL EC2 インスタンスに使用できます。たとえば、未使用のサブスクリプションが 2 つあれば、4 つの EC2 インスタンスを作成することができます。
2.2.Pacemaker リソースエージェント
ASCS/ERS スタンドアロンアプローチは、SAPInstance リソースエージェントの IS_ERS 属性を含む resource-agents-sap-3.9.5-124.el7.x86_64 以降でサポートされています。これは、次の RHEL リリースに含まれています。
- AWS Marketplace: HA および US 7.5 以降を備えた RHEL for SAP
- クラウドアクセス: RHEL for SAP Solutions 7.5 以降
2.3.SAP NetWeaver 高可用性アーキテクチャー
SAP NetWeaver High-Availability の一般的なセットアップは、次の 3 つの特徴的なコンポーネントで設定されます。
- SAP Netweaver ASCS/ERS クラスターリソース
- SAP Netweaver アプリケーションサーバー - プライマリーアプリケーションサーバー (PAS) および追加のアプリケーションサーバー (AAS)
- データベース: SAP HANA または Oracle/DB2/ASE/MaxDB
この記事では、ペースメーカークラスター内の SAP Netweaver ASCS および ERS の設定に焦点を当てます。ベストプラクティスとして、(A)SCS および ERS 用に指定された 2 ノードクラスターの外側の別のノードにアプリケーションサーバーとデータベースをインストールすることを推奨します。
以下は、インストール例のアーキテクチャー図です。
2.4.SAP インスタンス リソースエージェント
SAPInstance は、 ASCS リソースと ERS リソースの両方に使用されるペースメーカーリソースエージェントです。SAPInstance リソースエージェントのすべての操作は、SAP 開始サービスフレームワーク sapstartsrv を使用して実行されます。
2.5.ストレージ要件
Netweaver のインストール用に作成されたディレクトリーは、次のルールに従って共有ストレージに配置する必要があります。
2.5.1.インスタンス固有のディレクトリー
ASCS と ERS のインスタンス固有のディレクトリーは、それぞれ対応するノード上に存在する必要があります。これらのディレクトリーは、クラスターが開始される前に使用可能になっている必要があります。
- ASCS ノード:/usr/sap/SID/ASCS<Ins#>
- ERS ノード:/usr/sap/SID/ERS<Ins#>
アプリケーションサーバーの場合、アプリケーションサーバーインスタンス用に指定された対応するノードで次のディレクトリーを使用できるようにする必要があります。
- アプリケーションサーバー D<Ins#>:/usr/sap/SID/D<Ins#>
2.5.2.共有ディレクトリー
次のマウントポイントは、ASCS、ERS、およびアプリケーションサーバーノードで使用できる必要があります。
/sapmnt
/usr/sap/trans
/usr/sap/SID/SYS
2.5.3.HANA 上の共有ディレクトリー
次のマウントポイントが HANA ノードで利用可能である必要があります。
/sapmnt
これらのマウントポイントは、クラスターによって管理されるか、クラスターの開始前に マウントされる 必要があります。
2.5.4.共有ストレージとしての Amazon EFS
Amazon Elastic File System (Amazon EFS) は、Amazon EC2 インスタンスにシンプルでスケーラブルな共有ファイルストレージサービスを提供します。このドキュメントの設定では、Amazon EFS を共有ストレージとして使用し、NFS としてマウントします。
3.必要な AWS 設定
3.1.AWS の初期セットアップ
AWS 環境の初期セットアップの手順については、Amazon Web Services での Red Hat Enterprise Linux 7.4 (以降) 高可用性クラスターのインストールと設定を 参照してください。
要約すると、次のコンポーネントを設定しておく必要があります。
- AWS アカウント
- キーペア
- ルーティングテーブルの変更とセキュリティーグループの作成、IAM ポリシーとロールの作成を行う権限を持つ IAM ユーザー
- 1 つの VPC
- 3 つのサブネット: 2 つの異なるアベイラビリティゾーンにまたがる 1 つのパブリックサブネットと 2 つのプライベートサブネット (ゾーン単位の障害に関連するサービスの中断を最小限に抑えるために推奨されます)。ただし、単一のアベイラビリティーゾーンも許容されます)
- NAT ゲートウェイ
- ジャンプサーバーのセキュリティーグループ
- Netweaver インスタンスのセキュリティーグループ
- GUI アクセス用のリモートデスクトッププロトコル (RDP)
3.2.サポートされている SAP NW インスタンスのタイプとストレージを選択します
サイズ要件に基づいて、ASCS/ERS およびアプリケーションサーバーにそれぞれ適切なインスタンスタイプを選択します。
- ASCS と ERS の 2 つのノードを異なるアベイラビリティゾーンに作成することを推奨します。
- アクセスを有効にするには、秘密キーをジャンプサーバーと各 Netweaver ノードにコピーします。
サービス -> EC2 -> イメージ -> AMI で、次の AMI のいずれかを選択します。
- クラウドアクセス経由の Bring Your Own Subscription 用
RHEL 7.5 RHEL for SAP と HA および US 7.5による Pay As You Go
ジャンプサーバーの AMI とインスタンスタイプ:
- 無料利用枠からインスタンスタイプを選択できます (例: 30 GiB EBS ストレージボリュームの t2.micro)。
RHEL 7.5で十分です。RHELfor SAP SolutionsやRHEL for SAP with HA および USを使用する必要はありません。
Netweaver ノードを作成したら、次のセクションで使用する次の情報に注意してください。
- リージョン: 例:
us-east-1 - AWS ユーザーアカウントのアカウント ID
- 2 つの ASCS/ERS ノードのインスタンス ID
- AWS Access Key ID
- AWS Secret Access Key
この例では、次の EC2 インスタンスが作成されます。
node1: ASCS/ERS cluster node 1
node2: ASCS/ERS cluster node 2
nwhana1: HANA node
nwpas: Primary Application Server node
nwaas: Additional Application Server node
3.3.ポリシーの作成
IAM ユーザーの場合、次の 3 つのポリシーを作成する必要があります。
サービス -> IAM -> ポリシー -> データプロバイダー ポリシーの作成:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"EC2:DescribeInstances",
"EC2:DescribeVolumes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "cloudwatch:GetMetricStatistics",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::aws-data-provider/config.properties"
}
]
}
サービス -> IAM -> ポリシー -> OverlayIPAgent ポリシーの作成:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1424870324000",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeTags",
"ec2:DescribeRouteTables"
],
"Resource": "*"
},
{
"Sid": "Stmt1424860166260",
"Action": [
"ec2:CreateRoute",
"ec2:DeleteRoute",
"ec2:ReplaceRoute"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:<region>:<account-id>:route-table/<ClusterRouteTableID>"
}
]
}
最後の Resource 句で、次のパラメーターを実際の値に置き換えます。
地域: 例:us-east-1account-id: ユーザーアカウントのアカウント IDClusterRouteTableID: 既存のクラスター VPC ルートテーブルのルートテーブル ID (rtb-XXXXX の形式)。
サービス -> IAM -> ポリシー -> STONITH ポリシーの作成:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1424870324000",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "Stmt1424870324001",
"Effect": "Allow",
"Action": [
"ec2:ModifyInstanceAttribute",
"ec2:RebootInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:<region>:<account-id>:instance/<instance-id-node1>",
"arn:aws:ec2:<region>:<account-id>:instance/<instance-id-node2>"
]
}
]
}
最後の Resource 句で、次のパラメーターを実際の値に置き換えます。
地域: 例:us-east-1account-id: ユーザーアカウントのアカウント IDinstance-id-node1、instance-id-node2: 2 つの SAP ASCS/ERS インスタンスのインスタンス ID
3.4.IAM ロールを作成する
IAM ロールを作成し、前の手順で作成した 3 つのポリシーをアタッチし、そのロールを 2 つの ASCS/ERS インスタンスに割り当てます。
- EC2 -> IAM -> ロール -> 新しいロール (例:
PacemakerRole)を作成し、それに 3 つのポリシー (DataProvider、OverlayIPAgent、およびSTONITH)をアタッチします。 - ASCS/ERS および HANA インスタンスにロールを割り当てます。すべての ノードに対して実行します。AWS EC2 コンソールで ノードを右クリックし、インスタンス設定 -> IAM ロールのアタッチ/置換 -> PacemakerRole を選択し、適用 をクリックします。
3.5.AWS CLI をインストールする
AWS CLI のインストール セクションに従って、ASCS/ERS および HANA ノードに AWS CLI 設定をインストールして確認します。
3.6.EFS ファイルシステムを設定する
3.6.1.EFS ファイルシステムの作成
AWS コンソール -> EFS -> ファイルシステムの作成 -> Netweaver インストールの VPC と、Netweaver ノードと HANA ノードが実行されているアベイラビリティゾーンを選択して、ノードが EFS ファイルシステムにアクセスできるようにします。
この例では、EFS ファイルシステムが作成されています: fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/
3.6.2.EFS を NFS としてマウントする
EFS ボリュームのルートディレクトリーをマウントします。
# mkdir /mnt/efs
# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs
3.6.3.サブディレクトリーの作成
EFS ボリューム上に、SAP Netweaver HA インストールで使用されるさまざまな共有ファイルシステムとしてマウントされるサブディレクトリーを作成します。
[root@node1 ~]# cd /mnt/efs
[root@node1 efs]# mkdir RH2 trans sapmnt
[root@node1 efs]# chmod 777 *
[root@node1 efs]# cd RH2
[root@node1 RH2]# mkdir SYS ASCS20 D21 D22 ERS29
[root@node1 RH2]# chmod 777 *
3.7.オーバーレイ IP アドレスの作成
AWS では、IP フェイルオーバーの仮想 IP はオーバーレイ IP アドレスによって実現されます。詳細については 、オーバーレイ IP アドレスによる IP フェイルオーバー を参照してください。
3.7.1.仮想 IP を決定する
この例では、次のインスタンスに仮想 IP が必要です。IP アドレスが他のアプリケーションで使用されていないことを確認してください。
ASCS virtual hostname and IP: rhascs 192.168.200.101
ERS virtual hostname and IP: rhers 192.168.200.102
HANA virtual hostname and IP: rhdb 192.168.200.103
3.7.2.送信元/宛先を無効にします。チェック
送信元/宛先を無効にします。3 つのインスタンス (node1、node2、nwhana1) を確認します。
AWS コンソールで、それぞれのインスタンスを右クリックし、ネットワーク -> ソース/宛先の変更を選択します。チェック→ポップアップウィンドウではい、無効にするをクリックします。
3.7.3.オーバーレイ IP をそれぞれのインスタンスにマップする
Netweaver インストールの場合、仮想ホスト名と仮想 IP はそれぞれ次のインスタンスにマッピングされます。
node1 rhascs 192.168.200.101
node2 rhers 192.168.200.102
nwhana1 rhdb 192.168.200.103
ノード 1 で次のコマンドを実行します。AWS CLI がインストールされている必要があります。(マッピングは、AWS コンソールを通じてルーティングテーブルに追加することもできます)
# echo $(curl -s http://169.254.169.254/latest/meta-data/instance-id)
I-0b1c0612341288612
# aws ec2 create-route --route-table-id rtb-9dd99ee2 --destination-cidr-block 192.168.200.101/32 --instance-id I-0b1c0612341288612
node2 と nwhana1 で手順を繰り返します。
AWS コンソールを確認すると、ルーティングテーブル rtb-9dd99ee2 にマッピングが表示されているはずです。
3.7.4.それぞれのインスタンスに仮想 IP アドレスを追加します
対応する各インスタンスに IP アドレスを追加します。
[root@node1 ~]# ip address add 192.168.200.101 dev eth0
[root@node2 ~]# ip address add 192.168.200.102 dev eth0
[root@nwhana1 ~]# ip address add 192.168.200.103 dev eth0
3.7.5.すべてのインスタンスの/etc/hosts に Virt IP アドレスを追加します。
Netweaver インストールのすべてのインスタンスで、仮想 IP とホスト名のマッピングを /etc/hosts ファイルに追加します。
[root]# cat /etc/hosts
192.168.200.101 rhascs
192.168.200.102 rhers
192.168.200.103 rhdb
3.7.6.仮想 IP アドレスをテストする
仮想 IP アドレスに到達でき、仮想ホスト名が解決できることを確認してください。また、仮想 IP またはホスト名を使用してノードへの SSH 接続を試みます。
3.8.オプション - Route 53 エージェントの設定
トラフィックを Amazon EC2 インスタンスにルーティングするには、Route 53 エージェントが必要です。ドキュメントに従って設定してください。
4.SAP Netweaver をインストールする
4.1.このドキュメントで使用する設定オプション
以下は、このドキュメントのインスタンスに使用される設定オプションです。
2 つのノードがペースメーカーで ASCS/ERS インスタンスを実行します。
1st node hostname: node1
2nd node hostname: node2
SID: RH2
ASCS Instance number: 20
ASCS virtual hostname: rhascs
ERS Instance number: 29
ERS virtual hostname: rhers
2 ノードクラスターの外側:
PAS Instance number: 21
AAS Instance number: 22
HANA データベース:
SID: RH0
HANA Instance number: 00
HANA virtual hostname: rhdb
4.2.ホストの準備
インストールを開始する前に、次のことを確認してください。
- RHEL 7.5 以降をインストールする
HA および US AMI で RHEL for SAPを使用する場合:HA および US AMI を備えた RHEL for SAP7.5 以降を使用してインスタンスを作成する
- クラウドアクセス経由で
RHEL for SAP ソリューションを使用する場合:- SAP ソリューション 7.5 以降の RHEL をインストールする
- システムを RHN または Satellite に登録し、SAP アプリケーションチャネルまたは Update Services (E4S) チャネルに対して RHEL を有効にします。
- 高可用性アドオンチャネルを有効にする
- 共有ストレージとファイルシステムが正しいマウントポイントに存在する
- インスタンスによって使用される仮想 IP アドレスが存在し、到達可能である
- インスタンスによって使用されるホスト名を IP アドレスに解決したり、逆に解決したりできます。
- インストールメディアが利用可能です
- システムは、SAP Netweaver を実行するための推奨事項に従って設定されています
- Red Hat Enterprise Linux 7.x: Installation and Upgrade - SAP Note 2002167
4.3.ネットウィーバーをインストールする
ソフトウェアプロビジョニングマネージャー (SWPM) を使用して、次の順序でインスタンスをインストールします。
- ASCS インスタンス
- ERS インスタンス
- DB インスタンス
- PAS インスタンス
- AAS インスタンス
4.3.1.ASCS をノード 1 にインストールする
次のファイルシステムは、ASCS がインストールされるノード 1 にマウントする必要があります。
[root@node1 ~]# mkdir /sapmnt
[root@node1 ~]# mkdir -p /usr/sap/trans /usr/sap/RH2/SYS /usr/sap/RH2/ASCS20
[root@node1 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/sapmnt /sapmnt
[root@node1 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/trans /usr/sap/trans
[root@node1 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/RH2/SYS /usr/sap/RH2/SYS
[root@node1 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/RH2/ASCS20 /usr/sap/RH2/ASCS20
rhascs の仮想 IP は、node1 で有効にする必要があります。
インストーラーを実行します。
[root@node1]# ./sapinst SAPINST_USE_HOSTNAME=rhascs
高可用性システム オプションを選択します。
4.3.2.ERS をノード 2 にインストールする
次のファイルシステムは、ERS がインストールされるノード 2 にマウントする必要があります。
[root@node2 ~]# mkdir /sapmnt
[root@node2 ~]# mkdir -p /usr/sap/trans /usr/sap/RH2/SYS /usr/sap/RH2/ERS29
[root@node2 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/sapmnt /sapmnt
[root@node2 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/trans /usr/sap/trans
[root@node2 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/RH2/SYS /usr/sap/RH2/SYS
[root@node2 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RHEL-NW-HA-750/RH2/ERS29 /usr/sap/RH2/ERS29
rhers の仮想 IP は、node2 で有効にする必要があります。
インストーラーを実行します。
[root@node2]# ./sapinst SAPINST_USE_HOSTNAME=rhers
高可用性システム オプションを選択します。
4.3.3.SAP HANA
この例では、SAP HANA は次の設定を使用します。サポートされている他のデータベースを使用することもできます。
SAP HANA SID: RH0
SAP HANA Instance number: 00
SAP HANA は別のホストにインストールする必要があります。オプションで、ドキュメント Amazon Web Services の Pacemaker での SAP HANA システムレプリケーションの設定に従って、自動 HANA システムレプリケーションを 別の Pacemaker クラスターにインストールできます。
HANA ホストでインストーラーを実行します。
[root]# ./sapinst SAPINST_USE_HOSTNAME=rhdb
4.3.4.アプリケーションサーバーのインストール
Application Server インスタンスを実行するには、次のファイルシステムをホストにマウントする必要があります。複数のアプリケーションサーバーがある場合は、それぞれを対応するホストにインストールします。
/usr/sap/RH2/D<Ins#>
/usr/sap/RH2/SYS
/usr/sap/trans
/sapmnt
インストーラーを実行します。
[root]# ./sapinst
高可用性システム オプションを選択します。
4.4.インストール後の設定
4.4.1.(A)SCS プロファイルの変更
(A) SCS インスタンスはクラスターによって管理されるため、エンキューサーバーの自動再起動を防ぐために、プロファイルを次のように変更する必要があります。変更を適用するには、ASCS プロファイル /sapmnt/RH2/profile/RH2_ASCS20_rhascs で次のコマンドを実行します。
[root]# sed -i -e 's/Restart_Program_01/Start_Program_01/' /sapmnt/RH2/profile/RH2_ASCS20_rhascs
4.4.2.ERS プロファイルの変更
ERS インスタンスはクラスターによって管理されるため、自動再起動を防ぐためにプロファイルを次のように変更する必要があります。変更を適用するには、ERS プロファイル /sapmnt/RH2/profile/RH2_ERS29_rhers で次のコマンドを実行します。
[root]# sed -i -e 's/Restart_Program_00/Start_Program_00/' /sapmnt/RH2/profile/RH2_ERS29_rhers
4.4.3./usr/sap/sapservices ファイルを更新します。
ノード 1 とノード 2 の両方で、/usr/sap/sapservices ファイルで次の 2 行がコメントアウトされていることを確認します。
#LD_LIBRARY_PATH=/usr/sap/RH2/ASCS20/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/RH2/ASCS20/exe/sapstartsrv pf=/usr/sap/RH2/SYS/profile/RH2_ASCS20_rhascs -D -u rh2adm
#LD_LIBRARY_PATH=/usr/sap/RH2/ERS29/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/RH2/ERS29/exe/sapstartsrv pf=/usr/sap/RH2/ERS29/profile/RH2_ERS29_rhers -D -u rh2adm
4.4.4.フェイルオーバーノードで ASCS と ERS のマウントポイントを作成する
それぞれ:
[root@node1 ~]# mkdir /usr/sap/RH2/ERS29
[root@node1 ~]# chown rh2adm:sapsys /usr/sap/RH2/ERS29
[root@node2 ~]# mkdir /usr/sap/RH2/ASCS20
[root@node2 ~]# chown rh2adm:sapsys /usr/sap/RH2/ASCS20
4.4.5.他のノードでインスタンスを開始する手動テスト
ASCS および ERS インスタンスを停止します。インスタンス固有のディレクトリーを他のノードに移動します。
[root@node1 ~]# umount /usr/sap/RH2/ASCS20
[root@node2 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RH2/ASCS20 /usr/sap/RH2/ASCS20
[root@node2 ~]# umount /usr/sap/RH2/ERS29
[root@node1 ~]# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx:/RH2/ERS29 /usr/sap/RH2/ERS29
ASCS と ERS のオーバーレイ IP をそれぞれ他のノードに移動します。
[root@node1 ~]# ip address del 192.168.200.101 dev eth0
[root@node2 ~]# ip address del 192.168.200.102 dev eth0
[root@node2 ~]# ip address add 192.168.200.101 dev eth0
[root@node1 ~]# ip address add 192.168.200.102 dev eth0
新しいクラスターノードで ASCS インスタンスと ERS インスタンスを手動で起動し、それぞれ手動で停止します。
4.4.6.すべてのノードで SAP HostAgent を確認する
すべてのノードで、SAP HostAgent のバージョンが同じであり、最小バージョン要件を満たしているかどうかを確認します。
[root]# /usr/sap/hostctrl/exe/saphostexec -version
SAP HostAgent をアップグレード/インストールするには、SAP ノート 1031096 に従ってください。
4.4.7.恒久的な SAP ライセンスキーをインストールする
高可用性シナリオでの SAP ハードウェアキーの決定が改善されました。各クラスターノードのハードウェアキーに基づいて、複数の SAP ライセンスキーをインストールする必要がある場合があります。詳細については、SAP Note 1178686 - Linux: SAP ハードウェアキーを生成する代替方法を参照してください。
5.Pacemaker をインストールする
Pacemaker のドキュメントに従ってください: HA アドオンリファレンス - RHEL 7。
以下はペースメーカーを取り付けるサンプル手順です。Red Hat コンサルタントと協力して、環境に Pacemaker をインストールして設定することを推奨します。
5.1Pacemaker rpm をインストールする
# yum -y install pcs pacemaker fence-agents-aws
# passwd hacluster
[provide a password]
# mkdir -p /var/log/pcsd
# systemctl enable pcsd.service; systemctl start pcsd.service
5.2.クラスターを作成する
nwha という名前のクラスターを作成し (node1 と node2 で設定)、クラスターを開始します。この時点では、クラスターは再起動後に自動起動するようにまだ設定されていないことに注意してください。
# mkdir -p /var/log/cluster
# pcs cluster auth node1 node2
# pcs cluster setup --name nwha node1 node2
# pcs cluster start --all
5.2.1.一般的なクラスターのプロパティーを定義する
リソースの固定性を設定します。
# pcs resource defaults resource-stickiness=1
# pcs resource defaults migration-threshold=3
5.3.STONITH の設定
5.3.1.インスタンス ID を調べる
次のステップで使用するために、node1 と node2 のインスタンス ID をメモしておきます。
[root@node1]# echo $(curl -s http://169.254.169.254/latest/meta-data/instance-id)
i-0b1c0612341288612
[root@node2]# echo $(curl -s http://169.254.169.254/latest/meta-data/instance-id)
i-0e4e940fbbcb87337
5.3.2.STONITH の作成
# pcs stonith create stonith-nwha fence_aws region=us-east-1 \
pcmk_host_map="node1:i-0b1c0612341288612;node2:i-0e4e940fbbcb87337" \
power_timeout=240 pcmk_reboot_timeout=600 pcmk_reboot_retries=4 \
pcmk_max_delay=45 op start timeout=600 op stop timeout=600 op monitor interval=180
# pcs config
...
Stonith Devices:
Resource: stonith-hanasr (class=stonith type=fence_aws)
Attributes: pcmk_host_map=node1:i-01e958df71a17cbb5;node2:i-0821bf7b586a564ba pcmk_reboot_retries=4 pcmk_reboot_timeout=480 power_timeout=240 region=us-east-1
Operations: monitor interval=60s (stonith-hanasr-monitor-interval-60s)
Fencing Levels:
...
5.3.3.テストフェンシング
STONITH を設定した後、ノード 1 で ノード 2 の フェンシングをテストします。
[root@node1]# pcs stonith fence node2
ノード 2 は 適切にフェンスで囲まれている必要があります。フェンシング後、次のコマンドを使用してノード 2 でクラスターを起動します。これは、クラスターの自動起動がまだ有効になっていないためです。自動開始は、クラスターが適切に設定されていることを示す初期テスト後に有効になります。
[root@node2 ~]# pcs cluster start
5.4.resource-agents-sap を ノード 1 とノード 2 の両方にインストールします
[root]# yum install resource-agents-sap
5.5共有ファイルシステムのクラスターリソースを設定する
すべてのクラスターノードに次のマウントポイントを提供するように共有ファイルシステムを設定します。
/sapmnt
/usr/sap/trans
/usr/sap/RH2/SYS
5.5.1.クラスターによって管理される共有ファイルシステムを設定する
以下に示すように、複製された ファイルシステム クラスターリソースを使用して、外部 NFS サーバーからすべてのクラスターノードに共有をマウントできます。
注: --clone オプションは RHEL 7 では機能しますが、RHEL 8 では機能しません。したがって、RHEL 8 の場合、クローンリソースを作成する現在の方法は、--clone を使用せずにリソースを作成し、pcs resource clone を実行してクローンを作成することです。
RHEL 7 の場合
# pcs resource create rh2_fs_sapmnt Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/sapmnt' directory='/sapmnt' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport' --clone interleave=true
# pcs resource create rh2_fs_sap_trans Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/trans' directory='/usr/sap/trans' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport' --clone interleave=true
# pcs resource create rh2_fs_sys Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/RH2/SYS' directory='/usr/sap/RH2/SYS' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport' --clone interleave=true
RHEL 8 の場合
# pcs resource create rh2_fs_sapmnt Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/sapmnt' directory='/sapmnt' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport'
# pcs resource clone rh2_fs_sapmnt interleave=true
# pcs resource create rh2_fs_sap_trans Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/trans' directory='/usr/sap/trans' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport'
# pcs resource clone rh2_fs_sap_trans interleave=true
# pcs resource create rh2_fs_sys Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/RH2/SYS' directory='/usr/sap/RH2/SYS' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport'
# pcs resource clone rh2_fs_sys interleave=true
ファイルシステム リソースを作成した後、すべてのノードでそれらが適切に開始されていることを確認します。
[root]# pcs status
...
Clone Set: rh2_fs_sapmnt-clone [rh2_fs_sapmnt]
Started: [ node1 node2 ]
Clone Set: rh2_fs_sap_trans-clone [rh2_fs_sap_trans]
Started: [ node1 node2 ]
Clone Set: rh2_fs_sys-clone [rh2_fs_sys]
Started: [ node1 node2 ]
...
5.5.2.クラスター外で管理される共有ファイルシステムを設定する
共有ファイルシステムがクラスターによって管理されない場合は、Pacemaker サービスが開始される前にそれらが使用可能であることを確認する必要があります。
RHEL 7 では、systemd 並列化のため、共有ファイルシステムが resource-agents-deps ターゲットで開始されていることを確認する必要があります。詳細については、ドキュメントセクションを参照してください。 9.6.Pacemaker によって管理されないリソースの依存関係の起動順序の設定 (Red Hat Enterprise Linux 7.4 以降)。
5.6.ASCS リソースグループの設定
5.6.1.仮想 IP アドレスのリソースを作成する
# pcs resource create rh2_vip_ascs20 aws-vpc-move-ip ip=192.168.200.101 interface=eth0 routing_table=rtb-9dd99ee2 --group rh2_ASCS20_group
注: このドキュメントの以前のバージョンには、上記のコマンドに monapi=true オプションが含まれていました。これはプローブ操作のバグの回避策であり、その後修正されました。ただし、monapi=true に設定すると、API スロットリングなどの外部要因により、不必要なフェイルオーバーが発生する可能性があります。このため、Red Hat と Amazon は monapi=true を設定することを推奨してい ません。バグ修正が含まれるように、OS マイナーリリース用の リソースエージェント パッケージの利用可能な最新バージョンがインストールされていることを確認してください。
5.6.2.ASCS ファイルシステムのリソースを作成する
# pcs resource create s4h_fs_ascs20 Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/RHEL-S4-HA/S4H/ASCS20' directory=/usr/sap/S4H/ASCS20 fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport' force_unmount=safe --group s4h_ASCS20_group
5.6.3.ASCS インスタンスのリソースを作成する
# pcs resource create rh2_ascs20 SAPInstance InstanceName="RH2_ASCS20_rhascs" \
START_PROFILE=/sapmnt/RH2/profile/RH2_ASCS20_rhascs \
AUTOMATIC_RECOVER=false \
meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \
--group rh2_ASCS20_group \
op monitor interval=20 on-fail=restart timeout=60 \
op start interval=0 timeout=600 \
op stop interval=0 timeout=600
注: meta resource-stickiness=5000 は、 ERS によるフェイルオーバー制約のバランスを取るためのもので、リソースが開始されたノードに留まり、制御不能にクラスター内を移動しないようにします。
グループにリソーススティッキネスを追加して、可能であれば ASCS がノードに留まるようにします。
# pcs resource meta rh2_ASCS20_group resource-stickiness=3000
5.7.ERS リソースグループの設定
5.7.1.仮想 IP アドレスのリソースを作成する
# pcs resource create rh2_vip_ers29 aws-vpc-move-ip ip=192.168.200.102 interface=eth0 routing_table=rtb-9dd99ee2 --group rh2_ERS29_group
注: このドキュメントの以前のバージョンには、上記のコマンドに monapi=true オプションが含まれていました。これはプローブ操作のバグの回避策であり、その後修正されました。ただし、monapi=true に設定すると、API スロットリングなどの外部要因により、不必要なフェイルオーバーが発生する可能性があります。このため、Red Hat と Amazon は monapi=true を設定することを推奨してい ません。バグ修正が含まれるように、OS マイナーリリース用の リソースエージェント パッケージの利用可能な最新バージョンがインストールされていることを確認してください。
5.7.2.ERS ファイルシステムのリソースを作成する
# pcs resource create s4h_fs_ers29 Filesystem device='fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/RHEL-S4-HA/S4H/ERS29' directory='/usr/sap/S4H/ERS29' fstype='nfs4' options='nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport' force_unmount=safe --group s4h_ERS29_group
5.7.3.ERS インスタンスのリソースを作成する
ERS インスタンスクラスターリソースを作成します。注: ENSA2 デプロイメントでは、IS_ERS 属性はオプションです。IS_ERS の詳細については、スタンドアロンエンキューサーバー (ENSA1 および ENSA2) を使用する SAP NetWeaver クラスターで IS_ERS 属性がどのように機能しますか? で追加情報を参照してください。。
# pcs resource create rh2_ers29 SAPInstance InstanceName="RH2_ERS29_rhers" \
START_PROFILE=/sapmnt/RH2/profile/RH2_ERS29_rhers \
AUTOMATIC_RECOVER=false \
IS_ERS=true \
--group rh2_ERS29_group \
op monitor interval=20 on-fail=restart timeout=60 \
op start interval=0 timeout=600 \
op stop interval=0 timeout=600
5.8.制約を作成する
5.8.1.ASCS および ERS リソースグループのコロケーション制約を作成する
リソースグループ rh2_ASCS20_group と rh2_ERS29_group は、同じノードで実行しないようにする必要があります。グループの順序は重要です。
# pcs constraint colocation add rh2_ERS29_group with rh2_ASCS20_group -5000
5.8.2.ASCS リソースの場所の制約を作成する
ASCS20 インスタンス rh2_ascs20 は、 フェイルオーバーが発生しているときに、以前に ERS が実行されていたノードでの実行を優先します。
# pcs constraint location rh2_ascs20 rule score=2000 runs_ers_RH2 eq 1
5.8.3.ASCS および ERS リソースグループの順序制約を作成する
rh2_ERS29_group よりも前に rh2_ASCS20_group を開始することを優先します (オプション)
# pcs constraint order start rh2_ASCS20_group then stop rh2_ERS29_group symmetrical=false kind=Optional
6.クラスター設定をテストする
6.1.制約を確認してください
# pcs constraint
Location Constraints:
Resource: rh2_ascs20
Constraint: location-rh2_ascs20
Rule: score=2000
Expression: runs_ers_RH2 eq 1
Ordering Constraints:
start rh2_ASCS20_group then start rh2_ERS29_group (kind:Optional) (non-symmetrical)
Colocation Constraints:
rh2_ERS29_group with rh2_ASCS20_group (score:-5000)
Ticket Constraints:
6.2.ノードクラッシュによるフェイルオーバー ASCS
クラッシュ前は、ASCS がノード 1 で実行され、ERS がノード 2 で実行されていました。
# pcs status
...
Resource Group: rh2_ASCS20_group
rh2_vip_ascs20 (ocf::heartbeat:aws-vpc-move-ip): Started node1
rh2_fs_ascs20 (ocf::heartbeat:Filesystem): Started node1
rh2_ascs20 (ocf::heartbeat:SAPInstance): Started node1
Resource Group: rh2_ERS29_group
rh2_vip_ers29 (ocf::heartbeat:aws-vpc-move-ip): Started node2
rh2_fs_ers29 (ocf::heartbeat:Filesystem): Started node2
rh2_ers29 (ocf::heartbeat:SAPInstance): Started node2
...
ノード 2 で次のコマンドを実行して、クラスター内のステータスの変化を監視します。
[root@node2 ~]# crm_mon -Arf
次のコマンドを実行して、node1 をクラッシュします。コマンドの後、node1 への接続が失われることに注意してください。
[root@node1 ~]# echo c > /proc/sysrq-trigger
ノード 2 で、フェイルオーバープロセスを監視します。フェイルオーバー後、クラスターはこのような状態になり、ASCS と ERS の両方がノード 2 に存在します。
[root@node2 ~]# pcs status
...
Resource Group: rh2_ASCS20_group
rh2_fs_ascs20 (ocf::heartbeat:Filesystem): Started node2
rh2_ascs20 (ocf::heartbeat:SAPInstance): Started node2
rh2_vip_ascs20 (ocf::heartbeat:aws-vpc-move-ip): Started node2
Resource Group: rh2_ERS29_group
rh2_fs_ers29 (ocf::heartbeat:Filesystem): Started node2
rh2_vip_ers29 (ocf::heartbeat:aws-vpc-move-ip): Started node2
rh2_ers29 (ocf::heartbeat:SAPInstance): Started node2
...
6.3.ERS は以前に障害が発生したノードに移動します
ノード 1 をオンラインに戻し、ノード 1 でクラスターを起動します。
[root@node1 ~]# pcs cluster start
ERS はノード 1 に移動し、ASCS はノード 2 に残る必要があります。ERS が移行を完了するまで待ちます。最後にはクラスターは次のような状態になります。
[root@node1 ~]# pcs status
...
Resource Group: rh2_ASCS20_group
rh2_fs_ascs20 (ocf::heartbeat:Filesystem): Started node2
rh2_ascs20 (ocf::heartbeat:SAPInstance): Started node2
rh2_vip_ascs20 (ocf::heartbeat:aws-vpc-move-ip): Started node2
Resource Group: rh2_ERS29_group
rh2_fs_ers29 (ocf::heartbeat:Filesystem): Started node1
rh2_vip_ers29 (ocf::heartbeat:aws-vpc-move-ip): Started node1
rh2_ers29 (ocf::heartbeat:SAPInstance): Started node1
...
7.再起動後にクラスターを自動起動できるようにする
クラスターは、再起動後に自動起動するようにまだ有効化されていません。システム管理者は、ノードをフェンスして再起動した後、クラスターを手動で起動する必要があります。
前のセクションをテストした後、すべてが正常に動作したら、再起動後のクラスターの自動起動を有効にします。
# pcs cluster enable --all
注: 状況によっては、ノードの再起動後にクラスターを自動起動しない方が有益な場合があります。たとえば、クラスターリソースに必要なファイルシステムに問題があり、再度使用する前にファイルシステムを修復する必要がある場合、クラスターは自動起動しますが、ファイルシステムが機能しないために失敗します。さらにトラブルを引き起こす可能性があります。
ここで、前のセクションのテストを再実行して、クラスターが引き続き正常に動作することを確認してください。セクション 6.3. では、ノードの再起動後にコマンド pcs cluster start を実行する必要がないことに注意してください。再起動後にクラスターが自動的に起動するはずです。
Comments