| Oracle® Enterprise Manager Cloud管理ガイド 12c リリース5 (12.1.0.5) B70509-13 |
|
 前 |
 次 |
この付録では、本番データが更新されるたびに、アプリケーションの開発者とテスト実施者がEnterprise Managerを使用して、セキュアでストレージ効率のよいデータベースのクローンを迅速かつ簡単にオンデマンドでプロビジョニングする方法を示します。
この付録には、次のセクションがあります。
通常、IT環境では、アプリケーションの開発とテストのために本番データの複数のコピーが必要となります。ただし、本番データのクローン全体のプロビジョニングは時間のかかるプロセスであり、データベース管理者、システム管理者およびストレージ管理者の間での調整が必要となるばかりではなく、大きなストレージ容量も必要となります。
アプリケーションの開発者またはテスト実施者がデータベースのクローンを必要とする場合、一般的には承認サイクルを経る必要があり、その後に煩雑で時間のかかるクローニング・プロセスを開始しますが、これには数日かかることもあります。クローンは複数のユーザーおよびアプリケーションで共有されますが、複数ユーザーによる共有が増える結果としてパフォーマンスが低下します。このような環境において、本番データベースへの変更を反映するためのテスト・データのリフレッシュは、通常は固定したスケジュールで行われ、必要な頻度では実施されないことがあります。その結果として、ともすれば、開発者およびテスト実施者が最新データを使用してテストすることの徹底が難しくなります。
これ以降の項では、Enterprise Managerの機能を活用した、前述の課題に対するソリューションを提供します。その目標は、本番データベースの更新によって必要となった際にはいつでも、開発者およびテスト実施者がセキュアでサイズを減らした本番データベースのコピーをオンデマンドでプロビジョニング可能とすることです。
このソリューションでは、エンタープライズのDatabase as a Service (DBaaS)クラウド機能が有効化されていることが必要なことに注意してください。DBaaSを有効化する手順は、第12章「DBaaSクラウドの有効化」を参照してください。
このシナリオ例の基本フローを次の図に示します。
このシナリオでは、アプリケーションのテストに使用する本番データベースのコピーである、テスト・マスター・データベースが管理者レベルのロールで作成されることを想定しています。Oracleにはテスト・マスター・データベースを作成するための様々なオプションが提供されていますが、このシナリオでは、管理者がRMANバックアップおよびRMANリストアの操作を使用して本番データベースのバックアップを作成し、それをテスト・マスターとしてリストアすることを想定しています。
RMANバックアップを使用して、定期的に予定された頻度で別々に、本番データベースの最新データでテスト・マスター・データベースをリフレッシュすることが期待されています。
本番データをテストに利用可能とするためには、機密性があると特定されたデータは、テスト・マスター・データベース上でマスキング(またはスクランブル)される必要があります。理想的には、データ・サブセッティングも併用して、テストに必要なデータのみが含まれるようにデータベースのサイズを縮小する必要があります。
たとえば、ある企業が人事管理アプリケーションを開発中であり、従業員の社会保障と給与のデータを使用したテストを必要としているとしましょう。この機密データにはマスキングやスクランブルをかけることが可能ですし、それと同時に、従業員の所在地のような外部データは実際のテストに必要なデータ・サブセットから除外することもできます。
Oracleのインラインのマスキングおよびサブセッティングの機能を使用すると、すべて同じタスク・フローの中で、機密データをマスキングすると同時にデータベースのサイズを縮小することが可能です。これによって、機密性のある本番データを保護したうえで、大きなマスキング済本番データベースをテストのために格納するハードウェアのコストを大きく引き下げるという2つの目的がかなえられます。
テスト・マスターの作成およびリフレッシュと、テストに使用するデータの保護とサブセッティングを行うプロセスの後には、アプリケーションの開発者およびテスト実施者(DBaaS用語ではセルフ・サービス・ユーザーとも呼ばれます)は、Database as a Serviceの主要なユーザー・インタフェースであるEnterprise Managerのセルフ・サービス・ポータルを使用して、テスト・マスター・データベースのクローンを迅速かつ簡単に作成できます。
この機能は、スナップ・クローン(Database as a Serviceによって提供され、Oracle Databaseの全機能を有するコピーを最小限のストレージ要件で作成可能にする機能)を通じて有効になります。スナップ・クローンでは、ストレージ要件を最小限としたうえで、ユーザーはテラバイト級のデータを含むテスト・マスターのクローンを、何時間もかけずにわずか数分で作成できます。
この項では、前項に概要を示したテスト・データ・リフレッシュ・ソリューションの実装に必要なタスクの概要を説明します。
ロール: スーパー管理者
ロールは、Enterprise Manager内でシステムおよびオブジェクトの権限を管理するために使用されます。ロールは、管理者とセルフ・サービス・ユーザーのどちらにも割り当てられる必要があります。
このシナリオの中で様々なDBaaS設定タスクを行うユーザーに、次の管理者ロールを割り当てます。これらのロールは、Enterprise Manager内で即時提供されます。
EM_SSA_ADMINISTRATOR: このロールを持つユーザーは、クローンを作成するセルフ・サービス・ユーザーの割当て制限と制約を定義できます。
EM_STORAGE_ADMINISTRATOR: このロールのユーザーは、スナップ・クローンの使用に必要なストレージ・ハードウェアを登録する権限を持ちます。
このタスクを完了する手順は、第3.3項「ロールの定義およびユーザーの割当て」を参照してください。
テスト・マスター・データベースのクローンを作成するためにセルフ・サービス・ポータルを使用するユーザーには、カスタムのセルフ・サービス・ユーザーを作成する必要があります。通常、アプリケーション開発者や機能テスト実施者など、テストに必要な様々な機能グループのそれぞれに対してロールを作成します。
すべてのロールは、Enterprise Managerとともに提供されるEM_SSA_USERロールに基づきます。
このタスクを完了する手順は、第3.3.1項「セルフ・サービス・アプリケーション管理者およびユーザーのカスタム・ロールの作成」を参照してください。
各種のロールを作成した後に、クローンを作成する個々のテスト実施者または開発者に対してそれぞれセルフ・サービス・ユーザー・アカウントを作成します。各ユーザーは、前述のタスクで定義されたカスタム・ロールのいずれかに割り当てられます。
このタスクを完了する手順は、第3.3.2項「ユーザーの作成およびロールの割当て」を参照してください。
ロール: DBA
Oracle RMANバックアップ操作を使用して本番データベースのバックアップを作成します。このバックアップは、その後、クローンを作成するテスト・マスター・データベースの作成のためにリストアされます。
テスト・マスター・データベースの作成にはいくつかのオプションが利用可能ですが、作成されるバックアップ・データベースのマスキングとサブセッティングが可能であることからRMANのバックアップおよびリストアが使用されます。
データベースのバックアップを作成する手順は、次のドキュメントを参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em121&id=EMLCM93231
ロール: DBAおよびセキュリティ・アナリスト
マスキングおよびサブセッティング用データの準備のため、次の手順を完了する必要があります。
開始する前に、保護の必要があるデータ、テストに必要なデータ、およびマスキングとサブセッティングを最適に実装する方法を決定します。
マスキングが必要な機密データを特定します。
機密データを含む表および列の位置を特定します。Oracle Enterprise Managerのデータ検出およびモデリング機能を使用すると、パターン検索条件によってこのようなデータを簡単に検出できます。
どのマスキング・アルゴリズムが企業のニーズに合致しているかを決定します。機密データベースの一般的な形式のマスキング用としてOracleが提供する書式を使用できるか、それともカスタム書式を作成する必要があるかを決定します。
どの表が不要で除外可能であるなど、データをサブセッティングする最適な方法を決定します。
データ・サブセッティングとデータ・マスキングは、どちらもアプリケーション・データ・モデル(ADM)に依存します。ADMは、アプリケーション内部の参照関係や機密列などのアプリケーション・メタデータ情報を取得および格納するEnterprise Manager内のナレッジ・ベースです。
ADMを作成する手順は、次のドキュメントを参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em121&id=RATUG4045
Enterprise Managerのユーザー・インタフェースを使用してデータ・マスキング定義を作成し、機密列にマスキング形式を適用します。Oracleには、そのまま使用することも必要に応じて変更することも可能な、マスキング形式の多彩なライブラリが提供されています。カスタムのマスキング形式を作成することもできます。
このタスクを完了する手順は、次のドキュメントを参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em121&id=RATUG04000
Role: ストレージ管理者
スナップ・クローン機能には、作成されるデータベースのクローン用として適切なストレージが必要となります。ネイティブで提供されるストレージのサポートに加えて、Oracleでは、Oracle Sun ZFSファイル・システムを使用したスナップ・クローンに対するソフトウェア手法もサポートされています。
このシナリオでは、Oracle Sun ZFSファイル・システム・ストレージの利用を想定しています。基本フローは、まずZFSファイル・システムを構成し、次にストレージをEnterprise Managerに登録するというものです。最初の手順として、ZFSストレージ・サーバーに対してストレージの取得および割当てを行う必要があることに注意してください。
主な手順は次のとおりです。
Enterprise Managerからストレージを管理できるユーザーを構成または作成します。
ストレージ・ボリュームをホストするために使用するZFSプールを構成し、そのプールに対する権限を付与します。
そのZFSプールに対する割当て制限を行い、ユーザーに権限を割り当てます。
ユーザー名、プロトコル、ストレージ資格証明を指定して、ZFSファイル・システムをEnterprise Managerに登録します。
ストレージ・ボリュームを作成します
このタスクを完了する手順は、第12.7.3.1項「ストレージ・サーバーの構成」を参照してください。
テスト・マスター・データベースは、スナップ・クローンのコピーが作成されるストレージ・ボリューム上に作成される必要があります。テスト・マスターは、前のポイント・イン・タイムで取得され、特定の間隔でリフレッシュされるスナップショットまたはRMANバックアップ・プロファイルから作成できます。
このタスクを完了する手順は、第20.5.6項「個別に同期されたテスト・マスターの作成」を参照してください。
テスト・マスター・データベースが作成されると、スナップ・クローンに有効化される必要があります。
Enterprise Managerでストレージ登録ページに戻ります。
テスト・マスター・データベースの構成がリフレッシュされると、ターゲットが自動的に検出されてストレージ登録ページ上に表示されます。テスト・マスター・データベースを選択し、ページ上部の「スナップ・クローンの有効化」オプションを選択します。
これでテスト・マスター・データベースのスナップ・クローンに対する準備が整いました。詳細は、第20.4.7項「スナップ・クローンのテスト・マスターの有効化」を参照してください
Role: セルフ・サービス管理者
テスト・マスターの準備が整うと、定義されたルールに従ってデータのマスキングとサブセッティングが可能となります。
本番データベースに変更が発生した場合には、テスト・マスター・データベースをリフレッシュする必要があります。本番データベースに変更を反映するには、マスキングとサブセッティングの規則の再検討が必要となる可能性があります。その場合には、新しいサブセット定義をテスト・マスター・データベースに適用できます。
Enterprise Managerユーザー・インタフェースを介してサブセット定義を作成することにより、データのマスキングとサブセッティングは同時に実行可能です。基本フローは次のとおりです。
テスト・マスターをソース・データベースとして選択します。
サブセットに含めるデータをフィルタする表ルールを定義します。領域見積りアクションを実行して、データベースのサイズがどれだけ削減されているか測定します。これは、ルールを微調整してデータベース・サブセットのサイズを変更する反復プロセスとなることがあります。
第A.6.3.3項「マスキング定義の作成」で作成したマスキング定義を参考にします。
オプションとして、列ルールを使用して追加の列をマスキングしますが、通常、これはCLOB列やBLOB列などの垂直列となります。これはサブセットのサイズの削減にも役立ちます。
このタスクを完了する手順は、次のドキュメントを参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em121&id=RATUG4053
サブセット定義が作成されたら、それをテスト・マスター・データベースに適用します。主な手順は次のとおりです。
サブセット定義をZIPアーカイブとして保存します。
そのアーカイブをテスト・マスター・データベース・ホスト上で抽出します。
テスト・マスター・データベースに対してサブセット・スクリプトを実行して、データのマスキングおよびサブセッティングを適用します。
このタスクを完了する手順は、次のドキュメントを参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em121&id=RATUG4214
Role: セルフ・サービス管理者
ストレージの構成とテスト・マスター・データベースの設定が行われた後に、セルフ・サービス・ユーザーがテスト・マスター・クローンの作成に使用するセルフ・サービス・ポータルを構成する必要があります。
最初の手順は、Platform as a Service (PaaS)インフラストラクチャの作成です。PaaSゾーンには、クローンが作成されるターゲット(データベース・ホスト)のセット、およびこれらのターゲットにアクセス可能である(ロールに基づく)ユーザーに対する配置ポリシー制約が定義されます。たとえば、(APP_DEVロールを割り当てられた)開発者のグループにPaaSゾーンを作成して特定ホストのセットへのアクセス権を付与し、テスト実施者のグループには別のPaaSゾーンを作成して異なるホストのセットへのアクセス権を付与することもできます。
各ゾーン内のホストは、オペレーティング・システムおよび各ホストにインストールされたOracle Databaseのタイプおよびバージョンによって、プールへとグループ分けされます。たとえば、あるプールはLinux上でシングル・インスタンスのOracle Databaseリリース12.1.01で構成されたすべてのホストのために作成し、別のプールをSolaris上のOracle RAC用として作成するようなことが可能です。
ユーザーがスナップ・クローン機能を使用してテスト・マスター・データベースのクローンを作成できるようにするには、テスト・マスター・データベースのプロビジョニング・プロファイルを作成する必要があります。ユーザーによって作成されるクローンはこのプロファイルをベースとします。
最後に、前述の構成をカプセル化するために、スナップ・クローン・サービス・テンプレートが作成されます。セルフ・サービス・ユーザーがクローンを作成する際には、クローンが作成されるホストおよびデータベースを定義しているこのテンプレートが選択されます。
テスト・マスターのクローンがデプロイされるホストが含まれるPaaSインフラストラクチャを作成します。
ゾーンに1つ以上のデータベース・ホスト・ターゲットを追加します。
それぞれのホストに配置ポリシー制約を指定します。
このゾーンにアクセス可能なセルフ・サービス・ユーザー・ロールを選択します。
このタスクを完了する手順は、第11.2.2.1項「PaaSインフラストラクチャ・ゾーンの作成」を参照してください。
PaaSインフラストラクチャ・ゾーンの中で、各データベース・タイプに対して1つずつとなるように、1つ以上のデータベース・プールを作成します。
スナップ・クローンに必要なホスト資格証明を指定します。
データベース・プールが作成されるPaaSインフラストラクチャ・ゾーンを選択します。
データベースがデプロイされる構成(シングル・インスタンスまたはクラスタ)、プラットフォームおよびバージョンを指定します。
プール内の各ホストで実行可能なデータベース・インスタンスの数を指定します。
このタスクを完了する手順は、第11.2.2.2.1項「データベース・プールの作成」を参照してください。
リクエストできる時間、その期間などを指定して、データベースのリクエスト設定を構成します。リクエスト設定を構成するには、次の内容を指定する必要があります。
将来の予約の長さ
アーカイブの最大保存期間
デフォルト・リタイア期間
このタスクを完了する手順は、第11.2.3項「リクエスト設定の構成」を参照してください。
割当て制限は、各セルフ・サービス・ユーザーが使用可能なDBaaSリソースの量を制御します。割当て制限を行うには次の手順を実行します。
割当て制限を行うセルフ・サービス・ユーザー・ロールを選択します。
セルフ・サービス・ユーザーによって作成されたすべてのデータベースに割当て可能な、メモリーおよびストレージの総容量を指定します。
ユーザーがリクエスト可能なデータベースの数を指定します。
このタスクを完了する手順は、第11.2.4項「割当て制限の設定」を参照してください。
テスト・マスター・データベースに対するプロビジョニング・プロファイルを作成します。次の手順で作成されるサービス・テンプレートがこのプロファイルを使用します。
プロファイルを作成するデータベースとして、テスト・マスター・データベースを選択します。第A.6.6項「テスト・マスター・データベースを有効化してスナップ・クローンを使用」で説明されているように、データベースでスナップ・クローンが有効である必要があります。
データベースへのアクセスが必要となる名前付き資格証明を指定します。
プロファイルに対して一意な名前(「スナップ・クローン・プロファイル」など)を入力します。
このタスクを完了する手順は、第20.4.8項「スナップショットを使用したデータベース・プロビジョニング・プロファイルの作成」を参照してください。
最後に、テスト実施者および開発者がテスト・マスター・データベースのクローンの作成に使用するサービス・テンプレートを作成します。
前の手順で作成したスナップ・クローン・プロファイルをテンプレートのベースとなるプロファイルとして選択します。
データベース・タイプ(シングル・インスタンスまたはRAC)、データベースSIDおよびドメイン名など、データベース定義の詳細を指定します。
PaaSインフラストラクチャ・ゾーンおよびデータベース・プールを選択します。このサービス・テンプレートを使用して作成されるデータベースのクローンは、このプールにデプロイされます。ホスト・ターゲットは「参照ホスト」フィールドに移入されています。
データベースのクローンが使用するストレージ・ボリュームを構成します。デプロイされるデータベースの新しいマウント・ポイントに対する接頭辞およびブロックの変更に必要となる領域の量を指定します。
クローンされたデータベース上にセルフ・サービス・ユーザーが取得可能なスナップショットの数を指定します。
スナップショット・ポリシーおよびクローンのシステム・スキーマに対する資格証明を指定します。
新しいデータベースの操作に影響する可能性のある初期化パラメータを構成します。
このサービス・テンプレートにアクセス可能なセルフ・サービス・ユーザー・ロールを選択します。
このタスクを完了する手順は、第20.4.9項「スナップ・クローン・プロファイルを使用したサービス・テンプレートの作成」を参照してください。
Role: セルフ・サービス・ユーザー
この時点で、Enterprise Manager Cloud Controlが提供するデータベース・クラウド・セルフ・サービス・ポータルのインタフェースは、テスト実施者および開発者が必要なときにはいつでも、テスト・マスター・データベースのクローンの作成に使用可能となっています。セルフ・サービス・ユーザーが従う必須の手順は次のものです。
テスト・マスター・サービス・テンプレートを使用テンプレートとして選択します。
クローンがデプロイされるPaaSインフラストラクチャ・ゾーンを選択します。
このタスクを完了する手順は、第22.2項「データベースのリクエスト」を参照してください。
テスト・データのリフレッシュをサポートするインフラストラクチャが設定されると、本番データに施された更新を反映するために、データの定期的リフレッシュの計画を導入する必要があります。データのリフレッシュが必要となるたびに次の手順を繰り返す必要があります。
最新の本番データを取得するには、テスト・マスター・データベースをリフレッシュする必要があります。このタスクを完了する手順は、第20.5.10項「テスト・マスター・データベースのリフレッシュ」を参照してください。
テスト・マスターをリフレッシュした後、スナップショット・ベースのデータベース・プロビジョニング・プロファイルの新しいリビジョンを作成する必要があります。このタスクを完了する手順は、第20.5.11項「スナップショット・プロファイルのリフレッシュ」を参照してください。
セルフ・サービス・ユーザーは、スナップショット・ベースのデータベース・プロビジョニング・プロファイルの新しいリビジョンを使用してこのデータベース・インスタンスをリフレッシュし、最新の本番データを反映できます。第22.3項「データベースのリフレッシュ」を参照してください。
