nZDT と Ansible を使用してクラスタ構成の SAP HANA データベースのアップデートプロセスを自動化

このブログは、Gergely Cserdi と Akshay Parkhi が共同執筆しました。

はじめに

SAP は 2027 年までに SAP HANA 以外のデータベースに対する一般的なサポートを終了するため、近い将来、 SAP HANA は SAP システムの新規導入における唯一の選択可能なデータベースになります。特に多数の HANA インスタンスを運用しているお客様にとって、TCO を削減するためには、一貫性のある自動化された方法でデータベースのパッチを適用することが重要です。多くの場合、HANA ノード間では HANA System Replication (HSR) が有効になっています。これを Pacemaker クラスタと組み合わせると、お客様のデータベースは HA アーキテクチャを実現できます。このような方法でデータベースをクラスタ化すると、HANA データベースにパッチを適用する nZDT (ほぼゼロのダウンタイム) 方式のメリットを受けることができます。このブログでは、クラスタ化された HANA ノードに nZDT パッチを適用する方法について説明し、Red Hat Enterprise Linux (RHEL) ベースのシステムでプロセス全体を自動化する Ansible プレイブックのサンプルも紹介します。

パッチ適用処理中のほとんどの時間においては、データベースは少なくとも 1 つのノードで使用が可能な状態です。クラスタを使用しない場合のパッチ適用については、SAP ヘルプサイトにかなり詳しく記載されていますが、HANA ノードがクラスタ構成の場合に nZDT パッチを実行する方法に関する情報は限られています。

図 1: ペースメーカーを使用した 2 ノードの HANA クラスタ構成

前提条件:

稼働中の HANA HSR クラスタペア (AWS Launch Wizard を使えば、数時間で、完全に自動的に SAP HANAのクラスタ構成の構築ができます。詳細に関しては、AWS Launch Wizard ユーザガイドをご参照ください。)
HANA パッチを適用する前に、必要な OS パッチ (ある場合) が適用されていること。詳細については、以下の情報をご確認ください。
OS に関して、BYOS の場合は“Red Hat Enterprise Linux for SAP Solutions”、またはAWS Marketplace の場合は“Red Hat Enterprise Linux for SAP with High Availability and Update Services” が必要です。サポートされている OS については、OSS ノート 1631106 をご参照ください。また、Red Hat Enterprise Linux for SAP ソリューションサブスクリプションのナレッジベースを参照することもできます。
root パスワードが必要で、まつ両方のノードで同じパスワードになっていることが必要です。この点に関するサポートが必要な場合は、チームの Linux 管理者に問い合わせてください。
SYSTEMDB と TENANT のために SYSTEM ユーザパスワードが必要です。この点に関しては、チームのデータベース管理者に問い合わせてください。
使用可能な Ansible インフラストラクチャーをお持ちで、HANA ノードでプレイブックを実行するように設定されていること。
必要な HANA のパッチパッケージが S3 バケットにあるか、ファイルシステムに保存されていること。 (オートメーション処理は両方からファイル取得可能)
SAP HANA パッチソフトウェアは SAP Marketplace ソフトウェアダウンロードセンターからダウンロードします。(ダウンロードエリアにアクセスするには SAP Marketplace アカウントが必要)
パッチファイルが Amazon S3 バケットに保存される場合、Amazon EC2 には、該当のバケットにアクセスできる IAM ロールが付与されていること。

手順

nZDT メソッドで HANA クラスタノードにパッチを適用する一般的なプロセスは以下になります。この例では、ノード 1 が現在プライマリノードで、ノード 2 がセカンダリノードであると仮定します。

* 注意 : 作業順番を守ることは重要です。

クラスタノード 2 をスタンバイモードに設定
スタンバイモードを有効にすると、指定したノードはリソースをホストできなくなります。制約が許せば、そのノードで現在アクティブなリソースがあれば、別のノードに移動されます。この場合、HANA インスタンスはセカンダリ役割であり、現在使用されているクラスタノード 1 はすでにプライマリインスタンスとなっているため、リソースはクラスタノード 1 に移動されません。
クラスタをメンテナンスモードに設定
クラスタ全体をメンテナンスモードにすると、クラスタがクラスタリソースを一切管理しなくなります。HANA のパッチ適用中に HANA サービスが断続的に停止し、そうしなけれ場クラスタが動作する可能性があるため、これは不可欠です。
ノード 2 の HANA パッチ適用
セカンダリノードで HANA にパッチを適用します。このステップは、データベースのソフトウェアバージョンを更新するための中心的な部分です。

