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

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

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:

TrinityBox – die flexible Remote Backup Lösung


Liebe Kunden, Freunde und Interessenten,

ich freue mich, Euch heute unser neues, gerade fertiggestelltes Produkt vorzustellen:

Die TrinityBox

zur Sicherung wichtiger Daten an einem entfernten Standort. Als einfache Remote-Backup Lösung in Eurem Büro oder Serverraum.

Was kann die TrinityBox?
Sie stellt dort, wo sich Ihre wichtigen Daten befinden, ein Netzlaufwerk bereit. Das Netzlaufwerk sorgt einenständig dafür, dass all seine gespeicherten Daten automatisch auf den bereitgestellten Online-Speicher im WorNet Rechenzentrum gesichert werden.

Wie macht sie das?
Die TrinityBox besteht aus drei Komponenten:

  • Einem Gerät, das Netzlaufwerke bereitstellt (NAS), und das Ihnen dauerhaft zur Verfügung gestellt wird.
  • Dem TrinityLink. Ein robuster Prozess zur Übertragung der Daten.
  • Dem WorNet Rechenzentrum in München, das gesicherten Online-Speicherplatz bereitstellt.

Außerdem sind weitere wertvolle Funktionen eingebaut:

  • Bandbreitenmanagement
  • Monitoring
  • TrinityWeb als Informationszentrale
  • Weitere Netzlaufwerke zu Ihrer freien Verfügung
  • Daten-Kurierservice

Für wen ist die TrinityBox geschaffen?
Für Büros, Unternehmen, Praxen, Kanzleien, Selbständige, IT-Dienstleister, Werkstätten, Agenturen, industrielle Betriebe, Handelsunternehmen, öffentliche Einrichtungen, Vertreter,  usw. …
Kurz: für alle, die sicher gehen möchten oder müssen, dass Ihre Daten nicht von einem Standort alleine abhängig sind.

Interesse?
Gerne könnt Ihr euch selbst überzeugen und euch kostenlos eine Demo-TrinityBox zum ausprobieren borgen.

Weitere Informationen findet Ihr auf dem Produktblatt oder auf unserer Homepage.
Natürlich beraten wir Euch gerne auch persönlich am Telefon: 08171-418090

TrinityWeb informiert

IT bleibt spannend!

Viele Grüße
Hannes Wilhelm