WorNet sichert Domains mit DNSSEC


Kann Ihre Domain DNSSEC? Schnell geprüft:
http://dnssec-debugger.verisignlabs.com/

DNS ist eines der zentralen Systeme des Internets. Umso erstaunlicher ist die Tatsache, dass DNS immer noch weitestgehend ungesichert betrieben wird. Verschlüsselung oder Signierung bei DNS? Fehlanzeige! Für DNS existiert allerdings seit einigen Jahren ein Standard namens  DNSSEC, der eigentlich für Sicherheit sorgen sollte. Dies geschieht bei DNSSEC mit Hilfe von kryptografisch signierten DNS-Records. Die Schlüsselkette muss dabei von allen an einer DNS-Rekursion beteiligten Nameservern bis zum Trust-Anchor bei den Top-Level-Registraren konsistent sein, so, dass der Empfänger die Herkunft von DNS-Antworten eindeutig validieren kann. Bislang können DNS-Abfragen ohne DNSSEC abgefangen und beliebig verändert werden. Damit könnte ein Angreifer beispielsweise durch Manipulation von DNS-Paketen eMails oder HTTP-Anfragen auf einen anderen Server umleiten. Diese Signierung verhindert nun unbemerktes Verändern der DNS-Inhalte.

Weiterlesen

SecuMail sichert E-Mail Übertragung mit DANE


Eine moderne Technik zur zusätzlichen Absicherung von TLS-gesicherten Diensten wie z.B. SMTP oder HTTP heißt:
DANE (DNS-based Authentication of Named Entities)

Warum?
DANE hilft dabei die alten und bekannten Schwächen der verbreiteten TLS-Sicherung zu beheben, indem es unabhängig von der Vertrauenswürdigkeit einer Zertifizierungsstelle ein sicheres Verfahren zur Validierung von SSL-Schlüsseln ermöglicht. Dies ist erforderlich, da jede Zertifizierungsstelle als single point of failure zu betrachten ist. Wird sie kompromitiert, dann sind sämtliche Sicherheits-Maßnahmen, die auf den ausgestellten Zertifikaten basieren, unbrauchbar. Dabei hat der Anwender jedoch weder Einfluß auf die Sicherung seiner Zertifizierungsstelle, noch auf deren  Informationspolitik im Falle eines relevanten Problems.

DANE-Screenshot

Weiterlesen

E-Mail-Firewall: Diese Dateiformate sollten sie blockieren


Ransomeware  wie Locky oder TeslaCrypt  kann ganze Unternehmen lahmlegen. Der Verschlüsselungstrojaner Locky schlägt derzeit besonders große Wellen: Er kommt via Dateianhängen in E-Mails, zumeist in Makros z.B. in veralteten MS-Office-Dateien oder auch in Java-Script-Code (.js Dateien). Aktuell blockiert unser Filterservice SecuMail auch zunehmend E-Mails mit Dateianhängen im .jse-Format – eine neue Angriffswelle von Locky. Wir erklären Ihnen in diesem Beitrag, welche Dateiformate in Ihrem Postfach generell nichts verloren haben und blockiert werden sollten.

Weiterlesen

Änderung der SecuMail-Filterung bei alten Officedateien


secumail-logo

vor einer guten Woche hatten wir schon einmal DOC-Dateien temporär gesperrt, weil darüber gehäuft Makro-Viren auftraten. Leider tritt das Problem seit Sonntag wieder massiv auf. Virenscanner helfen dagegen nur bedingt, da zwischen dem Auftreten einer neuen Viren-Variante und der Erkennung durch die Virenscanner immer einige Stunden liegen. Das gilt für die zwei von uns verwendeten Virenscanner ebenso wie für den Virenscanner bei Ihnen im Unternehmen. Erschwerend kommt hinzu, dass der eigentliche Schadcode dieser Makroviren in der eMail selbst nicht enthalten ist, sondern erst im MS-Office Programm durch ein Makro nachgeladen wird. Weiterlesen

Creating multiple bonding interfaces in Ubuntu 14.04 LTS


Hi,

I wanted to share some learnings about bonding configuration which I could not find elsewhere.

 

„Bonding, also called port trunking or link aggregation means combining several network interfaces (NICs) to a single link, providing either high-availability, load-balancing, maximum throughput, or a combination of these.“ [1]

Bonding is an essential technology for highly available Linux systems. Thankfully all major distributions support bonding in some way. In Ubuntu you can easily create a bonding interface in /etc/network/interfaces. But this is only supported for a single interface.

What if you need bond0 and bond1 or even more independent bonding interfaces, maybe with different modes of operation?

We currently introduce Ceph in our datacenter so I wanted two logical interfaces (for the Public and Cluster network) with a primary 10GBit primary and a 1 GBit backup physical interface.

10G-1G-Interfaces

fast and highly available: multiple 10GBit Interfaces with 1 GBit backup interfaces with Ubuntu 14.04 LTS

I found many recipes which relied on modprobe. But in order to create multiple bonding interfaces the bonding module needs to be loaded into the kernel several times, e.g.:

modprobe bonding -o bond0 mode=active-backup miimon=100 primary=eth2 max_bonds=2
modprobe bonding -o bond1 mode=active-backup miimon=100 primary=eth3 max_bonds=2

This method however doesn’t work with Ubuntu 14.04, because modprobe is now kmod and -o is no longer supported.

The solution is to use the Sysfs-Interface of the bonding module and to create and configure the bonding interfaces yourself during the upstart process:

  1. you must not load the bonding module in /etc/modules because this immediately triggers the networking configuration, but you cannot configure bonding once the interface is up
  2. Use a custom Upstart Configuration to create the bonding interfaces manually (see /etc/init/bonding.conf below)
  3. use a script to create bonding interfaces (see listing below)
  4. now you can configure the interfaces and enslave physical interfaces in /etc/network/interfaces in the usual way

Good luck and may the uptime be with you,

Christian

 

/etc/init/bonding.conf

# bonding interfaces

description    "bonding interfaces"

start on (startup
   and started udev)
# stop on runlevel [!2345]

umask 022

script
   /usr/local/tools/create_bond_interface.sh -v -i bond0 -m 1 -p eth2
   /usr/local/tools/create_bond_interface.sh -v -i bond1 -m 1 -p eth3
end script

create_bond_interface.sh:

#! /bin/bash

VERBOSE=0
INTERFACE=bond0
MODE=1
PRIMARY=eth0
PROGRAMNAME=$0

usage () {
   echo "Usage: $PROGRAMNAME [-v] [-h] [-i INTERFACE] [-m MODE] [-p PRIMARY]"
   echo
   echo "   -v           be verbose"
   echo "   -h           this help"
   echo "   -i INTERFACE create bonding Interface (default: bond0)"
   echo "   -m MODE      bonding mode"
   echo "   -p PRIMARY   only Mode 1: Primary Interface"
   exit 1
}


while getopts ":hvi:m:p:" opt; do
   case $opt in
      h)
         usage
         ;;
      v)
         VERBOSE=1
         ;;
      i)
         INTERFACE=$OPTARG
         ;;
      m)
         MODE=$OPTARG
         ;;
      p)
         PRIMARY=$OPTARG
         ;;
      \?)
         echo "Invalid option: -$OPTARG" >&2
         usage >&2
         exit 1
         ;;
      :)
         echo "Option -$OPTARG requires an argument." >&2
         exit 1
         ;;
   esac
done

# load bonding module
modprobe bonding

# create bonding interface if it doesn't exist
EXISTING_BONDS=`cat /sys/class/net/bonding_masters`
echo " $EXISTING_BONDS " | grep " $INTERFACE "  >/dev/null
if [ $? -gt 0 ] ; then
   echo "+$INTERFACE" >/sys/class/net/bonding_masters
fi

# check if interface exist now
if [ -d /sys/class/net/$INTERFACE ]; then
   echo $MODE >/sys/class/net/$INTERFACE/bonding/mode
   echo 100 >/sys/class/net/$INTERFACE/bonding/miimon
   if [ ! _$PRIMARY == _ ]; then
      echo $PRIMARY >/sys/class/net/$INTERFACE/bonding/primary
   fi
else
   echo "Creation of Interface $INTERFACE failed"
   exit 1
fi

if [ $VERBOSE -gt 0 ]; then
   echo -n "Bond Interfaces:    "
   cat /sys/class/net/bonding_masters
   echo    "Interface created:  $INTERFACE"
   echo -n "Bonding mode:       "
   cat /sys/class/net/$INTERFACE/bonding/mode
   echo

   cat /proc/net/bonding/$INTERFACE

fi

ifconfig $INTERFACE up

exit 0

Example /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
   address AA.BB.CC.DD
   netmask 255.255.255.0
   gateway AA.BB.CC.XX
   dns-search MY.DOMAIN
   dns-nameservers NAMESERVERS
   pre-up ifenslave bond0 eth0 eth2
   post-down ifenslave -d bond0 eth0 eth2

auto bond1
iface bond1 inet static
   address WW.XX.YY.ZZ
   netmask 255.255.255.0
   pre-up ifenslave bond1 eth1 eth3
   post-down ifenslave -d bond1 eth1 eth3

Troubleshooting

* Status via /proc-Filesystem. Erfolgreiches Interface z.B.:

root@s3cn1:~# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth2 (primary_reselect always)
Currently Active Slave: eth2
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:30:48:64:db:b2
Slave queue ID: 0

Slave Interface: eth2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: f4:52:14:3d:fe:70
Slave queue ID: 0

* Upstart-Logfile:

root@s3cn1:~# cat /var/log/upstart/bonding.log
----------------------------------------------------
Bond Interfaces:    bond0
Interface created:  bond0
Bonding mode:       active-backup 1

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: None
MII Status: down
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

----------------------------------------------------
Bond Interfaces:    bond0 bond1
Interface created:  bond1
Bonding mode:       active-backup 1

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: None
MII Status: down
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Modulares Web-Cluster Hosting


