Amazon FSx for NetApp ONTAP クローニングによる開発リフレッシュサイクルの加速とコストの最適化

本記事は 2023 年 5 月 22 日に Naim Mucaj (Senior Solutions Architect) 、Ramam Kallakuri (Solutions Architect)、Saadelden Abdelkreem (Solutions Architect) によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

企業は本番環境と同様の最新データセットのコピー上で開発、テスト、QA をするため、データベース環境のリフレッシュを実行します。さらに、IT チームは可用性、回復性、パフォーマンスの高いレベルを維持しながら、増大するデータフットプリントを管理することが課題となっています。多くの顧客の開発サイクルは、DTAP （開発 (Development)、テスト (Test)、受け入れ (Acceptance)、本番 (Production)）のデータ環境を保持しており、これらすべてにインフラとリソースが必要です。より多くのバージョンとリフレッシュが必要になるにつれ、より多くのストレージが必要になります。

Amazon Elastic Compute Cloud (Amazon EC2) と Amazon FSx for NetApp ONTAP (FSx for ONTAP) を使用することで、数秒で大規模なデータベースをクローンできます。追加のストレージ容量を消費することなく、リフレッシュ時間を短縮し、テスト環境全体のリソース消費を削減できます。データベース環境（本番環境から開発環境へ）のリフレッシュを高速化するために、FSx for ONTAP の 3 つの主要なデータ管理機能であるスナップショット、 Flexclone、 SnapMirror レプリケーションを利用できます。

この記事では、FSx for ONTAP とそのネイティブ機能を使用して、本番環境から開発環境にデータベース環境をリフレッシュするプロセスを説明します。FSx for ONTAP を使用することで、複数の環境間でデータベースとアプリケーションのデータセットのスナップショットを取得し、クローンを分けることで、運用の複雑さを軽減し、アジリティを向上させ、コストを削減することができます。この記事では、Oracle Database Server 19c を使用したエンドツーエンドの更新プロセスを紹介します。

ソリューション概要

この例では、Amazon EC2 上で稼働する Oracle データベースサーバーと FSx for ONTAP を利用して、データ環境のリフレッシュを高速化し、データベース / アプリケーションのデータセットのコスト最適化されたデータレイヤーを提供する方法を紹介します。同じ考え方が、MySQL、PostgreSQL、MariaDB、Oracle、SAP HANA などの他のデータベースや、複数のデータセットが必要なアプリケーションにも適用できます。

FSx for ONTAP は、ONTAP の一般的なデータアクセスと管理機能とともに、AWS クラウドでフルマネージドな共有ストレージを提供しています。

FSx for ONTAP のスナップショット、FlexClone、SnapMirror の機能を組み合わせることで、迅速かつコスト効率よく環境のリフレッシュを実行できます。たとえば、データベースワークロードを実行していて、本番環境のデータベースに対して操作を実行する前にテストしたい場合は、データベースのクローンを作成し、さまざまなテスト環境で利用可能にすることで操作をテストできます。

Oracle データベースのデプロイにおいて、Amazon FSx ファイルシステムを利用する方法はいくつかあります。今回のシナリオでは、NFS 共有をデータ、ログ、および Oracle のホームドライブとして、Amazon EC2 上で動作する Oracle Database 19c インスタンスにマッピングします。

これらの NFS 共有で表示されるドライブは、データセットの対象となり、スナップショット、ミラー、クローン、および開発環境の Oracle データベースサーバーへ連携のプロセスのベースとなります。このアーキテクチャには、本番用 FSx for ONTAP ファイルシステムと開発用 FSx for ONTAP ファイルシステムが含まれます。本番用環境と開発環境の隔離を想定していますが、同じファイルシステム上で同じプロセスを実行できます（別のファイルシステムに SnapMirror する必要はありません）。

FSx for ONTAP file system replicated to secondary FSx for ONTAP file system

