Team Deutschland

4 Posts authored by: okrause

Die Performance von Speichersystemen ist seit jeher eine eigene Domain. Viele von uns haben irgendwann den Umgang mit Performance im Compute-Bereich der IT halbwegs verstanden (und auch das ist ein beliebig komplexes Thema), Storage-Performance bleibt aber für viele ein Buch mit sieben Siegeln. Jede Woche erlebe ich es beispielsweise wieder, das mit der Metrik MB/s argumentiert wird, obwohl diese Metrik ausser im HPC Bereich selten die Richtige ist.

 

Nun muss ich zugeben das dies auch ein komplexes Thema ist und auch ich meine ersten zwei Jahre in der Industrie voll daneben lag und auch heute immer wieder mal was lerne. Eine lustige Anekdote aus dem Jahre 2000 ist, wie ein Kollege und ich bei einem Kunden einen Performance-Test durchführten und versucht haben, mit allen möglichen Tricks die Performance der Oracle Logwriters über 5MB/s zu bekommen. Wir waren uns ganz sicher das in der Umgebung des Kunden irgendetwas nicht stimmte, unsere DD Tests hatten immer viel bessere Resultate erbracht. Was wir damals noch nicht so recht verstanden hatten war der Zusammenhang von Single-Threaded und Latency ...

 

Wo will ich hin? Storage Performance ist ein komplexes Thema. Und es Bedarf einer Menge Wissen und Erfahrung um dieses Thema zu meistern. Auf der anderen Seite werden Storagesysteme immer komplexer und spätestens bei einem Scale-Out-System wie Clustered Data ONTAP verliert man leicht den Überblick.

 

NetApp hat erkannt, das klassische Performance Monitoring Tools, die hauptsächlich Metriken auf die eine oder andere Weise visualisieren, unzureichend sind. Wir entwickeln daher für Clustered Data ONTAP die nächste Generation von Performance Management Tool. Darf ich vorstellen:

 

OnCommand Performance Manager 1.0

 

OPM 1.0 ist die erste Version des neuen Performance Managers. Bei OPM dreht sich alles um das Erkennen von Performance Problemen. Dazu wertet OPM diverse Metriken (primär Latenzen) einzelner Subsysteme und Storageobjekte des Clusters aus und setzt sie in Zusammenhang. Das ermöglicht das Beantworten von Fragen wie:

  • Liegt das aktuelle Performanceproblem im Storagesystem oder ausserhalb?
  • Welche Resourcen (z.B. LUNs, Volumes) sind betroffen? OPM nennt diese Opfer (Victims).
  • Wer verursacht das Problem? OPM nennt diese Täter (Bully).
  • Ist der Täter eine externe (z.B. ein defektes Skript erzeugt auf einmal 10mal mehr Workload und zieht die Produktionsdatenbank runter) oder interne Workload (vielleicht sollte der vol move doch zu einer Off-Hour gestartet werden)?
  • Okay, das Problem liegt wirklich im System: Wie schaffe ich Abhilfe?

 

Das Ganze verpackt in eine moderne und gefällige UI. Beispiel:

OPM001.png

Das Bild zeigt die Latenz einer LUN (blaue Linie). Der graue Korridor ist der Bereich in dem sich die Latenz in der Vergangenheit bewegt hat (OPM hat gelernt, was die normale Latenz der LUN ist). Sobald sich die Latenz aus dem Korridor bewegt, wird ein Event erzeugt (roter Punkt) und OPM verrät einem die Ursache. Hier sieht man, das OPM die Ursachen in Bereiche wie Network (ist der Link nach aussen saturiert), Policy Group Limit (Clustered ONTAP hat Quality of Service; bin ich in ein vom Administrator mit QoS gesetztes Limit gelaufen) oder Aggregate (wir ziehen mehr IO als die angeschlossenen Disks liefern können) einordnet. Wenn man tiefer ins Detail geht werden mehr Informationen und oft auch eine Tipp zur Abhilfe gegeben.

 

OPM 1.0 wird nicht die Antwort auf jedes Performanceproblem liefern. Wir haben eine umfangreiche Vision und Roadmap für seine Zukunft, heute geht es mit V1.0 los. Dennoch ist es ein extrem starker Auftakt für ein Tool, das kein cDOT Admin missen darf. OPM kann viel Zeit und Nerven sparen und wer wünscht sich nicht eine schnelle Antwort, wenn es mal wieder heisst "der Storage ist Schuld" (Hint: ist er meist nicht).

 

Und das Beste kommt zum Schluss: OPM ist Free. Free wie in "kostenlos". Sollten Sie also eine Clustered Data ONTAP System betreiben, geschwind http://support.netapp.com/NOW/download/software/oncommand_pm/1.0RC1/ ansurfen und loslegen!

 

Und sicher lohnt es sich auch in der OnCommand Community vorbeizusehen.

 

Bevor Airbus mir jetzt seine Anwälte schickt: Der Vergleich ist natürlich Schwachsinn. Ein Learjet kann Passagiere schneller und billiger als ein Airbus ans Ziel bringen. Klappt aber nur, wenn wenn wir von max 10 Personen sprechen (ein Learjet nimmt weniger als ein Dutzend Personen auf, ein A340 Hunderte) und wenn er eine Abkürzung fliegt (ein A340 hat eine höhere maximale Fluggeschwindigkeit als ein Learjet).

 

Was soll der seltsame Vergleich? Es ist ein typischer Äpfel-mit-Birnen-Vergleich, wie er mir kürzlich auch in dem Artikel "Oracle punktet gegen NetApp: Mehr Performance, geringere Kosten" begegnet ist. Der Artikel beruht wohl auf Aussagen, die Oracle auf der Produktwebseite zur Sun ZFS Storage 7320 Appliance macht. Dort steht: "32% higher throughput and 9% faster overall response time than the NetApp FAS3270 on the SPECsfs2008_nfs benchmark* at a fraction of the cost". Und nachdem ich bei Hochzeits-Crasher ein Menge gelacht habe, lade ich mich zu der Benchmark-Party selber ein.

 

Gehen wir die einzelnen Aussagen Stück für Stück an:

 

Performance -  "32% higher throughput and 9% faster overall response time"


SPEC SFS2008 ist ein Benchmark der primär die Leistungsfähigkeit des NAS-Controllers vermisst. Dazu wird das Disksubsystem üblicherweise so ausgebaut, dass es nicht das Limit darstellt.

 

Die beiden betreffenden Resultate sind auf der SPEC Webseite inklusive der Konfiguration der Systeme und der Testbedingungen verfügbar:

 

NetApp FAS3270: Die FAS erreicht in einem 1,5 Jahre alten Ergebnis einen Wert von 101183 Ops/Sec (Overall Response Time = 1.66 msec).

Sun ZFS Storage 7320 Appliance: Die Sunkist erreicht in einem brandneuen Test einen Wert von 134140 Ops/Sec (Overall Response Time = 1.51 msec).

 

Das spiegelt die Aussage von Oracle wider. Wenn man sich jedoch etwas mit dem SPECsfs auskennt, weiss man, dass die Systeme oft in alltagsfernen Konfigurationen getestet werden. Meist wird kräftig getuned. Sehr beliebt sind hier Tricks wie "RAID ausschalten", "viele, viele kleine Disks", "sehr viel Cache" oder "viele kleine Filesysteme" damit die Workload nicht zu random wird.

 

NetApp testet Systeme üblicherweise in einer recht praxisnahen Konfiguration. Auch in diesem Test: Ein Filesystem pro Controller, die zu diesem Zeitpunkt üblichen 450GB/15K SAS Drives, und natürlich mit eingeschaltetem RAID-DP, unserem leistungsfähigen RAID6-Verfahren. Wir betrachten den Test mit eingeschaltetem RAID-DP auch als vertrauensbildende Maßnahme. Es ist ein klares Statement: "Unser System performt im Alltag!"

 

