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

Netzwerke für Netzwerker


Übersicht über interessante Unternehmernetzwerke im Raum München aus Sicht eines IT-Unternehmers.

Netzwerke bestehen nicht nur aus Kabeln aber immer aus VerbindungenJeder, der sich mit Computernetzwerken etwas intensiver befasst hat, kennt die 7 Schichten des OSI/ISO-Modells. Bei aller Leidenschaft insbesondere für die Schichten 2 und 3, weiss ich doch, dass es Themen gibt, die man auf Layer 8 klären muss, dem Executive Layer. Und auch hierfür gibt es spezielle Netzwerke, von denen ich die für mich wertvollsten kurz vorstellen möchte:

Münchner UnternehmerKreis IT (MUK)

http://www.muk-it.com
Seit 10 Jahren eine Kooperations- und Diskussionsplattform mit sechs „Roundtables“ pro Jahr, auf denen Fachvorträge, Impulsvorträge und reichlich Zeit für persöniche Gespräche unter den 50 bis 100 Teilnehmern geboten werden. Dies sind ausschließlich Geschäftsführer von IT-Firmen, was eine hohe Qualität der Gesprächspartner garantiert. Für mich der beste Einstieg ins Networking in München, insbesondere dank dem unermüdlichen Einsatz des Organisators Lutz Steffen, der mit einer gekonnten Mischung von Humor und Disziplin für einen reibungslosen Ablauf sorgt.

IT-KOOP

Infos auf den Seiten des MUK-IT

Seit drei Jahren Frühjahr stattfindende Veranstaltung zum Knüpfen von Kooperationen zwischen IT-Unternehmen, organisiert von MUK-IT, IHK und der Stadt München. Im Open-Space-Format stattfindende Diskussions-Workshops in ruhiger und angenehmer Athmosphäre. Ideal um Kooperationsideen einer interessierten Kreis von Unternehmern vorzustellen und dauerhafte Arbeitsgruppen oder neue Netzwerke ins Leben zu rufen.

 commendIT

http://www.commendit.de/

Auf dem IT-KOOP 2009 entstanderens Empfehlungsnetzwerk mit aktuell 15 Mitgliedern, die sich alle 14 Tage zum Frühstücken treffen um sich näher kennenzulernen, Erfahrungen auszutauschen und Geschäfte zu vermitteln. Jede Spezialisierung innerhalb der IT kommt nur einmal vor, hier enden aber auch die Paralellen zum BNI. Im commendIT wurde die Erfahrung gemacht, dass ein weniger formalisierter Ablauf mehr Raum für Gespräche über das gemeinsame Geschäft bietet. Soziale Events und regelmäßige Fachvorträge runden das Programm ab.

IT-Forum Bayern

http://www.it-forum-bayern.de/

Auf dem IT-KOOP 2010 gegründete und noch immer im Aufbau befindliches Netzwerk, das den Mitgliedern vertriebsunterstützende Maßnahmen bietet. Derzeit ist erst ein Arbeitskreis für die Maschinenbaubranche aktiv. Nicht zu verwechseln mit dem …

ITK-Forum Mittelstand

http://www.itk-forum.eu/

Vortragsveranstaltung mit vier Terminen pro Jahr (zwei in Töging, zwei in München), die von einigen Firmen aus dem Kreis des commendIT-Netzwerks organisiert werden. Auch hier gibt es Fachvorträge kombiniert mit viel Raum für Gespräche. Der Teilnehmerkreis ist nicht auf IT beschränkt, sondern umfasst auch Geschäftsführer mittelständischer Unternehmen.

 

Nun noch einige Netzwerke in denen ich nicht aktiv bin, von denen mir aber gutes Berichtet wurde:

 

Daneben gibt es noch einige lokale Unternehmernetzwerke ohne IT-Bezug, die für mich interessantesten sind:

Für weitere Hinweise zu (insbesondere IT-bezogenen) Netzwerken in der Region bin ich immer dankbar.

 

IT bleibt spanndend,

Christian Eich

eMail-Migrationsprojekt


Hallo, zusammen

gerade habe ich im Blog des Arbeitskreis Maschinenbau des IT-Forum Bayern einen Artikel über ein eMail-Migrationsprojekt bei Weber Schraubautomaten in Wolfratshausen veröffentlicht. Immerhin unser größtes Zarafa-Projekt bislang, mit entsprechenden Herausforderungen 🙂

Das IT-Forum Bayern ist eine Diskussions- und Kooperations-Platform für IT-Dienstleister. Der Arbeitskreis Maschinenbau besteht aus Unternehmern, die sich auf Kunden im Bereich Maschinenbau spezialisiert haben und entsprechende Branchenkenntnis und Erfahrung mitbringen. Neue Mitglieder sind herzlich willkommen.

IT bleibt spannend,

Euer Christian

