Currently Being Moderated

Nach mehr als 20 Jahren in der IT Branche habe ich irgendwann alles schon mal gehört – geht es Ihnen nicht auch manchmal so?

Aktuell habe ich bei dem Begriff Storage Tiering ein Déjà Vu. Begriffe wie z.B.  HSM (hierarchisches Storage Management) und dessen „Nachfolger“  ILM (Information Lifecycle Management)  geistern schon ewig durch die Medien. Vor allem HSM gibt es schon seit es Mainframes gibt. Und wer hat´s erfunden? Ja genau: IBM.

Die Idee, Daten entsprechend ihrer Nutzungscharakteristik auf die passenden Speichermedien abzulegen, ist also bestimmt nicht neu. Aber irgendwie hat es sich in den letzten 20 Jahren auch nicht wirklich durchgesetzt. Der neueste „Ableger“  AST (Automated Storage Tiering) wird gerade ganz aktuell durch´s Dorf gejagt. Die Idee ist im Prinzip immer noch die gleiche:

 

-     - Man analysiert die Nutzung von Daten auf Storage Arrays. Dadurch kann man feststellen, ob sich das Nutzungsmuster ändert.

-     - Wird auf Daten häufig zugegriffen, liegen sie auf schnellen/teuren Platten, im Extremfall SSD´s.

-     - Wird auf Daten selten zugegriffen, liegen Sie auf langsameren/günstigeren Platten, meistens SATA Disks.

-     - Dazwischen wäre z.B. noch ein Level mit SAS Disks.

 

Eine Typische 3-Tier Architektur könnte z.B. so aussehen:

AST.png

Was läuft da nun konkret ab? Bei der Installation muss man sich natürlich zuerst Gedanken machen, welche Daten lege ich auf welchem Tier ab. Das kann je nach vorhandener Datenstruktur eine sehr mühsame und zeitaufwändige Aufgabe sein. Wenn man das geschafft hat muss man Regeln definieren, nach welchen Kriterien die Daten von Tier zu Tier verschoben werden sollen. Danach kann man die Anwender und Applikationen auf das ganze „loslassen“.  Erfahrungsgemäß kann man sich noch so viele Gedanken vorab machen, es läuft in der Realität meistens anders, als man es sich vorgestellt hat. D.h. Daten, die auf SATA Platten abgelegt wurden, werden z.B. für einen monatlichen Rechnungslauf benötigt. Die Daten für den Quartalsabschluss liegen am Quartalsende auf den SSDs und sollten danach natürlich auf Tier-2 oder Tier-3 verschoben werden. Plötzlich arbeiten die Ingenieure wieder an einem alten Projekt und beschweren sich über die grottenschlechte Performance beim Zugriff.

Was passiert jetzt bei dem AST Konzept?

 

Die Daten, deren Nutzungsverhalten sich verändert hat, werden markiert und beim nächsten „Migrationslauf“ auf das dafür passende Tier verschoben. Das passiert aber nicht auf Basis von kleinen Blöcken, sondern es werden immer mindestens 1 GB  oder ganze Files verschoben.

 

Auf den ersten Blick eine coole Sache. Die Daten für die Monatsabrechung liegen jetzt auf den SSDs und die Daten für die Quartalsabrechnung auf den SATA Disk. Nur die Monatsabrechung ist höchstwahrscheinlich schon längst vorbei. Das Muster hat sich ja genau wegen der laufenden Abrechnung verändert. Die Daten liegen jetzt aber auf der SSD, verschwenden wertvollen Speicherplatz und haben viel I/O Kapazität beim eigentlichen Verschieben benötigt. Am nächsten Tag verbrauchen sie die schon wieder, wenn sie nämlich auf SATA zurückkopiert werden.

Dieses Beispiel offenbart die großen Nachteile der AST Technologie:

 

-     - Kein Echtzeitprozess -> Daten sind schon wieder „kalt“ wenn sie auf dem schnellsten Tier liegen

-     - Hoher Bedarf an Disk I/O  und CPU Ressourcen durch das Verschieben von 1 GB großen Blöcken oder ganzen Files

-     - Aufwändige und komplexe Administration

 

Hmm, wie könnte man es also besser machen? Bei dem Gedanken kommt mir die Analogie zum CPU Cache in den Sinn. Kein Mensch würde auf die Idee kommen, sich in das Cache Handling einer intelligenten CPU „einzumischen“. Die erkennt sofort, welche Daten „hot“ sind, und speichert sie ohne jede Verzögerung, in Echtzeit und vollautomatisch auf den 3 heutzutage gängigen Cache Levels.

Genau dieses Prinzip hat NetApp mit FlashCache für Storage umgesetzt und nennt es „Virtual Storage Tiering“ . Man steckt die FlashCache Karte in den Controller, lässt die Software die Charakteristik der Zugriffe auf ALLE Daten des Controllers analysieren und genießt dann die extrem gesteigerte Performance des gesamten Systems.  Genauso wie eben beim CPU Cache

Die Vorteile liegen auf der Hand:

-     - Keine Administration

-     - Echtzeitprozess

-     - Kein zusätzlicher I/O Bedarf

-     - Voll Transparent für ALLE Daten des Controllers

-     - Keine Einschränkung bzgl. der Funktionalität (der Cache ist z.B. Dedupe aware)

 

WOW! Wie geil ist das denn!  Genau so stelle ich mir das vor.

Comments

Filter Blog

By author: By date:
By tag: