Datenbanktuning: Datenbankkonfigurations-Nodes

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

In diesem Thema werden Datenbankkonfigurations-Nodes beschrieben. Die folgenden Datenbankkonfigurations-Nodes gehören zu den erweiterten Datenbank-Konfigurationselementen der NetWitness Core-Datenbank, die nur selten geändert werden.

packet.dir , meta.dir , session.dir

Dies ist der primäre Konfigurationseintrag für jede Datenbank (auch Hot-Tier genannt). Damit wird gesteuert, wo im Dateisystem die jeweiligen Datenbanken gespeichert werden. Dieser Konfigurationseintrag kann eine komplexe Syntax verarbeiten, mit der mehrere Verzeichnisse als Speicherorte angegeben werden.

Konfigurationssyntax:

 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 ? ; 

Beispiel:

 /var/lib/netwitness/decoder/packetdb=10 t;/var/lib/netwitness/decoder0/packetdb=20.5 t 

Die Größenwerte sind optional. Sofern festgelegt, geben sie die maximale Gesamtgröße der hier gespeicherten Dateien an, bevor Datenbanken verschoben werden. Falls keine Größe angegeben wurde, wird die Datenbank nicht automatisch verschoben. Die Größe lässt sich jedoch auf andere Weise verwalten.

Die Verwendung von = oder == ist bedeutend. Datenbanken verhalten sich standardmäßig so, dass sie beim Starten des Core-Services automatisch Verzeichnisse erstellen. Allerdings lässt sich dieses Verhalten durch die Verwendung der Syntax == überschreiben. Wenn == verwendet wird, werden keinerlei Verzeichnisse durch den Service angelegt. Wenn die Verzeichnisse beim Start des Services nicht vorhanden sind, ist eine erfolgreiche Verarbeitung durch den Service nicht möglich. Dadurch wird dem Service eine gewisse Ausfallsicherheit gegenüber Dateisystemen verliehen, die beim Start des Hosts fehlen oder getrennt sind.

Wenn Sie die Größe eines bereits verwendeten Verzeichnisses ändern, wird die Änderung sofort wirksam, solange sie nach oben erfolgt. Wird die Größe nach unten geändert, wird sie ignoriert, wenn sie mehr als 10 Prozent kleiner als die derzeitige Größe ist. Dadurch wird ein versehentlicher Vertipper vermieden, durch den ein erheblicher Datenverlust entstehen könnte. Wenn die Paketdatenbank beispielsweise für 12 TB konfiguriert wurde und jemand versehentlich 12 GB eingegeben hat, würden in der Datenbank mehr als 11 TB an Daten gelöscht werden, um sie auf nur 12 GB zu schrumpfen. Stattdessen ignoriert die Datenbank die Vorgabe 12 GB und protokolliert eine Warnmeldung, sodass der Fehler schnell ermittelt werden kann. Wenn die angegebene Größe richtig ist und sich um mehr als 10 % von der aktuellen Größe unterscheidet, wird sie selbstverständlich erst bei einem Neustart des Services wirksam. Bei einem Service-Neustart interpretiert das System die Größenangabe als richtig und nimmt eine Anpassung der Datenbankgröße vor, indem die ältesten Daten ausgelagert werden, um die neue Größe zu erreichen. Wenn Sie beabsichtigen, die Größe ohne einen Neustart des Systems um mehr als 10 Prozent zu verringern, müssen Sie die Größe in mehreren Vorgängen anpassen und sie jedes Mal um weniger als 10 Prozent verringern. Beobachten Sie die Serviceprotokolle, um einen Überblick zu behalten, wann die Datenbank die neue Größe erreicht hat, da die Gesamtgröße der Datenbank erst nach Schließen der letzten geschriebenen Datei angepasst wird.

Falls neue Verzeichnisse hinzugefügt oder gelöscht wurden (durch Semikolon getrennt), werden diese Änderungen erst nach einem Neustart des Services wirksam.

packet.dir.warm , meta.dir.warm , session.dir.warm

Diese Einstellungen sind optional und werden für die Warm-Tier-Speicherfunktion auf einem Archiver verwendet. Standardmäßig sind sie leer und nicht in Gebrauch. Wenn sie konfiguriert sind, weisen Sie dasselbe Format und Verhalten auf wie packet.dir , meta.dir und session.dir (siehe _ packet.dir , meta.dir und session.dir _ weiter oben). Sofern konfiguriert, wird die älteste Datei im Hot Tier in den Warm Tier verschoben, wenn der Platz im Hot Tier nicht mehr ausreicht.

packet.dir.cold , meta.dir.cold , session.dir.cold

Diese Einstellungen sind optional und finden Anwendung, wenn Dateien aus einem Hot- bzw. Warm-Tier-Speichersystem in ein angegebenes Cold-Tierverzeichnis verschoben werden. Bei dieser Einstellung handelt es sich um nichts anderes als ein Verzeichnis; es gibt keine Größenangaben. Der angegebene Pfadname weist jedoch einige spezielle Formatvorgaben auf, die Sie für die Benennung des Verzeichnisses mit dem Datum der darin enthaltenen Daten verwenden können.

 %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 