Vortrag zu Datenschutz und Datensicherung


Hallo, zusammen

letzte Woche durfte ich für die UWW (Unternehmervereinigung Wirtschaftsraum Wolfratshausen) einen Vortrag über Datenschutz und Datensicherung in Unternehmen halten. Thematisch war das für uns kein Problem, aber fast 30 Zuhörer in unserem Büro unterzubringen war eine erchte Herausforderung. Hierfür gebührt meinen Kollegen großer Dank, insbesondere Markus, Richard und Ingrid, die ihr Büro räumen mussten. Als kleine Entschädigung wurde das leere Büro gleich renoviert und farblich aufgepeppt 😉

Die Folien gibt es als PDF zum Download:  Datenschutz und Datensicherung

Und natürlich gab es anschließend noch ein leckeres Buffet und viel Zeit zum Diskutieren und Netzwerken.

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

iSCSI-Performance-Optimierung: 380 MB/s in der VM mit openfiler und ESXi


Hallo, zusammen

(english version)

Zwischen den günstigen iSCSI-Storage-Appliances (QNAP, Thecus, Buffalo, Cisco SMB und Co.) und den „großen“ Storages aus der Fiberchannel-Welt klafft eine große Lücke, sowohl in der Performance, der Features aber insbesondere im Preis. Im WorNet-Labor haben wir eine überzeugende Lösung gefunden, die diese Lücke überbrückt. Natürlich mit OpenSouce-Mitteln!

unsere TestumgebungSchon lange setzen wir den auf Linux basierenden Openfiler für unsere iSCSI-Storage-Server ein. Allerdings waren wir mit der Performance nicht so recht zufrieden. Selbst mit leistungsfähiger Hardware kommt verglichen mit günstigen Appliances (in unserem Fall von QNAP) in den virtuellen Maschinen nur wenig mehr I/O-Leistung an. Die Testphase unseres neuen ESX-Clusters kam uns da sehr gelegen um systematisch an der Performance-Schraube zu drehen.

Hier hat sich ein optimales Vorgehen bei der Optimierung herauskristallisiert, bei dem die Reihenfolge der Optimierungsschritte  entscheidend ist.

Unsere Testumgebung:

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

Je 4 GBit Interfaces werden für iSCSI genutzt. Dabei werden 4 VLANs mit verschiedenen IP-Bereichen definiert. Die Interfaces müssen dem iSCSI-HBA zugeordnet werden bevor die Ziele sichtbar werden.  Dann wird ein Volume mit VMFS formatiert und man erhält einen Datastore mit dem man die Tests durchführen kann. Die Verwendung der Pfade wird auf „Round Robin“ konfiguriert.

virtuelle Testmaschine:

Wir haben eine virtuelle Maschine mit 1 vCPU, 2 GB RAM mit Windows 7 installiert. Die Größe der virtuellen Festplatte sollte mindestens 15 GB + 2 * RAM des Storageservers betragen. Zusätzlich wird IOMETER und ein standardisiertes Konfigurationsfile aus dem VMware-Forum installiert. Mit diesem Test erhält man Werte die mit den Ergebnissen anderer Forumsbeiträge vergleichbar sind.

1. Schritt: Ausgangssituation

Zunächst messen wir die Performance des nicht-optimierten Systems. Dabei wählen wir die Größe des Testfiles bewusst kleiner als der Arbeitsspeicher des Storage-Servers, d.h. wir messen zwar die iSCSI-Anbindung, nicht aber das Festplattensystem.

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

Für 4 GBit Speicheranbindung ist das nicht gerade beeindruckend. Das RAID-System des Storage-Servers liefert lokal im Openfiler gemessen 420 MB/s!

2. Schritt: Optimierung der iSCSI-Speicheranbindung

Jetzt optimiert aggressiv man alle Parameter, die die Speicheranbindung betreffen. Dabei ist es in Ordnung, wenn unsichere Einstellungen (z.B. Write-Cache im RAID-Controller ohne vorhandene BBU) gewählt werden. Auch wählt man die Größe der Testdatei in IOMETER kleiner als den RAM des Storage-Systems, denn wir wollen möglichst wenig Einflüsse der Platten und statt dessen nur den Weg von der virtuellen Maschine bis zum iSCSI-Daemon im Storage-System testen.

Insbesondere konfiguriert man:

  • Netzwerkkartenparameter (Jumbo Frames, TCP-Offload)
  • iSCSI-Parameter (Round-Robin-Parameter)
  • RAID-Controller (Write-Cache einschalten)

Bei uns machte sich das deutlich bemerkbar:

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

Damit sind wir sehr nahe am theoretischen Maximum (4 GBit entspricht ca. 440 MB/s inkl. iSCSI-Overhead).Leistungsanzeige der iSCSI-Pfade bei sequentiellem Zugriff