Der modulare WordPress-Cluster


Beispiel Zeitschriften-Fachverlag

Seit Mitte 2013 betreiben wir ein weiteren Web-Cluster, diesemal für einen bekannten Münchener Zeitschriften-Fachverlag. Das System hostet gleich mehrere News-Portale des Verlages, welche alle von einer gemeinsamen WordPress Instanz geliefert werden. Unsere Aufgabe dabei ist die Installation und der Betrieb des Clustersystems, während eine Webagentur die Installation und Pflege der WordPress-Installation übernimmt. Inhaltlich legt der Verlag selbst Hand an.

Weiterlesen

vSphere 5.5 Flash Read Cache: Performance und Praxis


vSphere 5.5 führt ein neues Feature namens vSphere Flash Read Cache (vFRC) ein. Das beschleunigt Lesezugriffe im SAN durch einen Cache lokaler SSD-Laufwerke.

Ein spannendes neues Feature – Grund genug das im Labor auszuprobieren

Die Testumgebung besteht aus einem HP Microserver N54L mit einer Samsung PRO 840 SSD (128 GB) und einer Benchmark-VM mit fio, die auf einem langsamen Datastore auf einer QNAP TS-210 liegt. Ohne vFRC liegen die Messwerte recht konstant bei knapp 50MB/s Lesedurchsatz (sequential read mit 16MB Blockgröße) und knapp 100 IO/s (random read mit 4K Blockgröße).

Der Test bestand aus zwei Serien mit verschieden großen Caches, die einer virtuellen Festplatte von 50GB zugeordnet waren. Getestet wurde alle 10 Minuten (je 30 Sekunden sequential read und 30 Sekunden random read), die ersten drei Messwerte der abgebildeten Graphen waren Tests ohne vFRC.

vFRC-Benchmark

Man sieht deutlich, dass insbesondere bei 5GB vFRC (10% der Gesamtplattengröße) der Durchsatz und die IO/s signifikant ansteigen. Bei 1 GB vFRC (2% der Plattengröße) scheint sich der Cache nur sporadisch auszuwirken, der Cache stellt nur eine minimale Verbesserung dar.

Zur Ehrenrettung sei gesagt, dass der verwendete Benchmark von den Plattenzugriffen her den Worst-Case für einen Cache darstellt. Die Zugriffe erfolgen rein Zufällig auf Bereiche der 50GB Platte, es gibt keine Hot-Spots, die zu cachen sich besonders lohnen würde. Bei typischen Servern gibt es Daten, die besonders häufig gelesen werden und daher auch einen größeren Performancegewinn versprechen.

Wir gehen davon aus, dass vFRC zumindest bei unseren gehobenen Hostingprodukten zum Einsatz kommen wird.

Einschränkungen bei Einsatz des vSphere Flash Read Cache

In der Praxis gibt es einige Einschränkungen und Fallstricke, die man beim Einsatz des vFRC beachten muss:

  • die virtuelle Maschine muss Hardwareversion 10 haben
  • der vFRC cacht nicht alle SAN-Zugriffe des Host sondern muss den einzelnen virtuellen Festplatten der VMs fest zugeordnet werden (im Unterschied zu SSD-Caches in Storagesystemen)
  • vFRC bringt einen RAM-Overhead auf dem Host mit sich, dieser ist abhängig von der Größe des Cache und der konfigurierten Blockgröße
  • der vFRC stellt eine Ressource dar, die für das Einschalten der VM bereitstehen muss (vMotion auf Host ohne freien vFRC ist nicht möglich)
  • der vFRC ist nicht in die HA-Admission Control integriert. Man kann mehr vFRC zuordnen als bei Ausfall von N Hosts zur Verfügung stehen. Bei CPU und RAM wird man hier gewarnt, bei vFRC muss man das manuell prüfen.
  • vMotion benötigt länger, da die zugeordneten Caches mitkopiert werden
  • Konfiguration nur über den Web-Client
  • vSphere Flash Read Cache setzt Enterprise Plus-Lizenzen voraus

Zum weiterlesen:

Deduplizierender Storage mit dem ZFS-Filesystem


Hallo Kollegen,

wir sind auf der Suche nach einem bezahlbaren Storage-System, das Deduplizieren und Komprimieren kann, und gleichzeitig für hoch produktive Umgebungen geeignet ist. Von einigen Kunden kennen wir die Datadomain von (mittlerweile) EMC, die zwar verblüffend hohe Performance bei optimalen Deduplizier-Raten leistet, jedoch auch erst für entsprechend verblüffende Preise zu haben ist. Wir fragen uns, was zum Beispiel Opensource hier beitragen kann? Bekannte Projekte sind ZFS und Opendedup. Nachdem ZFS auch als Kernelmodul vorliegt und eine weitaus größeres Featureset aufweist, werden wir uns einige Zeit (es wurden mehrere Monate) mit ZFS beschäftigen. Dabei geht es in dieser Reihenfolge um ZFS-Verstehen, Best-Practise, Versuchsaufbau, Benchmarking/Tests, Setup und Hardware für produktive Maschinen und Deployment.

