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 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. Weiterlesen

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

Storage Benchmarking mit fio


Graphische Darstellung einer fio Testreihe

Neue Storage Systeme brauchen neue Benchmark-Tools. Unser Testaufbau bestand aus vier schnelldrehenden  Western Digital 1TB Platten, die eine Geschwindigkeit von 10.000 U/m erreichen. Diese sind zusammen mit zwei SSDs, die rein für das Cache benutzt werden, in einem Raid 10 Verbund. Dieser Testaufbau wurde übrigens später weiterentwickelt zu einem sehr schnellen Storage-System für unsere eigenen Hosting-Angebote, aber dazu mehr in einem weiteren Artikel.

Die ersten Versuche, entstanden mit dem Tool bonnie++ diese führten zu widersprüchlichen Ergebnissen. Nach längerem recherchieren, sind wir darauf gestoßen das bonnie++ nicht genügend Last erzeugen kann um Tests in dieser Größenordnung durchzuführen. Die Grenze der zu messenden IOs liegt hier bei 8000.

Nach dieser ernüchternden Erkenntnis, haben wir begonnen mit fio zu testen und bis auf die Ausgabe hat uns dieses Tool voll und ganz überzeugt.

Die Vor- und Nachteile von fio:

  • Erzeugt mehr Last durch das Angeben der Prozesse die  gestartet werden
  • Unterscheidet zwischen dem Modus, der Blöckgröße, der Testdateigröße sowie die Anzahl der Prozesse die gestartet werden
  • Auch für Stresstests und Hardware-Verifikation geeignet
  • Kann gut Automatisiert werden
  • Wenn ein stark unter Last stehendes System getestet wird, wird es mit fio nicht so stark belastet, da die Datenmenge mit der getestet wird geringer wird je stärker das System beansprucht ist, das Problem der Überlastung wird daher umgangen
  • Der Output ist sehr detailliert, um die Testergebnisse auszuwerten jedoch schlecht lesbar
  • Unter Ubuntu-Linux einfach zu installieren (apt-get install fio)

Dieser Programmcode ist unser automatisierter fio Test, mit der dazugehörigen Überschrift. Diese Daten werden anschließend an unser Perl Programm übergeben um die Ausgewerteten Daten lesbar zu machen.

#! /bin/bash

DEVICE=$1
SIZE=$2

ARGS1="--direct=1  --runtime=30 "
ARGS2="--filename=$DEVICE --size=$SIZE "

#  fio --filename=/dev/sdb1 --direct=1 --rw=read --bs=512 --size=4G 
#      --runtime=60 --name=job1 --name=job2 --name=job3 --name=job4 
#      --name=job5 --name=job6

(
echo "     DEVICE;  SIZE;     MODE; BLOCKSIZE; NUMJOBS;  READMB; WRITEMB; READIOS; WRITEIOS"
# for mode in rw read randrw randread; do
for mode in randread; do
   for blocksize in 4k 16M ; do
      ARGS3="--bs=$blocksize --rw=$mode "
      for jobs in 1 2 3 4 6 8 10 12 16 20; do
         ARGS4=""
         i=0
         while [ $i -lt $jobs ]; do
            let i=$i+1
            ARGS4="$ARGS4 --name=job$i"
         done
         #echo -n "$DEVICE;$SIZE;$mode;$blocksize;$jobs;"
         printf "%12s %6s %8s %10s %8s" "$DEVICE;" "$SIZE;" "$mode;" "$blocksize;" "$jobs;"
         fio $ARGS1 $ARGS2 $ARGS3 $ARGS4 | /usr/local/tools/fio_parser.pl
      done
   done
done
) | tee /tmp/fio-result-`/bin/date +%Y-%m-%d--%H-%M-%s`-`/bin/hostname`.csv


#! /usr/bin/perl

