Dragon Age

Ich hab nun seit fast drei Wochen nicht mehr „geblogged“. Das lag zum einen an einem Besuch bei der TechEd, den ich noch sortieren muss, bevor ich dazu hier was blogge, zum anderen an meiner Arbeit, die einfach wenig Zeit lies. Ein Grund heißt allerdings auch DragonAge. Das neuste Machwerk von Bioware. Bis letztes Jahr stand ich dieser Firma eher skeptisch gegenüber. Nach dem grandiosen BuldersGate 1 hatte mich BuldersGate 2 so enttäuscht (besonders das Ende), dass ich eine geraume Zeit einen Bogen um klassische RPGs und BuldersGate Spiele im besonderen gemacht habe. Gut das viel mir nicht schwer. StarWars interessierte mich nie und Never-Winter-Nights wahr nur mehr vom gleichen… Erst letztes Jahr traute ich mich mal wieder ein Bioware Spiel auszuprobieren: Mass Effect. Ich hab es nicht bereut. Diesmal hab ich mich an ein „klassisches“ RPG von Bioware gewagt. Was soll ich sagen? Wer dieses Meisterwerk verpasst ist selber schuld! Dieses Spiel hat alles, was ein richtiger Rollenspieler braucht um sich von der Außenwelt abzuschotten. Sehr gute Story, umfangreiche und tief gehende Charaktere, ein Kampfsystem, dass auch Profis fordert, nur die Technik hingt dem ein wenig hinterher.

Der bewusste Bruch mit den Tabus

Ein Oger muss sterben
Ein Oger muss sterben
Obwohl DragonAge als “geistiger” Nachfolger von Bulders Gate gehandelt wurde (Bulders Gate nur in “schön”) gab sich Bioware und EA alle Mühe das MickiMaus-Flair der Rollenspiele abzulegen. Das sollte eine Spiel “für Erwachsene” werden. Was in erster Instanz hieß: Gewalt im Übermaß.

Die ersten DragonAge Videos und Footages die gezeigt wurden, waren bewusst auf Brutalität und Gewallt getrimmt. Manchmal hat man sich gefragt, ob neben dem “New Shit” noch andere Inhalte ins Spiel implementiert werden. Gut, böse Zungen beantwortet die Frage recht schnell: Sex! Diesmal sogar zwischen Männern! Das mag für prüde Amerikaner ein Aufreger sein, in meiner Hemisphäre kräht da kein Hahn nach, besonders wenn die Protagonisten dabei die Unterwäsche anlassen… Eins vorweg, das Spiel ist so, wie in den Videos gezeigt. Es spritzt Blut wie Wasser, Köpfe rollen und Gegner zerfallen in ihre Einzelteile wenn man es drauf anlegt. Fällt ein besonders schwerer Gegner kann man einem seiner Character in Zeitlupe dabei zuschauen, wie der finale Todesstoß ausgeführt wird. Dennoch tritt diese Gewalt eher in den Hintergrund. Zum einen liegt das am Spielablauf. Es wirkt nie aufgesetzt. Ein Kampf wirkt wie ein solcher. Es benötigt keine aufploppenden Zahlen um zu sehen, dass man einen Treffer gelandet hat. Man sieht es an den Gesichtern, Bewegungen und “Emotionen”. Wenn ein Krieger einen Schildhieb durchführen soll, sieht man, wie dieser ansetzt, wie das Schild beim Feind einschlägt und wie es den Gegner von den Füßen hebt. Man Fühlt sich mitten drinn. Das wird vor allem durch die “Schulterperspektive” der Kamera verstärkt. Wenn man sich zeit nimmt, kann man sogar die schmerzverzerrten Gesichter betrachten. Man hat nie das Gefühl, in einer Welt zu agieren die von fallenden Würfeln diktiert wird.

Der Hauptgrund warum die Gewalt nicht auffällt ist jedoch die Story selber. Ein Großteil der Brutalität kommt nicht durch “Bildgewalt” sondern durch die Geschehnisse selbst. Alleine in den ersten zwei Stunden wird man verraten, verfolgt, verliert seine Familie und findet sich einem Gegner gegenübergestellt, der direkt aus der Hölle kommt. Angesichts dieser Rahmenbedingungen rückt die Darstellung fast in den Hintergrund. So wie die Story beginnt, geht sie aber auch weiter. Man steht immer wieder vor zentralen Entscheidungen die auf beiden Seiten Verluste bedeuten, keine klaren “Gut/Böse” Entscheidungen. Anders als bei den meisten RPGs ist bei diesen Entscheidungen im ersten Momenten (Durchspielen) nicht klar, welche Konsequenzen sie haben werden oder ob sie überhaupt welche haben.

In neuen Landen

Ein Kampf mit einem Drachen
Ein Kampf mit einem Drachen
„Technisch merkt man DragonAge die Jahre der Entwicklungszeit an,“ das ist eine Floskel die man häufig im Zusammenhang mit Dragon Age ließt und hört. Und ja es stimmt. Die Landschaft könnte detaillierter sein. Aber das ist auch schon das einzige was ich an Optik bemängeln kann. Sowohl in Charakter als auch Zauberdarstellung setzt das Spiel zwar keine Maßstäbe, platziert sich aber für ein RPG sehr weit vorne. Jede Bewegung ist schön animiert. Einen hoch gerüsteten Charakter erkennt man an seiner Rüstung sofort. Was eher stört ist der Rest der Technik. Gerade wegen der guten Charakteranimationen fällt es auf, dass die Sprachausgaben nicht gut eingepasst wurden. Teilweise halten die Charakter „reden“ ohne ein Wort zu sagen (sowohl in der deutschen als auch der englischen Version). Hinzu kommt, dass die einzelnen Soundfiles schlecht abgemischt wurden. Unterschiedliche Charaktere sprechen unterschiedlich laut. Teilweise wechselnt im Gespräch mit einem Charakter die Lautstärke mehrfach. Das wird nur noch von Szenen getoppt, in dem die agierenden Charaktere nicht im Bild sind oder Dinge nicht so „gescripted“ sind, wie sie sein sollten. So was kann einen aus der ansonsten völlig vereinnahmenden Spielwelt sehr schnell raus reißen. Auch Bugtechnisch ist Bioware nicht der Wurf gelungen. Besonders bei längerer Spielzeit stürzt das Spiel gerne mal ab. produziert Bildfehler oder wird extrem lahm, so das man Neustarten muss. Das ist aber alles Meckern auf sehr hohen Niveau. 95% der Spielzeit wird man damit beschäftigt sein, seine Gruppe durch eine der besten Story der letzten Jahre zu führen.

Mass Gate 1.25

Eine Hexe der Wildniss
Eine Hexe der Wildniss

Wenn man das Spiel das erste mal startet, fühlt man sich irgendwie Heimisch. Spätestens wenn man einige Gespräche geführt hat, fragt man sich, ob das gerade Mass Effect war. Die Animationen hat man doch schon mal gesehen. Welches Team da von wem Profitiert hat, entzieht sich meine Kenntnis. Aber DragonAge gibt sich keine Mühe seine Wurzeln zu verstecken. Bulders Gate, NeverwinterNights, KOTR und MassEffect sind nun auch nicht die schlechtesten Wurzeln. Wie in fast allen Bioware spielen (und sonstigen RPGs) steht am Anfang die Generierung des Charakters. Leider nicht so schön integriert wie in Mass Effect aber dafür mit wesentlich mehr Möglichkeiten. Alleine für die Nase gibt es jetzt 8 Anstatt 4 Regler. Ein klarer Rückschritt gegenüber MassEffect ist, dass der eigene Charakter nicht spricht. Man kann zwar eine Stimme festlegen aber diese wird nur genutzt wenn der Charakter den Kampf kommentiert. Auch die Basisklassen sind stärker gelichtet als sonst. Es stehen nur drei Klassen zur Verfügung (Krieger, Schurke, Magier). Diese können zwar im Laufe des Spieles nochmal spezialisiert werden (4 Spezialbereiche für jede Klasse) aber wirklich “viel” ist das nicht. Bioware punkten definitiv mit Klasse statt Masse. Denn die Klassen spielen sich extrem unterschiedlich. Was gegenüber Mass Effect stark ausgebaut wurde, ist der “Background” die man wählen kann. Die Wahl des Volkes und der Herkunft hat nicht nur Auswirkung auf eine handvoll Gespräche. Für jede Herkunft (Adliger – Mensch, Adliger – Zwerg, Stadt – Zwerg, Magier – [Alle Rasse], Darish – Elf, Stadt- Elf) gibt es eine Origin-Geschichte von rund 1 1/2 Stunden Spielzeit und zieht sich dann mit Anspielungen und Konsequenzen durch die ganze Story. Dieser Einstieg dient als Tutorial. Wer jedoch Angst hat, dass es dabei ruhig zugeht irrt. Wie schon in MassEffect beginnt das Spiel ohne große Anlaufphase. Das Tutorial ist direkt in die ersten Geschehnisse integriert. Spätestens auf dem dritten der vier Schwierigkeitsgrade, wird sogar die Einführung zur Prüfung.

Klasse statt Masse

