lsyncd: inotify + rsync = admin-heaven

Ein Tool welches mir inzwischen an vielen Stellen exzellente Dienste leistet ist lsyncd.

Was macht lsyncd?

lsyncd kombiniert die Vorteile von inotify mit der Funktionalität von rsync. Das bedeutet, lsyncd hält eine entfernte Kopie eines Verzeichnisses dauerhaft auf dem Stand, der dem lokalen Verzeichnis entspricht.

Technisch gesehen beginnt lsyncd beim Start mit einen vollen rsync-Lauf, setzt aber gleichzeitig auf alle zu überwachenden Verzeichnisse und Unterverzeichnisse inotify-Watches. Alle Änderungen am Datenbestand werden jetzt vom Kernel an lsyncd gemeldet. Dieser Sammelt diese Meldungen und initiiert dann in kurzen Abständen für die geänderten Dateien einen erneuten rsync-Lauf.

Dieses Konzept ist einem periodischem Start von rsync doppelt überlegen. Zum einen erzeugt lsyncd wesentlich weniger Last (IO und CPU) auf dem System, zum anderen sind die möglichen Update-Intervalle deutlich kürzer.

Ok, bis hier habe ich die Möglichkeiten von lsyncd deutlich vereinfacht. Tatsächlich kann man bis ins kleinste Detail Skripten, welche Operationen lsyncd ausführt, wenn es eine inotify-Nachricht bekommt. Es gibt dazu aber drei Standardvorgaben, die für viele Zwecke vollkommen ausreichend sind.

Die Vorgaben sind rsync, rsyncssh und direct. Die ersten Beiden sind im Grunde identisch und gleichen nach dem ersten rsync weitere Änderungen immer per rsync aus. Es gibt bei rsyncssh aber eine Optimierung für die Fälle, in denen Dateien bzw. Verzeichnisse verschoben werden. Diese Verschiebeoperationen werden bei rsyncssh mittels eines per ssh aufgerufenen mv-Kommandos durchgeführt. direct ist nur für die lokale Verwendung geeignet, nach dem ersten rsync werden hier die Dateien per cp, rm und mv aktualisiert.

Das Konfigfile

Den grundlegenden Aufbau des Konfigfiles /etc/lsyncd.conf möchte ich an einem Beispiel auch noch vorstellen.

Der settings-Bereich definiert die Grundeinstellungen für den daemon. Die Option nodaemon kann auf true gesetzt werden, damit lsyncd beim starten nicht in den Hintergrund forkt. Logfile ist klar, statusFile gibt die Position einer von lsync regelmäßig aktualisierten Stausdatei an.

In der Statusdatei findet sich neben einem Zeitstempel Angaben über die ausstehenden Aktionen und die Liste aller inotify-Watches.

Danach folgen ein oder mehrerer sync{…}-Blöcke. Hier werden Quellverzeichnis, Ziel-Host und -Verzeichnis angegeben sowie diverse Optionen für rsync gesetzt.

settings  {
   logfile    = "/var/log/lsyncd.log",
   statusFile = "/var/run/lsyncd.status",
   nodaemon   = false
   }
sync {
   default.rsyncssh,
   source    = "/var/www/",
   host      = "10.0.0.2",
   targetdir = "/var/www/",
   delete = true,
   rsync = {
     archive = true,
   }

  sync {
    ...
  }

  ...

}

In diesem Beispiel wird als der Ordner /var/www zum Zielhost 10.0.0.2:/var/www gesynct. Zusätzlich wird lsync angewiesen Löschungen auch auf dem Ziel durchzuführen und die rsync-Option -a wird gesetzt.

Wie oft ein Abgleich durchgeführt wird steuert man mit den Optionen delay und mayDelays. Delay gibt die Zeit in Sekunden an, in denen lsynd Ereignisse bis zum nächsten Abgleich sammelt und maxDelays die Anzahl Ereignisse, nach denen lsyncd einen Abgleich startet auch wenn delay noch nicht abgelaufen ist. Ein Durchlauf wird also gestarten, wenn entweder delay Sekunden vergangen sind oder schon mayDelays Ereignisse gesammelt wurden.

Wozu nutzt man das jetzt?

Vielleicht überall wo man bisher rsync verwendet hat? Ich werde hier mal ein paar Szenarien vorstellen.

Cheap Failover

Das Szenario finde ich überaus nett. Man kann mit lsync und mysql-Replikation so ziemlich alle bekannteren CMS, Shop- oder Blogsysteme ausfallsicher machen. Ich synce also /var/www und die Datenbanken auf einen zweiten Server bei einem anderen Hoster, stellt die TTL im DNS halbwegs niedrig ein (z.B. 30 min). Wenn der Webserver stirbt setze ich im DNS die IP auf den Standby-Knoten und fertig.

Natürlich ist das kein tolle Umschaltzeit, es können sogar Datenverluste auftreten, aber für sehr viele Fälle ist das dennoch mehr als ausreichend. Im Gegenzug ist so ein Setup schnell aufgebaut, wenig komplex und komplett Providerunabhängig. Kosten-Nutzen-Mäßig absolut unschlagbar.

Cheap Undelete

Man nehme einen billigen PC, ein paar günstige Festplatten, btrfs oder zfs und synce seinen Fileserver auf diese Kiste. Dazu ein kleiner Cronjob der fleißig Snapshots erzeugt und alte löscht und fertig ist eine Lösung, mit der ich den Usern ihre gerade gelöschten Dateien wiederherstellen kann. Wer will kann auch seine Backup gegen diesen Host fahren und so die Last vom Fileserver nehmen. Nicht unbedingt Enterprise-Tauglich aber für KMUs erschwinglich und erstaunlich effektiv.

Monitoring nicht vergessen

Der lsyncd ist recht robust gegenüber Netzwerkstörungen, aber auch nicht komplett crashsicher. Daher fahre ich in meinem Monitoring ein kleines Skript gegen das lsyncd-Logfile, welches ein Hängen oder Abstürzen des Daemons erkennt und mich entsprechend alarmiert. Simple aber effektiv.

 

Dieser Beitrag wurde unter Allgemein veröffentlicht. Setze ein Lesezeichen auf den Permalink.

3 Kommentare zu lsyncd: inotify + rsync = admin-heaven

  1. Stephan sagt:

    Hallo, ein wirklich informativer Artikel. Was mich dabei noch interessiert, ist die Realisierung des angesprochenen monitorings. Wie wurde dies umgesetzt?

    Gruß
    Stephan

    • Nils Jürgens sagt:

      Hallo Stephan,

      derzeit werte ich mit einem Skript das Logfile
      /var/log/lsyncd.log
      aus. Das Auswertskript gibt Nagios-like Rückgabewerte zurück, kann also als Nagios-Plugin verwendet werden.

      Das Skript such am Ende der Datei nach Einträgen wie diesem:
      Tue Oct 8 16:58:13 2013 Normal: Finished (list): 0
      parst das Datum und vergleich diesen mit dem aktuellen Datum. Ist der Zeitabstand zu groß gibt es eine Nagios-Meldung.

      schöne Grüße,
      Nils

  2. Wenn auf meine servern ein Daemon hängen sollte (kommt recht selten vor) dann startet meine Überwachung dieser Daemon neu, und benachrichtet mir. Zur diesen Zweck habe ich Zabbix in unseren Datenzentrum am laufen.

    Danke für dieser Artikel, fand es auch informativ. Habe letzte Woche mal mit lsyncd gespielt, arneite zurzeit aber weiter mit rsync über ssh, einfach weil es auch problemlos läuft.

    Gr aus Holland 🙂

    Herman

Kommentare sind geschlossen.