FlashArray: What's new for //X ? DirectMemory Cache with Intel Optane - Reduce Your SAP HANA costs

Neben dem Newcomer FlashArray //C wurde im Rahmen der Pure Storage Accelerate 2019 auch eine Neuerung für FlashArray //X vorgestellt. Um //X noch performanter zu machen, wurde eine weitere Speichertechnologie entwickelt.


Pure Storage FlashArray //X DirectMemory.

ein DirectMemory Modul (DMM)

DirectMemory basiert auf Intel Optane Technologie. Vereint mit Purity sorgt Intel Optane (3D XPoint) Storage Class Memory (SCM) für eine erhebliche Performancesteigerung, welche sich speziell bei Hochleistungsanwendungen bemerkbar macht. Die Anforderungen moderner Datenbanken und Analytics-Tools steigen stetig und verlangen immer mehr Leistung.

SCM (storage class memory) setzt neue Maßstäbe vor SLC (single-level cell)

Ein DirectMemory Modul (DMM) ist 750GB groß und dient als read-Cache. Hierbei ist wichtig zu wissen: es handelt sich um kein Tiering!

Grundsätzlich arbeitet Caching so, dass der Teil der Daten einer Anwendung, welches aktiv im Zugriff ist, das sogenannte "Working Set" ist. Diese Daten werden im sogenannten Cache gehalten, falls sie unmittelbar nach dem Schreiben oder mehrfach wiederholt bei intensiven lesenden Workloads verwendet werden.

Der Einsatz von Caching-Technologie ist jedoch in der Vergangenheit mit einigen Kompromissen verbunden gewesen. Mit dem traditionellen Caching konnten Anwendungsdaten/-IOs beschleunigt werden, aber die gelieferte Leistung und deren Informationen/Daten waren nicht konsistent. Daten, welche nicht "gecacht" sind müssen beim Zugriff aus persistentem Speicher gelesen werden, was zu einer höheren Antwortzeit führt.



Pure Storage DirectMemory Deep Dive


Ich gehe davon aus, dass bei Pure Storage DirectFlash die Daten in den DirectMemory-Modulen nicht komprimiert, so kann ein gewisser Latenzaufwand beim Lesen vermieden werden. Ich vermute dies, da die Daten nicht dauerhaft sind und die Optane-Latenz sehr niedrig ist. Die Werte sind bei einer Dekomprimierung während des Lesens sonst in meinen Augen nicht möglich. Es gibt keine Redudanz für die DirectMemory Module. Fällt ein Laufwerk aus, wird der verfügbare Cache einfach reduziert. Auch diese Designwahl (errinnert an ein RAID0) kommt der Performance zugute, da keine Paritätsberechnungen erforderlich sind (heißt nicht, dass dann ein Datenverlust entsteht, da die Daten ja noch auf DFM liegen!). Schreibvorgänge gehen nach wie vor direkt an den NVRAM, so dass DirectMemory nur die Leistung der lesenden Zugriffe verbessert: es gibt keinen Cache-Effekt auf die Schreiblatenz, die Bandbreite oder eine Erhöhung der Systemspeicherkapazität. DirectMemory verwendet einen einfachen "least recently used" (LRU) Algorithmus, dieser arbeitet nach dem Prinzip: der Eintrag, auf den am Längsten nicht zugegriffen wurde, wird verdrängt.

Weitere genutzte Algorithmen der Konkurrenz sind: "first in first out" (FIFO), "least frequently used" (LFU), Random und CLOCK.


Eine Optane SSD hat eine 10 μs Leselatenzzeit.

Eine NVMe SSD hat eine Leselatenzzeit von 100 bis 110 μs.

Das DirectFlash-Modul von Pure hat eine Latenzzeit von etwa 50 μs.

Das DirectFlash Fabric von Pure - End-to-End NVMe - hat eine Latenzzeit von 200-300 μs.

Das DMM reduziert die Latenzzeit des DirectFlash-Moduls mit einem Lesecache-Treffer von 10 μs - anstelle der 50 μs, um die Daten von DirectFlash zu erhalten, und spart so bis zu 40 μs beim Lesezugriff.


Die DirectMemory Module (DMM) von Pure Storage werden direkt in die FlashArray//X70- und //X90-Systeme gesteckt, so werden OLTP- und OLAP-Vorgänge beschleunigt. Das Ganze - wie gewöhnlich bei allen Pure Updates/Upgrades - non-disruptive (NDU), so können Unternehmen unterbrechungsfrei ohne Downtime weiterarbeiten.

Dem OLAP-Ansatz steht der traditionelle, operative OLTP-Ansatz („Online Transaction Processing“) gegenüber, wie er im relationalen Datenbankkonzept zum Ausdruck kommt. Beide Ansätze unterscheiden sich gravierend: Bei OLTP wiederholen sich die Datenbankprozesse ständig, sind strukturiert und bestehen aus isolierten, atomaren Transaktionen. Diese arbeiten mit aktuellsten Daten und greifen lesend sowie schreibend meist nur auf wenige Datensätze über Primärschlüssel zu. Bei OLAP hingegen steht die historische, aggregierte Information im Vordergrund. Die Analysen bestehen aus komplexen Abfragen, der Zugriff erfolgt meist nur lesend.

Quelle: "BI-Methoden (Teil 1): Ad-hoc Analysen mit OLAP" vom 16.04.2008 Klaus Manhart - Tecchannel

Quelle: "OLTP vs. OLAP" von DW4U - Datawarehouse4u.info


Es gibt die Module auch wieder in Form von Packs:

3 TB (4x750GB) und

6 TB (8x750GB)

DirectMemory Module werden ab Purity 5.3.1 unterstützt! Es muss also zwingend ein Upgrade auf das aktuellste Betriebssystem durchgeführt werden.

Hierbei ist wichtig zu wissen, dass das 6TB Pack nur für die //X90 vorgesehen ist. Äußerlich (nach dem Verbau im Chassis) sind DMMs nur an der silberfarbenen Entriegelung der Module erkennbar.



Wie oben angesprochen, werden Datenbanken und Unternehmensanwendungen, welche in Bezug auf Latenz und Geschwindigkeit sensibel sind, spürbar schneller. Mithilfe von Pure1 Meta Analysen konnte man feststellen, dass: 80% der Systeme eine 20% geringere Latenz beim Lesen und 40% der Systeme zwischen 30-50% erreichen.


"Erstens macht es alles schneller" ... "Zweitens sparen sie Betriebskosten. SAP HANA kann beispielsweise im Hostspeicher oder auf den DirectMemory Modulen laufen. Mit den DirectMemory Modulen erhalten Anwender 90% der Leistung des Hostspeichers, aber zu einem 65% günstigeren Preis." - Matt Kixmoeller, VP, Produkt & Solution Marketing Pure Storage

DirectMemory und SAP HANA


SAP HANA kann sich zu einer ungeplant-kostspieligen Datenbank entwickeln, insbesondere wenn ein großes Datenwachstum stattfindet. Um sicherzustellen, dass die Kosten für den Betrieb der In-Memory-Datenbank nicht "explodieren", wurde ein Verfahren/Strategie zur Auslagerung von Daten auf externe/persistent Speichermedien geschaffen. Die Methode basiert auf verschiedenen Ebenen, welches Daten nach der Regelmäßigkeit von Datenzugriffen, Kapazitäts- und Leistungsanforderungen kategorisiert.

Die erste Schicht im Modell sind sogenannte "hot data" heiße Daten, auf die häufig zugegriffen wird und die höchsten Leistungsanforderungen erfüllen müssen. Die zweite Schicht ist für "worm data" warme Daten, Daten, auf die nur selten zugegriffen wird und die geringere Leistungsanforderungen haben als heiße Daten, die aber als Kernstück der Datenbank liegen müssen.

Die dritte und letzte Stufe ist für "cold data" kalte Daten, Daten, auf die sporadisch mit geringen Leistungsanforderungen zugegriffen wird.

Die Implementierung einer solchen Datenstrategie für SAP HANA kann dazu beitragen, die Gesamtbetriebskosten (TCO) zu senken und gleichzeitig das langfristige Datenwachstum eines Unternehmens möglichst preiswert sicherzustellen.


Hot Data für SAP HANA liegen klassisch im Server-Speicher/RAM. Da hier im Regelfall immer der Datenzuwachs stattfindet, wird mehr physischer Speicher benötigt, dieser ist wiederum sehr teuer, was zu höheren Kosten der Datenbank führt. Für den Fall, dass jedoch ein Teil der Daten in der Hot Tier nicht häufig verwendet wird, könnten diese Daten zur Kapazitäts-/Kosteneinsparung durch eine Tierverlagerung in eine niedrigere Stufe eingespart werden.


