How to avoid/cleanup „_1“,“_2″… volume names in NetApp OnCommand on secondary storage systems

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 teamix GmbH tätig. Seine Kernthemen sind VMware, sowie NetApp (bis 2015). Seit 2005 ist er in sämtlichen Projektgrößen und -komplexitätsstufen als Consultant, Systems Engineer & Trainer unterwegs. Seit 2014 gehören auch Datacenter Produkte rund um die Hersteller Trend Micro & Citrix zu seinem Aufgabengebiet. In den Jahren 2015 & 2016 wurde er für seine Blog-Aktivitäten zum VMware vExpert ernannt.

 
Kommentare

Noch keine Kommentare vorhanden.

Hinterlassen Sie einen Kommentar