Bei der SUN 7320 findet sich das typische Tuning. Mehrere 17 Disk (300GB/15K SAS) große RAID0-Pools und 32 Filesysteme. Wir erinnern uns, RAID0 ist reines Striping, und die Ausfallwahrscheinlichkeit steigt mit jeder weiteren Platte. Diese Konfiguration mag für Scratch gut sein, für ernsthafte Datenhaltung ist sie unbrauchbar. ZFS hat mit RAID-Z2 ein bezüglich Datensicherheit (laut Datenblatt) ähnlich sicheres Verfahren wie ONTAP. Aber natürlich kostet Sicherheit Performance. Müsste die 7320 in dem Benchmark aber zusätzlich RAID-Z2 berechnen, würde sich der "32% higher throughput" wahrscheinlich ins Gegenteil verkehren. Wenn ich dem Blogeintrag "WHEN TO (AND NOT TO) USE RAID-Z" glauben darf, liegt hier eine sehr viel hässlichere Wahrheit vergraben. ("Effectively, as a first approximation, an N-disk RAID-Z group will behave as a single device in terms of delivered random input IOPS. Thus a 10-disk group of devices each capable of 200-IOPS, will globally act as a 200-IOPS capable RAID-Z group.") *Hust.* Demnach wuerde das Disk-Backend dann nur noch 17 * 200 IOPS schaffen ...


