Hardware für mysql-Server m...

Ich lasse dabei mal die Systeme weg, die es auch in ähnlicher Art und Weise bei allen Hersteller gibt. Die X4600 lasse ich auch mal etwas aussen vor. Wir sind da mit 16 schwergewichtigen Cores (demnächst 32 Cores) schon bei Groessenordnungen, die ich nicht mehr mit mysql machen würde.

ZFS
Kris schreibt, das lineare Writes gut sind und hat damit recht. Das macht ZFS von Haus aus. Ein nettes Feature von ZFS ist das Gruppieren von Writes. Writes gelangen aus dem ZIL immer in linearer Art und Weise auf den rotierenden Rost, auf dem sie dann persistieren sollen, sofern natürlich der Platz am Stück da ist. Zudem hat man seit Opensolaris Build 68 zusätzlich die Möglichkeit, das ZFS Intent Log auf eigene Spindeln auszulagern. Auch das bringt noch einmal ein Plus an Performance, inbesondere wenn diese Auslagerung auf Solid State Disks erfolgt.

Zum Thema RAID: RAID-Z ist eine wesentlich bessere Idee als RAID-5, da der full stripe read/full stripe read-Zyklus wegfällt. Das hängt unter anderem damit Zusammen das ZFS ein copy-on-write-filesystem ist in Tateinheit mit der Tatsache, das ZFS mehr über die interne Struktur des Volumes weiss, als herkömmliche Filesysteme. Änderungen werden nie an die selbe stelle geschrieben, deswegen muss man auch nicht die alten Stripes ändern. Dadurch und durch das Write Grouping wird die Anzahl der IOPS wesentlich reduziert, die Entscheidung für oder gegen RAID-Z wird dadurch etwas komplexer. Habe ich viele Spindeln zur verfügung, kann man ich überlegen, eine Reihe von RAID-Z Volumes zu stripen, um mehr IOPS zur Verfügung zu haben. Der Nachteil kommt so potentiell weniger zum Tragen. Trotzdem: Für Datenbanken ist RAID-10 immer noch die performantere Wahl. Ich würde sagen, das für RAIDZ+seperated LOG ungefähr das gilt, was Kris zu RAID-5 mit NVRAM-Haltigen Controller gesagt hat, nur halt ohne RAID-Controller.

Einige andere Features von ZFS sind zudem administrativ ziemlich nützlich: Compression um Test und Developmentdatenbanken möglichst platzsparend vorzuhalten. Checksummen zur Garantierung der Datenvalidität und Snapshots um auf die Schnelle Testdatenbanken zu erzeugen, die keinen zusätzlichen Platz verbrauchen. Schlussendlich gibt es auch noch Hotspot Relocation, die Schreibrequests immer versucht auf die am niedrigsten auszugelastete Platte durchzuführen. Damit wird die Last statistisch gesehen gleichmaessig auf die Platten verteilt.

Obwohl ZFS ein sehr junges Filesystem ist gemessen am Alter von UFS bespielsweise, so konnte bereits in Benchmarks die selbe Leistung wie bei UFS mit directio erreicht werden. Bei diesen Benchmarks war das "seperate logging" noch nicht verfügbar, so das hier nochmals ein positiver Effekt zu erwarten ist.

Hilfreiche Tuningtips für Datenbanken auf ZFS findet man im Solaris Internals Wiki. Eine tiefer gehende Analyse zum Thema ZFS und mysql findet sich nebst einigen Tuningtips in der Website von Dimitri

UltraSPARC T1/Niagara II
Systeme, wie die T1000/T2000 stellen sehr leistungsfähige Datenbankserver dar. Ein recht guter Artikel zu diesem Thema ist bei Digitar zu finden, die über Ihre Erfahrungen. Die Herren schliessen damit, das für Ihren Workload eine T2000 die 13,7 fache Geschwindigkeit einer 2 Prozessor HP Opteron Maschine aufweist. Auch wenn der Test etwa ein Jahr alt ist, hege ich zweifel, das Opterons im letzten Jahr 13 mal schneller geworden sind

