RHEL 上の SAP HANA 高可用性 VM を使用して SAP ASCS/ERS をデプロイする
この記事では、Red Hat Enterprise Linux (RHEL) で実行されている同じ高可用性クラスターに SAP HANA を ABAP SAP セントラル サービス (ASCS)/SAP セントラル サービス (SCS) および エンキュー レプリケーション サーバー (ERS) インスタンスと共にインストールして構成する方法について説明します。
リファレンス
- Pacemaker で Standalone Enqueue Server 2 (ENSA2) を使用して SAP S/4HANA ASCS/ERS 構成する
- RHEL 7.5 以降および RHEL 8 でスタンドアロン リソースを使用して SAP NetWeaver ASCS/ERS ENSA1 を構成する
- SAP Note 1928533: 次の情報が含まれています。
- SAP ソフトウェアのデプロイでサポートされる Azure 仮想マシン (VM) サイズの一覧。
- Azure VM サイズの容量に関する重要な情報。
- サポートされる SAP ソフトウェア、オペレーティング システム (OS) とデータベースの組み合わせ。
- Azure 上の Windows と Linux に必要な SAP カーネル バージョン。
- SAP Note 2015553: SAP でサポートされる Azure 上の SAP ソフトウェア デプロイの前提条件が記載されています。
- SAP Note 2002167: Red Hat Enterprise Linux 7.x 用の推奨 OS 設定が記載されています。
- SAP Note 2772999: Red Hat Enterprise Linux 8.x 用の推奨 OS 設定が記載されています。
- SAP Note 2009879: Red Hat Enterprise Linux 用の SAP HANA ガイドラインが記載されています。
- SAP Note 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が記載されています。
- SAP Note 2191498: Azure 上の Linux に必要な SAP Host Agent のバージョンが記載されています。
- SAP Note 2243692: Azure 上の Linux で動作する SAP のライセンスに関する情報が記載されています。
- SAP Note 1999351はAzure Enhanced モニタリング拡張機能 for SAP に関するその他のトラブルシューティング情報が記載されています。
- SAP Community Wiki には、Linux に必要なすべての SAP Note が掲載されています。
- Linux 上の SAP のための Azure Virtual Machines の計画と実装
- Linux 上の SAP のための Azure Virtual Machines のデプロイ
- Linux 上の SAP のための Azure Virtual Machines DBMS のデプロイ
- Pacemaker クラスターでの SAP Netweaver
- 一般的な RHEL ドキュメント:
- Azure 固有の RHEL ドキュメント:
概要
この記事では、同じ高可用性セットアップで SAP HANA、SAP ASCS/SCS、SAP ERS インスタンスをデプロイするコスト最適化シナリオについて説明します。 1 つの SAP システムの VM の数を最小限に抑えるために、SAP HANA が実行されている同じホストに SAP ASCS/SCS と SAP ERS をインストールする必要があります。 SAP HANA が高可用性クラスター セットアップで構成されている場合、SAP ASCS/SCS と SAP ERS もクラスターで管理する必要があります。 この構成は、基本的には、既に構成されている SAP HANA クラスターのセットアップへの追加です。 このセットアップでは、SAP ASCS/SCS と SAP ERS は仮想ホスト名にインストールされ、そのインスタンス ディレクトリはクラスターによって管理されます。
提示されたアーキテクチャでは、セットアップ用の高可用性インスタンス ディレクトリの Azure Files 上の NFS または Azure NetApp Files が示されています。
この記事で示す例では、次のシステム情報を使用してデプロイについて説明しています。
インスタンス名 | インスタンス番号 | 仮想ホスト名 | 仮想 IP (プローブ ポート) |
---|---|---|---|
SAP HANA DB | 03 | saphana | 10.66.0.13 (62503) |
ABAP SAP セントラル サービス (ASCS) | 00 | sapascs | 10.66.0.20 (62000) |
エンキュー レプリケーション サーバー (ERS) | 01 | sapers | 10.66.0.30 (62101) |
SAP HANA システム識別子 | HN1 | --- | --- |
SAP システム識別子 | NW1 | --- | --- |
Note
別の VM に SAP ダイアログ インスタンス (PAS と AAS) をインストールします。
コスト最適化ソリューションに関する重要な考慮事項
- SAP ダイアログ インスタンス (PAS と AAS) (sapa01 や sapa02 など) は、別の VM にインストールする必要があります。 仮想ホスト名を使用して SAP ASCS と ERS をインストールします。 仮想ホスト名を VM に割り当てる方法の詳細については、ブログ「Azure で Linux を使用した SAP 仮想ホスト名の使用」を参照してください。
- HANA DB、ASCS/SCS、ERS を同じクラスター セットアップにデプロイする場合、HANA DB、ASCS/SCS、ERS のインスタンス番号は異なっている必要があります。
- サイズ設定のガイドラインに基づいて、VM SKU のサイズを適切に設定することを検討してください。 クラスター内の別の VM が使用できない場合は、1 つの VM で複数の SAP インスタンス (HANA DB、ASCS/SCS、ERS) が実行される可能性があるクラスターの動作を考慮する必要があります。
- 別のストレージ (Azure NetApp Files や Azure Files 上の NFS など) を使用して、SAP ASCS および ERS インスタンスをインストールできます。
注意
SAP J2EE システムの場合、Azure Files の NFS に
/usr/sap/<SID>/J<nr>
を配置することはサポートされません。 /hana/data や /hana/log などのデータベース ファイル システムは、Azure Files 上の NFS ではサポートされていません。 - 別の VM にさらにアプリケーション サーバーをインストールするには、インスタンス ディレクトリ ファイル システムに NFS 共有またはローカル マネージド ディスクを使用します。 SAP J2EE システム用にさらにアプリケーション サーバーをインストールする場合、Azure Files 上の NFS で
/usr/sap/<SID>/J<nr>
はサポートされていません。 - このセットアップには同じ考慮事項が当てはまるため、「Azure Files 上の NFS の考慮事項」と「Azure NetApp Files の考慮事項」を参照してください。
前提条件
この記事で説明する構成は、既に構成されている SAP HANA クラスターのセットアップへの追加です。 この構成では、SAP ASCS/SCS および ERS インスタンスが仮想ホスト名にインストールされます。 インスタンス ディレクトリはクラスターによって管理されます。
HANA データベースをインストールし、使用しているストレージ オプションに応じて、「Red Hat Enterprise Linux 上の Azure VM での SAP HANA の高可用性」または「Red Hat Enterprise Linux で Azure NetApp Files を使用した SAP HANA スケールアップの高可用性」の手順に従って HANA システム レプリケーション (HSR) と Pacemaker クラスターを設定します。
HANA クラスターのインストール、構成、セットアップが完了したら、次の手順に従って ASCS および ERS のインスタンスをインストールします。
ASCS と ERS 用に Azure Load Balancer を構成する
この記事では、「Azure Load Balancer の構成」の説明に従って HANA クラスター セットアップ用のロード バランサーが既に構成されていることを前提としています。 同じ Azure Load Balancer インスタンスで、こちらの手順に従って、ASCS および ERS 用のフロントエンド IP と負荷分散規則をさらに作成します。
- SAP HANA クラスター セットアップ用に作成した内部ロード バランサーを開きます。
- フロントエンド IP 構成: 2 つのフロントエンド IP を作成します。1 つは ASCS 用で、もう 1 つは ERS 用です (例: 10.66.0.20 と 10.66.0.30)。
- バックエンド プール: ASCS と ERS を同じバックエンド プールにデプロイしているため、このプールは同じままです。
- 受信規則: 2 つの負荷分散規則を作成します。1 つは ASCS 用、もう 1 つは ERS 用です。 両方の負荷分散規則に対して同じ手順を実行します。
- フロントエンド IP アドレス: フロントエンド IP を選択します。
- バックエンド プール: バックエンド プールを選択します。
- 高可用性ポート: このオプションを選択します。
- [プロトコル]: [TCP] を選択します。
- 正常性プローブ: 次の詳細を使用して正常性プローブを作成します (ASCS と ERS の両方に適用されます)。
- [プロトコル]: [TCP] を選択します。
- ポート: 例: ASCS に対しては 620<Instance-no.>、ERS に対しては 621<Instance-no.>。
- サイクル間隔: 「5」と入力します。
- プローブしきい値: 「2」と入力します。
- アイドル タイムアウト (分): 「30」と入力します。
- **IP の
- 有効化**: このオプションを選択します。
正常性プローブ構成プロパティ numberOfProbes
(Azure portal では [異常しきい値] とも呼ばれます) が順守されていません。 成功または失敗した連続プローブの数を制御するには、プロパティ probeThreshold
を 2
に設定します。 現在、Azure portal を使用してこのプロパティを設定することはできません。 Azure CLI または PowerShell コマンドのいずれかを使用します。
パブリック IP アドレスのない VM が、内部の (パブリック IP アドレスのない) Standard Azure Load Balancer インスタンスのバックエンド プール内に配置されている場合、パブリック エンドポイントへのルーティングを許可するように追加の構成が実行されない限り、送信インターネット接続はありません。 送信接続を実現する方法の手順については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した Virtual Machines のパブリック エンドポイント接続」を参照してください。
重要
Azure Load Balancer の背後に配置された Azure VM では TCP タイムスタンプを有効にしないでください。 TCP タイムスタンプを有効にすると正常性プローブが失敗します。 パラメーター net.ipv4.tcp_timestamps
を 0
に設定します。 詳細については、「Load Balancer の正常性プローブ」を参照してください。
SAP ASCS/SCS と ERS のセットアップ
ストレージに基づいて、次の記事で説明されている手順に従い、クラスター内の SAP ASCS/SCS および SAP ERS インスタンス用に SAPInstance
リソースを構成します。
- Azure Files 上の NFS: Azure Files 上の NFS を使用する RHEL 上の SAP NW 用の Azure VM の高可用性
- Azure NetApp Files: Azure NetApp Files を使用する RHEL 上の SAP NW 用の Azure VM の高可用性
クラスターの設定をテストする
Pacemaker クラスターを十分にテストします。