OSDC-Ticker: PostregSQL Replikation & Distributed File Systems

Michael Renner informiert in seinem Vortrag über den aktuellen Status bei PostgeSQL und über verschiedene Replikationsmechanismen für PostgreSQL. Dabei stellt er sowohl die Historie mit Trigger basierter Replikation bzw. Logshipping, als auch die aktuellen Möglichkeiten der Live Migration, die fest im Daemon verankert ist. Verfügbar ist diese Funktionalität ab Version 9.0 des Datenbanksystems.
Einer der letzten Vorträge des gestrigen Tages von Fabrizio Manfred befasste sich mit verschiedenen Distributed File Systems, die als Open Source verfügbar sind. Er beginnt mit OpenAFS, einer Implementierung des Andrew Filesystems von IBM. Nach seiner Erfahrung lassen sich damit 40-50 MB/s erreichen. Es eignet sich gut für wesentlich mehr Reads als Writes und viele Clients. Als zweites stellt er GlusterFS vor, das auch bei sehr großen Datenmengen annähernd linear skaliert. Viele Features, die sich auch gut kombinieren lassen, machen es zu einem sehr flexiblen Werkzeug. Es eignet sich gut für große Datenmengen, Zugriff mit verschiedenen Protokollen und als Ersatz für teure SANs. Nachteil sind die geringen Security Einstellungen und schlechte Performance, wenn viele Aktionen auf ein und dem selben File stattfinden.
Ein weiteres Beispiel ist HDFS (Hadoop FS), das vom Google Filesystem und Mapreduce inspiriert ist. Die Namenodes verwalten die Metainformationen, während die Datanodes die eigentlichen Daten bereitstellen. Es bietet RW Replication und auch Re-Balancing und eignet sich sehr gut für Task- und Content-Distribution, dafür ist es kein Standard Filesystem und nicht Posix kompatibel. Das letzte Beispiel ist ceph, das einen ähnlichen Aufbau wie HDFS hat. Ein großer Vorteil ist, dass ceph Daten automatisch je nach Zugriffshäufigkeit neu umvorteilen kann. Für Fabrizio ist ceph damit das interessanteste DFS. Einziger Nachteil ist das relativ junge Alter, da es noch nicht so viel Erfahrung damit gibt.
Am Ende des Vortrags stellte er verschiedene Real-World Szenarien im Detail inkl. genauer Architektur vor, die auf OpenAFS, GlusterFS oder Hadoop basieren. Einige interessante Lessons learned aus diesen Projekten, die man schon am Anfang bedenken sollte: Bei 10PT Speicher fallen jeden Tag im Durchschnitt 22 Festplatten aus. Auch dafür sollte man vorbereitet sein und alleine diese Daten inkl. aller weiteren Änderungen müssen im Netz repliziert werden. Eine spätere Migration kann schon alleine deswegen aufwendig werden, weil das umkopieren von 1PB mit aktuellen Netzanbindungen bis zu 2 Jahre dauern kann.

CeBIT Live 2010: Vortrag auf dem Open Source Forum

Nach dem starken Andrang am zweiten Tag auf der CeBIT hatten ich gerade eben auch noch die Chance auf dem CeBIT Open Source Forum des Linux Magazins einen Vortrag über die Online Nagios Schulungen zu halten (wir berichteten bereits hier).
In der Präsentation wurde kurz in 15 Minuten vorgestellt wie die Schulungen aufgebaut sind und welcher Inhalt in den einzelnen Sessions vermittelt wird. Vielen Dank an dieser Stelle noch mal an die Kollegen vom Linux Magazin und von Techcast für die angenehme Zeit in München.
Angemerkt sei auch noch das speziell zur CeBIT eine Rabattaktion für die Schulungen aufgelegt wurde, wer also Interesse hat gleich unter http://academy.linux-magazin.de/ zuschlagen.
Anbei noch ein Bild wie die Schulungen Online präsentiert werden:

Hier noch die Präsentation mit den Schulungsinhalten:
Online Training

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Im vierten Teil der NSClient++ Serie geht es um die Überwachung des Windows Eventlogs und weitere kleine Features des NSClients wie z.B. check_multiple.
Die Prüfung des Windows Eventlogs kann über mehrere Wege stattfinden.
In unserer Serie erfolgt die Prüfung über CheckEventlog und die dazugehörige Filtersprache, durch Angabe verschiedener Filter sind auch hier komplexe Abfragen möglich. Beispielsweise kann mit folgender Abfrage auf vorkommen von Fehlermeldungen (nicht success) innerhalb des Systemlogs geprüft werden die einen Tag alt sind und von einem Service erzeugt wurden. Eine CRITICAL Meldung wird in diesem Fall ab dem ersten Treffer erzeugt.

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckEventLog -a file=system filter=new filter=out filter-eventType==success filter+eventSource=substr:Service 'filter-generated=>1d' MaxCrit=1

