Inhaltsverzeichnis

Transcrição

Inhaltsverzeichnis

Das_virtuelle_Datacenter_im_Datacenter_mit_Hilfe_von_VMware_Virtualisierungslösungen
Name des Autors:
Titel der Arbeit:
Hochschule und
Studienort:
Benjamin Bublitz
"Das virtuelle Datacenter im Datacenter mit Hilfe von VMware
Virtualisierungslösungen"
FOM Düsseldorf
Inhaltsverzeichnis
• 1 Einleitung
• 2 Vorstellung der Technologie
♦ 2.1 Vorstellung der
Infrastruktursoftware
♦ 2.2 Vorstellung der Optionen
◊ 2.2.1 DRS/DPM
◊ 2.2.2 VMotion
◊ 2.2.3 HA
♦ 2.3 Vorstellung Interfaces
◊ 2.3.1 vSphere CLI
◊ 2.3.2 PowerCLI
◊ 2.3.3 vSphere SDK for
Perl 4.0
◊ 2.3.4 vCenter Server
◊ 2.3.5 vCenter
Converter
♦ 2.4 Voraussetzung
◊ 2.4.1 Hardware
◊ 2.4.2 Betriebssysteme
• 3 Integrationsbeispiel
♦ 3.1 Konzept
♦ 3.2 Aufbau
◊ 3.2.1 Backup
◊ 3.2.2 Aufbau der
V-LANs
◊ 3.2.3 Einsatz der
virtuellen Maschinen
◊ 3.2.4 Aufbau des
Frameworks
◊ 3.2.5 Zugriff auf die
Kundenappliances
◊ 3.2.6 Integration einer
neuen
Kundenappliance
• 4 Analyse und Bewertung
♦ 4.1 Vorteile
◊ 4.1.1 technisch
◊ 4.1.2 ökonomisch
Inhaltsverzeichnis
1
♦ 4.2 Nachteile
◊ 4.2.1 technisch
◊ 4.2.2 ökonomisch
• 5 Empfehlung
• 6 Fazit
• 7 Fußnoten
• 8 Abkürzungsverzeichnis
• 9 Abbildungsverzeichnis
• 10 Tabellenverzeichnis
• 11 Literaturverzeichnis
1 Einleitung
Oftmals werden in Unternehmen Projekte mit einer Webschnittstelle geplant und realisiert. Die Erfahrung hat
gezeigt, dass hierbei oftmals die Ressourcen für diese Webschnittstellen falsch geplant werden und daher
überdimensioniert ausfallen. Um solche simplen Projekte ressourcenschonend zu realisieren, können die
Virtualisierungslösungen von VMware eingesetzt werden. Mit der Hilfe eines ESX/ESXi/vSphere Clusters kann
eine abgeschlossene Datacentereinheit abgebildet werden, die diese "Kleinprojekte" integriert.[1]
Abgrenzung zur Datacentervirtualisierung
Immer öfter wird in modernen Rechenzentren eine Datacentervirtualisierung durchgeführt, um Kosten zu senken,
Ressourcen besser zu verteilen, flexibler und ökonomischer zu arbeiten. Hierbei werden in der Regel Server,
welche noch auf Hardware laufen, vom Datacenter mittels dafür vorgesehener Software virtualisiert und in einer
neuen Clusterumgebung, z.b. in eine ESX/ESXi Umgebung, migriert, um die Hardware zu entfernen. Dabei
handelt es sich zum Großteil um komplexe Systeme mit mehreren Applikations- und Datenbank-Servern. Diese
Art der Virtualisierung ist nicht Teil dieser Seminararbeit, welche sich ausschließlich mit dem Gedanken eines
virtuellen Rechenzentrums in einem Rechenzentrum für simple Serversysteme befasst.
2 Vorstellung der Technologie
In den folgenden Kapiteln werden VMware Technologien und Software vorgestellt, die den Einsatz eines
virtuellen Rechenzentrum in einem Rechenzentrums ermöglichen, vereinfachen und administrierbar machen. Die
hier erläuterten Technologien und Softwarepakete werden als Grundlage für die spätere Analyse vorausgesetzt.
2.1 Vorstellung der Infrastruktursoftware
VMware bietet zur Zeit folgende Produkte an , mit denen man einen solchen Virtualisierungsansatz kostengünstig
umsetzten kann:
• VMware ESXi
• VMware vCenter Server
Bei ESXi handelt es sich um ein kostenloses Serverbetriebssystem auf Hypervisorbasis.[2] Einige Features sind
u.a.:[2]
• Bis zu 64 logische Kerne, 256 virtuelle CPUs (Central Processing Unit) und 1TB (Terrabyte) RAM
1 Einleitung
2
(Random Access Memory) pro Host
• NIC-Teaming (Network Interface Card)
• Memory Ballooning
VMware vCenter Server stellt eine Managementoberfläche für den ESXi bzw. vSphere Cluster zur Verfügung.
2.2 Vorstellung der Optionen
Nachfolgend werden diverse Optionen beschrieben, die für den Betrieb eines virtuellen Datacenters im Datacenter
vorausgesetzt werden.
Aufgrund des Lizenzmodels bei VMware sind diese Optionen nur mit einer Enterprise oder Enterprise Plus
Lizenz verfügbar. [3]
Abb. 1: Übersicht des VMware Lizenzmodells
2.2.1 DRS/DPM
DRS (Distributed Ressource Scheduling) ist ein Ressourcenoptimierungssystem von VMware. Desweiteren
können mit DRS sogenannte Ressourcepools erzeugt werden, mit deren Hilfe sich diverse VMs (Virtuelle
Maschinen) die Gesamtressourcen "teilen". Innerhalb eines Ressourcepools haben alle VMs die Möglichkeit die
maximalen, für diesen Ressourcepool konfigurierten, Ressourcen zu nutzen. Braucht eine VM kurzzeitig mehr
Arbeitsspeicher als ihr eigentlich zugeteilt wurde, so hat sie die Möglichkeit ungenutzte Ressourcen des
Ressourcepools zu aktivieren und für sich zu nutzen.[4][5]
Hierdurch ist es möglich z.B. einzelnen Unternehmensbereichen einen Ressourcepool zuzuweisen und ihnen die
Möglichkeit zu geben innerhalb dieses Pools die Ressourcen eigenständig zu verwalten, ohne Auswirkungen auf
VMs aus anderen Pools.[5]
Desweiteren wird DRS ebenfalls zur Lastverteilung auf den Hosts des Clusters eingesetzt. Sollte ein ESX-Host
nicht mehr in der Lage sein seine VMs alle mit genügend Ressourcen zu bedienen, so wird via VMotion die VM
auf einen Server migriert, der mehr Ressourcen zur Verfügungn stellen kann als der Alte.[4][5]
Eine Erweiterung von DRS is das DPM (Distributed Power Management). Mit dieser Funktion werden VMs, in
Zeiten einer Minimalauslastung, auf so wenige Server wie möglich migriert. Die Übrigen nicht
2.1 Vorstellung der Infrastruktursoftware
3
genutzen/gebrauchten Hosts werden heruntergefahren, was den Strombedarf von Rechenzentren enorm senkt.
[4][5]
2.2.2 VMotion
Abb. 2: VMware VMotion
VMotion bezeichnet eine VMWare Technologie zur Live-Migration von aktiven Virtuellen Maschinen zwischen
verschiedenen ESX-Hosts[6]. Sie ist die Grundlage für ein funktionierendes DRS System.[7]
Bei dieser Technologie ist eine unterbrechungsfreie Migration möglich, da u.a das Netzwerk, welches ebenfalls
virtuell ist, beibehalten wird bzw auf allen Hosts verfügbar ist. Diese kann genutz werden, um z.B. bei einer
Wartung alle VMs auf einen anderen ESX-Host zu migrieren, ohne den Betrieb zu unterbrechen. Ein integriertes
Scheduling System kann dazu genutzt werden (teilautomatisierte) Migrationstasks durchzuführen.[6]
Desweiteren ist es möglich via eines QoS (Quality of Service) Mechanismus eine Prioritätenliste für Migrationen
zu erstellen, um sicherzustellen, dass betriebskritische VMs zuerst migriert werden.[6][7]
2.2.3 HA
VMware stell eine eigene HA (High Availability) Lösung zur Verfügung, um im Falle eines Hostausfalls die
Ausfallzeit der VM-Guests so gering wie möglich zu halten.
Mit der HA Lösung werden alle, sich auf einem Host befindlichen, Guests auf andere Hosts des Clusters migirert,
sollte der erstgenannte Host, aufgrund eines Defektes, nicht mehr reagieren. Weiterhin ist es mit HA möglich
Betriebssystemfehler zu überwachen und im Fehlerfall das Gastbetriebssystem neuzustarten.[8]
Abb.: 3 VMware HA
Für die Migration auf weniger ausgelastete Hosts des Clusters sind VMware DRS und VMoition Voraussetzung[9]
2.2.1 DRS/DPM
4
2.3 Vorstellung Interfaces
Aufgrund der Tatsache, dass es sich bei ESXi um einen Hypervisor handelt wird keine Servicekonsole supportet,
weder am Host selber, noch per SSH (SecureShell-Verbindung)[10]. VMware bietet daher diverse Schnittstellen
zur scriptbasierten Administration,Automatisierung und operativen Betrieb für virtuelle Umgebungen, neben der
Administration über den VMware vCenter Server:[11]
Automatisierung:
• vSphere CLI (Command-Line Interface) (Kommandozeilen Schnittstelle für Windows)
• vCenter Orchestrator (Abbildung von häufig genutzten Workflows zur Automatisierung von vCenter
Tasks)
• vSphere Management Assistant (Virtuelle Appliance zum Development von Scripten und zur
Administration)
• Site Recovery Manager (Testet - und wertet Failover Scenarios aus)
SDK (Software Development Kit) & API (Application Programming Interface):
• PowerCLI (Powershell Schnittstelle)
• vSphere Web Services SDK (Java und C# Schnittstelle zur administration über den VMware Webservice)
• CIM API (Common Information Model API)
• vSphere SDK for .NET (.NET Schnittstelle)
• vSphere SDK for Perl (Perl Schnittstelle)
• Studio (VM zur Transformation von Softwarepaketen in virtuelle Appliances)
• OVF Tool (Open Virtualisation Format Command Line Utility zum Im-/Export von OVF (Open
Virtualisation Format) VMs ins vCenter)
• VDDK (Virtual Disk Development Kit) (C Library und Utilities zur Verwaltung von VMDK (Virtual
Maschine Disk) Dateien)
• VIX API (High-Level Automatisierung API für Perl, C und COM (Component Object Model) für
Gastbetriebssysteme)
• VMCI Sockets (Interface zur Kommunikation der VM mit dem Host oder VMs untereinander auf dem
selben Host)
• vSphere Guest SDK (Schnittstelle für Software um statistische Information über die VM zu sammeln)
veraltete Schnittstellen:
• Programming API (Schnitstelle für VMware Server 1.0 und früher, wurde ersetzt durch VIX Api)
• Scripting API (Schnittstelle für Perl und COM, wurde ersetzt durch SDK for Perl und Web Services SDK)
Nachfolgend werden die Wichtigsten kurz beschrieben.
2.3.1 vSphere CLI
Mit der Einführung von vSphere 4, hat VMware das unter dem alten Namen bekannte Remote-CLI Package, das
diverse Scripte und Binarys zur Administration für die ESXi/ESX Hosts bereitstellte, überarbeitet und unter dem
Namen VMware vSphere CLI released. Mit dem vSphere CLI kann man von jedem Rechner, der Zugriff auf das
selbe Netzwerk hat wie der ESXi/ESX Host oder der vCenter Server, die vSphere Umgebung administrieren.
Dieses Interface basiert auf dem vSphere SDK for Perl und wird daher zusammen mit dem SDK für Perl
2.3 Vorstellung Interfaces
5
installiert.[12]
2.3.2 PowerCLI
VMware bietet eine Powershellschnittselle zu den vSphere Funktionalitäten. Es werden 2 unterschiedliche Pakete
angeboten: [13]
• vSphere PowerCLI
• vCenter Update Manager PowerCLI
Das erstgenannte Paket enthält die cmdlets (Command-lets)[14] zur Administration der vSphere Umgebung.
Das zweite Paket enthält cmdlets, zur Erstellung eines Update Services für VMs und Hosts.
Als Editor wird auf dem VMware Blog "Virtualisation EcoShell" empfohlen.[15]
Abb. 4 Ecoshell
Dieser beinhaltet über 150 cmdlets als PowerShell snap-in und ermöglicht, dank PowerShell, die Administration
von Applikationen auf der VM, dem Betriebssystem der VM, dem Hypervisor des ESX/ESXi Hosts und der
generellen Infrastruktur (solange diese eine Powershellschnittstelle bietet).[16]
Der Editor stellt ein komplettes IDE (Integrated Development Environment) für PowerShell zur Verfügung und
ist als Freeware lizensiert.[16]
2.3.3 vSphere SDK for Perl 4.0
Das vSphere SDK for Perl 4.0 wir nur zusammen mit dem vSphere CLI Package angeboten, da beide Pakete
gegenseitig aufeinander aufbauen.[12] Dieses SDK stellt eine Schnittstelle zwischen Perl und der vSphere API dar.
Desweiteren sind einige Beispielscripte bzw. vorgefertigte Scripte in diesem Package schon vorhanden, die die
automatisierte scriptbasierte Administration vereinfachen[17]:
Scriptname
Beschreibung
connect.pl
Testet die Verbindung zu einem Host oder vSphere Center.
credstore_admin.pl
Wird zur Verwaltung der Zugangsdaten verwendet (Hinzufügen, Löschen, Ändern von
Benutzerkonten).
dsbrowse.pl
Zeigt die angeschlossenen Datastores an und bietet die Möglichkeit dessen Attribute zu
ändern
2.3.1 vSphere CLI
6
extractlog.pl
Exportiert das vmware.log File für die gewünschten VMs.
fileaccess.pl
Dient zur Verwaltung von VM Konfigurationsdateien.
guestinfo.pl
Zeigt und ändert Attribute von Gastbetriebssystemen einer/mehrere VMs.
hostdiagnostics.pl
Exportiert das ESX/ESXi Host logfile.
hostevacuate.pl
Migriert alle VMs eines Hosts auf einen anderen.
hostinfo.pl
Zeigt Netzwerk, CPU und Speicherlast eines ESX/ESXi Hosts an.
hostops.pl
Dient zur Administration des Clusters oder einzelner ESX/ESXi Hosts(Host hinzufügen,
entfernen, in Maintenancemodus setzen, herunterfahren...).
load_session.pl
Lädt eine vorher gespeicherte Session (Sessionfile) zu einem Host
save_session.pl
Verbindet zu einem Host und speichert die Sessioninformationen in einer Datei
(Sessionfile).
sharesmanager.pl
Dient zur Anzeige und Verwaltung von geteilten Ressourcen von VMs
snapshotmanager.pl Verwaltung von Snapshots.
vdiskcreate.pl
Erstellt eine neue virtuelle Festplatte für eine VM.
vidiscovery.pl
Zeigt Informationen über die Hierarchie des ESX/ESXi Hosts oder des vSphere Centers
an (Ordner, Ressourcepools u.v.a.) .
viperformance.pl
Exportiert Performancedaten eines Hosts.
viversion.pl
Zeigt Informationen über die eingesetzten Produkte an.
vmclone.pl
Dient zum Klonen und Aufbereiten von VMs und Gastbetriebssystemen.
vmcontrol.pl
Wird zum Starten, Stoppen, Pausieren von einer VM oder deren Gastbetriebssystems
verwendet.
vmcreate.pl
Erstellt aufgrund einer XML (Extensible Markup Language) Konfigurationsdatei eine
VM.
vminfo.pl
Zeigt die Eigenschaften von VMs an.
vmmigrate.pl
Migriert die angegeben VMs eines Hosts auf einen anderen Host.
vmreconfig.pl
Rekonfiguriert einzelne Eigenschaften von VMs.
vmregister.pl
Registriert oder deregistriert VMs an einem ESX/ESXi Host.
vmsnapshot.pl
Erstellt einen Snapshot.
vmtemplate.pl
Konvertiert eine VM in ein VM-Template und umgekehrt.
Quelle: In Anlehnung an:
http://www.vmware.com/support/developer/viperltoolkit/viperl40/doc/perl-toolkit-right.html
Tabelle 1: Auflistung aller Scripte aus dem SDK for Perl
2.3.3 vSphere SDK for Perl 4.0
7
2.3.4 vCenter Server
vCenter Server is die Managementoberfläche für vSphere und ersetzt somit den VMware Infrastructure 3 Client
(Virtual Center), der bis ESX/ESXi 3.5 genutzt wurde. Das vCenter stellt einen Großteil der oben genannten
Funktionen, wie z.B. VMotion, HA, erweiterte vSphere CLI Befehle, u.A, zur Verfügung. Weiterhin bietet das
vCenter eine große Auswahl an Administrationsmöglichkeiten:[18]
• Zentrale Lizensierungsstelle
• Performance Charts
• Integration der Perfomancedaten in Perfmon für Windows VMs
• Event- und Alarmsupport
• Error Reporting inklusive KED (Known Error Database) Link
• Host-Upgrade-Utility zum Upgrade für ältere ESX Hosts
• Datastore Management Konsole
2.3.5 vCenter Converter
Mit dem vCenter Converter ist es möglich physische Server, inclusive aller installierter Software, zu
virtualisieren. Desweiteren kann der Converter genutzt werden um eine Konvertierung zwischen den
verschiedenen virtuellen Formaten durchzuführen, wie z.b. VMware Server VMs in ESX kompatible VMs,
Microsoft VMs in VMWare Server VMs oder Norton Ghost Images in VMware kompatible VMs. [19]
Nachfolgend eine kurze Aufstellung über die Konvertierungsmöglichkeiten:[20]
Mögliche physische Quellen:
• 64-bit Windows XP/2003
• WinNT SP4+
• Windows 2000
• Windows XP
• Windows 2003
• Windows Server 2008
• Linux (Red Had Enterprise Linux (RHEL), SUSE und Ubuntu)
Kompatible Third Party Images:
• Microsoft Virtual Server
• Microsoft Virtual PC
• Parallels Desktop
• Symantec Backup Exec System Recovery (Live State Recovery)
• Norton Ghost
• Acronis
• StorageCraft
Nachfolgend sind alle Ziel VM Formate aufgeführt, in die alle oben genannten Formate konvertiert werden
können. Selbstverständlich ist auch eine Konvertierung zwischen verschiedenen VMware (Ziel-)Formaten
möglich.
Ziel VM Formate:
• VMware Workstation
• VMware GSX Server
2.3.4 vCenter Server
8
• VMware Player
• VMware Server
• VMware Fusion
• VMware ESX (mindestens mit VMware VirtualCenter 2.x)
2.4 Voraussetzung
2.4.1 Hardware
VMware setzt keine direkte Hardwarekomponente voraus (wie z.B. eine DL380 G6), sondern stellt einige
Ansprüche an die eingesetzte Hardware[21]:
Unterstützte Serverplattform:[21]
• VMware ESXi 4.0 kann nur auf Servern mit x86 CPUs im 64-Bit-Modus installiert und ausgeführt
werden.
♦ Bekannte 64-Bit-Prozessoren:
◊ Alle AMD Opteron-Prozessoren unterstützen 64 Bit.
◊ Alle Intel Xeon-Prozessoren der Serien 3000/3200, 3100/3300, 5100/5300, 5200/5400,
7100/7300 und 7200/7400 unterstützen 64 Bit
◊ Alle Intel Nehalem (zu denen wurden noch keine Xeon-Markennummern zugewiesen)
unterstützen 64 Bit.
• Mindestens 2 GB RAM
• Ein oder mehr Gigabit oder 10 Gb (Gigabit) Ethernet-Controller.
• Ein oder mehrere der folgenden Controller (alle Kombinationen möglich):
♦ SCSI (Small Computer System Interface)-Basis-Controller - Adaptec Ultra-160 oder Ultra-320,
LSI Logic Fusion-MPT oder die meisten NCR/Symbios SCSI-Controller.
♦ RAID (Redundant Arry of Independent Disks)-Controller - Dell PERC (Adaptec RAID oder LSI
MegaRAID) oder IBM (Adaptec) ServeRAIDController.
♦ SCSI-Festplatte oder lokale (nicht im Netzwerk befindliche) RAID-LUN mit nicht
partitioniertem Bereich für die virtuellen Maschinen.
♦ SATA (Serial Advanced Technology Attachment) - eine über unterstützte SAS-Controller oder
unterstützte On-Board-SATA-Controller verbundene Festplatte.
ESXi 4.0 Installable unterstützt die Installation auf ,und das Starten von, folgenden Speichersystemen:
• SATA-Festplattenlaufwerke - hinter unterstützten SAS (Serial Attached SCSI)-Controllern oder
unterstützten On-Board-SATAControllern verbundene SATA-Festplattenlaufwerke.
• Zu den unterstützten SAS-Controllern gehören:
♦ LSI1068E (LSISAS3442E)
♦ LSI1068 (SAS 5)
♦ IBM ServeRAID 8K SAS-Controller
♦ Smart Array P400/256-Controller
♦ Dell PERC 5.0.1-Controller
• Zu den unterstützten On-Board-SATA-Controllern gehören:
♦ Intel ICH9
♦ Nvidia MCP55
♦ ServerWorks HT1000
2.3.5 vCenter Converter
9
• Serial Attached SCSI-Festplattenlaufwerke werden für die Installation von ESXi 4.0 und für das
Speichern von virtuellen Maschinen auf VMFS-Partitionen unterstützt.
• USB(Universal Serial Bus)-Geräte - Unterstützt für die Installation von ESXi 4.0.
Jegliche Hardwarekombinationen kann man mit Hilfe des Hardware Compatibility Guide von VMware
verfifizieren. [22]
2.4.2 Betriebssysteme
VMware unterstützt mittlerweile sehr viele Betriebssysteme (sogenannte GuestOS) auf ESX/ESXi 4.0. Unter
anderem werden folgende GuestOS von der Virtualisierungsplattform unterstützt:[22]
• Debian GNU/Linux
• Fedora
• FreeBSD
• Mac OS X
• Red Hat Enterprise Linux
• SUSE
• Solaris
• Ubuntu
• Windows 2000
• Windows XP
• Windows 7
• Windows Server 2008
• u.v.a
Dies ist nur eine kurze Aufzählung der unterstützten Systeme. Eine komplette Liste aller zur Zeit unterstützten
Systeme kann direkt bei VMware eingesehen werden. [22]
Eine recht interessante Option ist die Möglichkeit den vCenter Server als VM auf einem ESX/ESXi Host zu
betreiben oder einen virtuellen ESX/ESXi Server zu betreiben. Somit ist es möglich kleine virtuelle ESX/ESXi
Cluster in einem Hardware ESX/ESXi Cluster zu betreiben, um ggf Infrastrukturänderungen zu Testen oder zu
entwickeln.
3 Integrationsbeispiel
3.1 Konzept
Ziel des Konzeptes ist es eine Umgebung innerhalb eines Datacenters zu schaffen um "low-level"
Webintegrationen schnell, günstig, sicher und ressourcenoptimiert zur Verfügung zu stellen. Als "low-level"
Webintegrationen werden Webintegrationen bezeichnet, die wenig bis gar keinen Kontak zu anderen Servern
haben oder Verbindungen zu Datenbanken aufbauen, die entweder in der selben VM laufen oder aber als kleine
VM im selben Projekt laufen können und entsprechend wenig Ressourcen benötigen.
Jede dieser Webintegrationen gilt als Projekt. Da diese Webintegrationen im weitesten Sinne nur einen
bestimmten Zweck erfüllen, werden sie im weiteren Verlauf als Appliances beschrieben.
Auftraggeber sind für ein Rechenzentrum im weiteren Sinne Kunden. Daher wird im folgenden Verlauf immer
wieder von Kunden, Kundenzugang und Kundenappliance gesprochen. Hierbei sind nicht die Endnutzer/Kunden
der Webintegration gemeint.
2.4.1 Hardware
10
Es wird von ca. 128 verschiedenen Kundenprojekten ausgegangen, um eine ungefähre Planungsgrundlage zu
schaffen. Für immer wieder genutzte VMs werden VM-Templates erstellt. Mit diesen Templates ist es möglich
schnell eine VM von einem Template zu erstellen, ohne eine komplette Neuinstallation einer VM. Nachdem aus
dem Template eine VM erstellt wurde, muss diese nur noch an einigen Stellen konfiguriert werden (z.B.
Zuweisen einer statischen DHCP [Dynamic Host Configuration Protocol] Adresse, Festlegung des Hostnamens,
u.A.), damit sie eine komplett neue, eigenständige VM darstellt.
Folgende VM Templates werden erstellt:
• IPCop [23]
• Apache mit Reverse Proxy Modul[24]
• M0n0wall[25]
• VM mit CentOS 5.4 als Projekt Konsole
Eine genaue Nutzung dieser VMs wird in Kapitel 3.2.3 beschrieben.
3.2 Aufbau
Als erstes wird hierzu ein ESXi Cluster mit vCenter Server 4 und einem Backupserver benötigt, um die
notwendigen Ressourcen zu stellen, zu verwalten und zu sichern. Es wird ein Cluster aus 4 ESXi Servern
aufgebaut und mit dem eigentlichen Rechenzentrumsnetzwerk verbunden. Jeder dieser ESXi Hosts verfügt über 5
Netzwerkschnittstellen. Zur besseren Übersicht werden diese farblich bezeichnet:
Abb. 5: Hardwareaufbauschema eines virtuellen Rechenzentrums im Rechenzentrum
3.1 Konzept
11
1. (Rot): Verbindung zum Datacenter Netzwerk, Kommunikation nach außen.
2. (Blau1): Verbindung der ESX Hosts untereinander, mit Hilfe eines Switches, im weiteren Verlauf
Crossbar genannt. Dieser ist notwendig, um die später konfigurierten V-LAN (Virtuellen Local Area
Network) über alle ESXi Hosts abzubilden. Auf der Crossbar wird es, aufgrund der Tatsache, dass auf
diesem "Netz" die gesamte Kommunikation aller VMs untereinander stattfindet, zu sehr hohem Traffic
kommen.
3. (Blau2): Eine zweite Netzwerkschnittstelle zur Anbindung an die Crossbar, um das eben bereits
angesprochenen hohe Trafficaufkommen zu managen.
4. (Grün): VMotion Netzwerk. Ebenfalls eine Verbindung der ESXi Hosts untereinander, allerding wird
über dieses Netzwerkinterface nur der VMotion Mechanismus abgebildet, d.h. dass im Falle einer
Migration einzig und alleine diese Netzwerkschnittstelle genutzt wird, um die VM auf einen anderen Host
zu migrieren.
Als weitere Schnittstelle erhält jeder ESXi Host eine Verbindung an einen gemeinsamen SAN (Storage Area
Network) Speicher, damit VMotion und HA auch reibungslos eingesetzt werden können. Dies wäre nicht möglich
wenn die VMs auf den lokalen Platten der einzelnen Hosts liegen würden. In diesem Fall müssten VMs erst
heruntergefahren, auf den lokalen Speicher eines anderen Hosts transportiert und dort wieder gestartet werden,
was eine ggf. längere Unterbrechung des Services bedeutet.
3.2.1 Backup
Hierzu sollte ein dediziierter Server verwendet werden, da die Erstellung der Backup-Snapshots und deren
Komprimierung einen verhältnismäßig hohen Rechenaufwand bedeuten.
Als Backuplösung sollte ein Script erstellt werden, das einen Snapshot einer VM, im laufenden Betrieb, anlegt,
diesen komprimiert und auf dem Backup SAN/NAS (Network Attached Storage) speichert. Die Anzahl der
Backup-Snapshots sollte durch das Script frei definierbar sein. Es handelt sich hierbei jedes Mal um ein
Fullbackup, da ein Snapshot den aktuellen Stand der VM abbildet.[26]
Bei dieser Lösung ist darauf zu achten, dass ein Lauf dieses Scriptes nicht länger als 24 Stunden braucht, um von
allen VMs ein Backup zu erstellen, wenn ein tägliches Backup gewünscht wird. Dies kann man entweder
umgehen, indem man nur wöchentliche Fullbackups verwendet oder aber versucht mit Multithreating und
mehreren Cores zu arbeiten.
3.2.2 Aufbau der V-LANs
Jeder VM können 0-x Virtuelle Netzwerkkarten zur Verfügung gestellt werden. Auf diese Karten werden
V-LANs gebunden, um die Kommunikation der VM mit anderen Netzen zu ermöglichen. Diese V-LANs werden
im Folgenden bezüglich Name und Verwendung genauer definiert.
Damit VMotion reibungslos und unterbrechungsfrei funktioniert, müssen alle V-LANs, die auf einem ESXi Hosts
angelegt werden, auf allen ESXi Hosts angelegt werden. Hierzu werden desweiteren virtuelle Switche benötigt.
Die Konfiguration aller virtuellen Komponenten wird, sofern nicht anders beschrieben, mit Hilfe des vCenter
Servers durchgeführt.
Zur besseren Übersicht sind die V-LANs farblich bezeichnet.
Es werden folgende V-LANs verwendet:
3.2 Aufbau
12
1. (Rot): Verbindung zum Datacenter Netzwerk. Dieses Netzwerk wird 1:1 gemapped mit dem roten
Interface der Hardware. Hier wird der dafür zugeteilte Adressraum des Datacenters verwendet.
Netzwerkkonfiguration: Netzadresse 192.168.100.0/23 Subnetmask: 255.255.254.0
2. (Blau): Internes Netz. Über dieses Netz wird die Kommunikation der internen VMs geleitet. Interne VMs
sind VMs die dem Erhalt, der Stablität der Umgebung und der Verbindung der Umgebung zur
"Außenwelt" dienen. Beispiele hierfür sind Firewalls, Monitoring Lösungen sowie Reverse Proxys u.A..
Abhängig von der Größe der Umgebung sollte hier ein /22 Netz genutzt werden um die Kommunikation
zu gewährleisten. Netzwerkkonfiguration: Netzadresse 192.168.248.0/22 Subnetmask: 255.255.252.0
3. (Grün): Konfigurationsnetzwerk für VMs mit einer Webschnittstelle, die nicht über das rote oder blaue
Interface erreichbar sein sollen, um die Sicherheit und Umgebungsintegrität zu gewährleisten. In der
Regel reicht hier ein /24 Netzwerk, da es meist nicht sehr viele Webschnittstellen gibt, die nicht von
Außen erreichbar sein sollten. Wichtig hierbei ist die Abgrenzung zum blauen Netzwerk, daher sollten
hier unterschiedliche Netze ausgewählt werden (z.B. 192.168.248.0/22 für Blau und 192.168.129.0/24 für
Grün). Netzwerkkonfiguration: Netzadresse 192.168.129.0/24 Subnetmask: 255.255.255.0
4. (Lila): Konfiguration meherer Projekt V-LANs zur Abgrenzung der einzelnen Webintegrationsprojekte
untereinander. Auch hier ist wieder darauf zu achten, dass nicht das selbe Netz genutzt wird wie für das
blaue oder grüne Interface. Hierbei ist zu beachten, das eine fortlaufende Nummerierung der V-LANs
durchgeführt wird. Da wir 128 Kundenprojekte integrieren wollen, müssen 128 ProjektV-LANs angelegt
werden, je ein eigenes V-LAN für jedes Projekt.
Netzwerkkonfiguration je Projekt V-LAN: Netzadresse 192.168.1.0/24 Subnetmask: 255.255.255.0
3.2.3 Einsatz der virtuellen Maschinen
Viele Hersteller bieten bereits virtuelle Appliances ihrer Software an. Virtuelle Appliances sind auf das
Wesentliche reduzierte Systeme, die nur dazu dienen den vom Hersteller vorgesehenen Dienst zu verrichten, z.B.
Goolge Search Appliances als Indexierungsdienst oder IPCop Appliances als Firewall. Für dieses Konzept
werden folgende Appliances genutzt:
• IPCop Appliance als Firewall und Schnittstelle zum Datacenternetzwerk.
• M0n0wall Appliance als Router und Firewall zur Abgrenzung einzelner Projektnetzwerke untereinander.
• Ubuntu 10.04 mit einem Apache Webserver als Namedbase Reverse Proxy.
• CentOS 5.4 als Projekt Konsole. Diese dient als Verbindungspunkt für die Auftraggeber des Projektes.
Die eigentlichen VMs, die die Webintegration beinhalten, werden nicht via vCenter Server administriert,
da der Auftraggeber keinen Zugriff auf den vCenter Server erhält.
• Nagios als Monitoringlösung.
• Eine Administrations-VM auf Basis von Ubuntu 10.04 zur Administration aller VMs mit
Netzwerkschnittstellen im blauen, grünen und lilanen V-LAN.
3.2.4 Aufbau des Frameworks
Ds folgende Bild zeigt einen schematischen Aufbau, sowie die eingestzten VMs die das Framework bereitstellen
um die Kundenappliances zu integrieren.
3.2.2 Aufbau der V-LANs
13
Abb. 6: Schematischer Aufbau der virtuellen Netze
Auf dem Bild ist sehr gut die Abgrenzung einzelner Projekt V-LANs zu erkennen, die eine Isolation der
Webintegrationen erst ermöglicht.
Da als Berechnungsgrundlage 128 Kundenprojekte vorausgesetzt wurden, besitzt unserere Umgebung 128
Adressen im Datacenternetzwerk (Rot), die an IPCops gebunden sind. Allerdings werden nicht 128 virtuelle
IPCop Appliances benötigt. Diese 128 Adressen werden in Blöcke à 16 IPs aufgeteilt um später Zuweisungen "je
Block" zu ermöglichen. Somit ist z.B. die Zuweisung eines Block zu einer bestimmten Firewallregel möglich, um
ggf. neben dem Intranetzugriff, auch den Zugriff vom Internet aus zu ermöglichen.
Für jeden Block wird ein IPCop verwendet, da man diese 16 Adressen alle auf einen Netzwerkadapter binden
kann (eth0 + eth0:0- eth0:14). Desweiteren wird ein Netzwerkadapter mit dem grünen Netzwerk verbunden. Über
dieses Netz soll das Konfigurations Web-GUI (Graphical User Interface) bereitgestellt werden. Ein direkter
Zugriff auf diese Web-GUI ist nicht von den anderen Netzwerken möglich. Weiterhin erhält der IPCop eine
Netzwerkschnittstelle in das blaue interne Netzwerk, um die Kommunikation mit den restlichen VMs zu
ermöglichen.
Ein ähnlicher Aufbau wird auch für die Reverse Proxys realisiert. Für jeden Block wird ein Reverse Proxy mit
mehreren Apache Instanzen für die einzelnen Projekte aufgesetzt. Auch hier werden 16 IPs, allerdings 16 IPs aus
dem internen Netz, an einen Netzwerkadapter des Reverse Proxy gebunden.
Die M0n0walls erhalten 2 Netzwerkadapter. Einen mit einer IP Adresse im internen Netz (Blau) und eine im
Projekt V-LAN (Lila) Sie arbeiten als Router zwischen den Netzen und erlauben auch nur Zugriffe aus dem
Projekt V-LAN über vorher festgelegt Ports. Jegliche andere Kommunikation vom Projekt V-LAN nach außen (in
3.2.4 Aufbau des Frameworks
14
das interne Netz bzw. in das Datacenternetzwerk) wird durch die M0n0wall geblockt. Weiterhin übernimmt die
M0n0wall die Rolle eines DHCP Servers im Projekt V-LAN.
Die Administrations-VM besitzt 3 Netzwerkschnittstellen, je eine in das blaue, grüne und lilane Netzwerk, wobei
die dDritte Schnittstelle für das lilane Netz frei gebunden werden kann, jenachdem in welchem Projekt V-LAN
man arbeiten möchte. Als Monitoringlösung soll Nagios zum Einsatz kommen. Hier wird aufgrund der
Ausfallsicherheit ein Nagios Cluster mit Heartbeat und DRBD (Distributed Replicated Block Device) verwendet,
mit einer Primary/Secondary Konfiguration. Da in dieser Arbeit die Virtualisierungslösung behandelt werden soll
und nicht die Monitoringlösung einer solchen Umgebung, wird nicht genauer auf diesen Abschnitt eingegangen.
Bei einer solchen Größe sollte ebenfalls ein eigener DNS (Domain Name System) Server für das interne Netz
(Blau) verwendet werden, mit statischen Releases für die stetig genutzen VMs (M0n0wall, Reverse Proxys, u.A.)
Die Projekt Konsolen erhalten eine fest zugewiesene Adresse ohne DHCP, damit diese in allen Projekt V-LANs
gleich ist, und direkt als Weiterleitungsregel in der M0n0wall eingetragen werden kann.
3.2.5 Zugriff auf die Kundenappliances
Es wird zwischen zwei verschiedenen Aufrufen der Webintegration unterschieden:
1. Administrativer Zugriff des Kunden
2. Zugriff auf die Webintegration von Endkunden/Nutzern
Der Zugriff der Endkunden wird wie folgt realisiert:
1. Der Endkunde ruft eine URL (Uniform Ressource Locator) auf.
2. Der DNS Server gibt die Adresse für diese URL zurück. Hierbei handelt es sich um eine IP-Adresse aus
dem Datacenternetzwerk. Diese Adresse ist an einen IPCop gebunden.
3. Der IPCop leitet die Anfrage auf Port 80 an den Reverse Proxy auf dem Blauen Interface weiter. Da
Name-Based Reverse Proxys genutzt werden, wird nun anhand der URL die IP einer M0n0wall ermittelt,
die die angeforderte Webintegration vom Rest des Netzwerkes abgrenzt.
4. Die Anfrage wird an eine M0n0wall auf Port 80 weitergeleitet.
5. Die M0n0wall leitet diese Anfrage an die Kundenappliance, die die Webintegration bereitstellt, weiter.
6. Die Appliance schickt die Antwort über den eben beschrieben Weg zurück an den Endkunden.
Da auch Administrative Zugriffe nötig sind, um ggf. Patches für die in der Appliance verwendeten Software
einzuspielen, muss auch eine Schnittstelle definiert sein, um den Zugriff auf die Shell Konsole oder
Windows/Linux GUI zu ermöglichen. Hierzu wird die Projekt Konsole verwendet. Beispielablauf eines Zugriffes
auf eine Linux Kundenappliance:
1. Verbindung auf die URL oder die IP mit Port 22
2. Der IPCop leitet diese Anfrage weiter an die interne Netzwerk-IP der korrespondierenden M0n0wall mit
Port 22.
3. Diese leitet die Anfrage an die Projekt Konsole, auf der ein SSH Server aktiv ist.
4. Der Kunde gibt die ihm zuvor bereitgestellten Logindaten ein und ist nun auf der Projekt Konsole
eingeloggt.
5. Zugriff auf die Kundenappliance erfolgt nun über einen weiteren SSH Aufruf auf die IP-Adresse der
Kundenappliance im Projektnetzwerk.
Sollte es sich bei der Kundenappliance um ein System mit einer GUI handeln, so muß der Zugriff auf die GUI mit
VNC (Virtual Network Computing) via SSH getunnelt werden.
3.2.5 Zugriff auf die Kundenappliances
15
Alle angegebenen Ports sind Beispielports, bzw. die Standardports der jeweiligen Applikation.
3.2.6 Integration einer neuen Kundenappliance
Im folgenden Abschnitt wird die Integration einer Kundenappliance in das Virtuelle Rechenzentrum beschrieben,
damit im späteren Verlauf Vor- und Nachteile besser aufgezeigt werden können.
Der Kunde liefert eine Readty-to-deploy VM, eine virtuelle Appliance, mit seinem Webdienst. Spezielle
Voraussetzungen, wie z.b. dass die Appliance ihre IP-Adresse per DHCP bezieht, müssen vorher besprochen
werden und vom Kunden umgesetzt werden.
Da VMs wie Reverse Proxy, M0n0wall, IPCop und Projekt Konsole Just-in-time in das Framework integriert
werden, muss nun kontrolliert werden, ob ein weiterer IPCop und Reverse Proxy von einem Template aus erstellt
werden muss, weil man einen neuen 16er Block anfängt, oder ob in den alten Blöcken noch genügend Platz
vorhanden ist.
Fall 1:
Es besteht noch genug Platz in einem alten Block:
• Erstellen einer neuer M0n0wall aus dem Template und Zuweisen einer statischen IP-Adresse vom DHCP
des internen Netzes.
• Erstellen einer Projek Konsole aus dem Template und Konfiguration der Netzwerkkarte auf das neue
Projekt V-LAN.
• Da die meisten Kunden VMs nicht direkt ESXi kompatibel sind müssen diese durch den VMware
Converter in die Umgebung integriert werden.
• Nach der Integration in die Umgebung, wird der Kundenappliance das Projekt V-LAN zugewiesen und
die VM erhält eine DHCP IP-Adresse von der M0n0wall diese Projektes. Diese wird sogleich statisch
gesetzt und kann aufgrund der getrennten Projekt V-LANs bei allen Kundenappliances in den
verschiedenen Projekt V-LANs, gleich sein, um M0n0wall NAT (Network Adress Translation) Regel
schon im Template zu integrieren. Ein Beispiel hierfür wäre die Portweiterleitung von Port 80.
• Beim IPCop werden die Firewall Regeln dahingehend angepasst, dass nun eine SSH oder
HTTP(Hypertext Transfer Protocol)/HTTPS (Hypertext Transport Protocol Secure) Anfrage an die
entsprechende M0n0wall bzw. den Reverse Proxy weitergeleitet wird.
• Beim Reverse Proxy wird eine neue Apache Instanz angelegt, die die Weiterleitung von Anfragen auf
Port 80/443 an die entsprechende M0n0wall übernimmt.
• Test der Verbindung von Außen und ggf. Troubleshooting im Fehlerfall.
• Alle neu erstellen VMs werden mit Hilfe von Scripten automatisch ins Monitoring eingetragen.
• Der Kunde erhält Rückmeldung über die erfolgreiche Integration seiner Appliance, inklusive der
Zugangsdaten zur Projekt Konsole (Externe IP, Login, Password)
Fall 2:
Ein neuer Block muss angelegt werden.
• Ein neuer IPCop wird aus dem Template erstellt und angepasst.
• Ein neuer Reverse Proxy wird aus dem Template erstellt und angepasst.
• Danach werden alle weiteren Schritte aus Fall 1 abgearbeitet.
4 Analyse und Bewertung
3.2.6 Integration einer neuen Kundenappliance
16
Im folgenden Abschnitt erfolgt eine Analyse und Bewertung der technischen Möglichkeiten, sowie eine
ökonomische Betrachtung des Systems.
4.1 Vorteile
4.1.1 technisch
• Volle Kontrolle der Umgebung mit einem Team realisierbar
• Einfache Skalierbarkeit, durch Erweiterung des Clusters mit weiterer Hardware
• Standartisierte VMs erleichtern den Administrationsaufwand
• Rapid Deployment durch Nutzung von Templates, daraus folgt eine sehr kurze Time-to-Market
• Festlegung von externen Firewallregeln für ganze Blöcke möglich
• Ausfallsicherheit durch VMware Meachnismen wie HA, Fault Tolerance und VMotion
• Aufgrund fester Standards (IP-Vergabe, IP-Bereiche, Aufgaben der VMs) leicht automatisierbar/scriptbar
• Gemeinsame Schnittstelle aller VMs und deren Guest OS (Operating System) durch VMware API &
SDK.
• Easy-to-use GUI durch vCenter Server
4.1.2 ökonomisch
• Ressourcenoptimierung durch DRS und DPM
• Besser Auslastung der Hardware
• Geringere Housing/Hostingkosten durch weniger Hardware
• Prozessoptimierte Fehleranalyse, da die gesamte Umgebung von einem Team betreut werden kann und
nicht von mehereren Abteilungen, wie in einem großen Rechenzentrum, was unter Umständen
langwierige Prozesse mit sich bringt.
• Höhere Kundenzufriedenheit aufgrund schnellerer Time-to-Market und besserer Fehleranalyse
4.2 Nachteile
4.2.1 technisch
• Wenig Customizing Spielraum, da für eine Automatisierung viele Standards eingehalten werden müssen.
• Einarbeitung in die VMware CLI erforderlich
• Sehr viel Scriptingaufwand, um die Plattform zu automatisieren und operabel zu gestalten.
• Keine VMware Tools Unterstützung bei einigen Kernkomponenten, z.B. M0n0wall.
4.2.2 ökonomisch
• Hohe Lizenzkosten durch die VMware Lizenzen
• Hohe Schulungskosten für diverse VMware Produkte, da die Schulungen aufeinander aufbauen[27]
• In der Regel ist SAN in Rechenzentren sehr kostspielig
4 Analyse und Bewertung
17
5 Empfehlung
Aufgrund der umfassenden technischen und ökonomischen Vorteile, ist eine oben beschriebene Umgebung
optimal, um Kosten zu sparen.Die anfallenden Lizenz- und Schulungskosten werden von den eingesparten
Energie- und Operatingkosten aufgefangen. Weiterhin wird eine bessere Time-to-Market geboten, da durch die
Reduzierung der Administration der gesamten Umgebung, auf ein Team, Prozesse optimiert werden können.
Diese Lösung verursacht allerdings im Vollausbau, im Vorfeld, einen hohen Infrastrukturaufwand sowie
Lizenzkosten, wodurch eine Umsetzung eher für Großunternehmen/Global Player, ggf. mit eigenem
Rechenzentrum, oder Webserviceprovider/Webhoster geeignet ist.
Dieses Konzept lässt sich allerdings auch auf kleinere Umgebungen übertragen, die nicht über 100
Kundenprojekte hosten wollen. Dabei werden aber einige VMware Features nicht genutzt werden können
(DRS/DPM oder VMotion), aufgrund der hohen Lizenzkosten.
6 Fazit
Mit VMware ist es möglich, aufgrund der zahlreichen Virtualisierungsoptionen, wie VMotion, HA oder DRS,
eine sichere Infrastruktur zur Verfügung zu stellen. Das Konzept der Konsolidierung interner Services in einer
virtuellen Umgebung ist für Unternehmen, die viele interne Services anbieten um ihren externen Service zu
verbessern, sehr gut geeignet, da es skalierbar, adminstrierbar und automatisierbar ist. Die hieraus resultierenden
Konsteneinsparungen, im Hosting, Housing und im Human Ressources Bereich können in neue Projekte investiert
werden. Durch vorgefertigte VMs die rein spezielle Aufgaben übernehmen, ist ein Rapid Deployment und eine
schnelle Time-to-Market realisierbar, was sich positiv auf die Customer Relations auswirkt.
Diese Konzept bietet hohes Erfolgspotential und vorallem Kosteinsparungpotential, sollte es global eingesetzt
werden. Die hieraus eingesparten Energiekosten und der verringerte CO² Ausstoß wären enorm, gemäß dem Fall
jedes Unternehmen mit einem Rechenzentrum oder jeder Global Player im Rechenzentrumsmarkt (wie Google
oder EBay) würden auf dieses Konzept wechseln, um Interne Services abzubilden. Das Konzept zeigt auf, dass es
möglich ist mit 4 ESXi Servern ca. 128 interne Services abzubilden und zu verwalten.
Darüber hinaus, besteht die Möglichkeit dieses Konzept zu erweitern und auf die Datacentervirtualisierung zu
übertragen.
7 Fußnoten
1. ? Vgl. VMware_why(2010)
2. ? 2,0 2,1 Vgl. VMware ESXi Features
3. ? Vgl. VMware Licensing
4. ? 4,0 4,1 4,2 Vgl. VMware DRS Overview
5. ? 5,0 5,1 5,2 5,3 Vgl. VMware DRS Features
6. ? 6,0 6,1 6,2 Vgl. VMware VMotion Overview
7. ? 7,0 7,1 Vgl. VMware VMotion Features
8. ? Vgl. VMware HA Overview
9. ? Vgl. VMware HA Features
10. ? Vgl. VMware ESXi FAQ
11. ? Vgl. VMware API & SDK Documentation
12. ? 12,0 12,1 Vgl. VMware vSphere CLI
13. ? Vgl. PowerCLI Documentation
14. ? http://msdn.microsoft.com/en-us/library/ms714395(VS.85).aspx
5 Empfehlung
18
15. ? Vgl. vSphere PowerCLI Blog EcoShell
16. ? 16,0 16,1 Vgl. EcoShell Product Presentation from Pablo Roesch
17. ? Vgl. VMware SDK for Perl 4.0 Utility Applications Reference
18. ? Vgl. VMware vCenter Features
19. ? Vgl. VMware vCenter Converter Overview
20. ? Vgl. VMware vCenter Converter Features
21. ? 21,0 21,1 Vgl. VMware ESXi 4.0 Installable
22. ? 22,0 22,1 22,2 Vgl. VMware Compatibility Guide
23. ? http://sourceforge.net/apps/trac/ipcop/wiki
24. ? http://www.apache.org/
25. ? http://m0n0.ch/wall/
26. ? VMware Snapshot Overview
27. ? Vgl. VMware Schulung Prerequisites
8 Abkürzungsverzeichnis
Abkürzung
CPU
TB
RAM
NIC
DRS
VM
VMs
DPM
QoS
HA
SSH
CLI
SDK
API
CIM
OVF
VDDK
VMDK
COM
VMCI
cmdlets
IDE
XML
KED
Gb
SCSI
7 Fußnoten
Bedeutung
Central Processing Unit
Terrabyte
Random Access Memory
Network Interface Card
Distributed Ressource Scheduling
Virtuelle Maschine
Virtuelle Maschinen
Distributed Power Management
Quality of Service
High Availbility
SecureShell
Command-Line Interface
Software Development Kit
Application Programming Interface
Common Information Model
Open Virtualisation Format
Virtual Disk Development Kit
Virtual Maschine Disk
Component Object Model
Virtual Maschine Communication Interface
Command-lets
Integrated Development Environment
Extensible Markup Language
Known Error Database
Gigabit
Small Computer System Interface
19
RAID
SATA
USB
DHCP
V-LAN
SAN
NAS
GUI
DRBD
DNS
URL
NAT
VNC
HTTP
HTTPS
OS
Redundant Array of Independent Disks
Serial Advanced Technology Attachment
Universal Serial Bus
Dynamic Host Configuration Protocol
Virtuelles Local Area Network
Storage Area Network
Network Attached Storage
Graphical User Interface
Distributed Replicated Block Device
Domain Name Service
Uniform Ressource Locator
Network Adress Translation
Virtual Network Computing
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Operating System
9 Abbildungsverzeichnis
Abb.-Nr.
1
2
3
4
5
6
Abbildung
Quelle
Übersicht des VMware
http://www.vmware.com/de/products/vsphere/buy/editions_comparison.html 2010-07Lizenzmodells
VMware VMotion
http://www.vmware.com/files_inline/images/DGRM_vSphere_vMotion.gif 2010-07-1
VMware HA
http://www.vmware.com/files_inline/images/DGRM_vSphere_HighAvailability.gif 20
https://vmware.webex.com/vmware/lsr.php?AT=pb&SP=MC&rID=34440042&rKey=
EcoShell
Minute 13:11 2010-07-17 11:18
Hardwareaufbauschema
eines virtuellen
Erstellt von Benjamin Bublitz
Rechenzentrums im
Rechenzentrum
Schematischer Aufbau
Erstellt von Benjamin Bublitz
der virtuellen Netze
10 Tabellenverzeichnis
Tabellen-Nr. Tabelle
Quelle
Auflistung
aller
In Anlehnung an:
Scripte
1
http://www.vmware.com/support/developer/viperltoolkit/viperl40/doc/perl-toolkit-right.html
aus dem
2010-07-17 11:23
SDK for
Perl
8 Abkürzungsverzeichnis
20
11 Literaturverzeichnis
Internetquellen
VMware_why(2010)
VMware ESXi
Features
VMware Licensing
VMware DRS
Overview
VMware DRS
Features
VMware VMotion
Overview
VMware VMotion
Features
VMware HA
Overview
VMware HA
Features
VMware ESXi FAQ
VMware API & SDK
Documentation
VMware vSphere
CLI
VMware PowerCLI
Documentation
VMware vSphere
PowerCLI Blog
EcoShell
EcoShell Product
Presentation from
Pablo Roesch
VMware SDK for
Perl 4.0 Utility
Applications
Reference
VMware vCenter
Features
VMware vCenter
Converter Overview
VMware vCenter
Converter Features
VMware ESXi 4.0
Installable
VMware(Hrsg) Grundlagen der Virtualisierung, "Wozu Virtualisieren?" http://www.vmware.com
VMware(Hrsg) ESXi Featurelist http://www.vmware.com/de/products/esxi/features.html, 10.06.
VMware(Hrsg) Vergleich der vSphere-Editions für mittelständische und große Unternehmen http
VMware(Hrsg) DRS "Übersicht" http://www.vmware.com/de/products/vi/vc/drs_overview.html
VMware(Hrsg) DRS "Features" http://www.vmware.com/de/products/vi/vc/drs_features.html, 14
VMware(Hrsg) VMotion "Übersicht" http://www.vmware.com/de/products/vi/vc/vmotion_overv
VMware(Hrsg) VMotion "Features" http://www.vmware.com/de/products/vi/vc/vmotion_feature
VMware(Hrsg) HA "Übersicht" http://www.vmware.com/de/products/vi/vc/ha_overview.html, 1
VMware(Hrsg) HA "Features" http://www.vmware.com/de/products/vi/vc/ha_features.html, 14.0
VMware(Hrsg) ESXi FAQ http://www.vmware.com/de/products/esxi/uses.html, 10.06.2010 19:0
VMware(Hrsg) VMware APIs and SDKs Documentation http://www.vmware.com/support/pubs
VMware(Hrsg) VMware vSphere Command-Line Interface Documentation http://www.vmware
VMware(Hrsg) VMware vSphere PowerCLI Documentation http://www.vmware.com/support/p
VMware(Hrsg) vSphere PowerCLI Blog EcoShell http://blogs.vmware.com/vipowershell/2009/0
vizioncore(Hrsg) EcoShell Product Presentation from Pablo Roesch
Webex: https://vmware.webex.com/vmware/lsr.php?AT=pb&SP=MC&rID=34440042&rKey=4
Document: http://communities.vmware.com/servlet/JiveServlet/download/2530-222424-1318360
VMware(Hrsg) vSphere SDK for Perl 4.0 Utility Applications Reference http://www.vmware.co
(Frei übersetzt von Benjamin Bublitz), 24.06.2010 16:13
VMware(Hrsg) vCenter "What's New in VMware vSphere 4.0" http://www.vmware.com/suppor
VMware(Hrsg) vCenter Converter Overview http://www.vmware.com/products/converter/overv
VMware(Hrsg) vCenter Converter Features http://www.vmware.com/products/converter/features
VMware(Hrsg) "Erste Schritte mit ESXi Installable" http://www.vmware.com/files/de/pdf/vsp_4
21
VMware
Compatibility Guide
VMware(Hrsg) "Search the VMware Compatibility Guide" http://www.vmware.com/resources/c
VMware Snapshot
Overview
VMware(Hrsg) "Understanding virtual machine snapshots in VMware ESX"
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&external
05.07.2010 17:56
VMware Schulung
Prerequisites
VMware(Hrsg) "Course Description for VMware vSphere: Troubleshooting [V4]" http://mylearn
22

Inhaltsverzeichnis

Transcrição

Documentos relacionados

Städtische Kliniken Neuss, Lukaskrankenhaus GmbH

Virtueller Rechner selbstgemacht

Zum Einsatz kostenloser VMware

- 2 - Bürgermeisteramt Iffezheim Herr Gerold Peter Hauptstr. 54

jbl vertec 4886 - Absolut

Migration Suite für Server -

IOMEGA® STORCENTER™ ix4-200d NAS-Server

Installationsanleitung - ONLINE USV

Broadcasting IT

Einführung in VMware vSphere