Im ersten Moment mag man jedoch denken, dass die Origin Geschichten nur dazu dienen “künstlich” den Wiederspielwert zu erhöhen. Enden sie doch alle im gleichen Ausgangspunkt für die Hauptstory. Doch das Kampfsystem stellt sich als eigentlicher Hauptgrund her raus. Da man immer nur drei Gefährten mitführen kann, kristallisiert sich schnell eine “Rumpfgruppe” her raus. Wie in Rollenspielen üblich benötigt es in einer Gruppe einen Tank und einen Heiler. Will man sich nicht einen Großteil der Einnahmen und Abkürzungen verbauen braucht es noch einen Schurken. Jeh nachdem, wie man seinen Hauptcharakter ausbaut, muss man die restlichen Partie-Plätze besetzen. Auf den ersten Blick erscheint die Gruppenzusammstellung damit recht statisch. Doch Bioware hat die Klassen sehr flexibel gestaltet. Schurken und Krieger haben gleiche mehrere Überschneidungen in Eigenschaftsbäume (Kampf mit zwei Waffen, Bogenschütze, …). So kann man einen Offensiven – Krieger ohne weiteres gegen einen Schurken austauschen und umgekehrt. Dennoch spielen sich die Klassen aufgrund ihrer zusätzlichen Spezialisierungen so unterschiedlich, dass es Sinn macht, die Charactere durch zu tauschen oder mehrfach durch zuspielen. Die Magierklasse spielt im ganzen Spiel eine ganz eigene Rolle. Die Auswirkung der Talentbäume sind bei dieser Klasse am Größten. Von Gestaltwandler über Heiler und Unterstützer bis zur wandelnden Naturgewalt hat man die freie Wahl. Jeder Talentbaum spielt sich dabei fundamental anders. Man kann (und muss) ohne Probleme mehrere Bäume kreuzen. Mittels eines “Fluchs” die Resistenzen der Feinde runter setzten und anschließend eine Naturgewalten auf sie niederregnen lassen oder alle Gegner einfrieren und dann mit einem Erdbeben dafür sorgen, dass die gefrorenen Gegner zersplittern. Die Kombinationen sind unzählig und mächtig. Fast schon zu mächtig. Ein gut eingesetzter Magier ist durchaus in der Lage 8 bis 10 Gegner gleichzeitig ins Nirwana zu jagen, wohlgemerkt mit zwei Zaubern! Einige der kniffligsten Stellen im Spiel (die auf Gegnermassen basieren) sind mit ein wenig Vorsehung (ein Skill) und dem richtigen Timing schlicht langweilig. Da der Magier durch Wände hinduchzaubern kann, kann er in einem Nachbarraum die lauernden Gegner schon so dezimieren, dass von der übermacht nur noch der Bossgegener mit 50% Leben übrig bleibt. Auf der anderen Seite begründet sich Hauptschaden des Magiers in Flächenschaden. Jeh nach Schwierigkeitsgrad kann man damit auch Verbündete schädigen. Kommt es also zu Tumulten (und das passiert häufig) verliert der Magier sein schärfstes Schwert, wohl dem, der dann noch Unterstützungszauber parat hat.

Auf in den Kampf

Türblockade
Türblockade
Die Kämpfe an sich spielen sich alle sehr dynamisch. Da auch der Gegner über alle Klassenzusammenstellungen verfügt, muss man nicht nur seine Gruppe im Griff haben, man muss auch seine Taktik ständig anpassen können. Da man in den Missionen (meistens) seine Charaktere nicht durchtauschen kann muss man vorausplanen. Kommt es dennoch zu einer Begegnung mit nicht optimaler Ausgangslage wird das Spiel erst richtig spannend. Schaltet man zuerst den Bossgegner aus und ignoriert das Gesocks? Oder lenkt man den Bossmob ab und nimmt sich erst die nervigen Bogenschützen vor? Die Frage ist nicht immer gleich zu beantworten. Alle Kämpfer im Spiel haben 4 Trefferzonen: Vorne, die beiden Seiten und der Rücken. Im Rücken gibt es keinen Schutz durch Schild oder Ausweichen. Nahkämpfer können hier ohne Probleme (vermehrt) kritischen Schade austeilen. Das funktioniert aber in beide Richtungen. Ignoriert man das “Fußfolk” wird es sich zwangsweise um den Tank versammeln. Das hält der beste Plattenpanzer nicht aus. An Engpässen ist das kein Problem. Da sich Charaktere nicht durch andere hindurch beamen können, kann man so geschickt Blockaden errichten. Man muss immer geschickt die Umgebung nutzten oder die Gegner in ihrer Bewegung einschränken.

Fazit

Was soll man sagen. Dragon Age hat mich in seinen bann gezogen… Ferelden wartet auf meine Rettung zu dritten oder vierten mal 😉

Karmic Koala auf der Seashell

Hier war es eine weile sehr ruhig, dass hatte zwei Gründe. Erstens hatte ich Urlaub (die letzte Woche) zum anderen hat sich gezeigt, dass beim Netbook-Remix von Jaunty (9.04) auf Karmic (9.10) sehr viel passieren würde. Es hätte wenig Sinn gemacht, den Jaunty auf der Seashell bis zum Brechen zu optimieren, um ihn anschließend durch den Karmic zu ersetzten.

Darum dreht sich die Frage ja im Grunde. Lohnt es sich, eine funktionierende  Jaunty-Netbook-Installation durch eine Karmic zu ersetzten. Kurz und knapp: Ja. Sämtliche Funktionen der Seashell funktionieren Out-of-the-Box. Hier nochmal die Auflistung:

  • WLAN und LAN: Beide Interfaces werden erkannt und können sofort genutzt werden.
  • HotKeys/LEDS: Fast alle wichtigen HotKeys (WLAN ausschalten, usw) funktionieren tadelos. Ausnahmen Touchpad-deaktiviern
  • Suspend to Disk/Ram: laufen jetzt besser/robuster.

Diese Verbesserungen sind zu großen Teilen auf den neuen Kernel (2.6.31) zurückzuführen. Hier war der Jaunty einfach „benachteiligt“. Beim damaligen Release hat sich in zu vielen Treiberteilen, die die Netbooks betreffen, zu viel getan. Besonders hart hat es den Treiber der Intel-Grafikkarten getroffen. Dieser war im alten Kernel einfach „gebrochen“. Die Performance ist zwar immer noch hinter den Windows-Treibern aber schon erheblich besser als unter Jaunty.

Das Design und die Bedienung wurden im Detail verbessert. Es wirkt alles aufgeräumter und dezenter.

Munin und 3Ware

