Backup to Object Storage ist in aller Munde und macht natürlich auch vor NetApps ONTAP keinen Halt!
Bereits seit ONTAP 9.12.1 ist die S3 API so vollständig, dass externe Backup Programme wie Veeam & CommVault damit kompatibel sind. Im Veeam Ready Programm wurde ONTAP 9.12.1 bereits freigegeben.
Doch das wichtigste Feature im Kontext von Backup und Object Storage ist ohne Frage Object Lock und genau das hat bisher noch gefehlt. Durch Object Lock erhält man eine echte Immutable Backup Lösung, da die Backupdaten mit einem Zeitstempel versehen werden und dadurch vor versehentlichem oder absichtlichem Löschen geschützt werden.
Und genau diese Object Lock Funktionalität hält mit der Version 9.14.1 jetzt Einzug in ONTAP. Wichtig hierbei ist allerdings, dass mindestens die Version 9.14.1P1 genutzt wird, da es in der GA Version noch ein Bug gab, der die Benutzung von Object Lock mit Veeam verhinderte.
Wichtig: Offiziell ist ONTAP 9.14.1 mit Object Lock bislang nicht über das Veeam Ready Programm zertifiziert. Wir sind allerdings eng im Austausch mit NetApp und Veeam und gehen davon aus, dass dies eher noch Formsache ist. Unsere Tests im Lab sind vielversprechend.
Nun aber an die Umsetzung, wie immer gibt es ein paar technische Voraussetzungen:
- Vermutlich Veeam 12/12.1 (die Tests wurden mit 12.1.1.56 durchgeführt)
- mindestens ONTAP 9.14.1P1
- Das ONTAP System sollte grundkonfiguriert sein, also Netzwerkkonnektivität, VLANs, Aggregate etc.
- SnapLock Lizenzen (sollte mittels ONTAP ONE problemlos möglich sein)
- SnapLock Compliance Clock auf ONTAP muss initialisiert sein
1. SVM anlegen
Auch wenn wir S3 potenziell auch in einer bestehenden SVM sprechen können, empfiehlt sich definitiv eine separate SVM.Cluster::> vserver create -vserver ontap_s3_demo -rootvolume ontap_s3_demo_root -aggregate <aggr-name> -rootvolume-security-style unix
2. Netzwerk Service Policy anlegen
Da im Default keine Service Policy für das S3 Protokoll existiert, muss diese angelegt werden.Cluster::> network interface service-policy create -vserver ontap_s3_demo -policy policy_s3 -services data-core,data-s3-server
3. Netzwerk Interface anlegenCluster::> network interface create -vserver ontap_s3_demo -lif ontap_s3_demo_lif01 -home-node Node11 -home-port e0c -service-policy policy_s3 -address 10.91.81.145 -netmask 255.255.255.0
4. Route und DNS
Das Default Gateway und DNS ist meistens sinnvoll und wird daher angelegt. In Szenarien, wo der S3 Service z. B. in einem dedizierten Backup Netz ist, kann darauf auch verzichtet werden.Cluster::> route create -vserver ontap_s3_demo -destination 0.0.0.0/0 -gateway 10.91.81.1
Cluster::>
dns create -vserver
ontap_s3_demo
-domains trng.xc.au.local-name-servers
10.91.81.1
5. Zertifikat
Das S3 Protokoll spricht HTTPS und benötigt damit ein Zertifikat. Hier gibt es mehrere Möglichkeiten. Entweder man nutzt das Default SVM Zertifikat, generiert ein neues Self Signed Zertifikat oder spielt ein offiziell gültiges Zertifikat ein. In unserem Fall nehme ich das SVM Zertifikat, das ich mir im ersten Schritt mal anschaue. Den Zertifikatsnamen benötigt man im nächsten Schritt.Cluster::> security certificate show -vserver ontap_s3_demo
6. Object Store Server erstellen
Wie bei jedem Protokoll, das man im ONTAP nutzen möchte, muss man auch bei S3 den Service „erstellen“.Cluster::> vserver object-store-server create -vserver ontap_s3_demo -object-store-server ontap_s3_demo -certificate-name ontap_s3_demo_17B9D816D6FF7CB6
7. Bucket anlegen
Das Bucket enthält die eigentlichen Nutzdaten und bekommt auch die Object Storage spezifischen Eigenschaften, also z. B. ob Object Lock aktiviert ist oder nicht. Beim Erstellen des ersten Buckets in ONTAP wird im Hintergrund automatisch eine FlexGroup angelegt. FlexGroups sind die Weiterentwicklung von FlexVolumes und können einen Namespace auch über Aggregatsgrenzen erstrecken. (Weitere Buckets verwenden die vorhandene FlexGroup, max. 1000 Buckets pro FlexGroup.)Cluster::> vserver object-store-server bucket create -vserver ontap_s3_demo -bucket demo5-veeam-objectlock -retention-mode compliance -versioning-state enabled -default-retention-period none -size 800gb
Wichtig ist hier, dass Versioning aktiviert ist. Zudem darf keine Default Retention gesetzt werden – es ist üblich, dass die Backup-Software die komplette Retention verwaltet. Prinzipiell unterstützt Veeam mittlerweile auch Object Lock Governance, allerdings nur über einen RegKey. Wir empfehlen dringend Object Lock Compliance zu nutzen. Man sollte sich jedoch im Klaren darüber sein, dass auch der ONTAP Administrator die Daten nicht vor Ablauf des Timestamps löschen kann.
8. Object Storage User und Gruppe anlegen
Standardmäßig hat der User noch keine Berechtigung S3 Operationen auszuführen. Durch die Mitgliedschaft in einer Gruppe kann man dem User „SVM-weit“ Rechte geben. Daher ist es sinnvoll wie oben empfohlen eine dedizierte SVM zu erstellen.Cluster::> vserver object-store-server user create -vserver ontap_s3_demo -user veeam
Cluster::> vserver object-store-server group create -vserver ontap_s3_demo -name veeam_group -users veeam -policies FullAccess
9. Credentials anzeigen lassen
Mit „advanced“-Privileges hat man die Möglichkeit sich sowohl den Access Key als auch den Secret Key des Users anzeigen zu lassen. Diesen benötigen wir dann gleich in Veeam.Cluster::> set -privilege advanced
Cluster::>
vserver object-store-server user show -vserver ontap_s3_demo -user veeam
Ab diesem Moment ist die Arbeit auf dem ONTAP Cluster getan und wir können uns der Konfiguration in Veeam widmen.
Als Erstes legen wir ein neues Object Storage Repository an.
Dieser Schritt ist der wohl wichtigste, hier wird definiert wie lange Backups über Object Lock als immutable geflagged werden.
Nachdem wir das Repository nun angelegt haben, konfigurieren wir einen Test Job.
Der Job ist erwartungsgemäß durchgelaufen. Wenn man nun versucht, die Backup-Daten zu löschen, läuft man in einen Fehler; Object Lock greift also. An dieser Stelle nicht über das Datum wundern (oben hatten wir 7 Tage eingestellt). Unter der Haube trägt Veeam dafür Sorge, dass die Retention passt, nachlesen kann man das hier.
Das Ganze lässt sich dann natürlich auch über AWSCLI oder natürlich Tools wie den S3 Browser prüfen. Hier wird ebenso die Object Lock Compliance Eigenschaft eines exemplarisch ausgewählten Files anzeigt.
Wer sich jetzt traut, über den S3 Browser mal eine oder mehrere Dateien zu löschen, wird mit Erschrecken feststellen, dass es geht….
Warum das so ist, könnt ihr hier nachlesen.
Auch in der Veeam Community gibt es einen Thread zum Thema Object Locking Support mit ONTAP 9.14.1, also gerne mal reinschauen.