Datenbanktuning: Optimierungstechniken

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

In diesem Thema werden Optimierungstechniken für die NetWitness Core-Datenbank beschrieben. Die NetWitness Core-Datenbank ist standardmäßig so eingerichtet, dass sie viele verschiedene Workloads verarbeiten kann. Wie bei jede Datenbanktechnologie kann die Performance stark abhängig sein sowohl von der Art der aufgenommenen Daten als auch der Art der Suchvorgänge, die Benutzer in der Datenbank durchführen.

Schwellenwerte

sind eine nützliche Optimierung, die sich erheblich darauf auswirken können, wie schnell Ergebnisse zur Ansicht „Navigation“ von NetWitness Suite zurückgegeben werden. Schwellenwerte werden auf den values-Aufruf angewendet. Weitere Informationen über den values-Aufruf erhalten Sie unter Abfragen.

Mit dem Schwellenwert wird begrenzt, wie viel der Datenbank von der Festplatte abgerufen wird, um eine Anzahl zu erzeugen. Bei den meisten Abfragen ist die Anzahl der Sitzungen, die der where-Klausel entsprechen, sehr groß. Wenn Sie beispielsweise alle Protokollereignisse nur einer Stunde auswählen, ergibt dies bei 30.000 Ereignissen pro Sekunde 108.000.000 entsprechende Sitzungen.

RSA führte den Schwellenwert aufgrund der Feststellung ein, dass das Ergebnis in den meisten Fällen, in denen eine Sitzungsanzahl erforderlich ist, nicht bis auf die letzte Sitzung exakt sein muss. Wenn z. B. in einer Übersicht erfasst werden soll, welche 20 IP-Adressen in der letzten Stunde am häufigsten auftraten, ist es nicht so wichtig, ob der Bericht für einen IP-Wert 10.000.000 oder 10.000.001 entsprechenden Sitzungen angibt. Eine Schätzung ist ausreichend. In solchen Szenarien kann als Anzahl ein Schätzwert zurückgegeben werden, wenn die Anzahl den Schwellenwertparameter übersteigt. Wenn der Schwellenwert erreicht wird, wird die verbleibende Anzahl geschätzt, und die Ergebnis werden bei Bedarf auf der Grundlage der geschätzten Anzahlen sortiert.

Komplexe where-Klauseln

Wie lange es dauert, bis die NetWitness Core-Datenbank ein Ergebnis erzeugt, hängt von der Komplexität der Abfrage ab. Abfragen, die direkt an den Indexen der Metadaten ausgerichtet sind, können schnell beantwortet werden, aber es ist sehr leicht, Abfragen zu schreiben, die nicht schnell beantwortet werden können. Manchmal werden Abfragen, auf die nicht schnell ein Ergebnis zurückgegeben werden kann, von der Core-Datenbank und dem Index unterschiedlich verarbeitet, um dem Kunden ein zufriedenstellenderes Ergebnis zu bieten.

Es ist nützlich, die relativen Kosten jedes Teils der where-Klausel zu kennen. Die Ausführung einer Klausel mit hohen Kosten dauert länger. In der folgenden Tabelle sind die Abfragevorgänge entsprechend der relativen Kosten geordnet, von den niedrigsten zu den höchsten.

                         
Vorgang Cost
exists, !exists Konstant
= , != Logarithmisch in Bezug auf die Anzahl der eindeutigen Werte für den Metaschlüssel, linear in Bezug auf die Anzahl der eindeutigen Element, die einem Bereichsausdruck entsprechen
< , > , <= , >= Logarithmisch in Bezug auf eindeutige Wertsuche, aber wahrscheinlicher linear, da der Ausdruck einem weiten Wertebereich entspricht
begins , ends , contains Linear in Bezug auf die Anzahl der eindeutigen Werte für den Metaschlüssel
regex Linear in Bezug auf die Anzahl der eindeutigen Werte für den Metaschlüssel mit hohen pro-Wert-Kosten

AND und OR