while ( $s =  ) {
# egrep "READ:|WRITE:|^  [a-z].*ios="
#   READ: io=4965MB, aggrb=84611KB/s, minb=13880KB/s, maxb=15064KB/s,
#         mint=60055msec, maxt=60088msec
#  WRITE: io=5015MB, aggrb=85463KB/s, minb=13999KB/s, maxb=15155KB/s,
#         mint=60055msec, maxt=60088msec
#  sdb: ios=9946/10014, merge=0/0, ticks=344830/329890,
#       in_queue=674820, util=99.93%

   chomp($s);
   if ( $s =~ / READ: /) {
      $ReadBandwidth = $s;
      $ReadBandwidth =~ s/^.*aggrb=//;
      $ReadBandwidth =~ s/B.*$//;
      $ReadUnit=chop($ReadBandwidth);
      if ($ReadUnit eq "M") {
         $ReadBandwidth=$ReadBandwidth*1024;
      } elsif ($ReadUnit eq "G") {
         $ReadBandwidth=$ReadBandwidth*1024*1024;
      }

      $Time = $s;
      $Time =~ s/^.*maxt=//;
      $Time =~ s/msec.*$//;
   } elsif ( $s =~ / WRITE: /) {
      $WriteBandwidth = $s;
      $WriteBandwidth =~ s/^.*aggrb=//;
      $WriteBandwidth =~ s/B.*$//;
      $WriteUnit=chop($ReadBandwidth);
      if ($WriteUnit eq "M") {
         $WriteBandwidth=$WriteBandwidth*1024;
      } elsif ($WriteUnit eq "G") {
         $WriteBandwidth=$WriteBandwidth*1024*1024;
      }

      if ($Time == undef ) {
         $Time = $s;
         $Time =~ s/^.*maxt=//;
         $Time =~ s/msec.*$//;
      }
   } elsif ( $s =~ /^  [a-z].*ios=/ ) {
      $ReadIOS = $s;
      $ReadIOS =~ s/^.*ios=//;
      $ReadIOS =~ s/\/.*$//;
      $WriteIOS = $s;
      $WriteIOS =~ s/^.*ios=[0-9]+\///;
      $WriteIOS =~ s/\,.*$//;
   }
}

printf( "%8s;", sprintf ("%.3f", $ReadBandwidth/1024) );
#print ";";
printf( "%8s;", sprintf ("%.3f", $WriteBandwidth/1024) );
#print ";";
printf ("%8i", int($ReadIOS*1000/$Time) );
print ";";
printf ("%9i", int($WriteIOS*1000/$Time) );
print "\n";


Und hier einmal eine Ausgabe.

DEVICE SIZE MODE BLOCKSIZE NUMJOBS READMB WRITEMB READIOS WRITEIOS
/dev/sdb1 49G randread 512 1 1624 0 3317 0
/dev/sdb1 49G randread 512 2 2926 0 5974 0
/dev/sdb1 49G randread 512 3 4363 0 8910 0
/dev/sdb1 49G randread 512 4 5572 0 11379 0
/dev/sdb1 49G randread 512 5 5918 0 12085 0
/dev/sdb1 49G randread 512 6 6396 0 13061 0
/dev/sdb1 49G randread 512 7 7076 0 14449 0
/dev/sdb1 49G randread 512 8 7647 0 15615 0
/dev/sdb1 49G randread 4k 1 12473 0 3193 0
/dev/sdb1 49G randread 4k 2 23147 0 5907 0
/dev/sdb1 49G randread 4k 3 33905 0 8656 0
/dev/sdb1 49G randread 4k 4 41183 0 10520 0
/dev/sdb1 49G randread 4k 5 43572 0 11122 0
/dev/sdb1 49G randread 4k 6 46203 0 11794 0
/dev/sdb1 49G randread 4k 7 48973 0 12501 0
/dev/sdb1 49G randread 4k 8 54445 0 13898 0
/dev/sdb1 49G randread 64k 1 106146 0 1693 0
/dev/sdb1 49G randread 64k 2 134256 0 2142 0
/dev/sdb1 49G randread 64k 3 184783 0 2949 0
/dev/sdb1 49G randread 64k 4 223165 0 3562 0
/dev/sdb1 49G randread 64k 5 250008 0 3991 0
/dev/sdb1 49G randread 64k 6 267242 0 4266 0
/dev/sdb1 49G randread 64k 7 282166 0 4504 0
/dev/sdb1 49G randread 64k 8 293171 0 4680 0
/dev/sdb1 49G randread 1M 1 267873 0 534 0
/dev/sdb1 49G randread 1M 2 314568 0 627 0
/dev/sdb1 49G randread 1M 3 290241 0 578 0
/dev/sdb1 49G randread 1M 4 297634 0 593 0
/dev/sdb1 49G randread 1M 5 247376 0 492 0
/dev/sdb1 49G randread 1M 6 263334 0 526 0
/dev/sdb1 49G randread 1M 7 269112 0 536 0
/dev/sdb1 49G randread 1M 8 269197 0 537 0

