このトピックでは、データベース構成ノードについて説明します。次のデータベース構成ノードは、NetWitnessコア データベースの、詳細なデータベース構成アイテムです。これらの構成アイテムは頻繁には変更されません。
packet.dir , meta.dir , session.dir
これは各データベースのプライマリ構成エントリーです（Hot階層とも呼ばれます）。ファイル システム内で個々のデータベースの格納先を制御します。この構成エントリーでは、複雑な構文も認識して多数のディレクトリを格納場所に指定できます。
構成の構文：
config-value = directory, { ";" , directory } ; directory = path, [ ( "=" | "==" ) , size ] ; path = ? linux filesystem path ? ; size = number size_unit ; size_unit = "t" | "TB" | "g" | "GB" | "m" | "MB" ; number = ? decimal number ? ; 例：
/var/lib/netwitness/decoder/packetdb=10 t;/var/lib/netwitness/decoder0/packetdb=20.5 t サイズ値はオプションです。サイズを指定した場合、その場所に格納されたファイルの合計サイズが設定した値に達すると、データベースがロールオーバーされます。サイズを指定しない場合、データベースは自動的にロールオーバーされませんが、他のメカニズムを使用してサイズを管理することは可能です。
= または == の使用は重要です。データベースのデフォルトの動作では、コア サービスの開始時に指定したディレクトリが自動的に作成されます。ただし、この動作は == 構文を使用して上書きすることができます。 == を使用すると、サービスではディレクトリが作成されません。サービスの開始時にディレクトリが存在しない場合、サービスの開始処理が正常に行われません。この場合、ホストの起動時に見つからなかったファイル システムまたはアンマウントされたファイル システムに対してサービスが復元されます。
ディレクトリのサイズを使用中に変更する場合、変更後のサイズが変更前よりも大きければ、そのサイズがすぐに適用されます。サイズを縮小する場合、変更後のサイズが元のサイズよりも10％以上小さいと変更は無視されます。こうすることで、誤入力による大量のデータ消失を防ぎます。たとえば、パケット データベースが 12 TB に構成されていたときに、誤って 12 GB と入力されると、サイズを12 GBに縮小するために、そのデータベースから11 TBを超えるデータが削除されることになります。そうならないように、このデータベースは 12 GB の設定を無視して、警告をログに記録するため、エラーをすばやく見つけることができます。もちろん、指定したサイズが実際に適切で、元のサイズよりも10%以上小さいサイズへの変更の場合は、サービスを再起動して変更を適用します。バックアップが開始されると、サイズが適切であると見なし、最も古いデータからロールアウトして、新しいサイズに到達するまでデータベースのサイズを調整します。実際にサービスを再起動せずにサイズを10％以上縮小する場合は、10％未満の変更を複数回にわたって実施しながらサイズを縮小する必要があります。データベースのサイズは、最後の書き込み対象のファイルがクローズしたときに合計サイズが調節されるため、データベースのサイズがいつ変更されたかを把握するには、サービス ログを参照する必要があります。
新しいディレクトリが追加された場合、またはディレクトリが削除された場合（セミコロン区切り）、サービスを再起動するまで変更は反映されません。
packet.dir.warm , meta.dir.warm , session.dir.warm
これらの設定はオプションです。ArchiverのWarm階層のストレージで使用されます。デフォルトでは、これらの設定は空白のままで使用されません。これらのパラメータを構成する場合、記述する形式と動作は、 packet.dir 、 meta.dir 、 session.dir と同じです（前述の「 packet.dir 、 meta.dir 、 session.dir 」を参照してください）。これらのパラメータを構成した場合、Hot階層に使用可能なスペースがないと、Hot階層にある最も古いファイルがWarm階層に移動します。
packet.dir.cold , meta.dir.cold , session.dir.cold
これらの設定はオプションです。Hot階層またはWarm階層のストレージ システムからCold階層の指定したディレクトリにファイルを移動する場合に使用します。これらの設定は単なるディレクトリ設定であるため、サイズの指定子はありません。ただし、定義済みのパス名にはいくつか特殊な書式指定子があります。その指定子を使用して、ディレクトリ内のデータの日付をディレクトリ名に指定することができます。
%y = The year of the data being moved to the cold tier %m = The month of the data being moved to the cold tier %d = The day of the data being moved to the cold tier %h = The hour of the data being moved to the cold tier %##r = A block of time within a day. So %12r would create two blocks, 00 and 01\. 00 for all data in the AM, 01 for all PM data 設定の例：
packet.dir.cold = /var/lib/netwitness/archiver/database1/alldata/cold-storage-%y-%m-%d-%8r この設定では、ログ データベース ファイルはColdストレージに移動されることになりますが、作成されたのが 2014-03-02 15:00:00 である場合、Cold階層の次のようなディレクトリに移動されます。
/var/lib/netwitness/archiver/database1/alldata/cold-storage-2014-03-02-01 最後の数値 01 については、もう少し説明が必要です。 %8r 指定子により、1日の時間が3等分（24 / 8 = 3）されます。最初の8時間（午前0時～8時）はブロック 00 となります。次の8時間（午前8時～午後4時）はブロック 01 に割り当てられます。Coldストレージに移動されるデータは午後3時に作成されているため、ブロック 01 に分類されます。 %r 形式の指定子は、1日（ %d ）と1時間（ %h ）の間の任意の間隔でファイルをバックアップするときに役立ちます。Cold階層のストレージ ディレクトリは、移動されるデータによってオン デマンドで作成され、書式指定子でディレクトリが定義されます。
データのパスに日付を追加する機能は、バックアップとリストアのために追加された便利な機能で、パス内のデータと日付を結びつけることができます。
packet.file.size , meta.file.size , session.file.size
これらは各データベースで作成されたファイルのサイズを制御します。デフォルト値でも十分に機能するため、通常はこれらの値を変更する必要はありません。これらの設定は、後続のファイルにすぐに反映されます。
packet.files , meta.files , session.files
これらの設定は、データベースで同時にオープンしておけるファイルの数を制御します。この値を大きくするとパフォーマンスを向上できますが、サービスがオープンのままにしておけるファイル数はオペレーティング システムによって制限されています。この制限値を超えるとエラーがレポートされ、サービスの機能が停止します。この設定はすぐに反映されます。
NetWitness Suite 10.6以降では、packet.files、meta.files、session.filesのデフォルト値は auto です。次の条件に基づいて、開いているファイルの数はサービスによって管理されます。
- コレクション数
- システム メモリ容量
auto に設定されている場合、数値は動的であり、数値に変更があったときは、ログで確認することができます。RSAでは、NetWitness Suite 10.6の場合、この値を auto に設定することを推奨します。特定の数値に変更しないでください。
packet.free.space.min , meta.free.space.min , session.free.space.min
この設定は、packet.dir、meta.dir、session.dirの各ディレクトリで指定したパスの最小空き領域を確保します。この設定は、データベース領域の空き領域不足を回避するために使用します。この設定はすぐに反映されます。
packet.index.fidelity , meta.index.fidelity
この設定は、パケットIDの場所とメタIDの場所にインデックスを付ける頻度を制御します。この設定を大きくすると、各パケットまたはメタのnwindexファイルで必要なスペースを減らすことができますが、個々のパケットまたはメタ アイテムを特定する速度は低下します。この設定はすぐに反映されます。
セッション データベースの場合、インデックス ファイルが生成されないため、fidelity設定はありません。
packet.integrity.flush , meta.integrity.flush , session.integrity.flush
この設定は、ファイルの書き込みが終了したときに、ファイル システムでデータベースの同期を実行するかどうかを制御します。デフォルト値は sync です。この場合、ファイルがクローズしたときに、データがストレージに書き込まれるため、大幅な遅延が発生します。より高い書き込みレートを（特にDecoderで）維持するには、この値を normal に設定する必要があります。この設定は、新しいファイルが作成されると反映されます。そのため、この値を normal に変更しただけでは、少なくとも1回以上の同期が発生することになります。
パケット ドロップが発生しているような状況で、packet.integrity.flushが sync に設定されていた場合には、 normal に設定して、監視してください。セッションとメタのフラッシュ設定は sync で保持します。それでもパケット ドロップの問題が解決しない場合は、3つの設定をすべて normal にして、監視します。
packet.write.block.size , meta.write.block.size , session.write.block.size
ブロック長は、各データベース ファイル内で一度に割り当てるデータ量を表します。ブロック長が大きいと、スループットと圧縮率が大きくなり、データベースからアイテムを順次取得する速度が向上します。ただし、ブロック長を大きくすると、圧縮されたパケットとメタのアイテムをランダムに読み取る速度が低下するというデメリットがあります。この設定はすぐに反映されます。
packet.compression , meta.compression
これらのパラメータでは、データベースでデータを圧縮するかどうかを制御します。圧縮により、各データベースに必要なストレージ領域は減少しますが、アイテムをデータベースに書き込む速度と、アイテムをデータベースから取得する速度が大幅に低下するというデメリットがあります。この設定は、新しいファイルが作成されると、すぐに反映されます。
NetWitness Suite 10.4では、このパラメータの有効な値は、 gzip 、 bzip2 、 lzma 、 none です。 gzip は、パフォーマンスとスペースの節約のバランスがよいため、圧縮を使用する場合の推奨アルゴリズムです。 bzip2 と lzma は、どちらもスペースをより節約できますが、速度が大幅に低下します。そのため、取得速度が遅くても、ストレージ領域が重要な場合のみ使用を検討してください。
packet.compression.level , meta.compression.level
これらの設定を使用すると、圧縮アルゴリズムの動作を細かく制御できます。圧縮が無効化されている場合、これらの設定も無効になります。有効な値は0～9です。デフォルト値のゼロを使用すると、速度と圧縮の最適な設定が自動的に選択されます。1～9の値を使用すると、パフォーマンス（1）と圧縮（9）のバランスが段階的に変化します。通常、値が9の場合、指定したアルゴリズムで最高の圧縮率になりますが、パフォーマンスは最も低下します。中間が一般的に最適な設定（値をゼロにした場合の設定）です。
hash.algorithm
この設定では、データベース ファイルのハッシュ方法を制御します。デフォルト値は none です。この場合、ハッシュは実行されません。有効な値は、 none 、 sha256 、 sha1 、 md5 です。データベース ファイルをハッシュすると、ファイルをクローズした後にそのファイルが改ざんされていないことを証明できます。ハッシュは時間のかかる処理であるため、有効にしていると取得パフォーマンスが低下します。変更はすぐに反映されます。
hash.databases
この設定では、ハッシュするデータベースを制御します。有効な値は、 session 、 meta 、 packet です。複数のデータベースをハッシュするときは、それらをコンマで区切ります。変更はすぐに反映されます。
hash.dir
この設定はデフォルトで空になっています。この場合は、ハッシュされるデータベース ファイルと同じディレクトリにハッシュ ファイルが作成されます。この設定を定義すると、代わりに、指定したディレクトリにハッシュ ファイルが書き込まれます。これは、ハッシュの改ざんに対する耐障害性を確保するためのライト ワンス方式ストレージのように運用する場合に便利です。
ハッシュ ファイルは小さなXMLファイルで、進エンコードされたハッシュと、ハッシュされたデータベース ファイルに関するメタデータが含まれています。