1. オンプレミスOracle WebLogic Serverワークロードをクラウドに移行します
  2. 始める前に

始める前に

リソースおよびアプリケーションの移行を開始する前に、移行オプションを検討し、必要なアプリケーション・データベースをプロビジョニングおよび移行します。

アプリケーション・データベースは、個別のデータベースとして、または単一のデータベース・システムのコンテナ・データベース(CDB)内のプラガブル・データベース(pdb)としてプロビジョニングできます。

Oracle Grid Infrastructure (複数ノードのdbをサポート)またはLogical Volume Managerの両方がサポートされています。

ノート:

ゼロ・ダウンタイム移行(ZDM)などのデータベース移行ツールを使用するには、移行するソース・データベースのSYSパスワードと同じものをターゲット・データベースSYSパスワードにする必要があります。

ワークロードの複雑さと停止時間の要件に応じて、使用できる移行計画が多数あります。

データベースのプロビジョニングの詳細は、このドキュメントの以前の仮想マシン・データベースのプロビジョニングに関する項を参照してください。

ワークロードの移行について

この項では、一般的ないくつかの移行シナリオについて説明します。

次の1つのオプション・セットは、オンプレミスのワークロードをOracle Cloud Infrastructureで新しく作成されたドメインに移行します。

  • WebLogic管理者コンソールを使用してワークロードを手動で移行し、リソースおよび次のいずれかの方法を使用してアプリケーションをデプロイします。
    • WebLogic管理者コンソール
    • JDeveloperデプロイメント・ツール
  • WebLogic Deploy Tool (WLDT)を使用したワークロードの移行。
  • 既存のアプリケーション・デプロイメント・スクリプトを新しいドメインにターゲット指定して、WebLogic Scripting Toolを使用してワークロードを移行します。

別の方法として、プレミアム(WebLogicスクリプト、WebLogicツール・モデル・ファイルなど)にドメインをデプロイするために使用するWebLogicサーバー・ツールを更新し、Oracle Cloud Infrastructureにターゲット指定して新しいドメインを作成し、アプリケーションを再デプロイします。

Oracle Cloud InfrastructureへのOracle Databasesの移行

OracleまたはOracle以外のデータベースをオンプレミス・データ・センターからOracle Cloud Infrastructureに移行する前に、次の考慮事項、前提条件および評価プロセスを確認します。

考慮事項

この項は、オンプレミスOracle DatabasesからOracle Cloud Infrastructureへの移行に適用されます。Oracle Cloud Infrastructureには、前の項でリストしたデータベース・プラットフォームが含まれています。移行の取組みを開始する前に、個々のデータベース・ワークロード、制限、および依存関係を理解します。

すべてのOracle Databaseの移行には、検出フェーズと計画フェーズが必要です。このフェーズの主なディスカッションには、次の質問が含まれている必要があります。これらの質問に対する回答は、データベースのグループ化、移行するデータベースの数、および移行の全体的な労力を判断するために役立ちます。
  • このデータベースの現行バージョンはどのバージョンですか。
  • このバージョンのデータベースをいくつ移行しますか。
  • 特定の事業分野(LOB)に関連付けられているデータベースはいくつありますか。
  • Linux以外のプラットフォームのデータベースがあるか。つまり、クロスエンディアン移行が行われますか。
  • 一緒に移行する必要がある依存データベースがありますか。
  • 移行するサード・パーティ・データベース(Oracle以外)やバージョン(SQL Server 2016など)はありますか。
  • テスト・データベースおよび開発データベースの場合、すべてのコピーを移行しますか、それともマスター・コピーのみを使用しますか。
  • データ・セットのサイズ(GB/TB単位のデータ自体の合計ディスク領域および領域)はどれくらいですか。
  • Oracle Cloudへのネットワーク接続にFastConnectまたはVPNを使用しますか。データベースの帯域幅とサイズを設定すると、主に移行ソリューションが実行されます。

移行オプション

オンプレミスからOracle Cloud InfrastructureにOracle Databasesを移行する方法は数多くあります。各方法は、ビジネス・リカバリ・ポイント目標(RPO )、リカバリ時間目標(RTO )、および全体的な可用性サービス・レベル合意(SLA)によって異なります。移行管理者は、これらのビジネス基本契約を適切な方法で評価およびマップする必要があります。

Oracle Maximum Availability Architecture (MAA)は、特にこれらのオプションとメソッドに対処します。次の表で、これらについて簡単に説明します。