Ich nehme hier vorweg, dass unser Versuch mit ZFS gescheitert ist. Und zwar am letzten Punkt „Deployment“. Mehrmals haben wir nach erfolgreichen Tests Probleme im Live-betrieb feststellen müssen, die wir letztlich nicht lösen konnten. Aber dennoch ist ZFS grundsätzlich ein interessantes Filesystem, außerdem haben wir bei diesem Versuchsprojekt viele spannende Dinge gelernt.

Warum Deduplizierung und Kompression?

In Zeiten der fortschreitenden Virtualisierung von IT-Technik, ist es üblich viele kleine (lokale) Storage-Systeme durch wenige große zu ersetzen. Das erhöht zum einen die Anforderungen an solche Systeme enorm. Auf der anderen Seite lassen sich dadurch auch Synergie-Effekte erzielen. Große zentrale Systeme bieten in der Regel auch einen höheren Funktionsumfang und rechtfertigen höhere Komplexität und Kosten. Eine gute Voraussetzung für die Einführung eines „schlauen“ Storage-System, mit dem Deduplizierung und Blocklevel-Kompression bei WorNet Einzug erhält. Mit dieser modernen Technik sollte sich der Bedarf an Speicherkapazität in Form von Festplatten reduzieren lassen. Die neuen Systeme sollen wesentlich sparsamer mit ihrem Plattenplatz umgehen und dadurch langfristig Kosten einsparen.

Den neue  ZFS-Storage würden wir als Storage-Server auf entsprechend leistungsfähiger Hardware im Münchener Rechenzentrum aufsetzen. Per ISCSI (oder NFS) an unsere ESX-Hosts angebunden, würden hauptsächlich Platten von virtuellen Maschinen (vmdk-Disks) abgelegt werden, die etwas weniger I/O-Leistung voraussetzen, sondern mehr auf Kapazität im Sinne einer Archivierungs- oder Backup-Lösungen.

Was kann ZFS?

ZFS, das Zettabyte File System ist von Sun entwickelt und zum ersten mal 106 Released worden. Es kann theoretische extrem große Datenmengen verwalten, nämlich bis zu 16 Exabyte ( 1018 Byte = 1.000.000.000.000. GByte). Das Copy-On-Write Dateisystem hat viele, sehr moderne Funktionen implementiert, und unterscheidet sich damit völlig von den üblichen Dateisystemen wie ext4 oder NTFS. Eine dieser interessanten Eigenschaften ist die Möglichkeit das Storage-System schneller zu machen indem SSD-Platten als Lese-Cache bzw. Schreiblog verwendet werden. Weitere spezielle Funktionen sind:

  • bis zu 16 Exabyte Datenmenge
  • Volume-Manager (vergleichbar mit LVM)
  • Snapshots
  • RAID-Levels (0, 1, 5,6, 10, 50, 60)    (Lesen Sie hierzu: RAID 10 vs RAID 50)
  • online Vergrößerung vorhandener RAID-Sets
  • Copy-On-Write
  • Blocklevel Deduplizierung
  • Blocklevel Komprimierung
  • Tiered-Storage per SSD-Chaches und -Logs
  • Finden und Korrigieren von schleichenden Bit-Fehlern

Angenehm ist bei ZFS auch die sehr gründliche Dokumentation von Sun (mittlerweile Oracle)  und das komfortable Handling der zur Verfügung gestellten Tools namens zpool, zfs und zdb:

  • # Zum Erstellen eines Storage-Pools  (wie LVM-Volumegroup):
    zpool  create -f mainpool mirror sdj sdf mirror sdh sdd mirror sdi sde
  • # Zum Erstellen eines Volumes mit aktivierter Deduplizierung und Kompression:
    zfs create mainpool/volumname
    zfs set compression=on mainpool/volumname
    zfs set dedup=sha256 mainpool/volumname
  • # NFS-Shares können direkt über zfs eingerichtet werden:
    zfs unshare -a
    zfs set sharenfs='rw=@10.97.155.0/24' mainpool/volumname
  • # SSD-caches und Schreiblog hinzufügen:
    zpool add mainpool log mirror sda1 sdb1
    zpool add mainpool cache sda2 sdb2

Softwarepakete

Spätestens bei der ersten Installation fällt auf, dass ZFS nicht ganz so glücklich mit Linux ist. Das liegt zunächst weniger an der Technik, sondern viel mehr an der Lizenz unter der ZFS verbreitet wird, die nicht kompatibel zur GPL des Linux-Kernels ist. Daher kann es keine fertigen Kernel-Implementierungen geben. Die meisten Distributionen machen sich jedoch die Mühe ein ZFS-Paket bereit zu stellen, das kurzerhand während der Installation erst kompiliert, um die Lizenz-Problematik zu umgehen. Das funktioniert erstaunlich gut, kann allerdings auch nicht als Ursache für die später festgestellten, versteckten Stabilitätsprobleme ausgeschlossen werden.

