Datenbanktuning: Tiered-Datenbankspeicher

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

In diesem Thema werden Tiered-Datenbankspeicher beschrieben und Empfehlungen für Hot-, Warm- und Cold-Tier-Storage gegeben.

Seit der Version 10.4 kann der Archiver-Service so konfiguriert werden, dass er Tiered Storage verwenden kann. Die Idee hinter Tiered Storage ist es, die aktuellen Daten auf einen Hot-Tier zu stellen, den am schnellsten verfügbaren Speicher auf dem Archiver.

Alle Services verwenden standardmäßig den Hot-Tier.

Der nächste Tier ist der Warm-Tier. Das ist normalerweise ein preiswerterer und langsamerer Speicher, wie etwa ein Network Attached Storage (NAS). Der Warm-Tier enthält ältere Daten; wie alt sie sind, hängt davon ab, wie viel Speicher auf dem Hot-Tier allokiert ist, sowie von der durchschnittlichen Aufnahmerate. Wenn der Hot-Tier die maximale Auslastung erreicht, werden normalerweise die ältesten Daten vom Hot-Tier auf den Warm-Tier verschoben. Wenn alles richtig konfiguriert ist, geschieht dies automatisch und für den Anwender unsichtbar. Abfragen und Datenzugriff geschehen automatisch, egal auf welchem Tier (Hot oder Warm) die Daten liegen. Allerdings kann es beim Zugriff auf Daten auf dem Warm-Tier im Vergleich zu dem Hot-Tier zu Performanceeinbußen kommen, da der Zugriff auf den Warm-Tier typischerweise langsamer ist.

Zusätzlich zum Hot- und Warm- gibt es auch noch einen Cold-Tier. Der Cold-Tier wird nur als Staging-Bereich für das Offline-Backup verwendet. NetWitness-Core-Services greifen nicht auf Daten auf dem Cold-Tier zu. NetWitness-Core-Services verschieben die ältesten Daten auf den Cold-Tier und betrachten sie als aufgegeben (der Service greift nicht länger auf die Daten zu). Diese Daten können dann langfristig gespeichert werden. Sie können zum Beispiel auf Band gesichert werden, damit sie bei Bedarf Monate oder Jahre später wiederhergestellt werden können. Das Sichern und nachfolgende Entfernen der Daten auf dem Cold-Tier muss außerhalb der NetWitness-Services über Skripte oder andere Prozesse erfolgen.

Wenn der Cold-Tier voll wird, weil externe Prozesse die Daten nicht rechtzeitig entfernen, wird der NetWitness-Core-Service die Aufnahme neuer Daten möglicherweise beenden, bis das Problem behoben ist.

Wenn Daten auf den Cold-Tier verschoben werden, empfiehlt RSA, das Verzeichnis auf demselben Mount-Punkt zu lassen, von dem es verschoben wird. Wenn daher die Daten von dem Warm-Tier kommen, ist es aus Performancegründen viel besser, das Cold-Tier-Verzeichnis auf dasselbe Dateisystem zu stellen. Der Grund dafür ist, dass der Service versucht, die Datei und das Verzeichnis einfach auf den Cold-Tier zu verschieben – ein Vorgang, der nahezu sofort auf demselben Dateisystem abgeschlossen ist. Wenn das Verschieben fehlschlägt, besteht die Sicherung darin, die Daten auf den Cold-Tier zu verschieben, was länger dauert und zusätzliche I/O-Konkurrenz auf dem Tier verursacht, von dem die Daten kopiert werden.

Archiver

Die Tiers der Speicherfunktionen werden vom Archiver verwendet. Sie können Archiver so konfigurieren, dass nur der (standardmäßige) Hot-Storage verwendet wird, Hot und Warm, oder alle drei (Hot, Warm und Cold). Alle Services müssen Hot verwenden. Sie können keinen Service so konfigurieren, dass er nur Warm verwendet. Die Daten fließen von Hot zu Warm und schließlich zu Cold. Sie können Warm auch überspringen und von Hot zu Cold gehen. Wenn Cold-Storage (offline) nicht konfiguriert ist, werden die ältesten Daten auf dem letzten konfigurierten Tier gelöscht. Dies ist bislang das Standardverfahren.

Die typische Archiver-Bereitstellung stellt alle Datenbanken auf unbegrenzte Größe ein (packet.dir, meta.dir, session.dir, index.dir und optional die Warm-Tier-Varianten). Das heißt, dass die Größenangabefunktion entweder ausgeschaltet oder auf Null eingestellt wird. So können die Datenbanken und der Index unbegrenzt wachsen. Anstatt dass jede Datenbank ihre eigene Größe verwaltet und Daten nur dann verlagert, wenn jede einzelne Datenbank ihre konfigurierte Größe überschreitet, verlagert Archiver alles zusammen mithilfe des Befehls /index sizeRoll . So können die Datenbanken und der Index die Daten gemeinsam verlagern. Weitere Informationen über sizeRoll finden Sie unter „Asynchrones Rollover“ in Rollover .

Archiver wird typischerweise so konfiguriert, dass Index-, Sitzungs-, Metadaten- und Paket (Protokoll)-Datenbank auf dem gleichen Volume liegen, anstatt auf mehreren Volumes wie ein Concentrator oder Decoder. Obwohl dies potenziell zu mehr I/O-Konkurrenz führen kann, wenn gleichzeitige Lesevorgänge über mehrere Datenbanken geschehen, maximiert es auch die allgemeine Aufbewahrung. Da alle Datenbanken auf demselben Volume liegen, sind sie so konfiguriert, dass sie Daten gemeinsam verlagern, wodurch die Verwaisung von Daten minimiert wird. Decoder und Concentrator werden für maximale I/O-Geschwindigkeit konfiguriert, können aber unter Fehleinschätzungen der richtigen Dimensionierung der Volumes leiden.

Beispiel: Wenn die Sitzungsdatenbank zu groß ist, hat sie möglicherweise ausreichend Speicherplatz für sechs Monate Aufbewahrung, während die Metadaten- und Indexdatenbank nur Platz für vier Monate Aufbewahrung hat. Weil die Sitzungs-, Metadaten- und Indexdatenbank miteinander verbunden sind, definiert die kürzeste Aufbewahrungsfrist der drei die allgemeine Aufbewahrungsfrist (in diesem Fall vier Monate). Die Aufbewahrung einzelner Datenbanken ist meist von Faktoren betroffen, die wir nicht unter Kontrolle haben, wie etwa erfasster Datenverkehr, erzeugte Metadaten (Parser, Feeds, Regeln) und Filterung. Die Größe der Datenbanken lässt sich durch eine einfache Konfigurationsänderung neu festlegen. Aber dafür müssen normalerweise auch Änderungen auf Hardware- und Dateilevel vorgenommen werden, um Partitionen zu ändern, wodurch die dynamische Größenänderung kompliziert wird. Archiver vermeidet diese Probleme, indem ein einziges Volume für alles verwendet wird, wofür eine etwas geringere I/O-Geschwindigkeit in Kauf genommen wird.

Next Topic:Manifeste
You are here
Table of Contents > Grundlegende Datenbankkonfiguration > Tiered-Datenbankspeicher

Attachments

    Outcomes