Energy saving Micro-Servers running VMware vShpere 5


Hi,

we were looking for inexpensive and energy efficient micro servers working with VMware vSphere 5 for our Lab and testing. These models worked just fine (although they dont have any VMware Certification, so you wont get support from VMware) :

Fujitsu MX130 S2

  • Dual-Core AMD Athlon II X2 220 2,8GHz
  • 16 GB RAM max. (4 x 4GB DDR3 1333 ECC unregistered)
  • onboard Broadcom GBit-LAN (tg3)
  • 2 non-hotswap 3,5″  SATA drive bays
  • 2 x HDD 500 GB
  • 4 low profile expansion slots (PCIe x1, x4, x16, legacy PCI)
  • power consumption 48W (vShpere 5.0 running, no active VM, without harddisks)

 

HP Proliant N40L

  • Dual-Core AMD Processor 1,5 GHz
  • 8 GB RAM max.
  • onboard Intel GBit-LAN
  • 4 non-hotswap 3,5″ SATA drive bays with SFF-8087 connector
  • 1 x HDD 250 GB
  • power consumption 42W (vShpere 5.0 running, no active VM)
  • nice: Set of screws and screwdriver on the back side of the front door, USB connector onboard, boots vSphere from USB

IT is exciting,
Christian Eich

MediaWiki – Die eigene kleine Enzyklopädie


Hallo Zusammen,

Fast jeder wird in seinem Leben schon mal auf eine Wikipedia-Seite gestoßen sein.  MediaWiki wurde anfangs für genau diese Enzyklopädie geschrieben und ist eine Software mit der man sich auch sein eigenes kleines Nachschlage-Werk für eigene wichtigen informationen erstellen kann.

Jeder der ein MediaWiki schon einmal installiert hat weiß, dass die Grundsoftware ziemlich dürftig ist! Die Suche ist nicht unbedingt die Beste und es gibt in der heutigen Zeit vieles was einem Fehlt. Das tolle an dem Mediawiki sind seine Extensions, dadurch kann man sich viele wünsche erfüllen, leider sieht man bei der riesen Menge an Extensions den Wald vor lauter Bäumen nicht..

Wir haben bei uns auch ein Mediawiki im Einsatz. Um uns das Leben ein wenig zu vereinfachen haben wir es um einige Extensions erweitert. Ein Paar davon möchte ich euch nun vorstellen.

Suche:
Die Standard-Mediawiki-Suche hat ein paar Nachteile. Sie kann zB. keine Teilstrings oder Wörter die kürzer als 4 Zeichen sind suchen. Sie hat eine begrenzte Such- syntax und Funktionalität und die Ergebnisse liefern auch nicht immer das Gesuchte. Auch hier ist die Auswahl der Extensions groß, die Entscheidung fiehl nach ein paar Vergleichen auf die SphinxSearch Suche. SphinxSearch ist eine Volltextsuche die einen Index erstellt der auf der MediaWiki-Datenbank basiert. Sie unterstützt alle standard MediaWiki-Suchtechniken und erweitert diese.

