Aus der Serverküche: CacheCade Performance

Dass MegaRAID Controller mit CacheCade und den richtigen SSDs mehr Leistung bringen als ein schlichtes RAID für sich, steht außer Frage. Aber wieviel eigentlich?

Diese Frage stellten wir uns (neben unseren Kunden) in letzter Zeit häufiger. Also taten wir, was jeder gute Techniker macht: Er misst. Jedoch ist es leider so, dass wer viel misst häufig Mist misst. Dazu eine kurze Erklärung:

Wir messen Disk-Performance grundsätzlich mit IOMeter, da die kleine Benchmarksoftware in der HDD- und Controllerbranche als Gold-Standard angesehen wird, also richteten wir uns auch für diesen Fall eine Testumgebung nach standardisierten Parametern ein, definierten Testserien in Excel und machten uns ans Werk.

Hierbei haben wir uns intern auf eine kleine Small Business-Konfiguration geeinigt, da hier häufig die Mittel für große SAS-RAIDs fehlen, aber doch viel Platz benötigt wird. Ideal für einen Vergleich 4xSAS (RAID10 oder RAID5) zu 2xSATA (RAID1) +2xSSD (RAID1).

Relativ schnell stellte sich im Test heraus, dass sich das CacheCade unterstützte SATA-RAID1 verhält, wie es ein nicht-CacheCade RAID tut: langsam.

Der Grund hierfür liegt in der Funktionsweise von CacheCade: Ähnlich wie Coca-Cola hat auch LSI ein Top-Secret Rezept, nämlich um Hotspots im RAID zu erkennen und diese HotSpots gezielt in den SSDs abzulegen, um somit Zugriffe zu beschleunigen. Naturgemäß ist es so, dass die SSDs dabei erheblich kleiner sind als die Gesamtgröße des RAIDs, also eben nur ein kleiner Teil der Daten (Hotspots) auf den SSDs liegen.

Wenn wir nun mit IOMeter gegen das RAID testen verwenden wir dabei die gesamte Disk Size des RAIDs (z.B. 1TB). Während des Tests mit IOMeter ergeben sich jedoch für den Controller keine Hotspots, da der Test vollkommen synthetisch ist und keine wiederkehrenden Zugriffsmuster aufweist (Stand iometer-1.1.0-rc1, full random mode). Demzufolge profitieren wir von den Vorteilen der SSDs nicht und genießen die volle Leistung der 2 SATA HDDs. In unserem Fall 119 IOPS. Der nächste logische Schritt war für uns nun die Max Disk Size mal etwas einzuschränken um zu sehen was passiert:

Bei ca. 1GB (eigentlich 1000MB oder 0.98GB ) sehen wir 22955 IOPS. Mit diesem stark eingeschränkten Testfeld kann der Controller also durchgängig alle Anfragen aus den SSDs beantworten. Schön, aber die meisten Datenbanken sind eben nicht nur 1GB groß. Was passiert also wenn wir einen Bereich größer als die SSDs (120GB) zum Test verwenden, z.B. 300GB?

Hier sehen wir eine deutliche Steigerung von 119 IOPS hoch auf 218. Man könnte also daraus Schlussfolgern: Sind die Hotspot-Daten größer als die für den Cache verwendeten SSDs, so nimmt nach dem Erreichen der SSD-Größe die Beschleunigung linear zum Ansteigen der Hotspot-Datenmenge ab. (Anmerkung: linear ist hier eher eine Vermutung basierend auf einigen nicht schriftlich dokumentierten Kurztests außerhalb der vollständigen Testläufe).

Nun hätten wir es dabei belassen können. Vielleicht hätte es ja niemand bemerkt, aber eigentlich hilft die Erkenntnis nicht wirklich weiter… SSDs sind schnell, Festplatten langsam. Habe ich mehr Daten als in meine SSDs passen, dann brauche ich meine Festplatten. Das hätten wir uns auch ohne 8h Testaufbau denken können. Deshalb haben wir uns die nächste Frage gestellt: Wie könnte es im echten Leben aussehen? Eine tatsächliche Serverumgebung in einem Disk-lastigen Benchmark mit mehreren Benutzern zu simulieren ist doch eher komplex und vor allem schwierig sicher zu reproduzieren. Deshalb haben wir bei den Kollegen im Desktop-Benchmark Bereich angefragt und uns hierfür einen Benchmark aus der Desktop-Welt ausgeliehen: SysMark 2007.

Ein Sysmark führt mehrere Arbeitsabläufe in Desktop-Anwendungen wie Office, Photoshop, 3DS Max, SketchUp, After Effects, Vegas, … skriptgesteuert durch und misst dabei die Verarbeitungszeit. Hauptsächlich wird hierbei die CPU belastet, aber die Erfahrung mit Sysmark zeigt, dass sich das Testergebnis stark mit dem verwendeten Disk-Subsystem beeinflussen lässt. Hierbei setzen wir also an. Natürlich sind die Testszenarien nicht repräsentativ für den Serverbetrieb, jedoch kommen wir mit den Zugriffsmustern und verwendeten Dateigrößen recht nah heran. Die von Sysmark ausgegebenen Werte sind jedoch keine IOPS sondern Punktezahlen. Eine kleine Abweichung bedeutet hierbei eine starke Auswirkung auf das Gesamtsystem. Die Übersetzung in tatsächliche Systemgeschwindigkeit fällt vielleicht leichter, wenn man die Punkte prozentual in Relation stellt.

Wir stellen mit je einer Grundkonfiguration, also 4xSAS, 2xSATA einen Basiswert her und fügen dann zum SATA-RAID die SSDs hinzu.

Wer jetzt schon die Luft anhält und auf ein Performancefeuerwerk wartet, muss sich mindestens noch bis Silvester gedulden:

Kurz herunter gebrochen, lässt sich sagen, dass in dieser Umgebung das SSD-gestützte SATA-RAID1 mindestens genauso performant wie ein RAID10 mit 4x SAS ist. Ich kann also in solch sehr kleinen Konfigurationen Leistungsansprüchen, die ich sonst nur mit schnelleren SAS HDDs decken könnte, auch mit weniger SATA HDDs und CacheCade SSDs erreichen und so ein besseres Platz/Leistungs/Kostenverhältnis erzielen.

Eine 100%ige Sicherheit, dass in jedem anderen Szenario die gleiche Leistungssteigerung zur Verfügung steht, gibt es natürlich nicht, jedoch kann in einer Small-Business Umgebung angenommen werden, dass die Lasten größtenteils vergleichbar sind (Sysmark simuliert einen intensiven 8h Arbeitstag, heruntergebrochen auf wenige Stunden Laufzeit).

Damit macht die Kombination aus 2+2 eine interessante Alternative für die Verwendung in kleinen Serversystemen. In größeren Umgebungen ist natürlich auch eine Leistungssteigerung da, jedoch ist fraglich ob dann dabei auf schnelle Spindeln als Rückgrat verzichtet werden kann, so wie hier.

Viel Spaß beim Messen.