Alle Artikel unter dem Schlagwort NetApp

In diesem Artikel möchte ich euch die Einrichtung von NetApp SnapManager SQL näher bringen. Ebenso wird in diesem Artikel die Integration in NetApp OnCommand erläutert, damit automatisiert über eine Protection Policy nach einem erfolgreichen lokalen Backup automatisiert ein SnapVault auf eine Secondary NetApp getriggert wird.

Folgende Konfigurationsschritte werden beschrieben:

  1. Anlegen einer Protection Policy in OnCommand
  2. Installation SnapManager SQL
  3. Initial Wizard SnapManager SQL
  4. Konfiguration des OnCommand Datasets für SnapManager SQL
  5. Anlegen eines Full Backup Jobs im SnapManager SQL

Weiterlesen

Autor: Benjamin Ulsamer
Benjamin Ulsamer ist seit Januar 2011 für die Firma Proact Deutschland GmbH tätig. Er startete als Senior Consultant & Trainer und war Teamlead im Bereich Virtualisierung. Im Oktober 2015 wurde er zum Manager Professional Services Region South ernannt. Seit Juni 2017 ist er verantwortlich für die IT-Ausbildung. In den Jahren 2015, 2016 und 2017 hat er für sein Engagement bzgl. Blogging & Wissensvermittlung von VMware die Auszeichnung zum vExpert erhalten. Seit 2021 ist er zudem mit verantwortlich für das Marketing von Proact.

Troubleshooting: OnCommand Core

Die OnCommand Installationen kommen nun in ein „gewisses“ Alter und nun läuft das SSL-Zertifikat ab. Somit kann keine Kommunikation mehr zwischen den Host Packages der VCenter und dem OnCommand Core stattfinden. Leider ist aus der Fehlermeldung auf die Schnelle nicht zu sehen, dass es sich um ein abgelaufenes Zertifikat handelt.

Im OnCommand erscheint nur diese Fehlermeldung:

SSL1

Weiterlesen

Autor: Matthias Kellerer
Matthias Kellerer ist seit Oktober 2013 für die Firma Proact Deutschland tätig. Sein Fokus liegt hauptsächlich auf NetApp Hard- und Software, die angrenzenden Themen Virtualisierung und Netzwerk sind für Ihn dabei auch kein Neuland.

Nach dem ersten Teil Sicheres Löschen von Daten und Festplatten, der die rechtliche Lage beleuchtet, folgt heute der zweite Teil, der erklärt, wie es bei NetApp Systemen umgesetzt wird.

NetApp Systeme bieten den Vorteil, dass sie die Löschvorrichtung für Festplatten schon mitbringen. Dieser Vorgang nennt sich Sanitize (engl. für Desinfizieren). Dabei werden die Festplatten vollständig mit einem Muster oder Zufallsdaten überschrieben.

Einige Systeme benötigen eine spezielle Lizenz für den den Sanitize-Vorgang, diese ist jedoch kostenfrei erhältlich. Daher bietet es sich an, NetApp Festplatten direkt dort zu löschen.

Um Festplatten direkt auf einem NetApp-System zu löschen, müssen diese zuerst als Spare-Platten im System angemeldet sein. Weiterlesen

Autor: M. B.
M.B. war bis 2012 bei Proact Deutschland als Produktmanager für die Backup-as-a-Service Produktreihe "FlexVault" um alle Belange der Datensicherung. Zuvor war er technischer Leiter eines großen Nürnberger Datacenters und kennt daher die Sorgen und Nöte der IT-Leiter und Administratoren bestens.

Bereits mehrfach ist es in Kundenprojekten vorgekommen, dass für den Aufbau und Betrieb von SnapMirror DR Beziehungen oder SnapVault Beziehungen NetApp OnCommand Protection Policies mit Secondary Provisioning Policies verwendet werden.

Beim Hinzufügen eines Primärvolumes zu einem SnapVault- bzw. SnapMirror-protected Dataset wird automatisch ein Zielvolume auf Basis der eingestellen Secondary Provisioning Policy erstellt. Gerne verwendet man die Variable %V, damit das Zielvolume automatisch den Namen des Quellvolumes erhält.

Weiterlesen

