Weshalb NetApp File auf AWS die Cloud verkompliziert (und verlangsamt) 

Weshalb NetApp File auf AWS die Cloud verkompliziert (und verlangsamt) 

 

Von David A. Chapa, Head of Competitive Intelligence, Qumulo

 

File on AWS wird mit NetApp nicht besser

Jüngst wurde auf dem AWS Storage Day die allgemeine Verfügbarkeit von Amazon FSx für NetApp ONTAP angekündigt. AWS FSx ist ein von AWS angebotener Managed Service und damit das dritte Angebot dieser Art von AWS. Das klingt nach einem großen Gewinn, aber es handelt sich um die gleiche Komplexität wie bei der On-Premises-Lösung, nur jetzt auf AWS.

Das Hauptproblem bei dieser Storage Day-Ankündigung ist, dass NetApp die gleiche Komplexität in die Cloud bringt, die jeder mit seinen Filern und seinem Betriebssystem ONTAP verbindet. Ein gemanagter Service sollte mehr „plug ’n play“ sein, aber in diesem Fall liegt es am Kunden, zu bestimmen, wie er seine Daten in diese Lösung einwählt. Zunächst einmal heißt es, dass die Lösung auf Petabytes an Speicherplatz skaliert werden kann. Lassen Sie uns das alles einmal ein wenig analysieren.

Beim Skalieren geht der Durchsatz verloren

In der Ankündigung wird behauptet, diese Lösung sei „praktisch unbegrenzt“ skalierbar.  Nach dem, was ich gelesen habe, gibt es jedoch zwei separate Speicherebenen.  Das primäre Volumen beträgt ~211 TB (grobe Umrechnung von den in der Pressemitteilung und auf der AWS-Produktseite beworbenen 192 TB). Um diese Skalierung auf Petabytes zu erreichen, muss also ein gewisses Tiering stattfinden. Mit dem Angebot wurde auch eine „intelligente Tiering“-Funktion eingeführt. Klingt einfach, aber wer mit der Standardoption „Auto-Tiering“ nicht zufrieden ist, muss das Was, Wann und Wie konfigurieren, damit Daten „intelligent“ verschoben werden.

Es scheint auch, dass das größere Volumen mit erweiterter Kapazität ein S3-Bucket ist. Okay, ein erster Realitätscheck: FSx für NetApp ONTAP skaliert nicht auf Petabytes an Speicher, wie wir uns alle die Skalierung eines Dateisystems vorstellen.  Es scheint, als ob diese Lösung eine Seite aus dem „Tape“  Hersteller Playbook nimmt und S3 als Ersatz für Tape verwendet, um Petabyte-Skalierung zu „vermarkten“. Technisch gesehen sind das Petabytes an Daten, aber die eigentliche Frage ist, wie schnell auf die Daten zugegriffen werden kann – und natürlich auch, wie schnell sie genutzt werden können. Um ehrlich zu sein, bedeutet Petabyte Scale für mich Petabyte Scale in einem Single-Namespace oder Volume. Ich meine, jede HSM-Lösung der „alten Schule“ kann sogar mehrere Zettabytes oder „praktisch unbegrenzten“ Speicherplatz für sich beanspruchen, aber die Daten befinden sich nicht unbedingt in einem Zustand, in dem man sie einfach und schnell nutzen kann. Es handelt sich eher um ein Archiv als um die intelligente Single-Namespace-Speicherlösung, die etwa Qumulo seinen Kunden bietet.  Es fühlt sich ein bisschen an wie ein Rückfall in die 1990er Jahre (ohne Vokuhila Haarstyle!)

Der zweite Realitätscheck ist der Datenzugriff. Wenn die Daten so rasch wie möglich benötigt werden, hat man dann neben der Betriebszeit auch Garantien für die Performance des Datenabrufs? Wenn es stimmt, dass der Kapazitätspool S3 ist, dann nehme ich an, dass die SLA, die ich bei meiner Suche nach „AWS S3 SLA“ gefunden habe, für diese Lösung für Kunden von FSx für NetApp ONTAP gilt. Wenn ich dies lese, sehe ich nichts über Performance-Garantien, nur über die Betriebszeit. Eine Performance-Garantie vom Kapazitätspool zum primären Volume oder Namespace ist, soweit ich das beurteilen kann, nicht bekannt. Was kann also ein Kunde, der ½ PB relativ aktiver Daten hat, tun, um zu vermeiden, dass der Kapazitätspool für diese relativ aktiven Daten belastet wird?  Nun, wer mehr als ~211 TB an Daten hat, kauft dann anscheinend zwei Instanzen von FSx für NetApp ONTAP.  Warum aber sollten Sie das tun, wenn Sie alles in einem einzigen Namespace ohne weitere Kompromisse von anderen Unternehmen bekommen können?

Es scheint auch Aufgabe des Kunden zu sein, zu definieren, wie effizient die Dateien mit De-Duplizierung und Komprimierung sein werden. Wahrscheinlich wird der NetApp oder AWS FSx-Vertreter sagen: „Das hängt ganz von Ihnen ab“, wenn er um Support gebeten wird. Das ist die Realität bei dieser Art von Technologie: Es ist wirklich ein Ratespiel, und wer daneben liegt, dessen Kosten werden höchstwahrscheinlich steigen. AWS FSx für NetApp ONTAP ist Komplexität in Reinkultur.

