Alle Artikel unter dem Schlagwort Ontap

In diesem Artikel eine Beschreibung, wie man es schafft, dass nach einem SMVI-Snapshot automatisch ein SnapVault auf eine Backupsite getriggert wird. Ebenso ist in diesem Beitrag ein Sample-Skript zu finden, ebenso der Hinweis, wo man das entsprechende Log-File findet, um das Konstrukt zu troubleshooten.

How to SMVI & SnapVault

  • 01. Die SnapVault Basisbeziehung für das gewünschte vSphere-Volume aufbauen. Siehe Punkte 01 – 06 auf Seite https://blog.proact.de/2011/08/26/how-to-netapp-snapvault/
    • -> Ziel: der Abgleich zwischen Primär- und Backupstorage funktioniert reibungslos, SnapVault-Beziehung aufgebaut.
  • 02. NetApp Virtual Storage Console (inkl. Backup & Recovery = SMVI) installieren und wie gewohnt den Backupjob für den/die entsprechenden Datastores anlegen
  • 03. SMVI-Job einmal manuell starten und prüfen, dass dieser funktioniert
    • -> Ziel: SMVI-Snapshots werden sauber auf dem Primärstorage erzeugt, Snap Schedule und Retention Time der Snapshots auf dem Primärstorage werden von SMVI verwaltet
  • 04. Auf dem Backupstorage (SnapVault Destination) die Anzahl der vorzuhaltenden Snaphots definieren
    • -> Ziel: Wie viele Snapshots sollen auf der Backupsite aufgehoben werden

Beispiel:

Wir möchten von einem vSphere Store mit Namen „nfs_store_01“, eine Snapshotschedule mit dem Namen „smvi_nfs_store_01_daily“ (der Backupjob im SMVI wurde mit Namen „nfs_store_01_daily“ erstellt) anlegen, welche 14 Snapshots auf dem Backupsystem vorhalten soll

snapvault snap sched nfs_store_01 smvi_nfs_store_01_daily 14@-

–> Wir haben eine lauffähige Snapshot Schedule und konsistente vSphere-Datastore-Snapshots auf der Primärseite durch den SMVI, eine funktionierende SnapVault Beziehung und eine definierte Anzahl an aufzuhebenden Snapshots auf der Backupseite.

AND NOW: BRING IT ALL TOGETHER!

  • 05. Download der SnapVault/SMVI Executables von der NetApp Community (Achtung: Anmelden nicht vergessen!)
  • 06. Datei entpacken und auf auf dem Server, auf dem die Virtual Storage Console installiert wurde, einen Ordner anlegen (i.d.R. vCenter Server) und die sv-smvi.exe und sv-smvi.pl darin ablegen
    • C:\Program Files\NetApp\SV-SMVI\
  • 07. Ablegen der sv-smvi.cmd aus der zip-Datei auf dem vCenter Server in das Skript-Verzeichnis des SMVI
    • (Bei der Konfiguration eines SMVI-Backupjobs gibt es den Punkt „Scripts“. Damit in diesem Menüpunkt Skripte ausgewählt werden können, müssen diese im folgenden Ordner abgelegt werden)

Default Path:
C:\Program Files\NetApp\Virtual Storage Console\smvi\server\scripts

  • 08. Verschlüsseltes Passwort für root bzw. Backupuser generieren (der User, mit dem sich das Skript in die primäre und Backup-NetApp einloggen soll. Befehl in einer cmd ausführen)
    • C:\Program Files\NetApp\SV-SMVI\sv-smvi.exe -cryptpasswd
  • 09. Kennwort notieren
  • 10. Anpassen der sv-smvi.cmd an ihre Storageumgebung

Beispiel-cmd:
set TEMP=C:\Temp
set TMP=C:\Temp
„C:\Program Files\NetApp\SV-SMVI\sv-smvi.exe“ -svip STORAGE-IP -svuser NETAPPLOGONUSER -svcryptpasswd GENERIERTES-PASSWORT

Wichtige Hinweise

Temp-Variable muss für den ausführenden User auf dem vCenter Server gesetzt sein, ansonsten TEMP-Variablen wie im Beispiel-Skript setzen. Variable „-svip“ muss eine IP-Adresse sein, die von vCenter erreichbar ist, da hierüber die ZAPI-Aufrufe laufen. Die „-svip“ kann pro cmd immer nur auf ein Storage verweisen, somit muss für jeden per SMVI zu sichernden Head ein Skript angelegt werden. Hierfür einfach mehrere cmd’s anlegen.

  • 11. Die cmd-Datei als Skript mit in die SMVI-Backupjobs aufnehmen (im SMVI – „Edit Backup“ und dann die, dem zu sichernden Head entsprechende Skriptdatei hinzufügen)
  • 12. Damit die Zapi-Aufrufe auf der Primary- und der Backup-NetApp funktionieren, muss der http-Admin-Zugriff auf diesen Systemen (sowohl Source als auch Destination) freigeschaltet sein bzw. freigeschaltet werden:
    • options httpd.admin.enable on
    • Wichtiger Hinweis:
    • Laut der Community und deren Manual-Beschreibung soll https möglich sein, in der aktuellen Version der Datei sv-smvi.exe (3.0.2) fehlt aber dieser optionale Schalter! Somit funktioniert derzeit nur http.
  • 13. Den abgeänderten SMVI-Job mit der integrierten Skriptdatei manuell anstarten und prüfen, ob alles sauber funktioniert.
  • 14. Sollte irgendetwas nicht laufen, kann im SMVI-Log geprüft werden, wo es vielleicht noch „hackt“…
    • Default Log Path SMVI, wenn mit NetApp Virtual Storage Console installiert:
    • C:\Program Files\NetApp\Virtual Storage Console\smvi\server\log\

Quick and simple. Have fun.. 🙂

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

How to NetApp NDMP

Kategorien: mynetapp.de
Kommentare: No

NDMP auf der NetApp einrichten. Seeeehr einfach… Hier wird erläutert, wie es geht.

WICHTIGE HINWEISE

NDMP ist ein in jeder NetApp kostenfrei integriertes Protokoll.
Viele Backupsoftwarehersteller benötigen für ein NDMP-Backup extra Lizenzen. Bitte vorab prüfen, welche Lizenzen auf Backupsoftware-Seite fällig werden.

How to NDMP

  • 01. NDMP aktivieren
    • ndmpd on
  • 02. Library physikalisch anschließen
    • Tapelibrary an einen freien Initiator-Port anschließen, evtl. mit fcadmin den Port auf „Initiator“ umstellen
  • 03. Prüfen, dass Library und Tapes an NetApp erkannt werden
    • sysconfig -m (zeigt die erkannten Loader an)
    • sysconfig -t (zeigt die erkannten Tapes an)
  • 04. Backupuser auf der NetApp einrichten
    • useradmin user add USERNAME -g „Backup Operators“
    • Passwort angeben
  • 05. NDMP Kennwort generieren
    • ndmpd password USERNAME
  • 06. das generierte Kennwort „…….“ (16-stellig) aus der Ausgabe aufnotieren
  • 07. NDMP Zugriff einschränken, so dass nur der Backupserver auf NetApp mit NDMP zugreifen darf
    • options ndmpd.access host=“Backupservername“
  • 08. Netapp in die Backupsoftware einbinden mit USERNAME und generiertem NDMP-Kennwort

Quick and simple… 🙂

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

How to NetApp Snapvault

Kategorien: mynetapp.de
Kommentare: No

In meiner Q&S-Serie möchte ich mit kurzen knackigen CLI-Befehlen aufzeigen, wie man ohne großen Aufwand einzelne Lösungsanforderungen mit NetApp realisieren kann. In diesem Beitrag heute: „How to SnapVault“.