Autor: Benjamin Ulsamer
Benjamin Ulsamer ist seit Januar 2011 für die Firma Proact Deutschland GmbH tätig. Er startete als Senior Consultant & Trainer und war Teamlead im Bereich Virtualisierung. Im Oktober 2015 wurde er zum Manager Professional Services Region South ernannt. Seit Juni 2017 ist er verantwortlich für die IT-Ausbildung. In den Jahren 2015, 2016 und 2017 hat er für sein Engagement bzgl. Blogging & Wissensvermittlung von VMware die Auszeichnung zum vExpert erhalten. Seit 2021 ist er zudem mit verantwortlich für das Marketing von Proact.
This entry is part [part not set] of 2 in the series OnCommand Management Suite

Der heutige Blog-Post ist der Start einer mehrteiligen Serie über selten genutzte Produkte der OnCommand Suite, den Anfang macht die Software OnCommand Balance (ehemals Akorri BalancePoint oder OnCommand Insight Balance) für das Monitoring Ihrer Infrastruktur mit einem hohen Anteil an virtualisierten Systemen. OnCommand Balance unterstützt den Administrator bei der täglichen Arbeit indem die Zusammenhänge zwischen NetApp-Storage, ESXi-Umgebungen und den einzelnen virtuellen oder physikalischen Servern übersichtlich dargestellt werden, entweder in der OnCommand Balance Web-GUI oder direkt im vSphere-Client durch ein mitgeliefertes, optionales Plugin. Weiterlesen

Autor: Bernd Löhlein
Bernd Löhlein ist seit Ende 2010 für die Firma Proact Deutschland aktiv. Sein Fokus liegt hauptsächlich auf NetApp Hard- und Software, die angrenzenden Themen Virtualisierung und Netzwerk sind für Ihn dabei auch kein Neuland. Neben den üblichen Consulting-Einsätzen ist er auch noch als Trainer im NetApp Umfeld aktiv.

Wichtiger Hinweis

Dieser Artikel beleuchtet das Thema „How to SnapLock Enterprise“. Er dient als Orientierung für Neueinsteiger und als kleine Core-Command-Sammlung für Erfahrene, wie man mit NetApp SnapLock ein Disk-basierendes WORM-Archiv aufbauen kann. Alles basiert auf einem Beispiel und hat keinen Anspruch auf 100%ige Vollständigkeit…
Im SnapLock Umfeld sind viele Befehle nur einmalig ausführbar bzw. gewisse Aktionen nur schwer rückgängig zu machen. Bei der Einrichtung von SnapLock ist somit äußerste Vorsicht geboten!

Aggregatsdesign

Soll SnapLock intergriert werden, muss ein eigenes Aggregat als SnapLock Enterprise Aggregat konfiguriert werden (zusätzlich zum standardmäßigen „root“-Aggregat oder vorhandenen „Standard“ Aggregaten).
Soll die Möglichkeit bestehen, dass ein Administrator in diesem SnapLock Enterprise Aggregat bzw. Volume einzelne Files löschen kann (bei SnapLock Enterprise möglich), kann optional ein weiteres Aggregat mit eigenen Festplatten für ein sog. SnapLock Logvolume (Protokolliert die Löschaktionen) angelegt werden.
Das Aggregat, auf dem das „Logvolume“ abgelegt wird, muss als SnapLock Compliance Aggregat angelegt werden (nicht veränderbar).
Logging ist kein MUSS, um SnapLock Enterprise zu integrieren, es KANN integriert werden, wenn ein Administrator einzelne Files in einem SnapLock Enterprise Volume löschen können soll.

