スナップショットを使用したSAP ASE データベースの自動化された回復手順を作成する方法

SAPのクラウド移行を検討するお客様はますます増えています。お客様の多くはSAP HANAに移行していますが、SAPがAnyDBと呼んでいる非SAP HANA データベースを使用する場合もまだまだあります。これらのSAPシステムもまた重要で、確実なバックアップとリストアの戦略を実装する必要があります。

スナップショットを使用したSAP HANA データベースの自動化された回復手順を作成する方法という以前のブログでは、SAP HANAベースのSAPシステムにおいて、AWSの能力と機能を実際に使用したクラウドネイティブなアプローチを紹介しました。

このブログ記事では、SAP ASE (以前のSybase ASE)とAmazon EBS スナップショットおよび自動化された回復手順を組み合わせることで、以前のブログで紹介したソリューションを拡張します。これにより、AWS上で稼働するSAPデータベースとして、同じバックアップ統合とポリシーに準拠することができます。

SAP ASEをサードパーティー製バックアップソリューションでバックアップするための十分な理由がまだあります (例えば、複数のDBを対象とした単一バックアップツールの必要性)。しかしながら、私たちは、Amazon Elastic Block Store (EBS) スナップショット、Amazon EBS 高速スナップショット復元、Amazon EC2 インスタンス上の複数のAmazon EBS間でクラッシュ整合性のあるスナップショットを取得など、クラウドネイティブな機能を使用する別のアプローチに焦点を当てます。これらの機能を使用することで、ネイティブなバックアップ/リストア機能と自動化プロセスを備えたインフラストラクチャーを実装できます。

高速かつ自動化されたリストアプロセスは、クラウド環境で新しい特性を提供するでしょう。例えば、自動化されたリストアプロセスでは、スタンバイインスタンスをパイロットアプローチで実装したか、ホットスタンバイで実装したかに関わらず、スタンバイインスタンスのコストを削減できます。さらに、サードパーティー製ソフトウェアにかかる追加のライセンス費用が不要です。

ソリューションの概要

紹介するアーキテクチャは、Amazon EBS スナップショットに基づいています。スナップショットは、データベースサイズに関係なく、高速で、コスト効果の高いバックアッププロセスを提供します。スナップショットは、自動的にAmazon Simple Storage Service (S3)に保存され、どのアベイラビリティゾーンからでもアクセス可能です。加えて、Amazon EBS スナップショットは、デフォルトで増分的です。最新のスナップショット以降の差分変更のみを保存します。Amazon EBS 高速スナップショット復元は、作成時に完全に初期化されたスナップショットからボリュームを作成します。これにより、ブロックに初めてアクセスしたときのI/O操作の待ち時間がなくなります。高速スナップショット復元を使用して作成したボリュームは、プロビジョニングされた性能をすべて即座に提供します。復元力のある高可用性アーキテクチャを実装するには、自動化が重要です。何かが失敗したときに備えて、データベースを回復するためのすべての手順を自動化する必要があります。

次の図は、ハイレベルなアーキテクチャを示しています。

Amazon EBS スナップショットとSAP ASE データベースの統合を構成

まず初めに、SAP ASE 16 SP03 PL08 データベースを使用する分散構成のSAP NetWeaverをインストールし、次の変更を行いました。

Amazon Elastic File System (Amazon EFS)で準備したNFS共有 /backup-efs を使用し、その領域をSAP ASEのトランザクションログバックアップ用に構成しました。
データベースとトランザクションのダンプを設定するために、SAP ASEの構成を調整する必要があります。バックアップはAmazon EFSに直接書き込まれ、アベイラビリティゾーン間で複製されます。バックアップ、特にログバックアップは安全に保存され、アベイラビリティゾーンに影響を与える事象が発生した場合でも引き続き利用可能です。
さらに、Amazon EFS 低頻度アクセス (EFS IA)のオプションを有効にします。これにより、90日以内にアクセスがなかったデータを自動的にEFS IA ストレージクラスに保存します。最近のAmazon EFS 低頻度アクセスの料金の引き下げにあるよう、Amazon EFS 標準と比較して最大92%のコスト削減ができます。

ログバックアップは、Amazon EFSの /backup-efs ファイルシステムに自動的に書き込まれます。デフォルトではSAP ASEのログはトリガーされないため、設定する必要があります。今回は、DBAコクピットのDBA計画カレンダーを使い、15分毎のスケジュールを設定しました。この値を小さくすることで、目標復旧時点 (RPO)をさらに短くすることもできます。

加えて、SAPは、ログセグメントがしきい値 (fill level)に到達するたびにDUMP TRANSACTION コマンドを実行するしきい値アクションを設定することを推奨しています。SAP Note 1801984 – SYB: Automated management of long running transactionsに、ログセグメントのしきい値アクションを設定するために必要な手順が説明されています。