Hinter Munin versteckt sich ein sehr puristisches aber brauchbares Monitoring-Tool um ein ganzes Netzwerk zu überwachen. Munin besteht dabei aus zwei Teilen. Der Node und einem Crawler, der zyklisch (5 Minuten) alle bekannten Nodes abfragt. Danach werden Graphen von den gesammelten Daten über die Zeiträume Tag, Woche, Monat und Jahr erzeugt. Damit lassen sich gut Trends und Ungereimtheiten ablesen. Dazu wird noch rudimentäres „Alerting“ geboten. Über/Unter-schreitet ein „getrackter“ Wert ein vorgegebenes Limit, wird eine Warnmail ausgesendet. Zudem wird der Wert Farblich zusätzlich markiert, so das man beim Kontrollieren der Status-Webseite sofort sieht, das was im Argen liegt.

Die Node bietet dabei von Start weg überhaupt keine Funktionalität. Alles was man angezeigt bekommen will, muss via Plugins geliefert werden. Die Communitie bietet hier jedoch ein extrem umfangreiches Repertoire an schon vorhanden Plugins. Darunter auch Plugins die SNMP Quellen abfragen.

Nun bieten 3Ware einen SNMP Zugang zu allen RAID-Daten. Nur ist dies leider sehr umständlich. Da sich Plugins sehr einfach schreiben lassen, hab ich einfach drei Plugins geschrieben, die mir die wichtigsten Daten extrahieren und in Munin zur Verfügung stellen. Ich benutzte dazu „tw_cli“ welches von 3Ware mitgeliefert wird. Anschließend wird dessen Output ausgewertet und dargestellt.

die Sources gibt es hier:

  • RAID-Status: Liefert den Status aller im System bekannten RAID-Units
  • RAID-Unit-Status: Listet den Status aller physikalisch Einheiten einer RAID-Unit.
  • BBU – Status: Liefert den Status der installierten BBUs

Performance vs Verschlüsselung

Wenn man einen File-Server betreibt, so kann man unglaublich viel Zeit darin investieren, den Raid zu planen, die Verschlüsselung einzurichten und das Netzwerk zu tunen. All das nutzt aber nichts, wenn am Ende der Benutzer glaubt, die Bytes einzeln über die Leitung schieben zu müssen.

Dass kann bzw wird passieren, wenn man seinen File-Server verschlüsselt. Der tollste RAID bringt wenig, wenn er auf den CPU warten muss, weil dieser fröhlich am ent-/verschlüsseln ist. Hier liegt ein grundlegender Widerspruch zwischen zwei Anforderungen vor. Jeh stärker man die Verschlüsselung forciert, desto langsamer wird der Datenzugriff.

Die erreichten Werte skalieren dabei jedoch nicht wie erwartet. Und überhaupt fällt es im ersten Moment schwer, die wirklich wichtigen Parameter auszumachen. Zuallererst müssen die Rahmenparameter abgesteckt werden:

  • Wichtig ist die LAN-Anbindung. 100MBit/s oder 1GBit/s. Beides Transferraten sind wesentlich langsamer, als dass was fast alle RAIDs (auch Software RAIDs) Zustande bringen. Aus dem Stand schaffte mein Testsystem 251,59MByte/s (write) und 293,41MByte/s (read). An dieser Stelle sei darauf hingewiesen, dass man von Bits in Byte umrechnen muss. (1GBit/s=1024MBit/s = 128MByte).
  • Der zweite Rahmenparameter sind die Clients, bzw. deren Festplatten. Die maximale Transferrate ergibt sich aus der Lese/Schreibgeschwindigkeit dieser Komponente. In großen Netzwerken sollte kann man das getrost ignorieren, da immer mehrere Clients den Server ans Limit fahren. Im Privatgebrauch, mit weniger als fünf Clients, sollte man aber schon mal schauen wie viel Power man wirklich braucht. Dazu nimmt man seine „schnellste“ Kiste (in meinem Fall 60MByite/s Read/40MByte/s Write) und nimmt die mal 1.5. Das ist zwar kein wissenschaftlich ermittelter Wert, aber über den Daumen reicht das.

Neben diesen „harten“ Rahmenbedingungen gibt es noch eine Reihe weicher „Auswahlkriterieren“. Bei fast jedem Benchmarktool bekommt man verschiedene Werte der „Festplatte“ ausgewiesen. Sequenzjelles(Block) Lesen/Schreiben, zufälliges Lesen/schreiben und so weiter. Eine Fülle von Informationen von denen man nicht weiß, welcher Wert wichtiger ist. Zur Vereinfachung lässt sich sagen, dass bei einem Fileserver in 90% der Fälle das sequenzielle Lesen/Schreiben wichtiger ist.

Zum Testszenario: Alle Verschlüsselungs/Cipher-Algorithmen-Kombination musste ein 750GB Device verschlüsseln, wobei auch verschiedene Schlüssellängen durchprobiert wurden. Als überlagertes Dateisystem kam XFS zum Einsatz. Der CPU (ein 2.5GHz Intel Core 2 Duo) übernahm dabei nur die Krypto-Aufgaben. Der (Hardware) RAID-Controler war für die IO Zuständig. Die 4GB RAM kann man ausklammern, da der Benchmark (in diesem Fall bonnie++) bewusst den RAM umgeht. Bei einem Testfile von 8GByte Nutzt einem weder der 4GByte-RAM noch die 256 MByte Controller-Cache irgendwas. Was ja auch Sinn dieser Test ist. Das ganze lief unter einem 64 Bit Ubuntu 9.04

