Suns Enterprisedateisystem ZFS gibt es wg. Lizenzprobleme nicht für den Linuxkernel (nur über FUSE), aber für OpenSolaris. Nun hat sich eine Entwicklergruppe daran gemacht, um diesen Opensolaris-Kernel eine Art Debian (zumindest mit den Tools aus Debian) herumzustricken. Herausgekommen ist Nexenta. Verheiratet man dies nun mit genügend Hardware (Beispielsweise Backplaze), hat man eine günstige Lösung, die sich hinter einem NetApp-Filer Featuretechnisch nicht groß zu verstecken braucht.

Video über ein USB-Stick-RAID mit ZFS

siehe schwabenblog

HP unterhält ein riesiges Testlabor für die Entwicklung der EVA. Hier ein paar Fakten des Labs:

• 1200 Server
• 500 EVAs
• >20TB Speicherplatz

Ein ausführlicher Bericht von Nigel

Unser Terminalservercluster hatte teilweise extreme Probleme mit der Geschwindigkeit. Die virtuellen Maschinen waren ausgestattet mit 4GB RAM und 4vCPUs, eine Maschine hatte nur 2vCPUs.
Die Anwender beschwerten sich, dass das System langsam reagiert und arbeitet. Und das, obwohl jede Maschine nur ein viertel der Last im Vergleich zur Singleserverlösung vorher zu tragen hatte. Das generelle SMP-Problem mit der HAL.DLL ist natürlich auf allen Servern gefixt. Die Auslastung des VM-Clusters zeigte, dass die Maschine mit 2vCPUs bei gleicher Tätigkeit nur die Hälfte an CPU-Leistung frißt als die 4vCPU-Maschinen im direkten Vergleich. Es lag also nahe, alle Maschinen mit nur 2vCPUs zu fahren. Und es half. Nun ist es “sehr schnell” wie die Anwender sagen.

Offensichtlich hat Windows 2000 große Probleme mit mehreren Prozessoren. Die Verwaltung von SMP-Umgebungen ist also nicht optimal gelöst und skaliert in keinster Weise.

Weniger ist halt manchmal doch mehr.

Wie zwingt man eine Dual-Quadcore-Opteron 2,3GHz mit 32GB RAM in die Knie? Ganz einfach: man virtualisiert zwei Windows 2000 Terminalserver SP4, Updatererollup 1 mit 4 vCPUs und läßt darauf je 20 User leicht arbeiten. Und die Maschine ist am Ende!

Wie das? Microsoft hat mit Updaterollup 1 die HAL.DLL (genauer die halmacpi.dll) gepatcht. Die neue Version 5.0.2195.7006 hat aber leider einen Bug: Microsoft hat vergessen, den HALT-Modus für die Prozessoren zu aktivieren. Ergebnis: Der Prozessor braucht im Leerlauf schon 20% CPU-Leistung auf der Hardware, zeigt im Taskmanager aber nur 3-5% an. Arbeiten nun die User, geht das System sehr schnell in die Knie und blockiert durch die fehlende Auszeit auch noch die anderen VMs auf der Hardware.

Microsoft unterstützt keinen Wechsel der HAL. Neuinstallation ist die offiziell einzige Möglichkeit. Man kann inoffiziell auf die Vorgängerversion 5.00.2195.6691 wechseln, die den Fehler noch nicht enthält. Oder aber man zwingt die HAL dazu, die Halt-Modi zu nutzen und setzt ihr die Optionen per Hand. Es gibt einen

• Bootparameter “/usepmtimer” für die boot.ini
• Registrykey unter “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HAL”, Name “14140000FFFFFFFF”, Wert “00000010″ hex DWord

Beide sind relativ einfach anzuwenden, haben aber ihre Probleme. Der Bootparameter scheint nicht immer zu funktionieren, der Registrykey hat Probleme nach dem Aufwachen aus Hibernate, er wirkt nicht mehr. Ein Server geht aber nicht in Standby, Sleep oder Hibernate, sodass der RegKey die einfachste Methode ist.

Das Ergebnis ist wirklich überraschend: Im Leerlauf verbrät die VM auf der Hardware nur noch knapp 30MHz, während vorher noch gut 500MHz gebraucht wurden.

Das Problem besteht auch nur bei den SMP-Varianten der HAL, die Singleprozessor-Ausgaben haben dieses Problem nicht.

siehe

• Energieverschwendung
• MSFN Forge
• MS Übersicht HALs

Ein kleiner Bausatz zum zusammenbasteln ein Petabyte-Storage gibts bei BackPlaze.

siehe backblaze.com