図 2: セカンダリノードの HANA パッチ適用
パッチ適用プロセス中、セカンダリノードは一定期間使用できなくなります。ただし、プライマリノードは通常どおり稼働しており、SAP アプリケーションとユーザーにサービスを提供します。
ノード 2 をスタンバイモードから解除
このステップでは、クラスタノード 2 がクラスタで再び使用可能になり、リソースを受け入れられます。
クラスタのメンテナンスモードをオフ
メンテナンスモードを無効にすると、クラスタはプライマリノードとセカンダリノードの間の HSR を自動的に再確立します。SAP はセカンダリノードをプライマリノードよりも高いパッチレベルに設定することをサポートしています。セカンダリノードはプライマリノードと同期される状態になります。
レプリケーションが再開され、正常に動作
この段階では、セカンダリノードがプライマリノードと完全に同期し、引き継ぐ準備が整うまで待つ必要があります (ステータス SOK)。
ノード 1 をスタンバイモードに設定
スタンバイモードでは、プライマリクラスタノードはリソースをホストできなくなり、プライマリ HANA の役割がノード 1 からノード 2 に引き継がれます。クラスタは現在のプライマリノードを降格させ、ノード 2 の HANA インスタンスを昇格させます。また、クラスタはオーバーレイ IP をノード 2 に移動し、ルートテーブルの更新を行います。これにより、SAP を引き継いだ後も、ユーザーは引き続き先の HANA データベースに接続できます。

図 3: テイクオーバー処理中にセカンダリノードが昇格
テイクオーバーが完了するまで待機
テイクオーバー処理には少し時間がかかります。ノード 1 にパッチを適用する前に、ノード 2 の HANA インスタンスが完全にプライマリ役割を引き継いでいることを確認する必要があります。
クラスタをメンテナンスモードに設定
クラスタがパッチ適用プロセスの妨げにならないようにするには、クラスタ全体をメンテナンスモードにする必要があります。
ノード 1 の HANA パッチ適用
この段階では、HANA DB はノード 2 でプライマリとして実行されており、SAP システムからの接続とユーザーからの接続を受け入れます。ノード 1 の HANA インスタンスにパッチを適用できるようになりました。

図 4 元のプライマリであったノード1へのパッチ適用し、現在はセカンダリノードがプライマリ役割
ノード 1 をスタンバイステータス解除
ノード 1 のパッチ適用が完了したら、スタンバイ状態から外すことで、クラスタノードとして再び有効にできます。
クラスタのメンテナンスモードをオフ
クラスタがメンテナンスモードを終了すると、クラスタノード 1 で HANA インスタンスが起動していることを確認します。現在、クラスタノード 2 の HANA インスタンスにはプライマリ役割があるため、クラスタノード 1 の HANA インスタンスはセカンダリ役割として起動され、ノード 2 からノード 1 へのレプリケーションが開始されます。

図 5: パッチを適用した HANA ノード間で HSR を再確立
クラスタリソースを消去
メンテナンス作業中に、クラスタフレームワークでエラーやアラートが発生することがあります。クラスタを最初からやり直すには、これらをクリーンアップする必要があります。

まとめると、パッチ適用プロセス中は、テイクオーバー発生時に短時間停止する場合を除いて、常に少なくとも 1 つのノードでデータベースが使用可能である必要があります。注:プライマリとセカンダリは、最後に入れ替わります。これは正常であり、データベースの動作には影響しません。都合の良いときに元のトポロジーに切り戻すことができます。

プロセス全体を自動化する Ansible プレイブックのサンプルコードは、この公開 github リポジトリにあります。

Ansible プレイブックを実行するための準備

ターゲット HANA パッチ SAR ファイルを SAP Marketplace からダウンロードし、S3 バケットまたはサーバーのファイルシステムに配置します。S3 バケットまたはディレクトリに 1 つの SAR パッチファイル以外のファイルが含まれていないことを確認してください。以下は、パッチ HANA SP05 rev64 の SAR ファイルを格納している S3 バケットの例です。

