インスタンスの移動
Oracle Integrationインスタンスを移動する方法はいくつかあります。
別のコンパートメントへのインスタンスの移動
Oracle Integrationインスタンスを別のコンパートメントに移動できます。
かわりに、インスタンスを別のリージョンに移動する場合は、別のリージョンまたはストライプへのインスタンスの移動を参照してください。
ノート
インスタンスを別のコンパートメントに移動しても、Oracle Integrationインスタンスへのランタイム・アクセスまたは設計時アクセスには影響しません。ただし、Oracle Cloudコンソールでインスタンスにアクセスできるユーザーが変更される可能性があります。たとえば、ユーザーAにコンパートメント1のみのアイテムを管理する権限があり、インスタンスをコンパートメント2に移動すると、ユーザーAはインスタンスへのアクセスを失います。インスタンスを新しいコンパートメントに移動する前に、インスタンスへのアクセスが必要なすべてのユーザーが、移動後も引き続きインスタンスにアクセスできることを確認してください。
インスタンスを別のコンパートメントに移動しても、Oracle Integrationインスタンスへのランタイム・アクセスまたは設計時アクセスには影響しません。ただし、Oracle Cloudコンソールでインスタンスにアクセスできるユーザーが変更される可能性があります。たとえば、ユーザーAにコンパートメント1のみのアイテムを管理する権限があり、インスタンスをコンパートメント2に移動すると、ユーザーAはインスタンスへのアクセスを失います。インスタンスを新しいコンパートメントに移動する前に、インスタンスへのアクセスが必要なすべてのユーザーが、移動後も引き続きインスタンスにアクセスできることを確認してください。
Oracle Integrationインスタンスを別のコンパートメントに移動するには:
別のリージョンまたはストライプへのインスタンスの移動
Oracle Integrationインスタンスを別のリージョンまたはストライプに移動するには、新しいリージョンまたはストライプにインスタンスを作成し、古いインスタンスから設計時メタデータをエクスポートして新しいインスタンスにインポートします。
かわりに、インスタンスを別のコンパートメントに移動する場合は、別のコンパートメントへのインスタンスの移動を参照してください。
ノート
- You can't move an Oracle Integration instance from one tenancy to another, even if the tenancies are both within the same region, but you can export/import integrations across tenancies with appropriate permissions for object storage or explicit transfer of the export file.
- (インスタンスのクローニングだけでなく)インスタンスを移動する場合、新しいインスタンスが古いインスタンスを置き換えるため、新しいインスタンスのみが使用されるように、古いインスタンスを削除する必要があります。両方のインスタンスを同時にアクティブにすることはできません。
次に、インスタンスを別のリージョンに移動するためのベスト・プラクティスの概要を示します。
| 最適な方法 | 関連文書 |
|---|---|
| 既存のOracle Integrationインスタンスがカスタム・エンドポイントを使用し、すべてのクライアントがカスタム・エンドポイントを使用していることを確認します。 | インスタンスのカスタム・エンドポイントの構成 |
| Oracle Cloud Infrastructure (OCI)ログをバックアップします。設計時メタデータのクローニング時に、監査およびアクティビティ・ストリーム・データはコピーされません。 | OCIドキュメントのシナリオ: オブジェクト・ストレージへのログのアーカイブ |
| 新しいリージョンまたはストライプに新しいインスタンスを作成します。 | Oracle Integrationインスタンスの作成 注意:次のタスクでは、新規インスタンスは空である必要があります。 |
| 古いインスタンスから設計時メタデータをエクスポートし、新しいインスタンスにインポートします。 | Oracle Integration 3での統合の使用のサービス・インスタンス全体の設計時メタデータのクローニング |
| 新しいインスタンスのカスタム・エンドポイントを、古いインスタンスに使用したものと同じホスト名で構成しますが、新しいインスタンスが正常に動作していることを確認するまで、DNS Canonical Name (CNAME)を更新しないでください。 | インスタンスのカスタム・エンドポイントの構成 |
| 古いインスタンスと同じように、新しいインスタンスでユーザー・アクセス、接続性および追加機能が構成されていることを確認します。 | チェックする領域の例として、アップグレード後の手順を使用します: Summary of Post-Upgrade Tasks |
| 統合ロード・テストの実行など、新しいインスタンスで組織の検証タスクを完了します。ただし、重複する処理を回避するために、ポーリングまたはスケジュールを開始しないでください。 | 該当なし |
| 新しいインスタンスの検証が終了し、すべての非ポーリング統合がアクティブ化されたら、カスタム・エンドポイントCNAMEを新しいOracle Integrationインスタンスのホスト名を指すように切り替えます。 | Oracle管理カスタム・エンドポイントの構成後タスク |
| すべてのポーリング統合を非アクティブ化し、古いインスタンスのスケジュールを停止します。 | Oracle Integration 3の統合の使用の統合の非アクティブ化および統合スケジュールの開始および一時停止 |
| ポーリング統合をアクティブ化し、新しいインスタンスでスケジュールを開始します。 | 『Oracle Integration 3との統合の使用』の「統合の有効化」および「統合スケジュールの開始および一時停止」 |
| 古いインスタンスを削除します。 | インスタンスの削除 |
| ファイル・サーバーを使用している場合は、各リージョンおよびホスト名でロード・バランサが必要になることがあります。ロード・バランサは、ファイル・サーバーのポート番号がインスタンス間で一致するという保証がないため、ポート・マッピングを実行します。これは、外部クライアントに標準のSFTPポートをホスト名とともに使用する絶好の機会です。ロード・バランサが各リージョンで設定され、機能していることが確認されたら、トラフィックを新しいファイル・サーバーに移動する準備ができたら、ホスト名を新しいリージョン・ロード・バランサに切り替えることができます。 | 該当なし |