Neue Seite erzeugen:
Das anlegen einer neuen MediaWiki-Seite ist aufwändig! Aber auch hier können Extensions wie zB. Input Box Abhilfe schaffen. Mit dieser Erweiterung ist das Einbinden vordefinierter HTML-Formulare möglich.
Dadurch kann mit ein wenig Aufwand ein Button auf der eigenen Seite erstellt werden, der eine neue Seite mit einem gewünschten Namen erzeugt. Die Extension erlaubt auch das Laden eines Seitentemplates, womit man sich einiges an Schreibarbeit erspaart. In Verbindung mit der ParserFunctions-Erweiterung, welche die Möglichkeit bietet das MediaWiki um logische Funktionen zu ergänzen, ist es auch möglich Informationen aus Seitentitel heraus zu trennen und in den Titeln der neuen Seite wieder zu verwenden. Wir nutzen die Verbindung beider Extensions auch um History-Einträge zu erstellen.

Übersicht und Struktur:
Um eine Struktur in alle Artikel und Kategorien zu bringen, nutzen wir für jede Seite mehrere Kategorien.

  1. Wer ist für diese Artikel zuständig?
  2. Ist dieser Artikel Aktuell?
  3. Zusätzlich noch eine oder mehrere um alles in Kategorien zu Ordnen!

Mit Hilfe der Extension DynamicPageList kann ein Liste von Artikeln angezeigt werden, die in mehreren Kategorien enthalten sind.

Hierbei sind ich gleich noch 2 weitere Extensions zu erwähnen. Zum ersten wäre da CategoryTree welches eine aufklappbare Baumstruktur einer Kategorie und aller unterKategorien bzw. Seiten bietet. Zum zweiten ist die Extension PdfBook auch interessant, weil sie einem ermöglicht, eine Kategorie mit allen Unterseiten auf die schnelle auszudrucken.

Da auch hin und wieder Programmier-Code im MediaWiki dargestellt werden soll, ist eine syntax highlighting Funktion sehr hilfreich. Hierfür nutzen wir die Extension SyntaxHighlight GeSHi welche den Code vieler Sprachen kennt und farblich hervorheben kann. Eine ähnliche Variante die Formatierung zu behalten ist die Extension SyntaxHighlight vim welche den Text so formatiert darstellt wie er im Mediawiki-Quelltext steht.

Die Extension FCKeditor ist ein wysiwyg-Editor der das Ganze noch abrundet, wobei erfahrene Nutzer wohl lieber den Code-Editor verwenden.

Unter all diesen Erweiterungen verwenden wir auch eine Selbstgeschriebene, welche Informationen aus Datenbanken anderer Applikationen heraus sucht und diese in MediaWiki-Seiten einbindet, damit die Daten nicht zusätzlich noch im MediaWiki gepflegt werden müssen.

Die Vielfallt der Extensions ist sehr groß. Einige davon sind ein wichtiger Bestandteil unserer MediaWiki-Installation geworden und helfen deren Funktionsumfang zu erweitern und an unsere individuelle Anforderungen anzupassen.

IT bleibt spannend!

Richard Schunn

Quellen:

 

RAID50 vs. RAID10


Hallo Kollegen,

das Thema RAID ist wohl ein niemals endendes. Gerade jetzt, da in Zeiten vortgeschrittener Virtualisierungstechnik auch die Storage-Strategie angepasst werden muss und  damit größere SAN-Systeme auch in kleines und mittleres Gewerbe Einzug erhalten, stellen viele Admins neue Überlegungen über ihren jeweils optimalen RAID-Verbund an. Im Unterschied zu früher sind die Arrays jetzt viel größer, dazu kommt die Problematik der schnellen Daten-Übertragung über das Netzwerk. Auf das Prinzip von dedizierten Storage-Netzwerken und parallelen Daten-Pfaden werden wir ein anderes mal eingehen.
Die Auswahl des RAID-Setups ist schon der erste magische Punkt, der sorgfältig vorbereitet werden sollte, weil nachträgliche Änderungen nur schwer möglich sind. Viele Storage-Systeme verfügen zwar über eine Funktion bestimmte RAID-Level in andere zu überführen,  ohne dabei Datenbestände oder den Betrieb zu verlieren, in der Praxis ist jedoch oft die benötigte Kombinationnicht möglich oder die Live-Migration würde über Tage das gesamte System deutlich belasten, so, dass der tägliche Betrieb beeinträchtigt werden könnte. Die Auswahl des RAID-Levels sollte daher auf soliden Überlegungen beruhen.

