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:
Wir nutzen intern und auch für Kunden die Backup-Lösung CrashPlanPRO, da diese ein kontinuierliches Backup wichtiger Anwender-Daten im Hintergrund ermöglicht. Den CrashPlanPRO-Client gibt es auch für Linux. Nun hat allerdings die Linux-Variante ein Problem auf aktuelleren Linux-Distributionen: Die grafische Oberfläche CrashPlanDesktop stürzt beim Start ab.
Glücklicherweise gibt die Protokoll-Datei ui_output.log – bei einer systemweiten Installation des Client üblicherweise in /usr/local/crashplan/log – Aufschluß über die Fehlerursache:
|
1 2 |
# Problematic frame: # C [libsoup-2.4.so.1+0x6ec71] soup_session_feature_detach+0x11 |
Also ein Problem in Zusammenhang mit der Bibliothek libsoup. Der Name der Bibliothek war der Schlüssel dazu, einen Workaround zu finden.
So gibt es in dem entsprechenden Fehlerbericht #705420 für Debian den Hinweis auf CrashPlan. Den eigentlichen Workaround beschreibt der Hersteller Code42 in einem Support-Artikel. Demnach ist es erforderlich, den Variablen mit den Start-Optionen in der Konfigurationsdatei run.conf, die sich bei einer systemweiten Installation üblicherweise in /usr/local/crashplan/bin befindet, die Option -Dorg.eclipse.swt.browser.DefaultType=mozilla für den Standard-Browser hinzuzufügen. Das ganze sieht dann so aus:
|
1 2 3 |
ms@mango:/usr/local/crashplan/bin> cat run.conf SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Dorg.eclipse.swt.browser.DefaultType=mozilla" GUI_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanDesktop -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Dorg.eclipse.swt.browser.DefaultType=mozilla" |
Laut Code42 handelt es sich um einen Fehler in der Bibliothek. Die Eclipse-Entwickler sehen das anders und behoben den Fehler in der Anwendung . So oder so: Mit dem Workaround hat die aktuelle Version von CrashPlanPROe 3.6.1.4 gerade das Backup der nicht auf einem NFS-Mount befindlichen Workstation-Daten abgeschlossen.
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:
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.
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.
Default Path:
C:\Program Files\NetApp\Virtual Storage Console\smvi\server\scripts
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.
Quick and simple. Have fun.. 🙂
NDMP auf der NetApp einrichten. Seeeehr einfach… Hier wird erläutert, wie es geht.
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.
Quick and simple… 🙂
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…
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…
Nach langem Warten und viel Spekulation hat Netapp diese Woche endgültig offiziell die Katze aus dem Sack gelassen: Es gibt einen SnapManager für Virtual Infrastructure: VMWare ESX Backup&Recovery mit Netapp Snapshots!
Diese Software erlaubt- ähnlich wie die bereits verfügbaren Tools SnapManager Exchange/SQL/Sharepoint – eine Sicherung der Daten im laufenden Betrieb mit Hilfe von Netapp Snapshots. Das Zusammenspiel von VMWare und Netapp wird somit noch perfekter, die Herausforderungen, welche das Backup bisher gestellt haben sind nun endgültig gelöst. Neben der Möglichkeit Datensicherungen zu erstellen kann auch per SnapRestore in sekundenschnelle ein Recovery erfolgen!
SnapManager for VI wird vorraussichtlich im April ausgeliefert und wird laut offiziellen NetApp Angaben ca 2000 US Dollar pro physikalischem Server kosten. Die erste Version von SMVI wird nur VMware Virtuelle Maschinen unterstützen, später soll dann auch Support für Citrix XEN, OracleVM, VirtualIron und Microsoft Virtualisierungstechnik dazukommen.
Sobald alle anderen SnapManager von Netapp eine neue Schnittstelle zum SMVI erhalten haben, wird es mit dem SMVI auch möglich sein, auf andere SnapManager Instanzen zuzugreifen und die entsprechende Applikation zu sichern. Exchange/SQL/Sharepoint usw können dann also sowohl auf physikalischer Hardware als auch in virtuellen Maschinen laufen und mit den Tools von Netapp verwaltet werden. Diese Funktionalität soll aber erst zu einem späteren Zeitpunkt in SMVI eingebaut werden.
Laut Netapp funktioniert SMVI sowohl mit NAS als auch mit SAN Storage. Genauere Angaben haben wir leider noch nicht, besonders interessant könnte sein, inwiefern SMVI auch RDM bzw. NPIV unterstützt.
Selbstverständlich werden wir bei team(ix) sofort Tests durchführen und darüber berichten, sobald wir SMVI bekommen!
Proact Deutschland GmbH
Südwestpark 43
90449 Nürnberg
Mail: info@proact.de
Tel.: 0911 309990