SAP HANA Snapshot Backup & Recovery on AWSを試してみた

2020.07.15

この記事を書いたメンバー：

Hiroko

はじめに

・目的
企業におけるデータのバックアップ／リカバリーは、事業継続性の点からも重要な要素です。
特に基幹システムは、企業の要のデータを扱っています。SAP ERP 6.0までは、MS SQL Server, Oracle, DB2といった様々なデータベースにも対応しておりましたが、SAP S/4HANAからは、対応データベースはSAP HANA Databaseだけとなります。
また、既存システムにおけるデータ容量も、日々増大しており、バックアップに要する時間短縮は、常に課題にあげられます。
・方法
Snapshot Backupという、取得時のバックアップデータの「青写真」をとることで、その瞬間のデータの取得が容易となり、また開いているファイルに対しても取得できることから、「○月×日△時□分のもの」という形である種の一貫性を保つことができます。
そのSnapshot Backupが、AWS上でも使えるようになったということで、動作検証しました。
・期待される効果
システムを止めることなく静止点データのバックアップが取得できること、従来型バックアップより取得時間が短いこと、AWS Snapshotによる、バックアップデータの多重化の自動化などから、バックアップ方法の選択肢を増やすこと、全体的な運用管理や自動化の見直しの選択肢が増えることなどが期待できます。

テスト環境
 前提条件
 準備
 バックアップ
 リストア
この度、AWSから、スナップショットを使用したSAP HANA データベースの自動化された回復手順を作成する方法というBlog記事が提供されたことから、この技術を利用して、SAP HANA Snapshot Backupを、Auto Scaling機能を利用しないで活用することができないかどうかを検証してみました。
（英語原文）

HANA Snapshot Backup Image

テスト環境

・SLES for SAP Application
・SAP HANA 2.0 SPS4.0 Rev.47

前提条件（AWSのBlogや、関連するスクリプトのGitHubページより）

1．対応しているOS環境であること
2．SAP HANAが対応しているバージョン、パッチレベル以上であること
3．SAP HANA Data Volumeは、LVMであること
4．SAP HANA Log Volumeは、LVMであること
5．jqパッケージが、SAP HANA Host (EC2) にインストールされていること
6．/hana/data, /hana/log のボリュームのSSMSパラメータがストアされていること
7．SYSTEM DATABASEのSYSTEMユーザのパスワードが、HANA hdbuserstoreにてストアされていること
8．HANA テナントDBの自動起動＝NOであること (‘restart=no’)
9．対象のEC2インスタンスのIAMに、SSMの実行、Snapshotの実行、Volume Attachといった、必要なロールが付与されていること
10．/etc/fstabにおいて、/hana/data, /hana/logを、該当ディスクがマウントされていない状態でも、EC2インスタンスが起動してくるように、nofailを追加すること
11．/backup_efsディレクトリを作成し、Amazon EFSファイルシステムを作成し、EFSマウントヘルパーなどを利用して、作成したファイルシステムをマウントすること
12．SAP HANAパラメータ”basepath_logbackup”, “basepath_databackup”, “basepath_catalogbackup”を、/backup_efs 以下をさすように、変更してあること
13．Amazon EFS低頻度アクセス(EFS IA)オプションを有効にすること

準備

1, 2, 3, 4に関しては、AWS Cloudformationを利用してSAP HANA Database環境を作成した場合には、あまり気にする必要がありませんが、事前にdf, aws-versionといったコマンドなどを利用して、環境の確認をしておきます。
検証中に判明したことではありますが、HANA Snapshot Backupのバックアップ容量が正しく取得できないという状態であることが分かったことから、SAP HANA Databaseのパッチレベルを検証時点での最新に上げています。
SAP Note 2795010 – Snapshot Based Data Backup Shows Size 0 in Backup Catalog
5 検証時において、SLES 15には、jqパッケージのレポジトリが、プリセット環境に含まれておりませんでしたことから、下記コマンドを実行してインストールを行っております。
インターネットに出ることができない環境の場合、何らかの工夫の上、インストールする必要があります。

# cd /usr/local/bin
# wget http://stedolan.github.io/jq/download/linux64/jq
# chmod +x jq

6 AWS SSMパラメータの適用コードのサンプルは、下記になります。