解決策 複雑なパスワード検証 移行の粒度 移行タイプ(物理または論理) 全体的なデプロイメント作業量 移行モデル キー移行ユース・ケース
Data Pumpの従来型のエクスポートおよびインポート 低 中 論理 高 オンライン/時点
  • 小規模データベース
  • スキーマのサブセット化
Data Pump完全トランスポータブル 中 低 物理 中 オンライン/連続

エクスポート時にはソースが読取り専用である必要があります

 Endiannessが同じデータベース全体(ソースOracle Databaseバージョン11.2.0.3が必要)
Data Pumpトランスポータブル表領域 中 低 物理 中 オンライン/連続 スキーマ表領域のセット(ソースOracle Databaseバージョン11.2.0.3が必要)
SQL*Loader 低 高 論理 高 オフライン 特定の表またはスキーマの移行
GoldenGate 高 高 論理 高 オフライン/連続
  • スキーマ・サブセット化
  • 論理変換
RMANのバックアップおよびリストア 低 低 物理 低 オフライン/連続 全データベースまたは一連の表領域
Data Guard 低 低 物理 低 オンライン/連続 停止時間がゼロまたはほぼゼロの全データベース

PDBのリモート・クローニング

リモート・クローニング

PDBの再配置

PDBの移行

 低 低 物理 低 オンライン/連続
  • 既存の12 c PDBからPDBへの移行
  • リモート・クローニングは非CDBにできます

ノート:

多くのソリューションを組み合せて、最も効率的な移行戦略を作成できます。パッケージ・アプリケーションの中には、移行でサポートされるツールに制限があるものもあります。

サイズ設定および配置の計画

ソース移行の作業の一部として、データベースが容量およびパフォーマンスの要件を満たしていることを確認するために、適切なサイズ設定および計画の実施が必要です。

ノート:

データベースとVMの容量のサイズ変更作業は、オンプレミスの場合と同じです。
この計画の結果は、ターゲット・データベース構成およびVM形状の定義に役立ちます。
  • ワークロードのパフォーマンス要件
    • トランザクション数/秒
    • ユーザー接続数
    • 将来のワークロード変更が予期されます
  • 容量要件
    • vCPU
    • メモリー
    • 記憶域およびIO容量
    • 将来の増加
  • 管理性の要件
    • Oracle Cloud Infrastructureネイティブ・サービスおよびアクセシビリティ
    • モニタリング・ツール
    • バックアップ・ソリューション
  • スケーラビリティ機能
    • データベース・スケール
    • VMスケール
    • クラスタ・スケール
  • 可用性の要件
    • Oracleの高可用性ソリューション
    • vMotion、DRS
  • アプリケーション要件
    • オンプレミス・コンポーネント間の依存関係
    • アプリケーションとOracle Cloud Infrastructureサービス間のネットワーク・フロー

合理化、標準化および連結

移行作業の一部として、移行チームがこの商談を使用してデータベース・バージョンを標準化し、適切な場合にデータベース・システムを連結することをお薦めします。Oracle Database 19 cは、長期サポート・リリースを提供するため、最小限の標準化されたデータベース・バージョンである必要があります。

統合は、組織が運営の効率を高めるために追跡している主要な戦略の1つです。統合により、組織ではITリソースの利用率を向上させることができ、同じ結果を得るために必要なリソースが少なくなるためコストが削減されます。監視、管理および保守する必要があるコンポーネントやオブジェクトの数が減少するため、運用コストも削減されます。

Dbaおよび管理者は、できるかぎり多くのデータベースを統合できる最良の機会を探し出すようにしてください。Oracle 19 cでは、最大3つのプラガブル・データベース(PDB)でOracleマルチテナント・オプションを使用できます。これにより、スケーリングの大規模さとより高い統合密度をアプリケーションやデータベースの近代化で実現できます。したがって、デプロイメントのコンテナ・データベース(CDB)・モデルに適合するデータベースを判別する必要があります。

連結とともに、分離管理も検討します。分離要件は、可能な連結の方法または程度に影響を与える場合があります。システムが要求する分離レベルによって、複数のPdbを1つのデータベースで統合するか、単一のプラットフォームで複数のデータベースをホストするか、または両方のアプローチの組合せを一部使用するかが決まります。分離は、障害、リソース、セキュリティ、操作の4つの領域に分類できます。各クラウド・モデルは、OSまたはデータベースの組込み機能を使用して、少し分離を処理しますが、多くの場合、高度な機能または製品と組み合せて、完全なソリューションを提供し、そのリスクで始まる始まることができます。