SUSE Best Practices ケールアップ - パフォーマンス最適化シ …...SUSE Best Practices SAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化シナリ

SUSE Best Practices

SAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化シナリオ

SUSE Linux Enterprise Server for SAP Applications 15-SP1

Fabian Herschel, Distinguished Architect SAP, SUSE

Bernd Schubert, SAP Solution Architect, SUSE

Lars Pinne, System Engineer, SUSE

1 SAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化シナリオ

SUSE® Linux Enterprise Server for SAP Applicationsは、SAP *アプリケー

ション向けにさまざまな方法で最適化されています。このガイドは、パフォーマンス

最適化シナリオにおけるSAP HANAシステムレプリケーションに向けた、SUSE

Linux Enterprise Server for SAP Applicationsのインストールとカスタマイズ

に関する詳細情報を提供します。本ドキュメントは、すでにインストールされて稼働

しているSAP HANAをシステムレプリケーションと統合する手順に焦点を当ててい

ます。

発行日: 2020-03-19

目次

1 このガイドについて 3

2 サポートするシナリオと前提条件 10

3 本ドキュメントのスコープ 12

4 インストレーションの計画 14

5 OSの設定 17

6 両方のクラスターノードへのSAP HANAデータベースのインストール 19

7 SAP HANAシステムレプリケーションの設定 20

8 SAP HANA HA/DRプロバイダーの設定 24

9 クラスターの構成 27

10 クラスターのテスト 39

11 管理 54

12 役に立つリンク、マニュアル、SAPノート 63

13 例 66

14 参照 70

15 法的通知 70

16 GNU Free Documentation License 71


1 このガイドについて

1.1 はじめに

SUSE® Linux Enterprise Server for SAP Applicationsは、SAP *アプリケーション向けにさまざ

まな方法で最適化されています。このガイドは、パフォーマンス最適化シナリオにおけるSAP HANAシ

ステムレプリケーションに向けた、SUSE Linux Enterprise Server for SAP Applicationsのインス

トールとカスタマイズに関する詳細情報を提供します。

Pierre Audoin Consultants（PAC）社が最近実施した市場調査によって得られた結論は、「SAPの

顧客はSAP HANAに投資する」と言うことでした。ドイツでは、半数の企業が、SAP HANAはSAP環

境において支配的なデータベースプラットフォームになると予想しています。「SAP HANA *を活用した

SAP Business Suite *」のシナリオについては、既に具体的な協議が盛んに行われています。

SUSEは、この開発に対してもSUSE Linux Enterprise Server for SAP Applicationsを提供する

ことで対応しています。この製品は、SAP HANAに対して推奨されサポートされているOSです。SUSE

は、SAPとハードウェアパートナーとの連携を密にして、SAP HANAシステムレプリケーションの高可用

性を確保するための2つのリソースエージェントをお客様に提供しています。

1.1.1 概要

このガイドでは、高可用性ソリューションシナリオ「SAP HANAスケールアップシステムレプリケーショ

ンのパフォーマンス最適化」に基づき、SUSE Linux Enterprise Server for SAP Applicationsの

計画、設定、基本的なテストについて解説します。

アプリケーションの観点からは、以下のさまざまな構成を網羅しています。

単純なシステムレプリケーション

セカンダリサイトの読み取り可能なシステムレプリケーション

マルチティア（チェーン）システムレプリケーション

マルチターゲットシステムレプリケーション

上記すべてに対するマルチテナントデータベースコンテナ

インフラストラクチャの観点からは、以下の構成をカバーしています。

ディスクベースのSBDを搭載した2ノードクラスター

ディスクレスSBDを搭載した3ノードクラスター


1.1.2 スケール-アップとスケール-アウト

最初の一連のシナリオには、スケールアップソリューションのアーキテクチャと開発が含まれます。

pacemaker

アクティブ/アクティブ

ノード1 ノード2

A B

A B

SAP HANA DBプライマリ

SAP HANA DBセカンダリ

A B

システムレプリケーション

図 1: クラスター内のSAP HANAシステムレプリケーションのスケールアップ

SUSEは、これらのシナリオに対応するために、スケールアップリソースエージェントパッケージ

SAPHanaSRを開発しました。システムレプリケーションは、1台のコンピューターから別のコンピューター

にデータベースのデータを複製することで、データベースの障害を回復するのに役立ちます（シングル

ボックスレプリケーション）。

2番目の一連のシナリオには、スケールアウトソリューションのアーキテクチャと開発が含まれます（マ

ルチボックスレプリケーション）。SUSEは、これらのシナリオに対応するために、スケールアップリソース

エージェントパッケージ SAPHanaSR-ScaleOutを開発しました。

ノードA1

1

ノードA2

2 3 N

ノードA3

ノードA4 ノードA5

...

...

ノードB1

1

ノードB2

2 3 N

ノードB3

ノードB4ノードB5

...

...

SAP HANA PR1 – WDFサイト SAP HANA PR1 – ROTサイト

SR 同期

SLES for SAP Applications - pacemakerクラスター

プライマリセカンダリ

vIP

マジョリティメーカー

図 2: クラスター内のSAP HANAシステムレプリケーションのスケールアウト


この運用モードでは、内部のSAP HANA高可用性（HA）メカニズムとリソースエージェントは、互い

に連携して協調動作する必要があります。SAP HANAシステムレプリケーションのスケールアウト自動

化については、SUSEのドキュメンテーションWebページ https://documentation.suse.com/sbp/

all/ から入手できるドキュメントに説明されています。スケールアウトに関するドキュメントのタイトル

は「SAP HANAシステムレプリケーションのスケールアウト - パフォーマンス最適化シナリオ」です。

1.1.3 スケールアップシナリオとリソースエージェント

SUSEは、SAP HANAデータベースのインスタンスを実際にチェックする SAPHana リソースエージェ

ント（RA）を使用して、スケールアップシナリオを実装しています。このRAはマスター/スレーブリソース

として構成されます。スケールアップシナリオでは、マスターがプライマリモードで実行されているSAP

HANAデータベースに対して責任を負います。一方で、スレーブは同期（セカンダリ）ステータスで動作

するインスタンスに責任を負います。

クラスターの構成をできるだけシンプルにするために、SUSEは SAPHanaTopology リソースエージェ

ントも開発しました。このRAは、SUSE Linux Enterprise Server for SAP Applicationsクラスター

のすべてのノードで実行され、SAP HANAシステムレプリケーションのステータスと構成に関する情報

を収集します。これは、標準の（ステートレス）クローンとして設計されています。

スケールアップに対するSAP HANAシステムレプリケーションは、以下のシナリオまたはユースケース

でサポートされています。

パフォーマンス最適化 (A ⇒ B).このシナリオと設定については、本ドキュメントで説明していま

す。

pacemaker


SAP HANAプライマリ

SAP HANAセカンダリ


PRD

SAPHana Promoted

SAPHanaTopology

SAPHana Demoted

SAPHanaTopology



vIPvIP

PRD

図 3: クラスター内のSAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化

パフォーマンス最適化シナリオでは、SAP HANA RDBMSサイトAは、2番目のノードのSAP

HANA RDBMSサイトBと同期しています。2番目のノードのHANA RDBMSはテーブルをプリ

ロードするように構成されているため、通常テイクオーバー時間は非常に短くて済みます。


https://documentation.suse.com/sbp/all/https://documentation.suse.com/sbp/all/

SAP HANAのパフォーマンス最適化シナリオが大きく進化した点のひとつは、セカンダリデータ

ベースサイトで読み取りアクセスが可能になったことです。この読み取り可能な read enabled

シナリオをサポートするために、2番目の仮想IPアドレスがクラスターに追加され、システムレプリ

ケーションのセカンダリロールにバインドされます。

コスト最適化 (A ⇒ B, Q).このシナリオと設定は、SUSEのドキュメンテーションWebページ

(https://documentation.suse.com/sbp/all/ )から入手できる別のドキュメントで説明され

ています。コスト最適化のドキュメントのタイトルは「SAP HANA SRコスト最適化インフラストラ

クチャの設定」です。

pacemaker





PRD

SAPHana Promoted

SAPHanaTopology SAPHana Demoted

SAPHanaTopology

PRD

SAPインスタンス



vIP

SAP HANA QAS

QAS

vIP

図 4: クラスター内のSAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化

コスト最適化シナリオでは、2番目のノードも本稼働環境以外のSAP HANA RDBMSシステム

（QASやTSTなど）で使用されます。テイクオーバーが必要な場合は、常に本稼働環境以外のシ

ステムを最初に停止する必要があります。このノードにある本稼働環境のセカンダリシステムは、

システムリソースの使用を制限する必要があるため、テーブルのプリロードを必ずオフにしてくだ

さい。テイクオーバーは、パフォーマンスが最適化されたユースケースよりも長時間になる恐れが

あります。

コスト最適化シナリオでのセカンダリは、メモリ消費量を削減した構成で実行する必要がありま

す。このため、このシナリオでは read enabled を有効にしないでください。

マルチティア (A ⇒ B → C) およびマルチターゲット (B ⇐ A ⇒ C).


https://documentation.suse.com/sbp/all/

pacemaker



PRD

SAPHana Promoted

SAPHanaTopology

SAPHana Demoted



vIP

PRD


PRD

SAPHanaTopology

vIP

図 5: クラスター内のSAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化チェーン

A マルチティアシステムレプリケーションには、追加のターゲットがあります。かつては、この3つ

目のノードはセカンダリ（チェーントポロジー）に接続されている必要がありました。現在のSAP

HANAバージョンでは、SAPによりマルチターゲットトポロジーも許可され可能としています。

pacemaker



PRD

SAPHana Promoted

SAPHanaTopology

SAPHana Demoted



PRD


PRD

SAPHanaTopology

vIP vIP

図 6: クラスター内のSAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化マルチターゲット

マルチティアおよびマルチターゲットシステムは、本ドキュメントで説明されている方法で実装さ

れます。最初の複製ペア（AとB）だけがクラスター自身によって処理されます。単純なパフォーマ

ンス最適化シナリオとの主な違いは、自動登録をオフに設定する必要があることです。

マルチテナンシーまたはマルチテナントデータベースコンテナ（MDC）

マルチテナンシーは、上記のすべてのシナリオとユースケースでサポートされています。このシナ

リオはSAP HANA SPS09以降でサポートされています。クラスターから見た設定と構成は、マ

ルチテナンシーもシングルコンテナも同様です。したがって、上記のドキュメントは両方のシナリオ

に適用できます。


1.1.4 パフォーマンス最適化シナリオの概念

ノード1（ノードまたはデータベースインスタンス）のプライマリSAP HANAに障害が発生した場合、クラ

スターは最初にテイクオーバープロセスを開始しようとします。これにより、既にセカンダリサイトにロード

されているデータを使用することができます。通常、このテイクオーバーはローカルでの再起動よりもは

るかに高速です。

このリソース処理プロセスを自動化するには、SAPHanaSRに含まれるSAP HANAリソースエージェ

ントを使用する必要があります。本稼働環境のデータベースのシステムレプリケーションは、SAPHana

とSAPHanaTopologyにより自動化されます。

クラスターは、SAP HANAシステムレプリケーションがプライマリサービスの停止時点まで同期してい

た場合にのみ、セカンダリサイトへのテイクオーバーを許可します。これにより、プライマリサイトで処理さ

れた最後のコミットが、確実にセカンダリサイトで利用可能になります。

SAPは、SAP HANAとクラスターフレームワークなどの外部ソフトウェア間のインタフェースを改善しま

した。この改善には、サービスまたはシステムレプリケーションチャネルのステータス変更など、特別な

イベントが発生した場合のSAP HANA呼び出しの実装も含まれています。これらの呼び出しは、HA/

DRプロバイダーとも呼ばれます。このインタフェースは、Pythonで記述されたSAP HANAフックを実

装することで使用できます。SUSEは、SAPHanaSRパッケージを改善し、クラスターインタフェースを最

適化するためのSAP HANAフックを含めました。本ドキュメントで述べたSAP HANAフックを使用する

と、SAP HANAシステムレプリケーションが機能停止した場合、即座にクラスターに通知することがで

きます。SAP HANAフックステータスに加えて、クラスターはシステムレプリケーションステータスを定

期的にポーリングします。

AUTOMATED_REGISTERパラメータを変更することにより、自動化のレベルを設定できます。自動化され

た登録が有効な場合、クラスタは新しいセカンダリになる元の障害発生プライマリの登録も自動で行い

ます。

重要このソリューションは、HAWKまたは他のクラスタークライアントコマンドを使用して、プライ

マリまたはセカンダリインスタンスを手動で「migrate」するようには設計されていません。管

理セクションでは、SAPおよびクラスターコマンドを使用して、プライマリをセカンダリサイトに

「migrate」する方法について説明しています。

1.1.5 完全なパッケージを提供

SAPHanaとSAPHanaTopologyリソースエージェントを使用すると、SAP HANAシステムレプリケー

ションをクラスターに統合することができます。これには、企業がビジネスクリティカルなSAPシステムだ

けでなく、SAP HANAデータベースも中断することなく使用できるメリットがあり、必要とする予算を大

幅に節減できます。SUSEはベストプラクティスのドキュメントとともに拡張ソリューションを提供します。


自社独自のSAP HANA高可用性ソリューションを持っていないSAPパートナーやハードウェアパート

ナーも、SUSEのこの開発から恩恵を受けることができます。

1.2 その他のドキュメントとリソース

このマニュアルの各章には、システムまたはインターネットから入手可能なその他のドキュメントリソー

スへのリンクが掲載されています。

最新のドキュメントについては、http://documentation.suse.com/ を参照してください。

SUSE Linux Enterprise Server for SAP Applicationsのベストプラクティスが掲載されたWeb

ページ:https://documentation.suse.com/sbp/all/ には、多数のホワイトペーパー、ベストプラク

ティス、設定ガイドなどもあります。

また、SUSEはSAPと高可用性に関するブログ記事も公開しています。ハッシュタグ

#TowardsZeroDowntimeを使用して、ぜひご参加ください。次のリンクからアクセスしてくださ

い。https://www.suse.com/c/tag/TowardsZeroDowntime/ .

1.3 正誤表

小さくとも緊急の修正や重要な情報をタイムリーに提供するために、本設定ガイドに関わる技術情報ド

キュメント（TID）は頻繁に更新、保守、公開されます。

SAP HANA SRパフォーマンス最適化シナリオ - 設定ガイド - 正誤表 (https://

www.suse.com/support/kb/doc/?id=7023882 )

クラスター監視ツールでSOKステータスを表示するワークアラウンド (https://www.suse.com/

support/kb/doc/?id=7023526 - 次のブログ記事もご覧ください https://

www.suse.com/c/lets-flip-the-flags-is-my-sap-hana-database-in-sync-or-not/ )

他のソリューションについては、本ガイドに加えてSUSE SAPベストプラクティスガイド正誤表をご確認

ください (https://www.suse.com/support/kb/doc/?id=7023713 ).

1.4 フィードバック

複数のフィードバックチャネルが利用可能です。

バグと機能強化のリクエスト

お使いの製品で利用できるサービスとサポートオプションについては、 http://

www.suse.com/support/ を参照してください。


http://documentation.suse.com/https://documentation.suse.com/sbp/all/https://www.suse.com/c/tag/TowardsZeroDowntime/https://www.suse.com/support/kb/doc/?id=7023882https://www.suse.com/support/kb/doc/?id=7023882https://www.suse.com/support/kb/doc/?id=7023526https://www.suse.com/support/kb/doc/?id=7023526https://www.suse.com/c/lets-flip-the-flags-is-my-sap-hana-database-in-sync-or-not/https://www.suse.com/c/lets-flip-the-flags-is-my-sap-hana-database-in-sync-or-not/https://www.suse.com/support/kb/doc/?id=7023713http://www.suse.com/support/http://www.suse.com/support/

製品コンポーネントのバグを報告するには、https://scc.suse.com/support/ リクエストにアクセス

してログインし、 Submit New SR (Service Request)を選択します。

メール

本製品のドキュメントへのフィードバックについては、[email protected] (mailto:doc-

[email protected]) 宛てにメールを送信してください。ドキュメントのタイトル、製品のバージョ

ン、ドキュメントの発行日を必ず記載してください。エラーを報告したり機能拡張を提案するには、

問題の簡潔な説明と共に、該当するセクション番号とページ（またはURL）を記載してください。

2 サポートするシナリオと前提条件SAPHanaSRリソースエージェントソフトウェアパッケージでは、スケールアップ（シングルボックスからシ

ングルボックスへ）システムレプリケーションを、以下の構成とパラメータに限定してサポートします。

標準は2ノードクラスターです。3番目のノードにもリソースエージェントをインストールする場合

は、3ノードクラスターでも構いません。ただし、3番目のノードではSAP HANAリソースを実行し

ないことをクラスターで定義してください。この場合、3番目のノードは、クラスターを分離する場合

に、追加の意思決定者になります。

クラスターには、有効なSTONITH手段が含まれている必要があります。

SUSE Linux Enterprise 15 High Availability Extension（SDB、IPMIなど）でサ

ポートされているすべてのSTONITHメカニズムがSAPHanaSRでサポートされています。

本ガイドでは、ハードウェアに依存しないことからSBDフェンシングメソッドに焦点を当てて

います。

フェンシングメカニズムとしてディスクベースのSBDを使用する場合は、1台以上の共有ド

ライブが必要になります。本稼働環境では、SBDデバイスを複数使用することをお勧めしま

す。ディスクベースSBDの詳細については、SUSE Linux Enterprise High Availability

Extensionの製品ドキュメントと、本マニュアルのページsbd.8およびstonith_sbd.8を参

照してください。

ディスクレスSBDの場合は、少なくとも3クラスターノードが必要になります。ディスクレス

SBDメカニズムには、フェンシング用の共有ドライブが不要となるメリットがあります。

2つのノードは、同一のネットワークセグメント（レイヤー2）にあります。オーバーレイIPアドレスや

ロードバランサー機能などは、クラウド環境から提供される同様の機能でも構いません。クラウド

独自のガイドに従って、SUSE Linux Enterprise Server for SAP Applicationsクラスターを

設定します。


https://scc.suse.com/support/mailto:[email protected]:[email protected]

admなどのテクニカルユーザーとグループは、Linuxシステムにローカルで定義されます。

クラスターノードと仮想IPアドレスの名前解決は、すべてのクラスターノードでローカルに実行す

る必要があります。

ネットワークタイムプロトコル(NTP) などのクラスターノード間の時刻同期。

プライマリとセカンダリのSAP HANAインスタンスのSAP識別子（SID）とインスタンス番号はど

ちらも同じです。

各クラスターノードが異なるデータセンターやデータセンターエリア内にインストールされている

場合、それらの環境は、SUSE Linux Enterprise High Availability Extensionクラスター

製品の要件と一致する必要があります。ここで特に懸念されるのは、ネットワーク遅延とノー

ド間の推奨最大距離です。これらの推奨事項については、SUSE Linux Enterprise High

Availability Extensionの製品ドキュメントで確認してください。

停止したプライマリに対する、テイクオーバー後の自動登録。

プロジェクトを適切に初期構成するために、停止したプライマリの自動登録をオフにする

ことをお勧めします。 AUTOMATED_REGISTER="false"がデフォルトの設定になります。こ

の場合、停止したプライマリは、テイクオーバー後に手動で登録する必要があります。SAP

HANAコックピットやhdbnsutil.などのSAPツールを使用してください。

最適な自動化には、 AUTOMATED_REGISTER="true"に設定することをお勧めします。

システム起動中のSAP HANAインスタンスの自動起動はオフにする必要があります。

マルチテナンシーデータベースコンテナ（MDC）をサポートします。

マルチテナンシーデータベースは、他のすべての設定（パフォーマンスベース、コスト最適

化、マルチティア）と組み合わせて使用することができます。

MDC構成において、SAP HANA RDBMSはすべてのデータベースコンテナを含む単一

システムとして扱われます。したがって、クラスターのテイクオーバーの決定は、個々のデー

タベースコンテナのステータスには関係なく、専らRDBMSのステータスに基づいて行われ

ます。


SAP HANA 1.0の場合、本稼働中にテナントを停止し、クラスターが引き継げるようにす

るためには、バージョンSPS10 rev3、SPS11以降が必要になります。SAP HANAのバー

ジョンがそれより古い場合は、テナントを停止させるとシステムレプリケーションは失敗と

マークされます。

マルチテナンシーデータベースでのテストは、テナント間の独立性が強いを強力に分離さ

せている場合、別のテスト手順を強いられる可能性があります。例として、 HDB killを使

用してSAP HANAインスタンスをすべて停止することはできません。各テナントが異なる

LinuxユーザーUIDで実行されているためです。は、他のテナントユーザーのプ

ロセスを終了させることはできません。

少なくともSAPHanaSRバージョン0.153が必要で、SUSE Linux Enterprise Server for SAP

Applications 15 SP1以降が最善です。SAP HANA 1.0は、SPS09 (095)以降に定義されているす

べての設定でサポートされています。SAP HANA 2.0は、すべての既知のSPSバージョンでサポートさ

れています。

重要有効なSTONITH手段がない場合は、クラスターのすべてはサポートされないため、正しく動作

しません。

別のシナリオを実装する必要がある場合は、SUSEと共にPoC（概念実証）を規定することを強くお勧

めします。PoCは、そのシナリオにおける既存ソリューションのテストに焦点を当てます。上記の制限を

付けた理由は、慎重にテストする必要があるためです。

SAP HANAの他に、SAPホストエージェントをシステムにインストールする必要があります。

3 本ドキュメントのスコープ本ドキュメントは、クラスターを設定して、システムレプリケーションシナリオにおいてSAP HANAを制御

する方法を説明します。このドキュメントでは、すでにインストールされて稼働しているSAP HANAをシ

ステムレプリケーションと統合する手順に焦点を当てています。

ここで説明している設定例では、Walldorf（WDF）とRot（ROT）にある2つのデータセンターで、2つの

SLES for SAP 15 SP1システムにインストールされたSAP HANA HAクラスターを構築します。


pacemaker





PR1PR1

SAPHana Promoted

SAPHanaTopology

SAPHana Demoted

SAPHanaTopology

SAP HANA プライマリ


vIPvIP

図 7: SAP HANA SRを使用したクラスター - パフォーマンス最適化

クラスターの設定は、YaSTウィザードを使用することも、手動で行うことも、また、所有されている自動

化機能を利用することもできます。

YaSTウィザードを使用する場合は、ショートカットyast sap_haからモジュールを起動することができま

す。YaSTを使用してSAPHanaSRを設定する手順については、SUSE Linux Enterprise Server for

SAP Applicationsの製品ドキュメントのセクションSAP HANAクラスターを設定するに記載されてお

り、https://documentation.suse.com/sles-sap/15-SP1/single-html/SLES4SAP-guide/#cha-

s4s-cluster から入手できます。

図 8: YAST MODULE SAP_HAでのSAP HANAのシナリオ選択

本ガイドは、クラスターの手動による設定に焦点を当てて詳細を説明し、独自の自動化機能を構築でき

るよう支援します。

設定手順は以下のように主に7段階に分かれています。


https://documentation.suse.com/sles-sap/15-SP1/single-html/SLES4SAP-guide/#cha-s4s-clusterhttps://documentation.suse.com/sles-sap/15-SP1/single-html/SLES4SAP-guide/#cha-s4s-cluster

計画 OS 設定 HANAｲﾝｽﾄﾚｰｼｮﾝ

HANAHSR

HANA統合

クラスタ― 設定

テスト

計画 (4項「インストレーションの計画」を参照)

OSのインストレーション (5項「OSの設定」を参照)

データベースのインストレーション (6項「両方のクラスターノードへのSAP HANAデータベース

のインストール」を参照)

SAP HANAシステムレプリケーションの設定（を参照） 7項「SAP HANAシステムレプリケーショ

ンの設定」

SAP HANA HA/DRプロバイダーフック (8項「SAP HANA HA/DRプロバイダーの設定」を参

照)

クラスター構成（9項「クラスターの構成」を参照)

テスト(10項「クラスターのテスト」を参照)

4 インストレーションの計画


HANAHSR

HANA統合

クラスター設定

テスト

SAP HANAクラスターを正しく設定するには、インストレーションの計画が不可欠です。

事前に用意するものは以下のとおりです。

SUSEのソフトウェア: SUSE Linux Enterprise Server for SAP Applicationsのインストー

ルメディア、有効なサブスクリプション、およびアップデートチャネルへのアクセス

SAPのソフトウェア: SAP HANAインストールメディア

ディスクを含む物理または仮想システム

記載済みのパラメータシート (以下の 4.2項「パラメータシート」を参照)


4.1 ラボの最小要件と前提条件

注記ここで説明しているラボの最小要件は、SAPのサイジング情報ではありません。これらのデータ

は、ここで述べたクラスターをテスト目的でラボに再構築するためにのみ提供されます。たとえテ

ストであっても、そのシナリオによっては要件が増える場合があります。本稼働システムについて

は、ハードウェアベンダーに問い合わせるか、公式のSAPサイジングツールやサービスをご利用

ください。

注記許容されるストレージ構成とファイルシステムについては、SAP HANA TDIドキュメントを参照

してください。

サイトごとに1つのSAPインスタンスが必要 (1 : 1) - マジョリティメーカーなし（2ノードクラスター）:

各々32GB RAMを備えた2つのVM、システムに対して50GBのディスク容量

10MBのディスク空き容量を備えたSBD用の共有ディスク1台

SAP HANA用に各々96GB容量のデータディスク2台（各サイト1台）

テイクオーバー用の1つの追加IPアドレス

読み取り可能な設定用の1つのオプションIPアドレス

HAWK管理GUI用の1つのオプションIPアドレス

サイトごとに1つのSAPインスタンスが必要 (1 : 1) - マジョリティメーカー有（3ノードクラスター）:

各々32GB RAMを備えた2つのVM、システムに対して50GBのディスク空き容量

2GB RAMを備えた1つのVM、システムに対して50GBのディスク空き容量

SAP HANA用に各々96GB容量のデータディスク2台（各サイト1台）

テイクオーバー用の1つの追加IPアドレス

Read-enabled設定用の1つのオプションIPアドレス

HAWK管理GUI用の1つのオプションIPアドレス


4.2 パラメータシート2つのSAP HANAサイトを編成するクラスターの設定が非常に簡単な場合でも、インストレーションは

適切に計画する必要があります。SID、IPアドレスを含め、必要なすべてのパラメータを用意する必要が

あります。最初にパラメータシートに記入してからインストレーションを開始することをお勧めします。

表 1: 計画用パラメータシート

パラメータ値ロール

ノード1 クラスターノード名とIPアドレス

ノード2 クラスターノード名とIPアドレス

SID SAPシステム識別子

インスタンス番号 SAP HANAデータベースの数。システムレプリケーション

では、インスタンス番号+1もブロックされます。

ネットワークマスク

vIPプライマリプライマリSAP HANAサイトに割り当てられる仮想IPアド

レス。

vIPセカンダリ読み取り可能なセカンダリSAP HANAサイトに割り当てら

れる仮想IPアドレス（オプション）。

ストレージ HDBデータとログファイル用のストレージは「ローカル」に

接続されています（ノードごと、非共有）。

SBD STONITHデバイス（2台は本稼働用）

HAWKポート 7630

NTPサーバータイムサーバーのアドレスまたは名前

表 2: NTPサーバー


ノード1 suse01 ,

192.168.1.11

クラスターノード名とIPアドレス

ノード2 suse02 ,

192.168.1.12

クラスターノード名とIPアドレス



SID HA1 SAPシステム識別子。

インスタンス番号 10 SAP HANAデータベースの数。システムレプリケーションでは、インスタンス番号+1もブロックされます。

ネットワークマスク 255.255.255.0

vIPプライマリ 192.168.1.20

vIPセカンダリ 192.168.1.21 （オプション）

ストレージ HDBデータとログファイル用のストレージは「ローカル」に

接続されています（ノードごと、非共有）。

SBD /dev/disk/by-

id/SBDA

STONITHデバイス（2台は本稼働用）

HAWKポート 7630

NTPサーバー pool

pool.ntp.org

タイムサーバーのアドレスまたは名前

5 OSの設定


HANAHSR

HANA統合


テスト

このセクションには、OSのインストール中に考慮すべき情報が含まれています。

本ドキュメントのスコープでは、最初にSUSE Linux Enterprise Server for SAP Applicationsをイ

ンストールして構成します。次に、システムレプリケーションを含むSAP HANAデータベースを設定しま

す。最後に、クラスターを伴う自動化を設定して構成します。


5.1 SUSE Linux Enterprise Server for SAP Applicationsのインストール

さまざまな理由により、サーバーの設定には各々の方法があり、すでに複数のインストレーションガイド

が公開されています。これらのガイドを入手できる場所を以下に示します。さらに、システムを適切に動

作させるために検討すべき重要な詳細情報も入手できます。

5.1.1 ベースOSをインストールする

使用するインフラストラクチャとハードウェアに応じて、インストレーションを調整する必要があり

ます。サポートされているすべてのインストレーション方法と最小要件は、導入ガイド (https://

documentation.suse.com/sles/15-SP1/html/SLES-all/book-sle-deployment.html )で説明

されています。自動インストールの場合は、 AutoYaSTガイド (https://documentation.suse.com/

sles/15-SP1/html/SLES-all/book-autoyast.html )で詳細情報を確認できます。SAP HANAの

すべての要件に適合するSUSE Linux Enterprise Server for SAP Applicationsの主要インスト

レーションガイドは、SAPノートから入手できます。

2578899 SUSE LINUX Enterprise Server 15: インストレーションノート、および

2684254 SAP HANA DB: SLES 15 / SLES for SAP Applications 15向けに推奨される

OS設定。

5.1.2 追加ソフトウェアのインストール

SUSEは、SUSE Linux Enterprise Server for SAP Applicationsと共に、SAP HANA用の特別な

リソースエージェントを提供します。sap-hanaパターンを使用すると、SAP HANAスケールアップに対

するリソースエージェントがインストールされます。スケールアウトのシナリオでは、特別なリソースエー

ジェントが必要になります。SAPノート1984787に基づいてシステムをインストールした場合は、各ノー

ドで以下の指示に従ってください。ハイアベイラビリティパターンは、すべてのノードにインストールす

ることが推奨されるツールを余すことなく要約したものです。これにはマジョリティメーカーも含まれま

す。

例 1: HAクラスター用の追加ソフトウェアのインストール

1. すべてのノードの High Availability パターン

suse01:~> zypper in --type pattern ha_sles

2. すべてのノードに SAPHanaSR リソースエージェントをインストールする


https://documentation.suse.com/sles/15-SP1/html/SLES-all/book-sle-deployment.htmlhttps://documentation.suse.com/sles/15-SP1/html/SLES-all/book-sle-deployment.htmlhttps://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.htmlhttps://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.html

suse01:~> zypper in SAPHanaSR SAPHanaSR-doc

詳細については、SUSE Linux Enterprise High Availability Extensionのインストレーションと基

本設定をご覧ください。

6 両方のクラスターノードへのSAP HANAデータベースのインストール


HANAHSR

HANA統合


テスト

本ドキュメントでは、インストール済みのSAP HANAと、すでにPacemakerクラスターに設定されてい

るシステムレプリケーションとの統合に焦点を当てていますが、この章では、テスト環境の概要を説明し

ます。SAP HANAをインストールしたり、システムレプリケーションを設定する際は、必ずSAPの公式ド

キュメントを参照してください。

6.1 両方のクラスターノードへのSAP HANAデータベースのインストール事前準備

SAP マーケットプレースから入手したSAPインストレーションおよび設定マニュアルを理解しま

す。

SAP マーケットプレースからSAP HANAソフトウェアをダウンロードします。

実行手順

1. SAP HANAサーバーのインストレーションガイドの説明に従って、SAP HANAデータベースをイ

ンストールします。

2. SAPホストエージェントがすべてのクラスターノードにインストールされていることを確認します。

このSAPサービスがインストールされていない場合は、今すぐインストールしてください。

3. 両方のデータベースが稼働しており、これらのすべてのプロセスが正しく実行されていることを確

認します。


Linuxadmユーザーとして、 HDBコマンドラインツールを使用して、実行中のHANAプロセスの

概要を取得します。 HDB infoの出力は、以下のように表示されます。

suse02:ha1adm> HDB infoUSER PID PPID ... COMMANDha1adm 13017 ... -shha1adm 13072 ... \_ /bin/sh /usr/sap/HA1/HDB10/HDB infoha1adm 13103 ... \_ ps fx -U ha1adm -o user:8,pid:8,ppid:8,pcpu:5,vsz:10,rss:10,argsha1adm 9268 ... hdbrsutil --start --port 31003 --volume 2 --volumesuffix mnt00001/hdb00002.00003 --identifier 1580897137ha1adm 8911 ... hdbrsutil --start --port 31001 --volume 1 --volumesuffix mnt00001/hdb00001 --identifier 1580897100ha1adm 8729 ... sapstart pf=/hana/shared/HA1/profile/HA1_HDB10_suse02ha1adm 8738 ... \_ /usr/sap/HA1/HDB10/suse02/trace/hdb.sapHA1_HDB10 -d -nw -f /usr/sap/HA1/HDB10/suse02/daemon.ini pf=/usr/sap/HA1/SYS/profile/HA1_HDB10_suse02ha1adm 8756 ... \_ hdbnameserverha1adm 9031 ... \_ hdbcompileserverha1adm 9034 ... \_ hdbpreprocessorha1adm 9081 ... \_ hdbindexserver -port 31003ha1adm 9084 ... \_ hdbxsengine -port 31007ha1adm 9531 ... \_ hdbwebdispatcherha1adm 8574 ... /usr/sap/HA1/HDB10/exe/sapstartsrv pf=/hana/shared/HA1/profile/HA1_HDB10_suse02 -D -u ha1adm

7 SAP HANAシステムレプリケーションの設定


HANAHSR

HANA統合


テスト

詳細については、SAP HANA管理ガイドのシステムレプリケーションの設定セクションをご覧ください。

実行手順

1. プライマリデータベースをバックアップします。

2. プライマリデータベースを有効にします。

3. セカンダリデータベースを登録します。

4. システムレプリケーションを確認します。


7.1 プライマリデータベースをバックアップするSAP HANA管理ガイドのSAP HANAデータベースのバックアップとリカバリーセクションの説明に

従って、プライマリデータベースをバックアップします。SQLコマンドを使用した例を示します。これらの

バックアップコマンドは、バックアップインフラストラクチャに適合させて使用する必要があります。

例 2: 1回のバックアップコールでシステムデータベースとすべてのテナントを簡単にバックアップする

ユーザーとして、次のコマンドを入力します。

hdbsql -u SYSTEM -d SYSTEMDB \ "BACKUP DATA FOR FULL SYSTEM USING FILE ('backup')"

以下の（または同様の）コマンド出力が表示されます。

0 rows affected (overall time 15.352069 sec; server time 15.347745 sec)

例 3: 単一コンテナ（非MDC）データベースの単純なバックアップ

ユーザーとして、以下のコマンドをとして入力します。

hdbsql -i -u \ "BACKUP DATA USING FILE ('backup')"

重要有効なバックアップがない場合は、SAP HANAをシステムレプリケーション構成にすることがで

きません。

7.2 プライマリノードを有効にするLinux のadm ユーザーとして、プライマリノードでシステムレプリケーションを有効にします。サイ

ト名（例: WDF）を定義する必要があります。このサイト名は、システムレプリケーションを介して接続さ

れているすべてのSAP HANAデータベースで一意にしなければなりません。したがって、セカンダリは

異なるサイト名にしてください。

注記「primary」や「secondary」などの文字列はサイト名に使用しないでください。

例 4:

-sr_enableオプションを使用してプライマリを有効にします。

suse01:~> hdbnsutil -sr_enable --name=WDFchecking local nameserver:


checking for active nameserver ...nameserver is running, proceeding ...configuring ini files ...successfully enabled system as primary site ...done.

例 5: プライマリを有効にする

hdbnsutil -sr_stateConfigurationコマンドを使用して、プライマリのSR構成を確認しま

す。

suse01:~> hdbnsutil -sr_stateConfiguration --sapcontrol=1SAPCONTROL-OK: mode=primarysite id=1site name=WDFSAPCONTROL-OK: done.

モードが「none」から「primary」に変更され、サイトにサイト名とサイトIDが追加されました。

7.3 セカンダリノードを登録するセカンダリ側のSAP HANAデータベースインスタンスは、システムレプリケーションに登録する前に一

旦停止する必要があります。 HDB や sapcontrolなどのお好みの方法でインスタンスを停止します。

データベースインスタンスが正常に停止すれば、 hdbnsutilを使用してインスタンスを登録することが

できます。再び、Linux のadmユーザーを使用します。

例 6: セカンダリを停止する

コマンドラインツールのHDBを使用して、セカンダリを停止することができます。

suse02:~> HDB stop

例 7: CKEYおよびKEY-DATAファイルをプライマリからセカンダリサイトにコピーする

SAP HANA 2.0から、システムレプリケーションは暗号化されています。そのため、鍵ファイルを

プライマリサイトからセカンダリサイトにコピーする必要があります。

cd /usr/sap//SYS/global/security/rsecssfsrsync -va {,:}$PWD/data/SSFS_.DATrsync -va {,:}$PWD/key/SSFS_.KEY

例 8: セカンダリを登録する

セカンダリの登録は、 hdbnsutil -sr_register …を呼び出すことによってトリガーされます。

...suse02:~> hdbnsutil -sr_register --name=ROT \


--remoteHost=suse01 --remoteInstance=10 \ --replicationMode=sync --operationMode=logreplayadding site ...checking for inactive nameserver ...nameserver suse02:30001 not responding.collecting information ...updating local ini files ...done.

この例では、 remoteHost がプライマリノードであり、remoteInstance はデータベースインスタンス

番号です（ここでは10）。

次に、データベースインスタンスを再起動し、システムレプリケーションステータスを確認します。セカン

ダリノードでは、このモードは「SYNC」または「SYNCMEM」のいずれかである必要があります。レプ

リケーションモードとしては"ASYNC" も可能ですが、自動化されたクラスターテイクオーバーではサ

ポートされません。.このモードは、セカンダリの登録中に定義されたsync オプションに依存します。

例 9: セカンダリを起動してSR構成を確認する

新たなセカンダリを起動するには、HDBコマンドラインツールを使用します。次に、 hdbnsutil -

sr_stateConfigurationを使用してSRシステムレプリケーション構成を確認します。

suse02:~> HDB start...suse02:~> hdbnsutil -sr_stateConfiguration --sapcontrol=1SAPCONTROL-OK: mode=syncsite id=2site name=ROTactive primary site=1primary masters=suse01SAPCONTROL-OK: done.

SAP HANAクラスター全体のレプリケーションステータスを表示するには、プライマリノード

でadmユーザーとして、以下のコマンドを使用します。

例 10: システムレプリケーションステータスの詳細を確認する

systemReplicationStatus.py スクリプトは、現在のシステムレプリケーションに関する詳細情

報を提供します。

suse01:~> HDBSettings.sh systemReplicationStatus.py --sapcontrol=1...site/2/SITE_NAME=ROT1site/2/SOURCE_SITE_ID=1site/2/REPLICATION_MODE=SYNCsite/2/REPLICATION_STATUS=ACTIVEsite/1/REPLICATION_MODE=PRIMARYsite/1/SITE_NAME=WDF1


local_site_id=1...

7.4 SAP HANA SRシステムレプリケーションのテイクオーバーの手動テストSAP HANAシステムレプリケーションをクラスターに統合する前に、手動でテイクオーバーを実行する

ことが不可欠です。クラスターを使用しないテストは、基本動作（テイクオーバーと登録）が想定どおり

に機能していることを確認するのに役立ちます。

ノード1でSAP HANAを停止します。

SAP HANAをノード2にテイクオーバーします。

ノード1をセカンダリとして登録します。

ノード1のSAP HANAを起動します。

同期ステータスがアクティブになるまで待機します。

7.5 オプションSAP HANA SRを手動で元の状態に再構築するシステムを元の状態に戻します。

ノード2のSAP HANAを停止します。

SAP HANAをノード1にテイクオーバーします。

ノード2をセカンダリとして登録します。

ノード2でSAP HANAを起動します。

同期ステータスがアクティブになるまで待機します。

8 SAP HANA HA/DRプロバイダーの設定


HANAHSR

HANA統合


テスト


この手順は、セカンダリの同期が失われた場合に、直ちにクラスターに通知する際に必須になります。こ

のフックは、セカンダリが非同期になった時点で、HA/DRプロバイダーインタフェースを使用してSAP

HANAによって呼び出されます。一般的には、最初のコミット保留が解除されたケースに該当します。シ

ステムレプリケーションが復帰したときに、SAP HANAによってフックが再び呼び出されます。

実行手順

1. SAPHanaSR Pythonフックを実装します。

2. システムレプリケーション運用モードを構成します。

3. からクラスターへのアクセスを許可します。

4. SAP HANAを起動します。

5. フックの統合をテストします。

8.1 SAPHanaSR Pythonフックを実装する

この手順は両方のサイトで実行する必要があります。SAP HANAがHA/DRフックスクリプトを起動時

に統合できるようにするには、SAP HANAを停止してglobal.iniを変更する必要があります。

HA/DRフックスクリプトを読み取り/書き込み可能なディレクトリにインストールします。

フックをglobal.iniに統合します（オフラインで実行するためにSAP HANAを停止する必要があ

ります）

起動時にフックの統合を確認します。

SAPHanaSRパッケージ（バージョン0.153以降で使用可能）のフックを使用してください。必要に応じ

て、/ hana / share / myHooksなどのお好みのディレクトリにコピーします。フックは、すべてのSAP

HANAクラスターノードで使用できる必要があります。

例 11: SAP HANAを停止

HDB またｈsapcontrolを使用して、SAP HANAを停止します。

sapcontrol -nr -function StopSystem

例 12: GLOBAL.INI によりSAPHANASRを追加する

[ha_dr_provider_SAPHanaSR]provider = SAPHanaSRpath = /usr/share/SAPHanaSRexecution_order = 1


[trace]ha_dr_saphanasr = info

8.2 システムレプリケーション運用モードを構成する

システムがSAPHanaSRターゲットとして接続されている場合、 global.ini内に、運用モードを定義す

るエントリーを見つけることができます。現時点では、以下のモードが利用できます。現時点では、以下

のモードが利用できます。

delta_datashipping

logreplay

logreplay_readaccess

反対方向にテイクオーバーして再登録されるまで、プライマリサイトにおける運用モードのエントリー

は失われたままです。当初、利用可能な運用モードはdelta_datashippingでした。現在におけるHA

での推奨モードは、logreplayまたはlogreplay_readaccessです。logreplay運用モードを使用する

と、SAP HANAシステムレプリケーションのセカンダリサイトがホットスタンバイシステムになります。す

べての運用モードの詳細については、「SAP HANAのシステムレプリケーションを実行する方法」など

のSAPドキュメントをご覧ください。

例 13: 動作モードを確認する

両方のglobal.iniファイルを確認し、必要に応じて運用モードを追加します。

セクション

[ system_replication ]

エントリー

operation_mode = logreplay

global.iniのパス: /hana/shared//global/hdb/custom/config/

[system_replication]operation_mode = logreplay

8.3 にクラスターへのアクセスを許可する

SAPHanaSR pythonフックの現在のバージョンは、 sudoコマンドを使用することにより、

ユーザーがクラスター属性にアクセスできるようにします。Linuxでは、 visudoを使用して、/etc/

sudoers構成ファイルのviエディタを起動できます。


ユーザーは、hana__sid＿site_srHook_ *クラスター属性を設定できる必要がありま

す。SAP HANAシステムレプリケーションフックには、パスワード不要のフリーアクセスが求められます。

次の例では、sudoアクセスを限定し、必要な属性を正確に設定することだけにしています。

を小文字の SAPシステムID( ha1など）に置き換えます。

例 14: SUDO PERMISSIONS /ETC/SUDOERS ファイルのエントリー

にsrHookの使用を許可する基本的なsudoersエントリー。

# SAPHanaSR-ScaleUp entries for writing srHook cluster attribute ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana__site_srHook_*

高度なセキュリティレベルを達成するためのより詳細なsudoersエントリー。すべての

Cmnd_Aliasエントリーは、それぞれ1行のエントリーとして定義する必要があります。次の

例では、1行にドキュメントの書式設定によって強制された改行が含まれています。この例で

は、Cmnd_Aliasエントリーに4つの別々の行があり、1行はユーザー用で、それ以外

がコメント用です。

# SAPHanaSR-ScaleUp entries for writing srHook cluster attributeCmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana__site_srHook_ -v SOK -t crm_config -s SAPHanaSRCmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana__site_srHook_ -v SFAIL -t crm_config -s SAPHanaSRCmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana__site_srHook_ -v SOK -t crm_config -s SAPHanaSRCmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana__site_srHook_ -v SFAIL -t crm_config -s SAPHanaSR ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB

9 クラスターの構成


HANAHSR

HANA統合


テスト

この章では、SUSE Linux Enterprise Server for SAP ApplicationsとSAP HANA Database

Integrationの一部である、SUSE Linux Enterprise High Availability Extensionクラスターソフ

トウェアの構成について解説します。


実行手順

1. 基本的なクラスター構成。

2. クラスターのプロパティとリソースを構成します。

9.1 基本的なクラスター構成

最初のステップは、基本的なクラスターフレームワークを設定することです。便宜上、YaST2またはha-

cluster-initスクリプトを使用してください。2番目のCorosysncリングを追加し、UCAST通信に変更し

て、環境に合わせてタイムアウト値を調整することを強くお勧めします。

9.1.1 「ストレージベースフェンシング」のウォッチドッグを設定する

SBDフェンシングメカニズム（ディスクレスまたはディスクベース）を使用する場合は、ウォッチドッグも

設定する必要があります。ウォッチドッグは、システムがSBD（ディスクレスまたはディスクベース）にアク

セスできなくなった場合に、ノードをリセットするために必要になります。ウォッチドッグドライバーをロード

するようにLinuxシステムを構成することが必須になります。hpwdt、iTCO_wdtなどの、ハードウェアの

#アシスタンスト（ほとんどの最新システムで利用可能）を備えたウォッチドッグを使用することを強くお

勧めします。次善の策として、softdogモジュールを使用できます。

例 15: ウォッチドッグに対する設定

重要ウォッチドッグタイマーへのアクセス: 他のソフトウェアがウォッチドッグタイマーにアクセス

することはできません。常に1つのプロセスだけがアクセスできます。一部のハードウェア

ベンダーは、システムリセットにウォッチドッグを使用するシステム管理ソフトウェアを提供

しています（例: HP ASRデーモン）。ウォッチドッグをSBDで使用する場合は、このような

ソフトウェアを無効にする必要があります。

最適なウォッチドッグモジュールを選択します。または、カーネルバージョンと共にインストールさ

れているドライバーのリストを調べる方法もあります。

ls -l /lib/modules/$(uname -r)/kernel/drivers/watchdog

ウォッチドッグモジュールがすでにロードされているかどうかを確認します。

lsmod | egrep "(wd|dog|i6|iT|ibm)"


結果が表示された場合は、システムにはウォッチドッグがすでにロードされています。そのウォッ

チドッグがウォッチドッグデバイスに対応していない場合は、そのモジュールをアンロードする必

要があります。

モジュールを安全にアンロードするには、まずアプリケーションがウォッチドッグデバイスを使用し

ているかどうかを確認します。

lsof /dev/watchdogrmmod

ウォッチドッグモジュールを有効にして永続化します。以下の例ではsoftdogが使われています

が、いくつか制約がありますので他のオプションを優先してください。

echo softdog > /etc/modules-load.d/watchdog.confsystemctl restart systemd-modules-load

ウォッチドッグモジュールが正しくロードされていることを確認します。

lsmod | grep dogls -l /dev/watchdog

ウォッチドッグのテストは、簡単な手順で実行できます。ウォッチドッグは、正規の手順を踏まずに

システムを強制的にリセット/シャットダウンするため、必ず最初にSAP HANAを切り替えてくだ

さい。

ハードウェアウォッチドッグの場合は、ウォッチドッグがタイムアウトした後のアクションを事前に定

義します。ウォッチドッグモジュールがロードされていて、他のアプリケーションによって制御され

ていない場合は、次の手順を実行します。

重要ウォッチドッグを継続的に更新せずに、ウォッチドッグをトリガーして、システムをリセットす

るか電源をオフにします。これが意図されたメカニズムです。次のコマンドは、システムのリ

セットまたは電源オフを強制します。

touch /dev/watchdog

softdogモジュールが使用されている場合は、以下のアクションを実行できます。

echo 1> /dev/watchdog

テストが成功した場合は、すべてのクラスターメンバーにウォッチドッグを実装する必要がありま

す。


9.1.2 ha-cluster-initを使用したクラスターの初期設定

詳細については、SUSE Linux Enterprise High Availability Extensionの自動クラスター設定を

参照してください。

初期設定を作成するには、 ha-cluster-initコマンドを使用してダイアログに従ってください。これ

は、最初のクラスターノードだけに実行してください。

suse01:~> ha-cluster-init -u -s

このコマンドは、以下を含む基本的なクラスターフレームワークを構成します。

SSH鍵

構成ファイルを転送するためのcsync2

SBD（1台以上のデバイス）

corosync（1つ以上のリング）

HAWK Webインタフェース

重要ha-cluster-init の要求に基づいて、haclusterユーザーのパスワードを変更します。

9.1.3 CorosyncとSBD構成を適用する

2番目のcorosyncリングを追加することをお勧めします。-uオプションを使用してha-cluster-initを

開始しなかった場合は、corosyncを変更してUCAST通信を使用する必要があります。UCASTに変

更するには、 systemctl stop pacemakerを使用して、すでに稼働しているクラスターを停止しま

す。corosync構成とSBDパラメータを設定した後に、クラスターを再起動します。

9.1.3.1 Corosync の構成

/etc/corosync/corosync.confファイルにある以下のブロックを確認します。また、本ドキュメントの最

後に掲載されている例も参照してください。

totem { ...

interface { ringnumber: 0 mcastport: 5405 ttl: 1


} #Transport protocol transport: udpu

}nodelist { node { #ring0 address ring0_addr: 192.168.1.11 nodeid: 1

} }

9.1.3.2 SBD構成を適用する

SBDデバイスを使用していない場合は、このセクションをスキップできますが、サポートされている別の

フェンシングメカニズムを必ず実装してください。

詳細については、マニュアルのページsbd.8およびstonith_sbd.7をご覧ください。

表 3: /ETC/SYSCONFIG/SBDファイルのSBDオプション

パラメータ説明

SBD_WATCHDOG_DEV ウォッチドッグデバイスを定義します。ウォッチドッ

グの使用は必須です。SBDは、ウォッチドッグが

ないと信頼性が低くなります。ウォッチドッグの設

定については、SLESマニュアルとSUSE TIDs

7016880を参照してください。

SBD_WATCHDOG_TIMEOUT タイムアウトは秒単位で定義します。定義しなけ

れば、ウォッチドッグはノードがパニックに陥るま

で待機したままになります。

このパラメータは、使用中のストレージ環境と整

合している必要があります。仮にストレージが30

秒間ハングすることが予想される場合は、このパ

ラメータをより長い値に設定する必要があります。

一般的な設定は5秒ですが、本稼働環境では意

欲的な値になり得ます。

このパラメータは、Pacemaker クラス

ターのstonith-watchdog-timeoutプ

ロパティにも整合させる必要がありま



す。stonith-watchdog-timeoutプロパティ

は、SBD_WATCHDOG_TIMEOUTの値以上

に設定する必要があります。

stonith-watchdog-timeout を負の値に

設定すると、Pacemakerはこのタイムアウトを

自動的に計算し、SUSE Linux Enterprise

High Availability Extension 15以降の

SBD_WATCHDOG_TIMEOUT の値の2倍に設定し

ます。

SBD_STARTMODE 起動モード。 cleanに設定されている場合、sbd

はノードが以前クリーンにシャットダウンされた

か、またはスロットが空の場合にのみ起動します。

SBD_PACEMAKER Pacemakerクォーラムとノードに異常がないかを

チェックをします。

以下では、/dev/disk/by-id/SBDA、および/dev/disk/by-id/SBDBを実際のsbdデバイス名に置

き換えます。この例では、 SBD_WATCHDOG_TIMEOUTは15秒に設定されており、一般的な5秒に比べる

と意欲的な値ではありません。

# /etc/sysconfig/sbdSBD_DEVICE="/dev/disk/by-id/SBDA;/dev/disk/by-id/SBDB"SBD_WATCHDOG_DEV="/dev/watchdog"SBD_WATCHDOG_TIMEOUT=15SBD_PACEMAKER="yes"SBD_STARTMODE="clean"SBD_OPTS=""

重要タイムアウトの計算に関して、詳しくは次のSUSE製品ドキュメントもご覧ください。https://

documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#sec-ha-

storage-protect-watchdog-timings

9.1.3.3 SBDデバイスを確認する

SBDデバイスを使用していない場合は、このセクションをスキップできますが、サポートされているフェ

ンシングメカニズムを必ず実装してください。


https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#sec-ha-storage-protect-watchdog-timingshttps://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#sec-ha-storage-protect-watchdog-timingshttps://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#sec-ha-storage-protect-watchdog-timings

両方のノードからSBDデバイスにアクセスでき、有効なレコードが含まれているか確認することをお勧め

します。これを/etc/sysconfig/sbdで構成されているすべてのデバイスに対して確認してください。

suse01:~ # sbd -d /dev/disk/by-id/SBDA dump==Dumping header on disk /dev/disk/by-id/SBDAHeader version : 2.1UUID : 0f4ea13e-fab8-4147-b9b2-3cdcfff07f86Number of slots : 255Sector size : 512Timeout (watchdog) : 20Timeout (allocate) : 2Timeout (loop) : 1Timeout (msgwait) : 40==Header on disk /dev/disk/by-id/SBDA is dumped

サンプルのタイムアウト値は初期値に過ぎませんので、ご使用の環境に合わせて調整してください。

さまざまなクラスターノードの現在のSBDエントリーを確認するには、 sbd listを使用します。すべて

のエントリーが clearされている場合、SBDデバイスにはフェンシングタスクがマークされません。

suse01:~ # sbd -d /dev/disk/by-id/SBDA list0 suse01 clear

SBD構成パラメータの詳細については、 SUSE Linux Enterprise High-Availability Extension、

およびTIDsが 7016880と7008216のストレージベースフェンシングセクションをご覧ください。

ここで、最初のノードでクラスターを再起動します( systemctl start pacemaker )。

9.1.4 2番目のノードのクラスター構成

2ノードクラスターの2番目のノードは、 ha-cluster-joinコマンドを実行して統合することができま

す。このコマンドは、IPアドレスか最初のクラスターノードの名前を要求します。必要なすべての構成ファ

イルがコピーされます。その結果、クラスターは両方のノードで起動されます。

# ha-cluster-join -c

9.1.5 初めてクラスターを確認する

これで、初めて両方のノードでクラスターを確認し、オプションでクラスターを起動する時がきました。

suse01:~ # systemctl status pacemakersuse01:~ # systemctl status sbdsuse02:~ # systemctl status pacemakersuse01:~ # systemctl start pacemaker


suse02:~ # systemctl status sbdsuse02:~ # systemctl start pacemaker

crm_monを使用してクラスターのステータスを確認します。「-r」オプションを使用して、構成済みで停

止しているリソースも表示します。

# crm_mon -r

このコマンドは、空のクラスターを表示し、以下のような画面出力を表示します。ここで最も興味深い情

報は、「online」オンラインステータスの2つのノードがある点と、「partition with quorum」というメッ

セージです。

Stack: corosyncCurrent DC: suse01 (version 2.0.1+20190417.13d370ca9-3.6.1-2.0.1+20190417.13d370ca9) - partition with quorumLast updated: Wed Feb 5 15:06:35 2020Last change: Wed Feb 5 15:04:42 2020 by hacluster via crmd on suse022 nodes configured1 resource configuredOnline: [ suse01 suse02 ]Full list of resources: stonith-sbd (stonith:external/sbd): Started suse01

9.2 クラスターのプロパティとリソースを構成する

このセクションでは、 crm configure シェルコマンドを使用して、制約、リソース、ブートストラッ

プ、STONITHを構成する方法について説明します。このコマンドは、SUSE Linux Enterprise High

Availability Extensionドキュメントのクラスターリソースの構成・管理（コマンドライン）セクションで

説明されています。

crm コマンドを使用して、オブジェクトをCRMに追加します。以下の例をローカルファイルにコピーし、

ファイルを編集して、その構成をCIBにロードしてください。

suse01:~ # vi crm-fileXXsuse01:~ # crm configure load update crm-fileXX

9.2.1 クラスターブートストラップなど

最初の例では、クラスターのブートストラップオプション、リソース、運用のデフォルトを定義しま

す。stonith-timeoutは、SBD msgwaitタイムアウトの1.2倍よりも大きくする必要があります。

suse01:~ # vi crm-bs.txt# enter the following to crm-bs.txt


property $id="cib-bootstrap-options" \ stonith-enabled="true" \ stonith-action="reboot" \ stonith-timeout="150s"rsc_defaults $id="rsc-options" \ resource-stickiness="1000" \ migration-threshold="5000"op_defaults $id="op-options" \ timeout="600"

次に、この構成をクラスターに追加します。

suse01:~ # crm configure load update crm-bs.txt

9.2.2 STONITHデバイス

ディスクレスSBDを使用している場合は、このセクションをスキップしてください。

以下の構成では、SBDディスクのSTONITHリソースを定義します。

# vi crm-sbd.txt# enter the following to crm-sbd.txtprimitive stonith-sbd stonith:external/sbd \ params pcmk_delay_max="15"

再び、この構成をクラスターに追加します。

suse01:~ # crm configure load update crm-sbd.txt

IPMI/ILOによるフェンシングについては、セクション9.2.3項「IPMIをフェンシングメカニズムとして使

用する」をご覧ください。

9.2.3 IPMIをフェンシングメカニズムとして使用する

IPMI/ILOフェンシングの詳細については、クラスター製品ドキュメント（https://

documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/ ）をご覧くださ

い。IPMI STONITHリソースの例は、本ドキュメントのセクション13.4項「IPMI STONITH手段の

例」に掲載されています。

IPMIを使用するには、リモートマネジメントボードがIPMI標準と互換性を有している必要があります。

IPMIベースフェンシングでは、クラスターノードごとにプリミティブを設定する必要があります。各リソー

スは、1つのクラスターノードを確実にフェンスする役割を果たします。リモートマネジメントボードのIPア

ドレスとログインユーザー/パスワードをSTONITHリソースエージェントに適合させる必要があります。


https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/

リモートマネジメントボードへのrootアクセスを提供する代わりに、特別なSTONITHユーザーを作成す

ることをお勧めします。ロケーションルールは、ホストが独自のSTONITHリソースを実行しないことを保

証する必要があります。

9.2.4 他のフェンシングメカニズムを使用する

STONITHメカニズムとして、SBDを最初の選択肢、IPMIを2番目の選択肢として使用することをお勧

めします。SUSE Linux Enterprise High Availability製品は、本書では取り上げていないその他の

フェンシングメカニズムもサポートしています。

フェンシングの詳細については、SUSE Linux Enterprise High Availabilitガイドをご覧ください。

9.2.5 SAPHanaTopology

次に、HANAインスタンスが起動する前に、必要なリソースのグループを定義します。crm-

saphanatop.txtのようなテキストファイルで変更の準備をし、以下のコマンドと共にロードします。

crm configure load update crm-saphanatop.txt

# vi crm-saphanatop.txt# enter the following to crm-saphanatop.txtprimitive rsc_SAPHanaTopology_HA1_HDB10 ocf:suse:SAPHanaTopology \ op monitor interval="10" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="HA1" InstanceNumber="10"clone cln_SAPHanaTopology_HA1_HDB10 rsc_SAPHanaTopology_HA1_HDB10 \ meta clone-node-max="1" interleave="true"

すべてのパラメータに関する追加情報は、以下のコマンドを使って検索することができます。

man ocf_suse_SAPHanaTopology

再び、この構成をクラスターに追加します。

suse01:~ # crm configure load update crm-saphanatop.txt

ここで最も重要なパラメータはSIDとインスタンス番号です。これはSAP環境では自明のことです。こ

れらのパラメータの他に、タイムアウト値や、開始、監視、停止の各動作は、いずれも典型的な調整可能

なものです。

9.2.6 SAPHana

次に、HANAインスタンスが起動する前に、必要なリソースのグループを定義します。crm-

saphana.txtのようなテキストファイルで変更内容を編集して、以下のコマンドと共にロードします。


crm configure load update crm-saphana.txt

表 4: さまざまなシナリオにおける一般的なリソースエージェントパラメータの設定

パラメータパフォーマン

ス最適化

コスト最適化マルチティア

PREFER_SITE_TAKEOVER true false false / true

AUTOMATED_REGISTER false / true false / true false

DUPLICATE_PRIMARY_TIMEOUT 7200 7200 7200

表 5: 重要なリソースエージェントパラメータの説明


PREFER_SITE_TAKEOVER 停止したプライマリをローカルで再起動する代わりに、RA

がセカンダリインスタンスへのテイクオーバーを優先する

かどうかを定義します。

AUTOMATED_REGISTER 以前のプライマリを自動的に登録して、新しいプライマリ

のセカンダリにするかどうかを定義します。このパラメータ

を使用すると、システムレプリケーションの自動化のレベ

ルを調整できます。

false に設定した場合は、以前のプライマリを手動で

登録する必要があります。クラスターは、プライマリが2重

に稼働する状況を回避するために、登録されるまでこの

SAP HANA RDBMSを起動しません。

DUPLICATE_PRIMARY_TIMEOUT デュアルプライマリの状況が発生した場合は、2つのプラ

イマリのタイムスタンプの間に時間差が必要になります。

時間差が時間間隔よりも小さい場合、クラスターは一方

または両方のインスタンスを「WAITING」ステータスに

維持します。これは、管理者がフェイルオーバーに対応す

る機会を与えるためです。以前のプライマリのノードが完

全にクラッシュした場合、以前のプライマリは、時間差が

経過した後に登録されます。SAP HANA RDBMS「だ

け」がクラッシュした場合は、以前のプライマリが直ちに登

録されます。この新たなプライマリへの登録後、すべての

データはシステムレプリケーションによって上書きされま

す。


すべてのパラメータに関する追加情報は、次のコマンドで検索することができます。

man ocf_suse_SAPHana

# vi crm-saphana.txt# enter the following to crm-saphana.txtprimitive rsc_SAPHana_HA1_HDB10 ocf:suse:SAPHana \ op start interval="0" timeout="3600" \ op stop interval="0" timeout="3600" \ op promote interval="0" timeout="3600" \ op monitor interval="60" role="Master" timeout="700" \ op monitor interval="61" role="Slave" timeout="700" \ params SID="HA1" InstanceNumber="10" PREFER_SITE_TAKEOVER="true" \ DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"ms msl_SAPHana_HA1_HDB10 rsc_SAPHana_HA1_HDB10 \ meta clone-max="2" clone-node-max="1" interleave="true"

その構成をクラスターに追加します。

suse01:~ # crm configure load update crm-saphana.txt

ここでも、最も重要なパラメータは、やはりSIDとインスタンス番号です。これらのパラメータの他に、開

始、昇格、監視、停止の各動作におけるタイムアウト値は、典型的な調整可能なパラメータです。

9.2.7 プライマリサイトの仮想IPアドレス

クラスターに追加される最後のリソースは、仮想IPアドレスをカバーします。

# vi crm-vip.txt# enter the following to crm-vip.txt

primitive rsc_ip_HA1_HDB10 ocf:heartbeat:IPaddr2 \ op monitor interval="10s" timeout="20s" \ params ip="192.168.1.20"

このファイルをクラスターにロードします。

suse01:~ # crm configure load update crm-vip.txt

ほとんどのインストレーションでは、ipパラメータのみをクライアントシステムに提供する仮想IPアドレス

に設定する必要があります。

9.2.8 制約

2つの制約により、クライアントデータベースアクセス用の仮想IPアドレスの正しい配置と、SAPHanaと

SAPHanaTopologyの2つのリソースエージェント間の開始順序が調整されます。


# vi crm-cs.txt# enter the following to crm-cs.txt

colocation col_saphana_ip_HA1_HDB10 2000: rsc_ip_HA1_HDB10:Started \ msl_SAPHana_HA1_HDB10:Masterorder ord_SAPHana_HA1_HDB10 Optional: cln_SAPHanaTopology_HA1_HDB10 \ msl_SAPHana_HA1_HDB10

このファイルをクラスターにロードします。

suse01:~ # crm configure load update crm-cs.txt

9.2.9 アクティブ/アクティブ読み取り可能なシナリオ

この手順はオプションです。読み取り可能なセカンダリによるアクティブ/アクティブSAP HANAシステ

ムレプリケーションがある場合は、必要となる2番目の仮想IPアドレスをクラスターに統合することが可

能です。これは、2番目の仮想IPアドレスリソースと、そのアドレスをセカンダリサイトにバインドする場所

の制約を追加することによって行われます。

# vi crm-re.txt# enter the following to crm-re.txt

primitive rsc_ip_HA1_HDB10_readenabled ocf:heartbeat:IPaddr2 \ op monitor interval="10s" timeout="20s" \ params ip="192.168.1.21"colocation col_saphana_ip_HA1_HDB10_readenabled 2000: \ rsc_ip_HA1_HDB10_readenabled:Started msl_SAPHana_HA1_HDB10:Slave

10 クラスターのテスト


HANAHSR

HANA統合


テスト

テストのリストは、本ドキュメントの次回の更新時に改訂される予定です。

どのようなクラスターにおい�

Documents

SUSE Best Practices ケールアップ - パフォーマンス最適化シ …...SUSE Best Practices SAP HANAシステムレプリケーションのス ケールアップ - パフォーマンス最適化シナリ

SUSE Best Practices ケールアップ - パフォーマンス最適化シ …...SUSE Best Practices SAP HANAシステムレプリケーションのスケールアップ - パフォーマンス最適化シナリ