Kleiner NAS-Server Vergleich

Da sich mein altgedienter RAID-File-Server verabschiedet hat, der mich ca. 8 Jahre lang begleitet hat, musste ich mich nach einer neuen Lösung umsehen. Mittlerweile gibt es ja ausreichend viele gute kleine Lösungen für NAS-Systeme für den "Heimbedarf". Nach einer kurzen Umfrage unter Kollegen und ein bisschen Recherche habe ich mich für den D-Link DNS-323 entschieden und kurzerhand zusammen mit zwei 2 TB Festplatten bestellt. Da ich im Zusammenspiel mit meinen Mac's allerdings keine einfache Anbindung herstellen konnte (dazu später mehr) habe ich dann noch die etwas teurere zweite Empfehlung Synology 210j hinzugenommen und kann nun hier ein bisschen vergleichen.

Vorneweg noch zur Info: Soviel ich auch bei meinem Mac mini bastle und experimentiere. Das NAS soll einfach funktionieren. D.h. ich habe keine der beiden Stationen modifiziert. Lediglich ein Firmware-Update auf die letzte stabile offiziell über die Hersteller-Website angebotene Version habe ich vorgenommen.

Als Festplatten betreibe ich zwei unterschiedliche Festplatten im RAID 1 Verbund, damit die Wahrscheinlichkeit eines gleichzeitigen Ausfalls minimiert wird:
- 2 TByte, 3,5", 7200rpm, SATA II 32 MB Cache (Hitachi Deskstar 7K2000)
- 2 TByte, 3,5", 5400rpm, SATA II 32 MB Cache (Samsung F3 HD203WI EcoGreen)

In beiden Systemen habe ich erstmal nur eine Festplatte betrieben.

D-Link DNS-323
Positiv fällt direkt das vergleichsweise schwere Metallgehäuse auf. Macht einen gut verarbeiteten stabilen Eindruck. Der Einbau der Festplatte ist geradezu Kinderleicht und kann ohne Werkzeug bzw. Schrauben durchgeführt werden. Einfach die Kunststoff-Front vorne nach oben drücken und dann abziehen. Die Festplatte(n) können dann einfach in das gerät eingeschoben werden bis sie spürbar einrasten. Mit dem Hebel auf der Rückseite des Gerätes lassen sich die Platten dann wieder lösen und herausziehen. Praktisch!

Die Benutzeroberfläche ist schlicht und übersichtlich. Es gibt ein Tool für die schnelle Einrichtung unter Windows. Damit hatte ich schnell das gesamte Volume freigeschaltet für den Zugriff. Dieser Zugriff auf die gesamte Platte ohne Passwortschutz funktionierte auch direkt unter Mac OS. Anschliessend habe ich ein paar Verzeichnisse und einen Nutzeraccount angelegt und wollte mich wieder mit den Laufwerken verbinden. Unter Windows wieder kein Problem. Unter Mac OS 10.6 allerdings klappte der Zugriff nicht mehr. Ich sehe zwar weiterhin das Gerät und auch die verfügbaren Freigaben. Als ich aber die Zugangsdaten eingegeben hatte, meldete Snow Leopard, dass das Laufwerk nicht existiert: "Der Vorgang konnte nicht abgeschlossen werden, da das Originalobjekt für „SHARE“ nicht gefunden wurde."

Schliesslich fand ich heraus, dass das wohl an der veralteten Version von Samba auf dem D-Link NAS (Firmware 1.07) liegt. Snow Leopard unterstützt dessen Authentifizierung wohl nicht mehr. Mit einem Firmware-Update auf 1.08 soll sich das Problem beheben lassen. Dieses ist aber noch im Beta-Test-Stadium und somit ohne Garantie/Support bei Problemen. Zudem habe ich auf der Website von D-Link zwar die neue Firmware gefunden, aber nur für die Hardware-Versionen A1 und B1. Nicht aber für mein Gerät mit C1. Diese gibt es zwar im Web auch, aber nur über andere Quellen.

