Verschlüsseltes LVM vergrößern

Vorletzte Woche habe ich doch tatsächlich bei der Daten-Partition meines Fileservers die 90% Kapazitätsmarke erreicht. Nun stand eine Vergrößerung des Dateisystems an. Die Besonderheit dabei war, dass es sich um eine verschlüsselte Partition auf einer “Logical Volume” handelte. Dennoch ging die Vergrößerung mit nur wenigen Handgriffen ohne Probleme über die Bühne:

Partition unmounten und Verschlüsselung schließen:

# sudo umount /home/fileserver
# sudo cryptsetup luksClose fileserver

LVM vergrößern (hier um 512GB):

# sudo lvresize /dev/data/fs_crypt -L +512G

Verschlüsselung wieder aktiveren:

# sudo cryptsetup luksOpen /dev/data/fs_crypt fileserver

Dateisystemcheck durchführen (sonst beschwert sich resize2fs):

# sudo e2fsck -f /dev/mapper/fileserver

Schließlich Dateisystem auf dem verschlüsseltem Device vergrößern:

# sudo resize2fs /dev/mapper/fileserver

Mal sehen, wie lange das jetzt hält

LinuxTag 09: GPFS für Cluster

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.

Festplatten in Standby fahren

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.

MD3000i Performance-Test

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:

• Bei der Verwendung von NTFS mit 64k Clustergröße verringert sich die CPU-Belastung bei intensiven Schreibzugriffen zwischen 20 und 40%. Dabei verschlechtert sich die Performance bei Random-Zugriffen etwas (7%), der sequentielle Durchsatz bleibt konstant.
• Auch bei aktiviertem Flow-Control im ISCSI-Netzwerk nimmt die CPU-Belastung stark bei intensiven Schreibzugriffen ab (20-40%). Im Vergleich zu NTFS 64k bricht dabei jedoch die Performance bei Random- und sequentiellem Zugriff nicht ein, sondern steigt minimal an. Fazit: Beste Performance bei annehmbarer CPU-Belastung.
• Wird Jumbo-Frames im ISCSI-Netzwerk aktiviert, erhält man die geringste CPU-Belastung im gesamten Test: 13% geringer bei Random-Zugriff, 52% geringer bei seq. Lesen und 130% bei seq. Schreiben. Die Performance nimmt jedoch auch ab: 4,5% schlechtere Werte bei 32k seq. Lesen und 10% beim Random-Zugriff. Fazit: Geringste CPU-Belastung bei guter Performance.

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.

DELL EqualLogic-Workshop

Vorgestern war ich auf einem EqualLogic-Workshop in Frankfurt. Gezeigt wurde nach etwas allgemeiner Dell-Hardware-Werbung die Live-Einrichtung einer PS5xxx und die wichtigsten Funktionen in der Webadministrationsoberfläche. Folgende Punkte finde ich besonders erwähnenswert:

• Je 16 Festplatten (Fassungsvermögen eines EqualLogic-Systems) wird ein weiteres, vollwertiges Storage-System fällig. Mehrere Storage-Systeme (Array-Members) werden zu einer logischen Einheit (SAN-Group) zusammengefasst und erscheinen nach außen wie ein großes Storage-System mit einer virtuellen IP. Beste Voraussetzung für eine gute Skalierung vor allem im Bereich Performance. Die Kosten steigen jedoch auch linear.
• Die EqualLogic bietet “Virtualisierungsfunktionen” für VMWare ESX und XenServer. Damit lassen sich Storage-Funktionen wie Neuanlegen von Volumes, Anpassen der Größe und Erstellen von Snapshots direkt in der Virtualisierung-Managementsoftware von VMWare und ESX durchführen. Hierzu ein Demo mit XenServer und EqualLogic.

Weitere Notizen zum Workshop findet sich im Wiki.