Dabei wird ausgegeben welche Services den Fehler verursacht haben, zur genaueren Diagnose sollte dann das Eventlog herangezogen werden.
Die Ausgabe kann je nach Gusto noch mit verschiedenen Parametern angereichert werden. Zu finden ist die Dokumentation der Filtersprache unter http://www.nsclient.org/nscp/wiki/CheckEventLog/CheckEventLog
Ein weiterer interessanter Check des NSClients ist im Modul CheckHelpers enthalten. Das Kommando CheckMultiple ermöglicht es ähnlich zu check_multi unter Linux/Unix in einem Connect mehrere Abfragen auszuführen. CheckMultiple erwartet als Argumente die auszuführenden Checks, um Beispielsweise die Festplattenauslastung sowohl auf prozentualer als auch auf absoluter Basis zu messen kann beispielsweise dieses Kommando verwendet werden:

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckMultiple -a command=CheckDriveSize Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long command=CheckDriveSize Drive=c MinWarnFree=2G MinCritFree=1G ShowAll=long
WARNING: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%) > warning, OK: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%)|'c:'=90%;80;95; 'c:'=36.00G;37.99;38.99;

Die Verknüpfung der von CheckMultiple ausgeführten Prüfungen ist immer oder, d.h. der schlechteste Status der ausgeführten Subprüfungen wird immer in das Ergebniss übernommen. In unserem Testfall ist die Prüfung also ein WARNING Status. Die Textuelle Ausgabe der beiden Prüfungen wird ausschließlich bei den Performancedaten kombiniert, so bleibt jede Information der eigentlichen Prüfungen erhalten.

Serie NSClient++ – Teil 3: Basisüberwachung

Nachdem in Teil eins und zwei der Blogserie über den NSClient++ die Grundlagen und Installation durchgeführt wurden kann es nun ans Überwachen der ersten Komponenten gehen. Ziel dieses Teils ist es eine Basisüberwachung des Betriebssystems abzudecken, daraus ableiten lässt sich dann auch eine erweiterte Überwachung diverser Dienste, Festplattten oder Prozesse.
Die Kommunikation hin zum Client erfolgt über das Plugin check_nrpe, wichtig hierbei ist NRPE mit aktivierten Kommandoargumenten übersetzt zu haben. Die benötigte Option hierfür heißt “–enable-command-args” und muss zur Kompilezeit angegeben werden.
Generell funktionieren die verschiedenen Abfragen ähnlich, einzig das auszuführende Kommando (Parameter “-c”) und die dazugehörigen Argumente (Parameter “-a” für check_nrpe) unterscheiden sich je nach Prüfung.
Ein Beispielhafter Aufruf für die Prüfung der CPU Auslastung über einen Zeitraum von 5 Minuten sieht wie folgt aus:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long

Sieht das Ergebnis wie gewünscht aus können wir uns den weiteren Checks widmen. Als Basisüberwachung werden folgende Prüfungen auf jedem Windowssystem eingerichtet:

  • CPU Auslastung (80% Warning, 95% Critical, 5 Minuten Messintervall)
  • Festplattenauslastung (80% Warning, 95% Critical)
  • Speicherauslastung (70% Warning 85% Critical)
  • Uptime
  • Server Dienst

Die Kommandozeilen für die genannten Prüfungen:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
OK: 5m: average load 1%|'5m'=1%;80;95;
$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckDriveSize -a Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long
OK: c:: Total: 40G - Used: 24.6G (61%) - Free: 15.4G (39%)|'c:'=61%;80;95;
$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckMEM -a MaxWarn=70% MaxCrit=85% type=physical ShowAll=long
OK: physical memory: Total: 2G - Used: 840M (41%) - Free: 1.18G (59%)|'physical memory'=41%;70;85;
$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckUpTime -a ShowAll=long
OK: uptime: 0:13
$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckServiceState -a Server
OK: All services are in their apropriate state.

Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:

define command {
        command_name    check_win_load
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=$ARG3$ ShowAll=long
}
define command {
        command_name    check_win_drive
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckDriveSize -a Drive=$ARG1$ MaxWarnUsed=$ARG2$ MaxCritUsed=$ARG3$ ShowAll=long
}
define command {
        command_name    check_win_mem
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckMEM -a MaxWarn=$ARG1$ MaxCrit=$ARG2$ type=physical ShowAll=long
}
define command {
        command_name    check_win_uptime
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckUpTime -a ShowAll=long
}
define command {
        command_name    check_win_service
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckServiceState -a $ARG1$
}

Serie NSClient++ – Teil 2: Installation

