Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Virtuelle Maschinen im Unternehmen
3 Virtualisierungssoftware – eine Marktübersicht
4 Auswahl der möglichen virtuellen Maschine
5 Auswahl der richtigen Virtualisierungssoftware
6 Auswahl der richtigen physikalischen Infrastruktur
7 Installation und Update des Wirt-Systems
8 Verwaltung der Virtualisierungssoftware
9 Virtuelle Netzwerke
10 Virtuelle Festplatten
11 Erstellung einer virtuellen Maschine
12 Verwaltung der virtuellen Maschinen
13 VMware VirtualCenter
14 Skriptierung und Programmierung unter VMware und MS Virtual Server
15 Backup, Restore und Disaster Recovery
16 Templates (VM-Vorlagen)
17 Zusatzsoftware
18 Nützliche Adressen im Web
A Clustereinrichtung und Beispielumgebungen
B Kommandozeile und wichtige Dateien
C Häufige Fragen
Stichwort

Download:
- ZIP, ca. 17,5 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
VMware und Microsoft Virtual Server von Dennis Zimmer
Virtuelle Server im professionellen Einsatz
Buch: VMware und Microsoft Virtual Server

VMware und Microsoft Virtual Server
geb., mit CD
612 S., 49,90 Euro
Galileo Computing
ISBN 978-3-89842-701-2
Pfeil 6 Auswahl der richtigen physikalischen Infrastruktur
Pfeil 6.1 Hardware
Pfeil 6.1.1 Wichtigkeit der Entscheidung
Pfeil 6.1.2 Unterstütze Hardware
Pfeil 6.1.3 Zwei-, Vier- oder »Mehr«-Wege-Systeme?
Pfeil 6.1.4 Hersteller
Pfeil 6.1.5 Hardwaretest
Pfeil 6.2 Sizing der Wirt-Systeme
Pfeil 6.2.1 Messdaten und Verfügbarkeit
Pfeil 6.2.2 Prozessor
Pfeil 6.2.3 Hauptspeicher
Pfeil 6.2.4 Massenspeicher
Pfeil 6.2.5 Netzwerkanbindung
Pfeil 6.3 Infrastruktur
Pfeil 6.3.1 Massenspeicher
Pfeil 6.3.2 Netzwerke


Galileo Computing - Zum Seitenanfang

6.2 Sizing der Wirt-Systeme Zur nächsten ÜberschriftZur vorigen Überschrift

Bevor Sie irgendwelche Aussagen über ein Sizing der benötigten Maschinen treffen können, bedarf es einiger Vorbereitungen. Sie müssen sich zunächst darüber im Klaren sein, welche Maschinen Sie überhaupt in eine virtuelle Umgebung integrieren möchten.

Wie Sie die benötigte Performance Ihrer potenziellen Maschinen messen können, haben Sie bereits in Abschnitt 4.2, Performancemessung, gelesen. Nun müssen Sie diese Messungen in ein Konzept übernehmen, mit dem Sie die Gesamtzahl Ihrer Serversysteme und deren Sizing planen können.


Galileo Computing - Zum Seitenanfang

6.2.1 Messdaten und Verfügbarkeit Zur nächsten ÜberschriftZur vorigen Überschrift

Um eine gute Planung zu gewährleisten, müssen Sie Ihre physikalischen Systeme über mehrere Wochen beobachten und die Messungen erfassen. Wie bei den Hardwaretests gilt auch hier: Je länger Sie diese Messungen durchführen, um so genauer wissen Sie, mit welcher Auslastung Sie auf dem endgültigen System zu rechnen haben.

Schwierig, ja gar unmöglich ist dies natürlich bei Systemen, die noch gar nicht angeschafft sind, aber in die virtuelle Welt übernommen werden sollen. In diesem Fall können Sie nur auf Erfahrungswerte anderer Unternehmen bauen, die vielleicht dieses Produkt schon einsetzen, oder Sie müssen sich auf einen ungefähren Richtwert seitens des Herstellers verlassen. Da mittlerweile viele Hersteller selbst ihre Software auf virtuellen Systemen testen, können Sie sogar darauf bauen, dass die Messwerte durchaus realistisch sind. Wenn Sie alle Werte beisammen haben, nehmen Sie diese am besten in eine Liste auf und versuchen anschließend, die ausgewiesenen »Hardwarefresser« mit solchen Systemen zu mischen, deren Auslastung weniger hoch ausfällt.