Bedenken Sie bei der Erstellung einer where-Klausel, dass sich die Aneinanderreihung vieler Begriffe mit dem Operator AND positiv auf die Performance der Abfrage auswirken kann. Wann immer der Satz Sitzungen, die der where-Klausel entsprechen, durch mehrere Kriterien gefiltert werden kann, ist der Arbeitsaufwand für die Abfrage reduziert. Entsprechend vergrößert jede OR-Klausel den Satz Sitzungen, die für eine Abfrage verarbeitet werden müssen.

Als allgemeine Faustregel gilt: Je mehr AND-Klauseln eine Abfrage enthält, um so schneller wird sie ausgeführt, aber je mehr OR-Klauseln eine Abfrage enthält, um so langsamer sie ausgeführt.

Anwendungsbeispiel: Abgleichen eines großes Subnetz

Benutzer versuchen beim Erstellen von Abfragen häufig, Subnetze der Klasse A ein- oder auszuschließen. Hierbei handelt es sich um eine gängige Abfrageart, da die Benutzer versuchen, einen großen Teil ihres internen Netzwerks in die Ermittlungen einzuschließen oder davon auszuschließen.

Es ist problematisch für die Abfrage-Engine, die Abfrage ausschließlich mit dem Index ip.src oder ip.dst zu verarbeiten. Das Problem besteht darin, dass eine where-Klausel wie diese:

 ip.src = 10.0.0.0/8 

Tatsächlich wie folgt interpretiert werden muss:

 ip.src = 10.0.0.0 || ip.src = 10.0.0.1 || ip.src = 10.0.0.2 || ... || ip.src = 10.255.255.255 

Daher muss der Index unter Umständen eine where-Klausel mit über 16 Millionen Begriffen erstellen.

Diese Problem lässt sich mithilfe des Decoder lösen, mit dem gängige, in Frage kommende Netzwerke mit Anwendungsregeln kennzeichnen kann. Beispielsweise könnten Sie Metadatenelemente mit einer Anwendungsregel erstellen, die folgendermaßen aussieht:

 name=internal rule="ip.src = 10.0.0.0/8" order=3 alert=network 

Mit dieser Regeln werden Metadatenelemente im Metaschlüsselnetzwerk mit dem internen Wert einer beliebigen IP-Adresse im 10.0.0.0/8-Netzwerk erstellt.

Die where-Klausel könnte wie folgt ausgedrückt werden:

 network = "internal" 

Angenommen, es gibt einen value-level-Index für die Netzwerkmetadaten, dann muss diese Abfrage durch den Index nicht in etwas Komplexeres erweitert werden und die Sitzungen, die dem gewünschten Subnetz entsprechen, werden schnell gefunden.

Anwendungsbeispiel: Abgleichen von Teilzeichenfolgen

Die Verwendung der Operatoren begins, ends, contains und regex in einer where-Klausel kann die Ausführung stark verlangsamen, wenn es eine große Anzahl von Werten für den Metaschlüssel gibt. Jeder dieser Operatoren wird einzeln gegen jeden eindeutigen Wert ausgewertet. Wenn der Operator regex lautet, muss regex einzeln gegen jeden eindeutigen Wert ausgeführt werden.

Die wirkungsvollste Strategie zur Umgehung ist die Neuorganisation der Metadatenelemente, sodass der Benutzer kein Abgleichen von Teilzeichenfolgen verwenden muss.

Beispiel: Angenommen, die Benutzer versuchen, den Hostnamen innerhalb einer URL irgendwo in der Sitzung zu finden. Die Benutzer könnten eine where-Klausel wie folgt schreiben:

 url contains 'www.rsa.com' 

In diesem Szenario enthält der Metaschlüssel url wahrscheinlich einen eindeutigen Wert für jede Sitzung, die vom Decoder erfasst wurde, und daher gibt es eine große Anzahl von eindeutigen Werten. In diesem Fall ist der contains-Vorgang langsam.

Es empfiehlt sich, den Teil der Metadaten zu identifizieren, der abgeglichen werden soll, und den Abgleich dann in den Inhaltsparser zu verschieben.