図 1: FSx for ONTAP ファイルシステムがセカンダリ FSx for ONTAP ファイルシステムにレプリケートされている様子

前提条件

この記事では、Oracle データベース、NFS 共有の Linux マウントを理解し、 FSx for ONTAP の基本的な知識を持っていることを前提としています。同様の環境をお客様環境で作成するには、次の前提条件を満たす必要があります。

Amazon EC2 と FSx for ONTAP を利用できる AWS アカウント
Oracle データベース（または他のデータベースアプリケーション）がインストールされ、図のようにデータとログのボリュームが表示された EC2 インスタンス
クラスタがピアリングされ、 Oracle ボリューム用に SnapMirror が設定された FSx for ONTAP (シングルもしくは複数アベイラビリティーゾーン (AZ)) (開発環境ではミラーリングせず、本番環境のファイルシステム上にローカルでクローンを作成することもできます。)
図のように、FSx for ONTAP ボリュームを作成し、NFS 共有として Oracle データベースサーバーに表示
本番環境と開発環境の両方において、AWS Command Line Interface (AWS CLI) を使用して Oracle データベースサーバーと FSx for ONTAP ファイルシステムの両方にアクセス可能
SYSDBA としての中級レベルの Oracle スキル

ウォークスルー : 本番環境から開発環境へのデータベースのリフレッシュ

次は、前述のアーキテクチャ図にある Oracle 19c データベース環境をクローンするために必要なプロセスの詳細な手順です。このプロセスに沿って進めることで、Oracle データベースボリュームのアプリケーション整合性のあるスナップショットを取り、開発環境にレプリケートしてクローンを作成し、読み書き可能なボリュームを開発用の Oracle データベースサーバーにマウントできます。その後、必要に応じてテストや品質保証を実行できます。その後、要件に応じてテストと QA を実行できます。また、1. 削除、2. クローンを独立したデータセットに分割するオプションの手順も含まれています。

FSx for ONTAP clones created from replicated volumes and mounted to Oracle Dev Server

図 2: レプリケートされたボリュームから作成され、Oracle 開発サーバーにマウントされた FSx for ONTAP クローン

この例では、データベースを開発環境にリフレッシュするプロセスを説明します。クローンされたデータベースを削除したり、独立して保守したりする後工程とともに、開発環境への完全なリフレッシュ工程をカバーします。

概要として、プロセスは次のとおりです:

Oracle データベースをバックアップモードにする。（アプリケーション整合性のあるスナップショットを確実に取得するため）
FSx for ONTAP の Oracle データベースのボリュームのスナップショットを取得する。
Oracle データベースのバックアップモードを解除する。
SnapMirror update を実行し、取得したスナップショットを同期し、開発環境の FSx for ONTAP ファイルシステムにクローン作成する。
クローンしたボリュームを開発用 Oracle サーバーにマウントする
データベースを起動し、すぐにシャットダウンする。
最後に Oralce にて操作する。開発用 Oracle データベースサーバーの設定ファイルを更新し、クローンしたデータベースを開発用サーバーにマウントして、データベースが稼働し、読み取り書き込み操作が可能であることを確認する。

実装

Oracle データベースをバックアップモードにする。（アプリケーション整合性のあるスナップショットを確実に取得するため）

SQL Plus で、データベースをバックアップモードに設定します。

SQLPLUS> ALTER DATABASE BEGIN BACKUP;

FSx for ONTAP の Oracle データベースのボリュームのスナップショットを取得する。

FSx for ONTAP ファイルシステム CLI で、データベースファイルが存在するボリュームのスナップショットを取得します。（スナップショットに適切な名前のラベルを付けます。）

FsxId01234567890abc:> vol snapshot create -vserver fsx -volume prddb_orahome -snapshot prddb_orahome_snapshot_28March2023 
FsxId01234567890abc:> vol snapshot create -vserver fsx -volume prddb_oradb -snapshot prddb_oradb_snapshot_28March2023 
FsxId01234567890abc:> vol snapshot create -vserver fsx -volume prddb_oraarch -snapshot prddb_oraarch_snapshot_28March2023

