Also gut, ich möchte anfangen, mein SAN etwas stärker zu nutzen als bisher und gleichzeitig die Vorteile von ESXi nutzen.
Derzeit habe ich ein Array von Dell PowerEdge 1955 Blades, die an ein EMC AX4-5 FC-Speicherarray mit Einzelgehäuse angeschlossen sind. Ich verwende das SAN im Wesentlichen als DAS. Ich habe LUNs auf dem SAN, die auf bestimmte physische Maschinen zeigen, und diese Maschinen verwenden die LUNs für was auch immer (meistens Datenbanken und Samba/NFS-Freigaben, abhängig vom Zielserver).
Ich habe mehrere physische Dateiserver, und jeder hat eine Samba-Konfiguration, um die entsprechenden Freigaben bereitzustellen. Da ich RHCS nie zum Laufen gebracht habe, sind die LUNs immer nur auf einem der Dateiserver gemountet. Falls ein Dateiserver ausfällt, sperre ich ihn manuell (entweder indem ich das Laufwerk aushänge und nicht mehr präsentiere, das Navisphere-Dienstprogramm verwende oder indem ich die Stromversorgung über DRAC abschalte) und verwende dann das Navisphere-Dienstprogramm, um die präsentierten LUNs auf dem nächsten Konkurrenten zu aktivieren (und starte danach Apache und die anderen Daemons). Im Moment alles manuell.
Ich fühle mich ein bisschen wie Ferris Bueller, der Klarinette spielt. Ich hatte nie Unterricht!
Wie auch immer, ich versuche, mich zu verbessern. Ich möchte ESXi auf den physischen Hosts installieren und dann LUNs erstellen, um zwei Dateiserver-Images zu speichern (falls eines beschädigt wird/ausfällt), von denen eines das aktive und das andere das Standby-Image sein wird. Zumindest verbessere ich auf diese Weise nicht die Automatisierung (obwohl ich bald dazu komme, ein Skript zum Wechseln des „aktiven“ Servers zu schreiben), aber ich habe das Gefühl, dass ich Flexibilität hinzufüge. Außerdem kann ich die ESXi-Hosts verwenden, um andere VMs zu speichern, und die Hardware wird nicht verschwendet, wie es jetzt der Fall ist.
Meine Fragen sind:
1) Wie dumm ist mein Plan?
2) Wenn es um die eigentliche Implementierung geht, sollte ich ein normales VMDK-Image auf der LUN erstellen oder sollte ich ihm eine „rohe“ Partition geben (falls das mit ESXi überhaupt möglich ist?)
3) Gibt es eine „gute“ Möglichkeit, nicht geclusterte Dateiserver zu verwenden?
Antwort1
Ihr Plan ist nicht verrückt. Wie üblich gibt es mehrere Möglichkeiten, dies anzugehen, je nachdem, was Sie erreichen möchten und wie Sie Ihre Daten schützen möchten.
Zunächst können Sie einer VM mithilfe eines „Raw Device Mapping“ eine Raw-LUN präsentieren. Gehen Sie dazu wie folgt vor:
- Präsentieren Sie die LUN dem ESXi-Host (oder der Hostgruppe, wenn Sie Clustering/HA verwenden möchten).
- Fügen Sie Ihrer VM eine Festplatte hinzu, wählen Sie Raw Device Mapping und zeigen Sie auf die LUN
- Scannen Sie den SCSI-Bus innerhalb der VM erneut
- fdisk, mounten und zu fstab hinzufügen, genau wie eine normale Festplatte.
Vorteile: schnell einzurichten, schnell zu verwenden, einfach, kann die Festplatte auf dem physischen Host darstellen, wenn Sie später V2P benötigen
Nachteil: Je nachdem, ob Sie den physischen oder virtuellen Kompatibilitätsmodus verwenden, gehen möglicherweise einige VMware-basierte Snapshot-/Rollback-Optionen verloren
Eine alternative Option besteht darin, VMFS auf der LUN zu erstellen, um einen Datenspeicher zu erstellen und dann der VM auf diesem Datenspeicher eine VMDK-Festplatte hinzuzufügen.
- Vorteil: Es ist Storage vMotion-kompatibel, wenn Sie jemals eine Lizenz dafür erwerben. Dies ermöglicht die Hot-Migration von VMDK-Festplatten zwischen LUNs und sogar SANs.
In beiden Fällen besteht ein ähnliches Risiko, falls VMware oder Ihre VM bei einem Fehler das Dateisystem auffrisst. Das eine ist nicht wesentlich besser als das andere, obwohl die verfügbaren Wiederherstellungsoptionen ganz unterschiedlich sein werden.
Ich setze RDMs nur ein, wenn es unbedingt sein muss. Ich habe festgestellt, dass sie mir als VMDK nicht viel Flexibilität verschaffen (und ich bin gebissen worden vonFehlerdas machte sie bei der Durchführung anderer Speichervorgänge unpraktisch (inzwischen behoben - siehe Abschnitt RDM in diesem Link))
Was Ihre VM betrifft, ist es am flexibelsten, die Startdiskette Ihres Dateiservers als VMDK im SAN zu speichern, damit Sie sie im Falle eines Hostausfalls von anderen Hosts starten lassen können. Mit der HA-Funktionalität von VMware erfolgt das Booten Ihrer VM auf einem anderen Host automatisch (die VM wird auf dem zweiten Host gestartet, als wäre der Strom abgeschaltet worden; rechnen Sie damit, dass Sie die üblichen fscks und Zaubertricks ausführen müssen, um sie wie bei einem normalen Server hochzufahren). Beachten Sie, dass HA eine lizenzierte Funktion ist.
Um das Risiko eines VM-Ausfalls zu mindern, können Sie einen leichten Klon Ihres Dateiservers erstellen, der das absolute Minimum enthält, das zum Booten und Starten von SAMBA in einem konfigurierten Zustand erforderlich ist, und diesen auf der lokalen Festplatte jedes Hosts speichern, bis Sie das Datenlaufwerk der ausgefallenen VM hinzufügen und es einschalten.
Dies verschafft Ihnen im Falle eines SAN-Ausfalls möglicherweise zusätzliche Optionen, muss es aber nicht. Im besten Fall ist für Ihren Datenspeicher ein Fsck oder eine andere Reparatur erforderlich, aber Sie müssen die VM darüber zumindest nicht reparieren, neu erstellen oder konfigurieren. Im schlimmsten Fall haben Sie die Daten verloren und müssen auf das Band zurückgreifen … aber in diesem Zustand befanden Sie sich ohnehin schon.
Antwort2
Ich würde bei den VMDK-Images bleiben, nur für den Fall, dass Sie in Zukunft zu VMotion wechseln. Wer weiß, vielleicht bekommen Sie ja noch ein Budget dafür.
Wenn Ihre Maschinen nicht geclustert sind, besteht meiner Meinung nach die beste Möglichkeit, sie zu verwalten, darin, die Last so gleichmäßig wie möglich zu verteilen. Ich habe drei nicht geclusterte 2950er, bei denen die Last der kritischsten VMs jeweils so viel wie möglich beträgt, nämlich 1/3. Theoretisch ist es unwahrscheinlich, dass ich mehr als eine Box auf einmal verliere, sodass mindestens 2/3 unbeeinträchtigt weiterarbeiten können.
Aus Energiesicht wäre es wahrscheinlich effizienter, die Maschinen möglichst zu 100 % auszulasten und die anderen Maschinen ausgeschaltet zu lassen, aber für mich ist das, als würden Sie alle Eier in einen Korb legen.
Ich würde mich nicht als Experten auf diesem Gebiet bezeichnen, es ist einfach das, was ich tue.
Antwort3
Hallo Matt. Es gibt viele Möglichkeiten, eine Lösung aufzuteilen, wenn Sie eine Virtualisierungslösung verwenden. Zunächst einmal gibt es viele Benchmarks, die die Leistung von Raw LUN (RDM) gegenüber VMDK zeigen, und der Unterschied ist normalerweise vernachlässigbar. Einige Dinge, die Sie bei RDMs beachten sollten: Nur bestimmte Clustering-Situationen erfordern die Verwendung von RDMs (MS-Clustering). RDMs haben ein Limit von 2 TB, aber LVM kann verwendet werden, um dieses Limit zu umgehen. RDMs sind „schwieriger“ zu verfolgen, als ESXi ein LUN zur Verwendung für VMFS zu geben und VMDKs darauf zu platzieren. VMDKs (wie erwähnt) haben einige nette Vorteile: svMotion, Snapshots (ein Snapshot eines pRDMs ist nicht möglich).
Wenn Sie Free ESXi verwenden, könnte ich Ihre Situation folgendermaßen angehen. Zunächst befinden sich alle Daten in VMDK-Dateien auf VMFS-LUNS. Richten Sie 2 VMs ein und verwenden Sie Heartbeat für das Failover von IP und Diensten. Heartbeat verschiebt die Dienst-IP und kann bei Bedarf Skripte zum Aushängen/Einhängen der Daten-LUN verarbeiten. Sie könnten sogar ein Skript für VMware Remote CLI erstellen, um sicherzustellen, dass die „ausgefallene“ VM zum Fencing ausgeschaltet wird. Da Heartbeat die Systeme direkt koordiniert, sollte das Risiko, dass beide auf die Daten-LUN zugreifen und dieselben Dienste ausführen, äußerst gering sein. Der Schlüssel liegt hier darin, sicherzustellen, dass das Einhängen/Aushängen der Daten-LUN und das Starten/Herunterfahren der Dienste von Heartbeat und nicht von den normalen Initialisierungsmechanismen gehandhabt wird.
Ein alternatives Failover kann über ein Überwachungssystem durchgeführt werden. Wenn es den ausgefallenen Host erkennt, kann es VMware Remote CLI verwenden, um ein Ausschalten (aus Sicherheitsgründen) und anschließend das Einschalten der Backup-VM zu veranlassen. In dieser Situation erfolgt das Failback relativ manuell.
In meiner „winzigen“ Umgebung habe ich noch nie erlebt, dass eine VMDK beschädigt wurde. Was mir außerdem klar geworden ist, ist, dass Sie vCenter benötigen, wenn Sie mehr als zwei ESX(i)-Hosts oder ein Dutzend VMs haben, um den Überblick zu behalten. Einige der Essential/Plus-Pakete sind angesichts der Vorteile nicht zu teuer.
Antwort4
Ich denke, Sie sollten sich die Frage stellen: „Plane ich, irgendwann wieder zu physischen Servern zurückzukehren?“
Wenn die Antwort vielleicht lautet, sollten Sie vielleicht bei RDM bleiben. Für ESXi mit RDM müssten Sie (glaube ich) etwas kaufen, damit Ihre Glasfaser funktioniert (bei ESXi bin ich mir auch hier nicht 100 % sicher).
Wir hatten mehrere Maschinen, die ich mithilfe von RDM schnell von physischen Servern auf ESX (4.0) verschoben habe. Ich hatte eine Mischung aus Linux- und Windows-Maschinen (super einfach für beide Plattformen). Wir haben noch einige mit altem FreeBSD (6.0 und älter) auf physischen Servern, für die wir RDM nicht verwenden können, da der alte FBSD-Kernel dies nicht unterstützt. Es ging schnell und ich musste nichts weiter tun, als meine LUN zuzuweisen und dann VMWare-Tools zu installieren. Kinderleicht … kein Konverter, kein Stress …
Sie sollten sich auch die Frage stellen: „Welche Funktionen von VMWare möchte ich verwenden?“
Abhängig von Ihrer Antwort darauf haben Sie möglicherweise keine andere Wahl als VMDK. Wenn Sie Ihr SAN für Snapshots verwenden und dafür beispielsweise kein VMware verwenden möchten …
Ich möchte Ihnen einige Anmerkungen zu unseren bisherigen Erfahrungen mitteilen. Vmotion funktioniert gleichermaßen gut mit RDM und VMDK, Storage Vmotion hingegen funktioniert nur mit Nicht-RDM einwandfrei, und der Versuch, mit Vmotion-Speicher von RDM zu VMDK zu wechseln, ist ätzend, verwenden Sie einfach einen Konverter. Die meisten Linux-Distributionen haben ein Open-Source-Paket mit VMware-Tools, sodass die Installation der Tools kein Problem darstellt. Das Backup-Gerät funktioniert wirklich gut und ist kostenlos bei VMware erhältlich, kann aber nicht so viel, wie wir gerne hätten. Ich empfehle dringend, einen Kurs bei VMware zu belegen. Der, den ich belegt habe, dauerte eine Woche und war jeden Cent wert. Der VMware-Support ist fantastisch. Wenn Sie einen Supportvertrag abschließen und anrufen müssen, sind sie erstklassig. Es frustriert mich, wenn ich jemanden finde, der mir helfen kann (zu viele Menüs ...), aber wenn ich sie einmal erreicht habe, kommen sie IMMER mit schnellem und zuverlässigem Support.