Aber wie lässt sich von einer schwer voraussagbaren Anforderungen der eigenen Systeme auf das richtige RAID-Setup schließen?

Im Groben ist das ganz einfach:
Man untersucht die Anforderungen an Performance- und  Platzbedarf und zirkelt dann mit Hilfe der folgenden und vermutlich jedermann halbwegs geläufigen Tabelle der wichtigsten RAID-Level, eine Entscheidung herbei.

RAID 0 RAID 1 RAID 5 RAID 10 RAID 50
Prinzip Stripes über 2 PLatten Ein Platte gespiegelt Verteilte Parität Stripes über n Platten, gespiegelt Stripes über n RAID5
Mindest Anz. Platten 2 2 3 4 6
Datensicherheit keine 1 Ausfall 1 Ausfall 1 Ausfall pro Subarray 1 Ausfall pro Subarray
Kapazität 100% 50% 67% – 94% 50% 67% – 94%
Performance schnell schreiben schnell lesen mittel schnell schnell bei großen Datenmengen
Rebuild Performance gut mittel sehr gut mittel
Vorteil 100% Kapazität / Performance Datensicherheit / Schreib-Performance Datensicherheit /hohe Kapazität Skalierbarkeit / Performance Skalierbarkeit / Kapazität

Große RAID-Setups

Das hat bisweilen ganz gut funktioniert in Zeiten der „Baremetal-Rechner“, die nur sich selbst mit Storage versorgen mussten. Gilt es jedoch beispielsweise einen VM-Ware-Cluster mit drei ESX-Servern und  insgesamt 50 virtuellen Rechnern zu bedienen, dann ist diese Informationsbasis zu dürftig.
Wir nehmen hier vorweg, dass wir schnell zu dem Schluss gekommen sind, die RAID-Level 10 und 50 genauer zu untersuchen, da sie als einzige gleichzeitig hohe Performance, Ausfallsicherheit und Skalierbarkeit mitbringen.

Performance ist nicht gleich Performance

Storage-Performance nicht so einfach messen und durch einfache Zahlenangaben charakterisieren. In der Regel wird einfach eine mittelgroße Datenmenge sequenziell auf den zu testenden Store geschrieben bzw. gelesen. Das lässt sich zumeist recht einfach umsetzen und das Ergebnis sind dann Zahlen wie z.B. 73MB/s schreiben etc. . Werden beispielsweise große zusammenhängende Datenmengen bewegt, ist das schon einmal eine hilfreiche Information. Andere Fragen bleiben jedoch zunächst unbeantwortet. Welche Eigenschaften eines Storage-System lassen z.B.einen Windows Domain-Controller in Windeseile booten oder helfen eine relationale Datenbank zu beschleunigen? Ausschlaggebend dafür ist ein schwer zu messendes Kriterium, namens Transaktionen pro Sekunde (tps). Also die Anzahl der Schreib- bzw Lese-Zugriffe pro Zeiteinheit. Die tps eines Systems lassen sich nur durch ausgeklügelte Benchmarks ermitteln, da dazu ein Testumgebung nötig ist, die parallel extrem viele kleine und kleinste I/O-Requests starten kann. Der für das durchschnittliche Serversystem „natürlichen“ I/O-Last kommt das jedoch erheblich näher, als die übliche Lese- und Schreibrate sequenzieller Daten.