Oracle データベースのバックアップモードを解除し、データベース制御ファイルをトレースファイルにバックアップして、後で開発環境で再利用できるようにする。

SQLPLUS> ALTER DATABASE END BACKUP;
SQLPLUS> alter database backup controlfile to trace as '/home/oraebs/controfilescript.sql';

アプリケーション整合性のあるスナップショットが利用可能になったので、これらを開発環境にミラーリングすることができます。(クローニングとローカルでのマウントも可能です。)

SnapMirror update を実行し、取得したスナップショットを同期する。

開発用の FSx for ONTAP ファイルシステム CLI で SnapMirror 関係を更新し、スナップショットが転送されたことを確認します。（開発環境を使用せず、ローカルでクローンを使用する場合は、この手順を省略できます。）

FsxId01234567890abc:> snapmirror update -destination-path <SVM name>:devdb_orahome_DP -source-snapshot prddb_orahome_snapshot_28April2023 
FsxId01234567890abc:> snapmirror update -destination-path <SVM name>:devdb_oradb_DP -source-snapshot prddb_oradb_snapshot_28April2023 
FsxId01234567890abc:> snapmirror update -destination-path <SVM name>:devdb_oraarch_DP -source-snapshot prddb_oraarch_snapshot_28April2023

更新後、利用可能なスナップショットが表示されます。次のコマンドを実行し、ステップ 2 でリストしたスナップショット名を確認します。

FsxId01234567890abc:> snap list devdb_orahome_DP 
FsxId01234567890abc:> snap list devdb_oradb_DP 
FsxId01234567890abc:> snap list devdb_oraarch_DP

開発環境の FSx for ONTAP ファイルシステムのスナップショットからクローンを作成する。

開発用の FSx for ONTAP ファイルシステム CLI で、ミラーリングされたスナップショットを参照するボリュームクローンを作成します。

FsxId01234567890abc:> vol clone create -vserver fsx_dev -flexclone devdb_orahome_clone_28March2023 -type RW -parent-volume devdb_orahome_DP -parent-snapshot prddb_orahome_snapshot_28March2023 -junction-path /devdb_orahome -junction-active true 
FsxId01234567890abc:> vol clone create -vserver fsx_dev -flexclone devdb_oradb_clone_28March2023 -type RW -parent-volume devdb_oradb_DP -parent-snapshot prddb_oradb_snapshot_28March2023 -junction-path /devdb_oradb -junction-active true 
FsxId01234567890abc:> vol clone create -vserver fsx_dev -flexclone devdb_oraarch_clone_28March2023 -type RW -parent-volume devdb_oraarch_DP -parent-snapshot prddb_oraarch_snapshot_28March2023 -junction-path /devdb_oraarch -junction-active true

クローンボリュームを開発用 Oracle サーバーにマウントする。

Oracle 開発サーバーにマウントポイント用のディレクトリを作成します。（開発サーバーにすでにマウントポイントが作成されている場合は、このポイントをスキップしてください。）

# mkdir -p /devdb_orahome 
# mkdir -p /devdb_oradb 
# mkdir -p /devdb_oraarch

作成したボリュームクローンを必要なマウントポイントにマウントします。

# mount -t nfs -o nconnect=16 <SVM NFS DNS name or IP address>/devdb_orahome_clone_28March2023 /devdb_orahome 
# mount -t nfs -o nconnect=16 <SVM NFS DNS name or IP address>/devdb_oradb_clone_28March2023 /devdb_oradb 
# mount -t nfs -o nconnect=16 <SVM NFS DNS name or IP address>/devdb_oraarch_clone_28March2023 /devdb_oraarch

データベースを起動し、すぐにシャットダウンする。

SQLPLUS> startup; 
SQLPLUS> shut immediate;

開発用 Oracle データベースサーバーの設定ファイルを更新する。

