Prüfung von Datenbanken bei The Grid Teil 2: Beobachtungen nach der Bereitstellung

Im vorherigen Beitrag zu dieser Serie habe ich darüber gesprochen, wie wir die Anforderungen für dieses Projekt gesammelt haben, wie wir eine Entscheidung darüber getroffen haben, welches Tool verwendet werden soll, und wie wir die Bereitstellung geplant haben, um Dienstunterbrechungen zu vermeiden. Wie versprochen konzentriert sich dieser Folgebeitrag auf Beobachtungen nach der Bereitstellung und welche Faktoren dies für uns zu einer Erfolgsgeschichte gemacht haben.

Vorbereitete Anweisungen und Befehlsklassenfilterung

Unser ursprüngliches Design für dieses Projekt zielte darauf ab, eine Funktion im Percona-Plug-In zu nutzen, mit der Sie die ausgegebenen Ereignisse filtern können, um entweder eine Liste der enthaltenen Befehle oder ausgeschlossene Befehle zu verwenden, um den Umfang auf das zu beschränken, was wir tatsächlich prüfen müssen.

Die Funktion beruht darauf, dass das Plugin jeden erkannten SQL-Befehl anhand einer mysql-eigenen Liste mit einer Klasse markiert und von dort in der Ausgabeschicht entscheidet, ob die erkannte Befehlsklasse unterdrückt oder ausgegeben werden soll.

Daher haben wir den ursprünglichen Entwurf geschrieben, um die Funktion „audit_log_exclude_commands“ zu nutzen, um alle SQL-Befehle auszuschließen, die keine Schreibvorgänge oder Änderungen an Zeilendaten verursacht haben. Wir haben uns für eine Ausschlussliste entschieden, weil wir der Meinung waren, dass eine Einschlussliste das Risiko birgt, dass Befehlsklassen im Geltungsbereich fehlen, und ein Grund für Lücken in unseren Audit-Protokollen werden könnte.

Beim ersten von uns getesteten Cluster haben wir jedoch festgestellt, dass alle geprüften Befehle als Fehler klassifiziert wurden, obwohl klar war, dass diese Anweisungen erfolgreich ausgeführt wurden und dies im Falle einer Änderung der Daten auch erfolgreich geschah. Wir haben auch gesehen, dass alle Abfragen unabhängig von dieser Ausschlussliste, die mit dieser Fehlerklassifizierung korreliert zu sein scheint, an den zentralisierten Syslog-Server gesendet wurden.

Das bedeutete, dass wir weitaus mehr Ereignisse in Elasticsearch gespeichert haben, als wir tatsächlich benötigten, was sich definitiv auf unsere Fähigkeit auswirken wird, fehlerhaftes Verhalten zeitnah zu analysieren und zu erkennen. In Zusammenarbeit mit dem Sicherheitsteam haben wir beschlossen, Percona über den Bugtracker über das Problem zu informieren, aber auch die befehlsbasierte Filterung auf die zentrale Syslog-Ebene zu verlagern.

Wie alles in der Technik bestand der Kompromiss hier darin, mehr Daten durch die DB-Netzwerkschicht zu senden und die Filterung in der zentralisierten Syslog-Schicht komplexer zu gestalten, was im Gegenzug unsere Anforderungen an die elastische Suchskalierung überschaubarer und die Konfiguration auf der Datenbankseite einfacher machte.

Leistung

Eine der wichtigsten Entscheidungen in diesem Projekt, die uns viel Kummer erspart hat, ist die Entscheidung, die rsyslog-Funktion zu verwenden, um diese Protokolle abzufangen und an einen zentralen Syslog-Server zu senden.

Aber nichts ist ohne Vor- und Nachteile.

Diese Entscheidung bedeutete, dass die Verfügbarkeit eines separaten Systems und die Zuverlässigkeit des dazwischen liegenden Netzwerkstacks entscheidend für die Bereitstellung der SLA wurden, die wir brauchten, um unserem Prüfungsteam das Vertrauen in diese Prüfungslösung zu geben.

Für diejenigen, die diesen Kompromiss nicht eingehen möchten und die Verantwortung für die Persistenz der Audit-Protokolle innerhalb des DB-Stacks behalten müssen, empfehle ich die Verwendung des FILE -Handlers im Audit-Plugin und dann die Verwendung von lokalem Logstash, um die Protokolle zu übernehmen und sie an ihr Analysesystem weiterzuleiten Auswahl.

Letztere Wahl bedeutet, dass viel mehr Festplatten-IOPs außerhalb des Datenbankprozesses verbraucht und vom Audit-Plug-in und Logstash belegt werden, und es bedeutet, dass Sie den Festplattenspeicher auf Ihren Instanzen sorgfältig zwischen Ihren Datenbanktabellendateien, Betriebsprotokollen und dem Audit ausgleichen müssen Plugin-Protokolle. Das Abwägen Ihrer Optionen hängt ausschließlich davon ab, was für das Unternehmen einfacher zu bedienen / akzeptabel ist, aber Sie haben dennoch die Wahl.

In unserem Fall erwies sich die Wahl von rsyslog als am wenigsten schädlich für unsere ausgelasteten Datenbanken, mit einem Spitzenwert von etwa 5400 Transaktionen/s, während des normalen Betriebs sahen wir keine Auswirkungen auf die Leistung. Das Audit-Plug-In tuckerte mit und sendete seine Ereignisse ohne Auswirkungen auf die Datenbankleistung. Alles nur, weil wir eine Architektur gewählt hatten, die es vermeidet, festplattenbasierte Operationen auf der Datenbankseite zu verbrauchen.

Frühere Entscheidungen zahlen sich aus

Eine der ersten Bedenken, die wir hatten, als wir mit diesem Projekt begannen, war die Auswirkung auf die Leistung. Einer der Datenbank-Cluster im Geltungsbereich war sehr ausgelastet und seine Anwendungen reagieren empfindlich auf Verzögerungen. Daher mussten wir sicherstellen, dass wir Leistungsmetriken wie Transaktionen pro Sekunde, Festplatten- und CPU-Auslastung im Auge behalten, um die Zahlen nach der Bereitstellung des Plugins und zu vergleichen mal sehen was die strafe dafür ist.

Es war eine freudige Überraschung zu sehen, dass wir im normalen Betrieb keine großen Strafen erlitten haben. Da wir uns, wie bereits erwähnt, für die Verwendung des SYSLOG-Handlers entschieden haben, bedeutete dies, dass wir normalerweise keine lokale Festplattenkapazität zum Verfolgen dieser Audit-Ereignisse verwenden mussten.

Wir wollten aber auch nicht nur nach „Normalbetrieb“-Zeiten planen.

Wir mussten auch wissen, dass, wenn rsyslog auf lokale Spooldateien zurückgreifen muss, diese Ereignisse nicht zu Dienstausfällen führen, die sich auf die kritischeren DB-Cluster auswirken. Durch das Testen des rsyslog-Spooling-Verhaltens unter genauer Beobachtung in der Produktion stellten wir fest, dass die Arbeit der letzten Jahre, unsere Datenbanken funktional zu fragmentieren, uns den ungeplanten Vorteil einer Menge Festplatten-IOPs-Kapazität eingebracht hat, um Ereignisse wie das rsyslog-Spoolen auf die Festplatte zu absorbieren, die dann zum erneuten Senden benötigt wurden all diese Veranstaltungen.

Wir haben definitiv die Zunahme der Festplattenauslastung während dieser Ereignisse festgestellt, aber die DB-Instances wurden nie in einen kritischen Zustand versetzt oder die kundenorientierten Aktivitäten beeinträchtigt.

Kompromisse

Wie bei allem in der Softwareentwicklung gibt es immer Kompromisse. In diesem Projekt haben wir eine Protokollbereitstellungsmethode in Betracht gezogen, die zuverlässiger ist und ein geringeres Potenzial für verlorene Protokolle aufweist. Das würde bedeuten, die Protokolle auf die Festplatte zu schreiben und sie dann mit so etwas wie logstash aufzunehmen und an Analyseziele zu senden, die das Sicherheitsteam verwenden kann.

Aber das hätte einen erheblichen Platten-IOP-Verbrauch auf der Datenbankseite bedeutet, von dem wir wussten, dass er möglicherweise die Servicequalität von kundenorientierten Anrufen bei diesen Datenbanken beeinträchtigen könnte.

Wir haben entschieden, dass unsere geschäftlichen Anforderungen ausreichend erfüllt werden, indem wir eine robuste Protokollierung in rsyslog verwenden, einen Spool von angemessener Größe verwenden und TCP verwenden, um die Ereignisse an unseren Protokollüberwachungsstapel zu senden. Wie alles im Leben ist nichts für immer. Und wir sind uns bewusst, dass diese Entscheidung möglicherweise in Zukunft überdacht werden muss.

Endlich

Obwohl dieses Projekt ein halbes Dutzend Cluster und eine große Anzahl von Instanzen umfasste, wurde es in einem einzigen Quartal abgeschlossen, während das DB-Ops-Team in einem immer noch schnell wachsenden Geschäft weiterhin das Licht am Laufen hielt. Das wäre ohne die enge Zusammenarbeit zwischen der DBE und dem Sicherheitsteam nicht möglich gewesen und nicht ohne ein starkes Produktmanagement, das den Umfang begrenzt und bekannt hielt, um sicherzustellen, dass wir alle unser Endziel im Auge behalten, unser Geschäft sicherer zu machen.