Dies dient als Orientierung für Neueinsteiger und als kleine Core-Command-Sammlung für Erfahrene. Alles basiert auf Beispielen und hat keinen Anspruch auf 100%ige Vollständigkeit…

  • 01. Lizenz auf Source and Destination Filer einspielen
    • license add XXXXX
  • 02. SnapVault auf beiden Filern aktivieren
    • options snapvault.enable on
  • 03. NDMP auf beiden Filern aktivieren (optional)
    • ndmpd on
  • 04. Zugriff erlauben auf Source & Destination Filer
    • options snapvault.access „host=XXXXX“
    • (muss auflösbar sein, auf der Source den Destination Filer und auf dem Destination Filer den Source Filer angeben)
    • oder einfach, wenn jeder alles darf:
    • options snapvault.access all
  • 05. Volume auf der Destination Site anlegen, auf die gesnapvaultet werden soll
  • 06. Basisinitialisierung vom Destination Filer aus starten
    • snapvault start -S systemA:/vol/volxx/qtree /vol/volxx/qtree
    • (qtree auf Destination-Site muss nicht vorhanden sein, nur das Volume)
  • 07. Oh da ging was schief…. SnapVault löschen von SnapVault Secondary (Destination Filer)
    • snapvault stop /vol/volxx/qtree
    • snapvault release sec_qtree_path prim_system:prim_qtree_path
  • 08. Alle Standard Snapshot Schedules auf den Filer-Volumes deaktivieren (Source und Destination Filer)
    • snap sched VOLNAME 0 0 0
  • 09. Alle alten Snapshots bereinigen (Source und Destination Filer)
    • snap delete VOLNAME SNAPNAME
  • 10. Snap Reserve anpassen (je nachdem, wie viel mit Snapvault vorgehalten werden soll (Source und Destination Filer)
    • snap reserve VOLNAME 30
    • (in diesem Beispiel 30%)
  • 11. Snapshotschedules auf Primärseite festlegen (Produktivsystem = Primary)

Beispiele

  • 12. SnapVault Primary Snapshot Schedule weekly (2 Snapshots, jeden Sonntag, 0 Uhr)
    • snapvault snap sched volxx sv_weekly 2@sun@0
  • 13. SnapVault Primary Snapshot Schedule nightly (12 Snapshots, Montag bis Samstag, 0 Uhr)
    • snapvault snap sched volxx sv_nightly 12@mon-sat@0
  • 14. SnapVault Primary Snapshot Schedule hourly (46 Snapshots, Montag bis Sonntag, jede Stunde, quasi 2 Tage jede Stunde zurück)
    • snapvault snap sched volxx sv_hourly 46@mon-sun@1-23
  • 15. Snapshotschedules auf Backupsite festlegen (Backupsystem = Secundary)

Beispiele basierend auf Pkt. 12 bis 15:

  • 16. SnapVault Secondary Snapshot Schedule mit Abgleich Primary Schedule weekly (16 Wochen Vorhaltezeit)
    • snapvault snap sched -x volxx sv_weekly 16@sun@0
  • 17. SnapVault Secondary Snapshot Schedule mit Abgleich Primary Schedule nightly (16 Wochen jeden Tag Restore möglich)
    • snapvault snap sched -x volxx sv_nightly 96@mon-sat@0

Im Unternehmen ist keine 2. NetApp vorhanden, um die Vorteile von SnapVault nutzen zu können?

Ein Beispiel-Szenario:
Irgendwann läuft die „Alte“ aus dem Service und muss erneuert werden. Nicht einfach wegwerfen. Neue NetApp erwerben, sowie eine SnapVault-Lizenz für die „Alte“ und die „Neue“, Produktivdaten auf die „Neue“, Backup einrichten in Richtung „Alte“ 😉

Quick and simple…

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

How to NetApp SnapMirror

Kategorien: mynetapp.de
Kommentare: No

Dieser Artikel beleuchtet das Thema „How to SnapMirror“. Er dient als Orientierung für Neueinsteiger und als kleine Core-Command-Sammlung für Erfahrene. Alles basiert auf Beispielen und hat keinen Anspruch auf 100%ige Vollständigkeit… Alle Erläuterungen beziehen sich auf einen Volume SnapMirror.

Wichtiger Hinweis:
Vol-Snapmirror funktioniert nicht zwischen Trad- und Flexible-Volumes und nicht zwischen 32- und 64-bit Aggregaten. Ebenso sollte gewährleistet sein, dass die Destination immer auf der gleichen oder einer höheren Ontap-Version läuft als die Source. Qtree-SnapMirror überwindet diese Grenzen und verwendet statt der Volume-Pfade einfach Qtree-Pfade (Befehle wie in diesem Q&S, Pfadangaben wie in Artikel „Q&S – SnapVault“)

  • 01. SnapMirror Lizenz auf Source und Destination einspielen
    • license add XXXX
  • 02. SnapMirror auf Source- und Destination-Filer aktivieren
    • options snapmirror.enable on
  • 03. Auf dem Sourcefiler den Zugriff auf den Destination-Filer und auf dem Dest-Filer den Zugriff auf den Source-Filer erlauben (Vorgehen siehe auch Q&S – SnapVault)
    • options snapmirror.access „host=xxx“ (muss auflösbar sein)
    • oder jeder darf überall hin spiegeln
    • options snapmirror.access all
  • 04. Zielvolume auf Spiegelseite anlegen
    • vol create volxx
  • 05. Qtrees Security Style des Zielvolumes anpassen
    • qtree security xxx xxx
  • 06. Zielvolume restricten
    • vol restrict volxx
  • 07. Basisinitialisierung des SnapMirrors vom Destination-Filer aus starten
    • (erste Übertragung startet sofort, Aufpassen auf Storage und Netzauslastung, sowie Snapshot-Reserven)
    • snapmirror initialize -S sourcefiler:sourcevol destfiler:destvol
  • 08. Permanente Replikation einrichten auf dem Destination-Filer
    • (das angegebene File per CIFS-Share oder mit wrfile auf der CLI editieren)
    • /etc/snapmirror.conf
  • 09. folgende Zeilen für eine entsprechende Replikations-Schedule in die /etc/snapmirror.conf einfügen
    • (Scheduleerläuterung: „minute“ „hour“ „day_of_month“ „day_of_week“)
  • 10. Beispielhaftes Update des initialen Spiegels jede Nacht 0:00 Uhr
    • sourcefiler:sourcevol destfiler:destvol – 0 0 * *
  • 11. Beispielhaftes Update des initialen Spiegels zu jeder Stunde
    • sourcefiler:sourcevol destfiler:destvol – 0 * * *
  • 12. Beispielhaftes Update des initialen Spiegels jeden Sa+So, 0:00 Uhr
    • sourcefiler:sourcevol destfiler:destvol – 0 0 * 6,7

Replication works….

Weitere Commands to know:

  • 13. Wie kann ich den Spiegel manuell updaten? (Befehl auf der Destination ausführen)
    • snapmirror update -S sourcefiler:sourcevol destvol
    • (normalerweise reicht sogar nur die Angabe des Destination-Volumes)
  • 14. Ich möchte einen laufenden SnapMirror abbrechen… (Befehl auf der Destination ausführen)
    • snapmiror abort destvol
  • 15. Wann sind meine SnapMirrors zum letzten Mal gelaufen, wie ist deren Status bei der Übertragung?
    • snapmirror status
  • 16. Ich möchte das gespiegelte Volume online nehmen und beschreibbar machen = Spiegel brechen (auf Destination)
    • snapmirror break destvol
  • 17. Ich möchte die Schedule kurz aussetzen bzw. möchte sichergehen, dass erst einmal keine SnapMirrors mehr laufen (Destination)
    • snapmirror quiesce destvol
  • 18. Wie bekomme ich den SnapMirror „wieder in die Schedule, nachdem ich gequiesced habe? (Destination)
    • snapmirror resume destvol
  • 19. Wie kann ich die SnapMirror Beziehung endgültig auflösen, damit diese endgültig weg ist (Destination)
    • snapmirror release destvol
    • oder
    • /etc/snapmirror.conf entsprechend editieren und die entsprechenden Zeilen für den entsprechenden Spiegel entfernen

Quick and simple asynchronous replication with snapmirror… 🙂

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

Für alle die nicht wissen was es mit diesem „alignment“ überhaupt auf sich hat, kann ich folgendes White Paper von NetApp sehr empfehlen. Es behandelt übrigens auch ausführlich die Korrektur der Ausrichtung.. http://media.netapp.com/documents/tr-3747.pdf

Um nun herauszufinden welche LUN(s) Problem(e) machen, braucht ihr zunächst ein ONTAP in einer Verison größer oder gleich 7.2.1.

Anschließend müsst ihr in den Diagnose-Modus wechseln, welcher eigentlich nur für NetApp-Mitarbeiter ist. Seid euch hier halt bitte bewusst, dass ihr in diesem Modus durchaus einigen Schaden anrichten könnt wenn ihr nicht genau wisst was ihr macht.
filer> priv set diag

Nun fangen wir an Daten über die LUNs auf dem System zu sammeln:
filer*> stats start lun

Lasst das ganze nun einige Sekunden/Minuten laufen. Je nach Auslastung kann es etwas dauern bis ihr ausreichend Daten habt. Ca. eine Minute ist aber ein guter Richtwert.

Wenn Ihr genug Daten habt, stopt die Messung und lasst euch die Ergebnisse ausgeben:
filer*> stats stop

Wenn ihr zum Beispiel eine LUN /vol/volume/lun.0 habt könnte die Ausgabe wie folgt aussehen:
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.0:100%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.1:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.2:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.3:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.4:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.5:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.6:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_align_histo.7:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.0:90%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.1:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.2:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.3:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.4:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.5:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.6:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_align_histo.7:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:read_partial_blocks:0%
lun:/vol/volume/lun.0 : HnX3/JH-uqpl:write_partial_blocks:10%

Die Werte „read_align_histo“ und „write_align_histo“ sagen nun vereinfacht gesagt aus, wieviele LUN-Reads/Writes auf wieviele WAFL-Reads/Writes verteilt wurden. Wenn der Prozentsatz bei .0 (also 0 Operationen mehr als nötig) sehr hoch ist, dürfte das Alignment passen – wenn sich die anderen Zähler hervortuen habt ihr ein sicheres Zeichen für misalignment.

Wenn ihr genau hingesehen habt, ist euch sicher aufgefallen das bei den schreibenden Operationen ca. 10% als partial_blocks, also nicht volle Blöcke geschrieben wurden. Dies sagt nur aus, das 10% der geschrieben Blöcke keine vollen 4k (bzw. kein Vielfaches von 4k) waren, sondern etwas weniger Byte..

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

Wer kennt das nicht: Daten werden per SnapMirror auf eine andere Physik migriert und nachdem man zum Zwecke der Arbeitszeitoptimierung alle SnapMirror-Beziehungen gleichzeitig gestartet hat, bekommen die User, welche auf dem Primär oder Sekundärsystem arbeiten, die hohe Last durch weniger Durchsatz bzw. höhere Latenzen direkt zu spüren.

Natuerlich kann man jetzt mit „snapmirror throttle“ einzelne Verbindungen reglementieren, was aber wenn es sich um einige zig SnapMirror-Beziehungen handelt?

Hier helfen die weithin unbekannten Optionen:
# replication.throttle.enable
# replication.throttle.incoming.max_kbs
# replication.throttle.outgoing.max_kbs

Die Namen sind soweit bezeichnend, dass es hier nur weniger erläuternder Worte bedarf:
1.) Es gilt für SnapMirror und(!) SnapVault
2.) kbs bedeutet KiloBitperSecond
3.) Der Wert bezieht sich auf die Netzbandbreite, sprich wenn die SnapMirror Compression angeschaltet wird (neues Feature in 7.3.2), kann es durchaus höhere Netto-Übertragunsgraten geben.

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

Wenn aus RAM plötzlich RAMsch wird…

Kategorien: mynetapp.de
Kommentare: No

Man kennt das: spontan crashende Rechner haben oft defektes oder schlechtes RAM als Ursache. Auf den NetApp Systemen ist das Problem bedingt durch die Verwendung Chipkill-ECC RAM nicht so gravierend, da bei defekten Zellen einfach einzelne Chips ausgeblendet werden und ECC meistens für die Fehlerkorrektur sorgt, so dass das System einfach weiterläuft.

Aber wenn einfach alles weiter funktioniert, wie merkt man dann, dass man schlechtes RAM („RAMsch“) hat? Das System triggert bei dieser Gelegenheit keinen Autosupport, die bequeme Variante entfällt also auch… Trotzdem hilft der Autosupport in diesem Fall weiter. In der ASUP Mail einfach ‚mal nach „ECC MEMORY SCRUBBER STATS“ suchen (alles groß):

===== ECC MEMORY SCRUBBER STATS =====

Main memory
-----------
Scrub range: 100000 --> 480000000
Current scrub is 0% complete
Last full scrub completed at: Thu Oct 8 13:11:22 CEST 2009 Main
memory ECC errors since last reboot: 492

Die letzte Zeile ist entscheidende Hinweis. Um dann mehr Details zu bekommen, geht man in das CLI und setzt folgende Befehle ab:

