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.
Im Anschluss muss die Verschlüsselung für diesen Bucket aktiviert werden. Dieser Schritt ist zwingend für die einwandfreie Konfiguration von CloudSnap erforderlich. Diese Anpassung erfolgt auf dem Bucket selbst unter "Eigentschaften" > "Standardverschlüsselung". AES-256 als Verschlüsselung ist hingegen zu AWS-KMS kostenlos.
Die Bucketkonfiguration ist an für sich hiermit abgeschlossen. Wichtig ist an dieser Stelle: "mehr - default - ist manchmal mehr". Es dürfen auf keinen Fall "Lifecyle Regeln" und eine Veröffentlichung des Buckets stattfinden, um die Funktion und Sicherheit sicherzustellen.
AWS-Benutzererstellung
Es muss nun, um die AWS-Konfiguration abzuschließen noch ein entsprechender Benutzer mit Zugriff auf den Bucket erstellt werden. Die Benutzeradministration von AWS erfolgt über das "IAM" und kann über die Suche aufgerufen werden:
Ich erstellte mir den Benutzer "purebucketuser-PURE-X50-2" mit "Programmgesteuerter Zugriff" und weise ihm aus den Standard-Richtlinien die Richtlinie "AmazonS3FullAccess" zu. Für Arrays, welche nur restoren, sollten ReadOnly-Rechte ausreichend sein. Alle weiteren Einstellungen beließ ich auf den Standardwerten.
Mit "Benutzer erstellen" wird der Benutzer angelegt und die Zugangsdaten generiert. Man kann diese als CSV (was ich für die spätere Verwendung empfehle) exportieren und an einem gesicherten Speicherort ablegen.
Für die spätere Verwendung relevant ist: der "Access key", der "Secret access key" und der Bucketname.
Konfiguration FlashArray
Einbindung Offload Target / FlashBlade
Der vorbereite AWS-Bucket muss nun noch mit dem FlashArray verbunden werden. Dies erfolgt über Storage > Array > "+":
Es muss ein Alias angegeben werden: ich bin - wie immer - auch hier ein Fan von eindeutigen Namen, daher wählte ich den festgelegten Bucketnamen aus "offloadtoawsfrankfurt". Den Access Key und Secret Access Key entnehme ich der zuvor exportierten CSV. Der Bucketname ist aus der S3 AWS Console auslesbar.
Insofern der Bucket noch nicht für CloudSnap verwendet wurde, kann dieser mit der Checkbox "initialize bucket as offload target" dafür vorbereitet werden. Die Placement Strategy steht in Auswahlmöglichkeiten zur Verfügung:
aws-standard-class: mit dieser Option werden alle Offloads auf S3 Standard-Speicher ausgelagert.
retention-based: mit dieser Option werden alle Offloads entweder auf S3 Standard-Speicher oder S3 "kalten"-infrequent Speicher abgelegt. Diese Option hängt von den jeweils definierten Werten der Protection Groups in Purity ab. "retention-based" Speicher ist auch als S3-IA bekannt. Alle Snapshots welche im Ziel länger als > 30 Tage aufbewahrt werden, werden in S3-IA Speicher platziert.
unchanged: mit dieser Option MUSS fortgefahren werden, wenn man sich zu einem bereits bestehenden S3 Bucket verbindet, welcher bereits mit Purity genutzt wurde.
Die Verbindung wird mit "Connect" hergestellt und das FlashArray hat eine Verbindung mit dem Bucket. Der Status wird in Purity in der Übersicht angezeigt. Bei Problemen sollte man die Erreichbarkeit zwischen den Systemen und die gesetzten Berechtigungen prüfen.
Der angegebene S3 Bucket wird zuerst gescannt, sollten bereits Snapshots erkannt werden, werden diese in Purity sichtbar.
Konfiguration Snapshot-Offload-Job
Wie bereits vorhin angesprochen, basiert CloudSnap auf Protection Groups. Alle Volumes innerhalb einer Protection Groups (nachfolgend PGROUP genannt) können an ein/oder mehrere definierte(s) Ziele repliziert werden. Innerhalb einer PGROUP können Volumes, Snapshot-Pläne, Replikations-Ziele/Pläne/-Zeiträume/-Fenster definiert werden.
Daher erstellen wir als Erstes eine neue PGROUP über Storage > Protection Groups > Create Protection Group (PGROUP darf nicht Mitglied eines Containers sein) mit einem eindeutigen Namen: "PGROUP-offload-TO-FB-01".
Anschließend definieren wir die zu replizierenden Volumes, das CloudSnap-Target, Snapshot-Pläne und den Replikations-Plan.
Einrichten Protection Group
Anpassung Protection Group
Der Snapshot Plan wurde nach folgendem Muster angelegt:
alle 15 Minuten wird ein lokaler Snapshot erstellt (96 Snapshots täglich), welcher für einen Tag auf der Quelle/FlashArray verbleibt. Wiederum ein täglicher Snapshot verbleibt weitere 7 Tage am lokalen System.
Auf dem FlashArray verbleiben also nur wenige "short-usage" Snapshots.
Der Replikationsplan hingegen ist eigentlich für "long-usage" gedacht - aufgrund des AWS Free-Accounts wurde keine längere Retention gewählt:
alle 4 Stunden (kleinster möglicher Wert) wird geprüft, ob neue Snapshots übertragen werden müssen. Im Bucket verbleiben die Snapshots für 1 Tage PLUS ein täglicher Snapshot für weitere 7 Tage.
Nach Definition des Snapshot Plans wird automatisch der Baseline-Snapshot gemacht, nach Abschluss werden nur noch oben angesprochene incremental-Snapshots erzeugt.
Einschränkungen
Der Replikationsintervall kann zum Zeitpunkt des Blogs mit Purity 5.3.1 nicht kleiner 4 Stunden gestellt werden.
Händische/Manuelle Backups
Unabhängig von den geplanten Snapshot- und Replikationspläne können jederzeit nach Bedarf PGROUP-Snapshots erzeugt und repliziert werden. Hierzu wechselt man in die jeweilige PGROUP (Storage > Protection Groups) und erstellt über "+" einen Snapshot. Hierbei kann optional ein Suffix erzeugt werden, angepasst werden, ob der Snapshot in den regulären PGROUP-Snap-Intervall einbezogen werden soll und ob dieser repliziert werden soll.
Monitoring
Neben der FlashArray GUI kann man die Snapshots und Offloadvorgänge einfach über Pure1 monitoren. Im Register > Snapshots kann man über die Timeline alle Snaps auflisten und erhält alle relevanten Informationen (Größe, Target, Erstellungszeitpunkt ...).
Es ist ebenfalls möglich bei mehreren Systemen mit Filtern zu arbeiten und auf alle verfügbaren Kategorien granular herunterzubrechen.
Über die Registerkarte Protection > Protection Groups und die Timeline der jeweiligen PGROUP ist es möglich, sich weitere Informationen zu einem Snapshot/PGROUP anzuzeigen.
Statistiken wie Latenzen, IOPS und Bandbreite können Sie entweder über Pure1 einsehen, oder wie gewöhnlich auf den FlashSystemen selbst.
(die Screenshots dieses Abschnitts "Monitoring" stammen aus dem Beitrag zum Thema Snap to NFS, aber unterscheiden sich nur in den Bezeichnungen und nicht der Funktionsweise mit CloudSnap.)
AWS Snap Wiederherstellung
Sollte es nun wirklich zum Restore eines Storage Snapshots vom Bucket kommen, kann dieser Vorgang ganz einfach erledigt werden (bei "short term-Restores". Sollte der Snap lokal am FlashArray vorhanden sein, kann nicht der AWS-Snap verwendet werden (würde auch im Regelfall keinen Sinn machen). Sollte man doch vom AWS-Target wiederherstellen müssen, muss der lokale Snapshot zuvor entfernt (mit der Option "immediate") werden.
Der Wiederherstellungs-Prozess sieht wie folgt aus:
1. Wiederherstellung des Snapshots vom Bucket. Im Hintergrund wird eine lokale Kopie des Snapshots auf dem FlashArray angelegt.
2. Kopieren des lokalen Snapshots auf ein neues Volume oder Überschreibung eines vorhandenen Volumes.
3. Verbinden des Volumes mit dem Host und Zugriff auf die Daten.
"Let's restore"
Wir wechseln nach Storage > Array > Offload Targets und wählen das jeweilige AWS-Target aus:
Innerhalb des Targets sehen wir die darin enthaltenen Snapshots und können per Klick auf den Download Button eine Kopie des Volumes (optionale Eingabe eines Suffixes) herstellen. Bei dem automatischen Suffix wird das Volume nach folgendem Namensmuster kopiert: SourceArrayName:ProtectionGroupName.VolumeName.restore-of.SnapshotName.
Das Backupvolume finden wir dann unter: Storage > Volumes.
Nun können wir das Volume kopieren oder direkt das Ursprungsvolume überschreiben lassen.
Zuerst lassen wir uns eine Kopie des Snapshots erstellen, hierbei muss ein Volumename und ein Container (optional) angegeben werden. Zudem kann man mit "overwrite" ggf. bestehende Volumes überschreiben lassen. Ich wählte als Volumename "Restore-FROM-AWS".
Anschließend könnte man das Volume direkt mit einem Host verbinden.
Beim Restore eines Snapshots hat man keine Möglichkeit Einstellungen anzupassen, sondern das Volume wird einfach unwiderruflich überschrieben.
Im Anschluss kann dieses Volume direkt mit einem Host/Hosts verbunden werden.
Die Snapshotkopie wird NICHT automatisch entfernt. Dieser Vorgang muss manuell durchgeführt werden. Die Kopie wird hierbei nicht vom Bucket entfernt. Die Löschung erfolgt nur innerhalb des lokalen FlashArrays und wird (ganz regulär) für 24h im Papierkorb vorbehalten.
Wer die Inhalte des Buckets sich ansehen will, kann sich über die AWS S3 Konsole eine einfach Übersicht machen. Die Ordnerstruktur verwaltet Purity selbst und darf keinesfalls modifiziert werden oder durch manuelle Löschungen Speicher zurückgewonnen werden.
Weitere Infos - Links
Sämtliche offiziell veröffentlichten Einstellungsmöglichkeiten in der GUI, aber auch CLI können über die "on-board" User Guides der Pure Storage Systeme nachgelesen werden.
Im Purity Hauptmenü hierzu auf "Help" klicken.
Der User Guide ist wie das Hauptmenü gegliedert und kann von Ebene zu Ebene geöffnet werden. Eine Suchfunktion ist auch integriert - hier kann mit Schlagworten gesucht werden.
WEB: Pure Storage (Pure1) Supportportal - Ticketsystem und Unterstützung *(erfordert registrierte FlashSysteme)
TEL: Pure Storage Telefonsupport: GER - (+49) (0)800 7239467; INTERNATIONAL - (+1) 650 7294088
WEB: Pure Storage OFFICIAL Blog