# aws ssm put-parameter --name HANADATAVOL --type StringList --value vol-1234,vol-5678,vol-9101112

# aws ssm put-parameter --name HANALOGVOL --type StringList --value vol-131415,vol-161718,vol-192021

実行前に、

aws configure

で、Default region nameだけでも設定しておく必要がある可能性があります。
今回検証したEC2インスタンスサイズ (R5.2xlarge) では、/hana/data のLVMは、
/dev/sdb
/dev/sdc
/dev/sdd
を使用していたことから、それをもとに、EC2インスタンスのディスク情報より実際のEBS ID情報を取得して置換しています。
/hana/logのLVMは、
/dev/sdh
/dev/sdi
を使用していたことから、同様にEBS ID情報を取得して置換しています。
7 SYSTEM DATABASEのSYSTEMパスワードがhdbuserstoreで設定する作業は、サンプルスクリプトコード内容を参考に、SYSTEMで作成しています。

 hdbuserstore -i set SYSTEM <hostname>:3NN13@SYSTEMDB SYSTEM <Password>

8 HANAテナントDBの自動起動の無効化は、下記SQL文にて設定可能です。

 ALTER DATABASE <Tenant-SID> NO RESTART;

9 EC2インスタンスのIAMには、各自の環境において、必要十分な権限を付与してください。必要十分な権限が付与されていない場合、スクリプトそのものがエラーを起こして実行することができません。
10 /etc/fstabに記載されているディスクが、マウントされていない状態でも、OS （EC2インスタンス）が正常に起動できるように、nofailオプションを追加します。詳しくは、fstab記述方法を確認ください。
11 EFSディスクは、Cloudformationを使って環境を作成作成した際にも、自動で作成されますが、AZごとに異なる名前でEFSを作成してしまいます。EFSの複数AZまたがった環境で作成したい場合は、設計デザインに基づいて、別途作成することをお勧めします。また、/etc/fstabには、自動では記述されませんので、手動で記述を追記します。VPCデザインによっては、EFSマウントヘルパーが使えない場合がありますので、そのあたりのセキュリティも考慮の上、環境構築をお願いいたします。
12 global.iniに格納されている各値を変更します。
SAP標準では、それぞれ
/hana/backup/data
/hana/backup/log
/hana/backup/log
であり、Cloudformationで作成した環境のそれぞれは、
/backup/data
/backup/log
/backup/log
となりますが、どのEC2インスタンスでも同一のBackup Catalogを見るように設定したいため、
/backup_efs/data
/backup_efs/log
/backup_efs/log
となるように設定を行います（HANA Cockpit, HANA Studioなどで変更してください）。
13 Amazon EFS低頻度アクセスの設定は、EFSディスクデータの保存期間とかかわってきます。ライフサイクル設計と合わせて期間の設定を行ってください（あとから変更可能です）。
以上の設定が済んだ状態で、初めてHANA Databaseを、スナップショットバックアップする準備ができたこととなります。

バックアップ

さて、バックアップスクリプトを手動にて実行してみます。
任意のディレクトリに、

 aws-sap-hana-snapshot.sh

を設置します。
リストアスクリプトを見ると、/hana/以下に記述するのが良いように見えますが、外部ツールを利用してコールするなどがあると思います。最適な場所に設置してください。
初回実行の際は、

#!/bin/bash
set -ue
#set -x

の箇所を、下記のように変更すると、画面上にログが流れるので、実際のスクリプトの動作が確認できます。

#!/bin/bash
set -ue
set -x

実際の実行は、スクリプト内の

# Function: Create Snapshot in HANA backup catalog.
hana_create_snap() {
sudo -u $sidadm -i hdbsql -U $HDBUSERSTORE "BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'Snapshot created by AWS Instance Snapshot';"
#get snapshot ID
SnapshotID=$(sudo -u $sidadm -i hdbsql -U $HDBUSERSTORE "SELECT Backup_ID FROM M_BACKUP_CATALOG WHERE ENTRY_TYPE_NAME = 'data snapshot' ORDER BY SYS_START_TIME DESC LIMIT 1;" | awk 'FNR==2')

log "INFO: HANA prepared for Snapshot -- HANA Snapshot-ID: " $SnapshotID
}