Etwaige Cluster ihrer virtuellen Maschinen, auf die wir im weiteren Verlauf dieses Buches noch kommen werden, sollten natürlich nicht auf ein und demselben Wirt-System laufen. Dasselbe gilt für sämtliche Server, die sie sich bei einem Ausfall wechselseitig vertreten sollen. Denn Hardwaredefekte sind in der virtuellen Welt durchaus real, wenn es auch nie die Hardware in der virtuellen Maschine treffen kann, die des Wirt-Systems, wie ich schon ausführlich beschrieben habe, jedoch sehr wohl.

Im Folgenden präsentiere ich Ihnen zwei kleine Grafiken, die zum besseren Verständnis beitragen sollen. Dabei soll die Auslastung in Prozent die Gesamtauslastung darstellen, die durch die virtuelle Maschine auf dem Wirt-System verursacht wird.

Abbildung 6.5 Was ist hier falsch?

Ich nehme an, bei genauerem Hinsehen bemerken Sie sofort, auf was ich hinaus will bzw. wo die Planungsfehler stecken. So sollten Sie Ihre virtuellen Maschinen auf keinen Fall verteilen! Die virtuellen Maschinen mit geringer Auslastung liegen auf Wirt-System 1 und dümpeln vor sich hin, während Wirt-System 2 doch schon recht hoch belastet wird.

Auch sind die beiden Clusterserver auf demselben Wirt-System beheimatet. Damit macht der Cluster nicht mehr ganz soviel Sinn, da nur der Ausfall des virtuellen Clusterteilnehmers abgefangen wird und nicht der des Wirt-Systems.

Abbildung 6.6 So ist die Verteilung in Ordnung

In dieser Grafik ist die Welt wieder in Ordnung! Die Auslastung ist gleichmäßig verteilt, und die Clustersysteme sind auf unterschiedlichen Wirt-Systemen beheimatet. (Dieses Cluster-Konstrukt ist nicht mit jeder Virtualisierungssoftware möglich.) Dieses Beispiel ist zwar recht plakativ, aber in der Realität kann man während der Planung solche Aspekte leicht vergessen. Grundsätzlich lässt sich die Auslastung des Systems in vier große Kategorien aufteilen, deren Wichtigkeit von Server zu Server unterschiedlich ist:

  • Anzahl und Leistungsfähigkeit der Prozessoren
  • Größe des benötigten Hauptspeichers
  • Anbindung und Anzahl der Wege zu einem Massenspeicher
  • Anbindung und Anzahl der Wege zum Netzwerk

Auf den nächsten Seiten werde ich genauer auf jede dieser Kategorien eingehen. Eine genaue Qualifizierung kann ich allerdings nicht leisten, weil jedes Unternehmen andere Serversysteme benötigt bzw. bevorzugt. Dies zu tun, wäre dann z. B. die Aufgabe einer Projektgruppe.


Galileo Computing - Zum Seitenanfang

6.2.2 Prozessor Zur nächsten ÜberschriftZur vorigen Überschrift

Die Ermittlung der benötigten Leistungsfähigkeit der Prozessoren ist wahrscheinlich das geringste Problem, da die Berechnung, sofern man über entsprechende Messwerte aus einem längeren Zeitraum verfügt, nicht besonders kompliziert ist. Diese Kennzahl summieren Sie einfach von allen virtuellen Maschinen, die für einen Server vorgesehenen sind, und schon kennen Sie die benötigte Prozessorleistung auf dem Wirt-System.