Das mysql gewisse Skalierungsprobleme über viele CPU hat, kann ich uebrigens ein Stück weit bestätigen. Auf der T2000 wurde festgestellt, das mysql bei Läufen über 32 threads etwas ins Rudern kommt.Nicht viel, aber feststellbar. Wenn man in 32 Threads gleichzeitig laeuft, treten die lock contention Probleme häufiger auf. Es hat sich herausgestellt, das die Maschine in gewissen Sinne zu schnell für bestimmte Applikationen sein kann. Die Probleme sind allerdings weitestgehend beseitigt.

Sollte man trotzdem auf diese Probleme laufen, kann man den Trick mit der Aufteilung in mehrere Datenbanken auch auf einer Maschine machen. Entweder installiert die beiden Datenbanken in eine Zone (funktioniert auf allen UltraSPARC, SPARC64 und x86-Prozessoren) oder in einer Logical Domain (funktioniert nur mit sun4v). Diese kann man dann auf die Prozessoren binden. Die Replikation findet dann innerhalb des Systems statt. Anders als VMware oder XEN laufen beide Virtualisierungsmethoden auf Solaris mit nur sehr wenig Overhead, so das das ein valider Weg ist.

Wichtig ist: Die T2000 wird für einen einzelnen Query wahrscheinlich langsamer sein. Interessant wird die Maschine dann, wenn ich viele gleichzeitige Querys ausführe. OLTP-artige Lasten für Webserver oder ähnliches rennen normalerweise wie der Teufel auf der Kiste. Datawarehousing ist dann eine gute Idee, wenn die Loader- und Analyse-Prozesse multithreaded sind. Ansonsten ist eine Opteronmaschine für kleine und SPARC für grosse DWH mit Sicherheit eine bessere Wahl.

Die Listenpreise für die Systeme finden sich hier. Aber wer zahlt schon Listenpreise. Ausserdem gilt es zu bedenken, das eine T2000 full-blown etwa 350 Watt schluckt. Das braucht die Marktbegleitung teilweise alleine, um die Prozessoren warm zu bekommen

Allgemeine Systemarchitektur
Michael Fucknerhat ja in seinem Blog eiinen Vorschlag gemacht, wie er sich eine mysql-Maschine vorstellt.Ob ich wirklich 26k für ein solches System ausgeben moechte ... ich weis nicht ... am Ende ist es auch nur eine heftig gepimpte Opteronmaschine. SPARC können im RAS-Sektor noch einige Dinge mehr ... Opterons sind doch ziemliches best-effort-computing

Nein ... mal ernsthaft: Ich würde nicht die internen Plattenbays nutzen, weil dadurch ein Clusterfailover nicht möglich ist. Wenn ich die Platten extern habe, kann ich über ein SAN einen Clusterfailover durchführen, der auf jeden Fall bis zur letzten abgeschlossenen Transaktion aktuell ist. Interne Platten sind zum Booten und für Systemlogs. Alles andere gehoert auf Speicher, der im Cluster wandern kann.

Ein sehr gutes Clusterfamework ist übrigens Sun Cluster, das es jetzt auch als Cluster Express in einer OpenSource-Version gibt. Sun Cluster Express ist sozusagen das Gegenstück zu Solaris Express. Grosse Teile sind schon offen, Rest kommt bald.

Braucht man wirklich keinen Clusterfailover, ist eine Sun Fire X4500 auch eine gute Alternative. 48 Spindeln um damit rumzuspielen, zwei Dualcore-Opterons und 16 GB Hauptspeicher. Gibt einen ziemlich guten Datenbankserver ab, insbesondere, wenn der Workload schreiblastig ist.

You ain't seen nothin' yet.
Richtig gespannt bin ich auf die NiagaraII Systeme. Ich habe zwar schon Benchmarks gesehen, deren Veröffentlichung mir unter den Nägeln brennt, aber ich darf ja nicht. Da kann man sich noch einiges on top erwarten.