FlashArray und Amazon AWS: Snap to AWS / CloudSnap to AWS

Aktualisiert: 8. Mai 2021

Wie in meinem Beitrag "FlashArray und FlashBlade: Snap to NFS / Snap to Flashblade" vom 17. August 2019 bereits das Thema Snapshot-Auslagerung auf NFS-Speicher vorgestellt wurde, wurde mit Purity 5.2 die Funktion "Snap to AWS" released, ein weiteres Features basierend auf der portablen Snapshot-Technologie von Pure Storage. Mit dem aktuellsten Purity 5.3 wurde zusätzlich die Funktionalität für Microsoft Azure Blob erweitert.


CloudSnap funktioniert wie Snap to NFS, einziger Unterschied: die Schnittstelle ist eine Andere.


Wie bereits bekannt, werden Snapshots auch für Test/Dev-Szenarien oder Klonvorgänge genutzt. Mit "CloudSnap" wird diese Funktionalität erweitert, um Ihre Systeme nicht mit Snapshot-Kapazität zu "belagern" und diese Kapazitäten auf billigen Cloudspeicher auszulagern. Die übertragenen Snapshots liegen komprimiert (nicht dedupliziert), aber in einem nicht direkt lesbaren Benutzer-/Anwendungsformat vor. Es wird jedoch ein FlashArray System benötigt um Snapshots wiederherzustellen. Eine Wiederherstellung ist also auch auf jedes x-beliebige unterstützte FlashArray-System (auch anderes Modell, aber min. Purity 5.2) möglich.

Für die Nutzung dieser Funktionalität gilt wie immer: keine zusätzlichen Softwarelizenzen/Kosten.


CloudSnap funktioniert ebenfalls agentenlos, d. h. es wird in der AWS keine Pure Software benötigt. Die Datenkompression erfolgt bereits während der Übertragung, spart Netzwerkbandbreite und erhöht die Effizienz des Ziels. Nach der Initialübertragung der Baseline werden nur noch Deltas der nachfolgenden Volumesnaps (inkrementeller Snapshot) übertragen, dieser Prozess des Abgleichs erfolgt innerhalb Puritys.


Bei einer Wiederherstellung weiß Purity bereits, welche Datenblöcke auf dem FlashArray vorhanden sind und muss nur veränderte/fehlende Blöcke transferieren. Ebenso werden deduplizierungsoptimierte Wiederherstellungen durchgeführt, heißt: wiederhergestellte Daten vom Offload-Ziel werden direkt beim Transfer dedupliziert und belegen so keinen wertvollen Platz.


"CloudSnap" ist eine App/Integration welche in den "Köpfen" der FlashArray-Controller betrieben wird - bekannt als PurityRUN. Der dafür benötigte Overhead ist minimal und hat keinen großen Einfluss (max. 10% der Performance) auf den primären Storagetraffic.

Es wird eine Reservierung (mit geringerer Prio) von 4-8 Cores und 8-16 GB RAM angelegt. Sollte der Load am System einen einwandfreien Betrieb des Front-IO-Traffics nicht mehr gewährleisten können, werden die PurityRUN Funktionalitäten gedrosselt.


Die Praxis


CloudSnap kann über die FlashArray GUI oder die CLI gemanagt, aber auch durch Pure1 gemonitored werden. Selbstverständlich können über die REST API auch unterstützte Tool Vorgänge in die Arrays steuern.


Ähnlich wie die asynchrone Pure Storage Replikation verwendet CloudSnap sogenannte "Protection Groups".


Systemvoraussetzungen


Es wird ein dedizierter Amazon AWS S3 Bucket benötigt. Dediziert im Sinne: es dürfen keine weiteren Daten enthalten sein, welche nicht mit CloudSnap in Verwendung sind.


Limitierungen


Ärgerlich für mich an dieser Stelle war es, das Purity derzeit maximal ein offload Target zulässt. Hieß im Umkehrschluss für mich, ich musste mein Snap to NFS-Ziel trennen. Die Grenzwerte für die maximale Auslagerung an Volume Snapshots sollte mit 100 000 kein Problem darstellen. An ein offload Target können derzeit 4 * FlashArrays maximal verbunden werden.


* 2 FlashArrays für Backup und Restore + 2 FlashArrays für reinen Restore.


Basis - Einrichtung


Die Initialkonfiguration muss durch den Pure Storage Support vorgenommen werden. Hierzu einfach ein Ticket erstellen (Betreff: "Pure Storage PurityRUN CloudSnap enablement"). Im Vorfeld sollte man eine freie IP-Adresse (mit Verbindung ins Netz) vorbereiten. Diese IP-Adresse braucht der Support für die Einrichtung des Offloads.


Nach der Aktivierung des Remote Assist/RA kann der Supportmitarbeiter nun die Konfiguration vornehmen. Die vorbereitete IP-Adresse wird als virtuelles Interface über ein Replikationsinterface beider Controller (ct0-eth2, ct1-eth2) gelegt. Hierbei ist wichtig zu wissen: dies hat keinen Einfluss auf den Betrieb von Funktionalitäten wie ActiveCluster!

Abschließend müssen beide Controller nacheinander (keine Downtime) durchgestartet werden und "CloudSnap" ist vollständig nutzbar.



INFO: seit Purity 5.2.0 ist PurityRUN* bereits default aktiv und enthält vorbereitete, jedoch aber deaktivierte Apps. Es werden also keine Ressourcen (bei Nichtnutzung) verschwendet.


Im Reiter Settings > Software > App Catalog werden im Standard zwei vorbereitete Apps angezeigt. Man kann diese jedoch installieren, aber nicht konfigurieren.



PurityRUN* = eine KVM-Virtualisierungsplattform zur Bereitstellung von Integrationen/Apps auf dem Pure Storage System

Konfiguration AWS


Die Einrichtung des AWS Buckets geht schnell von statten, wer die Funktion lediglich testen möchte, kann vom Amazon Free AWS für 1 Jahr Gebrauch machen.


Anmeldung an AWS


Zuerst melden wir uns an der AWS-Managementkonsole an und wechseln in das AWS S3 Konsole Dashboard.




Erstellung Bucket


Im Dashboard klicken wir auf "Bucket erstellen" und folgen dem Wizard. Es muss ein Name für den Bucket vergeben werden und die Region des AWS Rechenzentrums. Hier ist es empfehlenswert immer kürzeste Wege zu nehmen (insofern keine Geoabsicherung erfolgen soll).

Ich verwende wie immer eindeutige Namen "offloadtoawsfrankfurt" für die Erstellung und Identifizierung.