開発用 Oracle データベースサーバー上で、前述の手順でバックアップしたコントロールファイルトレース SQL スクリプト（controlfilescript.sql）を更新します。

# vi controlfilescript.sql

新しい DB 名、ログファイルディレクトリ、データファイルディレクトリの場所に合わせて、ファイルの内容を更新してください。

クローンしたデータベースを開発用サーバーにマウントします。SQL Plus でコントロールファイルの SQL スクリプトを使用してデータベースをマウントし、データベースログをリセットします。

SQLPLUS> @controlfilescript.sql; 
SQLPLUS> ALTER DATABASE OPEN RESETLOGS;

Oracle で、データベースが操作可能であることを検証します。

SQLPLUS> SELECT STATUS FROM V$INSTANCE; 
SQLPLUS> SELECT NAME FROM V$DATABASE;

上記のプロセスが完了すると、本番環境のデータベースが開発環境にリフレッシュされました。これにより、データベースの読み書きテストが可能になります。このプロセスは高速かつ効率的で、追加のストレージを必要とせず、変更されたブロックのストレージのみを消費します。

次のコマンドを使用してボリュームクローンの使用状況を検証し、最後の列に表示されるボリュームの物理ストレージの使用量の割合を確認してください。

FsxId01234567890abc:> vol show -vserver <vserver name> -volume <volume clone name> -fields size,used,available,percent-used,physical-used,physical-used-percent

DB のクリーンアップまたは新しいコピーのメンテナンス手順

ここまでの手順で、ボリュームクローンと開発用データベースは、テスト、QA、その他の処理のために、読み取り書き込み状態になりました。このプロセスが完了したら、今度はテストデータセットを削除するか、独立したデータセットに分割するかを決定する必要があります。

次では、クローンデータベースの削除もしくは分割の手順を説明します。

開発データベースの削除

データベースのマウントを解除し、クローンを削除します。

Oracle でデータベースのマウントを解除し、Oracle 開発サーバーから NFS マウントポイントのマウントを解除します。
次のコマンドを使用して、開発用 FSx for ONTAP ファイルシステムからボリュームクローンをオフラインにして削除します。

FsxId01234567890abc:> volume offline -vserver <vserver name> -volume <volume clone name> 
FsxId01234567890abc:> volume delete -vserver <vserver name> -volume <volume clone name>

開発データベースのメンテナンス

クローンを分割し、通常の開発作業を継続します。

このプロセスは、現在の FSx for ONTAP ファイルシステム上に独立したボリュームセットを構築し、データセットの全ストレージ使用量を消費します。

ボリュームのクローンを独立したボリュームに分割する。

FsxId01234567890abc:> volume clone split start -vserver <vserver name> -volume <volume clone name>

2. (オプション）ボリュームは元のクローン名を保持しているので、適切なボリューム名に変更する。

FsxId01234567890abc:> volume rename -vserver <vserver name> -volume <volume> -newname <new name of volume>

まとめ

この記事では、FSx for ONTAP のスナップショット、FlexClone、SnapMirror の機能や特徴を使用して、データベース環境を本番環境から開発環境にリフレッシュするプロセスを説明しました。これらの機能を活用することで、効率的かつ迅速にリフレッシュを実行しながら、ストレージ消費を最適化できます。これにより、開発、テスト、QA を、本番環境と同様の最新データセットのコピーで実行できることが確認できます。

この記事では、Oracle 19c データベースのリフレッシュの例として取り上げましたが、同じデータリフレッシュの原則を他のデータベース（SAP HANA、MySQL、PostGres、Microsoft SQL など）や、同じデータセットの複数の読み取り/書き込みコピーを管理することで得られるメリットをアプリケーションにも適用できます。

FSx for ONTAP の詳細については、製品ページをご覧ください。 AWS での Oracle の詳細については、AWS の Oracle FAQ ページをご覧ください。

Amazon Web Services ブログ