Vergessen Sie nicht, dass das Wirt-System einen so genannten »Virtualisierungsoverhead« benötigt. Im Falle von VMware GSX und Microsoft Virtual Server kann dieser Overhead zwischen 7 % und 20 % der Leistung des Wirt-Systems in Anspruch nehmen. VMware ESX benötigt ein bisschen weniger Leistung, weil das Host-Betriebssystem daraufhin optimiert wurde.


Beispiel:

Es sollen sechs physikalische Systeme virtualisiert werden. Alle Server sind Zwei-Wege-Systeme mit einer Prozessorleistung von einem GHz. Die Prozessorauslastung liegt auf vier Servern bei ca. 15 %, auf den beiden anderen bei etwa 18 %. Die dafür nötigen Formeln haben Sie bei der Berechnung des Gast-Systems schon kennen gelernt (Abschnitt 4.2.2, Berechnung der virtuellen Maschine):

  • (1000 * 2) * 15 % = 300 * 4 = 1200 MHz
  • (1000 * 2) * 18 % = 360 * 2 = 720 MHz
  • 1200 + 720 = 1920 MHz

Wie man sieht, würde man theoretisch mit einem 2 GHz Prozessor für die virtuellen Maschinen auskommen. 2,4 GHz sollten es dann insgesamt doch schon sein, da es den Virtualisierungsoverhead des Wirt-Sstems einzurechnen gilt. Einen gewissen Puffer sollte man zur Sicherheit auch noch mit einplanen. Man kann diesen Overhead nicht oft genug erwähnen, weil er sehr gerne unterschlagen wird.


TIPP
Idealerweise sollte man bei der Verwendung eines VMware ESX Servers eine weitere CPU einkalkulieren, da auf CPU0 immer die ServiceConsole mitbetrieben wird und daher nicht komplett nutzbar ist. Dadurch schafft man sich eine gewisse Ressourcensicherheit und eine Reserve für die Zukunft. Dies ist klar eine Empfehlung und kein Muss!


Galileo Computing - Zum Seitenanfang

6.2.3 Hauptspeicher Zur nächsten ÜberschriftZur vorigen Überschrift

Die Menge des benötigten Hauptspeichers ist natürlich ebenso leicht zu berechnen. Man summiert einfach die benötigte Hauptspeichermenge pro virtueller Maschine, die auf dem Wirt-System laufen muss. Sicherheitshalber sollte man aber auch hier einen gewissen Puffer einplanen, da vielleicht einmal eine zusätzliche virtuelle Maschine auf das System gelegt wird oder eine vorhandene virtuelle Maschine ein wenig mehr Speicherplatz benötigt.

Auch hier gilt es, das Wirt-System nicht zu vergessen.

Je nach Produkt und Anzahl der virtuellen Maschinen können zwischen 256 und 1 GB Hauptspeicher benötigt werden. Zudem entsteht auch hier, abhängig von der Hauptspeichermenge der virtuellen Maschine, ein Virtualisierungsschwund, also ein Hauptspeicherbereich, der vom Wirt-System für das Betreiben der virtuellen Maschine benötigt wird und den Sie beim Sizing des Wirt-Systems mit einplanen müssen.

Dieser Schwund bewegt sich bei allen Virtualisierungsprodukten in ähnlichen Dimensionen. Zahlen existieren jedoch nur von VMware ESX.


Tabelle 6.1 Virtualisierungsoverhead bei virtuellen Maschinen

Hauptspeicher VM Virtualsierungsoverhead durch das Wirt-System

bis zu 512 MB, 1 virt. CPU

54 MB

bis zu 512 MB, 2 virt. CPU

64 MB

bis zu 1000 MB, 1 virt. CPU

70 MB

bis zu 2000 MB, 1 virt. CPU

102 MB

bis zu 3600 MB, 1 virt. CPU

134 MB


Man kann also für die ersten 512 MB 54 MB Overhead rechnen, ab dann für jedes weitere Gigabyte jeweils 32 MB. Das Produkt VMware ESX bietet noch zwei interessante Techniken, um Hauptspeicher zu sparen.

Memory Sharing und Memory Overcommitment