Filer> priv set advanced
Filer*> memerr
Correctable ECC memory errors:
Errors on DIMM 1: 0
Errors on DIMM 2: 0
Errors on DIMM 3: 0
Errors on DIMM 4: 0
Errors on DIMM 5: 0
Errors on DIMM 6: 0
Errors on DIMM 7: 492
Errors on DIMM 8: 0
Errors on DIMM 9: 0
Errors on DIMM 10: 0
Errors on DIMM 11: 0
Errors on DIMM 12: 0
Errors on DIMM 13: 0
Errors on DIMM 14: 0
Errors on DIMM 15: 0
Errors on DIMM 16: 0
Multiple errors at the same address; replace DIMM 7 soon.

Und so sieht man dann, dass in diesem System DIMM7 ausgetauscht werden sollte.

Frohes Durchforsten der ASUPs… 😉

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

Manchmal benötigt man auf einem Volume Snapshots welche zeitlich weniger als eine Stunde auseinander sind, z.B. wenn es um sehr flüchtige oder sicherheitskritische Daten geht.

Dieses Problem kann man zum einen dadurch lösen, dass scriptgesteuert Snapshots generiert werden oder alternativ dazu auch mit dem normalen Scheduler. Die Syntax hierfür ist:

snap sched <volume> <weekly> <daily> <hourly>@<time_of_day> <minutly>@<minute_of_hour>