Zum Ergebnisdiagramm:  Der RAID lieferte nativ (unverschlüsselt) 252 MByte/s (Block Write) und 293,41 MByte/s (Block Read). Dies ist nicht auf dem Diagramm zu sehen, weil dann die Skalierung unvorteilhaft geworden wäre. Die ersten 3 Testwerte stellen daher die „praktischen“ Referenzwerte dar. Als maximal physikalische Obergrenze steht dabei die 1GBits Ethernet Verbindung. In der Praxis bringt die es bei mir ungefähr auf 800 Mbit/s (100MByte/s), folglich sind alle IO-Bandbreiten, mit mehr Leistung sinnlos. Als zweiten Referenzwert hab ich die Festplattenleistung aller meiner Clients gemessen und deren Ergebnis gemittelt. Mehr Leistung als diese ist zwar nett, da dadurch mehrere Rechner gleichzeitig auf dem Server arbeiten können aber sonderlich viel mehr Leistung wird nicht gebraucht, da dass Netzwerk aus nicht mal 5 Rechnern besteht. Der dritte Referenzwert ist der Wert der (mich) am meisten überrascht hat. Es ist die Rohleistung die der Standard SMB-Client (libsmbclient 2:3.3.2-1ubuntu3.2) auf die Leitung bringt. Überraschend deswegen, weil er schneller schreiben als lesen kann. Ob dies an meiner Serverkonfig liegt, konnte ich noch nicht verifizieren.

Alle Tests fanden Donnerstag von 23 bis Freitag 2 Uhr statt.


Verschlüsselung Performance Statistic
Verschlüsselung Performance Statistik

CPU Auslastung
CPU Auslastung

Speicher Auslastung
CPU Auslastung

Die Auswertung: Da der Referenzbalken der Unverschlüsselten Performance fehlt, sieht das Ergebnis Feld ganz brauchbar aus. Das täuscht. Als erstes fällt auf, dass sich alle Algoritmen-Mischungen ungefähr gleich geschlagen haben. In absoluten Zahlen ausgedrückt sieht das wie folgt aus:

  • Write Char: Der schlechteste Wert ist 66.25 MByte/s und erreicht somit noch immer 91% der nativen Leistung. Ach die Streuung ist vernachlässigbar, Zwischen dem schnellsten und langsamsten Algorithmus liegen gerade mal 3 MByte/s.
  • Write Block: Der eigentlich interessante Wert für einen Fileserver weißt die erste Überraschung auf. Hier bringt es der schnellte Algorithmus gerade mal auf 61% (152 KByte) der ursprünglichen Leistung. Die Streuung ist hier auch am größten. Zwischen den beiden Extremen liegen 60 KByte/s. Das ist gemessen am absoluten Leistungsverlust (99MByte/s) ein enormer Wert.
  • Rewrite: Hier zeigt sich wieder ein ähnliches Bild wie beim „Write Char“-Test. Das Ergebnisfeld ist dicht beieinander. Mit einem Maximalunterschied von 6KByte/s spielt es fast keine Rolle.
  • Read Char: Auch hier das gleiche Bild. Alle Algorithmen liegen dicht beieinander. Auch der Verlust hält sich in Grenzen. (7KByte/s)
  • Read Block: Die größte Überraschung am Schluss: Mit einem Leistungsverlust von fast 80% schlagen sich alle Algorithmen in dieser Disziplin schlecht. Zudem gibt es hier wieder nennenswerte Unterschiede zwischen den einzelnen Algorithmen.(20KByte/s bei einem absoluten Verlust von 230 KByte/s) Da dies eine Königsdisziplin der FileServer ist (Dateien ausliefern) gebietet es sich, hier genauer hin zuschauen.

Neben diesen Einzelwerten fällt auf, dass die Leistung der Algorithmen nicht skaliert wie man es erwartet. Das liegt zum einen daran, dass der absolute Verlust an der Dimensionierung der CPU im Vergleich zur nativen Leistung hängt. Auf Deutsch:Der CPU gibt die maximale IO-Geschwindigkeit an, ein Monster RAID + LowCost CPU ist blöd. Der RAID wird sich die ganze zeit langweilen, weil der CPU nur am Rödeln ist. Hier wird auch klar, dass nachrüsten von Speicher an so einer Leistungsgrenze wenig bringt. Der Flaschenhals ist die CPU. Dass sieht anders aus, wenn man einen Software- oder Fake-RAID benutzt. Zum anderen skallieren die Algorithmen selber nicht wie erwartet. Wenn ein Algorithmus gut im Random-Access ist, sagt das noch lange nichts über seine Leistung im Block-Lesen oder gar Schreiben aus.  Dass Schreiboperationen performanter als Leseoperationen durchgeführt werden, entzieht sich komplett meiner Logik.

Neben diesen reinen Duschsatzzahlen war es interessant Festzustellen, dass alle Algorithmen aus CPU-Sicht gleich aufwändig sind. Die Auslastung lag fast immer am Limit. Auch wenn das CPU-Diagramm etwas anderes vermuten lässt. Im ersten Moment sieht es so aus, dass der CPU eine hohe IDLE-Rate hat (Pink+Türkies). Das ist aber nur die halbe Wahrheit. Besonders bei dem langen Block nach den Test (von 3 Bis 4 Uhr – hier wurden 180 GByte Backupdaten wieder auf den RAID aufgespielt) fällt auf, dass es faktisch nur noch drei Statie gibt, in dem sich der CPU befindet: IDLE, IOWAIT oder SYSTEM.  Eigentlich müssten sich IOWAIT und SYSTEM zu 100% ergänzen. Der Grund für das IDLE ist einfach: Keine oder kaum Parallelisierung. Ein CPU hat sich immer gelangweilt. Das hat den Vorteil, dass das System trotz Vollast noch gute Antwortzeiten aufweist und einsatzfähig ist, kostet aber enorm an Durchsatz.