Wichtig: Machen sie nicht weiter wenn Sie mit diesen Werten nicht 100%ig zufrieden sind. Ab hier wird es wieder schlechter!

Wenn man im vShpere-Client unter Leistung die Nutzung der iSCSI-Pfade bei sequentiellem Zugriff ansieht müssen die Pfade gleichmäßig mit je 1 GBit ausgelastet sein (Bild rechts).

Stolperfallen in unserem Test:

  • fehlerhafte Jumbo-Frame-Konfiguration (Test: Ping mit großen Paketen und Dont-Fragment-Bit), hierbei auch an den Switch (Cisco 2960S: „set mtu jumbo 9000“) denken!
  • Der Round-Robin-Algorithmus bei ESXi wechselt den Pfad im default nur nach 1000 IO-Operationen. Das muss man mit einem esxcli-Befehl umstellen.

3. Schritt: Optimierung der Storageparameter

Jetzt stellt man sinnvolle Werte für den Produktivbetrieb ein und  erhöht die Größe des Testfiles für IOMETER auf das doppelte des RAM des Storageservers. Aufpassen die „Maximum Disk Size“ wird in Blocks angegeben, ein Block hat 512 Bytes.

In unserem Fall haben wir nun verschiedene Raid-Level und Spindelzahlen verglichen.

Raid-10 mit 4 Platten zu je 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 mit 8 Platten:

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

Die Erhöhung der Anzahl der Festplatten von 4 auf 8 bei RAID-10 hat sich erstaunlicherweise nicht signifikant ausgewirkt. Da ist besser zwei unabhängige Datastores mit je 4 Platten anzulegen.

Ein Test mit einem RAID-6 aus 8 Festplatten ergab noch schlechtere Werte, insbesondere beim Random-Zugriff.

Fazit:

Mit knapp 400 MB/s und >10.000 IOPS sind wir absolut glücklich. Unser x86-Server mit Openfiler (ca. 4.000 Euro) schließt die Lücke zwischen den „kleinen“ (ca. 1.000 Euro und 70 MB/s und 2.000 IOPS) und den „großen“ jenseits der 10 k€.

Eine weitere Verbesserung der IOPS oder Latenzen ist mit schnelleren Festplatten, SSDs oder SAS-Platten sicher realisierbar. Eine Storage-Replikation ist mit „drbd“ machbar, wurde aber in diesem Test nicht untersucht.

Dieser Artikel basiert auf den Testreihen und Erfahrungen von Christian Eich, Richard Schunn und Toni Eimansberger.

IT bleibt spannend,

Christian Eich

Gedanken zum Cloud-Ausfall bei Amazon – Teil II


Hallo, zusammen

Ausfälle haben eine unangenehme Eigenschaft, sie richten sich nicht nach denen, die sie zu verhindern suchen. Vielmehr gehorchen sie Murphys Gesetz: „If anything can go wrong it will.“

Wie kann man sich also gegen den Ärger eines Ausfalls schützen?

  • Durch Service Level Agreements? Die verhindern zwar den Ausfall nicht, aber man fühlt sich zumindest besser im Fall der Fälle.
  • Durch Investition in Höchstverfügbarkeit? Damit reduziert man (hoffentlich) die Wahrscheinlichkeit eines Ausfalls aber auch die Komplexität und die Kosten.
  • Durch Resignation vor dem Unausweichlichen? Ja warum denn eigentlich nicht?

Wenn Fehler ohnehin passieren, kann man sich auch schützen indem man ihnen den Schrecken nimmt. Indem man sie zu einem Teil seiner Kultur macht. Diesen Ansatz liebe ich weil er zutiefst pragmatisch ist und den Fokus auf das Ergebnis lenkt statt auf die Anzahl der 9er in einer Statistik.

Ein Chaos-Affe?

Genau das hat auch der erfolgreiche amerikanische Filmverleiher Netflix getan und den „Chaos Monkey“ erfunden. Der Chaos Monkey ist ein Prozess, der zufallsgesteuert Teile der Netflix-Software beendet. Dieser Prozess läuft ständig im Produktiv-System!

Warum sollte jemand in einer Produktiv-Umgebung soetwas tun? Weil die Fehler ohne den Chaos Monkey ohnehin passieren (nur eben seltener). Der Chaos Monkey hilft den Entwicklern mit Fehler sinnvoll umzugehen, keine falschen Annahmen zu treffen und immer ein sinnvolles Ergebnis zu liefern, egal was schief geht. Denn keiner denkt mehr „das wird schon nicht schiefgehen“, vielmehr hat der Entwickler die Gewissheit, dass der Chaos Monkey auch seinen Code findet. Gleichzeitig werden alle automatischen Prozesse, die Fehler korrigieren, Prozesse neu starten, etc. fortwährend getestet.

