インスタンスの移動
Oracle Integrationインスタンスを移動する方法はいくつかあります。
別のコンパートメントへのインスタンスの移動
Oracle Integrationインスタンスを別のコンパートメントに移動できます。
かわりにインスタンスを別のリージョンに移動する場合は、別のリージョンまたはストライプへのインスタンスの移動を参照してください。
ノート:
インスタンスを別のコンパートメントに移動しても、Oracle Integrationインスタンスへのランタイム・アクセスまたは設計時アクセスには影響しません。 ただし、Oracle Cloudコンソールでインスタンスへのアクセス権を持つユーザーが変更される可能性があります。 たとえば、ユーザーAにコンパートメント1のみのアイテムを管理する権限があり、インスタンスをコンパートメント2に移動すると、ユーザーAはインスタンスへのアクセスを失います。 インスタンスを新しいコンパートメントに移動する前に、インスタンスへのアクセスを必要とするすべてのユーザーが、移動後もそのインスタンスにアクセスできるようにしてください。Oracle Integrationインスタンスを別のコンパートメントに移動するには:
- インスタンスは、Oracle Integrationインスタンスのリストから、またはインスタンスの詳細を表示しながら移動できます:
- 「統合インスタンス」ページ(Oracle Integrationインスタンスのリスト)から、移動するインスタンスの右にインスタンスを移動するには、
をクリックし、「移動」をクリックします。
- インスタンスの詳細ページからインスタンスを移動するには、移動するインスタンスを表示しながら、「アクション」をクリックし、「移動」をクリックします。
- 「統合インスタンス」ページ(Oracle Integrationインスタンスのリスト)から、移動するインスタンスの右にインスタンスを移動するには、
別のリージョンまたはストライプへのインスタンスの移動
Oracle Integrationインスタンスを別のリージョンまたはストライプに移動するには、新しいリージョンまたはストライプにインスタンスを作成し、古いインスタンスから設計時メタデータをエクスポートして新しいインスタンスにインポートします。
かわりに、インスタンスを別のcompartmentに移動する場合は、「別のコンパートメントへのインスタンスの移動」を参照してください。
ノート:
- テナンシが同じリージョン内にある場合でも、Oracle Integrationインスタンスをあるテナンシから別のテナンシに移動することはできませんが、オブジェクト・ストレージまたはエクスポート・ファイルの明示的な転送に対する適切な権限を持つテナンシ間で統合をエクスポート/インポートできます。
- (インスタンスをクローニングするだけでなく)インスタンスを移動する場合、新しいインスタンスが古いインスタンスを置き換えるときは、新しいインスタンスのみが使用されるように古いインスタンスを削除する必要があります。 両方のインスタンスを同時にアクティブにすることはできません。
インスタンスを別のリージョンに移動するためのベスト・プラクティスの概要を次に示します。
| 最適な方法 | 関連ドキュメント |
|---|---|
| 既存のOracle Integrationインスタンスがカスタム・エンドポイントを使用し、すべてのクライアントがカスタム・エンドポイントを使用していることを確認します。 | インスタンスのカスタム・エンドポイントの構成 |
| Oracle Cloud Infrastructure (OCI)ログをバックアップします。 設計時メタデータのクローニング時には、監査およびアクティビティ・ストリームのデータはコピーされません。 | OCIドキュメントのシナリオ: オブジェクト・ストレージへのログのアーカイブ |
| 新しいリージョンまたはストライプに新しいインスタンスを作成します。 | Oracle Integrationインスタンスの作成 ノート:次のタスクでは、新しいインスタンスを空にする必要があります。 |
| 設計時メタデータを古いインスタンスからエクスポートし、新しいインスタンスにインポートします。 | 『Oracle Integration 3での統合の使用』のサービス・インスタンス全体の設計時メタデータのクローニング |
| 古いインスタンスに使用したものと同じホスト名で新しいインスタンスのカスタム・エンドポイントを構成しますが、新しいインスタンスが正しく動作していることを確認するまで、DNS Canonical Name (CNAME)を更新しないでください。 | インスタンスのカスタム・エンドポイントの構成 |
| ユーザー・アクセス、接続性および追加機能が、古いインスタンスと同じように新しいインスタンスで構成されていることを確認します。 | アップグレード後のタスクのサマリーを確認する領域の例として、アップグレード後の手順を使用します。 |
| 統合負荷テストの実行など、新しいインスタンスで組織の検証タスクを完了します。 ただし、重複処理を回避するためにポーリングまたはスケジュールを開始しないでください。 | 該当なし |
| 新しいインスタンスの検証が完了し、すべての非ポーリング統合がアクティブになったら、カスタム・エンドポイントCNAMEを新しいOracle Integrationインスタンスのホスト名を指すように切り替えます。 | Oracle管理のカスタム・エンドポイントの構成後タスク |
| すべてのポーリング統合を非アクティブ化し、古いインスタンスのスケジュールを停止します。 | 『Oracle Integration 3での統合の使用』の統合の非アクティブ化および統合スケジュールの開始および一時停止 |
| ポーリング統合をアクティブ化し、新しいインスタンスでスケジュールを開始します。 | Oracle Integration 3での統合の使用の統合のアクティブ化および統合スケジュールの開始および一時停止 |
| 古いインスタンスを削除します。 | インスタンスの削除 |
| ファイル・サーバーを使用している場合は、各リージョンおよびホスト名にロード・バランサが必要になる可能性があります。 ロード・バランサは、ファイル・サーバーのポート番号がインスタンス間で一致することは保証されていないため、ポート・マッピングを実行します。 これは、外部クライアントに標準のSFTPポートとホスト名を使用する優れた機会です。 ロード・バランサが各リージョンで設定され、動作していることが確認されたら、トラフィックを新しいファイル・サーバーに移動する準備ができたら、ホスト名を新しいリージョン・ロード・バランサに切り替えることができます。 | 該当なし |