In hab mich für den aes-xts-plain mit einer Schlüssellänge von 256 entschieden. Da dieser die beste Block-Read/Write Performance hat. AES-ECB ist zwar nochmal eine ganze Ecke schneller (besonders beim lesenden Zugriff) jedoch ist dieser Algorithmus für eine reihe von Angriffen anfällig, die bis zur Extraktion der Krypto-Keys gehen.

[UPDATE] Nach der Veröffentlichung in den ubuntuusers-Foren hat mich Red Radish darauf hingewiesen, dass viele der hier genannten Verschlüsselungs-Algoritmen zwar möglich aber wenig sinnvoll sind. Leider ging das aus den Seiten die ich biss her gelesen hab nicht hervor. Die Anzahl der „sinnvollen“ Ciphers sind:

  • aes-ecb
  • aes-cbc-essiv:sha256
  • aes-lrw-benbi
  • aes-xts-plain
  • twofish-cbc-essiv:sha256
  • twofish-lrw-benbi
  • twofish-xts-plain

Danach sieht das Diagramm etwas übersichtlicher aus.


Verschlüsselung Performance Statistic
Verschlüsselung Performance Statistik

Links:

Verschlüsselung von RAIDs

Will man einen RAID verschlüsseln, steht man vor verschiedenen Problemen. Zuallererst muss man sich klar werden, dass eine Verschlüsselung die Datensicherheit (Redundanz) gefährden kann. Tausend Backups nützen nichts wenn der Schlüssel bzw. das Schlüsselfile verloren gegangen ist. Das klingt banal, schießt einen aber ins Knie, wenn der RAID bei einem Systemausfall die wichtigen Daten am Leben hält, das Schlüsselfile aber mit ins Nirwana gegangen ist.

Umgekehrt torpediert dein RAID meist mit der schieren Masse an  Daten die Datensicherheit im Sinne des Zugriffsschutzes. Je mehr Daten man mit dem gleichen Schlüssel verschlüsselt, desto „leichter“ lässt sich der Schlüssel aus dieser Menge extrahieren. Ab 2 GByte sollte man sich intensiv damit beschäftigen, welchen Verschlüsselungsalgorithmus (Cipher) man verwenden kann und mit welcher Schlüssellänge man arbeiten sollte.

Neben solchen theoretischen Vorüberlegungen muss man sich aber auch klar werden wie man Verschlüsseln will. Welche Features will man nutzen, worauf kann man verzichten. Ich für meinen Teil hatte klare Vorstellungen von meinem Setup:

  • FullDiskEncryption (FDE): Das RAID Array soll im ganzen verschlüsselt werden.
  • Dynamische RAID-Vergrößerung: Ab gewissen Speichergrößen ist eine Verdopplung des Speichers nicht mehr praktikabel oder schlicht bezahlbar.

Beide Punkte zusammen haben jedoch ihren Knackpunkt. Nicht alle Verschlüsselungstechnologien sind bei FDE (oder überhaupt) in der Lage einmal verschlüsselte Container/Volumes in der Größe zu verändern. TrueCrypt kann dies nur bei Containern und dann mit einem Performance-Overhead, der inakzeptabel ist. Bei den OpenSource-Technologien bleibt dann nur noch dm-crypt über. Dieses hat jedoch die „Schwäche“, dass der Verschlüsselungheader (welcher Cipher, Start, Ende, etc) selber unverschlüsselt auf der Platte liegt. Sicherheitstechnisch ist das kein Problem. Auch wenn der Angreifer den Cipher kennt, beißt er sich bei den richtigen Algorithmen und Schlüssellängen die Zähne aus. Nur kann ein dm-crypt Benutzer nicht glaubhaft abstreiten, dass er eben dm-crypt nicht benutzt.

Mir war die juristische Debatte erstmal egal, ich wollte ein verschlüsseltes dynamisches RAID-Device. Das hat mich ein ganzes Wochenende gekostet (500GB auf 750GB zu migrieren dauert immer ungefähr 4 Stunden). Es hat sich mir ein zentrales Problem in den weg gestellt. Es gibt für die Konsole kein Tool, dass eine Partition vergrößern kann, dessen Dateisystem es nicht erkennt. Man kann mittels fdisk die Partitionstabelle löschen und neu schreiben. So sadomasochistisch bin ich aber nicht veranlagt. Man riskiert immer vollen Datenverlust!

Man kann den Umweg über Logical Volume Manager (LVM) gehen. Dazu wird bei einem vergrößerten Device nicht die Partition vergrößert, sondern im neuen freien Bereich einfach eine weitere Partition erstellt. Diese wird dann dem Logischen Device hinzugefügt. Arbeitet man nur mit einem Fake- oder Software-RAID, mag das akzeptabel sein. Kommt es bei diesen zu einem Stromausfall darf man eh beten. Hardware-RAIDs nutzen jedoch BBUs um Datenverlust im Fehlerfall zu unterbinden. Was mit der LVM Zwischenschicht wieder ausgehebelt währe.