Für die Installation des NSClient++ zur Windowsüberwachung gibt es generell zwei Möglichkeiten.
Variante eins ist die Installation auf Basis von zum Download bereitstehenden MSI Paketen. Bei dieser Installationsweise werden während des Installationsvorgangs die benötigten Parameter abgefragt.
Bei der zweiten Installationsvariante wird das ZIP Archiv heruntergeladen und auf die Systeme ausgerollt. Vorab sollte allerdings eine Anpassung der globalen Konfigurationsdatei “nsc.ini” erfolgen um die gewünschten Parameter zu setzen. Danach kann dieses Archiv einfach auf beliebig viele Rechner verteilt werden, wobei nach Entpacken des Archives manuell der Windows-Dienst registriert und gestartet werden muss.
Die Registrierung und der Start des Dienstes erfolgt in einer Kommandozeile mit den Befehlen:

# nsclientpp.exe -install
# net start nsclientpp

Beiden Installationswegen gemein ist jedoch der automatische Start des “nsclientpp” genannten Dienstes beim nächsten Neustart des Systems. Wer sich für den manuellen Installationsweg entscheidet muss in der NSC.ini folgende Parameter an die vorhandene Umgebung
Aktivieren der gewünschten Checks in derr [modules] Sektion:

FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll

Durch die Aktivierung der oben genannten DLL’s wird die Funktionalität des NSClient++ bestimmt, eine Erklärung der Funktionen innerhalb der Bibliotheken findet sich in der Dokumentation unter http://www.nsclient.org/nscp/wiki/CheckCommands
Anpassungen im [settings] Abschnitt:

allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1

Die Direktive use_file weist den NSClient an die Konfigurationsdatei anstatt von Registryeinträgen zu verwenden. Bei der Installation wird also lediglich der Dienst registriert, weitere Einstellungen werden nicht in die Windows Registrierung geschrieben.
Zusätzlich müssen noch Kommandoargumente und Sonderzeichen für diese freigeschalten werden, dazu gibt es in der Sektion [NRPE] folgende Parameter die jeweils auf 1 zu setzen sind:

allow_arguments=1
allow_nasty_meta_chars=1

Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:

# net stop nsclientpp
# net start nsclientpp

Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:

# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion

Als Antwort des Clients wird hierbei die Versionsnummer der aktuell Installierten NSClient Version zurückgegeben. Sollten hier Fehler auftreten bietet der NSClient die Möglichkeit den Dienst über eine Kommandozeilenoption in den Debugmodus zu schalten und so eventuell auftretenden Fehler zu lokalisieren. Dazu wird als erstes der Dienst gestoppt und der NSClient manuell mit der Option “-test” gestartet.

# net stop nsclientpp
# nsclientpp.exe -test

Serie NSClient++ – Teil 1: Grundlagen

nswideZur Überwachung von Windows Servern mit Nagios oder Icinga hat sich mittlerweile der NSClient++ als Agent auf dem System etabliert.

Er bietet die Möglichkeit sowohl per “check_nt” als altes Verfahren und auch mittels NRPE Abfragen auf dem Windows System durchzuführen. Grundsätzlich sind die Abfragen in verschiedene Module gegeliedert, nennenswert an dieser Stelle sind:

  • CheckDisk – prüft die Festplattenauslastung
  • CheckEventLog – prüft Einträge im Eventlog
  • CheckSystem – prüft Prozesse, Dienste, CPU Auslastung, …

sowie

  • CheckHelpers – biete weitergehende Möglichkeiten zur Prüfungsausführung

Jedes dieser genannten Module bietet diverse Sub-Module um Abfragen auszuführen, die Parametrisierung der einzelnen Checks ist hierbei ähnlich.
Im weiterem Verlauf der Blogserie werden die Installation und Konfiguration wie auch diverse Checks und deren Aufruf vorgestellt. Die Kommunikation zum überwachten System findet hierbei ausschließlich per verschlüsseltem NRPE statt.

Sensation des Tages – Überwacht durch NAGIOS

Neckermann Logo
Heute bekamen wir von einem unserer Kunden einen etwas individuellen Consultingauftrag.
Der neckermann.de Webshop bietet zur Weihnachtszeit eine “Sensation des Tages” also ein Produkt das sich häufig ändert und besonders günstig zu erwerben ist an.
Verständlicherweise wird dieser Artikel sehr stark nachgefragt und dadurch auch häufig ausverkauft. Die Verfügbarkeit dieser Sensation wird nun mit Nagios überwacht per HTTP Abfrage minütlich überwacht, im Falle des Ausverkaufs eines Artikels kann so schnell reagiert und eine neue Sensation nachgelegt werden.

Maatkit – die Toolbox für MySQL Server

