Im Anschluss an den Vortrag über das Clusterdateisystem GPFS von IBM hat gestern Michael Adam vom Samba Team eine geclustertes CIFS-Lösung mit Samba vorgestellt. Für jeden, der Hochverfügbarkeit und Lastverteilung für sein NAS benötigt, ein spannendes Projekt. Meine Aufzeichnungen vom Vortrag habe ich gerade in das Wiki gestellt. Tieferführende Details kann man dem Samba-Paper entnehmen.
Wir sitzen gerade in der Kantine des LinuxTags und reden über den eben gehaltenen Vortrag über das LSC Projekt, mit dem eine Synchronisierung zwischen OpenLDAP und Active Directory realisiert werden kann. Neben den Standardattributen aus dem LDAP werden dabei auch spezielle Werte im Active Directory, wie das Sperren von Konten oder das Ablaufdatum eines Benutzerpassworts, synchronisiert. Vor allem für heterogene IT-Landschaften mit Linux und Windows sehr nützlich. Die Aufzeichnungen des Vortrags stehen wieder im Wiki bereit.
Ein weiterer interessanter Vortrag wurde heute über “Nagios in größeren IT-Umgebungen” gehalten. Neben einer kurzen Einführung in Nagios, wurde auf die erweiterten Nagios-Funktionen, empfehlenswerte Addons und weitere Integrationsmöglichkeiten mit anderen Webapplikationen eingegangen. Dabei wurde wieder mal deutlich wie groß mittlerweile die Community rund um Nagios geworden und wieviele nützliche Programme zur sinnvollen Erweiterung von Nagios entstanden sind. Auch wir setzen natürlich Nagios für sämtliche Serverüberwachungen erfolgreich bei uns ein. Eine Liste aller genannten Addons und Anwendungen mit einer groben Beschreibung findet sich im LinuxTag2009Nagios-Wikidokument.
Seit gestern Abend bin ich mit zwei Kollegen in Berlin, um den diesjährigen LinuxTag 2009 zu besuchen. Im Verlauf der Woche (bis einschließlich Samstag) versuche ich dabei hier im Blog über interessante Vorträge und Gespräche auf der Messe zu berichten.
Der erste Vortrag heute handelte über das Clusterdateisystem GPFS von IBM. Da wir selbst eher weniger gute Erfahrungen mit dem Clusterdateisystem von Oracle (OCFS2) gemacht haben, waren wir von dem alternativen Cluster-Produkt von IBM und den Erfahrungen, die die vortragende Firma damit in Kundenprojekten sammeln konnte, recht angetan. Alle wichtigen Notizen aus dem Vortrag sind unterhalb des LinuxTag 2009-Wiki-Dokuments zufinden.
Um Strom zu sparen, lassen sich Festplatten nach einer bestimmten Zeit der Inaktivität automatisch herunterfahren. Das kann vor allem bei Heim-Servern, die mit mehreren (vielleicht noch älteren, nicht stromsparenden) Festplatten ausgestattet sind und auf die nur bei Bedarf zugegriffen werden, einiges an Strom und Geld sparen. Bisherige Festplatten (IDE, aber auch SATA) haben hierfür den “IDE idle timer” unterstützt, den man mit hdparm wie folgt setzen kann:
hdparm -S Zeitangabe /dev/sdX
Nach Ablauf der Zeitangabe (siehe Manpage, je nach Höhe ein Vielfaches von Sekunden oder Minuten) wird die Festplatte, wenn in dieser Zeit kein Zugriff erfolgt ist, heruntergefahren und automatisch wieder hochgefahren, wenn wieder darauf zugegriffen wird.
Leider unterstützten diese Funktion einige, neuere Festplatten nicht mehr. Daher muss der Inaktivitäts-Timer als Software realisiert und die Festplatte nach Ablauf der Zeit manuell heruntergefahren werden. Eine solche Implementierung ist hd-idle, die sich unter Ubuntu/Debian recht einfach einrichten lässt. Der Ubuntu-Homeserver-Artikel wurde hierfür um ein neues Kapitel erweitert, welches die Einrichtung von hd-idle kurz erläutert.
Mit Hilfe von Undervolting, dem gezielten Herabsetzen der Core-Spannung der CPU, lässt sich der Stromverbrauch und die Erwärmung der CPU senken. Im Gegensatz zum Underclocking, bei dem der CPU-Takt heruntergesetzt wird, bleibt beim Undervolting der CPU-Takt und damit die volle CPU-Leistung erhalten, sprich weniger Stromverbrauch und Abwärme bei gleicher Leistung. Da bei diesem Verfahren ähnlich wie beim Overclocking Fertigungstoleranzen der CPU ausgenutzt werden, lassen sich CPUs unterschiedlich “gut” undervolten.
Die CPU-Spannung lässt sich zum einen im BIOS einiger Mainboardhersteller herabsetzen oder auch per Software während des Betriebs. Unter Linux existiert das Linux-PHC Projekt.
Für Ubuntu steht in einem externen Repository der aktuelle Ubuntu-Linux-Kernel 2.6.28.11 mit den entsprechenden Linux-PHC-Patches zur Verfügung. Die Installation und die Verwendung mit einem Intel E5200 Dual-Core CPU und dem Intel DG45FC Mainboard ist im Wiki beschrieben.
Mit Hilfe von Undervolting konnte bei 100%iger CPU-Auslastung der erwähnten Systemkonfiguration 11 Watt eingespart werden. Leider limitiert das Intel DG45FC Mainboard das Undervolting. Bei anderen Mainboards sind weitere Einsparungen und diese auch im Idle möglich.
Bei dieser Gelegenheit habe ich den Stromverbrauch meines Mini-ITX-Systems in verschiedenen Konfigurationen getestet. Hier die interessantesten Ergebnisse:
Der Idle-Wert von 35W schlägt sich im Vergleich zu aktuellen Dual-Core Atom-Systemen mit 25W (bis 35W je nach Ausstattung) recht gut. Dabei steht bei Bedarf wesentlich mehr CPU-Leistung als mit einem Atom-CPU zur Verfügung. Möchte man z.B. hohe IO-Raten mit Verschlüsselung erreichen kann es mit einem Atom-System eng werden (siehe dazu Performance-Einbrüche beim Zugriff auf verschlüsselte Daten auf NAS-Geräte mit Atom-CPUs).
Weitere Ergebnisse und Stromkostenberechnungen finden sich im Wiki.
Möchte man von mehreren Systemen auf eine zentrale Musik-Bibliothek zugreifen, bietet sich der Betrieb eines Media-Streaming-Servers an. Alle Musikdateien liegen dabei zentral auf dem Server und werden per Netzwerk an beliebige Clients gestreamt. Clients können dabei PCs mit Windows- oder Linux, Macs aber auch Hardware-Geräte sein. Firefly ist solch ein Open-Source Media-Server, der viele Streaming-Clients, u.a. auch ITunes unterstützt. Er ist unter Ubuntu schnell installiert und eingerichtet, macht jedoch unter der aktuellen Ubuntu 64Bit Version 9.04 Probleme. Wie man eine angepasste Version von Firefly installiert und einrichtet, ist im UbuntuHomeserver-Wikidokument beschrieben.
Heute berichte ich über die zentrale (und verschlüsselte) Datensicherung von Macs per Time Machine auf einem Ubuntu Linux-Server. Hierzu werden die Dienste Bonjour (Apples Implementierung von Zeroconf) und AFP (Apple Filing Protocoll) benötigt, damit die zu sichernden Macs den entfernten File-Server automatisch finden (Bonjour) und dort Daten ablegen können (AFP). Unter Linux steht mit dem Software-Paket netatalk eine Kernel-basierte Implementierung der AppleTalk Protokoll-Familie, darunter auch AFP, bereit. Leider ist aus Lizenzgründen unter Ubuntu nur ein netaltalk-Paket ohne verschlüsselter Authentifizierung verfügbar. Es muss daher mittels des Sourcecodes installiert werden (Anleitung im Wiki). Als Zeroconf-Implementierung (Bonjour-Ersatz) kommt unter Linux avahi zum Einsatz, dessen Einrichtung unter Ubuntu reibungslos verläuft. Im letzten Schritt steht die Konfiguration von Time Machine unter Mac OS X an. Da unter Linux keine stabile Implementierung für das Apple-Dateisystem HFS+ existiert, müssen alle Backups in ein Apple SparseBundle-Imagefile ablegt werden, welches wiederum per AFP freigegeben wird. Auch hierzu eine kurze Anleitung im Wiki, wie ein solches Imagefile erstellt wird.
Ich kann zwar noch nicht mit Langzeittests dienen, jedoch laufen die Time Machine Backups bisher sehr zuverlässig und reibungslos. Time Machine mounted automatisch die AFP-Freigabe auf dem Ubuntu-Server und das darin befindliche Image vor dem Backup und unmounted es nach Gebrauch wieder. Ist der Server nicht erreichbar, schlägt das Backup zwar fehl, funktioniert nach dem Einschalten des Servers dann aber wieder ohne Probleme und ohne manuellem Eingriff. Auch die Backups über WLAN funktionieren bisher gut.
Da ich meine Backups verschlüsselt auf meinem File-Server ablegen möchte, habe ich mich heute mit dm-crypt befasst. Als erstes stand die Entscheidung an, welchen Chiffrier-Modus für dm-crypt zum Einsatz kommen soll. Nach einer kurzen Recherche (Wikipedia #1, #2, Gentoo-Wiki) und Performance-Tests zwischen CBC, LRW, XTS und unterschiedlichen AES-Schlüssellängen (siehe Ergebnisse im Wiki) fiel die Wahl auf XTS mit einer Key-Size von 256.
Als nächstes stand die automatische Verschlüsselung der Swap- und Temp-Partitionen mit einem zufälligen Schlüssel und die manuelle Verschlüsselung anderer Datenpartitionen per Passwort an. Da der Server nicht ständig laufen soll, ist die Eingabe des Passworts für die verschlüsselten Backup-Partitionen beim Hochfahren des Systems jedoch sehr unpraktisch. Daher wurde für diese Partitionen zusätzlich ein Keyfile auf einem USB-Stick angelegt, der automatisch beim Hochfahren des Systems ausgelesen wird. Somit steckt man den USB-Stick mit dem Keyfile an den Servern, fährt das System hoch, während die verschlüsselten Partitionen automatisch gemounted werden und kann dann den USB-Stick wieder entfernen. Meines Erachtens eine bequeme und dennoch halbwegs sichere Lösung. Die einzelnen Schritte zur Einrichtung sind im Wiki dokumentiert.
Diese Woche kamen die letzten Teile für meinen neuen File-/Home-Server, den ich heute Abend mit Norman zusammengebaut habe. Da mich die Größe, das Gewicht und der hohe Stromverbrauch meines alten Servers zu Hause gestört haben, ist es ein stromsparendes Mini-ITX-System geworden (siehe Bild rechts: alter P4-Server mit Wasserkühlung unten, neues Mini-ITX-System oben). In einem Chenbro ES34069 Mini-ITX-Gehäuse mit 4 Hot-Swap SATA Festplatten-Einschüben ist ein Mini-ITX Mainboard DG45FC von Intel verbaut, welches mit 4 SATA- Anschlüssen und Gigabit-Netzwerkanschluss onboard ausgestattet ist. Das Gehäuse ist solide verarbeitet, sieht schick aus und ist wirklich sehr kompakt. Verbaut ist ein Dual-Core Pentium Prozessor mit 2.5Ghz, 2×2GB DDR2-800 RAM, 4 stromsparende 1TB Festplatten von WD, eine kleine 80GB 2.5″ Systemfestplatte und diverse Lüfter zur Kühlung. Weitere Details zur Hardware und Links zu Reviews und Anleitungen sind im Wiki zu finden.
Als Betriebssystem kommt Ubuntu Server 9.04 (Jaunty) zum Einsatz. Die vier großen Festplatten werden per Software in einem RAID5-Verbund betrieben. Im Wiki-Dokument UbuntuHomeserver werde ich sämtliche Konfigurationsschritte festhalten, die ich im Laufe der Einrichtung des Systems durchführen werde. Neben den schon erwähnten Hardware-Infos, ist dort aktuell die Partitionierung, die Liste der installierten Ubuntu-Pakete und kurze Beschreibungen zu Wake-on-Lan und dem Auslesen der Temperatursensoren (CPU und HDDs) dokumentiert.
Als sekundäres Storage-System für unsere Datenarchivierung und Backups haben wir uns kürzlich die ISCSI-basierte PowerVault MD3000i von DELL angeschafft. Bevor das System in den Livebetrieb übergeht wird es unterschiedlichen, internen Tests unterzogen. Die wichtigsten Erkenntnisse meines ersten Performancetests stelle ich in diesem Artikel und die detaillierten Ergebnisse im Techstories-Wiki vor.
Die MD3000i ist in diesem Test mit 8 x 1TB SATA-Festplatten im RAID-10 Verbund konfiguriert. Als weiteres Hardware-Equipment stehen zwei managebare Gigabit-Switches für ein dediziertes ISCSI-Netzwerk und zwei ähnliche Serversysteme mit Windows Server 2003 und CentOS 5.3 zur Verfügung. Die Server sind mit 2 x 1GBe (loadbalancing) und das Storage mit 2 x 2 x 1GBe (redundanter Controller und loadbalancing) angebunden. Genauere Informationen zur Hardware und zum Test-Aufbau findet sich im Wiki.
Unter Windows wurden die Performancetests mit IOMeter und ORION (Oracle I/O Calibration Tool) durchgeführt. Leider erzielten die Tests mit IOMeter unter Linux noch aus ungeklärten Gründen nur einen Bruchteil der Performancewerte unter Windows: z.B. 180MB/s sequentielles 32k-Lesen unter Windows vs. 40MB/s unter Linux. Erst mit einer Block-Größe von 1MB statt 32k konnte ein ähnlicher, sequentieller Durchsatz erreicht werden. Daher wurde unter Linux erst einmal nur mit bonnie++ und dd getestet werden.
Die MD3000i erzielte eine maximale sequentielle Leserate von 200MB/s (6414 IOPS x 32k), eine sequentielle Schreibrate von 125MB/s (4025 IOPS x 32k) und 685 IOPS bei 8k-Random-Zugriff mit 70% Leseanteil. Interessanter als die nominalen Ergebnisse dieser spezifischen Storage-Konfiguration waren jedoch die Auswirkungen auf die Performancewerte bei unterschiedlichen Test-Parameter: Zugriff auf Raw-Device oder NTFS/Ext3/XFS-Dateisystem, Zugriff mit mehreren offenen IOs und Threads, Aktivierung von Flow-Control und Jumbo-Frames im ISCSI-Netzwerks. Die wichtigsten Erkenntnisse im Überblick:
Weitere Details und Testergebnisse unter Linux sind im Wiki-Dokument festgehalten.
Wenn es die Zeit zulässt, folgen noch Updates bezüglich einer weiteren Senkung der CPU-Belastung beim Einsatz von TOE (TCP Offload Engine) und Performance-Vergleichtests beim Einsatz von RAID-5/6 statt RAID-10.
Ausblick auf neue Blog-Themen:
In den nächsten Monaten wird das aufgebaute Hardware-Equipment für intensive Tests der drei großen Virtualisierungslösungen Citrix XenServer, Virtual Iron und VMWare ESX zum Einsatz kommen. Erste, unvollständige Grundlagen dazu finden sich hier.
Für ein aktuelles IPhone-Projekt musste ich eine große Webseite mit nicht wohlgeformten HTML-Code parsen und bin unvorhergesehen auf viele Probleme gestoßen. Begonnen habe ich mit den Hausmitteln der IPhone SDK, der Cocoa Objective-C Klasse NSXMLParser, die wie alle anderen verfügbaren Parser für das IPhone auf der C-Bibliothek libxml2 basiert. Der NSXMLParser gehört zu den SAX-Parsern (“Simple API for XML“), d.h. er durchläuft das XML-Dokument sequentiell und löst bei XML-Konstrukten, wie z.B. öffnenden oder schließenden Tags, bestimmte Ereignisse aus, die vom Programm ausgewertet werden können. Es stellte sich jedoch schnell heraus, dass NSXMLParser nur für die Verarbeitung von kleineren XML-Dokumenten geeignet ist und nur mit XHTML-Code zurecht kommt. Bei nicht wohlgeformten HTML-Code wurden Teile falsch oder gar nicht erkannt und in einigen Fällen kam es sogar zu Speicherzugriffsfehlern in der Klasse.
Als nächstes bin ich auf die DOM-Parser-Implementierung XPathQuery gestoßen. Im Vergleich zu SAX wird bei DOM (“Document Object Model“) das komplette Dokument eingelesen und eine Baumstruktur im Speicher aufgebaut, über die man auf die verschiedenen Knoten und Elemente des XML-Dokuments zugreifen kann. XPathQuery unterstützt neben XML explizit auch das Parsen von HTML und kommt auch mit nicht wohlgeformten HTML-Code zurecht. Doch erste Tests auf der IPhone Hardware machte schnell deutlich, dass das Erstellen eines DOM-Trees mit Objective-C Objekten für ein über 800kb großes HTML-Dokument mit 10MB Speicherverbrauch und über 15 Sekunden Parse-Zeit die falsche Wahl auf dem IPhone ist.
Nach weiteren DOM-basierten Parsern (Übersicht im Techstories-Wiki), die ich eventuell in einem späteren Blog-Eintrag vorstellen werde, bin ich schließlich auf die Klasse AQXMLParser aufmerksam geworden. AQXMLParser baut auf NSXMLParser auf und löst die folgenden Probleme von NSXMLParser:
Leider ist aber auch diese Klasse nicht ganz fehlerfrei. Folgende Probleme konnte ich jedoch mit einem Patch beheben:
Mit der gepatchten AQXMLParser-Klasse steht eine performante und ressourcen- effektive Lösung für das Parsen von großen, nicht wohlgeformten HTML- und natürlich auch XML-Dokumenten auf dem IPhone zur Verfügung. Bei kleineren Dokumenten kommen jedoch auch DOM-basierte Parser in Frage, da sie meist einfacher zu implementieren sind.
Weitere Details und Beispiel Implementierungen finden sich im Wiki. Der Patch kann direkt hier heruntergeladen werden.
 |  | Artikel und Kommentare per RSS abonnieren oder Twitter-Account folgen. |