ログファイルが利用可能で、複数のアベイラビリティゾーンにまたがって安全に保存されるようになったので、データベースの完全バックアップを構成できます。

SAP ASE スナップショットスクリプト

スクリプト “aws-sap-ase-snapshot.sh” では、次のコマンドを実装しています。次のコード例では、最も重要なコマンドを説明します。

1. SAP ASE prepare database コマンドを使用して、データベースのデバイスファイルの一貫したAmazon EBS スナップショットを取得し、一貫した外部のDBコピーを作成します。このような外部コピーは、整合性があり、データベースを整合性のある状態で回復するために使用できます (SAP Note 1887068 – SYB: Using external backup and restore with SAP ASEを参照)。これにより、トランザクションログのダンプをAmazon EBS スナップショットからデータベースにリストアし、Amazon EFS ファイルシステムのトランザクションログの格納先から回復できます。

prepare database all_tag hold master, model, $ASE_SERVER, saptools, sybsystemdb, sybsystemprocs, sybmgmtdb for external dump with quiesce
	go

SAP ASE データベースにログインするために、sapsa ユーザーのパスワードをSAP ASE aseuserstore に保存します。

1. データベースが静止モードになっているため、リストア後にデータベースのロールフォワードが可能です。Amazon EBS ボリュームのスナップショットをトリガーするために、複数のEBSボリュームにわたってポイントインタイムでクラッシュ整合性のあるスナップショットを作成する機能を使用します。この機能の利点は、複数のボリュームの同期をとるために、ボリュームレベルでの手動の入出力 (I/O)のフリーズが不要なことです。次のコードスニペットが、Amazon EBS ボリュームのスナップショットの実行で使用されます。

aws ec2 create-snapshots --region $region --instance-specification InstanceId=$instance_id,ExcludeBootVolume=true --description $snapshot_description --tag-specifications "ResourceType=snapshot,Tags=[{Key=Createdby,Value=AWS-ASE-Snapshot_of_${HOSTNAME}}]" | jq -r ".Snapshots[] | .SnapshotId"

1. Amazon EBS 高速スナップショット復元 (FSR)を有効にしましょう。Amazon EBS FSRをどのアベイラビリティゾーンで有効にするかを定義するパラメーターにより、新規のボリュームを作成するときの初期化の時間を削減します。パラメーターが空の場合、Amazon EBS FSRは無効になります。

# Requirements in which zone(s) the the fast snapshot restore separated by spaces not comma! If empty Amazon EBS FSR will be disabled
	azs="us-east-1a us-east-1b"

aws ec2 enable-fast-snapshot-restores --region $region --availability-zones ${azs} --source-snapshot-ids ${recent_snapshot_list_new[$i]} --output table

デフォルトでは、ダンプの履歴機能を使用できないため、データベースのダンプ履歴ファイルには登録がありません。バックアップ履歴の登録はオプションであり、データベースはスナップショットのリストア後にログの回復プロセスを処理できます。

これで、Amazon EBS スナップショットとAmazon EFSに書き込まれたログバックアップを使用した完全バックアップのバックアッププロセスが完成しました。どちらのストレージロケーションもアベイラビリティゾーンから独立しており、別のアベイラビリティゾーンからアクセスできます。そのため、例えばAWS Auto Scaling グループを使用して、後から別のアベイラビリティゾーンでデータベース全体を再作成できます。

SAP ASE リストアスクリプト

リストアスクリプトとリストアプロセスの各手順を詳しく見ていきましょう。

前提条件として、AWSパラメーターストアの中にパラメーターが必要です。AWSパラメーターストアは、SAP ASE ボリュームのボリュームIDを記録します。

SAP ASEのスナップショットスクリプトの前提条件を考慮することが重要です。特に、コマンドラインオプション ‘-q’ を使用してSAP ASEを静止モードで起動し、データベースの静止後に保存されたトランザクションログのダンプを適用します。

1. コマンドラインインターフェースでパラメーターを作成するには、次のコマンドを使用します。

aws ssm put-parameter --name <name-for-sapdata> --type StringList --value vol-1,vol-2,vol-3, …, vol-n

aws ssm put-parameter --name <name-for-log> --type StringList --value vol-1,vol-2,vol-3, …, vol-n

この手順は、AWSパラメーターストアにパラメーターを作成するために設定中に1度だけ必要です。この値は、後でスクリプトによって自動的に更新されます。

1. 最新のスナップショットから新しいボリュームを作成するために、このスクリプトはスナップショットスクリプトとsnapshot-idによって作成された最新のスナップショットを探します。

