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.
Nun kann es allerdings passieren, dass man im Nachhinein noch einmal das Dataset ändern möchte bzw. neu- / umbauen muss. Baut OnCommand über die Secondary Provisioning Policy dann erneut die Beziehung auf, kann es passieren, dass trotz gelöschtem Zielvolume in der OnCommand Datenbank das Volume noch vorhanden ist. Somit wird das neue Volume mit dem Namen VOLNAME_1 angelegt. Ändert man das Dataset noch einmal ab, ergibt es VOLNAME_2 usw. Das ist unschön und vor allem bei SnapMirror Desaster Sites sehr fahrlässig, wenn automatische Scripte dann auf der Destination das Quellsystem 1:1 nachkonfigurieren sollen oder z.B. eine nachgelagerte Tapesoftware direkt den 1:1 Volumenamen sichern soll.
Hier die Schritte, wie man die _1 Volumes vermeiden kann bzw. dafür sorgen kann, dass die OnCommand Datenbank / Inventory sauber ist:
01. betroffenes Volume im OnCommand aus dem Dataset nehmen (Quellvolume, das protected werden soll / in neues Dataset soll / neu initialisiert werden soll)
02. das automatisiert angelegte Volume auf dem Destination Netapp Storage löschen (über CLI: „vol offline„, „vol destroy„)
03. von OnCommand erstellte Snapshots auf dem Volume, welches auf dem Source NetApp Storage liegt, bereinigen (über CLI: „snap delete„, „snap delete -a„)
Zwischenstand: Volume ist nicht mehr in OnCommand Dataset, auf der Source NetApp ist das Volume noch vorhanden, Snapshots bereinigt, Beziehungen sind aufgelöst, die Destination NetApp ist aufgeräumt (in den GUIs sieht alles „dufte“ aus)
04. auf dem OnCommand Core Server eine CLI („cmd“) öffnen
05. mit „dfpm relationship list“ prüfen, ob die Beziehung des Volumes aufgelöst ist
06. sollte dies nicht der Fall sein (OnCommand Server hat noch nicht erkannt, dass die Beziehung auf den Storages nicht mehr vorhanden ist), dann mit „dfm host discover SOURCENETAPPNAME“ und „dfm host discover DESTNETAPPNAME“ aktuelle Informationen der Storages in OnCommand einlesen -> Beziehung sollte aufgelöst sein
07. mit „dfbm secondary volume list“ das von OnCommand automatisiert angelegte Volume auffinden, ID notieren und mit „dfbm secondary volume delete ID“ löschen -> in OnCommand Datenbank keine Info mehr zu dem Volume im dfbm und dfpm
08. mit „dfm volume list“ das automatisiert angelegt Volume finden, ID notieren und mit „dfm volume delete ID“ löschen
Achtung: Volume scheint komplett aus dfm bereinigt zu sein, allerdings ist das Objekt nur als „deleted“ markiert und nicht komplett aus der OnCommand Datenbank entfernt!
09. mit „dfm volume list -a“ ist das Volume noch zu sehen (zeigt auch die „deleted“ Volumes an), ID des Volumes notieren
10. alle DFM Services mit dem Befehl „dfm service stop“ stoppen -> Achtung: jetzt sollte OnCommand nicht gerade Backups oder Restores fahren! Diesen und die folgenden Schritte in einer möglichen „Downtime“ erledigen
11. mit „dfm service start sql“ den DFM Sybase ASA Dienst starten
12. mit „dfm volume delete -f ID“ das Volume endgültig aus OnCommand entfernen
13. alle weiteren Services von OnCommand in folgender Reihenfolge wieder anstarten: DFM WebUI (webui), DFM Apache (http), DFM Event (eventd), DFM Monitor (monitor), DFM Scheduler (scheduler), DFM Server (server), DFM Watchdog (watchdog)
Ergebnis: OnCommand Datenbank ist sauber und alle Services laufen wieder
14. Primary Volume, das wieder ge-snapvaulted / mirrored werden soll, wieder ins Dataset mit entsprechend hinterlegter Protection- und Secondary Provisioning Policy sortieren
15. Goes (= Läuft) 😉
Anmerkung: Alle diese Schritte wurden unter OnCommand Core Version 5.2 durchgeführt. Wie es in älteren Versionen aussieht, konnte ich leider nicht testen…
– I wish I could be a Virtual Machine –
Benjamin Ulsamer
Senior Consultat & Trainer
teamix GmbH
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.