Möglichkeit drei ist einfach: man nutzt keine Partitionierung. Dazu muss man einfach wie folgt sein Device „beschreiben“

sudo parted /dev/sdX
mklabel msdos
quit

Nach dieser Aktion hat man eine MSDOS – Partitionierung, aber nicht erschrecken, die verschwindet gleich wieder ;).
Jetzt kann man die Festplatte direkt verschlüsseln, was z.B. bei einer GPT – Partitionstabelle nicht geht.

sudo cryptsetup luksFormat --cipher aes-xts-plain:sha256 -s 256 -q /dev/sdX #Verschlüsselung anlegen
sudo cryptsetup luksOpen /dev/sdX someCryptDev #Verschlüsseltes Device öffnen
mkfs.ext3 /dev/mapper/someCryptDev #verschlüsseltes Device formatieren
mount /dev/mapper/someCryptDev /mnt/someCryptDevUncrypted

Beim Wiedereinhängen einfach luksFormat und mkfs weglassen, sonst blöd 😉
Interessant wird jetzt die Vergrößerung. Dazu im unter lagerten RAID erstmal das Device vergrößern. Um die neue Festplattengröße dem System bekannt zu machen muss man entweder mittels des RAID-Treibers ein rescann auslösen, man entlädt einfach den ganzen Treiber und hängt ihn wieder ein oder startet einfach neu.

sudo lsmod #alle Treiber anzeigen lassen und den RAID-Treiber raus suchen.
sudo modprobe -r
 #RAID-Treiber entladen
sudo modprobe
 #RAID-Treiber laden

Letztes geht nicht ohne das aushängen der gemountet Partition. Besser gesagt, es geht schon, bloß muss man dann mit Datenverlust rechnen. Ein Rescan sollte zu keinem Datenverlust führen, das ist jedoch Treiber-abhängig, in jedem Fall das Manual oder den Maintainer konsultieren. Für 3Ware (jetzt LSI) Raids müssen die Devices z.B. ausgehängt sein.

Ist die neue Festplattengröße im System bekannt, muss man sie nutzbar machen. Dazu gibt es zwei Möglichkeiten:

  • Online – ohne Downtime des Dateisystems: Dies benötigt ein Dateisystem, was das Vergrößern/Verkleinern „on-the-Fly“ unterstützt. Das können z.b. EXT3 oder XFS.
    sudo fdisk -lu /dev/sdX #Sektoren raus schreiben
    sudo cryptsetup status  #Offset raus schreiben
    sudo cryptsetup resize -o  -b ;
    sudo resize2fs /dev/mapper/sdX #resize des FileSystems am Beispiel EXT3
  • Offline – mit Downtime des Dateisystems: Die kann mit allen Dateisystemen durchgeführt werden, die vergrößert/verkleinert werden können. Es ist auch ein Stück komfortabler.
    sudo umount /dev/mapper/; #aushängen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
    sudo cryptsetup luksClose  #schließen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
    sudo cryptsetup luksOpen /dev/sdX  #damit ist auch schon die Vergrößerung des verschlüsselten Devise erledigt...
    sudo resize2fs /dev/mapper/ #resize des FileSystems am Beispiel EXT3/EXT2

    Beim öffnen des Device nutzt selbiges scheinbar automatisch allen verfügbaren Platz, wenn man nichts anderes (mittels resize) einstellt.

So kann kann in jedem Fall ohne viel Stress seine RAID-Device stückchenweise nach seinen Bedürfnissen erweitern. Dennoch sollte man von allen wichtigen Daten immer ein Backup haben! Zudem sollte man dieses Vorgehen ein, zwei mal geübt haben, bevor man es mit wichtigen Daten durchführt;)

3Ware installation

Das erste was nach der Installation der Hardware auffällt ist, dass der Boot-Vorgang extrem viel länger dauert. Beim ersten Start hat es locker 30 Sek gebraucht, bis das BIOS des RAID-Controllers durch war und mein Server endlich ins Linux gebootet hat. In den folgenden Boots wird das nicht viel besser.

Die Installation des 9650 ist unter Ubuntu 9.04 denkbar einfach. Auch alle anderen Distributionen werden (wenn auch nicht offiziell) ohne Probleme unterstützt. Einzig die Kernelversion 2.6.14  oder die entsprechenden Treibermodule werden vorausgesetzt. 3Ware bietet drei Möglichkeiten den RAID-Controller zu administrieren. BIOS, CLI und die 3DM -genannte webbasierte RemoteManagement – Konsole. Die Installation erfolgt problemlos, einzig eine „echte“ JavaRuntime und das Programm „bc“ werden benötigt. Beide sind aber im offiziellen Repository enthalten und man gefährdet seinen Server nicht mit Fremdquellen. Ein „kleines“ „aptitude install“ vorneweg und die Installation kann beginnen.

Hat man eine grafische Oberfläche kann man das Setup einfach so starten, steht einem nur ein Kommandozeilen-Terminal zur Verfügung muss man noch den Parameter „-console“ anhängen. Anschließend führt ein Assistent durch die Installation und nach „wenigen“ Minuten steht einem der RAID-Controller in vollen Funktionsumfang zur Verfügung.

sudo aptitute install bc
tar xfvz 3DM2_CLI-Linux-x86_64-9.5.2.tgz
sudo ./setupLinux_x64.bin -consol