Über die vorhandene Funktionalität hinaus kann man den DNS-323 über PlugIns aufbohren. Diese muss man dazu auf oberster Ebene einspielen, Neustarten und dann werden entsprechende Aktionen ausgeführt. Das mag alles gut funktionieren, aber ist mir in dem Fall zu wackelig oder zu spannend. Schon um SSH freizuschalten muss dieser Weg beschritten werden. Auch Bittorent läßt sich auf diese Art "nachinstallieren".

Die Verwendung von USB-Platten am D-Link funktionierte leider auch nicht Out-Of-The-Box. Im Setup liessen sich nur Optionen für den Druckeranschluss finden. Vielleicht läßt sich das auch nachrüsten.

eMail - ich habe es leider mit keinem meiner Accounts hinbekommen, die eMail-Benachrichtigung zu aktivieren. Auch gänzlich unverschlüsselte SMTP-Mail-Accounts quittiert das NAS mit einem schlichten "Failed". Über die Admin-Oberfläche konnte ich kein Protokoll finden, das mehr Informationen preisgab.

Vor der Verwendung müssen Festplatten zunächst formatiert werden. Das ist bei beiden Geräten gleich. Die Formatierung einer einzelnen Platte dauert nur wenige Minuten.

Synology 210j
Das Gehäuse des Synology ist aus weißem Plastik. Das mach nicht so einen stabilen Eindruck und die Front wirkt ein bisschen antiquiert. Die Bodenplatte jedoch ist aus Metall. Der Einbau der Festplatten erfordert etwas mehr Geschick, als beim D-Link. Der Austausch der Platten muss mit einem Kreuzschraubendreher durchgeführt werden. Zunächst zwei Schrauben, um das Gehäuse zu öffnen (wobei es ab Werk unverschraubt geliefert wird, was ich prima fand, da kein Suchen nach den relevanten Schrauben erforderlich war. Das Gehäuse muss man dabei seitlich aufschieben, wobei die Plastikverarbeitung keine raue Gewalt vertragen wird. Die Platten werden dann in Metallschienen geschoben und von je 4 Schrauben gehalten.

Nach dem einschalten war ich schon ein wenig überrascht, das keine Firmware auf dem Gerät vorinstalliert zu sein scheint. Auf der CD war Version 959 dabei. Von der Hersteller-Website habe ich 1141 herunterladen können und diese auch direkt installiert. Interessanter Ansatz. So werden viele Kunden wahrscheinlich direkt zur neueren Version greifen.

Nach den kurz zuvor gemachten Erfahrungen und Eindrücken mit dem D-Link-NAS war das WebInterface des Synology ein WOW-Effekt! Es lässt sich alles über dieses Konfigurieren, auch wenn man ein bisschen Suchen muss aufgrund der Menge der Features.

eMail Benachrichtigung - Funktionierte AdHoc mit dem ersten getesteten Account. Hier lassen sich auch Verschlüsselung und Port etc. eingeben. Die Nachrichten, die man erhalten will, kann man in den jeweiligen Konfigurationsbereichen einstellen. Auch SMS kann man konfigurieren.

Über die Download Station kann man dem NAS direkt Links oder BitTorrents übergeben und erhält eine eMail, wenn der Download erledigt ist. Das klappt sehr zuverlässig.

Weniger zuverlässig ist leider die Sicherung. Ich habe einige der Verzeichnisse ausgewählt für eine direkte Sicherung auf eine zusätzliche angeschlossene USB-Platte eingetragen. Dieses bricht jedoch immer wieder ab und kann so keine Vollständige Sicherung durchführen. Aus dem Protokoll kann man zwar erkennen, welche Datei im nicht gefällt, aber einen Grund dafür konnte ich bislang nicht ausfindig machen.

Die Konfiguration von Freigaben für verschiedene Nutzer lässt sich Unix-Typisch für Benutzer und Gruppen einrichten. Analog ging das auch beim D-Link. Mit den Freigaben allerdings kommt Snow Leopard hervorragend klar. Besonderer Vorteil ist hier allerdings auch, dass das Synology-NAS auch den Mac-Dateidienst beherrscht und sogar als TimeMachine fungieren können soll, was ich aber nicht ausprobiert habe. Somit spiegeln sich Konfigurationsänderungen unmittelbar nach deren Speicherung auch auf dem Mac wieder.

Es gibt auch eine iPhone-Darstellung der Site, die aber nicht für die Management-Seiten genutzt werden kann, sondern z.B. für die FileStation. Wenn diese Dienste nicht aktiviert sind, ist die Seite bis auf den Link zur Desktop-Variante einfach leer.

Fazit
Nachdem ich mich für das Synology NAS entschieden habe, wurde auch die zweite Festplatte eingebaut. Zur Einrichtung des Volumes musste ich aber leider alles nochmal Formatieren als RAID. Wahrscheinlich kann man sich das sparen, wenn man auch mit einer Platte direkt als RAID die Konfiguration gemacht hat. Die Einrichtung des RAID 1 dauert allerdings sehr lange. Ca. 6 Stunden hat das Initialisieren benötigt. Anschliessend merkt man in der Handhabung nichts mehr vom RAID. Sollte eine der Platten mal ein Problem haben, werde ich hoffentlich wie konfiguriert auch hier zuverlässig die eMail bekommen, dass es Zeit wird für einen HW-Tausch.

Verteiltes Server-Monitoring: neighborhoodwat.ch

Erst vor wenigen Stunden im Netz aufgetaucht ist neighborhoodwat.ch (NHW). Einige Düsseldorfer haben die Idee eines verteilten Monitoring-Netzwerkes umgesetzt und bieten diesen interessanten Service an. Jeder, der einen Server überwachen lassen möchte, installiert auf einem seiner Server einen Agenten, der vom zentralen Server eine Liste mit URLs bekommt, die er fortan prüft. Aktuell bietet das System noch nicht viele Features. Es gibt z.B keine Historie. Aber mit einem derart verteilten Netz könnte man natürlich künftig interessante Aussagen über Performance und Verfügbarkeit aller Netze ermitteln, über die die Agenten verstreut sind.

Zur Prüfung meines Blogs, wollte ich den Service direkt mal ausprobieren. Zur Anmeldung kann man eine OpenID verwenden, die über viele Anbieter zur Verfügung steht. Da mein Blog über Google und Blogger läuft, lagen diese als IDs am nächsten. Aber leider bekam ich immer nur eine Fehlermeldung: Not found. Über den Twitter-Account der Betreiber (@thehoodwatch, @mutle) erfuhr ich dann, dass es noch Probleme gäbe und nur myOpenID aktuell sicher funktionieren würde.

Mit der OpenID von myOpenID funktionierte die Anmeldung dann ohne Probleme. Nach der Anmeldung landet man auf einer Übersichtsseite, die die überwachte Site und deren Staus anzeigt. Ohne Agenten tut sich hier aber noch nicht viel.

Für die Installation sind laut "Installationsbeschreibung" nur Ruby, Ruby Gems, Cron und natürlich ein NEIGHBORHOODWAT.CH-Account erforderlich. Darüberhinaus müssen noch gcc und g++ installiert sein, wenn Ihr wie ich Ruby selbst bauen wollt. Da auf dem Server noch kein Ruby installiert war, habe ich die Installation von Ruby (basierend auf Kates Gasis Anleitung) aber auf OpenSuSE 11 folgendermaßen durchgeführt:

wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p368.tar.gz
tar -xzf ruby-1.8.6-p368.tar.gz
cd ruby-1.8.6-p368/
./configure --prefix=/usr/local --enable-pthread \
--with-zlib-dir=/usr/local \
--with-readline-dir=/usr/local
make
sudo make install

Anschliessend musste noch Rubygems installiert werden. Es wird keine Version vorgegeben, also die aktuelle Version 1.3.5 verwenden:

wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
tar -xzf rubygems-1.3.5.tgz
cd rubygems-1.3.5/
sudo ruby setup.rb

Jetzt sollte die Installation des Agenten folgen. Der liess sich leider auf der referenzierten Github-Seite (Liste der Gems) nicht direkt finden. Wie ich aus den Tweets von @mutle erfuhr, fehlte noch die Freigabe bei Github. Einige Stunden später lag der Agent in Version 0.0.7 via GitHub vor. Die Installation war noch ein wenig zickig, da die eventmachine in einer falschen Version gezogen wird, wenn man direkt den Agenten holen will. Deshalb zunächst die Gems eventmachine und json installieren:


sudo gem install eventmachine
sudo gem install json
sudo gem install mutle-neighborhoodwatch-agent \
--source=http://gems.github.com/

Über die WebSite von NHW musste nun noch der neuen Agent angelegt und über "Instructions" die ID des Agenten abgeholt werden. Nachdem die Gems installiert waren, konnte nun der Agent aufgerufen und die ID übergeben werden. Das funktionierte auf Anhieb. VORSICHT: Nach dem ersten erfolgreichen Aufruf kann man die ID nicht mehr über die WebSite von Neighborhoodwat.ch abrufen.

neighborhoodwatch-agent <agent id>

Nun noch der Eintrag in die crontab:

*/5 * * * * neighborhoodwatch-agent <agent id>

Der Prozess muss nicht mit Root-Rechten gestartet werden, so dass die ganze Installation mit einem unpreviligierten User möglich ist.

Bislang funktioniert die Benachrichtigung über Störungen nur per eMail. Ich hoffe, das die Ergänzung um Twitter als Meldekanal in Kürze nachgereicht wird.

JAX 09 - 10 typische Fehler in Enterprise-Java-Anwendungen

Ein weiterer JAX-Talk diesmal von Eberhardt Wolff am 4. Tag. Seinen Vortrag findet Ihr auf seinem Blog. Der Vortrag selbst war inhaltlich gut (wenn auch nicht überraschend), aber vom Stil und den Folien gruselig. Ich hatte das Gefühl er ginge davon aus, das man auf den ersten Blick in einem Code-Schnipsel erkennt, welche Sünde er nun gerade ansprechen will.

Die 10 "üblichen" Fehler aus seiner Sicht sind:

#1 - Transaktionen so zu bauen, dass sie durch Exceptions verlassen werden können, ohne dass sie geschlossen werden. Seine Lösung ist die Verwendung von deklarativen annotierten Transaktionen oder die Verwendung von Transaktions-Templates. Dabei darf dann nur eine Transaktion in der Methode vorhanden sein.

#2 - Exception Design mit checked Exceptions. D.h. jede Exception muss behandelt werden, auch wenn das sinnvoll nicht möglich ist. Man sollte hier möglichst keine checked Exceptions verwenden und es vermeinden Exceptions zu wrappen und einfach weiterzuwerfen. Setze einen Aspect für das Logging ein, um die Informationen zu erhalten und im Code nur die Exceptions behandeln, mit denen man auch sinnvoll umgehen kann. Alle anderen Exceptions sollten in einem generischen Handler alle Runtime-Exceptions fangen. Eine weitere Variante ist über AOP alle Exceptions zu fangen und zu loggen.

#3 - falsches Exeption-Handling, z.B. kein Handling (leerer Catch-Block) oder Ausgabe des Stacktraces (ohne Logging). #2 führt dazu, das dieses Problem hier auftritt und damit Fehler sehr schwer zu finden sind, weil das Verhalten der Anwendung wirr wird. Die Lösung ist die gleiche wie zuvor: immer loggen, überlegen, ob die Exception sinnvoll bearbeitet oder ignoriert werden kann und auf jeden Fall generisch an den Außengrenzen des Systems abfangen.

#4 - Zirkuläre Paketabhängigkeiten, wodurch der Code wie klebrige Spaghetti verwoben ist und zusammenhängt. Eine sinnvolle Zerlegung des Codes ist somit nicht mehr möglich. Spaghetti muss im Vorfeld (!) durch saubere Architekturen vermieden werden. Zusätzlich sollte man regelmäßiges Refactoring einplanen. Allerdings kann man durch Refactoring nur schwer eine schlechte Architektur aufräumen.

#5 - Adaptor Layer, die in jeder Methode integriert werden müssen, z.B. Traceingausgaben bei Ein- und Austritt aus Methoden. Genauso Security-Checks und Null-Checks. Die Lösung hier ist natürlich AOP.

#6 - Keine DAO's zu verwenden - erschwert das Testen, da immer eine Datenbank verfügbar sein muss. Führt zu ungewollten SQL-Exceptions, u.s.w.

#7 - Keine oder schlechte Tests zu machen, wodurch die Code Qualität gering ist und man schwerlich feststellen kann, ob man durch eine Änderung andere Funktionalitäten verändert hat. Zudem immer positiv UND negativ Unit-Tests vorsehen. Mocks vereinfachen das Durchführen der Tests.

#8 - SQL-Statements schreiben und diese nicht manuell zu konkatenieren. Die Gefahr von SQL-Injektion muss an jeder Stelle geprüft werden. Es ist besser hier entsprechende Mapper oder Wrapper zu verwenden und Zeichen über Positivlisten (WhiteList für Character) zu filtern. Und Prepared Statements verwenden.

#9 - Man sollte sich Gedanken über das Mengengerüst und die Art der Anfragen machen und dieses auch frühzeitig testen. Je eher je besser. Wenn die Performanz Probleme später auftreten hat man keine Zeit für eine vernünftige Lösungssuche mehr. D.h. auch schon einzelne Module frühzeitig auf Performanz testen.

#10 - Nicht Threadsafe zu entwickeln, weil Fehler, die mit multiplen Threads und memory leaks verbunden sind während der Unit-Test nie auftreten werden und nur durch Code-Reviews und Analyse von Threaddumps zu finden sind. Man sollte lokale Variablen bevorzugt nutzen, Synchronisieren und WeakHashMaps einsetzen um Memoryleaks zu vermeiden.

Details und Codebeispiele findet Ihr in seinen Folien.

JAX 09 - Tag 3 - Retrospektive

Last- und Stresstest mit the Grinder 3

Andreas Spall stellte in seinem Short-Talk Grinder 3 als Lasttesttool und Alternative zu JMeter vor. Von einer Konsole aus steuert man über Agenten auf verschiedenen Rechnern diverse Worker die die Last erzeugen. Mit Grinder soll sich das Aufzeichnen und Abspielen gut durchführen lassen.


Keynote: JRuby Past, Present and Future

die Keynote zu JRuby von Charles Nutter hat Michael Johann (Chefredakteur des Magazins RailsWay) perfekt zusammengefasst: Artikel. Es war eine beeindruckende Präsentation, da sämtliche Beispiele "in Echtzeit" nachvollziehbar von Ihm gecoded wurden.


Komplex, oder doch nur kompliziert?

Der letzte Talk am 3. Tag drehte sich wieder um Projektmanagement. Guido Zockoll zog eine sehr interessanten Vergleich zum Schachspiel mit Start-, Mittel- und Endspiel. Zu Beginn des Schachspiels ist die Stellung bekannt und man hat ein einfaches Problem vorliegen, das man nach Katalog der Spieleröffnungen spielen kann. Beim Endspiel (z.B: König mit Pferdchen und Läufer gegen den verbliebenen gegnerischen König) ist es ein schwieriges bzw. kompliziertes Spiel, das aber auch mit Disziplin und Übung lösbar ist. Ganz anders sieht es im Mittelspiel aus, wenn die Figuren über das Spielbrett verteilt sind. Hierbei handelt es sich um ein komplexes Spiel, in dem sich der Schachspieler mit unüberschaubar vielen Möglichkeiten konfrontiert sieht, die er mit Bauchgefühl, Erfahrung und Heuristiken (Pferd am Rand bringt Kummer und Schand) angeht.

Übertragen auf die IT bzw. das Projektmanagement zeigt sich, das Projekte wesentlich komplexer sind als Schach, da die "Felder, Figuren und Zugmöglichkeiten" wesentlich umfangreicher bzw. Variantenreicher sind. Aber die Lösungsansätze können gut übernommen werden. Ein Schachspieler passt seine Vorgehensweise der Situation entsprechend an. Ein Projektleiter sollte das auch tun.