図 6: HANA SAR ファイルを格納する Amazon S3 バケット
リポジトリを Ansible コントローラーサーバーにコピー
リポジトリをコピーする 1 つの方法は、git clone コマンドを使用することです。git コマンドに関しては参考情報のセクションをご確認ください。そのためには、まず git をインストールする必要があります。Linux へのインストール方法をご覧ください。
コピーしたリポジトリのディレクトリにアクセスし、インベントリファイルを作成し、「SAP_ <SID>_hana_ha」という名前のグループを作り、そのグループに 2 つの HANA ノード IP を追加します。たとえば、HANA SID が「HDB」、HANA ノード 1 の IP が 10.20.30.40、HANA ノード 2 の IP が 10.20.30.50 の場合、インベントリファイルの内容は次のようになります。
```
[SAP_HDB_hana_ha]
10.20.30.40
10.20.30.50
```

自動化ツールHANA パッチツール hdblcm を実行するには、複数の認証情報が必要になります。セキュリティ上のベストプラクティスとして、可変ファイルやその他の方法でパスワードを簡単に開示できないようにしてください。Ansible は、機密情報の暗号化に役立つ ansible-vault ツールを提供しています。HANA パッチを適用する Ansible プレイブックソリューションでは、以下の認証情報を含む「passvault.yml」というボールトファイルが必要です。

root ユーザパスワード	変数名: ROOTPWD
<sid>adm ユーザパスワード	変数名: SIDADMPWD
SYSTEM @ テナントパスワード	変数名: SYSTEMTNTPWD
SYSTEM @ SYSTEMDB パスワード	変数名: SYSTEMDBPWD

これらの認証情報を「passvault.yml」ファイルに追加すると、変数名や暗号化された値が格納されます。
たとえば、暗号化された root パスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。

ansible-vault encrypt_string ‘theactualpassword’ --name ‘ROOTPWD’ | tee -a passvault.yml

別の例として、SYSTEM DB の SYSTEM ユーザーの暗号化されたパスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。

ansible-vault encrypt_string ‘somepassword’ --name ‘SYSTEMDBPWD’ | tee -a passvault.yml

パスワード変数を追加するときは、暗号化に同じボールトパスワードを使用してください。暗号化されたパスワードをすべて追加したら、ファイルの新しい行から始まるようにしてください。必要なパスワードをすべて追加すると、ファイルは次のようになるはずです。

