Wir haben bei uns im Lab eine der ersten Beta-Versionen von ONTAP 9.13.1 (Codename: Lighthouse) installiert. Auch wenn es diesmal für 9.13.1 keine weltbewegenden Neuigkeiten gibt, so haben wir doch ein paar der Highlights, die wir gefunden haben, herausgepickt, um sie hier kurz vorzustellen.
Sämtliche hier vorgestellten Funktionen sind direkt aus der Beta herausgefunden worden, und für keine davon gibt es von NetApp eine offizielle Bestätigung dass diese Funktion auch im 9.13.1 GA Release verfügbar sein wird. Insofern gilt für alle hier vorgestellten Punkte „keine Gewähr“.
TOTP Zwei-Faktor Authentifizierung für SSH
Bisher konnte man SSH nur bedingt mittels 2FA absichern, die einzige Möglichkeit war die Kombination aus Passwort und SSH Public/Private Keypaar.
Ab ONTAP 9.13 wird man einen klassischen TOTP Authenticator (Google Authenticator, Microsoft Authenticator, etc.) für den zweiten Faktor verwenden können.
Dazu wird für einen User als zweite Authentifizierungsmethode einfach TOTP ausgewählt:
ClusterF::*> security login create -vserver ClusterF -user-or-group-name drueing -application ssh -role admin -authentication-method password -second-authentication-method totp
Please enter a password for user 'drueing':
Please enter it again:
Warning: TOTP is initially disabled for user "drueing". To enable TOTP, user "drueing" must login and configure TOTP using the "security login totp create".Anschließend loggt man sich als der betreffende User einmal mit dem Passwort ein und schließt die TOTP Konfiguration ab:
ClusterF::*> security login totp create -vserver ClusterF -username drueing
TOTP profile information of user "drueing".
Warning: pasting the following URL into your browser exposes the OTP secret to Google:
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@Node12%3Fsecret%3DAETJIDF7ZDG45U4SURNHZZ2ZMU%26issuer%3DNode12
Your new secret key is: AETJIDF7ZDG45U4SURNHZZ2ZMU
Your verification code for code 1 is 534857
Your emergency scratch codes are:
61386064
92349487
41224566
46600427
43744348Man kann nun den angegebenen Secret Key direkt in die Authenticator-App seiner Wahl eingeben, oder über den Link einen QR-Code generieren und diesen einscannen. Dabei kann man die URL Parameter (z.B. Issuer) beliebig ändern, dieser wird 1:1 in die Authenticator-App übernommen:
Ab jetzt wird man beim Login nach dem zweiten Faktor gefragt:
login as: drueing
Keyboard-interactive authentication prompts from server:
| Password: *********
| Verification code: ******
End of keyboard-interactive prompts from server
Last login time: 3/27/2023 23:11:40
ClusterF::> S3 Object Store Lifecycle Management
Auch wenn StorageGRID immer noch die beste Wahl ist, um ein großes, geo-redundantes S3 Storage aufzubauen, besteht mit ONTAP S3 seit ein paar Versionen die Möglichkeit, auch mit einer FAS oder AFF einen einfachen S3 Objektspeicher zur Verfügung zu stellen. Dieser ist von der Funktionalität allerdings bei weitem nicht so flexibel wie die StorageGRID Produktreihe.
Trotzdem gibt es in ONTAP 9.13.1 ein paar kleine Verbesserungen, und zwar in der Form von Objekt Lifecycle Regeln.
Mit diesen Regeln kann für jeden Bucket konfiguriert werden, was mit bestimmten Objekten passieren soll, wenn diese ein gewisses Alter überschreiten. Dies kann mit einer Objektgröße kombiniert werden.
Beispielsweise können alle Objekte, die älter sind als 9 Monate sowie größer als 8MB automatisch gelöscht werden. Auch nach Tags kann gefiltert werden etc.
ClusterF::> vserver object-store-server bucket lifecycle-management-rule create ?
-vserver <vserver name> Vserver Name
[-bucket] <TextNoCase> Object Store Server Bucket Name
[-rule-id] <text (size 0..256)> Lifecycle Management Rule Identifier
[ -index <integer> ] Lifecycle Management Rule Index
[ -is-enabled {true|false} ] Is This Rule Enabled?
[ -prefix <text> ] Prefix to be Matched with Object Names
[ -tags <text>, ... ] Tags in Format <tag> or <tag=value>
[ -obj-size-greater-than {<integer>[KB|MB|GB|TB|PB]} ] Min Size of the Object
[ -obj-size-less-than {<integer>[KB|MB|GB|TB|PB]} ] Max Size of the Object
[-action] {Expiration|NoncurrentVersionExpiration| Lifecycle Management Action
AbortIncompleteMultipartUpload}
{ [ -obj-age-days <integer> ] Days after Creatin, After Which Current Version
of Objects Can be Deleted
[ -obj-exp-date <"MM/DD/YYYY HH:MM:SS"> ] Specific Date When the Objects Should Expire
[ -expired-obj-del-marker {true|false} ] Cleanup Object Delete Markers
| [ -new-non-curr-versions <integer> ] Number of Latest Non-current Versions to Be Retained
[ -non-curr-days <integer> ] Number of Days after Which Non-current Versions
will Be Deleted
| [ -after-initiation-days <integer> ] } Number of Days of Initiation, After Which
Upload Can Be AbortedSnapLock und FlexClone
Bisher konnte man zwar von SnapLock Volumes einen FlexClone anlegen, musste dabei aber insbesondere bei SnapLock Compliance aufpassen, da man den erzeugten Clone nicht mehr löschen konnte, bis alle Dateien darin abgelaufen waren.
Dies limitiert die Verwendbarkeit auf NearStore Systemen, z.B. in der „LockVault“ Variante, bei der angelegte Backups vor versehentlichem oder absichtlichen Löschen gesperrt werden sollen (um z.B. Ransomware Angriffen vorzubeugen). Möchte man eine VM aus einem SnapLock Volume wiederherstellen, so kann man nicht einfach einen Clone erzeugen und die VM direkt starten, sondern muss die VM erst zurückkopieren.
Ab ONTAP 9.13.1 kann man beim Clonen eines Volumes angeben, welchen SnapLock Status das Zielvolume besitzen soll. Somit ist es möglich, ein SnapLock Volume als reguläres Volume zu klonen, um es nach der Verwendung auch wieder löschen zu können. Dazu dient der neue Parameter -snaplock-type:
ClusterF::> volume clone create -snaplock-type ?
non-snaplock Non SnapLock
compliance SnapLock Compliance
enterprise SnapLock EnterpriseDamit ist auch der andere Weg möglich: Ein reguläres Volume als SnapLock Volume klonen, und mittels Auto-Commit sämtliche Dateien darin für einen bestimmten Zeitraum vor Änderungen oder Löschen zu schützen.
Storage Limits für SVMs
Eine weitere Neuerung dürfte für alle diejenigen hilfreich sein, die beispielsweise mittels Astra Trident automatisch Speicherplatz für Kubernetes-Cluster zur Verfügung stellen.
Dort war bisher immer eine Herausforderung „Wie stelle ich sicher, dass mein Kubernetes-Team nicht meine NetApp vollmacht?“
Vor ONTAP 9.13 musste man dort mit einer Kombination an Funktionen arbeiten, um etwa die Anzahl der Volumes für die Trident SVM zu limitieren, und im Kubernetes ein Limit auf die maximale Volume-Größe zu setzen. Dies konnte allerdings von Kubernetes-Admins problemlos wieder überschrieben werden. Eine andere Möglichkeit arbeitet mit einem maximalen Aggregats-Füllgrad, was allerdings unflexibel ist, wenn man mehrere Aggregate in Verwendung hat, und zusätzlich noch Zugriff auf die Cluster Admin SVM benötigt.
Ab ONTAP 9.13.1 kann bei einer SVM ein Storage Limit konfiguriert werden, welches den maximalen Speicherplatz dieser SVM definiert. Kurz bevor dieses Limit erreicht wird (standardmäßig bei 90%) wird ein Alarm ausgelöst, welcher im Monitoring abgefangen werden kann.
ClusterF::> vserver create -storage-limit ?
{<integer>[KB|MB|GB|TB|PB]} Storage LimitZusammenfassung
Auch wenn in 9.13.1 vermutlich nicht „das“ Killerfeature kommen wird, so gibt es doch an vielen Stellen kleine und durchaus praktische Veränderungen, von denen man profitieren kann.
Wir vermuten, dass ONTAP 9.13.1 im Sommer GA gehen wird und 9.13.1P1 dann gegen Herbst verfügbar sein wird. Unterstützte Hardware werden voraussichtlich alle Plattformen sein, die auch schon 9.12.1 unterstützen, also alles ab FAS 2700 aufwärts. Update: ONTAP 9.13.1 ist inzwischen als GA (General Availability) Release verfügbar für alle Systeme die auch ONTAP 9.12.1 unterstützen.
Matthias Beller