Wenn beispielsweise Metadaten für jede URL erzeugt werden, könnte ein Parser die URL auch in ihre Bestandteile zerlegen. Wenn der Decoder beispielsweise URL-Metadaten mit dem Wert http://www.rsa.com/netwitness erstellt, könnte er auch alias.host-Metadaten mit dem Wert www.rsa.com erstellen. Abfragen könnten wie folgt formuliert werden:

 alias.host = 'www.rsa.com' 

Da der Teilzeichenfolgenoperator nicht mehr erforderlich ist, wird die Abfrage viel schneller durchgeführt.

Indexspeicherung

Der Core-Index wird in Speicherpunkte, auch als Slices bezeichnet, unterteilt. Wenn der Index gespeichert wird, werden alle Daten im Index auf die Festplatte geschrieben und dieser Teil des Index wird als Schreibgeschützt gekennzeichnet. Speicherungen dienen zwei Funktionen:

  • Jeder Speicherpunkt stellt einen Platz dar, an dem der Index im Falle eines Stromausfalls wiederhergestellt werden kann.
  • Durch regelmäßiges Speichern können Sie sicherstellen, dass der Teil des Index, der aktiv aktualisiert wird, nicht die Größe des RAM übersteigt.

Speicherpunkte partitionieren den Index in unabhängige, nicht überlappende Segmente. Wenn eine Abfrage mehrere Speicherpunkte überschreiten muss, müssen Teile der Abfrage erneut ausgeführt und die Ergebnisse zusammengeführt werden. Dadurch dauert die Ausführung dieser Abfrage länger.

In NetWitness Suite 10.5 und späteren Installationen wird der Core-Index standardmäßig jedes Mal gespeichert, wenn der Datenbank 600.000.000 Sitzungen hinzugefügt wurden. Dieses Intervall wird durch den Indexkonfigurationsparameter save.session.count festgelegt. Weitere Informationen finden Sie unter Indexkonfigurations-Nodes.

Ältere Versionen von NetWitness Suite oder Systeme, die von NetWitness Suite-Versionen vor 10.5 aktualisiert wurden, verwenden eine zeitbasierte Speicherplanung, mit der der Index alle 8 Stunden gespeichert wird. Sie können das aktuelle Speicherintervall über den Scheduler-Editor in der NetWitness Admin-Benutzeroberfläche für den Service anzeigen. Der Standardeintrag sieht wie folgt aus:

 hours=8 pathname=/index msg=save 

Durch die Anpassung des Intervalls können Sie steuern, wie häufig Speicherungen erstellt werden.

Auswirkungen der Vergrößerung des Speicherintervalls

Durch eine Vergrößerung des Speicherintervalls werden Speicherpunkte weniger häufig erstellt und folglich sind weniger Speicherpunkt vorhanden. Dies wirkt sich positiv auf die Abfrageperformance aus: Es ist unwahrscheinlicher, dass Abfragen über Slices hinweg durchgeführt werden müssen, und wenn dies doch der Fall ist, müssen weniger Slices überquert werden.

Die Vergrößerung des Speicherintervalls weist jedoch auch Nachteile auf. Erstens ist die Wahrscheinlichkeit höher, dass der Concentrator den für einen der Indexe festgelegten Grenzwert valueMax erreicht. Zweitens ist die Recovery-Zeit erhöht, wenn das Gerät zwangsweise heruntergefahren werden muss oder wenn ein Stromausfall auftritt. Und drittens können sich Index-Slices, die zu groß für den Speicher sind, nachteilig auf die Aggregationsrate auswirken.

Auswirkungen der Verkleinerung des Speicherintervalls

Durch eine Verkleinerung des Speicherintervalls kann ein Erreichen des Grenzwerts valueMax vermieden werden, während gleichzeitig ein vollständiger Werteindex für Metadaten, der eine große Anzahl eindeutiger Werte enthält, erhalten bleibt. Die Verkleinerung des Speicherintervalls beeinträchtigt die Abfrageperformance, da mehr Slices erstellt werden.

Arbeiten mit valueMax