Beim »Memory Sharing« teilen sich die virtuellen Maschinen gemeinsame Speicherinhalte. Im Falle eines Terminalservers in einer virtuellen Maschine mit 10 Benutzern, starten diese 10 Benutzer die Windows-Oberfläche und Microsoft Office. Normalerweise werden diese Prozesse dann 10 Mal gestartet, obwohl die Speicheradressen und die Inhalte zum großen Teil identisch sind.

Beim Memory Sharing werden diese gleichen Speicherbereiche nur einmal durch den VMware ESX Server vorgehalten, insofern sparen Sie mindestens 9 mal Speicher, was bis knapp über 30 % des physikalischen Hauptspeichers im Wirt sparen kann. Durch »Memory Overcommitment« haben Sie die Möglichkeit, allen virtuellen Maschinen insgesamt mehr Speicher zur Verfügung zu stellen, als dem VMware ESX Server physikalisch zur Verfügung steht. Falls der physikalische Speicher wirklich einmal aufgebraucht ist, wird auf die Festplatte ausgelagert.


Galileo Computing - Zum Seitenanfang

6.2.4 Massenspeicher Zur nächsten ÜberschriftZur vorigen Überschrift

Wie immer kommt es auch hier darauf an, welche virtuellen Maschinen auf dem Wirt-System laufen sollen und für welches Virtualisierungsprodukt Sie sich entscheiden. Um den Gesamtbedarf an Plattenplatz zu errechnen, summieren Sie wieder den Plattenplatz aller virtuellen Maschinen.

Bei der benötigten I/O-Leistung sollten die Messdaten wieder über einen möglichst langen Zeitraum erfasst und summiert werden. I/O-intensive virtuelle Maschinen sollten ähnlich wie die Prozessor- und Hauptspeicherlast gut über die Wirt-Systeme verteilt werden. Auch hier darf das Wirt-System nicht vergessen werden! Sie benötigen genügend Platz für die Installation des Betriebssystems und des Auslagerungsbereiches. Dieser so genannte »Swap«-Bereich berechnet sich in den meisten Fällen folgendermaßen:

physikalischer Hauptspeicher * 1,5

Bei den Serverprodukten VMware GSX und Microsoft Virtual Server genügt diese Einstellung auch. VMware ESX kann dort andere Wege gehen, denn wegen der Zweiteilung zwischen Service Console (eigentliches Betriebssystem) und VMkernel (Kernel für die Verwaltung der virtuellen Maschinen und deren Ressourcen) haben beide einen getrennten Swap-Bereich. Der Swap-Bereich der Service Console errechnet sich wie der eines normalen Betriebssystems.

VMkernel hat andere Möglichkeiten: entweder keinen Swap (kein Memory Overcommitment möglich) oder soviel Swap, wie Sie den virtuellen Maschinen zum Auslagern geben möchten, jedoch maximal die Größe des physikalischen Hauptspeichers. Falls das System physikalisch 8 GB Hauptspeicher besitzt, können Sie maximal nochmals 8 GB als VMkernel Swap zur Verfügung stellen, d. h., für die virtuellen Maschinen können Sie 8 GB Hauptspeicher durch Memory Overcommitment konfigurieren. Das von den 8 GB ein Teil an das Wirt-System abgetreten wird, erwähne ich nur zur Erinnerung. Darüber hinaus müssen Sie sich Gedanken machen, ob Sie normale lokale SCSI-Platten oder ein SAN zur Verfügung stellen wollen.

Vielleicht wollen Sie aber auch ganz andere Wege gehen. Als hoffentlich guter Ratgeber führe ich im Folgenden die einzelnen Systeme auf und kommentiere sie jeweils kurz:

  • IDE
    Im Testbereich für VMware GSX oder Microsoft Virtual Server noch vertretbar, im produktiven Bereich sollten Sie die Finger davon lassen. Sie benötigen schließlich performante Platten, damit sich die virtuellen Maschinen nicht ständig gegenseitig ausbremsen. Bei VMware ESX funktioniert nur ein CD-Laufwerk mit IDE, Festplatten können keine angebunden werden!
  • S-ATA
    VMware GSX und Microsoft Virtual Server lassen sich damit betreiben. Da die Performance immer besser wird, kann man bei kleineren Systemen auch gute Erfahrungen machen. SCSI ist allerdings im Serverbereich immer noch Quasi-Standard. VMware ESX verweigert auch hier den Zugriff auf S-ATA-Festplatten, weil die Treiberunterstützung fehlt.
  • SCSI
    Alle drei Produkte geben sich mit SCSI zufrieden und bei moderner Hardware ist eine entsprechende Leistungsfähigkeit zu erwarten. Sie sollten aber trotzdem darüber nachdenken, die Platten über mehrere Controller anzubinden, um die Performance für die virtuellen Maschinen weiter zu steigern. Darüber hinaus ist es überaus empfehlenswert, RAID über die lokalen SCSI-Festplatten zu legen.
  • NAS
    VMware GSX und Microsoft Virtual Server unterstützen NAS-Systeme, allerdings kann ich davon nur abraten, weil die Performance der virtuellen Maschinen doch sehr darunter leiden kann. Aufgrund der Geschwindigkeitsproblematik bei der NAS-Technologie sollte beim Einsatz mindestens eine dedizierte Gbit-Netzwerkanbindung eingerichtet werden.
    Zudem schlagen sich Performanceprobleme im Netzwerk gleich doppelt nieder: einmal bzgl. der Festplattenzugriffe der virtuellen Maschinen und einmal bzgl. der Netzwerkzugriffe der virtuellen Maschinen und des Wirt-Systems.
  • iSCSI
    iSCSI ist die neueste Technik, Massenspeicher mit Systemen zu verbinden. Dabei wird nicht wie bei einem NAS Storage ein Netzwerkprotokoll benutzt, sondern SCSI-Befehle werden direkt über das Netzwerk transportiert. Damit ordnet sich ein iSCSI-System von seiner Performance, seiner Flexibilität und seinem Preis her gesehen mittig zwischen NAS und SAN ein. Im Betriebssystem selbst werden iSCSI-Festplatten wie lokale Festplatten gesehen und können auch dementsprechend eingebunden werden. Über spezielle Netzwerkkarten kann sogar über eine iSCSI-Festplatte das Betriebssystem gestartet werden. Um eine hohe Leistungsfähigkeit zu erhalten, ist eine dedizierte Gbit-Netzwerkverbindung ebenso wie bei NAS unumgänglich. Dass diese Technologie Zukunft hat, sieht man schon an den neuen Funktionen des aktuellsten VMware GSX Servers. Er unterstützt seit Version 3.2 Cluster-across-Boxes der virtuellen Maschinen über iSCSI. Unter VMware ESX wird iSCSI derzeit nur innerhalb der virtuellen Maschine und nicht durch die Service Console unterstützt.
  • SAN
    Es ist dies ganz klar die Königsklasse der Speichersysteme. Mit diesem System stehen Ihnen alle Möglichkeiten offen. Performante Anbindung des Wirt-System und der virtuellen Maschinen kann sehr leicht realisiert werden. Sie können sogar virtuellen Maschinen physikalisch ein LUN im SAN zur Verfügung stellen! Natürlich hat auch SAN einen Haken, und der liegt in der sehr komplexen Administration und Planung. Des Weiteren wären da die hohen Kosten, es müssen nämlich nicht nur die Festplatten des Storages, sondern es muss vielmehr eine ganze Infrastruktur geschaffen werden.
    Bei VMware ESX haben Sie über VMotion die Möglichkeit, während der Laufzeit eine virtuelle Maschine ohne Ausfall von einem ESX Server zu einem anderen hin zu übertragen. Voraussetzung hierbei ist, dass beide ESX Server die LUN sehen, auf der die Festplatte der virtuellen Maschinen liegt. Seit Version 2.5 kann diese LUN direkt an die virtuelle Maschine gebunden und VMotion betrieben werden. Damit wird Ihnen auch die Möglichkeit eröffnet, einen Cluster zwischen physikalischer und virtueller Maschine einzurichten. Wie das genau abläuft, erfahren Sie im weiteren Verlauf des Buches.

VMware ESX und SAN

Ganz wichtig und leider immer wieder Anlass zur Irritation ist die optimale Größe der LUNs. Hier sind die routinierten SAN-Administratoren oft nicht in der Lage, die neue virtuelle Technologie, wie Sie von VMware benutzt wird, zu verstehen. Normalerweise geht man als SAN-Admin davon aus, dass es sich bei virtuellen Maschinen um I/O-intensive Anwendungen handelt und daher möglichst kleine LUNs benötigt werden. Solche kleinen LUNs werden beispielsweise für Datenbanken genutzt, um die SAN-Leistung zu erhöhen. VMware ESX arbeitet aber anders mit einem SAN. Zum einen gibt es die eigene Verwaltung der SAN LUNs der ESX Server untereinander, d. h., alle betroffenen ESX Server sehen alle verwendeten LUNs! Die Sperrmechanismen, die den gleichzeitigen Zugriff mehrerer Systeme verhindern sollen, werden durch die ESX Server selbst geregelt, weshalb eine gerade benutzte Festplattendatei (aktive VM) z. B. nicht gesichert werden kann.

Zum anderen ist ein ESX Server nicht auf kleine LUNs angewiesen, um eine hohe Performance innerhalb der virtuellen Maschinen bereitzustellen. Hier ist nicht die Größe der LUNs, sondern die Anzahl der darauf liegenden Festplattendateien und deren I/O-Last ausschlaggebend. Bei sehr I/O-lastigen virtuellen Maschinen sollte man ca. 10 – 32 Festplattendateien in ein VMFS legen (was allerdings nicht mit der Anzahl der LUNs gleichzusetzen ist, da ein VMFS sich auch über mehrere LUNs erstrecken kann). Bei I/O-unkritischen virtuellen Systemen kann man mit bis zu 100 Festplattendateien kalkulieren. Daher kann es je nach Größe der Festplattendateien Ihrer virtuellen Maschinen durchaus Sinn machen, wenige große LUNs zu nutzen. Ein weiterer Nachteil vieler kleiner LUNs ist die Geschwindigkeit innerhalb VMware ESX. Bei sehr vielen LUNs kann das Scannen im SAN durch den ESX Server sich über einen mehrstelligen Minutenbereich erstrecken, was die Administration nicht gerade unterstützt.

RAID

Ganz gleich für welches System Sie sich entscheiden: Sie sollten für die Festplatten RAID (Redundant Array of inexpensive Disks) konfigurieren, um eine hohe Sicherheit und Performance des Wirt-Systems zu gewährleisten. Mangelnde Kenntnis bei der Konfiguration des RAID Levels und der daran beteiligten Anzahl an Festplatten kann zu unerfreulichen Effekten führen, die teilweise so nicht vermutet werden. Falls Sie beispielsweise mit zehn lokalen Festplatten arbeiten und daraus eine RAID Set mit RAID5 legen, sind Performanceprobleme vorprogrammiert. Dies ist zwar ein Extrembeispiel, zeigt Ihnen aber auf, worauf Sie zu achten haben. Vorweg ein kleiner Überblick über die Eigenschaften der RAID Level.


Tabelle 6.2 RAID Level im Vergleich

RAID Level Ausfallsicherheit Leseleistung Schreibleistung Platzverbrauch

RAID 0

keine

gut

sehr gut

minimal

RAID 1

hoch

schlecht

schlecht

hoch

RAID 10

sehr hoch

sehr gut

gut

hoch

RAID 5

hoch

gut

sehr schlecht

gering


