Eine immer wiederkehrende Geschichte: Linux und Windows.

Für eines unserer Projekte benötigen wir Systeminformationen von Windows Servern. Bisher konnten wir die notwendigen Informationen mit Hilfe des WMI-Clients für Linux problemlos erhalten. Bisher!

Auf einmal bekommen wir bei einem Projekt Probleme. Der WMI-Client verweigert die Mitarbeit, oder besser:

Der neue Windows Server verweigert die Zusammenarbeit. Anfangs ist guter Rat nicht nur teuer, sondern weit und breit nicht zu finden. Dann fällt mir ein, dass wir schon einmal mit Windows Server 2008 zu tun hatten und auch damals gab's Probleme. Es lag an der Samba-Installation auf einem File-Server. Wir mussten auf eine neuere Version hochziehen, damit Linux und Windows sich wieder vertrugen.

Also habe ich mich auf die Suche gemacht und Google bemüht. Nach einiger Zeit der Recherche (es dauerte Stunden) stieß ich auf einen sehr hilfreichen blog-Eintrag, der letztlich zum Erfolg führte.

Es gibt bei zenoss für den wmi-Client unter Linux aktualisierte Sourcen.

http://dev.zenoss.org/svn/trunk/inst/externallibs/wmi-1.3.9.tar.bz2

Mittlerweile ist die Version 1.3.13, dabei bleibt das Verzeichnis auf dem Server gleich.

Leider ist die NetApp VTL ja schon Geschichte :-(, aber dennoch durfte ich eine der wohl letzten ausgelieferten Geräte in die beim Kunden bestehende NetWorker Kunden Umgebung integrieren.

Da es keine Workshops zur NetApp VTL bei unserem Partner qSkills mehr geben wird, hatte der Kunde eine In-House-Schulung zum Thema gebucht.

Aus dieser Not wurde eine Tugend! Der Workshop konnte direkt in der aktiven Umgebung stattfinden und somit konnten die Auswirkungen der verschiedenen Szenarien (Cache Betrieb mit Direct Tape Creation, oder reine "Backup-To-Tape" Lösung) direkt sichtbar gemacht werden. Am Ende des 3 tägigen Workshops erhielt der Kunde somit eine fertige Lösung.

Implementiert wurde die Cache Version. Hiefür wurde im NetWorker ein Python-Script in die NetWorker Notification-Ressource integriert, das bei Bedarf Bänder automatisch aus der angeschlossenen Tape-Library importiert. Ein Cron-Job sorgt für die Auslagerung voller Bänder. Diese Auslagerung findet täglich statt und verdrängt dabei die Bänder aus der NetWorker Jukebox in den Shadow Bereich der VTL. Wird ein virtuelles Band für die Wiederherstellung benötigt, so generiert NetWorker automatisch eine Notification mit der Anforderung des benötigten Bandes. Das oben erwähnte Skript bringt das benötigte Medium dann umgehend zurück in die NetWorker Jukebox. Dabei ist es egal, ob das virtuelle Band noch in dem Shadow-Pool vorhanden ist, oder dieses aus der physiklaischen Jukebox eingelagert werden muss.

Die Lösung läuft rund und performant, Schade das es wohl keine weitere Implementation in der Art geben wird ;-(

Diese Woche war schwitzen angesagt (nicht nur der Temperaturen wegen ;-)), sondern auch das Projekt hatte es mal wieder in sich.

Es sollte ein NetWorker Active-Active Cluster bestehend aus einer NetWorker Storage-Node und einem NetWorker Server aufgebaut werden. Die Basis bilden:

• zwei Solaris-10 Maschinen, auf denen ein Veritas-Cluster zum Einsatz kommt
• ein über NFS angebundener Storage auf einem NetApp Metro-Cluster
• die Networker Version 7.5 von Fujitsu
• SAN Laufwerke aus einem ACSLS Roboter
• die SAN Laufwerkssharing Lösung SRS zum Verwalten der Laufwerksvergabe
• eine VTL-700 für die Sicherung der langsamen und asynchronen Daten

Die Lösung erlaubt eine automatische (von der Cluster-Software überwachte) Übernahme der NetWorker-Server Funktionalität an den StorageNode mit Übernahme aller Laufwerke und umgekehrt. Dies bedingt natürlich gleiche Laufwerksbezeichnungen aller verwendeten Laufwerke auf den beiden Cluster-Maschinen und ein durchdachtes Design des Storage und der Laufwerksaufteilung.

Das Schwitzen hat sich aber gelohnt ;-) das Cluster ist fertig und alle Kundenanforderungen konnten erfüllt werden.

Es gibt sie immer noch - die NetWorker Server mit der Version 7.2.

Eines dieser Arbeitstiere (die noch bestehenden V7.2 Server sind meist in größeren Umgebungen zu finden) durfte ich vor 2 Wochen auf eine neue Umgebung hieven. Hierbei wurde aber nicht nur die NetWorker Version auf den neuesten Stand gebracht, sondern auch die Hardware des NetWorker Servers und dessen StorageNode ausgetauscht. Des Weiteren wurde eine NetApp VTL-700 als Cache und als Datengrab in die bestehende Umgebung integriert.

Die Herausforderung bei der Umstellung war aber nicht das NetWorker Update, sondern die Integration der neuen 72 virtuellen Laufwerke in die Umgebung mit NetWorker-Server, dessen örtlich getrennter StorageNode und 8 NetApp Filern. Hier war im Vorfeld eine gute Planung und Abstimmung notwendig. Schließlich soll ja nicht jede Maschine alle 72 Laufwerke sehen können.
Auf der anderen Seite soll die StorageNode aber auch als Quasi-Cluster fungieren und die Laufwerke des Servers sehr wohl sehen. Hierfür ist eine eindeutige Namensgebung der Laufwerke (persistent device names) an Server und StorageNode Voraussetzung. Erreicht wurde dieses durch den Einsatz des LINUX udev Drivers und einer geschickten Namensgebung.

Nach einigen kleineren und größeren Problemen (es wurde unter anderem ein HotFix von Fujitsu benötigt), läuft die Konfiguration nun wieder reibungslos.