Intelligentes Tiering? Eine Ausrede für die Komplexisierung der Cloud

Die offene Frage, die sich mir bei dieser Lösung stellt, ist, ob NetApp seinen Kunden trotz des intelligenten Tierings“ weiterhin dringend raten wird, 80 % des Primärspeichers nicht zu überschreiten. Ich meine, das würde Sinn machen, da es sich um ONTAP handelt und ONTAP es nicht mag, wenn es zu voll wird. Wird die Performance begrenzt, werden die Tiering-Kriterien außer Kraft gesetzt und eine Massenmigration von Daten vom primären zum sekundären Speicher veranlasst, um Platz zu sparen und einen Performance-Alptraum zu vermeiden? Das ist im Moment noch nicht bekannt, aber mit dem, was ich über ONTAP weiß, würde es mich nicht überraschen, wenn genau das passiert.

Wir alle wissen, dass NetApp Performance-Probleme hat. Das ist ein inhärentes Problem bei allen Scale-up-Lösungen.  Deshalb benötigen Kunden ein skalierbares, verteiltes Dateisystem. Qumulo beispielsweise erreicht eine Leistung von bis zu 40 GB/s im Vergleich zu FSx für NetApp ONTAP mit einer Leseleistung von 2 GB/s und einer Schreibleistung von 1 GB/s. Jetzt bin ich noch neugieriger.  Beinhaltet die Leseleistung von 2 GB/s auch die Leseleistung aus dem Kapazitätspool, oder nur aus dem primären Storage-Volume auf FSx für NetApp ONTAP? Unklar, ich kann keine andere Referenz finden als die, die ich bereits oben erwähnt habe. Ich musste ein wenig suchen, um die tatsächlichen Performance-Werte zu finden. Sie waren in den FAQ vergraben.  Normalerweise möchte man seine Performance-„Helden“-Zahlen in der Ankündigung präsentieren. Aber es ist kein Wunder, dass in der Ankündigung und im Abschnitt über die Funktionen lediglich angegeben wird, dass mehrere Gigabyte an Performance erbracht werden können.

Kosten im Petabyte-Maßstab addieren

NetApp nennt in seiner Ankündigung ein Beispiel von 100 TB. Wenn man sich allerdings einen Anwendungsfall im Petabyte-Maßstab mit Daten ansieht, die man tatsächlich für Workloads wie etwa das Training von KI-Modellen, die genomische Sequenzierung oder auch die Videoproduktion verwenden muss, sprengt das Kostenmodell den Rahmen.

Hier haben wir die von NetApp veröffentlichte Berechnung auf ein Petabyte skaliert (was in NetApp nicht möglich ist, es sei denn, man möchte mehrere Volumes managen). Die Kosten liegen bei 72 TB pro Monat, und wer häufig auf seine Daten zugreifen muss (nehmen wir an, 80 % der Zeit), muss mit einem Preis von 142 TB pro Monat rechnen.

NetApp ONTAP macht die Cloud kompliziert und langsam

Wenn es einen Hinweis auf Komplexität gibt, sehen Sie sich nur die Anzahl der „Knöpfe und Regler“ an, die konfiguriert werden müssen, und die in der Folge die Kosten für Storage wie ein Lotterielos in die Höhe treiben!

Startpunkt: Umfang des Volumens

Als nächsten Schritt erstellt man ein Tiering-Profil, indem man abschätzt, wie viele Daten sich im primären Tier befinden werden (Daten mit häufigem Zugriff). Das ist der erste Kostenpunkt. Dann muss entscheiden werden, wie groß der „Kapazitätspool“ ist (Daten mit seltenem Zugriff). Das ist ein weiterer Kostenpunkt. Dann muss der Umfang der Durchsatzanforderungen festgelegt werden. Jawohl! Sie haben es erraten… ein zusätzlicher Kostenpunkt. Was ist mit Backups? Auch das ist ein Aspekt, der exakt festgelegt werden muss (und der ebenfalls Kosten verursacht). Nun: man sollten keine komplexen Entscheidungen treffen müssen im Umfang, als würden man jemanden auf den Mond schicken wollen, nur um Speicher zum Laufen zu bringen.

Das Netz auf NetApp

Der Bedarf an Datei-Services in der Cloud wächst exponentiell, und viele Kunden suchen nach Lösungen, die ihren individuellen Anforderungen gerecht werden und es darüber hinaus ermöglichen, aus dem Datacenter-Geschäft auszusteigen, damit der Fokus auf dem Kerngeschäft liegen kann. Das Problem ist, dass alte Dinosaurier wie NetApp nur ihre veraltete und komplexe Architektur in die Cloud bringen und nicht in der Lage sind, das goldene Dreigestirn aus Skalierung, Performance und Kosten zu liefern. Stattdessen sollten Kunden deshalb native Cloud-Plattformen in Erwägung ziehen, die nachweislich skalierbar und leistungsfähig sind und Kosteneffizienz im großen Maßstab bieten können.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.