Die Beschränkung durch valueMax ist für Benutzer frustrierend, die alle möglichen eindeutigen Metadaten indexieren möchten. Leider ist dies im Allgemeinen nicht möglich. Es gibt Metaschlüssel, die willkürliche, zufällige Daten von überall aus dem Internet enthalten können, und alle eindeutigen Werte können nicht indexiert werden.

Es ist jedoch möglich, einige der Beschränkungen von valueMax durch die Verwendung von Indexen auf Schlüsselebene anstelle von WertIndexen zu umgehen. valueMax hat keine Auswirkungen auf Indexe auf Schlüsselebene.

Es ist möglich, die Ansicht „Navigation“ mit einem Metaschlüssel, der auf Schlüsselebene indiziert ist, zu verwenden. Von der Datenbank werden in der where-Klausel nach Möglichkeit Indexe auf Wertebene verwendet, eindeutige Werte werden jedoch durch Metadatenbankscanning für den values-Aufruf aufgelöst. Dieser Ansatz funktioniert ausgezeichnet, wenn die where-Klausel einen wirksamen Filter bietet, mit dem der Suchumfang auf eine kleine Anzahl von Sitzungen eingeschränkt werden kann, etwa weniger als 10.000 Sitzungen.

Wenn valueMax erreicht wird, können Benutzer einen Datenbankscan an ihren Abfragen durchführen, um sicherzustellen, dass keine relevanten Werte verworfen wurden. Auf diese Funktion können Sie im Investigator 9.8-Client über das Kontextmenü in der Ansicht „Navigation“ zugreifen. Obgleich der Metadatenbankscan viel Zeit beansprucht, kann sich der Benutzer damit beruhigen, dass in den Berichten nichts fehlt.

Parallelisieren von Workloads

Wenn der Benutzer viele Berichte verwendet, muss sichergestellt sein, dass die Optionen zur parallelen Ausführung in Reporting Engine voll ausgeschöpft werden. Außerdem muss sichergestellt sein, dass die Anzahl von max.concurrent.queries der Hardware angemessen ist.

Die Ansicht „Navigation“ in NetWitness Suite ermöglicht eine parallele Ausführung der Komponenten der Ansicht „Investigator“, was sich erheblich auf die wahrgenommene Performance des NetWitness Core-Service auswirken kann.

Indexwiederherstellung

In seltenen Fällen kann ein Core-Service von einer Indexwiederherstellung profitieren. Beispiele:

  • Die Index-Slices in einem NetWitness Core-Service wurden von einer sehr alten Version des Produkts erstellt und er hat seit mehr als 6 Monaten keine Daten bereitgestellt.
  • Der Index wurde falsch konfiguriert und der Benutzer möchte alle Metadaten mit einer neuen Indexkonfiguration neu indexieren.
  • Die beim Core-Service eingehende Datenverkehrslast war sehr gering und das Speicherintervall war groß, wodurch mehr Slices als erforderlich erzeugt wurden.

In solchen Fällen kann eine Indexwiederherstellung die Performance verbessern. Dazu müssen Sie die Nachricht reset mit dem Parameter index=1 an den Ordner /decoder auf einem Decoder, den Ordner /concentrator auf einem Concentrator oder den Ordner /archiver auf einem Archiver senden.

Beachten Sie, dass die vollständige Indexwiederherstellung eines komplett ausgelasteten Concentrators mehrere Tage dauert und möglicherweise Wochen bei einem kompletten Archiver.

Skalieren der Aufbewahrung

Es gibt mehrere Möglichkeiten, um die Aufbewahrung in der NetWitness Core-Datenbank zu verbessern. Aufbewahrung bezieht sich auf den Zeitraum, der von den in der Datenbank gespeicherten Daten abgedeckt wird.

Als ersten Schritt zur Analyse der Aufbewahrung müssen Sie bestimmen, welcher Teil der Datenbank der einschränkende Faktor in Bezug auf die Aufbewahrung ist. Die Paket-, Meta- und Sitzungs-Datenbanken bieten die Statistiken packet.oldest.file.time, meta.oldest.file.time und session.oldest.file.time im Ordner /database/stats, um das Alter der ältesten Datei in der Datenbank anzuzeigen. Der Index liefert die Statistik /index/stats/time.begin, um die älteste im Index gespeicherte Sitzungszeit anzuzeigen.