Auf RAID0 gehe ich nicht genauer ein, da dieses RAID Level sich aufgrund der mangelnden Ausfallsicherheit nicht für den professionellen Serverbetrieb eignet.

  • RAID1
    Hierbei handelt es sich um ein gespiegeltes System. Es werden auf zwei Festplatten identische Daten gespeichert. Damit erhält man eine 100-prozentige Redundanz. Wenn eine der beiden Festplatten ausfällt, arbeitet die zweite Festplatte normal weiter. Diese hohe Ausfallsicherheit macht nur in kleineren Plattensystemen Sinn, da immer die doppelte Festplattenmenge benötigt wird, was hohe Kosten verursacht und ein Platzproblem innerhalb des Servers entstehen lässt.
  • RAID5
    Dies ist die beliebteste RAID-Methode der letzten Jahre. Sie benötigen mindestens drei identische Festplatten. Nun werden auf alle Festplatten so genannte Paritäts-Daten verteilt, die zur Wiederherstellung einer der Festplatten dienen. Bei n Festplatten sind (n-1)/n der Gesamtkapazität nutzbar, das restliche 1/n wird für die Paritätsdaten benötigt. Dadurch erreicht man immer noch eine gute Lesegeschwindigkeit, allerdings leidet die Schreibgeschwindigkeit gegenüber den meisten anderen RAID Leveln deutlich. Die Schreibgeschwindigkeit liegt sogar unter der von RAID0. Als größter Vorteil gegenüber RAID1 erweist sich, dass Sie deutlich weniger Kapazität »standby« und ungenutzt vorhalten müssen und damit bei gleicher Kapazität weniger Festplatten benötigen.
  • RAID10
    Dies ist die Kombination zwischen RAID0 und RAID1. RAID0 fasst einfach mehrere Festplatten zu einer zusammen und erhöht dadurch die Schreib- und Leseperformance auf ein Maximum. Man hat allerdings keinerlei Ausfallsicherheit. Bei RAID10 mischt man nun beides. Man fasst beispielsweise zwei 73 GB-Festplatten zu einer 146 GB-Festplatte zusammen und baut die gleiche Anzahl Festplatten zum Spiegeln per RAID1 ein.

Fazit

Für den produktiven Einsatz sind momentan nur SCSI- und FibreChannel-Karten zu empfehlen, da mit ihnen eine deutlich bessere I/O-Leistung zu erreichen ist. Wie schon erwähnt, werden von VMware ESX auch keine anderen Technologien unterstützt. Zudem sollten Sie sich ein an Ihre Gegebenheiten angepasstes RAID-Konzept überlegen, welches das Wirt-System und damit auch die virtuellen Maschinen leistungsgerecht abdeckt.

Sie sollten sich allerdings Gedanken darüber machen, wie viele Karten in das Wirt-System eingebaut werden. Wegen der erhöhten Ausfallsicherheit und Performance sollten dies mehrere sein. Vor allem bei Verwendung eines SAN-Systems ist es sehr empfehlenswert, durch mehrere FibreChannel-Karten verschiedene Wege anzubinden.

Gerade bei einer Virtualisierung hängt die Performance aller virtuellen Maschinen von dieser Entscheidung ab, da nur die Anbindung des Wirt-Systems zur Verfügung steht. Bei VMware ESX ist es seit Version 2.5 möglich, das komplette Wirt-Betriebssystem aus dem SAN zu booten. Dies ist hauptsächlich für Blades interessant, da man sich vielleicht die internen Platten sparen möchte, um mehr Blades ins Bladecenter integrieren zu können. Hintergrund ist, dass bei einer SCSI-Festplattenerweiterung meist ein weiteres Bay (Einschub für einen Bladeserver) wegfällt. Über den Sinn kann man streiten, ich persönlich bin kein Freund dieser Technik, weil bei einem Ausfall der FibreChannel-Karten eine Fehlersuche kaum möglich wäre. Man müsste zwingend zunächst über Boot-CD ein Betriebssystem booten, um etwas testen und überprüfen zu können.

Vermeiden sollte man einen SAN-Boot, wenn man virtuelle Maschinen clustern möchte oder man eine LUN direkt über das VMFS-Dateisystem anbinden will. Die gesamte Performance kann auch unter solch einer Konfiguration leiden, da sich Wirt-System und virtuelle Maschinen wenige FibreChannel-Adapter teilen müssen.

