03.12.2007 | Autor / Redakteur: Alex Barrett / Ulrich Roderer
David Williams, Autor einer Anleitung zur Programmierung von VMware APIs begann nach Erfahrungen mit Perl, Java und .NET in 2003 Skripts für den ESX-Server 2.0 zu entwickeln. „Die Vmware Managementwerkzeuge sind gut, aber begrenzt. Um große Umgebungen zu verwalten, benötigt man zusätzliche Routinen, um ermüdende Tasks zu automatisieren. Diese können als Skript am besten mit dem VI Client erstellt werden oder direkt auf dem Host.” Williams, der derzeit eine Consultingfirma leitet, die sich auf die Optimierung von Rechenzentren spezialisiert hat, hat verschiedene Optionen der Automatisierung für den ESX-Server erprobt. In diesem Interview mit SearchDataCenter beschreibt, welche Aufgaben sich mit Skripts automatisieren lassen sowie Best Practises dazu. Er benennt auch die Unterschiede zum neuen ESX 3i Server.
SearchDataCenter: Wieso müssen VMware-Administratoren eine Skripting- oder Programmiersprache beherrschen? Reicht VirtualCenter nicht aus, alle Aufgaben zu bewältigen?
David Williams: Zu den bisher größten Aufgaben der Administratoren gehört die Administration von Gruppen mit entsprechenden Massenänderungen sowie Change- und Konfigurationmanagement.
VirtualCenter ist bis jetzt in seiner Struktur so geartet, dass sich die meisten Operationen nur auf ein Objekt beziehen, sei es ein Host oder eine virtuelle Maschine. Die Plattform verfügt noch nicht über das Konzzept von Objektgruppen. An 30 VM einzeln eine Veränderung vorzunehmen ist aber fehleranfällig.
Nehmen wir an, Sie haben ein Environment mit sehr vielen virtuellen Maschinen beispielsweise Peoplesoft, und jetzt müssen sie ein neues Release einspielen. Natürlich wollen sie vor den Update einen Snapshot dieses Environments erstellen. Dazu müssen Sie momentan entweder 30 Minuten darauf verwenden, alle VM einzeln zu sichern oder sie setzen ein Skript ein.
Vor allem um Gruppen zu administrieren sind Skripts sehr hilfreich. Sie garantieren konsistente Konfigurationen. Ein Application Service Provider kann Skripts nutzen, um für jeden Kunden ein maßgeschneidertes Environment aus Webserver, Datenbank etc zu erstellen. Statt dies manuell für jeden einzeln zu machen, muss er nur dem Konfigurationsprogramm entsprechende Parameter übergeben.
Derzeit findet ein Paradigmenwechsel hin zu IT Governance statt. Bisher wurde eine Infrastruktur selten auf IT Governance hin getestet. Heute aber musst du eine Änderung an einem Host vor dem Change Control Board rechtfertigen: „Haben Sie die Änderung auch vorher getestet?“ Skripts sind ein guter Weg, die Anforderungen an das Change Management zu gewährleisten.
Scripting ergänzt darüber hinaus die Funktionalität von Managementwerkzeugen. Sie erlauben es beispielsweise einen Workflow zu entwickeln, um eine VM zu erzeugen, zu starten und zu testen. Ohne Skripts ist das ein ermüdender Prozess, der viel an Workflowlogik erfordert.
An erster Stelle stehen Shell Scripts, die einfach sind und von jedem erstellt werden können. Dann existieren eine Reihe von esxcfg-*-Tools, die sich miteinander verbinden lassen und auf dem ESX-Server ausführbar sind. Aber das ist alles nur rudimentär.
Dann gibt es natürlich die Service Console. Aber auch wenn das Scripting aufsetzend auf den ESX-Server verwendbar ist, halte ich diese Form für nicht ideal. Man kann nicht alles damit machen was VirtualCenter kann. Nicht alle Funktionen von VirtualCenter sind per Shell-Kommandos verfügbar. Im Falle, dass Sie mehrere Hosts administrieren müssen, haben sie mit Skripts in Virtual Center einen umfangreicheren Bereich als wenn sie Scripts der Service Console verwenden würden.
Sowohl ESX als auch VirtualCenter haben VMperl und VMcom API als Skriptschnittstellen. Aber um volle Automatisierung zu erzielen muss man auf VMware Web Services zurückgreifen wie beispielsweise das VMware VI3 SDK. Dazu benötigt man keine größeren Kenntnisse erhält aber mehr Funktionen. Der Code lässt sich mit allen Sprachen schreiben, die Web Services unterstützen wie Java, .NET, C#, VB, Perl. Java ist sicher am beliebtesten, weil es erlaubt, Open Source Bibliotheken einzubinden.
Auf der einen Seite hängt das sicherlich auch ab von Programmierkenntnissen. Aber ich habe auch mit erfahrenen Programmieren gearbeitet, die es für schwierig halten, das Vmware SDK zu programmieren. Es interessant die Lernkurve zu beobachten. Diese Programmierer hatten gute Kenntnisse in der Programmierung von Web Services aber mussten ihre Denkweisen ändern, als sie mit dem VMware APIs zu arbeiten begannen. Die VMware-Entwickler waren sehr kreativ und halten die APIs für ein cooles Produkt. Aber sie haben den normalen Entwickler nicht berücksichtigt und seine Denkweise, sondern suchten nach der besten Weise wie Dinge gemacht werden könnten.
Doch die Dinge verbessern sich. ESX 2.5 war wirklich schwierig zu programmieren, weil es so verschieden von allen anderen Ansätzen im Bereich der Web Services war. Mit der neuen Version VI3 hat Vmware die Web Services vollständig überarbeitet und es ist einfacher geworden. Der alte Code funktioniert nicht mehr mit der neuen Version. Aber es ist noch perfekt jetzt.
Das ist schwer zu sagen, weil 3,5 noch im Betastadium ist. 3.5 ist kein großes Release, also wird die Kompatibilität zum 3.0.2 SDK bestehen bleiben, auch wenn einige neue Funktionen hinzukommen. Sachen die häufig bemängelt wurden scheinen sie zu bereinigen.
Beispielsweise die Art wie man Objekte erreicht, die man verändern will. Aber auch die Menge der notwendigen Interaktionen zwischen SDK und Programm, die momentan sehr hoch sind. Damit wird die Performance und die Flexibilität der Anwendung erhöht. Ich schätze, dass mit 3.5 mehr Standardisierung Einzug hält. Meine Ideallösung wäre eine Kombination des SDK mit Entwicklungsumgebungen wie Eclipse und Visual Studio.
Ich glaube, dass 3i schnell populär wird weil man nur einen Flashbaustein in den Server stecken muss und das System ist virtualisiert. Das beseitigt einen Großteil der Komplexität und Overhead des momentanen ESX 3 Servers. Allerdings unterstützt 3i die Service Console nicht mehr, die eh sehr begrenzt ist und ich denke die meisten Entwickler werden auf VI migrieren.
Man sollte sowie so nur dann die Service Console nutzen, wenn keine anderen Möglichkeiten bestehen. Systeme auf genau dem System zu betreiben, dass man managen will ist keine gute Idee. Wenn ich Systemsmanagement-Skripts schreibe will ich sie nicht auf dem ESX-Server laufen lassen, sondern auf einem übergeordneten System.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009415)
