Directory Server Enterprise Edition の管理は、5.x バージョンの Directory Server から大幅に変更されています。これらの変更は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』で詳細に説明されています。
この章では、これらの変更の概要を示したあと、配備の計画段階で行う必要のある管理上の決定について説明します。
Directory Server Enterprise Edition では、管理者がインスタンスの作成や管理をより細かく制御できるようになりました。この制御は、2 つの新しいコマンド dsadm と dsconf を使用して実現されます。これらのコマンドは、以前の directoryserver コマンドで提供されていたすべての機能に加え、追加の機能を提供します。
dsadm コマンドを使用すると、管理者は Directory Server インスタンスを作成、起動、および停止できます。このコマンドは、Directory Server インスタンスへのファイルシステムアクセスが必要なすべての操作を行います。このコマンドは、インスタンスをホストするマシン上で実行してください。インスタンスへの LDAP アクセスまたはエージェントへのアクセスが必要な操作は実行しません。
新しい管理モデルでは、Directory Server インスタンスの 「ServerRoot」への関連付けはなくなりました。各 Directory Server インスタンスは、通常のスタンドアロンディレクトリと同じ方法で操作できるスタンドアロンディレクトリです。
dsconf は、cn=config への書き込みアクセスが必要な管理操作を行います。dsconf コマンドは、LDAP クライアントです。アクティブな Directory Server インスタンス上でのみ実行できます。このコマンドはリモートから実行することができ、それによって、管理者は複数のインスタンスを単一のリモートマシンから設定できます。
Directory Proxy Server は、dpadm と dpconf という、2 つの類似のコマンドを提供しています。dpadm コマンドを使用すると、管理者は Directory Proxy Server インスタンスを作成、起動、および停止できます。dpconf コマンドを使用すると、管理者は LDAP を使用して Directory Proxy Server を設定し、Directory Proxy Server を介して Directory Server 構成にアクセスできます。
これらのコマンド行ユーティリティーに加えて、Directory Server Enterprise Edition は Java Web コンソールにも統合されています。このコンソールを使用すると、Directory Server Enterprise Edition やその他の Sun 製品を集中管理のユーザーインタフェースから管理できます。Directory Service Control Center (DSCC) は、Directory Server と Directory Proxy Server の管理専用に用意された、Java Web コンソールのサービスです。DSCC は、コマンド行ユーティリティーと同じ機能のほか、複数のサーバーを一度に設定できるウィザードを提供しています。DSCC はまた、レプリケーショントポロジをグラフィカルに監視できる、レプリケーショントポロジの描画ツールも提供します。このツールでは、個々のマスター、ハブ、コンシューマや、それらの間のレプリケーションアグリーメントがリアルタイムに表示されるため、レプリケーションの監視が簡略化されます。
前の節で説明した Directory Server Enterprise Edition の管理モデルでは、トポロジ内の任意の Directory Server または Directory Proxy Server のリモート管理を行うこともできます。サーバーは、コマンド行ユーティリティーと Java Web コンソールの両方を使用して、リモートから管理できます。
dsadm および dpadm ユーティリティーはリモートからは実行できません。これらのユーティリティーは、管理対象のサーバーインスタンスと同じマシンにインストールして実行してください。dsadm と dpadm で提供される機能の詳細については、dsadm(1M) と dpadm(1M) のマニュアルページを参照してください。
dsconf および dpconf ユーティリティーは、リモートから実行できます。dsconf と dpconf で提供される機能の詳細については、dsconf(1M) と dpconf(1M) のマニュアルページを参照してください。
次の図は、新しい管理モデルによるリモート管理の容易性を示しています。この図は、コンソールコマンドや設定コマンドを Directory Server および Directory Proxy Server インスタンスからリモートにインストールして実行できることを示しています。管理コマンドは、これらのインスタンスに対してローカルに実行する必要があります。
データ破壊やデータ損失をともなう障害の状況では、データの最新のバックアップを保有していることが不可欠です。できるだけ、ほかのサーバーからのサーバーの再初期化は避けてください。データのバックアップ方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 9 章「Directory Server のバックアップと復元」を参照してください。
ここでは、バックアップと復元の戦略を計画する上で考慮すべき事項の概要について説明します。
バックアップ戦略を設計するときは、次の高レベルの原則を適用します。
バックアップする必要のあるデータを特定します。
Directory Server Enterprise Edition の場合、このデータには次のものが含まれます。
共有されているバイナリとプラグイン
証明書データベースのファイル
設定ファイル
ログファイルと更新履歴ログデータベース
スキーマファイル
ユーザーデータ
バックアップと復元の戦略に、ハードウェア、オペレーティングシステム、およびソフトウェアコンポーネントが含まれている必要があります。
バイナリバックアップまたは LDIF バックアップを保持するかどうかを決定します。
一般には、この両方を保持することをお勧めします。詳細については、「バックアップ方法の選択」および 「復元方法の選択」を参照してください。
バックアップおよび復旧ツール関連の自動化を確立するとともに、自動スクリプトが保守されている必要があります。
この戦略によって、緊急にバックアップからの復元が必要になった場合の不必要な遅延が回避されます。
保持とローテーションの戦略を決定します。
この戦略には、バックアップを実行する頻度と、バックアップを保持する期間が含まれます。バックアップの保持とローテーションを決定する場合は、パージ遅延と、それによる、レプリケートされるトポロジ内のバックアップへの影響に注意してください。サプライヤで変更が発生すると、それらの変更は更新履歴ログに記録されます。更新履歴ログを空にするための方法がないと、そのサイズは、すべての使用可能なディスク容量が更新履歴ログによって消費されるまで増え続けます。デフォルトでは、これらの変更は 7 日ごとに消去されます。この期間をパージ遅延と呼びます。変更が消去されると、その変更をレプリケートすることはできなくなります。そのため、データベースは、少なくともパージ遅延と同じ頻度でバックアップされる必要があります。
単にシステムのバックアップと復旧を実行するのではなく、Directory Server Enterprise Edition で提供されているバックアップおよび復旧ツールを使用します。
Directory Server Enterprise Edition では、バイナリバックアップと、LDIF ファイルへのバックアップという 2 つの方法でデータをバックアップできます。どちらの方法にも利点と制限があるため、効果的なバックアップ戦略を計画するには、それぞれの方法について理解することが役立ちます。
バイナリバックアップは、データベースファイルのコピーを生成するものであり、ファイルシステムレベルで実行されます。バイナリバックアップの出力は、すべてのエントリ、インデックス、更新履歴ログ、トランザクションログを含むバイナリファイルのセットです。バイナリバックアップには、設定データは含まれません。
バイナリバックアップは、次のいずれかのコマンドを使用して実行されます。
dsadm backup はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。
dsconf backup は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。
バイナリバックアップには、次のような利点があります。
すべてのサフィックスを一度にバックアップできる。
LDIF へのバックアップと比較して、バイナリバックアップは格段に高速である。
レプリケーション更新履歴ログがバックアップされる。
バイナリバックアップには、1 つの制限があります。バイナリバックアップからの復元は、「同一の」設定のサーバーだけでしか実行できません。
この制限は次を意味します。
両方のマシンが同じハードウェア、同じオペレーティングシステム (サービスパックやパッチも含まれる) を使用している必要がある。
両方のマシンに同じバージョンの Directory Server (32 ビットまたは 64 ビットのバイナリ形式、サービスパック、パッチレベルも含まれる) がインストールされている必要がある。
両方のサーバーは、同じサフィックスに分岐する同じディレクトリツリーを持つ必要がある。すべてのサフィックスのデータベースファイルをまとめてコピーする必要があり、サフィックスを個別にコピーすることはできない。
両方のサーバーの各サフィックスには同じインデックス (仮想リスト表示 (VLV) インデックスも含まれる) が設定されている必要がある。サフィックスのデータベースファイルの名前は同じである必要がある。
各サーバーに、レプリカとして同じサフィックスが設定されている必要があります。部分レプリケーションが設定されている場合、部分レプリケーションはすべてのマスターサーバーで同じように設定されている必要がある。
どちらのサーバーでも、属性の暗号化は使用できません。
少なくとも、整合性のあるマシンの各セットに対して定期的なバイナリバックアップを実行してください。整合性のあるマシンとは、前述のように同一の設定を持つマシンのことです。
ローカルバックアップからの復元の方が簡単なため、各サーバーでバイナリバックアップを実行してください。
この章の残りの図では、次の略語を使用します。
M = マスターレプリカ |
RA = レプリケーションアグリーメント |
次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 と M3 でバイナリバックアップが行われます。障害が発生した場合は、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。M1 と M2 を M3 のバイナリバックアップから復元することはできません。M3 と M4 を M1 のバイナリバックアップから復元することはできません。
バイナリバックアップのコマンドの使用方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリバックアップ」を参照してください。
LDIF へのバックアップはサフィックスレベルで行われます。LDIF へのバックアップの出力は、サフィックスに含まれているデータのコピーである、フォーマットされた LDIF ファイルです。このため、このプロセスはバイナリバックアップと比較して時間がかかります。
LDIF へのバックアップは、次のいずれかのコマンドを使用して実行されます。
dsadm export はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。
dsconf export は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。
これらのコマンドの実行時に -Q オプションを指定しないかぎり、レプリケーション情報はバックアップされます。
LDIF へのバックアップでは、dse.ldif 設定ファイルはバックアップされません。以前の設定を復元できるようにするには、このファイルを手動でバックアップしてください。
LDIF へのバックアップには、次のような利点があります。
LDIF へのバックアップは、設定に関係なくどのサーバーからも実行できる。
LDIF バックアップからの復元は、設定に関係なくどのサーバーからも実行できる。
LDIF へのバックアップには、1 つの制限があります。迅速なバックアップと復元が必要な状況では、LDIF へのバックアップでは時間がかかり過ぎる可能性があります。
トポロジの単一マスターで、レプリケートされた各サフィックスを LDIF に定期的にバックアップする必要があります。
次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadm export が実行されています。
LDIF へのバックアップのコマンドの使用方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF へのバックアップ」を参照してください。
Directory Server Enterprise Edition では、バイナリ復元と、LDIF ファイルからの復元という 2 つの方法でデータを復元できます。バックアップ方法と同様に、どちらの方法にも利点と制限があります。
バイナリ復元では、データベースレベルでデータがコピーされます。バイナリ復元は、次のいずれかのコマンドを使用して実行されます。
dsadm restore はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。
dsconf restore は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。
バイナリ復元には、次のような利点があります。
すべてのサフィックスを一度に復元できる。
レプリケーション更新履歴ログが復元される。
LDIF ファイルからの復元と比較して、バイナリ復元は格段に高速である。
バイナリ復元には、次のような制限があります。
復元は、同一の設定を持つサーバーでしか実行できない (「バイナリバックアップ」を参照)。バイナリ復元機能を使用したデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリ復元」を参照してください。
データベースが破壊されていることに気付かずにバイナリバックアップを実行した場合は、破壊されたデータベースが復元される危険性がある。バイナリバックアップは、データベースの現在の状態をありのままにコピーします。
マシンの設定が同一であり、実行時間を極力減らすことを一番の目的としている場合は、推奨される復元方法はバイナリ復元になります。
次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。
LDIF ファイルからの復元は、サフィックスレベルで実行されます。このため、このプロセスはバイナリ復元と比較して時間がかかります。LDIF からの復元は、次のいずれかのコマンドを使用して実行できます。
dsadm import はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。
dsconf import は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。
LDIF ファイルからの復元には、次のような利点があります。
このコマンドは、設定に関係なくどのサーバーからも実行できる。
レプリケーショントポロジに関係なく、ディレクトリサービス全体の配備に単一の LDIF ファイルを使用できる。予定されているビジネスニーズに合わせてディレクトリサービスをダイナミックに拡張または縮小する場合に、この機能は特に便利である。
LDIF ファイルからの復元には、1 つの制限があります。迅速な復元が必要な状況では、この方法は時間がかかり過ぎる場合があります。LDIF ファイルからのデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF ファイルからのデータのインポート」を参照してください。
次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadmin import が実行されています。
ロギングは、個別のサーバーレベルで管理および設定されます。ロギングは、デフォルトで有効になっていますが、配備の要件に従って再設定したり無効にしたりすることができます。ロギング方法の設計は、ハードウェア要件の計画に役立ちます。詳細については、「Directory Server のハードウェアサイジング」を参照してください。
ここでは、Directory Server Enterprise Edition のロギング機能について説明します。
トポロジ内の各 Directory Server は、ロギング情報を次の 3 つのファイルに格納します。
トポロジ内の各 Directory Proxy Server は、ロギング情報を次の 2 つのファイルに格納します。
アクセスログ: Directory Proxy Server に接続するクライアントと、要求された操作をリストします。
エラーログ: サーバーエラーメッセージが含まれています。
Directory Server と Directory Proxy Server の両方のログファイルを次の方法で管理できます。
ログファイル作成ポリシーの定義
ログファイル削除ポリシーの定義
ログファイルの手動での作成と削除
ログファイルのアクセス権の定義
ログファイル作成ポリシーを使用すると、現在のログを定期的に保存し、新しいログファイルを開始することができます。ログファイル作成ポリシーは、Directory Control Center からか、またはコマンド行ユーティリティーを使用して Directory Server と Directory Proxy Server に対して定義できます。
ログファイル作成ポリシーを定義する場合は、次の点を考慮してください。
保持するログの個数
このログ数に達すると、新しいログを作成する前に、フォルダ内のもっとも古いログファイルが削除されます。この値が 1 に設定されていると、ログはローテーションされず、かぎりなく増大します。
各ログファイルの最大サイズ (M バイト単位)
ログファイルがこの最大サイズか、または次の項目で定義される最長有効期間に達すると、そのファイルは保存され、新しいログファイルへのロギングが開始されます。
現在のログファイルを保存する頻度
デフォルトは毎日です。
ログファイルをローテーションする 1 日の中の時間帯
時間に基づいてローテーションすると、各ログファイルが同じ期間をカバーするようになるため、ログの分析や傾向判断などの処理が容易になります。
ログファイルのローテーションを、条件の組み合わせに基づいて行うこともできます。たとえば、ファイルサイズが 10M バイトより大きい場合に「のみ」、23 時 30 分にログをローテーションするように指定できます。
ログファイル作成ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。
ログファイル削除ポリシーを使用すると、保存された古いログを自動的に削除できます。ログファイル削除ポリシーは、Directory Service Control Center からか、またはコマンド行ユーティリティーを使用して Directory Server と Directory Proxy Server に対して定義できます。ログファイル削除ポリシーは、ログファイル作成ポリシーが定義されていないかぎり適用されません。ログファイルが 1 つしかない場合、ログファイル削除は機能しません。サーバーは、ログのローテーションの時点でログファイル削除ポリシーを評価および適用します。
ログファイル削除ポリシーを定義する場合は、次の点を考慮してください。
保存される合計のログの最大サイズ
この最大サイズに達すると、保存されているもっとも古いログが自動的に削除されます。
使用可能にする最小のディスク空き容量
ディスク空き容量がこの最小値に達すると、保存されているもっとも古いログが自動的に削除されます。
ログファイルの最長有効期間
ログファイルがこの最長有効期間に達すると、そのログファイルは自動的に削除されます。
ログファイル削除ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。
手動のファイルローテーションや強制されたログローテーションは、Directory Proxy Server には適用されません。
Directory Server に対して自動的な作成および削除のポリシーを定義したくない場合は、ログファイルを手動で作成および削除することができます。さらに、Directory Server には、定義されている作成ポリシーには関係なく、任意のログをただちにローテーションできるタスクが用意されています。この機能は、たとえば、さらに詳細に検証する必要があるイベントが発生した場合に有効なことがあります。この即座のローテーション機能では、サーバーに新しいログファイルが作成されます。これにより、元のログファイルには、今後サーバーからログが追加されない状態となり、そのファイルを検証することができます。
ログを手動でローテーションする方法、およびログのローテーションを強制する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server ログの手動でのローテーション」を参照してください。
5.x バージョンの Directory Server では、ログファイルを読み取れるのは ディレクトリマネージャーだけでした。Directory Server Enterprise Edition では、ログファイルの作成時にアクセス権をサーバー管理者が定義できます。ログファイルのアクセス権を定義する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「Directory Server のログの設定」を参照してください。
配備を成功させるには、効果的な監視とイベント管理の戦略が必要です。この戦略は、監視対象となるイベント、使用するツール、そのイベントが発生した場合に実行するアクションを定義します。発生しがちなイベントに対する計画を立てておけば、サービスの停止やレベル低下の可能性を防止できます。この戦略によって、ディレクトリのサービスの可用性と品質が向上します。
監視戦略を設計するには、次のことを実行します。
適切な監視ツールを選択します。「Directory Server Enterprise Edition で提供される監視ツール」を参照してください。
ディレクトリアーキテクチャー内の、監視対象となる主要な領域を識別します。
これらの領域は一般に、サイジングやチューニングの属性と同じです。「監視領域の特定」を参照してください。
パフォーマンス指標を監視する場合に、イベントまたはアラーム状態を始動する条件を定義します。
この戦略では、パフォーマンスの受容可能レベル、または各パフォーマンス指標に対する処理を定義します。
アラーム状態が発生したときに実行するアクションを決定します。
ここでは、Directory Server Enterprise Edition で使用できる監視ツールや、サーバーアクティビティーの監視に使用できるその他のツールの概要について説明します。
「監視領域の特定」で説明されている監視領域は、これらの 1 つ以上のツールを使用して監視できます。
コマンド行ツール: ディスク使用量などのパフォーマンスを監視するオペレーティングシステムに固有のツール、ディレクトリに格納されているサーバー統計を収集する ldapsearch などの LDAP ツール、サードパーティー製ツール、カスタムシェル、Perl スクリプトが含まれます。
Directory Server および Directory Proxy Server ログ: アクセス、監査、およびエラーログが含まれます。これらのログを手動で監視したり、カスタムスクリプトを使用して解析することで、配備に関連する監視情報を抽出できます。Directory Server Resource Kit には、アクセスログを解析できるログ分析ツール、logconv が用意されています。このログ分析ツールは、利用率統計を抽出し、重要なイベントの発生をカウントします。このツールの詳細については、logconv(1) を参照してください。ログファイルの表示と設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 15 章「Directory Server のログ」を参照してください。
Directory Service Control Center (DSCC): ディレクトリ操作をリアルタイムに監視できるグラフィカルユーザーインタフェースです。DSCC は、リソースの概要、現在のリソース使用状況、接続状態、グローバルデータベースキャッシュ情報など、一般的なサーバー情報を提供します。また、データベースのタイプや状態、エントリキャッシュ統計などの、一般的なデータベース情報も提供します。キャッシュ情報や、データベース内の各インデックスファイルに関連する情報も提供されます。さらに、DSCC には接続と各連鎖サフィックスで実行される操作に関する情報も表示されます。
レプリケーション監視ツール: コマンド行ツール、repldisc、insync、および entrycmp が含まれます。
これらのツールを使用すると、次の操作を実行できます。
マスターレプリカと 1 つまたは複数のコンシューマレプリカとの間の同期状態を監視する
複数の異なるレプリカの間で同じエントリを比較することで、レプリケーションの状態を確認する
完全なレプリケーショントポロジを描写する (これは複雑なディレクトリ配備で特に有用となる)
詳細については、repldisc(1)、insync(1)、および entrycmp(1) を参照してください。
DCC を使用してレプリケーションの状態を監視することもできます。レプリケーションの監視の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「レプリケーションの状態の取得」を参照してください。
SNMP (Simple Network Management Protocol): グローバルネットワーク制御と監視のための標準メカニズムであり、ネットワーク管理者はネットワーク管理作業を一元的に行えます。
SNMP エージェントを使用した監視については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 16 章「Directory Server の監視」を参照してください。
Java ES Monitoring Framework: JMX を介した、パフォーマンスやその他の統計の監視を可能にします。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Server and CMM/JMX」を参照してください。
監視する対象や、その対象をどの程度監視するかは、具体的な配備によって異なります。ただし、一般に、監視戦略には次の要素が含まれます。
リソース使用状況、サーバーの状態、接続情報などの、サーバーアクティビティー
キャッシュ、トランザクション、ロック、ログなどの情報を含む、データベースアクティビティー
使用可能なディスク容量やしきい値情報を含む、ディスクの状態
レプリケーションが実行されているかどうかの状態や、同期の状態を含む、レプリケーションアクティビティー
インデックスを使用しない検索、検索フィルタ、よく使用されるインデックスなど、インデックスの効率性に関する情報
失敗したバインド試行、開いている接続、実行権限を含む、セキュリティーの状態
Directory Server Enterprise Edition の Directory Editor コンポーネントは、Web ブラウザを使用してディレクトリデータを管理できる Java Web アプリケーションです。Directory Editor を使用すると、すべてのユーザーが、クライアントソフトウェアをインストールしなくてもディレクトリデータにリモートアクセスできます。
Directory Editor は、次の機能を提供します。
管理者やエンドユーザーがディレクトリユーザー、グループ、およびコンテナを作成したり編集したりできるようにする。
アプリケーションサーバーや配備されているハードウェアに応じて、複数の並行ユーザーをサポートする。
大規模な企業ディレクトリのインストールをサポートする。
インタフェースのカスタマイズ、ブランド化、および埋め込みを可能にする。
カスタマイズは、Directory Server スキーマに動的に適応します。
直接のプログラミングによるのではなく、フォームの設定によるカスタマイズを可能にする。
クライアントブラウザと Directory Server の間の SSL で暗号化された転送をサポートする。
ロールに基づいて、メニューや機能へのアクセスを制限する。
ロールはスキャンされ、グループ名とマッチングされます。ロールには特定の機能へのアクセス権が与えられます。機能とは、参照、設定、デバッグ、編集、作成、検索などの高レベルのアクションです。
Directory Server 内の既存の ACI に基づいて、データへのアクセスを制限する。Directory Editor に固有の ACI を定義する必要はありません。
仮想リスト表示 (VLV) インデックスに基づいて、大量データをページ化して表示する。
Directory Editor のインストール、設定、および使用の詳細については、Directory Editor マニュアル コレクションを参照してください。