2 設置計画
DIVAnet は一般に複数の DIVA サイトで構成される分散型アプリケーションです。この章では、インストールする DIVAnet サービスおよびインストール場所を判別するために必要な概念について説明します。次に示す 3 つの主要な手順があります。
-
特定のサイトについて、目的のワークフローを実現するために接続すべきサイトについて理解する必要があります。「サイト接続についての理解」を参照してください。
-
システム内の各サイトのリモートアクセス (またはローカルアクセス) を有効にする必要があります。「リモートアクセスのためのサイトの有効化」を参照してください。
-
DIVAnet ワークフローにローカルで接続してワークフローを使用するクライアントアプリケーションがあるサイト上で、ローカルクライアントアクセスを構成する必要があります。「ローカルクライアントアクセスの構成」を参照してください。
サイト接続についての理解
DIVAnet サイトは、1 つの DIVArchive インストール環境 (クラウド内にあってよい) および 1 つ以上の DIVAnet サービスとして定義されます。各サイトには一意のサイト名が割り当てられます。各 DIVAnet サービスは、DIVAnet 構成ファイル内の LocalSitename パラメータによって指定される特定のサイトに属します。複数の DIVAnet サイトを、ローカルクライアントアクセスありまたはなしでそれぞれ構成できます。DIVAnet サイトは互いに通信でき、互いの情報をレプリケートできます。
DIVAnet 接続のもっとも基本的なタイプは、単一の DIVArchive システムの単純な DIVArchive プロキシとして DIVAnet を使用することです。この構成では DIVAnet 直接モードが使用されます。DIVA API 接続の操作を許可または拒否するようにアクセス規則を構成できます。このモードは複数サイトのフェデレーテッドビューを提供せず、(たとえば) サイト間のコピーに使用できません。DIVAnet 直接モードの設定の詳細については、「クライアント API ポートの構成」を参照してください。
複数の DIVA サイトを 1 つの大規模なアーカイブシステムとして実際に扱うためには、DIVAnet サービスを使用して DIVAnet サイトを一緒に接続する必要があります。この章の残りのセクションでは、アーカイブされたコンテンツのフェデレーテッドビューを実現するために DIVAnet を構成する方法について説明します。
DIVAnet は DIVAnet レベルの要求を満たすために、リモートサイトに接続してアセット情報を取得し、リモートサイトのステータスをモニターし、サイトに要求 (たとえば復元要求) を送信できます。この豊富な対話により、DIVAnet は 1 つの大規模なアーカイブシステムとして操作できます。
注記:
一部の DIVAnet 配備では、各サイトをネットワーク内のほかのすべてのサイトに接続しなくてもかまいません。次の図は、ニューヨーク、ロサンゼルス、ダラスの 3 つのサイトによる DIVAnet の典型的な配備例を示しています。この例で、ニューヨークのアプリケーションは、ロサンゼルスとダラスのアセット (およびニューヨークに存在するアセット) を表示してコピーできます。さらに、ロサンゼルスのアプリケーションは、ニューヨークとダラスのアセットを表示してコピーできます。ダラスのサイトで実行中のアプリケーションはありません。
この配備を実現するには、最初にリモートアクセス用のサイトを構成します。ダラスにはサービスを提供するローカルクライアントがないため、このシナリオを実証するにはダラスが絶好のサイトです。ダラスをニューヨークに接続する方法について理解します。次に、ニューヨークとロサンゼルスを調査し、クライアントアクセス用のサイトを構成する方法と、これらを接続する方法について見ていきます。
DIVAnet サービス
DIVAnet サービスは、DIVAnet 配備でコンピューティングタスクの実施を担当するサーバーにインストールされる Windows または Linux のいずれかのサービスです。表2-1 は、使用可能な DIVAnet サービスのサマリーを示しています。
| サービス |
説明 |
|---|---|
|
ClientAdapter |
DIVAnet ClientAdapter サービスは、DIVA API と Web クライアントからの要求を受け入れ、これらの要求を満たすために DIVArchive サイトと DIVAnet データベースと対話します。ローカルクライアント (アプリケーション) アクセスを実装するときに構成されます。これは、プロキシのみの最小限の DIVAnet 配備 (「クライアント API ポートの構成」で説明する DIVAnet 直接モード) でも使用できます。 詳細については、「DIVAnet ClientAdapter サービス」を参照してください。 |
|
ManagerAdapter |
ManagerAdapter サービスは、DIVAnet と Oracle DIVArchive Manager の間の橋渡しとして機能します。DIVA サイト用のリモートアクセスを提供します。すべての DIVAnet サイト (特にアセット情報が同期されるサイト) に対して構成されます。 詳細については、「DIVAnet ManagerAdapter サービス」を参照してください。 |
|
DBSync |
DbSync サービスは、複数の DIVArchive サイトからのアセット情報の同期と、DIVAnet データベース内の情報の格納を担当します。ローカルクライアント (アプリケーション) アクセスを実装するときに構成されます。 詳細については、「DIVAnet DbSync サービス」を参照してください。 |
リモートアクセスのためのサイトの有効化
ほかの DIVAnet システムによるリモートアクセスのための DIVArchive サイトの有効化には、サイトでの ManagerAdapter サービスの設定と、リモートアクセスのための DIVArchive の構成が含まれます。
次の図は、DIVAnet の完全な構成 (リモートアクセスとローカルクライアントアクセス) を備えたニューヨークサイトとリモートアクセスだけが構成されたダラスサイトからなる 2 つのサイトの例を示しています。ダラスサイトでは、1 つの DIVAnet サービス (ManagerAdapter サービス) のみが実行中です。DIVArchive が構成されているため、ほかのサイトと十分にやり取りできます。
DIVAnet ManagerAdapter サービス
ManagerAdapter サービスは、DIVAnet と DIVArchive Manager の間の橋渡しとして機能します。これは、ほかの DIVAnet システムによるリモートアクセスを提供するように構成する必要があります。セキュリティーおよびパフォーマンス上の理由により、ManagerAdapter を DIVArchive Manager と同じシステム上にインストールすることをお勧めします。同様に、ClientAdapter と DIVAnet データベースがまったく異なるサーバー上で同時に実行されることもよくあります。ManagerAdapter は単純な構成ファイルを使用して構成されます。詳細については、第4章を参照してください。
DIVArchive
DIVAnet ワークフローを実現するために必要な構成の多くは、各 DIVArchive サイトで実行されます。このセクションでは、DIVAnet が DIVA と対話する方法と、DIVA 構成の重要性を理解するために必要ないくつかの概念について詳しく説明します。DIVArchive を構成する方法の詳細は、Oracle DIVArchive インストールおよび構成ガイドを参照してください。
オブジェクトとインスタンス
DIVArchive システムでは、アーカイブされたオブジェクトは、オブジェクト名とオブジェクトカテゴリの 2 つのパラメータによって一意に識別されます。カテゴリはオブジェクトの正式名の一部で、名前空間の一種です。たとえば、名前が CLIP01 でカテゴリが MOVIES のオブジェクトは、名前が CLIP01 でカテゴリが COMMERCIALS のものとは異なるオブジェクトです。
DIVAnet はオブジェクト名およびカテゴリを使用して、さまざまなサイトのオブジェクトを関連付けます。
注記:
1 つのサイトのオブジェクトが別のサイトのオブジェクトと同じオブジェクト名およびカテゴリを持つ場合、DIVAnet は両方とも同じオブジェクトだとみなします。DIVAnet を使用してアセットをアーカイブするとき、DIVAnet はすでに別のサイトにアーカイブ済みのアセットと同じ名前 (およびカテゴリ) を持つ新しいアセットを (デフォルトで) 拒否します。ただし、DIVArchive システムに直接発行されたアーカイブは、この方法ではチェックされません。DIVAnet を使用せずにアーカイブを行なった結果、サイト B のオブジェクトの内容が、サイト A の対応するオブジェクトと異なる内容になることがあります。これにより、DIVAnet が間違った内容を復元してしまうおそれもあります。
DIVArchive では、アーカイブされる各オブジェクトは多数のインスタンスを含むことができ、インスタンスは、テープ上またはディスク上のオブジェクトの物理コピーごとに 1 つとなります。各インスタンスにはインスタンス順序番号があります。番号付けはゼロから始まり、オブジェクト内のインスタンスごとに 1 ずつ増分します。したがって、オブジェクト名、カテゴリ、およびインスタンス順序番号を提供することによって、DIVA システム上のインスタンスを一意に識別できます。
DIVAnet は、DIVArchive インスタンス順序番号から派生した、DIVAnet 独自のインスタンス順序番号のセットを割り当てます。この動作が行われるため、各オブジェクトについて、DIVAnet インスタンス順序番号はすべての DIVAnet サイトにわたって一意になります。
ソースと宛先
DIVArchive のソース/宛先には、DIVArchive の外部にあるお客様のサーバーまたはディスクと通信するために必要な情報が含まれています。お客様はこれらのサーバーおよびディスクを介してコンテンツを DIVArchive とやり取りします。
DIVAnet には、ソース/宛先の名前に関する重要な規則があります。
注記:
1 つのサイトのソース/宛先の名前が別のサイトのものと同じ場合、DIVAnet はこれらが同じ物理サーバーとディスク、またはそのいずれかを参照するものと判断します。この規則は DIVAnet システムを設定する上で重要です (詳細については、「復元ワークフロー」を参照してください)。API 経由でソース/宛先を指定可能で、それらが同じ物理サーバー、ディスク、およびパスを指している場合、それらに同じ名前を指定する必要があります。
転送用ソース/宛先の設定
DIVAnet を使用してコンテンツを 1 つのサイトから別のサイトに転送するには、少なくとも 1 つのソース/宛先が両方のサイトからアクセス可能になるように構成します。この共通のソース/宛先は、DIVAnet によって 1 つのサイトから別のサイトにオブジェクトをコピーするために使用されます。両方のサイトのソース/宛先の構成は、次の特徴を持つ必要があります。
-
同じ名前 — すべてのサイトで、同じ物理サーバー、ディスク、ディレクトリを参照するソース/宛先に同じ名前を構成します。
DIVAnet のサイト間マッピングは、同じ場所を指しているが名前が必ずしも同じでないソース/宛先を処理できます。詳細については、「サイト間マッピング」を参照してください。
-
同じ場所 — 2 つのソース/宛先エントリが、サーバー上のディスクのまったく同じ場所 (パス) を指している必要があります。転送のタイプ (たとえば
FTP_STANDARD、DISK) がサイトごとに異なっていたり、構成のルートパスが異なる場合もあります。たとえば、名前が NY_SHOWS であるソース/宛先について、ニューヨークサイトではDISKタイプで、ロサンゼルスサイトではFTPタイプである場合もあります。 -
コード変換または名前変更なし — サイト間コピーに使用されるソース/宛先について、復元時にコード変換するようソース/宛先を構成しないでください。誤ったコンテンツが DIVA サイトにアーカイブされる可能性があります。
-
ソースの削除 — コピーコマンドで使用される各ソース/宛先について、DIVArchive のソース/宛先構成に -allow_delete_on_source オプションを設定します。これにより、コンテンツは DIVA に転送されたあとでサイトから削除されます。このオプションは、DIVA の「Source/Destination」構成パネルのオプションフィールドに指定します。
-
AXF およびチェックサム — DIVArchive の「AXF Genuine Checksums」を有効にすることによって、サイト間コピー (1 つのサイトから別のサイトへのコピー操作) でエンドツーエンドのチェックサム比較を有効化できます。DIVArchive の構成ユーティリティーで、コピーに使用するソース/宛先を選択してから、「AXF Genuine Checksum」オプションを選択します。これを実行したあと、DIVAnet サイト間マッピング AdditionalOptions パラメータに -axf オプションを設定できます。これにより、チェックサム情報をソースサイトで AXF ラッパーに組み込み、ターゲットサイトで再度チェックできます。
DIVArchive 構成ユーティリティーの「Source/Destination」パネルの「Site」パラメータの意味を取り違えないようにしてください。ここでのサイト名は DIVA によってのみ使用され、DIVAnet サイトに対応しません (詳細については、Oracle DIVArchive インストールおよび構成ガイドを参照してください)。
注意:
DIVAnet に接続したときに DIVArchive 構成パラメータの名前 (「Source/Destination」、「Media Names」、「Storage Plans」など) を変更すると、エラーが発生することがあります。メディア (ストレージ媒体) およびストレージ計画
DIVAnet が 1 つの DIVA システムから別の DIVA システムにオブジェクトをコピーするとき、ターゲットサイト上のコピーのアーカイブメディア名およびストレージ計画名を割り当てる際には十分注意する必要があります。各 DIVA システム上のメディア値に関して適切なネーミングポリシーを使用してください。
DIVAnet は各オブジェクトインスタンスを同期するときに DIVA メディア名を記録します。コピー操作でメディア/ストレージ計画を自動的に割り当てるように DIVAnet を構成できます。詳細については、「DIVAnet による選択 (any というメディア)」を参照してください。この機能を構成する方法の 1 つに、ソースオブジェクトと同じストレージ計画名を使用してターゲットサイトにアーカイブする方法があります。これを機能させるには、ターゲット DIVA で適切なストレージ計画を構成する必要があります。または、DIVA メディアマッピングを使用して、ターゲット DIVA サイトでストレージ計画名をメディアまたは別のストレージ計画にすべて変換できます。
Drop Folder Monitor (DFM)
DFM は、新しいコンテンツがないかフォルダをモニターし、新しいコンテンツを DIVArchive にアーカイブします。特定のドロップフォルダに復元することによって、DFM はコンテンツを取り出し、それを異なる DIVA システムにアーカイブできます。
DIVAnet は DFM なしでコピーワークフローを実装できますが、場合によっては DFM が必要であるか、あった方が好ましいことがあります。DFM を一緒に使用せずにコピーするには、DIVAnet RestoreAndArchive 転送方式が使用できます。ただし、DFM を使用した方が適切な状況もあります。DFM を使用する良い候補となるのは、転送に失敗したコンテンツの独自のクリーンアップを実行する自律サイトや、サードパーティー製 WAN アクセラレータが使用されるシステムなどがあります。DFM を転送に使用するには、DIVAnet RestoreAndMonitor サイト間転送方式を使用します。詳細については、「サイト間転送マッピング (ワークフロープロファイル)」を参照してください。
ローカルクライアントアクセスの構成
ローカルクライアントアクセスの構成には、次の構成が含まれます。
-
リモートアクセス用のローカル DIVArchive (「リモートアクセスのためのサイトの有効化」を参照してください)
-
ClientAdapter サービス
-
DbSync サービス
-
DIVAnet データベース
すべての DIVAnet サービスを構成すると、サイトでの完全な DIVAnet ワークフロー処理が可能になります。
次の図で、ニューヨークサイトとロサンゼルスサイトは両方とも完全な DIVAnet ワークフロー処理に対応するように構成されています。ロサンゼルスのアプリケーションは、LA の ClientAdapter に直接接続します。そうすることによって、必要に応じてニューヨークからコンテンツを取得できます。ローカル DIVAnet データベースは、1 つのサイトから別のサイトへの接続が失われている場合でも、サイトをまたぐアセットのグローバルビューを提供します。十分なアクセス権が付与されている場合、LA の DIVAnetUI ユーザーはコンテンツをニューヨークから LA にコピーでき、ニューヨークのコンテンツを削除することもできます。
Customer App 2 がニューヨークの ClientAdapter にリモート接続するように構成することは技術的には可能ですが、この構成の方が多くの場合、優れた可用性、セキュリティー、および監査能力を提供します。多くの場合、パフォーマンスとスケーラビリティーも (特に WAN リンクの信頼性が低いか処理が遅い場合に) 向上します。
DIVAnet ClientAdapter サービス
DIVA API を使用する必要があるか、DIVAnet GUI を使用する必要があるアプリケーションクライアントは、DIVAnet ClientAdapter サービスに接続します。この DIVAnet サービスは、アプリケーションから Web 接続およびソケット接続を受け入れ、要求を処理します。ClientAdapter は、DIVArchive および DIVAnet がインストールされたサイトにローカルのアプリケーションを持つ各サイト上で構成されます。ClientAdapter は ManagerAdapter サービスを介してローカルサイトおよびリモートサイトと通信します。ClientAdapter はソケットモードを使用して DIVArchive Manager に直接接続することもできます。
ClientAdapter サービスは、1 つ (または 2 つ) の構成ファイルを使用して構成されます (詳細については、第4章を参照してください)。
DIVAnet DbSync サービス
DbSync サービスは、複数の DIVArchive サイトからのアセット情報の同期と、DIVAnet データベース内の情報の格納を担当します。DbSync は複数のサイト上の ManagerAdapter サービスとリモート通信し、アーカイブ済みオブジェクト情報を同期します。DbSync は一般的に ClientAdapter と一緒に配備されます。DbSync サービスおよび ClientAdapter は両方とも DIVAnet データベースへの直接アクセスが必要です。
DbSync サービスは、単純な構成ファイルを使用して構成されます (詳細については、第4章を参照してください)。
オブジェクトのクリーンアップ
DIVAnet は、復元する前にリモートサイトからローカルサイトにオブジェクトを一時的にコピーすることによって復元操作を処理する場合があります。この方法により、今後実行されるコンテンツの復元がはるかに高速になります。DIVAnet は復元後にディスクインスタンスを自動的に削除しません。その代わりに、ほかのユーザーがコンテンツを復元する場合に備えてコンテンツを残したままにします。
DIVArchive には、所定のディスク/アレイがいっぱいになったときにコンテンツを自動的にクリーンアップできる、次の 2 つのツールがあります。
-
Oracle DIVArchive Storage Plan Manager (SPM) には、個別の DIVA サイトについてのディスクインスタンスを自動的にクリーンアップできる機能があります。
-
DIVArchive ローカル削除は同様の機能を実行できますが、オブジェクトがほかの DIVA サイトにも存在するかどうかをオプションで確認できます。
DIVArchive はデフォルトでニアラインディスクインスタンスを作成するように構成されているため、オブジェクトのクリーンアップも DIVAnet リモートアクセス専用に構成されている DIVA サイトで実行される必要がある可能性があります。
DIVAnet バージョンの互換性
DIVAnet 2.1 は DIVArchive 7.3.1 以降と相互運用されます。DIVArchive の今後のリリースに組み込まれる機能の一部には、DIVAnet を以降のリリースにアップグレードしないと DIVAnet からアクセスできない可能性があります。
DIVAnet 2.1 の ClientAdapter および DbSync サービスは DIVAnet 2.0 ManagerAdapter と相互運用されますが、例外が 1 つあります。DIVAnet プロキシモード (DIVAnet データベースのない直接モード) では DIVAnet 2.0 ManagerAdapter に接続されません。