Unter Ubuntu kann ZFS wie folgt installiert werden:

apt-add-repository ppa:zfs-native/stable
apt-get install python-software-properties
apt-get update
apt-get install ubuntu-zfs

ZFS gibt es übrigens nativ auch unter Freebsd. Dazu lohnt es sich das Opensource-Projekt Nas4Free anzusehen, wenn man beispielsweise aus alter Hardware ein ZFS-basierten Storage-Server betrieben möchte. Nas4Free scheint sehr comfortabel und ausgereift zu sein. Für unser Rechenzentrum ist es dann widerum zu eingeschränkt (Freebsd Treiber etc) und zu wenig performant.

Unser Hardware-Setup

Getestet wird gleich auf der Hardware, die auch später zum Einsatz kommen wird. Nachdem vor allem die Deduplizierung viele Ressourcen verschlingt, insbesondere RAM, verbauen wir:

  • Quadcore-Xeon 3,2GHZ
  • 24GB RAM
  • aktuelles Supermicro-Board und Gehäuse
  • 2x Adaptec 8Port-Controller
  • 9x3TB SATA-Platten,
  • 2 x 256GB SLC-SSD für den Cache.

Wir setzten das System  auf, lassen alle 8 Festplatten vom Adaptec Controller als Einzelplatten (JBODs) an das Betriebssystem durchreichen und konfigurieren einen ZFS-Pool mit folgenden Eigenschaften:

  • 4 x Mirror aus je 2 x 3TB Platten. (Diese Verbünde werden vdevs genannt. Es gibt auch raidz und raidz2, das einem RAID5 bzw RAID6 Level entspricht.)
  • Nachdem ZFS über alle vdevs ein dynamisches Striping macht, ergibt unser Setup eigentlich ein klassisches RAID10 aus 8 Platten.
  • Wie sorgen dafür, dass die beiden Mirror-Platten jeweils an unterschiedlichen Controllern angeschlossen sind, damit das System den Ausfall eines Controllers verkraften kann.
  • 1 x Spare-Platte  (scheint bisher noch nicht implementiert zu sein, wie sich später heraus stellt)
  • 2 x 256 GB SSD Platten als Cache-Device.

Wir erstellen also ein ZFS-RAID10 mit vier 3TB-Pärchen und statten es mit zwei SSDs für den Lese-Cache aus.

Performance Benchmarks

Jetzt interessiert uns brennend, wie Leistungsfähig unser System ist. Es wurde moderne und schnelle Hardware verbaut – immerhin acht spindeln und zwei SSD-Caches.
Wir testen auf dem System direkt, indem wir ein ZFS-Volume einfach mounten. Außerdem lassen wir ein anderes Volume von ZFS als Device bereitstellen, das wir mit LIO zu einem ISCSI-Device machen. In einem VMware ESX-Server mounten wir per ISCSI das Volume, so, dass wir auch die Netzwerkperformance testen können. Als Benchmarks dienen einfache Kopiervorgänge, sowie ein alter Bekannter namens FIO-Benchmark (Blog über FIO-Benchmarking).

Benchmark-Problem 1:
Wenn wir mit „Nullen“ testen, dann werden alle Daten ziemlich gut dedupliziert und wir benchmarken eigentlich nur, wie schnell die CPU Blocks zählen kann, weil ja nur der erste Block (mit Nullen) auf die Platten geschrieben wird. Das bringt uns also nicht viel, auch wenn die Werte sehr geschmeidig sind.

Benchmark-Problem 2:
Erzeugen wir zunächst Randomdaten für unsere Tests, dann verhindern wir damit sowohl die Deduplizierung, als auch die Komprimierung, weil das mit echten Zufalls-Daten nicht geht. Die Last wird natürlich trotzdem erzeugt.

Lösung:
Um dedup und comp zu testen braucht man also „echte“ Daten. Am besten solche, die später im produktiven Umfeld auch zu erwarten sind. Erst dann kann die Performance und effektivität des Systems halbwegs genau ermittelt werden.

Ergebnis:
Die Ergebnisse sind insgesamt für so ein System ziemlich mittelmäßig. Wir erhalten für das Lesen von großen sequenziellen Datenmengen, abhängig von der Mess-Methode, Werte zwischen 50 und 150MB pro Sekunde. Nach mehreren Benchmark-Läufen – damit ZFS die Lesecaches füllen kann – ermitteln wir beim Random-Read einen maximalen Wert von ca. 4000 Transaktionen pro Sekunde. Von einem „dummen“ Storage-System hätte man deutlich mehr erwarten können, in etwa das doppelte. Angesichts der zusätzlichen Features, mit denen ZFS daherkommt, ist die nicht richtig überzeugende Performance allerdings weder sonderlich überraschend, noch unplausibel. Für unser Backup-System  reicht der Wumms allemal aus. Beim Einsatz als Storage einer Datenbank oder Server-Virtualisierung wäre ich da deutlich skeptischer.

Produktiver Betrieb – Versuch

Das System steht und macht einen stabilen Eindruck, so, dass wir das Gerät in unserem Rechenzentrum in einer halb-Produktiven Umgebung mit der Realität konfrontieren. Dazu binden wir den ISCSI-Store in eines unser ESXi-Cluster ein, migrieren mehrere (Backup-)Server und Virtuelle-Festplatten drauf. Die ersten Maschinen laufen rund und gesund. Als nächstes zeihen wir einen unserer VMware-Datarecoverys auf den neuen Storage. Das sind ca 750GB in einem Rutsch und dauert viele Stunden. Dabei kommt es zum ersten mal zu einer Instabilität. Das ZFS-System scheint sich wegen andauernder Hochlast in eine sich selbst blockierende Situation zu manövrieren. Während das Betriebssystem normal reagiert, frieren alle Aktionen, die IO-Tätigkeit auf ZFS-Volumes ausführen, komplett ein oder dauern ewig. Der Kopiervorgang wird immer langsamer, bis er nur noch einige Kilobytes schafft, bringt aber nie völlig ab. Trotz funktionsfähigem Betriebssystem lässt sich die Maschine in diesem Zustand nicht einmal mehr rebooten, da das System ewig auf unmounts etc. wartet.
Dieses Problem ist definitiv reproduzierbar und tritt bei uns ausschließlich bei Storage-Migrationen großer Maschinen über einen ESX-Server auf. Beschleunigen können wir das Auftreten, wenn wir während der Migration zusätzlich ein paar GB Daten löschen, die gerade auf einem ZFS-Volume „herum liegen“.

Leider, leider, leider ist es uns nicht gelungen dieses Phänomen in den Griff zu bekommen. Wir  haben die Umgebung getauscht, ISCSI durch NFS getauscht, mirror-vdevs durch raidz-vdevs getauscht, Hardware tests durchgeführt, Internet-Recherche betrieben und so weiter …. Alles war leider zwecklos. Es bleibt dabei – große Datenmengen an sich sind scheinbar kein Problem, aber im Zusammenhang mit ESXi-Infrastruktur gibt es zuverlässig gravierende Probleme.
Das IST ein klassischer Showstopper! Der leider erst nach mehrmonatiger Arbeit zum Vorschein kommt.

Fazit

ZFS- ist durchaus cool! Jedoch mussten wir eindeutig feststellen, dass zumindest  Ubuntu-ZFS derzeit trotz offiziell anderslautender Meldungen, noch nicht ganz auf dem Stabilitäts-Niveau ist, das wir für unsere Technik im Rechenzentrum benötigen und voraussetzen. ZFS ist an sich schon als stabil zu betrachten und hat zudem ein sehr verlockendes Set an Features. Jedoch unterscheiden sich die Anforderungen an ein Dateisystem, das als Basis eines hochverfügbaren Virtualisierungs-Clusters herhalten muss doch maßgeblich von denen, die es im KMU-Segment zu erfüllen gilt. Gegen den Einsatz in letzterem gibt es möglicherweise nichts einzuwenden.
Dieser ZFS-Versuch ist ein gutes Beispiel für Versuchsprojekte, deren hart erarbeitetes Ergebnis bedeutet: „ja, aber nicht für uns“.
Aber wer sich lange mit einer Sache beschäftigt, der lernt so einiges dabei. In diesem Fall konnten wir z.B. unsere Fähigkeit zur Einschätzung der Effizienz von Block-Deduplizierung und Datenkopmprimierung steigern. Beides ist nämlich kaum pauschal zu beziffern, weil extrem abhängig von der Beschaffenheit der verwendeten Daten. Letztlich hat sich dadurch gezeigt, dass sich der ganze Aufwand mit dieser komplizierten Technik nur dann lohnt, wenn die Daten *wirklich* optimal deduplizierbar bzw. komprimierbar sind, wie z.B. bei einer Dateibackup, die mit per se schon einmal viele Kopien der gleichen Daten im Zuge der regelmäßigen (Full-)Backup anlegen würde. In unserem Fall wären aber nicht explizit nur Backupdaten zu speichern gewesen, sondern alles Mögliche von Betriebssystemen virtueller Rechner über bereits deduplizierte VMWare-Backups, zu verschlüsselten Kunden-Daten der Trinity-Boxen. Dieser Datenmischmasch hatte auf ZFS im Test ein durchschnittliches Kompressions-Verhältnis (dedup + compression) von nicht mehr als ca. 1:1,4. Das bedeutet, dass lediglich 40% an Festplattenkapazität eingespart würden. In unserem Mengengerüst wären diese 40% durch eine Hand voll zusätzlicher 3TB SATA-Platten zu haben gewesen und damit auf bewährter, herkömmlicher Technik, sicher, wartungsarm und stabil betrieben.
Letztlich trauern wir ZFS also an dieser Stelle nur wenige Tränen nach … zumindest solange wir keine vielfach deduplizierbaren Daten produzieren. Bis dahin ist ZFS vielleicht stabiler oder bereits btrfs im Einsatz.

