コアDB:階層型データベース ストレージ

Document created by RSA Information Design and Development on Feb 15, 2017
Version 1Show Document
  • View in full screen mode
  

このトピックでは、階層型データベース ストレージについて説明し、HotWarmColdの各階層ストレージに関する推奨事項を示します。

バージョン10.4以降、Archiverサービスは、階層型ストレージを使用するよう構成できます。階層型ストレージのコンセプトは、Archiver上でHot階層を最速のストレージで構成し、最新のデータを配置することです。

注:Hot階層は、デフォルトですべてのサービスによって使用されます。

次の階層はWarm階層と呼ばれ、通常は、より安価でそれほど高速ではないNAS(ネットワーク接続型ストレージ)などのストレージで構成します。Warm階層には、古くなったデータが格納されます。古さの程度は、Hot階層に割り当てられているストレージ容量と平均的な取得レートによって決まります。Hot階層の使用量が上限に達すると、Hot階層からWarm階層に最も古いデータが移動される運用となります。正しく構成されている場合、この処理は自動的に行われ、エンド ユーザーに対して透過的です。クエリーとデータ アクセスは、どの階層(HotまたはWarm)にデータが配置されているかにかかわらず自動的に行われます。ただし、Warm階層上のデータにアクセスするときは、Hot階層と比べてパフォーマンス インパクトが生じる場合があります。これは、Warm階層上のデータ アクセスの方が一般的に低速なためです。

HotWarmに加えて、Coldという階層も構成することができます。Cold階層は、オフライン バックアップ用のステージング エリアとしてのみ使用されます。Security Analyticsコア サービスは、Cold階層のデータにはアクセスしません。Security Analytics Coreサービスは、最も古いデータをCold階層に移動して、常時アクセス環境からは破棄されたものとみなします(サービスはそれらのデータにアクセスしなくなります)。このデータは、要件に応じて数か月後あるいは数年後にリストアできるよう、テープなどの長期ストレージにバックアップしておくことができます。Cold階層上のデータのバックアップとその後の削除は、スクリプトなどのプロセスを使用してSecurity Analytics Coreサービス以外のツールで処理する必要があります。

注意:外部プロセスで適時にデータを削除していない場合、Cold階層がフルになり、問題が修正されない限り、Security Analytics Coreサービスによる新しいデータの取得が停止されます。

Cold階層にデータを移動する場合は、データの移動元と同じマウント ポイントにディレクトリを残しておきます。ファイルをWarm階層から移動する場合は、Cold階層のディレクトリを同じ ファイル システム上に設定すると、パフォーマンスが大幅に向上します。これは、同一ファイル システム上でファイルとディレクトリをCold階層に移動するというほぼ瞬時の操作がサービスによって実行されるためです。移動に失敗した場合の代替手段としては、データをCold階層にコピーすることですが、この場合、処理時間が長くなり、コピー元の階層でI/Oの競合が増加します。

Archiver

ストレージ階層の機能はArchiverによって使用されます。Archiverは、Hot ストレージのみ使用するか(デフォルト)、HotWarmを使用するか、3つすべて(HotWarmCold)を使用するよう構成できます。Hotはすべてのサービスが使用する必要があり、Warmのみを使用するようサービスを構成することはできません。データはHotからWarmに移動し、最終的にColdに移動します。Warmをスキップして、HotからColdに移動することもできます。Cold(オフライン)ストレージが構成されていない場合、通常、最も古いデータは最後に構成された階層上で削除される運用となります。

典型的なArchiver導入環境では、すべてのデータベース(packet.dir、meta.dir、session.dir、index.dir、オプションでWarm階層などを指定)を無制限サイズに設定し、サイズ指定子はオフのままか、ゼロに設定します。このように設定すると、データベースとインデックスを無限に拡大できるようになります。各データベースごとにサイズを管理して個々のデータベースが構成済みサイズを超えた場合にのみロールアウトを行うのではなく、Archiverでは、/index sizeRollコマンドを使用して、すべてのデータベースをまとめてロールアウトするよう構成できます。これにより、データベースとインデックスを同時にロールアウトできるようになります。sizeRollの詳細については、以下にある「非同期ロールオーバー」を参照してください:ロールオーバー.

Archiverは通常、インデックス、セッション、メタ、パケット(ログ)の各DBをConcentratorやDecoderなどの複数のボリュームに配置するのではなく、同じボリュームに配置するよう構成されています。複数のデータベースにわたる同時読み取りが行われる場合は、このことが原因でI/O競合が増加する可能性がありますが、保存に関する全体的なメンテナンス性は向上します。すべてのデータベースが同じボリューム上に置かれるため、同時にロールアウトするよう構成でき、これによってデータの孤立化が抑制されます。DecoderとConcentratorは、I/O速度を最大限に高めるよう構成されていますが、適切なボリュームのサイジングが難しい面もあります。

たとえば、セッションDBのサイズが大きすぎる場合、6か月のデータ保存に十分なストレージ容量がセッションDBにあっても、メタDBとインデックスには4か月分の保存容量しかないケースなども考えられます。セッション、メタDB、インデックスは複雑に関連し合っているため、3つのうち最短の保存期間によって全体の保存期間(この場合は4か月)が定義されます。個々のデータベースの保存期間は、収集されるトラフィック、生成されるメタ(Parser、Feed、ルール)、フィルター処理など、制御不可能な要因によって大きく左右されます。データベースのサイズ変更はシンプルな構成変更によって容易に行うことができますが、通常は、パーティションを調整するためのハードウェア レベルやファイル システム レベルでの変更も伴うため、動的なサイズ変更が複雑化します。Archiverでは、すべてのデータベースに単一のボリュームを使用することによって、I/O速度を多少犠牲にしつつも、これらの問題を回避できます。

You are here
Table of Contents > 基本的なデータベースの構成 > 階層型データベース ストレージ

Attachments

    Outcomes