Erhöhen der Paket- und Metadatenaufbewahrung

Der primäre Mechanismus zur Erhöhung der Aufbewahrung in diesen Datenbanken ist das Hinzufügung von mehr Speicherkapazität. Wenn es nicht möglich ist, dem NetWitness Core-Service Speicherkapazität hinzuzufügen, dann kann es erforderlich sein, die Komprimierungsoptionen auf die Paket- und Metadatenbanken anzuwenden, um die Datenmenge zu reduzieren, die von jeder Datenbank geschrieben wird.

Wenn Sie sich um die Metadatenaufbewahrung sorgen, können Sie nicht benötigten Inhalt von dem Decoder entfernen, der Metadaten erzeugt. Viele Parser erzeugen Metadaten, deren langfristige Speicherung durch den Kunden nicht erforderlich ist.

Erhöhen der Indexaufbewahrung

Der Index wird gewöhnlich länger als die Datenbanken aufbewahrt, bei einem komplexen angepassten Index kann die Indexaufbewahrung jedoch kürzer sein. Im Allgemeinen besteht die einfachste Maßnahme darin, nicht benötigte Indexe auf Wertebene aus der angepassten Konfiguration zu entfernen oder einige der standardmäßigen Indexe auf Wertebene mit Indexen auf Schlüsselebene außer Kraft zu setzen.

Es ist auch möglich, den Index durch Hinzufügen von zusätzlichem Indexspeicher zu skalieren. Der Indexspeicher sollte jedoch nur mithilfe von Solid State Drives erweitert werden.

Horizontal skalieren

Ab Version 10.3 können Concentrators und Archiver mithilfe von Gruppenaggregation in einem Cluster zusammengefasst werden. Die Gruppenaggregation ermöglicht es einem einzigen Decoder Sitzungsfeeds mit Lastenausgleich an mehrere Concentrators oder Archiver zu übertragen. Durch Gruppenaggregation kann die Abfrage- und Aggregations-Workload über einen beliebig großen Hardwarepool verteilt werden.

Weitere Informationen finden Sie im Thema „Gruppenaggregation“ im Bereitstellungsleitfaden.

Gruppieren von Workloads

Die NetWitness Core-Datenbank funktioniert viel besser, wenn alle Systembenutzer in derselben Datenbankregion arbeiten. Da die Datenbank Daten vom Decoder mithilfe der First-in-First-out-Methode erhält, werden die Daten in der Datenbank in der Regel anhand des Zeitpunkts ihrer Erfassung und Speicherung in Clustern zusammengefasst. Daher funktioniert die Datenbank besser, wenn alle Benutzer an Daten desselben Zeitraums arbeiten.

Es ist jedoch nicht immer möglich, dass alle Benutzer gleichzeitig denselben Zeitraum bearbeiten. Die NetWitness Core-Datenbank kann dieses Anwendungsbeispiel zwar auch bewältigen, wird jedoch langsamer arbeiten, da sie zwischen verschiedenen Zeiträumen im RAM wechseln muss. Es ist nicht möglich, alle Zeiträume gleichzeitig im RAM zu haben. In der Regel passen weniger als 1 Prozent der Datenbank und weniger als 10 Prozent des Index in den RAM.

Damit NetWitness Suite für den Kunden funktioniert, ist es wichtig, dass der Kunde die Benutzer in Gruppen zusammenfasst, die gewöhnlich mit denselben Zeiträumen arbeiten. Beispielsweise könnte es sich bei Benutzern, die eine tägliche Überwachung der aktuellsten Daten durchführen, um eine Gruppe handeln. Eine andere Benutzergruppe führt Abfragen im Rahmen von Ermittlungen durch, die weiter zurück in die Vergangenheit reichen. Und eine dritte Benutzergruppe erstellt Berichte über lange Zeiträume. Wenn versucht wird, alle Gruppen über eine einzige Datenbank anzudienen, kann dies zu Frustration und langen Wartezeiten auf die zu erstellenden Ergebnisse führen. Wenn die verschiedenen Anwendungsbeispiele jedoch auf unterschiedliche Concentrator-Hardware verteilt werden kann, kann die wahrgenommene Performance viel besser sein. In diesem Fall kann es vorteilhaft sein, mehrere Concentrator-Services mit weniger RAM und CPU-Leistung zu verwenden, anstelle eines einzigen großen und teuren Concentrators, der allen Ansprüchen gerecht werden soll.