Wir setzen also bis auf weiteres auf unsere bewährten rock-solid, heavy-duty, ISCSI-Storages der Marke Eigenbau. Die sind zwar „dumm“, dafür aber ziemlich schnell und extrem robust dank einfacher Technik.

Quellen:

Monitoring Evolution


Seit unserem letzten Artikel „Quo vadis Nagios?“ über das Monitoring-System Nagios und die unterscheidlichen Alternativen, wie Icinga oder Shinken, sind schon wieder zwei Jahre vergangen. In dieser Zeit hat sich an den Entwicklungen um Nagios selbst nicht viel getan, sehr wohl aber bei vielen anderen Opensource Projekten, die mit Nagios kompatible Monitoring-Lösungen darstellen. Nachdem unsere eigene Nagios-Installation und die einiger Kunden mittlerweile in die Jahre gekommen ist und es einige Punkte gibt, bei denen wir mit unserem aktuellen Monitoring-System nicht mehr ganz zufrieden sind, haben wir uns nun Zeit genommen, um die zwei großen Opensource Projekte Shinken und Icinga noch einmal genauer unter die Lupe zu nehmen. Dazu haben wir beide Systeme parallel installiert und getestet. Unsere Erkenntnisse und Erfahrungen mit den beiden Systemen werden wir im folgenden Abschnitt näher erläutern.

 

Shinken & Skonf

Die grundsätzlichen Informationen über Shinken findet man bereits in unserem Artikel „Quo vadis Nagios?“, weshalb ich an dieser Stelle nicht weiter darauf eingehen werde.
Im Vergleich zum Nagios bringt Shinken ein eigenes, webbasiertes Konfigurationstool mit, das dem Benutzer die Konfiguartion seiner Shinken-Installation erleichtern soll. Ein interessantes Feature stellt dabei die selbstständige Service-Erkennung, beim Hinzufügen von neuen Hosts, dar. Die Oberfläche an sich wirkt recht schlicht und modern. Leider konnten wir Skonf für unsere Tests nicht verwenden, da es nach der Installation nic
ht von selbst funktionierte und wir es auch nach mehrmaligem Versuchen nicht geschafft haben, es richtig zu konfigurieren. Jegliche Änderungen im Skonf waren auch nach einem Neustart von Shinken nicht in der Konfiguration

zu sehen. Eine Dokumentation ist zwar im offiziellen Wiki vorhanden, dort sind aber nicht alle Features, Konfigurationsmöglichkeiten und Probleme aufzufinden und die Community ist aktuell zudem noch recht klein. Insgesamt fanden wir den Ansatz aber durchaus interessant und hoffen, dass wir das Skonf-Interface in Zukunft auch mal funktionierend ausprobieren können.

shinken-ui

Detail-Ansicht eines Hosts in der Shinken UI


Icinga

Icinga ist einer der wohl bekanntesten Nagios-Forks und zeichnet sich vor allem durch seine aktive Entwicklung und Kompatibilität zur Nagios-Konfiguration aus. Genau so, wie auch bei Shinken, kann man prinzipiell einfach seine bestehende Nagios-Konfiguration importieren und weiter verwenden. Außerdem hat das Icinga Team im Laufe der Jahre viele der nervigen Nagios-Bugs behoben und damit das Gesamtsystem etwas stabiler gemacht. Ein großer Vorteil im Vergleich zu Shinken sind die vorhandenen Dabian-Pakete für die einfache Installation und Wartung von Icinga und seinem Zubehör.

Icinga-Legacy

Detail-Ansicht eines Hosts in der Icinga Classic-UI


Icinga-Web

Abgesehen von der altbekannten Nagios-Weboberfläche bringt Icinga auch noch eine neue, auf Ajax basierende und schicke Weboberfläche mit. Sie benötigt die Verwendung eine IDO-Datenbank, welche als Schnittstelle zwischen dem Webinterface und der eigentlichen Icinga-Installation dient. Diese neue Oberfläche sorgt für eine übersichtliche und strukturierte Darstellung der aktuellen Zustände und bietet außerdem die Möglichkeit, bestimmte Befehle an den Icinga-Daemon zu senden, um beispielsweise die aktiven Checks oder die Benachrichtungen zu aktivieren. Falls man zusätzlich zum Monitoring auch noch ein Reporting-System, wie beispielsweise Jasper, einsetzt, kann man dieses sehr einfach in Icinga und Icinga-Web integrieren.

Icinga-Web

Service-Status Ansicht von Icinga-Web


Shinken vs. Icinga

Durch viele Versuche, die wir mit beiden Systemem durchgeführt haben und Dinge, die wir mit den beiden Systemen getestet haben, haben wir viele neue Erfahrungen gesammelt.