Beispiel für eine Einstellung:

 packet.dir.cold = /var/lib/netwitness/archiver/database1/alldata/cold-storage-%y-%m-%d-%8r 

Wenn bei der oben genannten Einstellung eine Datenbankprotokolldatei in den Cold-Speicher verschoben werden soll, die am 2014-03-02 15:00:00 erstellt wurde, würde sie in das folgende Verzeichnis im Cold Tier verschoben werden:

 /var/lib/netwitness/archiver/database1/alldata/cold-storage-2014-03-02-01 

Die letzte Ziffer 01 bedarf einer gewissen Erläuterung. Die Spezifizierung %8r unterteilt die Stunden eines Tages in 24/8 = 3 Teile. Die ersten acht Stunden des Tages sind Block 00 , also 0 Uhr bis 8 Uhr. Die nächsten acht Stunden von 8 Uhr bis 16 Uhr entsprechen Block 01 . Da die Daten, die in den Cold-Speicher verschoben werden sollen, um 15 Uhr erstellt wurden, zählen sie zu Block 01 . Die Formatspezifizierung %r eignet sich für die Sicherung von Dateien mit einer Detailgenauigkeit etwa zwischen einem Tag %d und einer Stunde %h . Die Erstellung des Cold-Speichers erfolgt nach Bedarf und ergibt sich aus den verschobenen Daten bei Verwendung der Formatspezifizierungen.

Die Möglichkeit, dem Datenpfad ein Datum hinzuzufügen, ist für Sicherungs- und Wiederherstellungszwecke hilfreich. Dabei werden die Daten mit einem Tag im Pfad versehen.

packet.file.size , meta.file.size , session.file.size

Hiermit wird die Größe der mit jeder Datenbank erstellten Dateien gesteuert. Normalerweise ist es nicht notwendig, diese Werte zu ändern, da die Standardwerte im Allgemeinen gut funktionieren. Diese Einstellung ist für nachfolgende Dateien sofort wirksam.

packet.files , meta.files , session.files

Mit dieser Einstellung wird die Anzahl der von der Datenbank offen gehaltenen Dateien gesteuert. Dieser Wert lässt sich erhöhen, um die Performance zu verbessern, wobei das Betriebssystem über eine Obergrenze für gleichzeitig geöffnete Dateien des Systems verfügt. Wird diese Grenze überschritten, gibt es eine Fehlermeldung, und der Service funktioniert nicht. Diese Einstellung wird sofort wirksam.

In NetWitness Suite 10.6 und höher lautet der Standardwert für packet.files, meta.files und session.files auto und der Service managt die Anzahl der offenen Dateien auf Grundlage der folgenden Kriterien:

  1. Anzahl der Sammlungen
  2. Menge des Systemspeichers

Bei Festlegung auf auto ist die Zahl dynamisch und Sie können die Änderungen in den Protokollen sehen. Für NetWitness Suite 10.6 empfiehlt RSA, diesen Wert auf auto festzulegen und ihn nicht in eine bestimmte Zahl zu ändern.

packet.free.space.min , meta.free.space.min , session.free.space.min

Mit dieser Einstellung wird eine Sicherheitsbeschränkung für den Mindest-Speicherplatz der jeweils von packet.dir, meta.dir und session.dir angegebenen Verzeichnisse festgelegt. Damit wird verhindert, dass dem Service der Speicherplatz ausgeht, wenn andere Programme den Platz nutzen, der normalerweise jeder dieser Datenbanken zugewiesen sein sollte. Diese Einstellung wird sofort wirksam.

packet.index.fidelity , meta.index.fidelity

Mit dieser Einstellung wird gesteuert, in welchen Zeitabständen die Paket-ID- und Meta-ID-Speicherorte indiziert werden sollen. Die Einstellung kann erhöht werden, um den für jedes Paket bzw. jede nwindex-Metadatei benötigten Speicherplatz zu verringern, wodurch sich jedoch die Geschwindigkeit verringert, mit der einzelne Pakete oder Metaelemente gefunden werden können. Diese Einstellung wird sofort wirksam.

Für die Sitzungsdatenbank gibt es keine Genauigkeitseinstellungen, da sie keine Indexdateien erstellt.

packet.integrity.flush , meta.integrity.flush , session.integrity.flush

Mit dieser Einstellung wird gesteuert, ob die Datenbank nach dem Schreiben einer Datei eine Synchronisierung des Dateisystems erzwingt. Der Standardwert ist sync . Das bedeutet, dass es bei einer geschlossenen Datei zu einer erheblichen Verzögerung kommt, wenn die Daten in einen nicht flüchtigen Speicher geschrieben werden. Es kann erforderlich sein, diesen auf normal zu setzen, um höhere kontinuierlichere Schreibgeschwindigkeiten zu erreichen, insbesondere auf einem Decoder. Diese Einstellung wird ab der nächsten erstellten Datei wirksam. Daher ist davon auszugehen, dass nach dem Setzen des Werts auf normal mindestens eine weitere Synchronisierung erfolgt.