Cache-Fenster

Berücksichtigten Sie die Reihenfolge der Ereignisse:

  1. Um 9:00 Uhr meldet sich der Benutzer „kevin“ an einem Concentrator an und fordert einen Bericht über die letzte Stunde des Erfassungszeitraums an.
  2. Der Concentrator ruft Berichte für den Zeitraum zwischen 08:00 und 09:00 Uhr ab.
  3. Um 09:02 Uhr meldet sich der Benutzer „scott“ beim selben Concentrator an und fordert ebenfalls einen Bericht über die letzte Stunde des Erfassungszeitraums an.
  4. Der Concentrator ruft Berichte für den Zeitraum zwischen 08:02 und 09:02 Uhr ab.

Obwohl beide Benutzer mit dicht beieinander liegenden Zeiträumen arbeiteten, konnte die vom Concentrator durchgeführte Arbeit, um die Berichte für Kevin zu erstellen, nicht an Scott gesendet werden, da die Zeiträume nicht identisch waren. Der Concentrator musste den Großteil der Berichte für Scott neu berechnen.

Die Einstellung cache.window.minutes auf dem Node /sdk ermöglicht Ihnen eine Optimierung dieser Situation. Wenn sich ein Benutzer anmeldet, bewegt sich der Zeitpunkt, der die aktuellste Datenerfassung repräsentiert, nur in Schritten vorwärts, die der in dieser Einstellung festgelegten Anzahl von Minuten entsprechen.

Nehmen wir beispielsweise an, /sdk/config/cache.window.minutes ist 10\. Die erneute Bewertung der oben genannten Aktion ändert die Reihenfolge der Ereignisse.

  1. Um 9:00 Uhr meldet sich der Benutzer „kevin“ an einem Concentrator an und fordert einen Bericht über die letzte Stunde des Erfassungszeitraums an.
  2. Der Concentrator ruft Berichte für den Zeitraum zwischen 08:00 und 09:00 Uhr ab.
  3. Um 09:02 Uhr meldet sich der Benutzer „scott“ beim selben Concentrator an und fordert ebenfalls einen Bericht über die letzte Stunde des Erfassungszeitraums an.
  4. Der Concentrator ruft Berichte für den Zeitraum zwischen 08:00 und 09:00 Uhr ab.
  5. Um 09:10 Uhr lädt der Benutzer „scott“ erneut die Berichte für die letzte Stunde des Erfassungszeitraums.
  6. Der Concentrator ruft Berichte für den Zeitraum zwischen 08:10 und 09:10 Uhr ab.

Da der in Schritt 3 zurückgegeben Bericht in das Cache-Fenster fällt, wird er sofort zurückgegeben. Dadurch erhält Scott den Eindruck, dass der Concentrator sehr schnell arbeitet.

Das bedeutet, dass größere cache.window -Einstellungen die wahrgenommene Performance verbessern, auf Kosten kleiner Verzögerungen bis die aktuellsten Daten für die Suche zur Verfügung stehen.

Zeitliche Beschränkungen

Wenn eine Abfrage lange Zeit in einer NetWitness Core-Datenbank ausgeführt wird, dediziert der Core-Service immer mehr CPU-Zeit und RAM, um diese Abfrage schneller abzuschließen. Dies kann sich nachteilig auf andere Abfragen und die Aggregation auswirken. Um zu verhindern, dass Benutzer mit niedrigeren Berechtigungen mehr als ihren Anteil an den Core-Serviceressourcen nutzen, empfiehlt es sich, Abfragen von normalen Benutzern mit zeitlichen Beschränkungen zu versehen.

You are here
Table of Contents > Optimierungstechniken

Attachments

    Outcomes