TR-4988:『Oracle Database Backup、Recovery、and Clone on ANF with SnapCenter』
ネットアップ、Niyaz Mohamed、Allen Cao氏
この解決策では、NFSプロトコルを使用したプライマリデータベースストレージとしてMicrosoft Azure NetApp FilesにOracleを自動導入し、dNFSを有効にしたコンテナデータベースとしてOracleデータベースを導入する方法の概要と詳細について説明します。Azureに導入されたデータベースは、SnapCenter UIツールを使用して保護され、データベース管理が簡易化されます。
目的
NetApp SnapCenter ソフトウェアは、使いやすいエンタープライズプラットフォームで、アプリケーション、データベース、ファイルシステム全体でデータ保護をセキュアに調整、管理できます。ストレージシステムでのアクティビティの監視と規制の機能を犠牲にすることなく、これらのタスクをアプリケーション所有者にオフロードすることで、バックアップ、リストア、クローンのライフサイクル管理を簡易化します。ストレージベースのデータ管理を活用することで、パフォーマンスと可用性が向上し、テストと開発の時間が短縮されます。
TR-4987では、 "NFSを使用したAzure NetApp FilesへのOracleの導入を簡易化、自動化"AzureクラウドのAzure NetApp Files(ANF)へのOracleの自動導入のデモを行います。このドキュメントでは、非常に使いやすいSnapCenter UIツールを使用して、AzureクラウドのANFでOracleデータベースの保護と管理を行う方法を紹介します。
この解決策 は、次のユースケースに対応します。
-
SnapCenterを使用して、AzureクラウドのANFに導入されたOracleデータベースのバックアップとリカバリを実行できます。
-
データベースのSnapshotやクローンコピーを管理することで、アプリケーション開発期間を短縮し、データのライフサイクル管理を強化できます。
対象者
この解決策 は、次のユーザーを対象としています。
-
Azure NetApp Files上にOracleデータベースを導入するデータベース管理者
-
データベース解決策アーキテクト。Azure NetApp FilesでOracleワークロードのテストを実施したいと考えています。
-
Azure NetApp Files上にOracleデータベースを導入して管理したいと考えているストレージ管理者。
-
Azure NetApp Files上にOracleデータベースを構築するアプリケーション所有者。
解決策 のテストおよび検証環境
この解決策のテストと検証は、最終的な導入環境とは一致しない可能性があるラボ環境で実行しました。を参照してください 導入にあたって考慮すべき主な要因 を参照してください。
アーキテクチャ
ハードウェアおよびソフトウェアコンポーネント
* ハードウェア * |
||
Azure NetApp Files の特長 |
Azure by Microsoftで提供中のサービス |
サービスレベルがPremiumの容量プール |
DBサーバ用Azure VM |
STANDARD_B4ms-4 vCPU、16GiB |
2つのLinux仮想マシンインスタンス |
SnapCenter用Azure VM |
STANDARD_B4ms-4 vCPU、16GiB |
Windows仮想マシンインスタンス×1 |
ソフトウェア |
||
Red Hat Linux |
RHEL Linux 8.6(LVM)- x64 Gen2 |
テスト用にRedHatサブスクリプションを導入 |
Windows Serverの場合 |
2022データセンター、AE Hotpatch-x64 Gen2 |
SnapCenterサアハノホスト |
Oracle データベース |
バージョン19.18 |
パッチp34765931_190000_Linux-x86-64.zip |
Oracle OPatchの略 |
バージョン12.2.0.1.36 |
パッチp6880880_190000_Linux-x86-64.zip |
SnapCenter サーバ |
バージョン5.0 |
ワークグループの導入 |
JDKを開く |
バージョンjava-11-openjdk |
DB VMでのSnapCenterプラグインの要件 |
NFS |
バージョン 3.0 以降 |
Oracle dNFSが有効 |
Ansible |
コア2.16.2 |
Python 3.6.8 |
ラボ環境でのOracleデータベースの構成
* サーバ * |
* データベース * |
* DBストレージ* |
ORA-01 |
NTAP1(NTAP1_PDB1、NTAP1_PDB2、NTAP1_PDB3) |
/u01、/u02、/u03 ANF容量プールへのNFSマウント |
ORA-02 |
NTAP2(NTAP2_PDB1、NTAP2_PDB2、NTAP2_PDB3) |
/u01、/u02、/u03 ANF容量プールへのNFSマウント |
導入にあたって考慮すべき主な要因
-
* SnapCenterの導入。* SnapCenterは、Windowsドメインまたはワークグループ環境に導入できます。ドメインベースの展開の場合、ドメインユーザーアカウントはドメイン管理者アカウントであるか、ドメインユーザーがSnapCenterホスティングサーバー上のローカル管理者のグループに属している必要があります。
-
名前解決。 SnapCenterサーバーは、管理対象の各ターゲットデータベースサーバーホストのIPアドレスに名前を解決する必要があります。各ターゲット・データベース・サーバ・ホストは、SnapCenterサーバ名をIPアドレスに解決する必要があります。DNSサーバを使用できない場合は、ローカルホストファイルに名前を追加して解決します。
-
リソースグループの設定。 SnapCenterのリソースグループは、一緒にバックアップできる同様のリソースを論理的にグループ化したものです。これにより、大規模なデータベース環境でのバックアップジョブの数が削減され、簡易化されます。
-
*フルデータベースバックアップとアーカイブログバックアップを別 々 に実行します。*フルデータベースバックアップには、データボリュームとログボリュームの整合グループSnapshotが含まれます。フルデータベースSnapshotを頻繁に作成すると、ストレージ消費量は増加しますが、RTOは向上します。もう1つの方法は、フルデータベーススナップショットの頻度を減らし、アーカイブログのバックアップを頻繁に行うことです。これにより、ストレージ消費量が削減され、RPOが向上しますが、RTOが延長される可能性があります。バックアップスキームを設定する際には、RTOとRPOの目標を考慮してください。ボリューム上のSnapshotバックアップの数には制限(1023)もあります。
-
*権限委譲。*必要に応じて、SnapCenter UIに組み込まれているロールベースのアクセス制御を利用して、アプリケーションチームやデータベースチームに権限を委譲できます。
解決策 の導入
以降のセクションでは、Azureクラウド内のAzure NetApp FilesでのSnapCenterの導入、設定、Oracleデータベースのバックアップ、リカバリ、クローニングの手順を詳しく説明します。
導入の前提条件
Details
導入には、AzureのANFで既存のOracleデータベースを実行する必要があります。そうでない場合は、次の手順に従って、解決策検証用に2つのOracleデータベースを作成します。AzureクラウドでのANFへのOracleデータベースの導入と自動化の詳細については、『TR-4987: "NFSを使用したAzure NetApp FilesへのOracleの導入を簡易化、自動化"
-
Azureアカウントがセットアップされ、必要なVNetセグメントとネットワークセグメントがAzureアカウント内に作成されている。
-
Azureクラウドポータルから、Azure Linux VMをOracle DBサーバとして導入します。Oracleデータベース用のAzure NetApp Files容量プールとデータベースボリュームを作成します。azureuserからDBサーバへのVM SSH秘密鍵/公開鍵認証を有効にします。環境のセットアップの詳細については、前のセクションのアーキテクチャ図を参照してください。参照先 "Azure VMおよびAzure NetApp Files へのOracleの導入手順を順を追って説明します" を参照してください。
ローカルディスクの冗長性を使用して導入されたAzure VMの場合は、VMのルートディスクに少なくとも128Gが割り当てられ、OracleインストールファイルをステージングしてOSスワップファイルを追加するための十分なスペースが確保されていることを確認してください。必要に応じて、/tmplvおよび/rootlv OSパーティションを展開します。データベースボリュームの命名規則がVMname-u01、VMname-u02、およびVMname-u03に準拠していることを確認します。 sudo lvresize -r -L +20G /dev/mapper/rootvg-rootlv
sudo lvresize -r -L +10G /dev/mapper/rootvg-tmplv
-
Azureクラウドポータルで、NetApp SnapCenter UIツールを最新バージョンで実行するためのWindowsサーバをプロビジョニングします。詳細については、次のリンクを参照してください。 "SnapCenter サーバをインストールします"。
-
最新バージョンのAnsibleとGitがインストールされたAnsibleコントローラノードとしてLinux VMをプロビジョニングします。詳細については、次のリンクを参照してください。 "NetApp解決策 自動化の導入" セクション-
Setup the Ansible Control Node for CLI deployments on RHEL / CentOS
または
Setup the Ansible Control Node for CLI deployments on Ubuntu / Debian
。Ansibleコントローラノードは、SSHポートを介してAzure DB VMにアクセスできるかぎり、オンプレミスまたはAzureクラウドに配置できます。 -
NetApp向けOracle Deployment Automation Toolkitのコピーのクローンを作成します。の手順に従います。 "TR-4887" をクリックしてプレイブックを実行します。
git clone https://bitbucket.ngage.netapp.com/scm/ns-bb/na_oracle_deploy_nfs.git
-
権限777のAzure DB VM /tmp/archiveディレクトリにOracle 19Cインストールファイルをステージングします。
installer_archives: - "LINUX.X64_193000_db_home.zip" - "p34765931_190000_Linux-x86-64.zip" - "p6880880_190000_Linux-x86-64.zip"
-
次のビデオをご覧ください。
SnapCenterを使用したANFでのOracleデータベースのバックアップ、リカバリ、クローン -
を確認します
Get Started
オンラインメニュー。
SnapCenterのインストールとセットアップ
Details
オンラインでアクセスすることをお勧めします。 "SnapCenter ソフトウェアのドキュメント" SnapCenterのインストールと設定に進む前に:を参照してください。Azure ANFにOracle向けのSnapCenterソフトウェアをインストールしてセットアップする手順の概要を以下に示します。
-
SnapCenter Windowsサーバから'最新のJava JDKをダウンロードしてからインストールします "デスクトップアプリケーション用Javaの取得"。
-
SnapCenter Windowsサーバから、最新バージョン(現在は5.0)のSnapCenterインストール実行ファイルをNetApp Support Siteからダウンロードしてインストールします。 "NetApp |サポート"。
-
SnapCenterサーバのインストールが完了したら、ブラウザを起動して、Windowsのローカル管理者ユーザまたはドメインユーザのクレデンシャル(ポート8146)を使用してSnapCenterにログインします。
-
レビュー
Get Started
オンラインメニュー。 -
インチ
Settings-Global Settings
、チェックHypervisor Settings
[更新]をクリックします。 -
必要に応じて、
Session Timeout
SnapCenter UIの場合は、希望する間隔に移動します。 -
必要に応じて、SnapCenterにユーザを追加します。
-
。
Roles
タブには、さまざまなSnapCenterユーザに割り当てることができる組み込みロールが表示されます。カスタムロールは、必要な権限を持つ管理者ユーザが作成することもできます。 -
移動元 `Settings-Credential`で、SnapCenter管理ターゲットのクレデンシャルを作成します。このデモのユースケースでは、Azure VMへのログインに使用するLinuxユーザと、容量プールへのアクセスに使用するANFクレデンシャルを使用します。
-
移動元
Storage Systems
タブ、追加Azure NetApp Files
上記で作成したクレデンシャルを使用 -
移動元
Hosts
タブで、Azure DB VMを追加します。これにより、Linux上のOracle用SnapCenterプラグインがインストールされます。 -
DBサーバVMにホストプラグインをインストールすると、ホスト上のデータベースが自動検出され、
Resources
タブ。戻る `Settings-Polices`を使用して、Oracleデータベースのフルオンラインバックアップとアーカイブログのみのバックアップのバックアップポリシーを作成します。このドキュメントを参照 "Oracle データベースのバックアップポリシーの作成" 詳細な手順については、を参照してください。
データベースバックアップ
Details
NetAppのSnapshotバックアップでは、データベースボリュームのポイントインタイムイメージが作成されます。このイメージを使用して、システム障害やデータ損失が発生した場合にリストアできます。Snapshotバックアップの所要時間はごくわずかで、通常は1分未満です。バックアップイメージにはSnapshotコピーが最後に作成されてからのファイルへの変更のみが記録されるため、ストレージスペースは最小限しか消費されず、パフォーマンスのオーバーヘッドもわずかです。次のセクションでは、SnapCenterでのOracleデータベースバックアップ用のスナップショットの実装について説明します。
-
移動
Resources
タブ:データベースVMにSnapCenterプラグインをインストールした後に検出されたデータベースが表示されます。最初は、Overall Status
データベースの表示数:Not protected
。 -
をクリックします
View
ドロップダウンで次の値に変更:Resource Group
。をクリックしますAdd
右側にサインインしてリソースグループを追加します。 -
リソースグループ、タグ、カスタムの命名規則に名前を付けます。
-
にリソースを追加する
Resource Group
。類似するリソースをグループ化すると、大規模な環境でのデータベース管理を簡易化できます。 -
バックアップポリシーを選択し、下の[+]記号をクリックしてスケジュールを設定します。
Configure Schedules
。 -
ポリシーにバックアップ検証が設定されていない場合は、[Verification]ページはそのままにしておきます。
-
バックアップのレポートと通知をEメールで送信するには、環境にSMTPメールサーバが必要です。メールサーバが設定されていない場合は黒のままにします。
-
新しいリソースグループの概要。
-
上記の手順を繰り返して、対応するバックアップポリシーでデータベースのアーカイブログのみのバックアップを作成します。
-
リソースグループをクリックすると、そのグループに含まれているリソースが表示されます。スケジュールされたバックアップジョブのほかに、1回限りのバックアップを実行するには、
Backup Now
。 -
実行中のジョブをクリックすると監視ウィンドウが開き、オペレータはジョブの進捗状況をリアルタイムで追跡できます。
-
バックアップジョブが正常に完了すると、データベーストポロジの下にSnapshotバックアップセットが表示されます。フルデータベースバックアップセットには、データベースデータボリュームのSnapshotとデータベースログボリュームのSnapshotが含まれます。ログのみのバックアップには、データベースログボリュームのSnapshotのみが含まれます。
データベースリカバリ
Details
SnapCenterによるデータベースリカバリでは、データベースボリュームイメージのポイントインタイムSnapshotコピーがリストアされます。次に、SCN /タイムスタンプ、またはバックアップセット内の使用可能なアーカイブログで許可されているポイントまで、データベースがロールフォワードされます。次のセクションでは、SnapCenter UIを使用したデータベースリカバリのワークフローについて説明します。
-
移動元
Resources
タブでデータベースを開きます。Primary Backup(s)
ページデータベースデータボリュームのSnapshotを選択し、Restore
ボタンをクリックしてデータベースリカバリワークフローを起動します。Oracle SCNまたはタイムスタンプでリカバリを実行する場合は、バックアップセット内のSCN番号またはタイムスタンプをメモします。 -
選択するオプション
Restore Scope
。コンテナ・データベースの場合、SnapCenterでは、フル・コンテナ・データベース(すべてのデータファイル)、プラガブル・データベース、または表領域・レベルのリストアを柔軟に実行できます。 -
選択するオプション
Recovery Scope
。All logs
は、バックアップセット内の使用可能なすべてのアーカイブログを適用することを意味します。SCNまたはタイムスタンプによるポイントインタイムリカバリも使用できます。 -
。
PreOps
リストア/リカバリ処理の前に、データベースに対してスクリプトを実行できます。 -
。
PostOps
リストア/リカバリ処理後にデータベースに対してスクリプトを実行できます。 -
必要に応じてEメールで通知
-
リストアジョブの概要
-
[Running job]をクリックして開きます。
Job Details
ウィンドウ。ジョブステータスは、Monitor
タブ。
データベースクローン
Details
SnapCenterを使用したデータベースクローンは、ボリュームのSnapshotから新しいボリュームを作成することによって実行されます。システムは、Snapshot情報を使用して、Snapshotの作成時にボリューム上のデータを使用して新しいボリュームをクローニングします。さらに重要なのは、他の方法と比べて短時間(数分)で本番環境のデータベースのクローンコピーを作成して開発やテストに役立てることです。これにより、データベースアプリケーションのライフサイクル管理が大幅に向上します。次のセクションでは、SnapCenter UIを使用したデータベースクローンのワークフローについて説明します。
-
移動元
Resources
タブでデータベースを開きます。Primary Backup(s)
ページデータベースデータボリュームのSnapshotを選択し、clone
ボタンをクリックしてデータベースクローンワークフローを起動します。 -
クローンデータベースのSIDに名前を付けます。必要に応じて、コンテナデータベースのクローニングもPDBレベルで実行できます。
-
クローンデータベースコピーを配置するDBサーバを選択します。別の名前を付ける場合を除き、デフォルトのファイルの場所を保持します。
-
クローンDBホストには、ソースデータベースと同じOracleソフトウェアスタックがインストールされ、設定されている必要があります。デフォルトのクレデンシャルは維持するが変更する
Oracle Home Settings
クローンDBホストの設定と照合します。 -
。
PreOps
クローニング処理の前にスクリプトを実行できます。データベースパラメータは、本番環境のデータベースと比較して、クローンDBのニーズに合わせて調整できます(SGAターゲットの削減など)。 -
。
PostOps
クローニング処理後にデータベースに対してスクリプトを実行できます。クローンデータベースのリカバリには、SCN、タイムスタンプベース、またはキャンセル(バックアップセット内の最後のアーカイブログへのデータベースのロールフォワード)までのいずれかを使用できます。 -
必要に応じてEメールで通知
-
クローニングジョブの概要。
-
[Running job]をクリックして開きます。
Job Details
ウィンドウ。ジョブステータスは、Monitor
タブ。 -
クローンデータベースはすぐにSnapCenterに登録されます。
-
DBサーバホスト上のクローンデータベースを検証します。クローン開発データベースの場合は、データベースアーカイブモードをオフにする必要があります。
[azureuser@ora-02 ~]$ sudo su [root@ora-02 azureuser]# su - oracle Last login: Tue Feb 6 16:26:28 UTC 2024 on pts/0 [oracle@ora-02 ~]$ uname -a Linux ora-02 4.18.0-372.9.1.el8.x86_64 #1 SMP Fri Apr 15 22:12:19 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux [oracle@ora-02 ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs 7.8G 49M 7.7G 1% /run tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup /dev/mapper/rootvg-rootlv 22G 17G 5.6G 75% / /dev/mapper/rootvg-usrlv 10G 2.0G 8.1G 20% /usr /dev/mapper/rootvg-homelv 1014M 40M 975M 4% /home /dev/sda1 496M 106M 390M 22% /boot /dev/mapper/rootvg-varlv 8.0G 958M 7.1G 12% /var /dev/sda15 495M 5.9M 489M 2% /boot/efi /dev/mapper/rootvg-tmplv 12G 8.4G 3.7G 70% /tmp tmpfs 1.6G 0 1.6G 0% /run/user/54321 172.30.136.68:/ora-02-u03 250G 2.1G 248G 1% /u03 172.30.136.68:/ora-02-u01 100G 10G 91G 10% /u01 172.30.136.68:/ora-02-u02 250G 7.5G 243G 3% /u02 tmpfs 1.6G 0 1.6G 0% /run/user/1000 tmpfs 1.6G 0 1.6G 0% /run/user/0 172.30.136.68:/ora-01-u02-Clone-020624161543077 250G 8.2G 242G 4% /u02_ntap1dev [oracle@ora-02 ~]$ cat /etc/oratab # # This file is used by ORACLE utilities. It is created by root.sh # and updated by either Database Configuration Assistant while creating # a database or ASM Configuration Assistant while creating ASM instance. # A colon, ':', is used as the field terminator. A new line terminates # the entry. Lines beginning with a pound sign, '#', are comments. # # Entries are of the form: # $ORACLE_SID:$ORACLE_HOME:<N|Y>: # # The first and second fields are the system identifier and home # directory of the database respectively. The third field indicates # to the dbstart utility that the database should , "Y", or should not, # "N", be brought up at system boot time. # # Multiple entries with the same $ORACLE_SID are not allowed. # # NTAP2:/u01/app/oracle/product/19.0.0/NTAP2:Y # SnapCenter Plug-in for Oracle Database generated entry (DO NOT REMOVE THIS LINE) ntap1dev:/u01/app/oracle/product/19.0.0/NTAP2:N [oracle@ora-02 ~]$ export ORACLE_SID=ntap1dev [oracle@ora-02 ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Tue Feb 6 16:29:02 2024 Version 19.18.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.18.0.0.0 SQL> select name, open_mode, log_mode from v$database; NAME OPEN_MODE LOG_MODE --------- -------------------- ------------ NTAP1DEV READ WRITE ARCHIVELOG SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 3221223168 bytes Fixed Size 9168640 bytes Variable Size 654311424 bytes Database Buffers 2550136832 bytes Redo Buffers 7606272 bytes Database mounted. SQL> alter database noarchivelog; Database altered. SQL> alter database open; Database altered. SQL> select name, open_mode, log_mode from v$database; NAME OPEN_MODE LOG_MODE --------- -------------------- ------------ NTAP1DEV READ WRITE NOARCHIVELOG SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 NTAP1_PDB1 MOUNTED 4 NTAP1_PDB2 MOUNTED 5 NTAP1_PDB3 MOUNTED SQL> alter pluggable database all open;
追加情報の参照先
このドキュメントに記載されている情報の詳細については、以下のドキュメントや Web サイトを参照してください。
-
Azure NetApp Files の特長
-
SnapCenter ソフトウェアのドキュメント
-
TR-4987:『Simplified、Automated Oracle Deployment on Azure NetApp Files with NFS』