Geeignete Benchmarks lassen sich z.B. in der Opensource-Welt finden. Wir verwenden ein freies Tool namens FIO u.a. zur Ermittlung der TPS-Werte. Mit einem  anderen Programm namens Bonni haben wir gute Erfahrungen auf kleineren Storage-Systemen gemacht. Für Tests an besonders schnellen Systeme, z.B. wenn SSD-Platten z.B. für Caches verwendet werden, mussten wir auf FIO umsatteln. Die genaue Funktionsweise von Benchmarkprogrammen, sowie die Interpretation der Resultate werden wir in einem eigenen Blogartikel genauer besprechen.

Welche Kriterien sind entscheidend für hohe TPS-Werte?

  • Die Anzahl der verwendeten Festplatten.
    Je mehr Festplatten (auch Spindeln genannt) gleichzeitig arbeiten, desto mehr Arbeit kann logischerweise auch verrichtet werden. Das trifft insbesondere auf TPS zu, da eine herkömmliche Festplatte bauartbedingt einige Zeit benötigt, um den Lesekopf neu zu positionieren. Bei vielen kleinen Zugriffen an „unterscheidlichen“ Stellen auf der Platte, entstehen so viele kleine Lese-Pausen, während sich der Kopf zum nächsten Ziel bewegt.
  • Das RAID-Setup.
    Am RAID-Level hängt ab, welche Arbeit der Controller verrichten wird und in welcher Weise Festplatten parallel arbeiten können. Logisch betrachtet sind in einem RAID 50 Verbund an einem Schreibzugriff mehr Platten aktiv beteiligt, als z.B. in einem RAID10. Beim Letzteren sollte daraus einen Performace-Gewinn resultieren.
  • Performance und Drehgeschwindigkeit der eingesetzten Festplatten.
    Je schneller sich die Datenscheibe der Festplatte dreht, desto weniger Zeit vergeht bis sich die „gesuchten Daten“ unter dem Lesekopf befinden. Insbesondere nach Repositionierungen des Kopfes muss dabei gewartet werden.

In der Praxis

Soweit die Theorie. Jetzt möchten wir wissen ob wir für unser VMWaren-Cluster besser RAID10 oder RAID50 einsetzten sollen und wie wir die Performance verbessern können.

Setup

  • VM-Ware-Cluster mit drei ESX-Servern (je 96GB RAM) und insgesamt 50 virtuellen Rechnern
  • Dell Equallogic PS4000 mit 12 Festplatten je 15.000 rpm
  • Dell Equallogic PS4000 mit 16 Festplatten je 7.200 rpm
  • Eine Linux-VM mit FIO-Benchmark Software.

Ergebisse (Ausschnitt)

EQL1 (10×15.000rpm) EQL2 (14x7200rpm)
RAID 10 RAID 10 RAID 50
Lesen-TPS 4KB 2161 tps 1406 tps 1390 tps
Lesen / Schreiben – TPS 4KB 1360 tps 800 tps 595 tps

Im direkten Vergleich auf EQL2 stehen sich RAID10 und RAID50 auf der selben Hardware gegenüber.
Außerdem werden zwei RAID10 Setups auf sehr ähnlicher Hardware, jedoch mit unterschiedlichen Ferstplattenbestückungen gegenüber gestellt.

Fazit:

Erwartungsgemäß ist RAID10 als das „teuerste“ RAID auch bei TPS am schnellsten. Allerdings ist der Vorsprung nicht sehr groß (zwischen 5% und 25% schneller als RAID50) und es gibt eine weitere Überraschung.
Die Bauart der Festplatten, insbesondere die Drehgeschwindigkeit, scheint auch in großen Verbünden maßgeblichen für die Leistung am Ende des Tages ausschlaggebend zu sein. Unseren Ergebnissen zufolge, ist die Annahme naheliegend, dass eine Verdoppelung der Drehgeschwindigkeit auch in etwa die Anzahl der Transaktionen verdoppelt. (Wenn man die Anzahl der Festplatten hochrechnet und Unterschiede in der übrigen Hardware vernachlässigt).