aws ec2 describe-snapshots --region $REGION --filters Name=volume-id,Values=${DATAVOLID[$i]} Name=status,Values=completed Name=tag:CreatedBy,Values= AWS-ASE-Snapshot_of_${HOSTNAME} | jq -r ".Snapshots[] | .StartTime" | sort -r | awk 'NR ==1'

aws ec2 describe-snapshots --region $REGION --filters Name=start-time,Values=${LATESTSNAPDATEDATA[$i]} Name=volume-id,Values=${DATAVOLID[$i]} | jq -r ".Snapshots[] | .SnapshotId"

リストアプロセスでは、回復するログファイルの数を減らすために最新のスナップショットを使用します。AMIはSAP ASE ボリュームなしで作成されており、これらのボリュームはAmazon EBS スナップショットから作成する必要があります。

1. スナップショットから新しいボリュームを作成する必要があります。

aws ec2 create-volume --region $REGION --availability-zone $AZ --snapshot-id ${SNAPIDDATA[$i]} --volume-type gp2 --output=text --query VolumeId

インスタンスにアタッチする前に、手順を待機させて、ボリュームが利用可能になるまで待つことをお勧めします。これは、新しく作成されたAmazon EBS ボリューム毎の有効性を確認するリストアスクリプトの中で実装されています。

1. ボリュームをインスタンスにアタッチします。

aws ec2 attach-volume --volume-id ${NEWVOLDATA[$i]} --instance-id $INSTANCEID --device ${DATADEVICEINFO[$i]}

これでデータベースを開始した場合、スナップショットが作成された時間に基づいて、クラッシュ整合性のある状態になります。データベースを最新の状態に回復するために、Amazon EFSに保存されているログファイルを使用できます。AMIは、起動時にAmazon EFS ファイルシステムを自動的にマウントします。

/etc/fstab
[…]
# EFS
<efs-fs-id>:/backup-efs    /backup-efs            efs    _netdev,tls 0 0

1. 逆引きおよび正引きのDNSルックアップ用にAmazon Route 53のDNSエントリーを更新します。SAP ASEのデータベースホスト用の仮想IPと仮想ホスト名を持つアダプティブコンピューティングを使用しました。

aws route53 change-resource-record-sets --hosted-zone-id $DNS_ZONE_ID --cli-input-json "$INPUT_JSON_A" --region ${REGION}

1. SAP ASEを最新の状態に回復するには、最後のAmazon EBS スナップショットのタイプスタンプよりも新しい各トランザクションログを繰り返し処理し、ポイントインタイムリカバリーを実行するためにログを静止モードでデータベースに1つずつ適用する必要があります。

sudo -u $SYBADM -i isql -k${SYBKEYNAME} -w 1024 -X -e -b --retserverror -o apply_log &lt;&lt; EOSQL
set nocount on
go
load transaction ${ASE_SERVER} from '${f}''
go
EOSQL

リストア時間は、2つの主要な要素に依存します。1) スナップショットから新しいボリュームを作成する時間、2) 回復するログファイルの数です。EBSスナップショットから作成されるときのボリュームの初期化は、ボリュームサイズとボリュームタイプによって異なります。Amazon EBS 高速スナップショット復元を使用することで、EBSスナップショットから作成されるボリュームを初期化するための時間を短縮することができます。データベースの回復プロセスは、スナップショットが作成されてからのログファイルの数とデータベースの変更率によって異なります。

追加で考慮すべき事項

追加の実装は、別のアベイラビリティゾーンで新しいインスタンスを起動できるAWS Auto Scaling グループにより、Amazon EC2 インスタンスのフェイルオーバーに使用することです。この構成では、アプリケーションサーバーが元のアベイラビリティゾーンに留まり、アベイラビリティゾーンをまたがったレイテンシーが少し大きい通信が発生する可能性があります。

推奨事項: ソフトウェアインストールディレクトリー $SYBASE のファイルシステムバックアップを同時に実行します。重要なファイルは、SAP ASEの構成ファイル <DBSID>.cfg、インターフェースファイル、ダンプ履歴ファイルです。

結論

現在、多くのSAPシステムがSAP HANAをデータベースとして稼働していますが、一部のシステムは引き続きSAP ASEなどのAnyDBを使用しており、これらの製品を使用しているお客様は効果的なバックアップおよびリストアプロセスを必要としています。

このブログでは、データベースの高速バックアップを作成し、複数のアベイラビリティゾーンにまたがって保存するために、EBSスナップショットとの統合を実際に行いました。このソリューションを実装するには、GitHub リポジトリ aws-ebs-snapshot-sap-ase を参照してサンプルコードを入手してください。

高可用性のために、SAP ASE Replication Serverを使用して、プライマリーデータベースの同期レプリケーションを操作し、目標復旧時点 (RPO)を削減できます。

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

Amazon Web Services ブログ