maatkitEin Kollege hat mich vor kurzem auf Maatkit aufmerksam gemacht, eine Sammlung von Tools die laut dem Ersteller (Baron Schwartz) das Leben bzw. Arbeiten mit MySQL deutlich einfacher und sicherer machen.
Maatkit enthält viele nützliche Werkzeuge sowohl für single instance Installationen als auch komplexere Replikationsszenarien, so gibt es z.B. mk-heartbeat welches die Replikation überwacht. Hierbei wird auf dem Master ein kontiunierliches UPDATE mit dem aktuellen Timestamp auf einen Eintrag ausgeführt, ein zweiter mk-heartbeat Prozess überwacht auf den Slaves den Replication lag. Die Überwachung beruht also nicht auf dem MySQL internen ‘SHOW SLAVE STATUS;‘ Kommando.
Folgende Kommandos erzielen das gewünschte Ergebnis:

  • Master
# mk-heartbeat -D test --table maatkit --update
  • Slave
# mk-heartbeat -h <slave-host> -D test --table maatkit --monitor
3s [  0.08s,  0.02s,  0.01s ]
4s [  0.15s,  0.03s,  0.01s ]
5s [  0.23s,  0.05s,  0.02s ]
6s [  0.33s,  0.07s,  0.02s ]

Ein weiteres mitgeliefertes Programm ist mk-parallel-dump, eine deutlich performantere Alternative zu mysqldump. Wie der Name schon andeutet ermöglicht es dem Benutzer das Sichern einer Datenbank mit mehreren Tabellen in parallel, mit mysqldump werden die Tabellen sequentiell nacheinander gesichert. Zusätzlich erlaubt es “Backup Sets” zu erstellen um logisch zusammenhängende Tabellen (auch Datenbankübergreifen und mit Prioritäten versehen) gleichzeitig zu sichern.

mk-parallel-dump –base-dir /var/tmp –password t3fzpcay
default:            397 tables,   397 chunks,   397 successes,  0 failures,  22.79 wall-clock time,  33.41 dump time
# mk-parallel-dump --base-dir /var/tmp
default:  397 tables, 397 chunks, 397 successes, 0 failures, 22.79 wall-clock time, 33.41 dump time

Ein Tool zum Restore der erstellten Backups ist selbstverständlich ebenfalls enthalten: mk-parallel-restore.
Zusätzlich zu den hier genannten gibt es noch Tools um MySQL Query EXPLAINs übersichtlicher darzustellen, Table Checksummen zu errechnen, Tabellen nach Filtern zu Archivieren und noch vieles mehr. Ein Blick auf die Webseite des Projektes loht in jedem Fall.
Als Fazit lässt sich festhalten das Maatkit die Arbeit mit MySQL deutlich vereinfacht. Jeder der täglich mit MySQL zu tun hat wird dieses Toolkit kennen und lieben lernen, es vereint viele  nützliche Funktionen in einem und ist obendrein bei einigen Distributionen enthalten.

Serie High Performance Websites – Zusammenfassung

LogoZusammenfassung der Serie über High Performance Websites.
In dieser Artikelserie haben wir versucht einen kurzen Einblick in die Optimierung von Server, Sourcecode und Infrastruktur in Bezug auf Performance zu geben.
Für Feedback oder Anregungen sind wir selbstverständlich jederzeit offen und freuen uns über jede Kontaktaufnahme.

Partnerschaft mit der Knürr AG

knuerrBereits auf der CeBIT im März diesen Jahres hatte ein erster Kontakt mit der Knürr AG stattgefunden um eine mögliche Kooperation in den Bereichen Monitoring von Rechenzentrumskomponenten mit Nagios/Icinga anzustoßen. Zusätzlich wurde eine Zusammenarbeit im Hardwarevertrieb über unseren  Shop vereinbart, inzwischen trägt diese Partnerschaft auch schon erste Früchte.
Entstanden sind bisher zwei Nagios bzw. Icinga Plugins für die Überwachung der Knürr RMS und PDU Komponenten, zu finden sind die beiden Plugins check_knuerr_pdu und check_knuerr_rms auf MonitoringExchange.
Die Abfrage ist hierbei mittels SNMP auf sämtliche E/A Schnittstellen möglich, auch das brandneuen DI-VIEW zur Messung des Stromverbrauchs über die Zuleitung direkt am Kabel wird bereits unterstützt und kann direkt in das Monitoring integriert werden.
Aktuell sind wir gerade dabei die ersten Hardwarekomponenten im Shop zu platzieren, desweiteren haben sich auch schon erste Synergien für Projekte ergeben, wir freuen uns auf eine lange und erfolgreiche Zusammenarbeit.
Vielen Dank an dieser Stelle für die Kontaktaufnahme auf der CeBIT 2009.