Einen Punkt muss ich Oracle hier aber geben. Dank des Einsatzes von SSD's erreichen sie das Controllerlimit schon mit 136 Disks, NetApp nutzt fast 3x soviel Disks im Test. Das ist ein klares Statement, dass Mechanismen wie NetApp's FlashCache (SUN's Read Flash Accelerator sind ein ähnliches Funktionsprinzip) wirkungsvoll die Anzahl der nötigen Festplatten reduzieren können, wenn IOPS gefordert sind. Heute würde wir den gleichen Benchmark wahrscheinlich mit FlashCache und weniger Disks durchführen. NetApp verkauft mittlerweile mehr als die Hälfte aller FAS32x0/62x0 Systeme mit FlashCache.

 

Capacity - Schliesslich kauft man Storage zum Speichern von Daten

 

Bevor wir über das Thema Preis reden, lohnt es sich, etwas Zeit mit Kapazität zu verbringen. Hier die Fakten:

 

In den SPECsfs-Tests erreicht das SUN-System eine usable Capacity von 37TB (also 32 Filesysteme a 1,2 TB). Das NetApp System hat 126TB, entspricht Faktor 3,4. Wenn man den fehlenden RAID-Schutz mit einrechnet, kommt das SUN-System nur noch auf 28,8 TB (136 Disks, max (7+2) Disks pro Raid). Faktor 4,4 mehr Kapazität mit dem NetApp System.

 

Viel mehr geht bei der 7320 auch nicht. In der HA-Config kann man max. 8x24=192 Disks anstecken. Die von Oracle getestete Konfiguration kann also um maximal 48 Disks erweitert werden und erreicht dann knappe 39TB. Das ist sehr viel für einen ambitionierten Heimanwender, für Unternehmen jedoch eher am unteren Ende. Die FAS3270 kann maximal 960 Disks verwalten …

 

Preis

 

Üblicherweise wird Storage nach Kapazität gekauft. Wenn das System die funktionalen Anforderungen erfüllt und schnell genug ist, sind Kapazität und Preis pro Gigabyte das primäre Kaufkriterium. Demnach darf das NetApp System aus dem SPECsfs-Test auch das 4,4- fache kosten. NetApp -Systeme werden aber nicht nur wegen der Leistungsfähigkeit des Blechs gekauft. Die Stärke unserer Systeme liegt in der einfachen Skalierbarkeit (die FAS3270 kann auf bis zu 960 Disks erweitert werden), der umfangreichen Applikationsintegration und dem gewaltigen Ecosystem.

 

So reißerisch die Schlagzeile auch klingt, der Benchmark wirbt für die Lösung eines Problems, das es in der Realität der IT- Abteilungen meist nicht gibt. Es ist daher fraglich, wo der Sweetspot der Sun ZFS Storage 7320 Appliance liegen soll. Scratch für temporäre Daten? Das macht eine NetApp E-Series auch, nur günstiger und schneller. Mit Raid6 ...

Wenn der Zählerüberlauf im Maya-Kalender wirklich den Weltuntergang darstellt, geh ich jetzt von einer Zombieapokalypse aus. Zumindest ist mir gestern im Büro ein Zombie begegnet. Kein körperlicher, sondern eher eine Art Wolpertinger, ein Fabelwesen der Storage-Industrie. Konkret das Phantom des "NetApp wird langsam bei 20% Speicherauslastung". Dieser FUD war vor 10 Jahren schon nicht mehr originell, und dass er heute noch auftaucht überrascht.

 

Auf den Sinn und Unsinn davon möchte ich gar nicht eingehen, das ist schon oft genug geschehen. Vielmehr kam ich etwas ins Grübeln über das Thema Auslastung. Die mittlere Auslastung eines Systems gibt an, wieviel der zur Verfügung stehenden Kapazität man wirklich nutzt, sprich wieviel "meines Geldes wirklich für mich arbeitet". Also wie voll sind Systeme eigentlich so im Schnitt? Was darf man realistisch erwarten? Das Ergebnis hat mich etwas überrascht.

 

Fangen wir mit den Buying Pattern unserer Kunden an. Fast immer werde Systeme beim initialen Kauf auf den Endausbau zum Laufzeitende gesized. Die Gründe sind immer die gleichen:

 

* Das Budget muss jetzt ausgegeben werden.

* Der Kunde glaubt - meist aus der Erfahrung mit anderen Storagesystemen - eine Kapazitätserweiterung sei komplex.

* Später gekaufte Kapazität hat einen anderen Abschreibungszeitraum.

 

Technisch ist es sehr einfach, im laufenden Betrieb Kapazität zu ONTAP Systemen hinzuzufügen. Das ist nicht der Grund. Die eigentlichen Hinderungsgründe sind vielmehr kaufmännisch/organisatorisch.

 

Betrachten wir doch mal die Auswirkungen dieses Vorgehens. Übliche Angaben vom Kunden sind: "Wir haben ein Datenwachstum vom 60% im Jahr und wollen das System 3 Jahre lang betreiben." Unter der Annahme das viele Kunden das so handhaben, kann man eine mittlere Auslastung berechnen. Dazu ein bisschen Mathematik:

 

Mithilfe des Datenwachstums kann man die Kapazität nach der Formel

formel1.png

berechnen, wobei n die Startkapazität, w das Wachstum in Prozent und t die Laufzeit ist. So ergibt sich für unseren Kunden, der heute 300 TB hat und um 60% jährlich wächst, nach 3 Jahren eine Zielkapazität von grob 1,2 PB. Die mittlere Auslastung (nach halber Laufzeit) kann man mit

formel2.png

berechnen. In unserem Beispiel wäre die Startauslastung bei ca 25% und nach der halben Laufzeit bei knapp 50%. Hier noch eine Tabelle, um ein Gespür zu bekommen, wovon wir reden:

 

Wachstum

mittlere Auslastung

40%

60%

50%

54%

60%

49%

70%

45%

80%

41%

90%

38%

100%

35%

 

 

Welche Schlüsse kann man daraus ziehen? Die Auslastung ist umso schlechter, je höher das jährliche Datenwachstum und je länger die Laufzeit des Systems ist. Keine Rocket Science, aber sehr ernüchternd zu sehen, das nur 50% Auslastung durchaus ein üblicher Wert ist. So hatte ich das noch nie betrachtet.

 

Wie kann man die Auslastung verbessern?

Wie oben beschrieben, ist die Ursache meist nicht technischer, sondern betriebswirtschaftlicher oder organisatorischer Natur. Wenn der Kunde hier seine Prozesse ändern kann und auch während der Laufzeit Kapazität bedarfsorientiert hinzufügt, wird die Auslastung besser. Oft erlauben das aber betriebliche Prozesse nicht. Manchmal kann ein Storage-On-Demand Konzept hier zusätzliche Flexibilität schaffen. Fragen Sie den Freundlichen.

 

Einen technischen Kniff habe ich aber noch parat. Wenn wir in obiger Formel das Wachstum kleiner bekommen, verbessert sich die mittlere Auslastung automatisch. Auf das Wachstum der Netto-Daten hat man als IT-Abteilung üblicherweise wenig Einfluss, aber am Hebel Netto-Daten vs. Brutto-Kapazität kann man dank Storage-Effizienz deutlich drehen. Besonders mit Deduplizierung und, ganz neu in ONTAP 8.1, mit Kompression lassen sie meist signifikante Ersparnisse erzielen. Effektiv entspricht das einer Reduzierung der Brutto-Wachstumsrate. Unsere Technologie erlaubt uns, weniger Blech für die gleiche Anforderung zu benötigen.

 

Das spart nicht nur Anschaffungskosten, sondern auch Stellplatz und Strom! Oder man nimmt einfach den 21. Dezember als festes Laufzeitende. Das spart auch Geld, das man dann in Pflanzen und Rasenmäher stecken kann.

okrause

Die COW Verwirrung

Posted by okrause Jan 12, 2012

Wir schreiben das recht frische Jahr 2012. Das heisst ich habe nur noch knappe 12 Monate um eine Verwirrung aus der Welt zu räumen, die mich bereits die letzten 12 Jahre begleitet. Aber nachdem ich lang genug in der IT bin, glaube ich, dass auch die Mayas von Counter Overflows nicht verschont waren und es sich nicht um den Weltuntergang, sondern nur um das Y2K-Problem der Maya-Zeitrechnung handelt.

 

Es hat daher wohl nachhaltigen Nutzen, die Verwirrung der Storage-Industrie um den Begriff Copy-On-Write (COW) zu beleuchten. Hier mein Versuch:

 

Copy-on-Write (COW) im Memory Management

 

Das Copy-On-Write Verfahren kommt ursprünglich aus dem Memory Management und beschreibt eine Technik, die dort üblicherweise vom Virtual Memory Management (VMM) genutzt wird, um Hauptspeicher effizienter zu nutzen. Grob gesagt wird bei einem klassischen Prozessmodell ein neuer Prozess erzeugt, indem der Elternprozess geclont wird. Der neue Prozess hat einen privaten virtuellen Adressraum, der zunächst aus Zeigern auf die physischen Speicherblöcke des Elternprozesses besteht. Erst wenn einer der beiden Prozesse seinen Speicher ändert, wird eine Kopie des Speicherblocks auf einen neuem physischen Block erstellt, der virtuelle Zeiger umgebogen und die Modifikation ausgeführt. Das führt dazu, dass die Prozesse sich gleiche Blöcke teilen und nur die Differenzblöcke zusätzlich gespeichert werden müssen. Der neue Block wird immer an eine neue, leere Stelle geschrieben.

 

Copy-on-Write in der Storage-Welt

 

In der Storage-Industrie wurde der Begriff Copy-On-Write bis vor einigen Jahren für ein Verfahren zum Erstellen von Snapshot-Kopien genutzt. Dabei baut ein klassisches Storage-System einen Snapshot, in dem es beim Überschreiben einer durch Snapshots gesicherten LUN den alten Datenblock erst wegkopiert (oft in einen extra zu definierenden, dedizierten Snapshot Bereich), bevor es den neuen Block an die ursprüngliche Stelle schreibt. Natürlich ist dieses Verfahren nicht das schnellste, da für jeden zu schreibenden Block ein Lese- und zwei Schreib-IOs stattfinden müssen. Jeder Schreib-IO erzeugt 3 IOs. Auch hier werden gleiche Blöcke zwischen der LUN und ihren Snapshots geteilt, Differenzblöcke werden aber in den Snapshot verschoben. Mehrere Snapshots auf einer LUN erhöhen bei manchen Systemen den Aufwand zusätzlich.

 

Write Anywhere

 

Moderne, virtualisierende Systeme wie NetApp's WAFL machen das anders. Wird ein Block überschrieben, wird der neue Block einfach an eine freie Stelle geschrieben und der virtuelle Zeiger angepasst. Daher auch der Name "Write Anywhere File Layout". Es erzeugt einen Schreib-IO versus 3 IOs beim COW-Verfahren. Man nennt Filesysteme, die nach diesem Prinzip funktionieren, auch oft log-structured Filesystems.

 

Die SNIA beschreibt diese Verfahren übrigens recht gut in folgendem Dokument: http://www.snia.org/sites/default/education/tutorials/2007/spring/data-management/Disk-based_Restoration_Technologies.pdf , Seite 28-32. WAFL benutzt nach dieser Definition Write Anywhere (surprise, surprise).

 

Wenn ich mich bei Kollegen umhöre, verbinden die meisten mit COW das langsame, drei IOs erzeugende Verfahren. Unser Tribal Knowledge sagt: "COW ist lahm, WAFL macht es besser".

 

Der Sündenfall

 

Wo ist also das Problem? In den letzten Jahren wurde der Begriff COW-Filesystem immer öfter für Systeme benutzt, die nach der SNIA Beschreibung eigentlich Write Anywhere Filesysteme sind. COW wird also einerseits für die langsamen 3 IO-Systeme als auch für die flinken Write Anywhere Systeme benutzt. Wenn man nun auf jemanden trifft, der das jeweils andere Verfahren unter diesem Begriff versteht, führt das schnell zu fundamentalen Irrtümern.

 

Wie kam es dazu? In meiner Wahrnehmung hat die Verwirrung mit dem Release von ZFS angefangen. Als erstes generelles Filesystem hat ZFS die meisten Funktionen des kommerziell erfolgreichsten Write Anywhere Filesystems (NetApp's WAFL) kopiert und durch den Open Source Ansatz viel Hoffnung genährt, dass diese Funktionalität schnell Standard in allen relevanten Systemen wird (was nicht geschehen ist). Sprich: Während WAFL in NetApp Systemen eher unscheinbar unter der Motorhaube treu seine Dienste leistete, wurde es durch ZFS auf einmal sexy über Filesysteme, ihre Features und ihre Funktion zu sprechen.

 

Wenn man nun auf die Funktionsweise und die Nomenklaturen in ZFS sieht, gewinnt man den Eindruck, die Entwickler hatten eher einen VMM- anstatt eines Storage-Backgrounds. Einige Konzepte erinnern mehr an ein VMM (z.B. Slabs) als an Storage. So ist es auch nicht verwunderlich, das die Entwickler - vermutlich in mangelnder Kenntnis des Begriffes "Write Anywhere" oder "log structured" - den ihnen vertrauten und ein ähnliches Konzept beschreibenden Ausdruck Copy-On-Write wählten. Seitdem wird ZFS als COW Filesystem beschrieben. BTRFS hat dieses Wording später übernommen. Das hat dazu geführt, dass log-structured Filesysteme mittlerweile von vielen Menschen Copy-On-Write genannt werden, jedoch NetApp als Marktführer in Deutschland den Begriff COW anders nutzt. Und voilà, die Verwirrung ist komplett, wir reden womöglich alle aneinander vorbei …

 

So what?

 

Ist es nun wichtig, welcher Begriff korrekter ist als der andere? Ob wir log-structured Filesysteme Write Anywhere oder COW nennen? Ich denke nein. Ist es wichtig, dass mein Gegenüber versteht was ich meine, wenn ich COW benutze? Auf jeden Fall, ja!

 

Wie lösen wir dieses Missverständnis auf?

 

Die meisten meiner Kollegen würden gerne weiter COW für das langsame, unter dem obigen SNIA Link beschriebene Verfahren benutzen. Jedoch ist sich die SNIA wohl auch nicht mehr so 100% sicher, die COW Definition liest sich eher wie Write Anywhere. Und in Wikipedia steht unter ZFS und BTRFS auch immer COW-Filesystem. Ich glaube, das Kind bekommen wir nicht aus dem Brunnen.

 

Oder wir lassen COW und Write Anywhere einfach aussen vor und weichen auf "log-structured" aus, klingt aber ziemlich nerdy. Und wie nennen wir eigentlich das lahme 3 IO-Verfahren, das früher COW hieß? Move-on-Write (MOW)? Oder gleich Every Modify Copies?

 

Zumindest sollten wir alle in Zukunft mit dem Begriff Copy-On-Write Filesystem vorsichtiger umgehen und uns gewahr sein, dass unser Gegenüber genau das Gegenteil verstehen könnte …

 

Frohes 2012

Filter Blog

By author: By date:
By tag: