Ich muss für einen Verein drei virtuelle Maschinen implementieren, um die Domäne zu verwalten, und zwei weitere Software, die Datenbanken verwenden wird. Natürlich haben sie kein großes Budget, aber ich versuche, mit ihrem Budget etwas Stabiles zu implementieren, das im Falle eines Geräteabsturzes verfügbar ist.
Ich plane, einen guten Server auszuwählen und ihn für die VM-Speicherung und -Berechnung zu verwenden und aus Kostengründen mit Hyper-V zu arbeiten.
Ich würde gerne wissen, ob es eine Möglichkeit gibt, eine Redundanz für die virtuelle Maschine zu schaffen, die eine kritische Software hostet (die eine Datenbank verwendet), ohne das Budget zu sprengen, indem man den Speicher vom ESX trennt und wie beim ESX zwei Geräte für die Speicherung und zwei für die Berechnung kauft.
Können wir konkret nur zwischen zwei Servern sicherstellen, dass, wenn einer abstürzt, der andere den Betrieb der VMs aufrechterhält?
Ich hoffe, dieser Fall interessiert vielleicht jemanden, danke!
Antwort1
Legen Sie fest, wie viel Redundanz Sie wünschen und mit welcher Methode Sie diese einsetzen möchten, und berücksichtigen Sie dabei die Funktionsweise Ihrer Anwendungen. Selbst im kleinen Maßstab kostet HA Zeit und Geld. Geben Sie entsprechend der Wiederherstellungszeitvorgabe des Unternehmens Geld aus.
Eine Anwendung, die nur als eine VM existiert, funktioniert nicht, wenn ein Compute-Knoten ausfällt. Erwägen Sie mehrere Optionen:
- Führen Sie eine Kopie derselben App-VM auf einem anderen Shared-Nothing-Host mit einem Lastenausgleichsschema aus.
- Booten Sie die gleiche VM auf einem anderen Host mit Live-Migration, möglicherweise auf einem gemeinsam genutzten Speicher.
- Verwenden Sie einen Failovercluster, damit eine Kopie der Anwendung auf einen anderen Host verschoben werden kann.
Insbesondere einige Datenbanken verfügen über eine eigene Replikation. Diese hält eine zweite Kopie der Datenbank auf einem anderen Host auf dem neuesten Stand, ohne dass gemeinsam genutzter Speicher erforderlich ist.
Wie viele Rechenknoten und welcher Speicher unterliegen Einschränkungen, hängt von der gewählten HA-Technologie ab.
- 3 physische Hosts sind im Allgemeinen die Mindestgröße eines Clusters. Zwei sind möglicherweise möglich, aber das erschwert die Einhaltung des Quorums.
- Shared-Nothing-Speicher ist einfacher zu speichern, da jeder Host lokalen Speicher verwenden kann. Dann befindet sich die HA im Load Balancer oder in der Datenbankreplikation. Oder möglicherweise mit einer Shared-Nothing-VM-Livemigration.
- Ein herkömmliches dediziertes Speicherarray ist eine relativ einfache Möglichkeit, gemeinsam genutzten Speicher bereitzustellen. Die Redundanz erfolgt intern, mit zwei Controllern und mehreren Festplatten. Eine Replikation auf ein anderes Array ist möglich, aber Sie möchten die Kosten niedrig halten.
- Hyperkonvergenz, bei der lokaler Speicher auf vielen Knoten zu einem Speicherpool zusammengefügt wird, lässt sich nicht gut auf eine kleine Umgebung mit zwei Knoten skalieren. Ist jedoch praktisch, wenn Sie über überschüssigen Speicher auf vielen Rechenknoten verfügen.