FlashArray und FlashBlade: Snap to NFS / Snap to FlashBlade

Mit Purity für FlashArray 5.1 wurde eine neue Funktion "Snap to NFS" released, eines der Features basierend auf der portablen Snapshot-Technologie von Pure Storage.


Dies macht die Kapselung von Metadaten zusammen mit Datenblöcken möglich, einen Snapshot eines Pure Storage FlashArray auf jedes heterogene/any vendor NFS-Speicherziel (also nicht nur Pure Storage-Technologie) übertragen und zu jedem Zeitpunkt auf einem FlashArray wiederhergestellt werden kann. Wie bereits bekannt, werden Snapshots auch für Test/Dev-Szenarien oder Klonvorgänge genutzt. Mit "Snap to NFS" wird diese Funktionalität erweitert, um Ihre Systeme nicht mit Snapshot-Kapazität zu "belagern" und diese Kapazitäten auf billigen (Tier-2/3) Storage 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.1.x) möglich.

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


Snap to NFS funktioniert agentenlos, d. h. es wird auf dem NFS-Ziel 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.


"Snap to NFS" 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


Snap to NFS 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 Snap to NFS sogenannte "Protection Groups".


Systemvoraussetzungen


Es wird ein NFS-Speichersystem benötigt, welches von jedem Hersteller sein kann, jedoch NFS Version 3 oder 4 und NLM unterstützt. Stand heute: es werden keine Windows NFS Server unterstützt.


Prinzipiell wird jeder NFS V3-V4 Speicher unterstützt, jedoch gibt es auch hier Empfehlungen: man sollte schon ausreichend Performance vorhalten.

Ein langsamer NFS Server zieht Backup und Restores in die Länge (empfohlen daher 10G-Anbindung). Der NFS Zielspeicher sollte entsprechend gegen Datenverlust z. B. durch ein RAID gesichert werden.


Der bereitgestellte NFS Share braucht Lese-/Schreib-/Ausführrechte (r/w/e), also kurz gesagt Vollzugriff.

Insofern erforderlich, kann der Zugriff auf den NFS-Share selbstverständlich auf Basis der IP-Adresse beschränkt werden.


Basis - Einrichtung


Die Initialkonfiguration muss durch den Pure Storage Support vorgenommen werden. Hierzu einfach ein Ticket erstellen (Betreff: "Pure Storage PurityRUN Snap to NFS enablement"). Im Vorfeld sollte man eine freie IP-Adresse (mit Verbindung ins Netz des NFS-Targets) 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 "Snap to NFS" 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 NFS Target / FlashBlade


In Zuge dieses Blockbeitrags verwenden wir eine FlashBlade als NFS-Speicherziel. Dieses wird über das default Data-Interface angesprochen. Man könnte hier auch überlegen, ein dediziertes virtuelles Interface in einem eigenen Netz anzulegen.


Wer diese IP-Adresse nicht zur Hand hat, kann diese über Settings > Network einfach herausfinden:

Im nächsten Schritt erstellen wir ein eigenes File System/Share als offload-Ziel. Den Share habe ich eindeutig mit dem Namen "offload-FROM-PURE-X50-2" und dem NFS Dienst ohne Zugriffsbeschränkungen (bei leer lassen der Export Rules automatisch r/w/e) erstellt.



Sollten keine Netzwerkbeschränkungen zwischen den Systemen vorliegen, ist die Vorbereitung der FlashBlade Freigabe hiermit abgeschlossen.


Konfiguration FlashArray


Einbindung Offload Target / FlashBlade


Der vorbereite Offloadspeicher muss nun noch mit dem FlashArray verbunden werden. Dies erfolgt über Storage > Array > "Connect to NFS Offload Target":

Es muss ein Alias angegeben werden: ich bin - wie immer

- auch hier ein Fan von eindeutigen Namen, daher wählte ich "offload-TO-FB-01".

Zudem muss die IP-Adresse des NFS-Targets und der Mount Point angegeben werden. Die Mount Options bleiben hier leer (mögliche Anpassung wie NFS-Version, Portnummern, R/W Blockgrößen, Protokolle (TCP/UDP)).


Beim Beispiel der verwendeten FlashBlade ist der Mount Point mit /FILE SYSTEM-Name anzugeben -> /offload-FROM-PURE-X50-2


Die Verbindung wird mit "Connect" hergestellt und das FlashArray hat eine Verbindung mit dem NFS-Ziel. Der Status wird in Purity in der Übersicht angezeigt. Bei Problemen sollte man die Erreichbarkeit zwischen den Systemen und die gesetzten Berechtigungen prüfen.



Konfiguration Snapshot-Offload-Job


Wie bereits vorhin angesprochen, basiert Snap to NFS 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 NFS-Target, Snapshot-Pläne und den Replikations-Plan.


Einrichten Protection Group



Anpassung Protection Group



Der Snapshot Plan wurde nach folgendem Muster angelegt:


alle 6 Stunden wird ein lokaler Snapshot erstellt (4 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 für "long-usage" gedacht:


alle 4 Stunden (kleinster möglicher Wert) wird geprüft, ob neue Snapshots übertragen werden müssen. Ein ausgeschlossener Zeitraum ist nicht definiert.

Auf dem NFS-Ziel verbleiben die Snapshots für 14 Tage PLUS ein täglicher Snapshot für weitere 7 Tage.

Nach Definition des Snapshot Plans wird automatisch direkt der Baseline-Snapshot gemacht, nach Abschluss werden nur noch oben angesprochene incremental-Snapshots erzeugt.


Einschränkungen


Derzeit können leider noch keine Volumes einer/s Volume Group/PODs/Containers Mitglied in einer Protection Group sein. Im Umkehrschluss können derzeit diese Volumes nicht "offloaded" werden. Ich gehe davon aus, dass diese Funktionalität zeitnah integriert wird.


Der Replikationsintervall kann zum Zeitpunkt des Blogs mit Purity 5.2.3 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.


Ich hatte hier zwei händische Snapshots erstellt. Einer mit Suffix, der andere ohne Suffix.


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 (nachfolgend: FlashBlade GUI).




NFS Snap Wiederherstellung


Sollte es nun wirklich zum Restore eines Storage Snapshots vom NFS-Speicher kommen, kann dieser Vorgang ganz einfach erledigt werden (bei "short term-Restores". Sollte der Snap lokal am FlashArray vorhanden sein, kann nicht der NFS-Snap verwendet werden (würde auch im Regelfall keinen Sinn machen). Sollte man doch vom NFS-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 NFS-Speicher. 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 NFS-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:VolumName.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 "copy-FROM-SNAP-local-VOL1".

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 NFS-Target 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 Shares sich ansehen will, kann sich den NFS-Share auch mounten (bei Windows: setzt installiertes Feature NFS-Client voraus).



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 Community


WEB: Pure Storage OFFICIAL Blog



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

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