20101112zze CA Virtualisierung richtig managen Teil 2
|
|
|
»manage
it«
als
|
Serie »Virtualisierung richtig managen«, Teil 2 Reales Management für virtuelle Welten Virtualisierung wird meistens unter technologiespezifischen oder wirtschaftlichen Aspekten diskutiert. Die vierteilige Serie »Virtualisierung richtig managen« stellt dagegen praxisnah am Beispiel eines Modellunternehmens dar, welche Schritte auf dem Weg zur Virtualisierung der IT-Infrastruktur notwendig sind. Teil 2 beschreibt das Management der virtuellen Infrastruktur und stellt die wichtigsten Werkzeuge vor.
nternehmen XY hat nicht die gesamte Infrastruktur virtualisiert, sondern Server mit geschäftskritischen Applikationen in der realen Welt belassen und sogar noch mit frei gewordener Hardware ausgebaut. XY arbeitet also nun mit einer Infrastruktur, die aus realen und virtuellen Komponenten besteht. Folgerichtig fragt sich das IT-Team, ob es für die virtuelle Infrastruktur neue Management-Werkzeuge benötigt. XY setzt ja bereits Management-Tools für die realen Server ein. Da liegt der Gedanke nahe, diese auch für die virtuelle Welt zu benutzen. Allerdings findet die Umsetzung dieser Idee schnell technische Grenzen. Denn das gehostete Betriebssystem merkt naturgemäß nicht, dass es virtualisiert wurde. Es geht davon aus, dass es exklusiv auf eigener Hardware läuft und wird Meldungen an die Management-Werkzeuge ausgeben, die jedoch die tatsächliche Lage nicht korrekt wiedergeben. Um Meldungen, die für das Infrastruktur-Management relevant sind, aus einem gehosteten System auszulesen, benötigt XY also spezielle Software, die auf virtuelle Umgebungen zugeschnitten ist. Mit anderen Worten: Für das Management einer gemischten Infrastruktur sind neben Werkzeugen für die reale Infrastruktur auch Tools für die virtuelle Welt notwendig. Von Bordmitteln zu einer integrieren Lösung Viele Unternehmen – und da ist XY keine Ausnahme – wollen dann zunächst die virtuelle Welt mit Bordmitteln der Virtualisierungsanbieter managen. Diese Bordmittel sind jedoch nicht in die Management-Umgebung der realen Welt integriert. Deswegen hat XY schnell gelernt, dass es schwierig ist, Rückschlüsse auf das Gesamtsystem zu ziehen. Denn ein Server innerhalb des VM-Systems, der Schwierigkeiten bekommt, kann auch das Verhalten realer Server und/oder eines virtuellen ESX-Clusters beeinflussen. Reale und virtuelle Welt sind eng untereinander vernetzt und beeinflussen sich gegenseitig. XY hat sich deshalb entschlossen, ein Monitoring über die gesamte Landschaft mit einer zentralen Sicht einzurichten. Sie arbeiten deshalb mit Virtual Assurance. Das Tool enthält E-Health-Komponenten, die das Performance Management für sowohl virtuelle als auch reale Server übernehmen. Die zentrale Sicht aus einer Vogelperspektive auf die gesamte Infrastruktur sorgt dafür, dass die Administratoren frühzeitig erkennen können, an welchen Stellen im realen und/oder virtuellen System etwas aus dem Ruder zu laufen droht. So könnten sie beispielsweise den Hinweis erhalten, einen Server von einer Vmware-Installation auf eine andere zu verlagern, um das Gesamtsystem zu entlasten. Oder sie könnten auch benachrichtigt werden, wenn die zur Verfügung stehende Hardware generell nicht mehr den gestiegenen Anforderungen genügt. Performance Monitoring in der realen und virtuellen Welt Mit dem Performance Monitoring sehen die Administratoren, wie viel die einzelnen Komponenten von der gesamten zur Verfügung stehenden Kapazität beanspruchen. Also: wie viel Kapazität haben sie einem virtuellen Server gegeben, und wie viel braucht er tatsächlich. Anhand der gemessenen Werte können sie erkennen, ob sie bei einem Server – sei er real oder virtuell – noch etwas »nachlegen« müssen, oder ob er sogar noch ungenutzte Reserven besitzt. Für die Administratoren von XY, die zehn virtuelle Prozessoren auf vier realen Prozessoren hosten, ist es wichtig zu wissen, wie stark die realen Prozessoren ausgelastet sind. Sie müssen also die benötigte Performance für die virtuellen Systeme mit der tatsächlich vorhandenen Serverleistung abgleichen können. Mit CA Virtual Assurance ist dies möglich. Bordmittel erlauben das nur rudimentär. Denn in der Regel fehlt ihnen das Reporting (wie hat sich das System in den letzten Wochen entwickelt) wie auch die Alarmierung bei überschrittenen Schwellwerten. Mit Bordmitteln können die Administratoren auch nicht hochrechnen, wann und wie viel neue Server installiert werden müssen, wenn sich die virtuellen Maschinen weiter ausdehnen. Automatische Provisionierung Der CA Automation Manager hat bei XY die Aufgabe, bei Bedarf reale und/oder virtuelle Maschinen anzulegen. XY hat seine virtuellen Server in Gruppen klassifiziert: So sind alle Oracle-Server in einer Gruppe und alle Web-Server in einer anderen zusammengefasst. Der Automation Manager misst nun die Performance dieser virtuellen Systeme. Stellt er dabei zum Beispiel fest, dass die Web-Server nur sehr gering ausgelastet sind, kann er automatisch einen oder auch mehrere Server ausschalten, um Strom zu sparen. Er kann aber auch neue Server automatisch hinzu provisionieren, wenn Server aus einer anderen Gruppe unter der Last »ächzen«. Anschließend misst er weiterhin die Performance, um zu prüfen, ob die Aktion gegriffen hat. Nicht zuletzt hat XY mit dem Automation Manager auch die Möglichkeit, Rechenleistung von einem externen Cloud-Anbieter wie Amazon zu beziehen – beispielsweise, wenn Buchhalter Kussler für einen Testlauf des Jahresabschlusses für wenige Stunden viel Rechenkapazität oder Mitarbeiter Schulze aus der Forschungsabteilung kurzfristig drei Server für Berechnungen benötigt. Konfigurationen aktiv managen Mit CA Virtual Configuration verwaltet XY die Konfigurationsänderungen und sorgt dabei für die notwendige Compliance. So verfügt XY über eine Gruppe von 20 virtualisierten Oracle-Servern. Einen Server aus dieser Gruppe haben die Administratoren so konfiguriert, wie es von Oracle empfohlen wird und wie er bei XY am besten im Verbund mit den anderen Maschinen und Applikationen arbeitet. Dieser sogenannte Gold-Standard wird dann mit Hilfe von Virtual Configuration gekapselt. Alle anderen Server in dieser Gruppe haben sich dann nach diesem Standard zu richten. Um die Einhaltung des Standards zu prüfen, stellen die Administratoren das Tool so ein, dass es regelmäßig – beispielsweise täglich um 16:15 Uhr oder jeden Montagmorgen – alle Server auf den Prüfstand stellt und gegebenenfalls Differenzen aufdeckt. Obwohl es technisch machbar wäre, stellt das Tool bei Abweichungen jedoch nicht automatisch den Gold-Standard bei einem abweichenden Server wieder her. Denn die Änderung kann ja gewünscht sein. So hatten die Administratoren von XY Probleme mit einem bestimmten Web-Server und dieses Problem an den Hersteller gemeldet, der daraufhin einen Patch per E-Mail zugeschickt hat. Nun läuft der Server wieder performant – allerdings nicht mehr im Gold-Standard. Die gewünschte Änderung wird deshalb in einem Change dokumentiert, und der betroffene Server bekommt innerhalb der Gruppe einen eigenen Standard. Nils Meyer __________________________________________ Nils Meyer, Principal Consultant, Technical Sales, CA Technologies
Serie Virtualisierung Teil 1: Notwendige Vorarbeiten Teil 2: Auch virtuelle Welten benötigen ein reales Management Teil 3: Management der verbundenen Subsysteme Teil 4: Fallback – ein steiniger Weg? |