So verbessert der Chaos Monkey sowohl die Software-Qualität als auch die Robustheit des Systems. Und das hat dazu beigetragen, dass Netflix den Amazon-Ausfall  unbeschadet überstanden hat, obwohl viele ihrer Server betroffen waren.

Standhaft durch Nachgeben

Ein bisschen erinnert mich das an das Judo-Prinzip „Siegen durch Nachgeben“. Statt seine Prozesse wie Trutzburgen gegen den Ausfall zu stemmen lässt man den Ausfall über sich ergehen und ist schnell wieder einsatzbereit, und geht während dessen bestmöglich damit um. Denn nicht die Ausfall-Statistik entscheidet am Ende des Tages sondern das Gesamtergebnis!

Weitere Interessante Artikel:

IT bleibt spannend,

Christian Eich

Gedanken zum Cloud-Ausfall bei Amazon – Teil I


Hallo, zusammen

Was lernen wir aus dem Ausfall der Amazon Cloud an Ostern?

Am Osterwochenende 2011 gab es einen großen Ausfall in einem der Amazon-Rechenzentren, das virtuelle Rechner als „elastic Cloud“ (EC2) bereitstellt (http://aws.amazon.com/message/65648/). Dabei waren viele Server für mehr als 24 Stunden nicht verfügbar. Bei einem sehr kleinen Teil davon gingen auch Daten unwiederbringlich verloren (http://www.heise.de/newsticker/meldung/Wolkenbruch-bei-Amazon-Datenverlust-in-der-Cloud-1234444.html).

Die technischen Ursachen dieses Ausfalls sind mittlerweile untersucht und Amazon wird sicher Maßnahmen ergreifen. Darüber ist schon hinreichend viel geschrieben worden. Kurz gesagt hat der Ausfall von Netzinfrastruktur die Verbindung zwischen den Datenspeichern gestört, worauf diese riesige Datenmengen auf Ausfallsysteme kopiert haben, was das Netz weiter lahmgelegt hat. Daneben war die Datenmenge wohl auch zu groß für die zur Verfügung stehenden Reservesysteme.

In der Diskussion fehlt mir aber eine allgemeinere Betrachtung der Konsequenzen für die IT-Landschaft und was der einzelne Unternehmer tun kann um sich abzusichern.

Cloud-Rechenzentren sind hochkomplex und nicht unfehlbar

Die veröffentlichte Forensik des Ausfalls ergibt ein Bild der hochkomplexen Redundanzen und Automatismen mit denen Amazon seine Cloud-Dienste ausgestattet hat. Ein Fehler führte zu automatischen Korrekturmaßnahmen, die für den Ausfall einzelner Systeme gedacht waren, aber beim Ausfall größerer Strukturen eine unsinnige Flut von Datentransfers zur Folge hatte.

Ein menschlicher Operator hätte wohl niemals eine solche Masse an Replikations-Aufträgen gleichzeitig gestartet!

Komplexität und Verfügbarkeit sind schwer unter einen Hut zu bringen

Bei WorNet gilt das „KISS-Prinzip“ (Keep it simple and stupid) nachdem insbesondere alles so auszulegen ist, dass der diensthabende Mitarbeiter, der nachts um 2 Uhr aus dem Bett geklingelt wird, die Fehlersuche auch unter Schlafmangel und Stress sicher ausführen kann.

Automatisch dürfen nur triviale Dinge passieren, und dieser Automatismus muss sicher abgeschaltet werden können. Das bedeutet zwar häufigere kleine Ausfälle, die ein Automatismus wohl abgefangen hätte. Aber die großen Ausfälle sind seltener und dauern weniger lange an, da ein Amok-laufender Automatismus die Lage nicht zusätzlich verschlimmert.
Ein Problem am DECIX in Frankfurt hatte zum Beispiel letztes Jahr Auswirkungen auf einen unserer Router in München. Der Operator konnte diesen Router einfach durch Unterbrechung der Stromzufuhr deaktivieren und in Ruhe die Logfiles durchsuchen. Der Betrieb hat sich unmittelbar stabilisiert und die Zahl der betroffenen Systeme wurde so sehr klein gehalten. Erst nachdem der Vorfall verstanden war wurde das System wieder in Betrieb genommen.

Dank „KISS-Prinzip“ mussten wir noch nie mehr als 4 Stunden Ausfall verkraften.

Im zweiten Teil geht es darum welche Bedeutung einzelne Rechenzentren erlangen können und wie man sich als Kunde gegen Ausfälle schützen kann.

IT bleibt spannend,

Euer Christian Eich

Veranstaltungs-Tipps


Hallo, zusammen

in der Zeit zwischen den Oster- und den Pfingsferien häufen sich die interessanten Veranstaltungen. Ein kleiner Überblick:

Vielleicht treffen wir uns ja bei einer dieser Gelegenheiten?

IT bleibt spannend,

Euer Christian Eich