レジリエンシのプラン
ビジネスまたは組織に、回復可能なデータ統合のための特定の要件があります。特定の単位で要件を満たす統合アーキテクチャを計画してから、詳細に設計を開始します。
レジリエンシ要件の決定
環境のリジリエンスをどうするかを計算する前に、まずユーザーとビジネスに対してどのようなレジリエンシ方法を定義する必要があります。つまり、統合プロセスの停止に関連するコストは何ですか。
一部の顧客では、数分間の停止が許容され、処理ウィンドウ内で正常に実行されるバッチ・プロセスのみが部分的に遅延されます。他の顧客の場合、停止が数秒であっても、ビジネスに直接影響する財政損失が発生します。
そのために、次の要素を検討することが重要です。
- 環境内で許容できる停止の期間はどれくらいですか。ここでは、停止時のビジネスのコストを定義し、停止時間が経過した場合のコストの概略を示します。
- 使用されるテクノロジと、どのようにして予測されるレベルのサービスに提供できるか。リアルタイムまたはバッチによる方法を使用していますか。あるいは、2つを組み合せますか。処理するデータの量
回復可能なアーキテクチャの定義
回復可能なアーキテクチャを定義するには、エンドツーエンドのデータ統合ソリューションを確認する必要があります。
統合プロセスの場合は、アーキテクチャ(ハードウェアとソフトウェアの両方)の次のコンポーネントを考慮する必要があります。
- ソース・システムのレジリエンシ
- ターゲット・システムのレジリエンシ
- ステージング領域のレジリエンシ(使用されている場合)
- データ統合ツールのレジリエンシ
- オーケストレーションのリジリエンシ(ETLツール以外の場合)
- ネットワークのリジリエンシ(接続の観点と帯域幅の観点の両方から)
また、障害時リカバリおよび高可用性という観点からも要件を考慮する必要があります。このインフラストラクチャがインストールされているデータ・センターを失うとどうなりますか。
Oracle Data Integratorインストールを回復可能にするには、次の要素が必要です。
- エージェントは冗長である必要があります: JEEエージェントは、ロード・バランサによってエージェント間に負荷が分散されるため、レジリエンシを提供するように設計されています。
- Oracle Data Integratorリポジトリは回復可能なシステム上で実行されている必要があります。Oracle RACまたはExadataのインストールは最小要件であるため、ノードの損失は完全なインフラストラクチャの損失を意味しません。Oracle Cloudデプロイメントの場合、Oracle Database Exadata Cloud Serviceは回復可能なソリューションを提供します。
- 外部製品を使用してOracle Data Integratorプロセス(インスタンス用のOracle Integration)を編成する場合、この製品も回復可能であることを確認する必要があります。
障害時リカバリ計画を検討する場合は、前述と同じ要素が必要なため、次の点を確認する必要があります。
- Oracle Data Integratorプロセスの実行を続行できるように、(最近の) Oracle Data IntegratorリポジトリがDRサイトに存在します。
- そのDRサイトで、Oracle Data Integratorエージェントがこのリポジトリにアクセスできるようにしています。
- ソースとターゲット・システムにアクセスできるか、またはソースとターゲット・システムのコピーにアクセスできます。
Oracle Data Integrator専用の場合、検証する必要があるトポロジの要素は次の2つです。
- Oracle Data Integrator作業リポジトリのIPアドレスまたはサーバー名は、Oracle Data Integratorマスター・リポジトリに格納されます。DRサイトに切り替えるときに名前またはIPアドレスが変更された場合は、Oracle Data Integratorを起動する前に、この情報が更新されていることを確認する必要があります。
- ソースとターゲット・システムのIPアドレスまたはサーバー名は、作業リポジトリに格納されています。次の2つの方法があります。
- 各環境の個別のコンテキスト(プライマリおよびDR)を定義し、論理ユニットごとに2つの個別の物理サーバー定義を保持できます。
- または、IPアドレスまたはサーバー名を上書きしてから、DRサイトでOracle Data Integratorを起動します。
- すべての場合において、Oracle Data Integratorリポジトリ内の情報を上書きするSDKを使用するスクリプトには、プライマリ・サイト内の情報をリストアするためのリバース・スクリプトが必要です。
初期ロードと連続ロードの計画
変更内容は、通常の負荷(ほぼリアルタイムまたは日次バッチ)に焦点を当てる前に、ターゲット・システムの初期負荷に対して少し異なるプロセスを設計する必要があります。
これは、予期しない将来の停止から自分を保護する必要がある場合、これらの初期ロード・プロセスを維持および維持することが重要です。次の状況に直面した場合に、初期ロード(または初期初期ロードの一部)を引くことができないようにします。
- メジャーな欠陥は、ロードされたデータ(データなし、ETLでの無効な式など)の妥当性において検出されます。
- 大きな停止は、データが大量に失われるターゲット・システムで発生します。
- なんらかの理由により、統合プロセスが長期間実行に失敗しました。
初期ロードを実行する機能を持つと、新しい環境をインスタンス化することもできます。
また、これらのロード戦略を拡張して、前回の負荷(前月の月-データなど)を再適用できます。この場合、ロードされたデータの部分的なクリーンアップと部分的なロードの組合せが必要になります。