# Function: Confirm Snapshot in HANA backup catalog.
hana_confirm_snap() {
sudo -u $sidadm -i hdbsql -U $HDBUSERSTORE "BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID $SnapshotID SUCCESSFUL 'AWS-Snapshot';"
log "INFO: Confirmation of Snapshot in HANA BACKUP_CATALOG"
}

の部分となります。
直前に、テナントDBのステータスを取得しています。オンラインであることが実行の条件のようです。
Snapshot Backupを取得し、その情報を、HANA Backup Catalogに記載するまでがセットで動作しています。
取得成功の可否は、HANA Backup Catalog (HANA Studio) からも確認できました。
スクリプト上は、正常終了したように見えても、実際のスナップショットバックアップは終了していません。状態は、
EC2ダッシュボード-> ELASTIC BLOCK STORE -> スナップショット
にて確認ください。Backupをしても、そのデータをリストアすることができなければ、環境の運用保守が正しくできるとは言えません。

リストア

次に、リストアをする方法となります。
簡単に言うと、/hana/data, /hana/logのLVM構成されているディスクを入れ替え、その後任意の時点までのログ適用となります。

HANA Snapthot Restore
1．取得してある最新のAMIより、EC2インスタンスを作成します。その際、/hana/data, /hana/log のボリュームディスクは作成しません
2．作成後にEC2インスタンスが起動してしまっている場合、EC2インスタンスのシャットダウンをします（この時、HANA DBのプロセスは動いていません）
4．Snapshotより、/hana/data, /hana/logのディスクを作成します
5.　作成したディスクを、EC2にアタッチします
6.　EC2インスタンスを起動します
7．/hana/data, /hana/logディレクトリ以下のデータの有無を確認します。（マウントできているかどうかの確認）
8．/etc/hostsのエントリを確認します（特に動的IPアドレスを利用している場合）
9．HANAのLogを手動で任意の時点（今回は、最新まで）適用します
10．HANA DBの起動状態を確認します。
11．テナントDBを起動します

1 EC2インスタンスを、AMIから新規に作成している様子です。
この際、/hana/data, /hana/logのボリュームディスクを構成している物理ディスクを作成しない形で、EC2インスタンスを作成します。

/etc/fstab に記述したnofailオプションが、正しく動いていれば、EC2インスタンスは正常に起動してきます。ただし、HANA DBのプロセスは一つも動いていません。
EC2インスタンスが停止している際にボリュームディスクをマウントするほうが、適切に作業を行うことができることから、あえてEC2インスタンスは停止させて、Snapshotから作成したディスクをアタッチさせる方法で検証しました。
7 ディスクマウント後、EC2インスタンスを起動し、/hana/data, /hana/log以下にデータがあることを確認します。また、/backup_efsへのアクセスができていることも確認します。
8 必要に応じて、/etc/hosts 内の、記述の修正を行います。（特にIPアドレスを動的割り当ての場合は、確認が必要です）
9 テナントDBへ、最新時点までのログを適用します。
該当SQL文は、aws-sap-hana-snapshot.shより抽出し、環境に応じて変更しました。
(run as root)

sudo -u hdbadm -i hdbsql -U SYSTEM "RECOVER DATABASE FOR HDB UNTIL TIMESTAMP '2099-01-01 12:00:00' CLEAR LOG USING CATALOG PATH ('/backup_efs/log/HDB/DB_HDB') USING SNAPSHOT;"

今回は、AMIバックアップ取得後かつSnapshot取得後に作成したユーザが、存在することを確認できたことから、最新の状態までのログが適用できていることと判断しました。

また、aws-sap-hana-snapshot.shのパラメータの変更が必要な部分を加工した上で、aws-sap-hana-snapshot.shを実行することで、aws-sap-hana-snapshot.sh が動作し、Snapshot取得が実行されるシナリオも確認しております。
Snapshot Backupは、通常のHANA Backupより取得にかかる時間も少なく、その後S3へバックアップを取るといったランニングコストと、Snapshot BackupのライフサイクとEFSの設定によるライフサイクルとのバランスを考慮することで、従来型の方法と、このSnashot Backup方法、backint方法、その他の方法と、採用の選択肢が広がっていきます。
Backintを利用したバックアップの検証も行っています。
合わせてご覧ください。

AWS Backint Agentを使用したSAP HANA Databaseのバックアップ

カテゴリー