WorNet in der Presse


wir freuen uns auf die positive Resonanz auf aktuelle Presseberichte:

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

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

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

Das Jahr fängt gut an …


Hallo, zusammen

Seit wir im Jahre 1997 unseren ersten Cisco-Router gekauft haben ist schon viel Wasser die Isar runter geflossen. Immer mehr Cisco-Komponenten haben sich und unserem eigenen Rechenzentrum angesammelt, ein eigenes Konfigurationswerkzeug wurde geschrieben (ursprünglich als Gesellenarbeit vom Hannes), wir haben uns mit komplexen Routingprotokollen bis hin zu BGP4 befasst, haben unsere Switchinfrastruktur nach allen Regeln der Kunst vermascht und haben auch in diversen Kundenprojekten unser Cisco-Know-How unter Beweis gestellt. Nur Cisco-Partner geworden sind wir nicht. Nicht weil etwas dagegenspräche, es hat sich nur einfach nicht ergeben. Wir lebten quasi in „wilder Ehe“ mit unserem wichtigsten Netz-Ausrüster.

Cisco Select Certified PartnerMit der strategischen Fokussierung auf Rechenzentrumstechnologien ist das Thema Herstellerpartnerschaften für uns immer wichtiger geworden und so sind wir stolz die Partnerschaft mit Cisco Systems, dem führenden Netzwerkausrüster verkünden zu können.

Das bedeutet, dass wir die Cisco-Small-Business und Cisco-Classic-Produkte, insbesondere die bei unseren Kunden häufig vertretenen ASA-Firewalls und Catalyst-Switches günstiger anbieten und mit Service-Verträgen versorgen können. Und selbstverständlich bieten wir Installation, Konfiguration und laufenden Betrieb in gewohnter Qualität.

Weitere zwei Herstellerpartnerschaften haben wir übrigens mit VMware und Fujitsu geschlossen. Zusammen mit Cisco und unseren Beratungsleistungen ergibt das ein umfassendes Produktportfoilo für die Ausrüstung und den Betrieb kleiner und mittelgroßer Rechenzentren.

IT bleibt spannend,

Euer Christian Eich

iSCSI performance tuning: 380 MB/s within a VM with openfiler and ESXi


Hi, folks

There is a large gap between entry level Storage appliances like QNAP, Thecus or Buffalo and „large“ SAN-Storages regarding performance, features and very much the price. We have found a solution to fill this gap for our datacenter. Using open source of course!

unsere TestumgebungFor quite a while we have been using Openfiler, a linux-based storage software. However, we were not content with the performance being just a notch above the entry level storages, despite the decent server hardware used. An ESXi cluster waiting for roll out was just the opportunity we needed to tune up I/O performance. So we hit the lab and found out, that the order of tuning steps was crucial to find the right configuration.

Our test bed:

  • 1 ESXi 4.1 server (Fujitsu RX 200 S6, 8 Cores 2,4 GHz, 48 GB RAM, 6 x GBit-NICs Intel)
  • 1 Openfiler 2.3 (Supermicro 8 Cores 2,0 GHz, 8 GB RAM, 3ware 9650SE 8 Ports, 6 x GBit-NICs Intel, 8 disk drives 2 TB SATA 7200U/min)
  • 1 switch Cisco Catalyst 2960S (24 port GBit)

We used four GBit NICs on either side for four iSCSI-VLANs with different IP address ranges. The NICs have to be assigned to the iSCSI software initiator to address all paths. We created an iSCSI volume in Openfiler, connected and formatted it in ESXi using VMFS 4 file system. Paths selection was configured „round robin“.

virtual machine for benchmarking:

We crated a VM with 1 CPU, 2 GB RAM and a harddisk of 15 GB + twice the size of the storage server’s RAM and installed Windows 7. Then we installed IOMETER and a standardized configuration from the VMware forums. This way your results can be compared with other forum posts.

1st step: Where do we start

First we measure the performance of the unoptimized system. The size of the test file we use is smaller than the storage server’s RAM. So any read and written data comes from the cache and we measure only the iSCSI connection.

Latency (ms) IO/s MB/s
Max Throughput-100%Read 14,6 4096,1 128,0
RealLife-60%Rand-65%Read 412,3 141,4 1,1
Max Throughput-50%Read 13,4 4302,2 134,4
Random-8k-70%Read 546,1 107,6 0,8

Not impressive, is it? Accessing the disks locally yields 420 MB/s! What a performance loss in the way to the VM.

2nd step: iSCSI path optimization

Next thing to do is tuning all parameters associated with the iSCSI paths. It is okay in this step to use unsafe settings (e.b. enabling a write buffer without having a BBU). The test file still is smaller than the storage server’s RAM, because we want to measure the iSCSI connection’s speed.

Things to look at:

  • Parameters of the network interface card (jumbo frames, TCP-offload)
  • iSCSI parameter (round-robin parameter)
  • RAID pontroller (enable write-cache)

The boost in performance was obvious:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,69 12624,71 394,52
RealLife-60%Rand-65%Read 318,66 181,52 1,42
Max Throughput-50%Read 8,08 7030,93 219,72
Random-8k-70%Read 369,51 150,26 1,17

This is close the theoretical limit.Leistungsanzeige der iSCSI-Pfade bei sequentiellem Zugriff

Beware: Don’t continue if you’re not satisfied. From now on it’s getting worse!

Watching the load of iSCSI paths in vSphere client should give a equal share of traffic over all paths.

Things we stumbled upon:

  • bad jumbo frame configuration. Test it with ping using large packets and „dont fragment“-bit set. Our switch needed a „set mtu jumbo 9000“
  • VMwares „round robin“ algorithm switches paths only every 1000 IO ops. You have to use „esxcli“ to change that.

3rd step: optimizing storage parameters

Now we set up everything to safe values for the production environment. The IOMETER testfile is twice as big as the storage server’s RAM. Caution: Size is given in blocks of 512 bytes.

We compared different RAID levels (getting practice in online RAID migration while doing so) and different number of disk drives.

Raid-10 with 4 disks: 2 TB (SATA, 7200 U/min):

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,93 12089,4 377,79
RealLife-60%Rand-65%Read 333,02 171,66 1,34
Max Throughput-50%Read 8,15 6857,19 214,29
Random-8k-70%Read 454,2 129,76 1,01

Raid-10 with 8 disks:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,8 12331,0 385,3
RealLife-60%Rand-65%Read 443,6 138,0 1,1
Max Throughput-50%Read 9,1 6305,3 197,0
Random-8k-70%Read 504,0 121,4 0,9

Increasing the number of spindles didn’t improve performance, although we expected better IOPS. So it would be better to use two independent datastores with 4 drives each.

Using RAID-6 with 8 drives gave worse IOPS.

Summary:

Almost 400 MB/s and >10.000 IOPS makes us very happy. Our x86 server with Openfiler (about $5.500) closes the gap between inexpensive entry level storage appliances ($1.500 Euro for 70 MB/s and2.000 IOPS) and large SAN storages for $15k+.

Further IOPS and latency improvement could be achieved using more and better drives (SSD, SAS). We haven’t tried storage replication yet, but we read reports about users successfully implementing „drbd“ .

 

IT bleibt spannend,

Christian Eich

This article is based on research by Christian Eich, Richard Schunn and Toni Eimansberger.
Author: Christian Eich