Um die Vorteile von DirectMemory in SAP HANA-Umgebungen nachzuweisen, war Pure Storage einer der ersten SAP Partner, der detaillierte Tests und Analysen zur Leistung von Online Analytical Processing (OLAP)-Operationen durchführte:


Es wurde getestet:

- eine 2TB-Datenbank mit allen Tabellen im Speicher.

- eine 2TB-Datenbank mit 75% der Tabellen, die für die Verwendung von NSE * spezifiziert sind, mit FlashArray///X und Direct Memory Cache.

- eine 2TB-Datenbank mit 75% der Tabellen, die für die Verwendung von NSE * spezifiziert sind, mit FlashArray///X.

- eine 2TB-Datenbank mit 75% der Tabellen, die für die Verwendung von NSE * spezifiziert sind, mit direkt angeschlossenem Speicher.


* Native Storage Extension (NSE): Ein nativer und integrierter warmer Datenspeicher, der es ermöglicht, weniger häufig abgerufene Daten zu verwalten, indem auf sie von der Festplatte aus zugegriffen wird, im Gegensatz zu In-Memory.

Die Ergebnisse verdeutlichten:

Die beste Leistung wird mit In-Memory Daten erzielt. Dies ist auch die Variante mit dem höchsten TCO.

FlashArray///X mit DirectMemory Cache hat im Vergleich zu In-Memory Daten nur einen geringen Leistungsabfall (10%), spart aber bis zu 60% der Kosten.

FlashArray///X ist nur 15-20% langsamer als In-Memory Daten, bietet aber bis zu 75% Kosteneinsparung.

Direct Attached Storage ist 40% langsamer.

Jede Umgebung hat unterschiedliche Anforderungen. Es zeigt sich jedoch, dass FlashArray mit DirectMemory-Cache einen erheblichen Vorteil für SAP HANA-Umgebungen bietet.

Die obigen Testwerte sind nicht durch mich geprüft, jedoch sind diese ausführlichst im offiziellen Pure Storage Blogbeitrag zum Thema SAP Hana mit DirectMemory Modules nachlesbar.


Schlussworte


Die Frage, die sich bei der Entscheidung für den Einsatz eines Cache stellen muss, ist, ob die Leistungssteigerungen und die daraus resultierenden Kosten für die Anschaffung von DirectMemory und der Einsparung der TCOs in Relation stehen. Es ist kein Geheimnis, dass Optane Caching auch durch das Primera-System von HPE unterstützt wird. Der neueste PowerMax von Dell EMC verwendet ebenfalls Optane. Das Max Data-System von NetApp unterstützt auch Optane DIMMs.


Es ist noch kein offizieller Guide zum Sizing der DMMs für Pure Storage Partner/Distributoren verfügbar. Ein vollständiger Sizer wird im vierten Quartal (Q4) 2019 als internes (Pure) Tool erwartet und dann auch zeitnah im Pure1 Planning (Workload/Hardware Simulation) verfügbar sein.

Auf meine Frage: "Was geschieht mit den verleibenden DataPacks-Slots beim Einsatz von DirectMemory?" konnte (oder wollte) man mir diese nicht beantworten. Bis GA der DMM bestand ein Chassis (max. 20 DFMs) immer aus DataPacks von 10 DFMs. Nun mit DirectMemory sind pro DataPack-Slot nur 4/8 Slots belegt. Heißt im Umkehrschluss man "verschenkt" 2/6 Slots, was ich persönlich für eine Verschwendung halte. Ich bin optimistisch und denke: auch hierfür wird sich eine Lösung finden.


Zudem kam mir noch in den Kopf: was, wenn die Implementierung von SCM/DMM gleichzeitig als Test für ein zukünftiges All-SCM-FlashArray genutzt wird?!

Es bleibt spannend!


Pure Storage FlashArray //X DirectMemory ist seit der Accelerate GA und ab sofort bestellbar.


Der Blog lebt von Fragen, Wünschen und Anregungen...jeder Kommentar ist -lich willkommen. Über Feedback bin ich sehr dankbar.

0 Ansichten
SIGN UP AND STAY UPDATED!

LINKS

>> purestorage.com - Pure Storage official site

>> virtualhome.blog - focused on veeam & virtualization topics by Falko Banaszak

MAIL:

|

TEL:

|

 Amberg, Bayern, Deutschland

LOC:

© 2019 by PUREFLASH.blog

  • Twitter Marcel Düssil PUREFLASH.blog
  • LinkedIn Marcel Düssil
  • Xing Marcel Düssil
  • PUREFLASH.blog official YouTube