目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / アマゾン ウェブ サービス(AWS)におけるSAP HANAシステムレプリケーションスケールアウト高可用性
SUSE Linux Enterprise Server for SAP Applications 12 SP4以降

アマゾン ウェブ サービス(AWS)におけるSAP HANAシステムレプリケーションスケールアウト高可用性

SUSE Best Practices
Authors
Fabian Herschel, Distinguished Architect SAP, SUSE
Bernd Schubert, SAP Solution Architect, SUSE
Lars Pinne, System Engineer, SUSE
Guilherme Felix, SAP Specialist, AWS
Sander Bleijenbergh, SAP Specialist, AWS
Somckit Khemmanivanh, SAP Specialist, AWS
日にち: 2020-05-13
日にち: 9 29, 2024

SUSE® Linux Enterprise Server for SAP Applicationsは、SAP *アプリケーション向けにさまざまな方法で最適化されています。このガイドは、アマゾン ウェブ サービス(AWS)クラウドにおける、自動化されたフェールオーバー機能を持つSAP HANAスケールアウトシステムレプリケーションに向けた、SUSE Linux Enterprise Server for SAP Applicationsのインストールとカスタマイズに関する詳細な情報を提供します。

本ドキュメントはSUSE Linux Enterprise Server for SAP Applications 12 SP4に基づいています。ただしこの概念は新しいバージョンでも利用できます。

1 このガイドについて

1.1 はじめに

SUSE® Linux Enterprise Server for SAP Applicationsは、SAP *アプリケーション向けにさまざまな方法で最適化されています。このガイドは、アマゾン ウェブ サービス(AWS)クラウドにおける、自動化されたフェールオーバー機能を持つSAP HANAスケールアウトシステムレプリケーションに向けた、SUSE Linux Enterprise Server for SAP Applicationsのインストールとカスタマイズに関する詳細な情報を提供します。

高可用性はミッションクリティカルなSAP HANAサーバーの稼動における重要な側面です。

SAP HANAスケールアウトシステムレプリケーションは、1つのSAP HANAスケールアウトクラスター内のすべてのデータを、異なるAWSアベイラビリティゾーン内のセカンダリSAP HANAクラスターにレプリケーションします。SAP HANAは非同期および同期レプリケーションモードをサポートします。このガイドでは、プライマリシステムのメモリからセカンダリシステムのメモリへの同期レプリケーションについて説明します。これは、Pacemakerクラスターが、実装されたアルゴリズムに基づいて決定を行うことができる唯一の方法であるためです。

目標復旧時間(RTO)は、定期的なデータレプリケーションにより最小化されます。

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

このマニュアルの各章にLinuxマニュアルページまたはインターネットから入手可能なその他のドキュメントリソースへのリンクが掲載されています。

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

SUSE Linux Enterprise Server for SAP Applicationsのリソースライブラリ:https://documentation.suse.com/sbp/all/には、多数のホワイトペーパーやガイドなどもあります。

1.3 フィードバック

次に示すフィードバックチャネルを利用できます。

バグと拡張リクエスト

ご使用中の製品に関して利用可能なサービスとサポートについては、http://www.suse.com/support/をご参照ください。

製品コンポーネントのバグを報告するには、https://scc.suse.com/support/リクエストにアクセスしてログインし、 Submit New SR (Service Request)を選択します。

メール

本製品のドキュメントへのフィードバックについては、doc-team@suse.com宛てにメールを送信してください。ドキュメントのタイトル、製品バージョン、およびドキュメントの発行日を必ず含めてください。エラーの報告または拡張の提案については、問題を簡潔に説明いただくとともに、各セクション番号とページ(またはURL)を示してください。

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

本ドキュメントでは、SUSE Linux Enterprise Server for SAP Applications 12 SP4またはSUSE Linux Enterprise Server for SAP Applications 15をベースとして、分離されたAWSアベイラビリティゾーンにインストールされたSAP HANAスケールアウトシステムレプリケーションクラスターの設定方法について説明します。

よりわかりやすい概要を提供するために、インストールと設定を7つのステップに分けます。

設定プロセスを実行した結果、システムレプリケーション構成でSAP HANAスケールアウトノードの2つのグループを制御するSUSE Linux Enterprise Server for SAP Applicationsクラスターが構築されます。フェールオーバーがわずか数分で完了することから、このアーキテクチャは「パフォーマンス最適化シナリオ」と名付けられました。

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

3 計画とインストール

インストール計画は、SAP HANAクラスターの設定を成功させるために不可欠です。

作業開始前に以下を準備する必要があります。

  • 「SUSE Linux Enterprise Server for SAP Applications 12 SP4」または「SUSE Linux Enterprise Server for SAP Applications 15」以降を使用して、Amazonマシンイメージ(AMI)から作成されたEC2インスタンス。Bring Your Own Subscription(BYOS)AMIを使用する場合、有効なSUSE製品サブスクリプションが必要です。

  • SAP HANAインストールメディア

  • 2つのAmazon Elastic File System(EFS) - 各アベイラビリティゾーンにつき1つずつ

  • 入力済みのパラメータシート(下記参照)

3.1 環境要件

このセクションでは、SAP HANAスケールアウトをインストールし、AWSにクラスターを作成するための最低要件を定義します。

注記
注記

ここで述べる最低要件にSAPサイジング情報は含まれません。サイジング情報については、公式のSAPサイジングツールおよびサービスをご利用ください。

注記
注記

AWSにSAP HANAスケールアウトクラスタをデプロイするには、AWSクイックスタートに従い、「単一のアベイラビリティゾーン(AZ)マルチノードアーキテクチャ」デプロイオプションを使用するのが推奨方法です。SAP HANAスケールアウトを手動でインストールする場合は、推奨のストレージ構成およびファイルシステムを含む詳細なインストール手順について、AWS SAP HANAガイドドキュメントをご参照ください。

ScaleOutCluster AWS
図 4: 2つのアベイラビリティゾーンにまたがるSAP HANAスケールアウトシステムレプリケーション向けに簡素化されたクラスターアーキテクチャ

このガイドでは一例として、2つの3ノードSAP HANAスケールアウトクラスター(各アベイラビリティゾーンにつき1つずつ)と1つのマジョリティメーカー(mm)ノードで構成されるSUSEクラスターの実装について詳しく説明します。ただし、EC2インスタンスの数を除き、他のすべての要件は、次に示すとおり、SAP HANAノードの数にかかわらず同じです。

  • AZ-a内の3つのHANA認定EC2インスタンス(ベアメタルまたは仮想化)

  • AZ-b内の3つのHANA認定EC2インスタンス(ベアメタルまたは仮想化)

  • AZ-c内の1つのEC2インスタンス。クラスターにおけるマジョリティメーカーとして使用。最低2つのvCPU、2GBのRAM、および50GBのディスク容量

  • /hana/shared用の2つのAmazon Elastic Filesystem(EFS)

  • プライマリ(アクティブ)HANAシステムクラスター用の1つのオーバーレイIPアドレス

3.2 パラメータシート

クラスター実装の計画は非常に複雑になる可能性があります。このため、適切なインストール計画を策定することをお勧めします。デプロイを開始する前に必要なすべてのパラメータを準備しておくことが推奨されます。初めにパラメータシートを記入し、インストールを開始するとよいでしょう。

表 1: NFSベースの設定を準備するためのパラメータシート
パラメータ

SAP HANAメディアへのパス

 

ノード名(AZ-a)

 

ノード名(AZ-b)

 

ノード名(マジョリティメーカー)

 

すべてのクラスターノードのIPアドレス

 

SAP HANA SID

 

SAPインスタンス番号

 

オーバーレイIPアドレス

 

AWSルートテーブル

 

SAP HANAサイト名(サイト1)

 

SAP HANAサイト名(サイト2)

 

EFSファイルシステム(AZ-a)(/hana/shared)

 

EFSファイルシステム(AZ-b)(/hana/shared)

 

ウォッチドッグドライバ

 

プレイスメントグループ名

 

3.3 SUSE Linux Enterprise High Availability ExtensionによるAWSのSAPスケールアウトシナリオ

AWSのSAP HANAスケールアウトクラスターでは、3つ目のアベイラビリティゾーンでマジョリティメーカーノードを使用する必要があります。マジョリティメーカーは、タイブレーカーノードともいい、1つのアベイラビリティゾーンが失われてもクラスタークォーラムの維持を確保します。AWSでは、スケールアウトクラスターの機能を維持するために、少なくとも1つのアベイラビリティゾーンにあるすべてのノードとマジョリティメーカーノードが稼動している必要があります。それ以外の場合、クラスタークォーラムが失われ、残っているSAP HANAノードがある場合は自動的に再起動します。

クラスターノードの各セットは、「クラスター」モードを使用する独自のEC2プレイスメントグループを所有することも推奨されます。これは、スケールアウトデプロイにおけるSAP HANAで求められるノード間通信に必要な低レイテンシと高スループットのネットワーク性能をノード間で実現可能するために必要です。

フェールオーバーを自動化するために、SUSE Linux Enterprise Server for SAP Applicationsに組み込まれているSUSE Linux Enterprise High Availability Extension(HAE)が使用されます。SAP HANAスケールアウト高可用性をサポートするために作成された2つのリソースエージェントが含まれています。

最初のリソースエージェント(RA)はSAPHanaControllerで、SAP HANAデータベースインスタンスのチェックと管理を行います。このRAはマスター/スレーブリソースとして構成されます。

マスターはプライマリモードで稼動しているSAP HANAデータベースのアクティブなマスターネームサーバーに対して責任を負います。その他のすべてのインスタンスはスレーブモードで表されます。

2番目のリソースエージェントはSAPHanaTopologyです。このRAはクラスターの構成を可能な限り単純化するために作成されています。SUSE Linux Enterprise High Availability Extension 12クラスターのすべてのSAP HANAノード(マジョリティメーカーを除く)で動作します。SAP HANAシステムレプリケーションのステータスと構成に関する情報を収集します。通常の(ステートレス)クローンリソースとして設計されています。

SAPHanaSR ScaleOut Cluster Resources02 AWS
図 5: クラスターリソースエージェントとマスター/スレーブステータスのマッピング

スケールアウト向けのSAP HANAシステムレプリケーションは、次のシナリオまたはユースケースでサポートされています。

パフォーマンス最適化、単一コンテナ(A > B)

パフォーマンス最適化シナリオで、サイト「A」のSAP HANA RDBMSは2つ目のサイト「B」のSAP HANA RDBMSと同期します。2つ目のサイトのSAP HANA RDBMSはテーブルをプリロードするように構成されるので、通常、テイクオーバーの時間は非常に短くなります。

パフォーマンス最適化、マルチテナンシ(MDCともいう)(%A > %B)

マルチテナンシは上記のすべてのシナリオとユースケースでサポートされています。このシナリオはSAP HANA 1 SPS12以降でサポートされています。クラスターから見た設定と構成は、マルチテナンシーもシングルコンテナも同様です。したがって、上記のドキュメントは両方のシナリオに適用できます。

マルチテナンシはSAP HANA 2.0のデフォルトのインストールタイプです。

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

AZ-aのプライマリSAP HANAスケールアウトクラスターに障害が発生した場合、High Availability Extensionはテイクオーバー処理の開始を試みます。これにより、AZ-bにあるSAP HANAスケールアウトで既にロード済みのデータを使用できます。一般にテイクオーバーはローカルの再起動に比べてはるかに高速です。

LandscapeHostConfigurationステータスがこのことを反映すると(リターンコード1)、サイトは「停止」または「エラー」と通知されます。これは、ローカルのSAP HANAスタンバイノードが残っていない状態でワーカーノードが停止するときに発生します。

追加の操作はなく、リソースエージェントはSAP内部HAクラスターがローカルで状態を修復するまで待機します。追加の操作としては、SAP HANA 2.0 SPS01以降で利用可能なSAPプロバイダsrServiceStateChanged()を使用するカスタムのPythonフックが考えられます。

このリソース処理プロセスの自動化を実現するために、SUSE® Linux Enterprise Server for SAP Applicationsとともに提供されるSAPHanaSR-ScaleOut RPMパッケージに含まれるSAP HANAリソースエージェントを使用できます。

パラメータAUTOMATED_REGISTERを設定することで、自動化のレベルを構成できます。自動化された登録が有効な場合、クラスターは新しいセカンダリになる、元の障害発生プライマリの登録も自動で行います。

3.5 重要な前提条件

SAPHanaSR-ScaleOutリソースエージェントソフトウェアパッケージは、次の構成とパラメータを使用して、スケールアウト(マルチノードからマルチノードへ)のシステムレプリケーションをサポートします。

  • クラスターには有効なSTONITH手段が必要です。AWSで使用されるSTONITHメカニズムはウォッチドッグを使用したディスクレスSBDです。

  • HANAプライマリおよびセカンダリは異なるアベイラビリティゾーン(AZ)にあるため、オーバーレイIPアドレスが必要です。

  • Linuxユーザーおよびグループ(<sid>admなど)は、Linux OSでローカルに定義されます。

  • すべてのノードの時刻同期は、デフォルトでAmazonのTime Sync Serviceを利用します。

  • 異なるアベイラビリティゾーンにあるSAP HANAスケールアウトグループは、同じSAP識別子(SID)およびインスタンス番号を持つ必要があります。

  • EC2インスタンスは異なるホスト名を持つ必要があります。

  • SAP HANAスケールアウトシステムは、1サイトにつきただ1つのアクティブなマスターネームサーバーを持つ必要があります。最大3つのマスターネームサーバー候補(構成済みのロール「master<N>」を持つSAP HANAノード)を持つ必要があります。

  • SAP HANAスケールアウトシステムは、ただ1つのフェイルオーバーグループを持つ必要があります。

  • 本ドキュメントで説明しているクラスターは、Read-enabledに設定されたセカンダリサイト用のサービスIPアドレスは扱いません。

  • ただ1つのSAP HANAシステムレプリケーション設定(AZ-aからAZ-bへ)があります。

  • この設定はパフォーマンス最適化シナリオを実装しますが、コスト最適化シナリオは実装しません。

  • saphostagentはすべてのSAP HANAノードで稼動している必要があります。これは、SAP HANAのインストール時に使用されるシステムノード名とSAPホスト名の間の変換で必要になるためです。

  • レプリケーションモードは「sync」または「syncmem」のどちらかである必要があります。

  • クラスターによって制御されるすべてのSAP HANAインスタンスは、sapinit自動起動でアクティブ化しないでください。

警告
警告

テイクオーバー後に障害発生プライマリの自動登録が可能です。ただし、開始時に適切な構成として、障害発生プライマリの自動登録をオフにすることが推奨されます。したがって、AUTOMATED_REGISTER="false"デフォルトで設定されます。

この場合、テイクオーバー後に障害発生プライマリを手動で登録する必要があります。hanastudioまたはhdbnsutilなどのSAPツールをご利用ください。

  • システムブート時のSAP HANAインスタンスの自動起動は、いずれの場合もオフにする必要があります。

  • 記述しているすべての設定には、少なくともSAPHanaSR-ScaleOutバージョン0.161、「SUSE Linux Enterprise Server for SAP Applications 12 SP4」または「SUSE Linux Enterprise Server for SAP Applications 15」、SAP HANA 1.0 SPS12(122)またはSAP HANA 2.0 SPS03が必要です。SAPノート2235581をご参照ください。

重要
重要

有効なSTONITH手段を実装する必要があります。有効なSTONITH手段がない場合は、クラスターのすべてはサポートされないため、正しく動作しません。当面のドキュメントでは、STONITHとしてディスクレスSBDが使用されます。

この設定ガイドでは、執筆時点でただ1つサポートされているシナリオとして、パフォーマンス最適化シナリオに焦点を当てます。

別のシナリオを実装したりクラスター構成をカスタマイズしたりする必要がある場合は、SUSEおよびAWSとともに概念実証(PoC)を定義することを強くお勧めします。このPoCはユーザーのシナリオで既存のソリューションをテストすることに焦点を当てます。

4 SUSE Linux Enterprise High Availability ExtensionクラスターによるAWSの使用

SUSE Linux Enterprise High Availability ExtensionクラスターはAWSリージョンにインストールされます。AWSリージョンは複数のアベイラビリティゾーン(AZ)で構成されています。アベイラビリティゾーン(AZ)は、AWSリージョン内で冗長な電源、ネットワーキング、および接続性を備えた1つ以上の別個のデータセンターです。AZではユーザーが、単一のデータセンターで実現可能なものと比べてより高い可用性、耐障害性、拡張性がある本稼働システムおよびデータベースを運用できます。AWSリージョン内のすべてのAZは、完全に冗長で、専用のメトロファイバーが提供する、高スループットで低レイテンシのAZ間ネットワークを通じて、高帯域幅で低レイテンシのネットワーキングにより相互接続されます。AZ間のすべてのトラフィックは暗号化されます。このネットワーク性能はAZ間の同期レプリケーションを実現するのに十分です。すべてのAZは互いに100km以内にありますが、他の任意のAZとかなりの距離(何kmも)を隔てて物理的に分離されています。個々のアベイラビリティゾーンの障害に耐えるため、AWSでは冗長なクラスターノードが異なるアベイラビリティゾーンにまたがって分散するアーキテクチャパターンを推奨しています。

AWS仮想プライベートネットワーク(VPC)はすべてのアベイラビリティゾーンにまたがっています。ユーザーは以下を所有していることが前提となります。

  • 3つのアベイラビリティゾーン(AZ)

  • 3つのAZ内に作成されたクラスタノード用のサブネット

  • それぞれのサブネットに属するルーティングテーブル

HANAサービス向けの仮想IPアドレスはオーバーレイIPアドレスです。これは、インスタンスが存在するアベイラビリティゾーン(およびサブネット)にかかわらず、ネットワークトラフィックをインスタンスに送信できる特定のルーティングエントリです。

クラスターはこのルーティングエントリを必要に応じて更新します。VPC内のすべてのSAPシステムコンポーネントは、このオーバーレイIPアドレスを通じて、VPC内にSAPシステムコンポーネントを持つAWSインスタンスに到達できます。

オーバーレイIPアドレスには1つの要件があり、VPCの外部にCIDR範囲を持つ必要があります。そうでない場合、サブネットと特定のアベイラビリティゾーンの一部になる可能性があります。

オンプレミスで、HANA StudioなどのユーザーはこのIPアドレスに到達できません。これは、AWS仮想プライベートネットワーク(VPN)ゲートウェイがトラフィックをそうしたIPアドレスにルーティングしないからです。

4.1 AWS環境構成

AWSでインストールを開始する前に満たす必要のある前提条件を以下に示します。

  • AWSアカウントを保有していること

  • 管理権限または以下の権限を持つAWSユーザーを保有していること。

    • セキュリティグループの作成

    • AWSルーティングテーブルの変更

    • ポリシーの作成とIAMロールへのアタッチ

    • EC2インスタンスの送信元/送信先チェックの有効化/無効化

    • プレイスメントグループの作成

  • ランドスケープについて以下を理解していること。

    • 使用するAWSリージョンとそのAWS名を知っている

    • 使用するVPCとそのAWS VPC IDを知っている

    • 使用するアベイラビリティゾーン(AZ)を知っている

    • 各アベイラビリティゾーンにサブネットが存在する

      • サブネットに暗黙的または明示的に付属するルーティングテーブルがある

      • サブネットにSAPインストール用のフリーIPアドレスがある

      • サブネット間のネットワークトラフィックを許可している

      • サブネットからの外部インターネットアクセスを許可している

注記
注記

AWS SAP HANAクイックスタートを使用すると、上記のすべての必須AWSリソースが自動的にデプロイされます。これは、該当するすべてのSAPノートおよび構成を確実にAWSリソースに適用するための最速で最も安全な方法です。

4.2 セキュリティグループ

クラスターノードによる相互通信を可能にするために、次のポートおよびプロトコルを構成する必要があります。

  • インバウンドUDP用のポート5405。Corosync通信レイヤを構成するために使用され、ポート5405がよく使用されます。Corosync構成に応じて別のポートを使用できます。

  • インバウンドTCP用のポート7630。Web GUI であるSUSE「HAWK」で使用されます。

注記
注記

このセクションでは、SUSE Linux Enterprise HAEクラスターで使用可能にする必要があるポートのみを示しています。SAP関連のポートは含まれていません。

4.3 プレイスメントグループ

SAP HANAノードがSAP HANAで要求される高いネットワークスループットを確実に実現するために、アベイラビリティゾーン毎に1つのクラスタープレイスメントグループが必要です。プレイスメントグループについて詳しくは、AWSのドキュメントをご参照ください(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)。

4.4 AWS EC2インスタンスの作成

SUSE Linux Enterprise HAEクラスターを構成するために、すべてのEC2インスタンスを作成します。EC2インスタンスは、互いに独立させるために、3つの異なるアベイラビリティゾーンに配置されます。

本ドキュメントでは、SAP HANA(プライマリサイト)向けにAZ-a内の3つのEC2インスタンス、SAP HANA(セカンダリサイト)向けにAZ-b内の3つのEC2インスタンス、クラスターのマジョリティメーカー(MM)としてAZ-c内の1つのインスタンスを対象とします。

AMIの選択は次のとおりです。

  • 「SUSE Linux Enterprise Server for SAP」AMIを使用します。AMIのリストで、「suse-sles-sap-12-sp4」または「suse-sles-sap-15」を検索します。使用可能ないくつかのBYOS(Bring Your Own Subscription)AMIがあります。有効なSUSEサブスクリプションを保有している場合は、これらのAMIを使用します。SUSEのSubscription Management Tool(SMT)、SUSE Manager、または直接SUSE Customer Centerを使用して、システムを登録します。

  • あらかじめSUSEサブスクリプションとHAEソフトウェアコンポーネントを含んでいる、AWS Marketplace AMI SUSE Linux Enterprise Server for SAP Applications 15を使用します。

アベイラビリティゾーン(AZ)固有のサブネットおよびプレイスメントグループにすべてのEC2インスタンスを起動します。これらのサブネットは互いに通信可能である必要があります。

4.5 ホスト名

デフォルトで、EC2インスタンスは自動生成されたホスト名を持ちます。ただし、SAP要件に合ったホスト名を割り当てることが推奨されます。SAPノート611361をご参照ください。ホスト名に関して、次のように/etc/cloud/cloud.cfgを編集する必要があります。

preserve_hostname: true
注記
注記

SUSE Linux Enterpriseを実行しているEC2インスタンスのデフォルトのホスト名を変更する方法については、 https://aws.amazon.com/premiumsupport/knowledge-center/linux-static-hostname-suse/にあるAWSの公開ドキュメントを参照してください。

4.6 AWS CLI プロファイル構成

クラスターのリソースエージェントはAWSコマンドラインインターフェース(CLI)を使用します。すべてのインスタンスでrootユーザー用に作成する必要があるAWS CLIプロファイルを使用します。SUSEクラスターリソースエージェントでは、出力をテキスト形式で生成するプロファイルが必要です。

プロファイルの名前は任意で、後でクラスター構成に追加されます。この例で選択されている名前はclusterです。インスタンスのリージョンも追加する必要があります。次の例で、文字列region-nameを目的のリージョンで置き換えます。

こうしたプロファイルを作成する1つの方法は、次の内容を含むファイル/root/.aws/configを作成することです。

[default]
region = region-name
[profile cluster]
region = region-name
output = text

別の方法は、aws configure CLIコマンドを次のように使用することです。

# aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: _region-name_
Default output format [None]:

# aws configure --profile cluster
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: region-name
Default output format [None]: text

上記のコマンドはデフォルトのプロファイルとクラスタープロファイルという2つのプロファイルを作成します。

注記
注記

AWSでは、これらのプロファイルにAWSユーザー資格情報またはAPI署名キーのいずれも格納しないことを推奨しています。これらのフィールドを空白のままにして、必要な権限が付いたEC2 IAMプロファイルをEC2インスタンスにアタッチします。

4.7 HTTP/HTTPプロキシの構成(オプション)

システムがインターネットに直接アクセスできる場合、この操作は不要です。

クラスターリソースエージェントはクラスターライフサイクルを通じてAWS API呼び出しを実行するため、AWS APIエンドポイントへのHTTP/HTTPSアクセスが必要です。透過的なインターネットアクセスを提供しないシステムでは、HTTP/HTTPSプロキシが必要になる場合があります。プロキシアクセスの構成については、AWSのドキュメントに詳しい説明があります。

次の環境変数をrootユーザーの.bashrcファイルに追加します。

export HTTP_PROXY=http://a.b.c.d:n
export HTTPS_PROXY=http://a.b.c.d:m
export NO_PROXY="169.254.169.254"

AWSのSAP用データプロバイダーはインスタンスのメタデータサービスに直接到達する必要があります。次の環境変数をrootユーザーの.bashrcファイルに追加します。

export NO_PROXY="127.0.0.1,localhost,localaddress,169.254.169.254"

SUSE Linux Enterprise HAEでは、プロキシ構成を/etc/sysconfig/pacemaker構成ファイルに次の形式で追加する必要もあります。

export HTTP_PROXY=http://username:password@a.b.c.d:n
export HTTPS_PROXY=http://username:password@a.b.c.d:m
export NO_PROXY="127.0.0.1,localhost,localaddress,169.254.169.254"

4.7.1 4.71 HTTPプロキシ設定の検証(オプション)

SUSEインスタンスがEC2インスタンスメタデータアドレスURL http://169.254.169.254/latest/meta-dataに到達可能であることを確認してください。これは、複数のシステムコンポーネントがアクセスする必要があるためです。したがって、制限するファイアウォールルールが存在する場合は無効化し、このURLへのプロキシアクセスを無効化することが推奨されます。

EC2インスタンスメタデータサーバーについて詳しくは、AWSのドキュメント(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)をご参照ください。

4.8 クラスターインスタンスの送信元/送信先チェックの無効化

クラスターの一部であるすべてのEC2インスタンスで、送信元/送信先チェックを無効化する必要があります。これは、AWSコマンドラインインターフェース(AWS-CLI)を使用するスクリプトまたはAWSコンソールの利用によって実行できます。クラスターの一部であるすべてのEC2インスタンスで、次のコマンドを一度だけ実行する必要があります。

# aws ec2 modify-instance-attribute --instance-id EC2-instance-id --no-source-dest-check

変数EC2-instance-idをAWS EC2インスタンスのインスタンスIDで置き換えます。このコマンドの実行対象となるシステムでは、次のポリシーを持つロールが一時的に必要です。

{
   "Version": "2012-10-17",
   "Statement": [
   {
      "Sid": "Stmt1424870324000",
      "Effect": "Allow",
      "Action": [ "ec2:ModifyInstanceAttribute"],
      "Resource": [
      "arn:aws:ec2:region-name:account-id:instance/instance-a",
      "arn:aws:ec2:region-name:account-id:instance/instance-b"
      ]
   }
   ]
}

次の個別パラメータを適切な値に置き換えます。

  • region-name(例: us-east-1)

  • account-id(例: 123456789012)

  • instance-a、instance-b(例: i-1234567890abcdef)

注記
注記

ポリシーに含まれる文字列「instance」は固定文字列です。置き換えが必要な変数ではありません。

送信元/送信先チェックはAWSコンソールから無効化することもできます。両方のEC2インスタンスのコンソールで、次のドロップダウンボックスから実行します(下図参照)。

PNG
図 6: コンソールで送信元/送信先チェックを無効化

4.9 eth0インターフェースにおけるオーバーレイIPアドレスの削除回避

SUSEのcloud-netconfig-ec2パッケージは、クラスターエージェントによって管理されるセカンダリIPアドレスを誤ってeth0インターフェースから削除する可能性があります。これによりクラスターサービスのユーザー向けのサービスが中断する場合があります。すべてのクラスターノードで次のタスクを実行します。

次のコマンドを使用して、パッケージcloud-netconfig-ec2がインストールされているかどうかを確認します。

# zypper info cloud-netconfig-ec2

パッケージがインストールされている場合、ファイル/etc/sysconfig/network/ifcfg-eth0を更新して次の行を「no」設定に変更するか、パッケージがまだインストールされていない場合は次の行を追加します。

CLOUD_NETCONFIG_MANAGE='no'

4.10 AWSロールおよびポリシー

SUSE Linux Enterprise HAEクラスターソフトウェアとそのエージェントは、クラスターを操作するためにいくつかのAWS IAM権限が必要です。クラスターの一部であるEC2インスタンスにIAMセキュリティロールをアタッチする必要があります。単一のIAMロールをクラスター全体で使用し、すべてのEC2インスタンスに関連付けることができます。

このIAMセキュリティロールには、ロールは、以下に説明するIAMセキュリティポリシーが必要です。

4.10.1 AWSデータプロバイダーポリシー

AWS上のSAPシステムには「AWS Data Provider for SAP」のインストールが必要で、AWSリソースにアクセスするためのポリシーが必要です。「AWS Data Provider for SAP Installation and Operations Guide」に示されているポリシーを使用し、クラスターEC2インスタンスによって使用されるIAMセキュリティロールにアタッチします。このポリシーはすべてのSAPシステムによって使用できます。「AWS Data Provider for SAP」では、1つのAWSアカウントにつきただ1つのポリシーが必要です。したがって、「AWS Data Provider for SAP」用のIAMセキュリティポリシーが既に存在する場合、それを使用できます。

{
    "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"
        }
    ]
}

4.10.2 オーバーレイIPエージェントポリシー

オーバーレイIPエージェントはAWSルーティングテーブル中のルーティングエントリを変更します。次に示すように、Manage-Overlay-IP-Policyなどの名前を持つポリシーを作成し、クラスターインスタンスのIAMセキュリティロールにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
           "Sid": "Stmt1424870324000",
           "Action": "ec2:ReplaceRoute",
           "Effect": "Allow",
           "Resource": "arn:aws:ec2:region-name:account-id:route-table/rtb-XYZ"
        },
        {
           "Sid": "Stmt1424870324000",
           "Action": "ec2:DescribeRouteTables",
           "Effect": "Allow",
           "Resource": "*"
        }
    ]
}

このポリシーによって、エージェントは使用されるルーティングテーブルを更新できます。次の変数を適切な名前に置き換えます。

  • region-name : AWSリージョンの名前

  • account-id : ポリシーが使用されるAWSアカウントの名前

  • rtb-XYZ : 更新する必要があるルーティングテーブルの識別子

4.11 ルーティングテーブルへのオーバーレイIPアドレスの追加

EC2クラスターインスタンスによって使用される2つのサブネットに割り当てられるルーティングテーブル中のルートエントリを作成します。このIPアドレスはHANAクラスターの仮想サービスIPアドレスです。オーバーレイIPアドレスは、VPCのCIDR範囲の外部にある必要があります。AWSコンソールを使用し、「VPC」を検索します。

  • VPCを選択

  • 左側の列で「Route Tables」をクリック

  • 使用するSAP EC2インスタンスとそのアプリケーションサーバーのいずれかからサブネットで使用されるルートテーブルを選択

  • 「Routes」タブをクリック

  • 「Edit」をクリック

  • リストの最後までスクロールし、「Add another route」をクリック

HANAデータベースのオーバーレイIPアドレスを追加します。フィルタとして/32を使用します(例: 192.168.10.1/32)。SAP HANAマスターになるEC2インスタンスにElastic Network Interface(ENI)名を追加します。リソースエージェントは、この後者を必要に応じて自動的に変更します。「Save」をクリックして変更内容を保存します。

注記
注記

ルーティングエントリを含むルーティングテーブルが、サービスのコンシューマを持つVPC内のすべてのサブネットに継承される必要があることは重要です。ルーティングテーブルの継承について詳しくは、AWS VPCのドキュメント(http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html)をご参照ください。

4.12 EFSファイルシステムの作成

SAP HANAスケールアウトクラスターの各セットは、独自のAmazon Elastic Filesystem(EFS)を持つ必要があります。EFSファイルシステムを作成するには、作成およびマウントの方法に関するステップバイステップのガイドを含む、AWSの公開ドキュメントをご確認ください(https://docs.aws.amazon.com/efs/latest/ug/getting-started.html参照)。

4.13 SAP HANA向けのOSの構成

使用するSAP HANAバージョンに対してOS(モジュール、パッケージ、カーネル設定など)を構成するには、以下のSAPノートを考慮してください。

SUSE Linux Enterprise Server for SAP Applications 12を使用する場合: - 1984787 SUSE LINUX Enterprise Server 12: Installation Notes - 2205917 SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12

SUSE Linux Enterprise Server for SAP Applications 15を使用する場合: - 2578899 SUSE Linux Enterprise Server 15: Installation Notes - 2684254 SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15

その他の関連SAPノート: - 1275776 Linux: Preparing SLES for SAP environments - 2382421 Optimizing the Network Configuration on HANA- and OS-Level

4.13.1 SAP HANAスケールアウトクラスターエージェントのインストール

SUSEは、SLES for SAPとともに、SAP HANA用の特殊なリソースエージェントを提供します。パターン「sap-hana」のインストールに伴い、SAP HANAスケールアップ用のリソースエージェントがインストールされますが、スケールアウトシナリオのためには特殊なリソースエージェントが必要です。既存のAWS Amazonマシンイメージ(AMI)に基づいてシステムをインストールしたか、AWSクイックスタートを使用してSAP HANAノードをデプロイした場合、各ノードで以下の手順に従ってください。パターンHigh Availabilityは、マジョリティメーカーノードなど、すべてのノードにインストールを推奨しているすべてのツールを要約します。

  • パッケージの削除: SAPHanaSR SAPHanaSR-doc yast2-sap-ha

  • パッケージのインストール: SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

例 1: スケールアップ用にSAPHanaSRエージェントをアンインストールする

rootユーザーとして、以下を実行します。

zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha
例 2: スケールアウト用にSAPHanaSRエージェントをインストールする

rootユーザーとして、以下を実行します。

zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

パッケージがまだインストールされていない場合、次のような出力が得られます。

Refreshing service 'Advanced_Systems_Management_Module_12_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_for_SAP_Applications_12_SP3_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 2 NEW packages are going to be installed:
  SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

2 new packages to install.
Overall download size: 539.1 KiB. Already cached: 0 B. After the operation, additional 763.1 KiB will be used.
Continue? [y/n/...? shows all options] (y): y
Retrieving package SAPHanaSR-ScaleOut-0.161.1-1.1.noarch                                                                            (1/2),  48.7 KiB (211.8 KiB unpacked)
Retrieving: SAPHanaSR-ScaleOut-0.161.1-1.1.noarch.rpm ....................................[done]
Retrieving package SAPHanaSR-ScaleOut-doc-0.161.1-1.1.noarch                                                                        (2/2), 490.4 KiB (551.3 KiB unpacked)
Retrieving: SAPHanaSR-ScaleOut-doc-0.161.1-1.1.noarch.rpm ................................[done (48.0 KiB/s)]
Checking for file conflicts: .............................................................[done]
(1/2) Installing: SAPHanaSR-ScaleOut-0.161.1-1.1.noarch ..................................[done]
(2/2) Installing: SAPHanaSR-ScaleOut-doc-0.161.1-1.1.noarch ..............................[done]

SUSEのHigh Availabilityパターンをインストール

zypper in --type pattern ha_sles

4.13.2 4.13.2 SUSEから入手可能な最新のアップデートをインストール

以前にパッケージをインストールしたことがある場合、リソースエージェントとその他のパッケージの最新バージョンを得るために、必ずすべてのマシンに最新のパッケージアップデートをインストールしてください。アップデートの入手には、SUSE Manager、SMT、またはSCC(SUSE Costumer Center)への直接接続など、複数の方法があります。

所属する会社またはユーザールールに応じて、zypper updateまたはzypper patchを使用します。

例 3: ソフトウェアアップデートは各ノードからトリガする必要がある

zypper patchは、入手可能で必要なパッチをすべてインストールします。rootユーザーとして、以下を実行します。

zypper patch

zypper updateは、可能な場合、すべてまたは特定のインストール済みパッケージを新しいバージョンで更新します。rootユーザーとして、以下を実行します。

zypper update

4.14 SAP HANAを実行するためのSLES for SAPの構成

4.14.1 チューニング/修正

必要なすべてのオペレーティングシステムチューニングは、SAPノート2684254とSAPノート2205917に説明があります。これらのSAPノートで述べられている各パラメータを手動で検証することをお勧めします。これは、SAP HANAのすべてのパフォーマンスチューニングが正しく設定されていることを確認するためです。

SAPノートで説明されている項目は次のとおりです。

  • SLES 15またはSLES 12

  • 追加のサードパーティ製カーネルモジュール

  • sapconfまたはsaptuneの構成

  • NUMAバランシングの停止

  • 透過的なHugePagesの無効化

  • Linuxにおける低レイテンシ用C-Stateの構成(インテルベースシステムにのみ適用)

  • CPU 周波数/電圧スケーリング(インテルベースシステムにのみ適用)

  • エネルギーパフォーマンスバイアス(EPB、インテルベースシステムにのみ適用)

  • Kernel Samepage Merging(KSM)の停止

  • Linux Pagecache Limit

4.14.2 公開鍵によるSSHアクセスの有効化(オプション)

公開鍵認証は、サーバーに対するパスワードなしのSSHアクセスを実現します。

この設定は、すべてのクラスターノードへのSSHアクセスを可能にする、ただ1つのSSHキーペアに基づいています。

例 4: SSHキーの作成と交換

rootユーザーとして、1つのノードのSSHキーを作成します。

ssh-keygen -t rsa

ssh-key生成により、不足しているパラメータが求められます。

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:ip/8kdTbYZNuuEUAdsaYOAErkwnkAPBR7d2SQIpIZCU root@<host1>
The key's randomart image is:
+---[RSA 2048]----+
|XEooo+ooo+o      |
|=+.= o=.o+.      |
|..B o. + o.      |
|   o  . +... .   |
|        S.. *    |
|     . o . B o   |
|    . . o o =    |
|     o . . +     |
|      +.. .      |
+----[SHA256]-----+

ssh-keygenが設定されると、/root/.ssh/の下に新しいファイルが2つ生成されます。

ls /root/.ssh/
id_rsa  id_rsa.pub

他のすべてのノードから公開ホストキーを収集します。ここではssh-keyscanコマンドを使用しました。

ssh-keyscan

最初のSSH接続時に、SSHホストキーは自動的に収集され、ファイル/root/.ssh/known_hostに格納されます。初回ログインの際に、ホストキーを受け入れる「yes」で確認することを避けるために、あらかじめホストキーを収集して格納します。

ssh-keyscan -t ecdsa-sha2-nistp256 <host1>,<host1 ip> >>.ssh/known_hosts
ssh-keyscan -t ecdsa-sha2-nistp256 <host2>,<host2 ip> >>.ssh/known_hosts
ssh-keyscan -t ecdsa-sha2-nistp256 <host3>,<host3 ip> >>.ssh/known_hosts
...

すべてのホストキーを収集した後で、authorized_keysという名前のファイルに格納します。完全なディレクトリ/root/.ssh/を最初のノードからすべてのクラスターメンバーにプッシュします。

rsync -ay /root/.ssh/ <host2>:/root/.ssh/
rsync -ay /root/.ssh/ <host3>:/root/.ssh/
rsync -ay /root/.ssh/ <host4>:/root/.ssh/
....

4.14.3 4.14.3 SAP HANA用のディスクレイアウトの設定

https://docs.aws.amazon.com/quickstart/latest/sap-hana/planning.htmlで説明されているストレージレイアウトに従うことを強く推奨します。このWebサイトの表には、使用するEC2インスタンスタイプに対して最低限必要なEBSボリュームの数、ボリュームサイズ、およびIOPS(IO1用)が示されています。ワークロードの要件に応じて、より大きなストレージまたはより高いIOPSを選択できます。次のEBSボリュームを構成します。

  • /hana/data

  • /hana/log

ファイルシステムは次のとおりです。

/hana/shared/<SID>

SAP HANAスケールアウトで、このディレクトリは同じスケールアウトクラスターのすべてのノードにマウントされ、AWSでこのディレクトリはEFSを使用します。バイナリ、トレース、ログファイルなどの共有ファイルを含みます。

/hana/log/<SID>

このディレクトリは、SAP HANAホストのredoログファイルを含みます。AWSでこのディレクトリはインスタンスに対してローカルです。

/hana/data/<SID>

このディレクトリは、SAP HANAホストのデータファイルを含みます。AWSでこのディレクトリはインスタンスに対してローカルです。

/usr/sap

これはローカルのSAPシステムのインスタンス用のディレクトリへのパスです。/usr/sapに対して別のボリュームを持つことをお勧めします。

4.15 ホスト名解決の構成

ホスト名解決を構成するために、DNSサーバーを使用するか、 すべてのクラスターノードで/etc/hostsファイルを変更することができます。

/etc/hostsファイルを管理することで、DNSサービスの障害による影響が最低限に抑えられます。すべてのクラスターノードで/etc/hostsファイルを編集し、すべてのクラスターノードのホスト名とIPを追加します。

vi /etc/hosts

次の行を/etc/hostsに挿入します。使用する環境に合わせてIPアドレスとホスト名を変更します。

192.168.201.151 suse01
192.168.201.152 suse02
...

4.16 すべてのノードでChrony/NTPサービスを有効化

デフォルトで、すべてのノードは自動的にAmazon Time Sync Serviceと同期します。すべてのノードのNTP/chrony構成/etc/chrony.confを参照し、タイムソースサーバーが169.254.169.123であることを確認します。

5 両サイトでのSAP HANAデータベースのインストール

インフラストラクチャの設定が終わったので、両サイトでSAP HANAデータベースをインストールできます。クラスター内のマシンはノードともいいます。

この例では、ドキュメントをよりわかりやすくするために、マシン(つまりノード)にsuse01、…​ suseXXという名前を付けています。奇数が付いているノード(suse01、suse03、suse05、…​)はサイト「A」(WDF1)の部分で、偶数が付いているノード(suse02、suse04、suse06、…​)はサイト「B」(ROT1)の部分です。

次のユーザーは、SAP HANAのインストール時に自動で作成されます。

<sid>adm

ユーザー<sid>admは、システムの開始および停止などの管理タスクに必要なOSユーザーです。

sapadm

SAPホストエージェントの管理者です。

SYSTEM

SAP HANAデータベースのスーパーユーザーです。

5.1 準備

  • SAPマーケットプレイスで入手可能なSAPインストールおよび設定ガイドを読みます。

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

  • SAP HANAデータベースソフトウェアおよびデータベースコンテンツ(データ、ログ、共有ファイル)をインストールするためにファイルシステムをマウントします。

5.2 インストレーション

SAP HANAサーバーインストールガイドの説明に従って、SAP HANAデータベースをインストールします。これを行うために、初めにHANAプライマリマスターサーバーを単一のスケールアップシステムとしてインストールします。完了したら、global.iniのパラメータ persistence/basepath_sharedを「no」に変更します。

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence','basepath_shared')='no';

これでHANAデータベースはすべてのノードにまたがって共有されるlog/dataディレクトリを必要としなくなります。この設定を適用した後で、データベースにホストを追加できます。同じアベイラビリティゾーン(プライマリサイト)にあるスケールアウトクラスターのすべてのHANAノードを追加します。

SAPノート2369981 - Required configuration steps for authentication with HANA System Replicationに従って、セカンダリサイトと暗号化キーを交換してください。

セカンダリサイトのマスターで同じ手順を繰り返し、SAP HANAデータベースをインストールします。persistence/basepath_sharedパラメータを変更し、セカンダリスケールアウトクラスターにノードを追加します。

5.3 チェック

両方のデータベースサイトが起動状態で、これらのデータベースのすべてのプロセスが正しく動作していることを確認します。

  1. Linuxユーザー<sid>admとして、SAPコマンドラインツールHDBを使用し、動作中のSAP HANAプロセスの概要を把握します。HDB infoの出力は、両方のサイトとも以下のスクリーンショットのように表示されます。

    例 5: HDB infoの呼び出し(ユーザー<sid>admとして)
    HDB info

    HDB infoコマンドは、該当のSIDに対して現在稼動中のプロセスを表示します。

    USER           PID  ...  COMMAND
    ha1adm         6561 ...  -csh
    ha1adm         6635 ...    \_ /bin/sh /usr/sap/HA1/HDB00/HDB info
    ha1adm         6658 ...        \_ ps fx -U HA1 -o user,pid,ppid,pcpu,vsz,rss,args
    ha1adm         5442 ...  sapstart pf=/hana/shared/HA1/profile/HA1_HDB00_suse01
    ha1adm         5456 ...   \_ /usr/sap/HA1/HDB00/suse01/trace/hdb.sap{sidlc}_HDB00 -d -nw -f /usr/sap/ha1/HDB00/suse
    ha1adm         5482 ...       \_ hdbnameserver
    ha1adm         5551 ...       \_ hdbpreprocessor
    ha1adm         5554 ...       \_ hdbcompileserver
    ha1adm         5583 ...       \_ hdbindexserver
    ha1adm         5586 ...       \_ hdbstatisticsserver
    ha1adm         5589 ...       \_ hdbxsengine
    ha1adm         5944 ...       \_ sapwebdisp_hdb pf=/usr/sap/HA1/HDB00}/suse01/wdisp/sapwebdisp.pfl -f /usr/sap/SL
    ha1adm         5363 ...  /usr/sap/HA1/HDB00/exe/sapstartsrv pf=/hana/shared/HA1/profile/HA1_HDB00_suse02 -D -u s
  2. PythonスクリプトlandscapeHostConfiguration.pyを使用して、SAP HANAサイト全体の状況を表示します。

    例 6: ホスト役割の照会(ユーザー<sid>admとして)
    HDBSettings.sh landscapeHostConfiguration.py

    ランドスケープホスト構成は、1つのSAP HANAホストにつき1行ずつ表示されます。

     | Host   | Host   |... NameServer  | NameServer  | IndexServer | IndexServer
     |        | Active |... Config Role | Actual Role | Config Role | Actual Role
     | ------ | ------ |... ----------- | ----------- | ----------- | -----------
     | suse01 | yes    |... master 1    | master      | worker      | master
     | suse03 | yes    |... master 2    | slave       | worker      | slave
     | suse05 | yes    |... master 3    | slave       | standby     | standby
    
     overall host status: ok
  3. 該当サイトのインスタンスの概要を把握します(ユーザー<sid>admとして)。

    例 7: インスタンスのリストを表示
    sapcontrol -nr <Inst> -function GetSystemInstanceList

    該当サイトに属するSAP HANAインスタンスのリストが表示されます。

    12.06.2018 17:25:16
    GetSystemInstanceList
    OK
    hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
    suse01, 00, 50013, 50014, 0.3, HDB|HDB_WORKER, GREEN
    suse05, 00, 50013, 50014, 0.3, HDB|HDB_WORKER, GREEN
    suse03, 00, 50013, 50014, 0.3, HDB|HDB_WORKER, GREEN

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

このセクションでは、SAP HANAが正しくインストールされた後のシステムレプリケーション(HSR)の設定について説明します。

手順

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

  2. プライマリデータベースを有効化する

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

  4. システムレプリケーションを検証する

詳しくはSAP HANA Administration Guideのセクション「Setting Up System Replication」をご参照ください。

6.1 プライマリデータベースをバックアップする

初めに、SAP HANA Administration Guideのセクション「SAP HANA Database Backup and Recovery」の説明に従って、プライマリデータベースをバックアップしてください。

SQLコマンドを使用してSAP HANAをバックアップする例をご紹介します。

例 8: 単一のバックアップ呼び出しを使用したシステムデータベースとすべてのテナントの単純なバックアップ

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

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)
例 9: シングルコンテナ(非MDC)データベースの単純なバックアップ

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

hdbsql -i <Inst> -u <dbuser> \
   "BACKUP DATA USING FILE ('backup')"
重要
重要

有効なバックアップがないと、SAP HANAをシステムレプリケーション構成に移行できません

6.2 プライマリデータベースを有効化する

Linuxユーザー<sid>admとして、プライマリノードでシステムレプリケーションを有効化します。システムレプリケーションを通じて接続されるすべてのSAP HANAデータベースに対して一意である必要があるサイト名(WDF1など)を定義する必要があります。つまり、セカンダリは異なるサイト名を持つ必要があります。

例 10: プライマリサイトでシステムレプリケーションを有効化

ユーザー<sid>admとして、次のようにプライマリを有効化します。

hdbnsutil -sr_enable --name=HAP

コマンド出力が以下のようになるか確認します。

nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

コマンドラインツールhdbnsutilを使用して、システムレプリケーションモードとサイト名をチェックできます。

例 11: プライマリでユーザー<sid>admとしてシステムレプリケーション構成状況をチェック
hdbnsutil -sr_stateConfiguration

プライマリでシステムレプリケーションの有効化に成功した場合、出力は以下のようになります。

checking for active or inactive nameserver ...
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

mode: primary
site id: 1
site name: HAP
done.

モードは「none」から「primary」に変わります。サイトはサイト名とサイトIDを持つようになります。

6.3 セカンダリデータベースを登録する

システムレプリケーションのためのシステム登録を行う前に、セカンダリ側のSAP HANAデータベースインスタンスを停止する必要があります。インスタンスを停止するために好みの方法を使用できます(HDBまたはsapcontrolなど)。データベースインスタンスが正常に停止した後で、hdbnsutilを使用してインスタンスを登録できます。

例 12: Linuxユーザー<sid>admとしてセカンダリを停止
sapcontrol -nr <Inst> -function StopSystem
例 13: Linuxユーザー<sid>admとしてセカンダリを登録
hdbnsutil -sr_register --name=<site2> \
     --remoteHost=<node1-siteA> --remoteInstance=<Inst> \
     --replicationMode=syncmem --operationMode=logreplay
adding site ...
checking for inactive nameserver ...
nameserver suse02:30001 not responding.
collecting information ...
updating local ini files ...
done.

remoteHostは今回のプライマリノードで、remoteInstanceはデータベースインスタンス番号(ここでは00)です。

ここで、セカンダリデータベースインスタンスを再び起動し、システムレプリケーション状況を検証します。セカンダリサイトで、モードは「SYNC」、「SYNCMEM」、「ASYNC」のいずれかである必要があります。モードは、セカンダリの登録時に定義される同期オプションに依存します。

例 14: セカンダリサイトでユーザー<sid>admとしてシステムを起動
sapcontrol -nr <Inst> -function StartSystem

SAP HANAデータベースが完全に起動するまで待機します。

例 15: ユーザー<sid>admとしてシステムレプリケーション構成をチェック
hdbnsutil -sr_stateConfiguration

出力は次のようになります。

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~
mode: sync
site id: 2
site name: HAS
active primary site: 1

primary masters: suse01 suse03 suse05
done.

6.4 システムレプリケーションを検証する

SAP HANAクラスター全体のレプリケーション状態を表示するには、 プライマリサイトで、<sid>admユーザーとして次のコマンドを使用します。

例 16: プライマリサイトでシステムレプリケーション状況をチェック(<sid>admとして)
HDBSettings.sh systemReplicationStatus.py

このスクリプトは、システムレプリケーションのチャネルとそれぞれのステータスを人間が読み取れる表形式で出力します。最も興味深い列はReplication Statusで、ACTIVEになっている必要があります。

| Database | Host   | .. Site Name | Secondary | .. Secondary | .. Replication
|          |        | ..           | Host      | .. Site Name | .. Status
| -------- | ------ | .. --------- | --------- | .. --------- | .. ------
| SYSTEMDB | suse01 | .. HAP      | suse02    | .. HAS      | .. ACTIVE
| HA1      | suse01 | .. HAP      | suse02    | .. HAS      | .. ACTIVE
| HA1      | suse01 | .. HAP      | suse02    | .. HAS      | .. ACTIVE
| HA1      | suse03 | .. HAP      | suse04    | .. HAS      | .. ACTIVE

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: HAP

7 SAP HANAとクラスターの統合

次のステップを進める必要があります。

手順

  1. PythonフックSAPHanaSRを実装する

  2. システムレプリケーション動作モードを構成する

  3. <sid>admがクラスターにアクセスできるようにする

  4. SAP HANAを起動する

  5. フック統合をテストする

7.1 PythonフックSAPHanaSRを実装する

SUSEのSAPHanaSR-ScaleOutリソースエージェントには、SAP HANAレプリケーションの障害を処理し、同期していないSAP HANAノードへのクラスターフェイルオーバーを防いでデータ損失を避けるためのSAP HANA統合スクリプトが含まれています。

この統合スクリプトは、SAP HANAの「srConnectionChanged」フックを監視します。いずれかの複製サービスでシステムレプリケーション接続の損失またか確立が発生し、クラスターに通知されると、マスターネームサーバーでsrConnectionChanged()メソッドが呼び出されます。

このステップは両方のサイトで完了する必要があります。global.iniを変更して、SAP HANAが起動時にHA/DRフックスクリプトを統合可能にするには、SAP HANAを停止する必要があります。

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

  • フックをglobal.iniに統合する(オフラインで行うためにSAP HANAを停止する必要がある)

  • 起動時にフックの統合をチェックする

SAPHanaSR-scaleOutパッケージからフックを取得し、/hana/share/myHooksなど、任意のディレクトリにコピーします。フックはすべてのSAP HANAノードで使用可能である必要があります。

suse01~ # mkdir -p /hana/shared/myHooks
suse01~ # cp /usr/share/SAPHanaSR-ScaleOut/SAPHanaSR.py /hana/shared/myHooks
suse01~ # chown -R <sid>adm:sapsys /hana/shared/myHooks

SAP HANAを停止

sapcontrol -nr <Inst> -function StopSystem
例 17: global.iniによりSAPHanaSRを追加
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /hana/shared/myHooks
execution_order = 1

[trace]
ha_dr_saphanasr = info

7.2 システムレプリケーション動作モードを構成する

使用するシステムがSAPHanaSRターゲットとして接続されると、global.iniに動作モードを定義するエントリが見つかります。現時点では2つのモードを使用できます。

  • delta_datashipping

  • logreplay

テイクオーバーと逆方向の再登録が発生するまで、プライマリサイトでの動作モードのエントリは存在しません。「古典的な」動作モードはdelta_datashippingです。HAで推奨されるモードはlogreplayです。logreplay動作モードを使用すると、SAP HANAシステムレプリケーションのセカンダリサイトがHotStandbyシステムになります。両方のモードについて詳しくは、「How To Perform System Replication for SAP HANA」など、入手可能なSAPドキュメントをご参照ください。

両方のglobal.iniファイルをチェックし、必要に応じて動作モードを追加します。

セクション

[ system_replication ]

キー

operation_mode = logreplay

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

[system_replication]
operation_mode = logreplay

7.3 <sid>admがクラスターにアクセスできるようにする

SAPHanaSR Pythonフックの現行バージョンは、「sudo」コマンドを使用して、<sid>admがクラスター属性にアクセスできるようにします。Linuxでは、「visudo」を使用して、「/etc/sudoers」構成ファイル用にviエディタを起動できます。

ユーザー<sid>admは、クラスター属性hana_<sid>_glob_srHook_*を設定できる必要があります。SAP HANAシステムレプリケーションフックには、パスワード不要のアクセスが必要です。次の例では、sudoアクセスを必要な属性の設定のみに制限しています。

<sid>を小文字のSAPシステムIDに置き換えます。

この変更はすべてのクラスターノードで必要です。

例 18: sudo権限/etc/sudoersファイルのエントリ

<sidadm>がsrHookを使用可能にするための基本的なパラメータオプション。

# SAPHanaSR-ScaleOut needs for srHook
<sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_<sid>_glob_srHook -v *

高いセキュリティレベルを満たすためのより特殊なパラメータオプション。

# SAPHanaSR-ScaleOut needs for srHook
Cmnd_Alias SOK   = /usr/sbin/crm_attribute -n hana_<sid>_glob_srHook -v SOK   -t crm_config -s SAPHanaSR
Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_<sid>_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
<sid>adm ALL=(ALL) NOPASSWD: SOK, SFAIL
例 19: <sid>をha1で置き換えた結果
# SAPHanaSR-ScaleOut needs for srHook
hd1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_ha1_glob_srHook -v *

7.4 SAP HANAを起動する

SAP HANA統合の構成が完了し、SAP HANA間の通信が確立したら、クラスターが両サイトでSAP HANAデータベースを起動できるようになります。

例 20: <sid>admとして完全なSAP HANAサイトを起動
sapcontrol -nr <Inst> -function StartSystem

sapcontrolサービスはOKで要求をコミットします。

11.06.2018 18:30:16
StartSystem
OK

次のように、SAP HANAの起動完了をチェックします。

sapcontrol -nr <Inst> -function WaitforStarted 300 20

7.5 フック統合をテストする

変更後にSAP HANAデータベースが再起動したら、フックスクリプトが正しく呼び出されることをチェックします。

次のように、<sid>admとして、SAP HANAトレースファイルをチェックします。

suse01:ha1adm> cdtrace
suse01:ha1adm> awk  '/ha_dr_SAPHanaSR.*crm_attribute/ \
     { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_suse01.*
2018-05-04 12:34:04.476445 ha_dr_SAPHanaSR SFAIL
2018-05-04 12:53:06.316973 ha_dr_SAPHanaSR SOK

「ha_dr_SAPHanaSR」メッセージが表示される場合、フックスクリプトは呼び出され、実行されています。

8 クラスターとSAP HANAリソースの構成

この章では、SUSE Linux Enterprise High Availability(SLE HA)クラスターの構成について説明します。SUSE Linux Enterprise High Availabilityは、SUSE Linux Enterprise Server for SAP Applicationsの一部です。さらに、SUSE Linux Enterprise High AvailabilityクラスターによるSAP HANAシステムレプリケーションの統合について説明します。この統合は、同様にSUSE Linux Enterprise Server for SAP Applicationsの一部である、SAPHanaSR-ScaleOutパッケージを使用して行われます。

手順

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

  2. クラスタープロパティおよびリソースの構成

  3. 最終ステップ

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

8.1.1 SBDフェンシング用のウォッチドッグの設定

すべてのインスタンスは、SUSEのディスクレスSBDフェンシングメカニズムを使用します。この方式では、SBDがAWS API呼び出しを発行しないので、追加のAWS権限は必要ありません。その代わりに、SBDは(ハードウェア/ソフトウェア)ウォッチドッグタイマーを利用します。

ほとんどのAWSベアメタルインスタンスはハードウェアウォッチドッグを備えており、こうしたインスタンスではハードウェアウォッチドッグを使用するために追加の操作はなく、非ベアメタルインスタンスはソフトウェアウォッチドッグを使用します。

SBDが使用される場合は常に、正しく動作するウォッチドッグが非常に重要です。最近のシステムは、ソフトウェアコンポーネントによる「くすぐり」、つまり「入力」が必要なウォッチドッグをサポートしています。ソフトウェアコンポーネント(通常はデーモン)が定期的にサービスパルスをウォッチドッグに書き込みます。デーモンがウォッチドッグへの入力を停止した場合、ハードウェアがシステム再起動を強制します。これにより、SBDプロセス自体の障害(停止など)またはI/Oエラーによる動作不能から保護されます。

適切なウォッチドッグモジュールを特定します。使用するカーネルバージョンとともにインストールされているドライバのリストを確認することもできます。

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

ウォッチドッグモジュールが既にロード済みかどうかをチェックします。

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

結果が表示される場合、システムにはロード済みのウォッチドッグが存在します。

ウォッチドッグを使用しているソフトウェアがあるかどうかをチェックします。

lsof /dev/watchdog

使用可能なウォッチドッグがない場合(仮想化されたEC2インスタンス上)、softdogを有効化できます。

再起動した後も永続的にsoftdogを有効化するには、クラスターの一部になるすべてのEC2インスタンスで(マジョリティメーカーノードを含む)、次のステップを実行します。

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

これにより、システムブート時に、ソフトウェアウォッチドッグカーネルモジュールもロードされます。

ウォッチドッグモジュールが正しくロードされているかチェックします。

lsmod | grep dog

ウォッチドッグのテストは、簡単な操作で実行できます。ウォッチドッグはシステムのクリーンでないリセットまたはシャットダウンを強制するので、始めにSAP HANAをオフにするよう注意してください。

ハードウェアウォッチドッグの場合、ウォッチドッグのタイムアウトに到達した後の適切な動作があらかじめ定義されています。ウォッチドッグモジュールがロードされており、他のアプリケーションによって制御されていない場合、下記のコマンドを実行します。

重要
重要

ウォッチドッグへの継続的な入力が無いまま、ウォッチドッグをトリガすると、システムのリセットまたはシャットダウンが発生します。これは意図されたメカニズムです。次のコマンドは、システムのリセットまたは電源オフを強制します。

touch /dev/watchdog

softdogモジュールが使用される場合は、以下を実行できます。

echo 1> /dev/watchdog

テストが正常終了したら、すべてのクラスターメンバーにウォッチドッグを実装できます。下記の例はsoftdogモジュールに適用されます。

for i in suse{02,03,04,05,06,-mm}; do
 ssh -T $i <<EOSSH
 hostname
 echo softdog > /etc/modules-load.d/watchdog.conf
 systemctl restart systemd-modules-load
 lsmod |grep -e dog
EOSSH
done

すべてのクラスターノードが/dev/watchdogにあるハードウェア/ソフトウェアウォッチドッグデバイスにアクセスできたら、すべてのクラスターノードの/etc/sysconfig/sbdで、次に示すSBD構成の属性をチェックします。

#SBD_DEVICE=""
SBD_PACEMAKER=yes
SBD_STARTMODE=always
SBD_DELAY_START=no
SBD_WATCHDOG_DEV=/dev/watchdog
SBD_WATCHDOG_TIMEOUT=5
SBD_TIMEOUT_ACTION=flush,reboot
SBD_OPTS=

ここで、すべてのクラスターノードでディスクレスSBDを有効化します。

systemctl enable sbd

8.1.2 クラスターの初期設定

AWS VPCはマルチキャストトラフィックをサポートしないため、Corosync通信にはユニキャストUDPが必要です。最初のクラスターノードで、次のようにクラスター通信用の暗号化キーを作成します。

corosync-keygen

上記のコマンドはファイル/etc/corosync/authkeyを生成します。次に示すように、UNIXファイル所有者および権限を変更せず、このキーをすべてのノードにコピーします。

ls -l /etc/corosync/authkey
-r-------- 1 root root 128 Feb  5 19:47 /etc/corosync/authkey

暗号化キーの配布が済んだら、クラスタータイミング、トランスポートプロトコル、および暗号化のパラメータを使用して、初期の/etc/corosync/corosync.conf構成を作成します。使用するネットワークトポロジに従って、ノードリスト中のすべてのクラスターノードのbindnetaddrおよびring0_addr(IPv4アドレス)を交換します。

corosync.confファイルの例:

# Read the corosync.conf.5 manual page
totem {
   version: 2
   token: 30000
   consensus: 32000
   token_retransmits_before_loss_const: 6
   secauth: on
   crypto_hash: sha1
   crypto_cipher: aes256
   clear_node_high_bit: yes
   interface {
      ringnumber: 0
      bindnetaddr: <<local-node-ip-address>>
      mcastport: 5405
      ttl: 1
   }
   transport: udpu
}
logging {
   fileline: off
   to_logfile: yes
   to_syslog: yes
   logfile: /var/log/cluster/corosync.log
   debug: off
   timestamp: on
   logger_subsys {
      subsys: QUORUM
      debug: off
   }
}
nodelist {
   node {
      ring0_addr: <<ip-node01-AZ-a>>
      nodeid: 1
   }
   node {
      ring0_addr: <<ip-node02-AZ-a>>
      nodeid: 2
   }
   node {
      ring0_addr: <<ip-node03-AZ-a>>
      nodeid: 3
   }
   node {
      ring0_addr: <<ip-node01-AZ-b>>
      nodeid: 4
   }
   node {
      ring0_addr: <<ip-node02-AZ-b>>
      nodeid: 5
   }
   node {
      ring0_addr: <<ip-node03-AZ-b>>
      nodeid: 6
   }
   node {
      ring0_addr: <<ip-majority-maker-node>>
      nodeid: 7
   }
}
quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
   provider: corosync_votequorum
}

構成を/etc/corosync/corosync.confのすべてのノードに配布

8.1.3 クラスターを起動する

すべてのノードでクラスターを起動

systemctl start pacemaker
注記
注記

すべてのノードは並行して起動する必要があります。そうしないと、確認されないノードがフェンシングされる場合があります。

crm_monを使用して、クラスターステータスをチェックします。ここではオプション「-r」を使用して、構成済みではあるが停止していないリソースも確認します。

crm_mon -r

このコマンドは「空の」クラスターを表示し、次の画面出力のようになります。ここで最も興味深い情報は、ステータスが「online」で「partition with quorum」というメッセージのノードが2つあることです。

Stack: corosync
Current DC: suse05 (version 1.1.18+20180430.b12c320f5-3.15.1-b12c320f5) - partition with quorum
Last updated: Fri Nov 29 14:23:19 2019
Last change: Fri Nov 29 12:31:06 2019 by hacluster via crmd on suse03

7 nodes configured
0 resource configured

Online: [ suse-mm suse01 suse02 suse03 suse04 suse05 suse06 ]

No resources

8.2 クラスタープロパティおよびリソースの構成