Klare Empfehlung meinerseits: Verzichten Sie nicht auf lokale SCSI-Festplatten, und trennen Sie möglichst Wirt-System-Adapter von den Adaptern für die virtuellen Maschinen, um eine maximale Performance sicherzustellen.


TIPP
Sollten Sie einen recht performanten Server besitzen, der trotzdem ständig an die Grenzen seiner Prozessorkapazität stößt, dann muss dies nicht zwingend mit dem Prozessor zu tun haben. Hier kann es durchaus an Hauptspeicher mangeln, denn Auslagern verursacht viel Prozessorlast. Oder aber es gibt ein Problem mit den Festplatten, die evtl. nicht leistungsfähig genug sind. Sie merken, nicht alle Ressourcenmängel sind leicht zu finden, und man muss auch mal um die Ecke denken. Falls Sie selbst mit der Einschätzung von Leistungsengpässen Probleme haben, scheuen Sie sich nicht, externe Berater ins Haus zu holen, deren Erfahrung Ihnen im Endeffekt Geld und Ärger ersparen kann.


Galileo Computing - Zum Seitenanfang

6.2.5 Netzwerkanbindung topZur vorigen Überschrift

Hier gilt, je mehr physikalische Netzwerkkarten desto mehr Möglichkeiten. So simpel sich dieser Satz liest, um so schwieriger ist seine Umsetzung. Gerade in kleinen Serversystemen oder Blades gibt es keinerlei Möglichkeiten, allzu viele Netzwerkkarten einzubauen. Man muss sich darüber hinaus Gedanken über die Netzwerkstruktur der virtuellen Maschinen machen.

Sollen alle im gleichen physikalischen Netzwerk liegen oder will man eine Trennung einrichten? Sollen mehrere virtuelle Netzwerke definiert werden, die einzelne physikalische Netzwerkkarten adressieren? Arbeitet man mit mehreren physikalischen Adaptern oder mit VLANs, die von VMware ESX sehr gut unterstützt werden. Wenn sehr viele virtuelle Maschinen auf demselben virtuellen Netzwerk arbeiten sollen, dann sollte man über eine Bündelung mehrerer physikalischer Netzwerkadapter nachdenken.

Die Empfehlung von VMware selbst für die Mindestanforderung an das Netzwerk bei VMware ESX sind zwei Netzwerkkarten, falls VMotion eingesetzt wird, sind es drei:

  • VMware Konsole
  • VMware ESX VMKernel (Ressourcen für virtuelle Maschinen)
  • VMotion (Netzanbindung die dediziert zwischen den ESX-Servern verwendet wird, um die virtuellen Maschinen zu verschieben)

Aber was wäre die Welt ohne Ausnahmen.

Bei manchen Blades hat man keine Möglichkeit, drei Netzwerkkarten zur Verfügung zu stellen, oder will es aufgrund des erhöhten Platzbedarfs nicht. Um dieses Problem aus der Welt zu schaffen, können bei VMware ESX die beiden physikalische Netzwerkkarten gebündelt und zwischen Service Console und VMkernel aufgeteilt werden. Falls nur eine Netzwerkkarte zur Verfügung steht, hat man diese Möglichkeit zwar auch, aber durch den zu erwartenden Performanceeinbruch, sollte man von einer solchen Lösung absehen. Die Netzwerkanbindung sollte möglichst über Gigabit realisiert werden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Aktuelle Bücher von
  Dennis Zimmer
Zum Katalog: VMware ESX 3.5 Automatisierung, Befehle, Scripting





 VMware ESX 3.5
 Automatisierung,
 Befehle, Scripting


Zum Katalog: VMware Infrastructure 4





 VMware
 Infrastructure 4


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Xen Das umfassende Handbuch






 Xen
 Das umfassende
 Handbuch


Zum Katalog: Windows Server 2008






 Windows Server 2008


Zum Katalog: Office SharePoint Server






 Office SharePoint
 Server


Zum Katalog: Exchange Server 2007






 Exchange Server 2007


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de