RAID 10 RAID 50
Vorteile Beste TPS-Werte, schnelles Rebuild, wenig Performanceverlust bei degradeten Arrays, etwas bessere Redundanz Beste Nutzung der Speicherkapazität (preisgünstiger), Ordentliche TPS-Werte, kleiner Vorteil beim lesen großen Datenmengen
Nachteile Nur 50% der Speicher-Kapazität nutzbar (teurer) Performanceverlust bei degradeten Arrays und während des Rebuilds, etwas weniger Redundanz
Einsatzzweck Schnelle Datenbanken, Storage für (virtuelle und physische) Systeme mit maximalen Leistungsanforderungen Große Datenbanken, Storage für (virtuelle und physische) Rechnersysteme mit normalen Anforderungen, Backup, Fileserver

Aufgrund dieser Messergebnisse haben wir uns entschieden, zwei unterschiedliche Storage-Systeme für unser VMWare-Cluster zu betreiben. Ein Storagesystem mit viel Speicherkapazität auf Basis normal-schneller Platten und RAID50 und dazu ein etwas kleineres System mit RAID10 und schnellen Platten. So können wir jede virtuelle Maschine und alle anderen Systeme mit Speicherplatz-Bedarf, nach Anforderung sortiert auf den jeweils individuell passenden Storage umziehen.

IT bleibt spannend!

Hannes Wilhelm
WorNet AG 2012

 

Quellen:

IT-Forum Bayern: Reihe zur IT-Konsolidierung


Das IT-Forum Bayern stellt gerade eine Reihe von Artikeln zur IT-Konsolidierung aus der Sicht der einzelnen Mitglieder zusammen:

weitere Artikel folgen in den kommenden Wochen – am besten gleich abonnieren:

http://itmaschinenbau.wordpress.com/feed/

Onlinespeicher TrinityBox erhält neue Webseite


Heute haben wird das von uns selbst produzierte Einführungsvideo zur TrinityBox fertiggestellt und mit der neuen Produkt-Webseite www.TrinityBox.de veröffentlicht:

Damit steht jetzt ein passender Webauftritt als umfassende Informationsquelle im Internet zur Verfügung, auf der alles zu lesen ist, was es über die TrinityBox zu wissen gibt.

TrinityBox Webseite

Wir bedanken uns für die umfangreiche Unterstützung und werden auch weiterhin Tipps und Hinweise zu Produkt und Webseite dankbar annehmen!

IT bleibt spannend!

Grüße

Hannes Wilhelm

fail2ban gegen schwache Passwörter


Beim Betrieb von Serverdiensten im Rechenzentrum werden zwangsläufig auch diverse Ports für das Internet freigeschalten, um Benutzern und Admins Zugang zu ermöglichen. Trotz sorgfältig eingesetzter Firewalltechnik können dabei schwache Passwörter von einem Angreifer aus dem Internet ggf. leicht erraten werden (Brute Force Attacke).
Wir schließen diese Lücke mit dem Programm fail2ban.
Es funktioniert nach dem Prinzip: erfolglose Loginversuche erkennen und nach einer festgelegten Anzahl die IP-Adresse sperren. Fail2ban ist für Posix-Betriebssysteme erhältlich, so ist z.B. bei SuSE- und Ubuntu-Linux ein vorkonfiguriertes Paket in der Distribution enthalten. Es lassen sich mehrere Dienste (auch gleichzeitig) damit überwachen, u.a. Apache, Lighttpd, sshd, vsftpd, qmail, Postfix und Courier Mail Server. Dabei werden die Logausgaben vom fail2ban-Daemon laufend überwacht und im Falle einer Attacke der oder die Angreifer per IP-Tables Regel verbannt.
Fail2ban ist auf allen gehosteten Servern unserer Kunden, die mit einem Wartungsvertrag ausgestattet sind, sowie unseren Eigenen im Einsatz. Dank der einfachen Handhabung entsteht dabei kaum administrativer Aufwand.

IT bleibt spannend!

Viele Grüße
Hannes Wilhelm

 

Quellen:

http://www.fail2ban.org/wiki/index.php/Main_Page
http://de.wikipedia.org/wiki/Fail2ban