[DE] PernixData FVP – Entkoppelte Storage Designs


In diesem Post geht um es zwei Punkte die sehr eng miteinander verbunden sind und meiner Meinung nach gemeinsam betrachtet werden müssen. Zum einen FVP im Kontext des Storage Designs und zum anderen der FVP „Entkoppelungs-Effekt“.

Bisher war die Leistung einer virtuellen Maschine immer an die Leistungsfähigkeit des darunterliegenden Storage System gebunden. Sprich war das System in der Lage max. 5000 IOPS zu liefern, so konnten VMs auch nicht mehr abrufen. War dies doch der Fall, was bei stetig steigender Applikationsdichte schnell passiert, so steigen nicht die IOPS sondern leider nur die Latenzen. Das heißt, eine Anwendung muss auf Grund physikalischer Grenzen entsprechend länger warten bis die gestellten I/O Anfragen verarbeitet wurde.

Der folgende Screenshot zeigt dies ziemlich gut, denn man erkennt das die Latenz der VM mit der Linie der Datastore Latenz überlappt und quasi unzertrennlich ist.

VM_and_Datastore_Latency

Bis zu einem gewissen Punkt, an dem FVP aktiviert wurde. Dann nämlich passiert das entscheidende, die Entkoppelung. Durch die Tatsache, dass FVP lesende als auch schreibende I/O mittels serverseitigen Medien wie Flash oder RAM beschleunigt, richtet sich die Leistungsfähigkeit jetzt primär nach dem Potential des eingesetzten Mediums.Die Leistung ist damit entkoppelt vom eigentlich Storage System und all den dazugehörigen Bottlenecks. Das bedeutet abgekürzt, mehr IOPS, mehr Durchsatz bei wesentlich geringerer Latenz.

Wie auf dem Screenshot zu erkennen, trennen sich die bisher unzertrennlichen Linien. Die Latenz der VM sink unter 3 ms und ebenso die Latenz des Storage Systems sinkt, warum? Da ein Großteil der Anfragen durch FVP beantwortet werden kann und somit direkt das Storage System entlastet wird.

Zugegebenermaßen ist die hierdurch entstehende Latenz erst einmal relativ, denn für Kunde A sind Latenzen von 20ms völlig normal und ggf. auch tolerierbar für Kunde B jedoch eine mittlere Katastrophe. Auch hat nicht jeder Kunde Anforderungen von zehntausenden IOPS, also könnte man schlussfolgern, dass FVP hier nicht benötigt wird? Nein! Und das ist der Punkt um den sich dieser Artikel eigentlich dreht.

Der ein oder andere kennt das Problem wahrscheinlich, wie viele IOPS brauche ich oder mein Kunde eigentlich? Eine Frage deren Antwort wahrscheinlich ein paar Monate nachdem diese, falls überhaupt, beantwortet wurde, bereits durch neue Anforderungen hinfällig ist. Noch schwieriger ist die Frage beziehungsweise die Planung einer maximal tolerierbaren Latenz. Also was tun, möglichst viele HDDs? Flash im SAN? Wieviel Flash? Kombinieren mit Auto Tiering? RAID5 oder doch lieber RAID10? Wie groß sollte der Cache, die dazugehörigen Controller (CPUs) sein? Welches Lese- Schreibverhältnis muss das Storage System bewältigen können oder mit welcher durchschnittlichen Blockgröße wird denn gelesen oder geschrieben? Man sieht schnell, mehr Fragen als Antworten. Vor allem sind die Antworten von Umgebung zu Umgebung völlig unterschiedlich, sodass generische Regeln eigentlich nicht anwendbar sind.

Warum sich nicht den Enkopplungs-Effekt von FVP zu Nutze machen und diesen bei neuen Storage Designs miteinbeziehen?

Dieser Effekt ermöglicht plötzlich wesentlich mehr Spielraum beim Design neuer & innovativer Storage Lösungen. Muss das neue System wirklich mit Flash und HDDs überprovisionieren sein, um auf Lastspitzen und neue Anforderungen vorbereitet zu sein? Welche Mehrkosten entstehen alleine für eine Planung nach dem Motto „auf Nummer sicher gehen?“. All diese zusätzlichen HDDs erzeugen nicht nur initiale Kosten, sondern benötigen Rackspace, Strom & wollen nicht zuletzt auch gekühlt werden. Ist für eine kleine Umgebung evtl. ein Array bestückt mit SATA HDDs anstelle von SAS HDDs ausreichend? Muss es wirklich immer RAID10 sein um möglichst viele IOPS aus dem Storage System zu quetschen, oder kann ich möglicherweise kapazitätsorientiert RAID5 einsetzen?

Es geht nicht darum eine Finale Antwort zu liefern, sondern zum Überdenken anzuregen und Designs auf den Prüfstand zu stellen. Möglicherweise ergibt sich die Möglichkeit neue Wege zu beschreiten ohne dabei auf bewährte Technologien verzichten zu müssen.

Denn ein Investment in eine neue Storage Plattform bestimmt den Weg idr. für die nächsten 3 Jahre und die Planung betrachtet idr. nur den Zeitraum indem die Spezifikationen definiert werden müssen. Überschreiten die zu bewältigen Anforderungen das eingeplante Wachstum, so müssen oft unfreiwillig nachträgliche Erweiterungen vorgenommen werden, mit Mitteln, die an anderer Stelle mindesten ebenso notwendig gewesen wären. Auch sind diese Investitionen nach Ablauf des Lebenszyklus abgeschrieben und alles beginnt von vorne. Mit einer strategischen Software Plattform, welche Server als auch Storage Replacements überlebt, bietet sich die Chance diesen klassischen Zyklus zu durchbrechen und zukünftig wesentlich effizienter & leistungsfähiger zu gestalten.

Print Friendly, PDF & Email

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *