SAP HANA の高可用性テストを自動化

はじめに

ソフトウェア開発および運用業界は近代化を進めており、プロセスの標準アプローチとして DevOps を採用するケースが増えています。しかし、SAP のインストールと運用は依然として手作業で行われる傾向にあります。これを自動化されたアプローチに進化させるために、1 つ目のブログ記事で、Terraform と AWS Launch Wizard などのネイティブ AWS ツールを使用して SAP アプリケーションのインフラストラクチャをプロビジョニングする方法を示しました。続いて 2 番目のブログ記事では、AWS Systems Manager を使用した SAP ソフトウェアのインストールの自動化について説明しました。最後に、3 番目のブログ記事では、自動化について詳しく説明し、高可用性 (HA) で動作する SAP ランドスケープのフルインストールをエンドツーエンドで実行しました。

このブログ記事では、SAP ランドスケープの運用に重点を置いています。アプリケーションの耐障害性を理解し、デプロイされたアプリケーションが目標復旧時間を満たしていることを確認するには、高可用性テストが必要です。多くの組織では、監査プロセスへの準拠を維持するために、高可用性構成を時々テストする必要もあります。

このブログで詳しく説明されているソリューションは、AWS SAP プロフェッショナルサービスチームが多くのお客様と共同で行った SAP HANA ワークロードの高可用性クラスタのデプロイとテストを自動化した結果です。SAP HANA ワークロードの高可用性クラスタは、お客様が必要に応じて使用および適応できるオープンソース (以下のリンク) として提供されています。

このブログ記事では、カオスエンジニアリングと呼ばれる業界全体のプラクティスを SAP の世界に紹介しています。これにより、SAP ランドスケープの動作について確信が持てるようになり、予測可能性が高まります。また、システム停止や重大なエラーの発生後に自己修復するように構成する方法についても同様です。

カオスエンジニアリングを適用すると、問題が発生する前に潜在的な問題を特定できるため、SAP ランドスケープの回復力を向上させることができますが、当社の経験から言うと、必要な一連のテストシナリオを手動で実行するには最大で 2 か月かかることがあり、ほとんどの組織では高度なスキルを持つ専門家が必要です。このブログ記事では、これらのテストシナリオを自動化し、チームの時間を大幅に節約し、監査プロセスのコンプライアンスを維持するための出発点として使用できるサンプルコードを共有します。

一般的な手動アプローチと比較して、このソリューションが HA 構成のテストにもたらすメリットは次のとおりです。

スピード: 約 2 か月から数時間。
信頼性: 12 の HA テストシナリオ (後述) を反復可能なプロセスでカバーします。
ヒューマンエラーの削減: HA テストは繰り返し可能なプロセスになるため、ヒューマンエラーによるテストの潜在的な失敗率が減少します。
監査資産: このソリューションによって生成される最終的な HTML レポートには、監査資産に必要な共通情報がすべて含まれています。
改善資産: エラーが発生した場合、最終的な HTML レポートではテスト中に具体的に何が問題になったかが強調され、エラーの前後のシステムの全体像も示されます。その後、この問題は SAP BASIS の専門家に解析され、高可用性構成に関する修正が適用されます。

ここで紹介するソリューションには、いくつかの異なる実行方法があります。しかし、最終的には、「レポート」セクションで示した例のように、すべてが HTML レポートを生成します。

このソリューションを出発点として、必要なコードがすべて揃ったパブリック GitHub リポジトリがあります。実行方法を理解するには、「How to Run」のセクションを参照してください。このガイドを使えば、簡単なラボ環境を構築できます。このサンプルコードは、企業での HA テストの自動化に必要な労力を軽減するための出発点として使用してください。このサンプルコードは、RedHat OS (オペレーティングシステム) 上の SAP HANA 1909 で実行できるようにビルドされ、テストされています。

前提条件

このガイドを開始してこのコードを実行する前に、以下の前提条件を満たす必要があります。

Ansible をコントローラインスタンスにインストールします。コントローラインスタンスには以下のものがあります。
1. 独自のインスタンス、ラップトップ、ワークステーション
2. このソリューションの実行を自動化する CI/CD ツール
3. アンシブルタワー
コントローラインスタンスと HA テストを実行する SAP ランドスケープインスタンスとの間に SSH アクセスと接続が確立されました。
1 つの SAP ランドスケープの構成は次のとおりです。
1. HA が以前に構成された 2 つの HANA インスタンス。詳細については、Red Hat Enterprise Linux クラスターの設定に関する AWS ドキュメント「configuring Red Hat Enterprise Linux clusters for SAP on AWS」を参照してください。
2. ASCS インスタンス 1 つ
3. PAS インスタンス 1 つ
AWS CLI (コマンドラインインターフェイス) で以下の権限が設定された 1 つの AWS IAM ロール。このロールはコントローラインスタンスの AWS CLI で設定する必要があります。Ansible はテスト中にこれを使用して SAP ランドスケープとやり取りします。詳細については、AWS CLI に追加のプロファイルを設定する方法をご覧ください。
1. ec2:StartInstance で全てのインスタンスを起動する
2. ec2:RebootInstances で全てのインスタンスを再起動する
3. ec2:StopInstances の全てのインスタンスを停止する
AMI を作成し、このシナリオに関係するインスタンスから各 EBS ボリュームのスナップショットをバックアップとしてキャプチャします。

想定するする高可用性テストシナリオ

各テストシナリオの目標は、すべてのテストを一度に実行したくない場合に備えて、スタンドアロンのテストとして役立つようにすることです。そのために、テストシナリオの前後に特定のタスクを実行して、環境の設定が有効で、テストが正常に完了したことを確認しています。これらの一般的な手順は、実行順序に示されているとおりです。

実行に必要なすべての入力パラメータが通知されましたか?
ノードとコントローラーノードは接続されていますか?
どのノードがプライマリで、どのノードがセカンダリか?
最低限の高可用性構成は整っているか?
HANA に設定されているレプリケーションモードは、フェイルオーバー前とフェイルオーバー後に同じですか?
テスト開始前の ASCS エンキュー番号はいくつですか?フェイルオーバー後の番号と一致していますか?
PAS は正しいデータベースインスタンスに接続されていますか?フェイルオーバー前とフェイルオーバー後?

GitHub リポジトリにあるテストシナリオは以下の通りです。

プライマリデータベースの「HDB Stop」。
新しいプライマリデータベースで「HDB Stop」(フェイルオーバー後)。
セカンダリデータベースの「HDB Stop」。
プライマリデータベースの「PCS node standby」。
新しいプライマリデータベースの「PCS node standby」(フェイルオーバー後)。
プライマリデータベースの「kill -9 pid」。
プライマリデータベースに「echo ‘b’ > /proc/sysrq-trigger」があると、インスタンスがクラッシュします。
新しいプライマリデータベースで「echo ‘b’ > /proc/sysrq-trigger」が発生してインスタンスがクラッシュする (フェイルオーバー後)。
プライマリデータベースで「HDB kill -9」が発生しました。
新しいプライマリデータベースで「HDB kill -9」(フェイルオーバー後)。
プライマリデータベースを再起動。
新しいプライマリデータベースを再起動 (フェールオーバー後)。

レポート

図 1 — 最後のステップで障害が発生して生成された HTML レポートの例

図 1 に示されている HTML は、実行された 2 つのシナリオを示しています（さらに、実際のテストを実行する前にシステム構成を全体的にチェックする #1 と、 #6 のシステムクラッシュに必要な事後処理である #7）。そのうちの1つは成功（HDB 停止、ケース #3、#4、#5）、システムクラッシュ（#6）は、ポストアクションステップ（#7）で見つかったように）失敗しました。

コードの実行方法

シングルボタンによる代替方法:3番目のブログ記事で説明したソリューションを使用している場合は、プロジェクトをリロードし (1 — vagrant destroy、2 — git pull、3 — vagrant up)、[Credentials] ですべてのパラメータを再入力し、[SAP Hana+ASCS+PAS 3 Instances] フォルダの下にある [Run HANA HA test] としてリストされている新しいジョブを見つけて、[build now] をクリックします。図 2 は、テストが完了した後の結果を示しています。

画像 2 — Jenkins パイプラインを使用して HA テストを実行したときの最終出力

これが完了すると、次の場所に移動する HTML レポートが表示されます。

ビルド番号 (この場合は 24) をクリックし、
「Workspaces」に移動します。
リストされている最初の項目を選択します。
フォルダー Report を選択し、
「report-<current date and time>.html」を右クリックし、ローカルデスクトップに保存します。必ずローカルに保存してください。保存しないと、レポートの形式が正しくありません。

図 3 — 最終的な HTML レポートをローカルに保存する

主な手順

Linux または Mac コンピューター上のターミナルにアクセスできる環境を用意します。
AWS CLI をローカルに設定してください。
GitHub リポジトリのクローンを作成してください。
各サーバー (HANA プライマリ、HANA セカンダリ、ASCS、PAS) について、hosts.yaml ファイルの情報を更新します。
1. ansible_host
2. ansible_user
3. ansible_ssh_private_key_file

var_file.yaml を開いて、必要な情報を入力します。

#	Field	Default value	Comments
Information for HANA
1	INPUT_HANA_SID	AD0	Your HANA SID
2	INPUT_HANA_INSTANCE_NUMBER	0	Your HANA instance number
3	INPUT_SYSTEM_USER	SYSTEM	Username for the SYSTEM default user. This will be used to check if a backup is available before starting the tests
4	INPUT_SYSTEM_PASSWORD	P@ssw0rd	Password for the SYSTEM user. This will be used to check if a backup is available before starting the tests
5	INPUT_HANA_SYNC_MODE	SYNC	HANA replication mode
Information for ASCS
6	INPUT_ASCS_SID	AD0	Your ASCS SID
7	INPUT_ASCS_INSTANCE_NUMBER	0	Your ASCS instance number
Information for PAS
8	INPUT_PAS_SID	AD0	Your PAS SID
9	INPUT_PAS_INSTANCE_NUMBER	0	Your PAS instance number
10	INPUT_CHECK_R3_TRANS	TRUE	Whether to check the R3trans command on PAS after database failovers or not
Information for AWS CLI
11	INPUT_AWS_REGION	us-east-1	The region where your instances are
12	INPUT_AWS_CLI_PROFILE	default	The profile you configured for your AWS CLI on Pre requisites, item 2
13	INPUT_PRIVATE_SSH_KEY	/my/path/to/pemFile.pem	Path to the SSH key for Ansible to SSH into your instances

ファイル「how_to_run.sh」を実行してください。

これがソリューションを実行する一番の近道です。BASH に慣れている場合は、「how_to_run.sh」ファイルを見てその動作を理解し、自分のシナリオで自動化できる可能性を見つけることをお勧めします。

HANA のサイズと構成によって、この作業には多少時間がかかります。ベンチマークとして、空の SAP ランドスケープインストールで 12 のシナリオをすべて実行すると、約 45 分から 1 時間かかります。

SAP 環境が大きい場合は、「More configurations allowed」のセクションをよく読んでソリューションの実行方法をカスタマイズし、シナリオを複数の実行に分割することをお勧めします。これにより、大量のテストを実行する前に、より短い時間枠で出力を確認し、インストールで発生する可能性のあるエラーを理解できます。

最終レポートを分析

テストが完了すると、各テストの結果を含む HTML レポートが生成されます。障害が発生した場合、このレポートには修復計画を設計するための基本リソースとして必要な情報がすべて記載されています。これにより、(1) どのテストがうまくいかなかったかを理解するための情報が得られます。(2) 失敗したコマンドは具体的にどれですか ? そして (3) そのコマンドがエラーになる直前にサーバーはどのように構成されていましたか?

レポートには (上記の項目 3 を理解しやすくするため)、調査に役立つ最も一般的な SAP HANA トラブルシューティングコマンドのスナップショットがいくつか記載されています。レポートに記載されているコマンド情報の例:

crm_mon -A1
HDB proc
hdbnsutil -sr_state
hdbuserstore list
python systemReplicationStatus.py
sapcontrol (…) -function GetProcessList

図 1 に示すレポート例に従い、手順 7 で「失敗」をクリックすると、画面は手順7の「Run POST ACTIONS for Scenario CRASH_NODE_PROC_PRE:」の詳細に移動します。

図 4 — エラーが発生したステップの詳細

赤色のステップの前の青色のステップは、エラーが発生する前にシステムで実行されたアクションを示しています。これを使うと、エラーが発生する前のシステム状態を理解できます。

エラー自体は赤色で表示され、何が起きたかを示す追加情報も表示されます。図 5 は、フェイルオーバーイベントの後も PAS が古いノードに接続されたままで、新しいプライマリノードに切り替えなかったことが検出された例を示しています。

図 5 — エラーが強調表示

テストシナリオの量と順序のカスタマイズ

このソリューションは 12 のシナリオすべてを実行するように事前に構成されていますが、Ansible に慣れて実行方法を変更したい場合は、目的に合わせてシナリオの数を減らすことができます。そのためには、aws-sap-hana-ha-test/main.yaml ファイルを見つけて、実行したくないブロックにコメントを付けてください。1 番目と 2 番目のブロック (「Check Inputs」と「Check current HA installation (prep / bridge tasks)」) は必須で、常に実行する必要があります。

例えば、単純な「HDB Stop」シナリオだけを実行して解決策を知りたいとしましょう。そうすれば、66 行から最後までのすべての行にコメントできます。

ほとんどのシナリオはスタンドアロンで、さまざまな順序で実行できるため、すべてをカスタマイズできます。唯一の例外は「Crush Instance」シナリオで、その後に「Post Action」シナリオを含める必要があります。そのため、93 行目または 111 行目のクラッシュシナリオを実行している場合は、そのすぐ下のシナリオ (それぞれ 102 行目と 120 行目) にしてください。

次のステップ

始める準備はできましたか?インストール自動化リポジトリに直接アクセスして、ご使用の環境でのテストを開始してください。

テストが完了したら、特定のニーズに合わせてリポジトリをカスタマイズできます。リポジトリのフォルダには README があり、各フォルダがどのように機能してすべてをまとめ、最終的に SAP を実行させるかについての詳細な説明が記載されています。

SAP システムを DevOps モデルに移行する際に専門家によるガイダンスやプロジェクトサポートを求めている場合は、AWS プロフェッショナルサービスグローバル SAP 専門プラクティスが役に立ちます。ハウスサービスや Phillips 66 などの SAP on AWS のお客様が、SAP 変革を加速させるために当社のチームとの連携に投資するケースが増えています。私たちがどのように支援できるかについて詳しく知りたい場合は、AWS プロフェッショナルサービスチームにお問い合わせください。

何千ものお客様が AWS for SAP を選択する理由については、AWSの SAP ページをご覧ください。

SAP on AWS ディスカッションにご参加ください。

カスタマーアカウントチームと AWS サポートチャネルに加えて、re: POST — AWS コミュニティ向けの最適化された Q&A エクスペリエンスを通じて私たちとつながることができます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。

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

Amazon Web Services ブログ