How to SnapLock Enterprise:

  • 01. Lizenz auf den entsprechenden Controllern einspielen (bei HA-Clustern auf beiden Heads)
    • Für SnapLock gibt es von NetApp sog. Master-Keys, die auf jedem Storage-System eingespielt werden können.
    • Hier findet man den SnapLock Enterprise
      • (https://support.netapp.com/NOW/knowledge/docs/olio/guides/snaplock_enterprise/license.shtml)
    • bzw. den SnapLock Compliance Key
      • (https://support.netapp.com/NOW/knowledge/docs/olio/guides/snaplock_compliance/license.shtml)
    • und spielt die entsprechende Lizenz mit folgendem Befehl ein:
      • „license add LICENSEKEY“
  • 02. Zeit auf den Filern richtig setzen und kontrollieren
    • „timezone Europe/Berlin“
    • „date“
  • 03. Compliance Clock initialisieren (hier muss die Uhrzeit auf dem Storage – siehe 02. – zu 100% passen, da dieser Vorgang die „Compliance Clock“ setzt und nur einmalig ausgeführt werden kann!)
    • „date -c initialize“
    • (in Ontap 8.1) „snaplock clock initialize“
      • 04. CHECK: Prüfen, welche Zeit die Systemclock (und später die Volumeclocks) haben
    • „snaplock clock status [VOLNAME]“
  • 05. SnapLock Enterprise Aggregat anlegen
    • „aggr create SLEAGGRNAME -L enterprise [-t raid4] ANZAHLDISKS“
    • (+ wenn nötig weitere Aggregatsoptionen -> alle Optionen durch Eingabe von „aggr create“ einsehbar)
  • 06. SnapLock Enterprise Volume in diesem Aggregat anlegen und weitere Einstellungen für dieses Volume wie gewohnt vornehmen (Snap Reserve, Snapshot Schedule, Deduplizierung)
    • „vol create SLEVOLNAME -s none SLEAGGRNAME XXXg“
    • „snap reserve SLEVOLNAME X“
    • „snap sched SLEVOLNAME X X X“
    • „sis on /vol/SLEVOLNAME“
  • 07. Default-, Mindest- und Maimal-Retentiontime für das Volume einstellen (d = day, m = month, y = years)
    • „vol options SLEVOLNAME snaplock_default_period“ (in SnapLock Enterprise ist hier default: die „minimum_period“)
    • „vol options SLEVOLNAME snaplock_minimum_period“ (in SnapLock Enterprise ist hier default: 0d)
    • „vol options SLEVOLNAME snaplock_maximum_period“ (in SnapLock Enterprise ist hier default: 30y)
  • 08. CHECK: Prüfen, welche „Retentiontimes“ auf dem Volume sind
    • „vol status -w“
  • 09. Eventuell muss nach Vorgabe der Archivierungssoftware ein Autocommit konfiguriert werden (nach Zeit x wird ein geschriebenes File im SnapLock Volume automatisch auf „Read-Only“ gesetzt)
    • Beispiel für ein „Autocommit“ nach 14 Tagen:
    • „vol options SLEVOLNAME snaplock_autocommit_period 14d“
  • 10. CHECK: Prüfen, welche Autocommit-Zeit auf dem Volume eingestellt ist
    • „vol options SLEVOLNAME“
  • 11. CIFS Share bzw. NFS Export für den Zugriff der Archivsoftware auf das SnapLockvolume mit den entsprechenden von der Archivsoftware geforderten Berechtigungen einrichten und an die Archivsoftware verbinden

Optionales Logging und Löschoption


!ACHTUNG: LOGVOLUME MUSS AUF COMPLIANCE AGGREGAT LIEGEN! Compliance Lizenz einspielen & Compliance Aggregat anlegen!

  • 12. Logvolume anlegen und weitere Einstellungen für dieses Volume wie gewohnt vornehmen (Snap Reserve, Snapshot Schedule, Deduplizierung)
    • „vol create LOGVOLNAME -s none COMPLIANCEAGGR XXXg“
    • „snap reserve LOGVOLNAME X“
    • „snap sched LOGVOLNAME X X X“
  • 13. Logvolume festlegen (default: 6 Monate Log Retention)
    • „snaplock log volume LOGVOLNAME“
  • 14. Einstellen, dass ein Administrator Dateien löschen darf
    • „snaplock options SLEVOLNAME privdel on“ (bei Enterprise default: off
  • 15. Der Administrator kann dann im „Notfall“ einzelne Files mit folgendem Befehl aus dem SnapLock Enterprise Volume löschen
    • „snaplock privdel -f PFAD_ZUM_ZU_LÖSCHENDEN_OBJEKT“

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.

Hi an die NetApp-OnCommand-/Backup-/Restore-Front, nachdem sich viele nicht die „Mühe“ machen, die OnCommand Datenbank auf eine eigene LUN zu legen und sich somit standardmäßig den Weg „verbauen“ mit der Snapshot-Technologie mehrfach täglich die Datenbank von OnCommand zu sichern (da „archive“ Backup maximal täglich funktioniert), hier ein kleiner „Workaround“…

Standardmäßig ist es wie erwähnt nur möglich mit den sog. „Archive“-Backups 1x am Tag zu sichern.
Der Trick sind einfach ein paar geplante Tasks auf dem OnCommand Server, die die Backupschedule einfach weiter drehen…

In meinem Beispiel sollen um 11.00 Uhr und um 23.00 Uhr Datenbankbackups auf die lokale Disk des OnCommand laufen:

Geplanter Task 1 – läuft täglich um 10.00 Uhr auf dem DFM-Server:
# Schedule auf 11.00 Uhr setzen
dfm backup schedule set -t archive -D 11:00
# Schedule enablen
dfm backup schedule enable
# Backupverzeichnis festlegen (Achtung: wenn bereits Backups vorhanden, alle in diesen Ordner kopieren)
dfm option set databaseBackupDir=C:\dfmbackup
# Backup Retention festlegen
dfm option set backupRetentionCount=14

Geplanter Task 2 – läuft täglich um 22.00 Uhr auf dem DFM-Server:
# Schedule auf 23.00 Uhr setzen
dfm backup schedule set -t archive -D 23:00
# Schedule enablen
dfm backup schedule enable
# Backupverzeichnis festlegen (Achtung: wenn bereits Backups vorhanden, alle in diesen Ordner kopieren)
dfm option set databaseBackupDir=C:\dfmbackup
# Backup Retention festlegen
dfm option set backupRetentionCount=14

Mit diesem Workaround ist es möglich, mehrere Archivebackups zu fahren.

Dies löst allerdings nicht das Problem, dass man beim databaseBackupDir keinen Netzwerkpfad angeben kann.
Ich habe es auf alle erdenklichen Weisen versucht – Netzlaufwerk direkt, Netzlaufwerk mit Unterordner, DirectoryLink gemountet in das Homedrive von Windows uvm. – allerdings immer ohne Erfolg… Die Knowledge-Base von Netapp hat auch nichts passendes zu bieten…
An dieser Stelle kann man dann darüber philosophieren, wie man die DB-Backups noch auf eine Backupseite bekommt…

Mögliche Varianten:

  • 01. Für Skriptfreunde:
    • die DB-Backup-Files aus OnCommand per klassischem robocopy oder Skript wegsichern
  • 02. für die Old-Schooler:
    • die DB-Backup-Files aus OnCommand per klassischer Backupsoftware auf Tape abziehen
  • 03. für die modernen Verrückten:
    • OnCommand als virtuelle Maschine aufsetzen und sich selbst nach dem DB-Backup per HostPackage auf ein zweites Storage sichern lassen – am besten in einem Dataset, dass von OnCommand selbst verwaltet wird
    • PS: extreeeeem coole Sache 😉
  • 04. für die Wissenschaftler:
    • OSSV auf den OnCommand Server und die Files per OSSV vom OnCommand auf ein weiteres Storage sichern
    • PS: Ob das geht, konnte ich noch nicht testen, hört sich aber spaßig an 🙂
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.

Seit der VMWare ESX Version 5.x gibt es die Möglichkeit, VAAI Thin Provisioning Block Space Reclamation (UNMAP) zu verwenden. In der Version 5.x gibt es aber Probleme beim Absetzen des Kommandos. Deshalb hat VMWare empfohlen, das UNMAP Kommando zu deaktivieren. Es wird auch bei Einspielen des Patches ESXi500-201112001 oder ESXi 5.0 Update 1 per default deaktiviert.

Das Problem dabei:
Dieses Feature wird dafür verwendet, dem Storage bei Thin Provisioned LUNs (ISCSI oder FC) mitzuteilen, welche VM-Blöcke wieder freigegeben werden können.

Sprich:
Ist dieses Feature disabled und es wird z.B. ein Storage VMotion angestoßen oder eine VM im entsprechenden Datastore gelöscht, so wird zwar im VI-Client der freie Speicherplatz angezeigt, allerdings nicht auf dem Storage freigegeben… Siehe Befehl auf der NetApp: „lun show -v /vol/volname/lunname“ -> Feld: Occupied Size

Die Gefahr:
Das Storage läuft voll…
Und dann schlägt irgendwann hoffentlich das Monitoring zu…
Und dann? Wie bekomme ich denn Platz wieder frei…?!?

VMWare hat die Möglichkeit geschaffen, manuell diesen „Space Reclaim“ abzusetzen:
Man wechselt hierfür auf der ESXi CLI in den entsprechenden Datastore („cd /vmfs/volumes/datastorename“)
und gibt folgenden Befehl ein „vmkfstools -y Prozentzahl“

Zur Erklärung:
Wird z.B. „vmkfstools -y 60“ angegeben, so verwendet VMWare ein temporäres File „.vmfsBalloontsWt8w“ im Datastore, um Space zu reclaimen. Die Größe des Files ist immer „Angegebene Prozent nach dem -y vom freien verbleibenden Speicherplatz im Datastore. Sind z.B. 10GB im Datastore noch nicht belegt und man gibt „60“ ein, wird versucht 6GB an Platz freizugeben und temporär für diese Operation ein 6GB File angelegt. Sind in diesem Beispiel im Storage weniger als 6GB zu „reclaimen“ wird natürlich nur das reclaimed, was möglich ist…

Mit „esxtop“ kann man den „delete“ Vorgang monitoren:
Im esxtop kommt man mit „u“ in die Disk Ansicht. Dort kann man mit „f“ weitere Felder einblenden.
Die Felder „o“ und „p“ können hinzugefügt werden und man sieht nach drücken von „ESC“ die entsprechenden VAAI-Statistiken. (Spalten evtl. noch mit „o“ sortieren).
In den Spaten „DELETE“, „DELETE_F“, „MBDEL/s“ sollten aktive Werte zu sehen sein…

Prüft man dann auf dem Storage System mit „lun show -v /vol/volname/lunname“ die „Occupied Size“, sollte (wenn Platz freigegeben werden kann) der Wert gesunken sein…

ACHTUNG:
Das Ausführen des Befehls kann erhöhte IO-Last auf dem Storage erzeugen, deshalb nur mit Vorsicht zu genießen!
Bitte erst auf einem Testdatastore überprüfen, ob die Space Reclamation funktioniert und wie sie funktioniert!
-> VM auf Testdatastore mit Storage VMotion verschieben
-> danach wieder mit Storage VMotion verschieben
-> prüfen, was der VI-Client anzeigt und was ein lun -v anzeigt
-> mit vmkfstools vertraut machen und Space reclaimen
-> ab gehts auf die produktiven Datastores

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.

Während meines Besuches des Data ONTAP 8.1 Cluster-Mode Administration Kurses bei der qSkills GmbH, habe ich die wichtigsten Befehle für die Administration eines ONTAP 8.1 Cluster Mode Clusters zusammengefasst.

Die Befehlssammlung umfasst über 200 Beispielbefehle mit kurzen Erläuterungen, was diese tun.
Sie erklärt nicht, wie welche Befehle in welcher logischen Reihenfolge durchgeführt werden müssen. Sie soll als „Nachschlagewerk“ dienen falls man mit der Tab-Completion im Cluster Mode nicht lange suchen möchte bzw. nachschlagen möchte, wie ein Befehl aus dem gewohnten 7-Mode im Cluster-Mode aussieht. 🙂 Sie ersetzt keinesfalls eine vollwertige Schulung.

Die Sammlung enthält Befehle aus den Bereichen Aggregate, Autosupport, CIFS, Cluster, Steuerungl, Disk, DNS, Export-Policy, FlexClone, ISCSI, Jobs, Lizenzen, LUN, Manual, Name mapping, NDMP, Netzwerk, NFS, Qtree, Quota, Routing, SnapDrive, Snapshot, SNMP, Storage Efficiency, Storage Failover, System, Zeit, Troubleshooting, Volume und vserver.

Die Befehlssammlung kann unter
http://people.teamix.net/~bu/81ClusterModeCLReference/CLI-Commands-NetApp-81-Cluster-Mode.pdf heruntergeladen werden.

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.

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.