Beispiel

snap sched vol0 0 0 24 6@5,15,25,35,45,55

Hält 24 „hourlys“ vor, welche immer um zur vollen Stunde generiert werden und 6 minuetliche, welche zur
Minute 5, 15,25, 35, 45 und 55 einer Stunde generiert werden.

Wichtig: Diese Snapshot sind selbstverständliche nicht applikationskonsistent, so wie alle nicht durch SnapManager
erzeugte Snapshots.

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.

Gerade wenn weitere Disks zu einem Aggregat hinzugekommen sind oder auch wenn mit sehr vollen Aggregaten gearbeitet wird, kann es passieren, dass die Verteilung der Datenblöcke auf den Disks nicht gerade optimal ist.

Dann besteht die Möglichkeit manuell das WAFL-Dateisystem zu rearrangieren und somit wieder in einen optimalen Zustand zu versetzen.

Zuerst sollte man jedoch mit „priv set diag“ und „wafl scan measure_layout VOLUME“ überprüfen ob dies notwendig ist. Das Überprüfen des Layouts kann je nach Volumegrösse sehr lange dauern. Ihr findet dann im Log-file (syslog oder „rdfile /etc/messages„) einen Wert. Ist dieser schlecht kann mit „wafl scan reallocate VOLUME“ eine „Defragmentierung“ per Hand angestossen werden.

Da der Snapshot bei Netapp ja die „heilige Kuh“ ist, werden Blöcke aus Snapshots nicht mit optimiert. Dies hat zur Folge, dass zum einen die (Lese)Performance von Snapshots nicht optimiert wird, zum anderen aber auch, dass Snapshots, welche vor dem Reallocate erstellt wurden mehr Platz benötigen.

Zum gelegentlichen Kontrollieren bietet sich das Kommando „wafl scan status„.

Vorsicht: Die oben angegeben Kommandos haben, während sie laufen, einen negativen Einfluss auf die Gesamtperformance des Systems!

Autor: mynetapp.de
MyNetApp war unsere deutschsprachige NetApp Community Plattform, welche wir von 2007 bis 2019 betrieben haben. Im Zuge der Konsolidierung von Plattformen haben wir die Artikel in unser Proact Blog integriert.