Der Einrichtugngsaufwand ist bei Shinken zwar etwas höher, als bei Icinga, aber insgesamt machen beide Monitoring-Systeme nach der Installation auf den ersten Blick einen guten Eindruck. Die Integration von PNP4Nagios, NagiosQL, etc. ist bei beiden prinzipiell möglich, allerdings gibt es dabei beim Einrichtungsaufwand einige Unterschiede. Shinken hat aktuell eine kleine Community und die Dokumentation ist sehr knapp. Das erschwert vor allem Neulingen, tiefer in die Konfiguration und das Funktionsprinzip der Software einzusteigen und man ist daher bei Problemen mehr auf sich selbst angewiesen. Die Erst-Einrichtung gestaltet sich daher bei Shinken wesentlich aufwändiger und schwieriger, als bei Icinga. Im laufenden Betrieb funktionierte Shinken zwar ohne größere Probleme, aber der Konkurrent Icinga lief merklich stabiler und arbeitete besser mit den zusätzlich installierten Plugins/Add-Ons zusammen. Näheres zu den zwei wichtigsten Plugins gibt es in den folgenden Absätzen.


PNP4Nagios

Auch das Plugin zur Erfassung und Darstellung von Performance-Daten, der Nagiosgrapher ist mittlerweile in die Jahre gekommen und wird nicht mehr aktiv weiterentwickelt. Daher haben wir uns auch hier eine Alternative gesucht und uns für das Tool PNP4Nagios entschieden, welches eine eigene Weboberfläche bietet und zudem gut mit Icinga oder Shinken zusammenarbeitet. Wie auch bei Nagiosgrapher werden die Monitoring-Daten in einer RRD-Datei gespeichert und anschließend graphisch aufbereitet und angezeit. Ob es sich bei den Daten um die CPU-Auslastung oder die Werte eines Temperatursensors handelt, ist dabei vollkommen unerheblich. Die Graphen können im Anschluss komfortabel für bestimmte Zeiträume generiert und auch als PDF exportiert werden.

PNP4Nagios

Ansicht des Ping-Graphs in der PNP4Nagios Weboberfläche


NagiosQL und Nconf

NagiosQL ist ein graphisches Konfigurationstool, mit dem man über ein Webinterface die Nagios-/Icinga-/Shinken-Konfiguration erstellen und anpassen kann. Dadurch spart man sich die Arbeit mit den vielen verschiedenen Konfiguratiosndateien und kann dadurch schnell und gezielt Änderungen vornehmen. Im Handumdrehen lassen sich so neue Servicechecks, Hosts, Escalations oder auch Benachrichtungen hinzufügen und bestehende bearbeiten.

NagiosQL ist in PHP geschrieben und läuft auf jedem Apache-Webserver. Es benötigt lediglich eine zusätzliche MySQL Datenbank, um die Konfiguration zu speichern. Nach der erfolgreichen Änderung der Einstellungen werden dann jeweils die Nagios-kompatiblen Konfigurationsdateien generiert und das Monitoringsystem neugestartet, sodass die neue Konfiguration wirksam wird.

NagiosQL

Service-Übersicht von NagiosQL

Die Installation und Konfiguartion von NagiosQL selbst ist etwas komplizierter, aber wenn es dann einmal fertig eingerichtet ist, funktioniert es wurnderbar. In unserem Test war die Integration ind Shinken etwas umständlicher und es war ein bisschen Handarbeit nötig, um das ganze dann vollständig zum Laufen zu bekommen. NagiosQL ist aber ohne weiteres mit Icinga kompatibel und die Installation klappt ohne größere Probleme.
Außerdem haben wir auch das Tool Nconf einmal etwas genauer betrachtet und gestestet. Dabei mussten wir allerdings recht schnell feststellen, dass Nconf keinen mit NagiosQL vergleichbaren Funktionsumfang bietet und wir es noch mit eigenen Lösungen ergänzen müssten.
Für uns stellt daher NagiosQL, trotz seiner etwas altbacken wirkenden Oberfläche, einen vernünftigen Ersatz für die schon deutlich in die Jahre gekommene, bisherige Lösung dar. Das Projekt ist Opensource und wird aktiv entwickelt, weshalb wir das Tool natürlich besonders gerne verwenden.


Fazit

Shinken machte für uns insgesamt einen eher unfertigen und durchwachsenen Eindruck, weshalb wir der noch relativ jungen Software vor dem produktiven Einsatz noch etwas Zeit zur Entwicklung lassen. Einen sehr positiven Eindruck macht dagegen die Nagios-Alternative Icinga. Das Zusammenspiel mit NagiosQL und PNP4Nagios, deren Integration ins Gesamtsystem und der normale Betrieb funktionierten ohne Probleme. Abgesehen von kleineren Konfigurationsunterschieden im Vergleich zum alten Nagios, läuft Icinga sehr stabil und macht alles in allem einen soliden Gesamteindruck.

Aus diesem Grund haben wir Icinga, zusammen mit einigen weiteren Komponenten, als Hauptbestandteil für unseren „Monitoring-Server 2013“ gewählt. Damit bieten wir unseren Kunden ein modulares und skalierbares System, das sich vor allem durch Stabilität, Aktualität und eine komfortable Bedienung auszeichnet.

IT bleibt spannend!

Euer Andreas Erhard