移行の計画
このアーキテクチャでは、複数の移行シナリオがサポートされています。
移行オプションの検討
Oracle Exadata Database ServiceまたはOracle Database Exadata Cloud at Customerでは、次の4つの一般的なデプロイメント・モデルを検討します。
- 大規模なオンプレミス・データベースを「現状のまま」Oracle Database Exadata Cloud at Customerに移動して、Oracle Data Guardによって接続されたOCIディザスタ・リカバリ(DR)インスタンスも提供します。
コンポーネント オンプレミス Exadata(ハーフ・ラック) データベース・サイズ 47 TB 47 TB コア 24 16 システム・グローバル領域およびプログラム・グローバル領域 4 TB 1.5 TB - 複数のオンプレミス・データベースをOracle Exadata Database ServiceまたはOracle Database Exadata Cloud at Customer上の複数のプラガブル・データベース(PDB)に統合し、Oracle Data Guardによって接続されたOCI DRインスタンスも提供します。
コンポーネント オンプレミス Exadata(フル・ラック10台) データベース 1000 1000 DB構成 2~16 TB/DB CDB = 29 PDB = さまざまなサイズの1000
- Oracle Database Exadata Cloud at Customerを使用して本番ワークロードをオンプレミスで実行し、Oracle Data Guardによって接続されたデータベース・インスタンスを使用して、OCIでDRまたはOracle Exadata Database Serviceを提供します。
コンポーネント オンプレミス Exadata(ハーフ・ラック) データベース・サイズ 19.5 TB 19.5 TB コア 24 12 システム・グローバル領域およびプログラム・グローバル領域 2.5 TB 1.5 TB - Oracle Data Guardによって接続されたデータベース・インスタンスとともにオンプレミス・ハードウェアを使用して、OCIおよびDR上のOracle Exadata Database Serviceで本番ワークロードを実行します。
コンポーネント オンプレミス Exadata(ハーフ・ラック) データベース・サイズ 19.5 TB 19.5 TB コア 24 12 システム・グローバル領域およびプログラム・グローバル領域 2.5 TB 1.5 TB
ゼロ・ダウンタイム移行サービスの使用
大規模なオンプレミス・データベースをOracle Cloud Infrastructure (OCI)に移行するには、ゼロ・ダウンタイム移行(ZDM)サービスの使用を検討してください。
Oracle Exadata Database ServiceまたはOracle Database Exadata Cloud at Customerのいずれを使用する場合でも、ソース・データベースのバックアップを作成し、ターゲット・データベースにリストアします。その後、RMANを実行してOracle Active Data Guard同期を実行し、プライマリ・ロールをソース・データベースからターゲット・データベースに切り替える必要があります。ゼロ・ダウンタイム移行では、選択したバックアップ・メディアに基づいて様々な移行方法もサポートされます。バックアップ・メディアには、Oracle Cloud Infrastructure Object Storage、Zero Data Loss Recovery Applianceまたはネットワーク・ファイル・システム(NFS)ストレージがあります。
次の表に、いくつかのゼロ・ダウンタイム移行(ZDM)シナリオの要件および条件を示します。
移行方法 | 移行時間 | 停止時間要件* | 使用されるOracleツール | 使用する状況 |
---|---|---|---|---|
ZDM - 物理オンライン | 8 Hours |
2~5分 (データベース・サイズに依存しない) |
|
|
ZDM - 物理オフライン | 8 Hours | TBあたり最大8時間 |
|
|
ZDM - 論理オンライン | 12 Hours |
2~5分 (データベース・サイズに依存しない) |
|
|
ZDM - 論理オフライン | 16 Hours | TBあたり最大16時間 |
|
|
*これらのダウンタイム番号は経験から得られるため、正確な数字ではなく全体的なガイダンスとして使用する必要があります。ダウンタイムの要件は大きく異なるため、本番の切替えを計画する前に徹底した分析とテストが必要です。
推奨
要件は、ここで説明するアーキテクチャとは異なる場合があります。次の推奨事項を開始点として使用します。
- VCN
VCNを作成する際、VCNのサブネットにアタッチする予定のリソース数に基づいて、必要なCIDRブロックの数および各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。
プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。
VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。
サブネットを設計する際は、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。
リージョナル・サブネットを使用します。
- クラウド・ガード
Oracleが提供するデフォルトのレシピをクローニングおよびカスタマイズして、カスタム・ディテクタおよびレスポンダ・レシピを作成します。これらのレシピでは、警告を生成するセキュリティ違反のタイプと、それに対して実行できるアクションを指定できます。たとえば、可視性がpublicに設定されているオブジェクト・ストレージ・バケットを検出できます。
クラウド・ガードをテナンシ・レベルで適用して、広範な範囲に対応し、複数の構成を維持する管理上の負担を軽減します。
管理対象リスト機能を使用して、特定の構成をディテクタに適用することもできます。
- セキュリティ・ゾーン
最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーンのリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureはセキュリティ・ゾーン・レシピのポリシーに対する操作を検証し、ポリシーに違反する操作を拒否します。
注意事項
Oracle Exadata Database Serviceを使用してオンプレミス・データベースをOracle Cloudにデプロイする場合は、次の点を考慮してください。
- ゼロ・ダウンタイム移行(ZDM)
ZDMはオンプレミスでもクラウドでも実行できます。ZDMは、様々なターゲットに移行するオンプレミス・データベースをサポートしています。
- Oracle Base Database Service
- 専用インフラストラクチャ上のOracle Exadata Database Service
- Oracle Exadata Database Service Cloud at Customer
- Oracle Exadataオンプレミス
- Oracle Autonomous Database
- Oracle Autonomous Transaction Processing (専用/共有)
- Oracle Autonomous Data Warehouse (専用/共有)
- ZDMおよびOracle Cloud Infrastructureデータベース移行サービス(DMS)
ZDMとDMSの主な違いは次のとおりです。
-
ZDMは、ほとんどのメソッド/ソース/ターゲットをサポートするメイン・エンジンとして機能し、コマンドライン・インタフェース(CLI)に基づいています。
-
DMSはカバーの下にあるZDMを使用し、OCIネイティブ・データベース・サービスへのユーザー・インタフェースを使用した論理オフライン/オンライン移行を可能にします。
-
データベースの移行は、データベースをOracle Cloud Infrastructure (OCI)に移行するための高パフォーマンスのセルフサービス・エクスペリエンスを提供する、完全に管理されたサービスです。
-
OCIデータベース移行は、テナンシおよびリソースとは別の管理対象クラウド・サービスとして実行されます。このサービスは、データベース移行サービス・テナンシのマルチテナント・サービスとして動作し、プライベート・エンドポイント(PE)を使用してリソースと通信します。PEはデータベース移行によって管理されます。
-
- データベース・サイズ
ZDMまたはDMSのサイズ制限はありません。理論上の制限は、オペレーティング・システムが持つことができるOracle Databaseの最大サイズになります。データファイルの最大数とデータファイルの最大サイズは、オペレーティング・システムによって異なります。
Autonomous Databaseへの小さい(<1)テラバイトのデータベース移行の場合、停止時間の要件に応じて、ZDM論理オフラインまたはオンラインの方法を使用できます。論理オンライン・オプションに必要なダウンタイムは数分のみですが、論理オフライン・オプションにはデータベースのサイズに応じて数時間の停止時間があります。
400TB以上のオンプレミス・データベース・サイズの場合、移行はオンプレミスからOracle Exadata Database Service Cloud at Customer (お客様のデータ・センターにもあります)になります。ZDM物理オンライン移行を使用して、Data Guardを使用して、ダウンタイムを低く抑え、移行中のリスクを削減します。ただし、ソース・データベースとターゲット・データベースは、同じバージョンである必要があります。実行中のアップグレードを下位バージョンから上位バージョンにする場合は、ZDM論理オンライン方法を使用します。オフライン・メソッドでは、ビジネスに許容できないダウンタイムが大きくなります。
- Data GuardおよびActive Data Guard
Data Guard (DG)とActive Data Guard (ADG)の両方には、1つ以上のスタンバイ・データベースを作成、保守、管理および監視し、プライマリOracleデータベースが障害やデータ破損に耐えられるようにするための包括的な一連のサービスが用意されています。スタンバイ・データベースは、本番データベースのコピーとして保持されます。ただし、ADGでは、プライマリ・データベースとの同期を維持しながら、スタンバイ・データベースを読取り専用(レポート目的など)でオープンできます。DGでは、同期プロセスを一時停止して、スタンバイ・データベースを読取り専用モードでオープンする必要があります。
- Exadataの仮想化
仮想マシンでExadataを仮想化することも、ベア・メタル・インストールを実行することもできます。オプションのアーキテクチャは大きく異なる場合があります。ベア・メタル・インストールでは、Exadataマシンを物理的にパーティション化しないかぎり、Exadataマシン全体に対して1つのOracleクラスタがあります。仮想化されたExadataマシンでは、デプロイされるVMクラスタの数に応じて、1つの管理ドメイン(dom0)と少なくとも1つのユーザー・ドメイン(domU)があります。
- Real Application Testing(RAT)
「詳細の参照」セクションのリンクを参照してください。