Sollte es zu Paketverlusten kommen und packet.integrity.flush weist die Einstellung sync auf, setzen Sie es auf normal und überwachen Sie den Vorgang. Belassen Sie die Einstellungen für die Sitzung und Meta-Leerung bei sync . Sollte das Problem mit den Paketverlusten weiter bestehen, setzen Sie alle drei auf normal und überwachen Sie den Vorgang.

packet.write.block.size , meta.write.block.size , session.write.block.size

Die Blockgröße zeigt an, welche Datenmenge jeweils in eine Datenbankdatei geschrieben wird. Durch größere Blockgrößen lassen sich höhere Durchsatz- und Komprimierungsraten erreichen, zudem wird die Geschwindigkeit verbessert, mit der Elemente nacheinander aus der Datenbank abgerufen werden können. Größere Blockgrößen können sich jedoch nachteilig auf Random-Lesegeschwindigkeiten für komprimierte Paket- und Metaelemente auswirken. Diese Einstellung wird sofort wirksam.

packet.compression , meta.compression

Mit diesen Parametern wird gesteuert, ob die Datenbanken Daten komprimieren. Durch Komprimierung wird der von den Datenbanken benötigte Speicherplatz verringert, was sich jedoch sehr negativ sowohl auf die Geschwindigkeit auswirken kann, mit der Elemente in die Datenbank geschrieben werden, als auch auf die Geschwindigkeit, mit der Elemente aus der Datenbank abgerufen werden. Die Änderungen sind sofort ab Erstellung der nächsten Datei wirksam.

Ab NetWitness Suite 10.4 lauten die gültigen Werte für diesen Parameter gzip , bzip2 , lzma oder none . gzip ist der bevorzugte Algorithmus, wenn die Komprimierung zum Einsatz kommt, da hier eine ausgewogene Balance zwischen Performance und gespartem Speicherplatz erzielt wird. Mit bzip2 und lzma wird zwar jeweils mehr Speicherplatz gespart, was sich jedoch ziemlich stark auf die Geschwindigkeit auswirkt. Diese beiden Parameter sollten daher nur für geringe Verarbeitungsgeschwindigkeiten verwendet werden oder dann, wenn es insbesondere auf den Speicherplatz ankommt.

packet.compression.level , meta.compression.level

Mit diesen Einstellungen können Sie die Komprimierungsalgorithmen genauer einstellen. Bei deaktivierter Komprimierung haben sie keinerlei Auswirkungen. Die gültigen Werte liegen zwischen 0 und 9\. Der Standardwert lautet 0, bei dem die optimale Einstellung für Geschwindigkeit und Komprimierung von der Software ausgewählt wird. Die Werte von 1 bis 9 entsprechen einer Gleitskala zwischen Performance (1) und Komprimierung (9). Beim Wert 9 erhalten Sie für einen gegebenen Algorithmus die beste Komprimierung, jedoch die schlechteste Performance. Die beste Einstellung liegt meist im mittleren Bereich, welcher bei der Einstellung 0 ausgewählt wird.

hash.algorithm

Mit dieser Einstellung wird das Hashen der Datenbankdateien festgelegt. Der Standardwert ist none , es erfolgt also kein Hashing. Gültige Werte sind none , sha256 , sha1 und md5 . Datenbankdateien können gehashed werden, um nachzuweisen, dass sie nach dem Schließen nicht manipuliert worden sind. Hashing-Vorgänge sind zeitaufwändig und beeinträchtigen, wenn sie aktiviert sind, die Verarbeitungs-Performance. Diese Änderung tritt sofort in Kraft.

hash.databases

Mit dieser Einstellung wird festgelegt, welche Datenbanken gehashed werden. Gültige Werte sind session , meta und packet . Beim Hashing von mehreren Datenbanken werden die Werte durch Kommas getrennt. Diese Änderung tritt sofort in Kraft.

hash.dir

Diese Einstellung ist normalerweise leer, d. h. die Hash-Datei wird in dasselbe Verzeichnis geschrieben wie die Datenbankdatei, die gehashed wurde. Bei Festlegung dieser Einstellung wird die Hash-Datei stattdessen in das angegebene Verzeichnis geschrieben. Das könnte eine Art Speicher zur Einmalverwendund sein, um gegen Hash-Manipulation gewappnet zu sein.

Bei Hash-Dateien handelt es sich um kleine XML-Dateien, die neben Metadaten den hex-kodierten Hash der Datei, die gehashed wurde, enthalten.

You are here
Table of Contents > Erweiterte Datenbankkonfiguration > Datenbankkonfigurations-Nodes

Attachments

    Outcomes