このセクションでは、crm構成シェルコマンドを使用して、クラスターリソース、STONITH、および制約を構成する方法について説明します。このことは、SUSE Linux Enterprise High Availability Administration GuideのセクションConfiguring and Managing Cluster Resources(コマンドライン)、SUSE Linux Enterprise High Availability(https://www.suse.com/documentation/sle-ha-12/singlehtml/book_sleha/book_sleha.html#cha.ha.manual_config)にも詳しい説明があります。

コマンドcrmを使用して、オブジェクトをCluster Resource Management(CRM)に追加します。以下の例をローカルファイルにコピーした後、構成をCluster Information Base(CIB)にロードします。ここで便利なのは、設定がスクリプト化され、構成のバックアップが得られることです。

すべてのcrmコマンドをただ1つのノード(たとえばマシンsuse01)で実行します。

初めに構成を含むテキストファイルを作成して、2番目のステップでクラスターにロードします。このステップは次のとおりです。

vi crm-file<XX>
crm configure load update crm-file<XX>

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

最初の例は、リソースと動作のデフォルトを含むクラスターブートストラップオプションを定義します。

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

vi crm-bs.txt

以下をcrm-bs.txtに入力

property $id="cib-bootstrap-options" \
            no-quorum-policy="freeze" \
            stonith-enabled="true" \
            stonith-action="reboot" \
            stonith-watchdog-timeout="10" \

op_defaults $id="op-options" \
            timeout="600"

rsc_defaults rsc-options: \
            resource-stickiness="1000" \
            migration-threshold="5"

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

crm configure load update crm-bs.txt

8.2.2 STONITH

本ドキュメントの要件セクションで説明したように、サポートされるクラスター設定にSTONITHは非常に重要です。有効なフェンシングメカニズムがない場合、クラスターはサポート対象外になります。

標準のSTONITHメカニズムとして、ディスクレスSBDフェンシングが実装されます。SBD STONITH手法は安定性と信頼性が非常に高く、非常に優れたロード機能であることが実証されています。

利用可能な他のフェンシング方式を使用することができます。ただし、あらゆる状況下でサーバーフェンシングを徹底的にテストすることが不可欠です。

ディスクレスSBDが構成済みで有効化されている場合、クラスターとともにSBDデーモンが自動的に起動します。これは以下のように確認できます。

# systemctl status sbd
● sbd.service - Shared-storage based fencing daemon
   Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-02-15 08:12:57 UTC; 1 months 22 days ago
     Docs: man:sbd(8)
  Process: 10366 ExecStart=/usr/sbin/sbd $SBD_OPTS -p /var/run/sbd.pid watch (code=exited, status=0/SUCCESS)
 Main PID: 10374 (sbd)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/sbd.service
           ├─10374 sbd: inquisitor
           ├─10375 sbd: watcher: Pacemaker
           └─10376 sbd: watcher: Cluster

8.2.3 メンテナンスモードのクラスター

リソースと制約の構成をステップバイステップでクラスターにロードします。予期しないクラスター反応を避けるための最適な方法は、初めに完全なクラスターをメンテナンスモードに設定することです。次に、必要なすべての変更を行った後、最後のステップとして、クラスターをメンテナンスモードから解除できます。

crm configure property maintenance-mode=true

8.2.4 SAPHanaTopology

次に、SAP HANAインスタンスを起動する前に、必要なリソースのグループを定義します。変更内容をテキストファイル(たとえばcrm-saphanatop.txtなど)に準備し、crmコマンドを使用してロードします。

SIDインスタンス番号(太字)を実際の値に変更する必要があります。

例 21: SAPHanaTopologyの構成
suse01:~ # vi crm-saphanatop.txt

以下をcrm-saphanatop.txtに入力

primitive rsc_SAPHanaTop_<SID>_HDB<Inst> ocf:suse:SAPHanaTopology \
        op monitor interval="10" timeout="600" \
        op start interval="0" timeout="600" \
        op stop interval="0" timeout="300" \
        params SID="<SID>" InstanceNumber="<Inst>"

clone cln_SAPHanaTop_<SID>_HDB<Inst> rsc_SAPHanaTop_<SID>_HDB<Inst> \
        meta clone-node-max="1" interleave="true"
primitive rsc_SAPHanaTop_HA1_HDB00 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="00"

clone cln_SAPHanaTop_HA1_HDB00 rsc_SAPHanaTop_HA1_HDB00 \
        meta clone-node-max="1" interleave="true"

すべてのパラメータに関する追加情報は、コマンド man ocf_suse_SAPHanaTopologyを使用して確認できます。

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

crm configure load update crm-saphanatop.txt

ここで最も重要なパラメータは、SID(HA1)とInstanceNumber(00)であり、SAPのコンテキストでは自明です。

これらのパラメータのほかに、タイムアウト値または動作(start、monitor、stop)が実際の環境に合わせる必要がある代表的な値です。

8.2.5 SAPHanaController

次に、SAP HANAインスタンスを起動する前に、必要なリソースのグループを定義します。変更内容をテキストファイル(たとえばcrm-saphanacon.txtなど)で編集し、crmコマンドを使用してロードします。

vi crm-saphanacon.txt
例 22: SAPHanaControllerの構成

以下をcrm-saphanacon.txtに入力

primitive rsc_SAPHanaCon_<SID>_HDB<Inst> ocf:suse:SAPHanaController \
        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="<SID>" InstanceNumber="<Inst>" \
        PREFER_SITE_TAKEOVER="true" \
        DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

ms msl_SAPHanaCon_<SID>_HDB<Inst> rsc_SAPHanaCon_<SID>_HDB<Inst> \
        meta clone-node-max="1" master-max="1" interleave="true"

ここで最も重要なパラメータは、SID(HA1)と<Inst>(00)であり、SAPのコンテキストでは自明です。これらのパラメータのほかに、タイムアウト値または動作(start、monitor、stop)が代表的な調整可能値です。

primitive rsc_SAPHanaCon_HA1_HDB00 ocf:suse:SAPHanaController \
        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="00" PREFER_SITE_TAKEOVER="true" \
        DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

ms msl_SAPHanaCon_HA1_HDB00 rsc_SAPHanaCon_HA1_HDB00 \
        meta clone-node-max="1" master-max="1" interleave="true"

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

crm configure load update crm-saphanacon.txt
表 2: 重要なリソースエージェントパラメータの説明表
名前説明

PREFER_SITE_TAKEOVER

RAで障害発生プライマリをローカルで再起動するよりもセカンダリインスタンスへのテイクオーバーが優先されるかどうかを定義します。

AUTOMATED_REGISTER

元のプライマリが新しいプライマリのセカンダリに自動登録される必要があるかどうかを定義します。このパラメータにより、システムレプリケーション自動化のレベルを適応できます。

falseに設定されている場合、元のプライマリは手動で登録する必要があります。プライマリが二重に稼動する状況を回避するために、登録が済むまで、クラスターはこのSAP HANA RDBMSを起動しません。

DUPLICATE_PRIMARY_TIMEOUT

二重プライマリ状況が発生した場合に、2つのプライマリタイムスタンプ間に必要な時差。この時差が時間のギャップよりも小さい場合、クラスターは一方または両方のサイトを「WAITING」ステータスで保留します。これにより、管理者はフェールオーバーに対処する機会が得られます。元のプライマリのノードが完全にクラッシュした場合、この時差が経過した後で元のプライマリが登録されます。SAP HANA RDBMS「のみ」がクラッシュした場合、元のプライマリはすぐに登録されます。この新しいプライマリへの登録後、システムレプリケーションによってすべてのデータが上書きされます。

すべてのパラメータに関する追加情報は、コマンド man ocf_suse_SAPHanaControllerを使用して確認できます。

8.2.6 オーバーレイIPアドレス

クラスターに追加する最後のリソースは、オーバーレイIPアドレスを扱います。太字を実際のインスタンス番号、SAP HANAシステムID、AWS VPCルーティングテーブル、およびオーバーレイIPアドレスで置き換えます。

例 23: IPアドレスの構成
vi crm-oip.txt

以下をcrm-oip.txtに入力

primitive rsc_ip_<SID>_HDB<Inst> ocf:heartbeat:aws-vpc-move-ip \
        op start interval=0 timeout=180 \
        op stop interval=0 timeout=180 \
        op monitor interval=60 timeout=60 \
        params ip=<overlayIP> routing_table=<aws-route-table>[,<2nd-route-table>] \
        interface=eth0 profile=<aws-cli-profile>

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

crm configure load update crm-oip.txt

オーバーレイIPアドレスは、VPCのCIDR範囲の外部にある必要があります。

8.2.7 制約

制約は、クライアントデータベースアクセスのための仮想IPアドレスの正しい配置と2つのリソースエージェントSAPHanaおよびSAPHanaTopology間の起動順序を整理します。ルールは、crm_monコマンドからのフォールスポジティブメッセージを除去するのに役立ちます。

例 24: 必要な制約の構成
vi crm-cs.txt

以下をcrm-cs.txtに入力

colocation col_saphana_ip_<SID>_HDB<Inst> 2000: rsc_ip_<SID>_HDB<Inst>:Started \
 msl_SAPHanaCon_<SID>_HDB<Inst>:Master
order ord_SAPHana_<SID>_HDB<Inst> Optional: cln_SAPHanaTop_<SID>_HDB<Inst> \
 msl_SAPHanaCon_<SID>_HDB<Inst>
location OIP_not_on_majority_maker rsc_ip_<SID>_HDB<Inst> -inf: <majority maker>
location SAPHanaCon_not_on_majority_maker msl_SAPHanaCon_<SID>_HDB<Inst> -inf:
 <majority maker>
location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_<SID>_HDB<Inst> -inf:
 <majority maker>

「<SID>」をSAP SIDで、「<Inst>」をSAP HANAインスタンス番号で、「<majority maker>」をマジョリティメーカーノードのホスト名でそれぞれ置き換えます。

colocation col_saphana_ip_HA1_HDB00 2000: rsc_ip_HA1_HDB00:Started \
 msl_SAPHanaCon_HA1_HDB00:Master
order ord_SAPHana_HA1_HDB00 Optional: cln_SAPHanaTop_HA1_HDB00 \
 msl_SAPHanaCon_HA1_HDB00
location OIP_not_on_majority_maker rsc_ip_HA1_HDB00 -inf: suse-mm
location SAPHanaCon_not_on_majority_maker msl_SAPHanaCon_HA1_HDB00 -inf: suse-mm
location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_HA1_HDB00 -inf: suse-mm

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

crm configure load update crm-cs.txt

8.3 最終ステップ

8.3.1 クラスターメンテナンスモードの終了

クラスターを構成するためにメンテナンスモードが有効化されている場合は、最後のステップとして、クラスターのメンテナンスモードを解除する必要があります。

必要なノードでSAP HANAおよびその他のクラスターサービスを起動する必要がある場合があるので、クラスターが安定するまでに数分かかることがあります。

crm configure property maintenance-mode=false

8.3.2 フックとクラスター間の通信の検証

ここで、HA/DRプロバイダが適切なクラスター属性hana_<sid>_glob_srHookを設定できるかどうかチェックします。<sid>を小文字のSAPシステムID(ha1など)に置き換えます。

例 25: srHookクラスター属性の照会
crm_attribute -G -n hana_<sid>_glob_srHook

次のような出力が得られます。

scope=crm_config  name=hana_<sid>_glob_srHook value=SOK

この場合、HA/DRプロバイダーは、SAP HANAレプリケーションステータスについてクラスターに通知するため、属性をSOKに設定します。

8.3.3 SAP HANAのインストール時に特殊な仮想ホスト名つまりFQHNを使用

短いノード名の代わりに特殊な仮想ホスト名つまり完全修飾ホスト名(FQHN)を使用した場合、リソースエージェントはこれらの名前をマッピングする必要があります。短いノード名と使用されたSAP「仮想ホスト名」を一致させるには、次のように、saphostagentがインストール済みのインスタンスのリストを正しく報告する必要があります。

例 26: 今回の設定では仮想ホスト名とノード名が一致
suse01:ha1adm> /usr/sap/hostctrl/exe/saphostctrl -function ListInstances
 Inst Info : HA1 - 00 - suse01 - 749, patch 418, changelist 1816226

9 クラスターのテスト

テストはクラスターの実装で最も重要なプロジェクトタスクの1つです。適切なテストが不可欠です。プロジェクトまたはユーザーの期待から導き出されるすべてのテストケースが定義され、完全に合格することを確認してください。テストなしでは、プロジェクトが本稼働で失敗する可能性があります。

特に明記されていない限り、テストの前提条件は常に、すべてのクラスターノードがブートされれていること、すべてのクラスタ-ノードが既にクラスターの正規メンバーであること、およびSAP HANA RDBMSが稼動中であることです。システムレプリケーションは、「SOK」で表される同期中です。クラスターはアイドルで、保留中のアクションはなく、移行制約は残っておらず、フェイルカウントは残っていません。

本バージョンの設定ガイドでは、テストケースの計画リストを提供します。将来はテストケースをより詳細に記述する予定です。本ガイドの更新版でこれらの詳細を提供するか、テストケースを抽出して別のテスト計画ドキュメントとします。

9.1 一般的なクラスターテスト

この種類のクラスターテストは、動作中のクラスター反応を扱います。この中には、完全なクラスターの起動と停止、SBD障害のシミュレーションなどが含まれます。

  • すべてのクラスターノードの並行起動(systemctl start pacemakerは短い時間枠で実行する必要があります)。

  • 完全なクラスターの停止。

  • 2つあるSAP HANAサイトの一方を分離。

  • マジョリティメーカーを電源オフ。

  • クラスターを連続稼動させた状態でメンテナンス手順をシミュレート。

  • クラスターを再起動した状態でメンテナンス手順をシミュレート。

  • いずれかのクラスターノードのCorosyncプロセスを停止。

9.2 プライマリサイトでのテスト

この種類のテストは、プライマリサイトのいくつかの障害に対する反応をチェックします。

9.2.1 プライマリサイトのクラスターノードに関するテスト

ここに示すテストは、プライマリサイトの1つ以上のノードが障害を起こすか、クラスターに復帰する場合のSAP HANAおよびクラスターの反応をチェックします。

  • プライマリのマスターネームサーバーを電源オフ。

  • プライマリのいずれかのワーカーノードを電源オフ(ただしマスターネームサーバーは除く)。

  • 以前に電源オフしたクラスターノードの復帰。

9.2.2 完全なプライマリサイトに関するテスト

このテストカテゴリは完全なサイト障害をシミュレートします。

  • プライマリのすべてのノードを並行して電源オフ。

9.2.3 プライマリサイトのSAP HANAインスタンスに関するテスト

ここに示すテストは、停止したSAP HANAインスタンスなどのアプリケーション障害によって引き起こされるSAP HANAおよびクラスターの反応に関するチェックです。

  • プライマリのマスターネームサーバーのSAP HANAインスタンスを停止。

  • プライマリのいずれかのワーカーノードのSAP HANAインスタンスを停止(ただしマスターネームサーバーは除く)。

  • プライマリのいずれかのSAP HANAインスタンスのsapstartrvを停止。

9.3 プライマリサイトでのテスト

この種類のテストは、セカンダリサイトのいくつかの障害に対する反応をチェックします。

9.3.1 プライマリサイトのクラスターノードに関するテスト

ここに示すテストは、セカンダリサイトの1つ以上のノードが障害を起こすか、クラスターに復帰する場合のSAP HANAおよびクラスターの反応をチェックします。

  • セカンダリのマスターネームサーバーを電源オフ。

  • セカンダリのいずれかのワーカーノードを電源オフ(ただしマスターネームサーバーは除く)。

  • 以前に電源オフしたクラスターノードの再参加。

9.3.2 完全なプライマリサイトに関するテスト

このテストカテゴリは完全なサイト障害をシミュレートします。

  • セカンダリのすべてのノードを並行して電源オフ。

9.3.3 プライマリサイトのSAP HANAインスタンスに関するテスト

ここに示すテストは、停止したSAP HANAインスタンスなどのアプリケーション障害によって引き起こされるSAP HANAおよびクラスターの反応に関するチェックです。

  • セカンダリのマスターネームサーバーのSAP HANAインスタンスを停止。

  • セカンダリのいずれかのワーカーノードのSAP HANAインスタンスを停止(ただしマスターネームサーバーは除く)。

  • セカンダリのいずれかのSAP HANAインスタンスのsapstartrvを停止。

10 管理

10.1 注意事項

プロジェクトで行うべきことを以下に示します。

  • クラスターに他のリソースを追加する前にSTONITHの定義(およびテスト)を行う。

  • 徹底的なテストを行う。

  • SAPHanaControllerおよびSAPHanaTopologyの動作のタイムアウトを微調整する。

  • PREFER_SITE_TAKEOVER=trueAUTOMATED_REGISTER=false、およびDUPLICATE_PRIMARY_TIMEOUT=”7200”で開始する。

  • クラスター構成にクライアント優先ロケーションの制約またはフェイルカウントが残っていないことを常に確認する。

  • テスト実行またはメンテナンス手順を開始する前に、クラスターがアイドル状態であるかチェックする。

プロジェクトで避けるべきことを以下に示します。

  • クラスター構成を急激に変更したり変更を元に戻したりすること。例: ノードをスタンバイに設定して再びオンラインに設定する、マスター/スレーブリソースを停止/開始する、など。

  • ホスト、ユーザー、グループの適切な時刻同期をしなかったり、不安定な名前解決でクラスターを作成する。

  • クローン、マスター/スレーブ、またはIPリソースのロケーションルールの追加。この設定ガイドで述べられているロケーションルールのみが許容されます。

  • CRMシェルでリソースを「migrate」または「move」すると、HAWKなどのツールがクライアント優先ロケーションを追加する場合があります。この動作は完全に禁止されています。

10.2 監視とツール

クラスターステータス要求には、High Availability Web Konsole(HAWK)、SAP HANA Studio、およびその他のコマンドラインツールを使用できます。

10.2.1 HAWK – クラスターステータスなど

インターネットブラウザを使用して、クラスターステータスをチェックできます。次のURLを使用します。 https://<node>:7630

ログイン資格情報は、ha-cluster-initのインストールダイアログで提供されます。Linuxユーザーhaclusterのデフォルトのパスワードを変更することに留意してください。

cluster status hawk 1
図 12: HAWKにおけるクラスターステータス

ha-cluster-initを使用してクラスターを設定し、前述したすべてのパッケージをインストールした場合、システムは非常に便利なWebインターフェースを提供します。このグラフィカルなWebインターフェースを使用して、完全なクラスターステータスの概要の把握、管理タスクの実行、リソースおよびクラスターブートストラップパラメータの構成を行うことができます。

この強力なユーザーインターフェースの完全なドキュメントについては、製品マニュアルをお読みください。

10.2.2 SAP HANA Studio

データベース固有の管理とチェックは、SAP HANA Studioを使用して行うことができます。

hana studio landscape
図 13: SAP HANA Studio – スケールアウトシステムのランドスケープ

システムレプリケーションのパラメータまたはトポロジの変更は、クラスターリソース管理に干渉する場合があるため、細心の注意が必要です。

肯定的な例としては、元のプライマリを新しいセカンダリとして登録することが挙げられ、AUTOMATED_REGISTER=falseを設定します。

否定的な例としては、セカンダリの登録解除、プライマリでのシステムレプリケーションの無効化などの操作が挙げられます。

システムレプリケーションを変更するすべての操作について、最初にメンテナンス手順をチェックすることをお勧めします。

10.2.3 クラスターコマンドラインツール

crm_mon

概要は、crm_monを呼び出すことで得ることができます。_-rオプションを使用すると、停止しているが既に構成済みのリソースも表示されます。-1オプションを使用すると、crm_monによるステータスの出力が周期的ではなく一度だけになります。

Stack: corosync
Current DC: suse05 (version 1.1.16-4.8-77ea74d) - partition with quorum
Last updated: Mon Jun 11 16:55:04 2018
Last change: Mon Jun 11 16:53:58 2018 by root via crm_attribute on suse02

7 nodes configured
16 resources configured

Online: [ suse-mm suse01 suse02 suse03 suse04 suse05 suse06 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started suse-mm
rsc_ip_HA1_HDB00        (ocf::heartbeat:IPaddr2):       Started suse02
 Master/Slave Set: msl_SAPHanaCon_HA1_HDB00 [rsc_SAPHanaCon_HA1_HDB00]
     Masters: [ suse02 ]
     Slaves: [ suse01 suse03 suse04 suse05 suse06 ]
     Stopped: [ suse-mm ]
 Clone Set: cln_SAPHanaTop_HA1_HDB00 [rsc_SAPHanaTop_HA1_HDB00]
     Started: [ suse01 suse02 suse03 suse04 suse05 suse06 ]
     Stopped: [ suse-mm ]

詳しくはマニュアルページcrm_mon(8)をご参照ください。

SAPHanaSR-showAttr

SAPHanaControllerおよびSAPHanaTopologyリソースエージェント内部値の一部を表示するために、プログラムSAPHanaSR-showAttrを呼び出すことができます。内部値、保管場所、およびそれらのパラメータ名は、次のバージョンで変更になる場合があります。SAPHanaSR-showAttrコマンドは、常に正しい保管場所から値を取得します。

重要
重要

crm_attributeなどのクラスターコマンドを使用して、クラスターから直接値を取得しないでください。そうした場合、属性を別の保管場所またはクラスターの外部に移動する必要が生じると、方式が壊れてしまいます。

最初のSAPHanaSR-showAttrはテストプログラムのみで、自動化されたシステム監視に使用しないでください。

例 27: rootユーザーとしてSAPHanaSR-showAttrをチェック
suse-mm:~ # SAPHanaSR-showAttr --sid=<SID>

このツールは、3つの領域の興味深いすべてのクラスター属性を表示します。

  • globalセクションには、CIBタイムスタンプに関する情報とシステムレプリケーションのステータスを扱う属性が含まれます。

  • siteセクションには、サイト毎の属性が含まれ、どのサイトがプライマリであるか、およびlandscapeHostConfiguration.pyスクリプトのリターンコードが表示されます。さらに、サイト毎にアクティブなマスターネームサーバーが表示されます。

  • hostsセクションには、ノードのステータス、SAP HANAデータベース内部のホストのロール、プライマリマスターネームサーバーを取得するための計算されたスコア、およびホストが属するサイト名が含まれます。

Global cib-time                 prim sec  srHook sync_state
------------------------------------------------------------
global Tue Jun 12 15:02:58 2018 WDF1 ROT1 SOK    SOK


Site lpt        lss mns    srr
-------------------------------
WDF1 1528808568 4   suse02 P
ROT1 30         4   suse01 S


Hosts   clone_state node_state roles                        score site
-----------------------------------------------------------------------
suse-mm online
suse01  DEMOTED     online     master1:master:worker:master 100 ROT1
suse02  PROMOTED    online     master1:master:worker:master 150 WDF1
suse03  DEMOTED     online     master3:slave:worker:slave   80  ROT1
suse04  DEMOTED     online     master2:slave:worker:slave   110 WDF1
suse05  DEMOTED     online     master2:slave:worker:slave   80  ROT1
suse06  DEMOTED     online     master3:slave:worker:slave   110 WDF1

マジョリティメーカーsuse-mmはSAP HANAインスタンスを実行しません。したがって、ロール属性もスコアまたはサイト値もありません。

10.2.4 SAP HANA LandscapeHostConfiguration

SAP HANAデータベースのステータスをチェックし、クラスターが反応する必要があるかどうかを調べるために、landscapeHostConfiguration.pyを使用できます。

例 28: ユーザー<sid>admとしてランドスケープステータスをチェック
HDBSettings.sh landscapeHostConfiguration.py

ランドスケープホスト構成は、1つのSAP HANAホストにつき1行ずつ表示されます。

 | Host   | Host   | ... NameServer  | NameServer  | IndexServer | IndexServer |
 |        | Active | ... Config Role | Actual Role | Config Role | Actual Role |
 | ------ | ------ | ... ----------- | ----------- | ----------- | ----------- |
 | suse01 | yes    | ... master 1    | master      | worker      | master      |
 | suse03 | yes    | ... master 2    | slave       | worker      | slave       |
 | suse05 | yes    | ... master 3    | slave       | standby     | standby     |

 overall host status: ok

SAP HAガイドラインに従って、SAPHanaリソースエージェントは次のようにリターンコードを解釈します。

表 3: リターンコードの解釈表
リターンコード説明

4

SAP HANAデータベースは稼動中で、OKステータスです。クラスターはこれを正しく稼動中のデータベースと解釈します。

3

SAP HANAデータベースは稼動中で、INFOステータスです。クラスターはこれを正しく稼動中のデータベースと解釈します。

2

SAP HANAデータベースは稼動中で、警告ステータスです。クラスターはこれを正しく稼動中のデータベースと解釈します。

1

SAP HANAデータベースは停止しています。データベースは稼動中である必要があり、意図的に停止されていない場合、テイクオーバーがトリガされる可能性があります。

0

内部スクリプトエラー – 無視されます。

13 GNU Free Documentation License

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

  15. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
 Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts". line with this:

with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.