[root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# cat passvault.yml
SYSTEMDBPWD: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          35643964393039616161626666353862653038373434613533313566353134376364643337666539
          6436623736323161613031663636356162633362353831620a393365646636653837636633623164
          32623365313931303939323532393265613565643965393538393737353436366330636233646330
          3265663163636366340a633734306136313839366431616562666162386633353035393764313833
          3137
SYSTEMTNTPWD: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          39613736376436396361383939313637623435326232656163353863383138633230326166666334
          3733653737646431373261313434353065646431343037370a333963643230313565653264643831
          36393332386266333438326639346539316330303331393464663539653864353834656665346264
          3134306666623765640a303733383031376131613438396436393334636166386233633966396432
          3232
ROOTPWD: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          30323033336466663837623064343631376634316534316165316438306635636562633164653266
          3331663837303932346237643165353062656165356562300a626363373134663635313962303363
          37323531633737656239356438613838343665353530313939356530616631623561623733643236
          6138653361316265650a386561366330303832346235383035346363633463663035383131623732
          3438
SIDADMPWD: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          63633035656533316432353435376433393565623066643735326165313137396633323132363730
          3562623132356439613533633536323563333738373931650a623964323966386634616466376631
          37386564666337626630333338666264666365616263366531306162636539366461386135663263
          3334373437643763380a316238373335653636323564363139376562616130396164613932633938
          3361
[root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]#

ファイルの設定が完了したら、次の手順に進みます。

プレイブックを実行

ディレクトリをコピーしたリポジトリのルートに切り替え、以下のコマンドを実行します。

ansible-playbook -i <inventoryfile> --ask-vault-pass -e "SID=<SID>" -e "MEDIASRC=<s3/fs>" -e "MEDIALOC=<locationofSARfile"  ./patch_sap_hana.yml

たとえば、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースが S3 バケット「s3://hanapatch/」にある場合は、次の構文を使用します。

ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=s3" -e "MEDIALOC=s3://hanapatch/"  ./patch_sap_hana.yml

別の例として、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースがファイルシステムから、SAR ファイルが /tmp/hanapatch/ にある場合は、次の構文を使用してください。

ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=fs" -e "MEDIALOC=/tmp/hanapatch/"  ./patch_sap_hana.yml

自動化処理は、前述で説明した順序でノードにパッチを適用します。パッチ適用処理が終了すると、ノードの役割が入れ替われることに注意してください。ノードの元のロールは後でいつでも元に切り戻すことができます。パッチが適用されたことを確認するには、Ansible ログの末尾にある各 HANA ノードの新しいパッチバージョンを確認できます。

クリーンアップ

Playbook が正常に実行されると、パスワードテンプレートファイルは自動的にクリーンアップされます。
プレイブックを実行した後も、再び必要になった場合に備えて、ソフトウェアは引き続き使用できます。不要になった場合は、アーカイブするか、単純に削除することをおすすめします。

コスト

2 つの HANA ノードのコスト以外に、自動化には Amazon EC2 インスタンス上で稼働する小さな Ansible 管理ノードが必要な場合があります。
HANA のパッチファイルを保存するために S3 バケットが必要です。一般的なパッチファイルは約 3 ～ 4 GB で、これは年間わずか数ドル (0.023$/GB /月) に相当します。

他の展開

SAP HANA HSR の概念について詳しくは、SAP 公式ヘルプドキュメントをご覧ください。
HANA HSR に関するよくある質問に対するその他の回答については、SAP Note 1999880 — FAQ: SAP HANA システムレプリケーションをご覧ください。
RHEL 上の HANA 用 SAP ペースメーカークラスタの詳細については、公式の SAP HANA on AWS ガイドをお読みください。
AWS 無料利用枠サービスを活用して、最小限のコストで SAP on AWS で Ansible を使用する方法を学ぶのに役立ちます。Amazon Linux 2 では AWS 無料利用枠を使用して EC2 インスタンスを作成できます。このインスタンスは Ansible 管理ノードを実行するのに使用できます。
Ansible モジュールとコーディング技術について詳しくは、ansible の公式ドキュメントをご覧ください。

結論

この例では、クラスタ化された HANA ノードの nZDT パッチ処理がどのようなものかを説明しました。また、プロセスを自動化する例の方法として、 Ansible プレイブックも提供しました。

図 7: nZDT HANA のパッチ適用プロセス全体の概要ステップ

AWS は HANA パッチ適用を自動化するための AWS Systems Manager ドキュメント (SSM ドキュメント) もサポートしていますが、クラスタノードはまだサポートされていないことに注意してください。
SLES ベースのシステムには、考え方は同じです。pcs コマンドをそれぞれ crm コマンドに置き換えるか、YAST モジュールを使用して処理することが可能です。

今後のアクション

AWS Launch Wizard for SAP を使用して新しい HANA クラスタ構成を構築してみましょう。まず、オンラインドキュメントをご確認ください。
無料利用枠の Amazon インスタンスに ansible をインストールし、公開リポジトリからサンプルコードのクローンを作成します。
HANA クラスタノードのロールを確認し、パッチを適用する前に HANA DB のバージョンを確認してください。
インベントリファイルと passvault.yaml ファイルを準備し、パッチ適用プレイブックを起動します。
HANA クラスタノードの役割をもう一度確認し、パッチ適用後に HANA DB のバージョンを確認します。現在、どのノードがプライマリになっているのかでしょうか？

不要なコストを避けるため、テスト後は必ずリソースをクリーンアップしてください。

リファレンス

公式 SAP ページにある SAP HANA システムレプリケーションによる SAP HANA システムのアップデート

Near Zero Downtime Upgrades のために、SAP HANA システムレプリケーションの使用

AWS Launch Wizard

YAST モジュールを使用した HANA クラスタの SLES nZDT パッチ適用

Git クローンコマンドのリファレンス

翻訳は Specialist SA トゥアンが担当しました。原文はこちらです。

Amazon Web Services ブログ