Jetzt wird man durch den Assistenten geführt. Das dauert wie gesagt ein paar Minuten. Anschließend ist alles nach Wunsch installiert und konfiguriert. Will man nachträglich etwas ändern so findet man das Config-File unter /etc/3dm2/

Man muss nur noch dafür sorgen, dass die Remote – Konsole auch automatisch gestartet wird. Leider ist der mitgelieferte Startscript, der auch brav unter /etc/init.d abgelegt wird, nicht ganz Standardkonform. Es fehlen die Angaben zu Required-Start und Required-Stop. Ergo schnell die Datei mit einem Editor der Wahl geöffnet und den Header angepasst.

#!/bin/sh
#
# 3dm2:         Starts the 3ware daemon
#
# Author:       Michael Benz

#
# Default-Start: 3 4 5
# Default-Stop: S 0 1 6
# Required-Start:  $network $remote_fs $syslog
# Required-Stop:   $network $remote_fs $syslog
# Provides: tdm2
# Short-Description: 3ware Daemon
# Description: Start the 3dm2 application which logs the current state
#              of the 3ware DiskSwitch controller card, and then polls
#              for state changes.
#
# config: /etc/3dm2/3dm2.conf

Zeile 9 und 10 sind von mir eingefügt. Anschließend folgenden Befehl ausführen.

sudo update-rc.d tdm2 defaults

Nun startet die Remote-Konsole automatisch beim Systemstart mit.
Für den ersten Test startet man entweder neu oder ruft den Script manuell auf.

/etc/init.d/tdm2 start

Wenn man die Konsole aufrufen will muss man beachten, dass nur HTTPS anfragen beantwortet werden. Nach dem Login (Standartpassword: 3ware) sollte man sofort die Passwörter ändern und ein BIOS-Update einspielen. letzteres bedarf leider eines Neustarts.

Anschließend kann man seine RAID-Arrays konfigurieren.

Ein neues Spielzeug: 3Ware 9650SE

Ich hab es also getan. Ich hab mir einen 3Ware 9650SE zugelegt. Ok wer nach schaut wird feststellen, dass es mehrere Controller mit der Bezeichnung gibt. Ich hab mir den mit 8 Ports gegönnt. Was hat mich nun bewogen so ein „Monster“ für den privat Gebrauch zu kaufen, zumal die Kosten horrend sind. Auf diese Frage gibt es nur eine Antwort: Der Umfang der von solchen Profie-RAIDs geboten wird. An oberster Stelle stehen natürlich Features die die Datensicherheit garantieren. Neben dem obligatorischen RAID 6 bietet der RAID-Controller folgendende Eigenschaften:

  • Festplatten die einen lokalen Fehler melden (Schreib/Lesefehler etc) werden nicht sofort als „unbrauchbar“ betrachtet. Sie steht auch weiterhin als Redundanz zur Verfügung. So kann ein Rebuild schneller erfolgen.
  • Der Schreib/Lese-Cache der Festplatten wird abgeschaltet und der Controller-eigene Cache genutzt. Dieser ist über eine Batterie (Battery Backup Unit – BBU) gesichert. Das garantiert, dass selbst bei einem totalen Systemausfall keine Daten verloren gehen.

Daneben bestechen Performance-Features:

  • Wird nicht der ganze verfügbare Speicherplatz einer RAID-Unit genutzt hinterlegt der RAID-Controler mehr Informationen auf den einzelnen Platten um im falle eines Rebuilds schneller wieder volle Redundanz herzustellen.
  • Zusätzlich werden alle Möglichkeiten genutzt den Plattenzugriff zu optimieren (Queuing,Read/Write-Cache)

Über die grundlegende Performance des Controllers braucht man nicht viel sagen. Wie man es erwartet, ist diese durch die Bank weg hoch. In den verfügbaren Benchmarks liegt er im oberen Drittel.

Neben diesen eckdaten gibt es noch eine Komfortfunktionen die sogar für den Privatgebrauch sehr angenehm sind.

  • Der RAID-Controller kann On-The-Fly RAID-Units vergrößern, migrieren, optimieren. Braucht man mehr Speicherplatz, steckt man einfach eine neue Platte rein oder ersetzt eine Festplatte nach der anderen mit einer Größeren.
  • Umfassenden Remote-Management: Alle funktionen des RAIDs können per Web-Interface aus der Ferne gesteuert werden. Fehler oder Warnung werden per Mail an eine Wartungsadresse. Falls wirklich mal eine Platte ausfällt, bekommt man es auf Wunsch sofort mit.

Alles in allem ein sehr angenehmes Gefühl mit so einem Gerät zu arbeiten.

Netzwerkdurchsatz unter Linux testen

Sollte man mal in die Verlegenheit kommen, die Netzwerkperformance (Durchsatz und co) testen zu müssen, so liefert das CommandLine Tool Netperf gute Dienste. Unter Ubuntu kann man es mittels folgendem Befehl ohne weiteres installieren.

sudo aptitude install netperf

auf einem rechner startet man den Performance-Server.

netserver -4 -p 

Das „-4“ sorgt dafür, dass nur auf IPV4 anfragen reagiert wird. Natürlich geht auch ein V6 für IP6 oder ganz weglassen für beides…

Auf der clientseite muss man nur noch den Test starten

netperf -4 -p  -H 

schon hat man schön übersichtlich die Leistung (s)eines Netzwerkes im Blick