Wie man einen fehlertoleranten Cluster mit kontinuierlicher oder hoher Verfügbarkeit bereitstellt

Einige Unternehmen können es sich nicht leisten, dass ihre Dienste ausfallen. Im Falle eines Serverausfalls könnte ein Mobilfunkanbieter Ausfallzeiten im Abrechnungssystem erleben, was zu einem Verbindungsverlust für alle seine Kunden führt. Die Anerkennung der potenziellen Auswirkungen solcher Situationen führt zur Idee, immer einen Plan B zu haben.

In diesem Artikel beleuchten wir verschiedene Möglichkeiten zum Schutz vor Serverausfällen sowie Architekturen, die für die Bereitstellung von VMmanager Cloud, einem Kontrollpanel zum Aufbau eines Hochverfügbarkeitsclusters, verwendet werden.

Einleitung

Die Terminologie im Bereich der Cluster-Toleranz unterscheidet sich von Website zu Website. Um ein Vermischen verschiedener Begriffe und Definitionen zu vermeiden, lassen Sie uns die Begriffe umreißen, die in diesem Artikel verwendet werden:

Fehlertoleranz (FT) ist die Fähigkeit eines Systems, seinen Betrieb nach dem Ausfall eines seiner Komponenten fortzusetzen.
Cluster ist eine Gruppe von Servern (Clusterknoten), die über Kommunikationskanäle verbunden sind.
Fehlertoleranter Cluster (FTC) ist ein Cluster, bei dem der Ausfall eines Servers nicht zu einer vollständigen Unverfügbarkeit des gesamten Clusters führt. Die Funktionen des ausgefallenen Knotens werden automatisch zwischen den verbleibenden Knoten neu zugewiesen.
Kontinuierliche Verfügbarkeit (CA) bedeutet, dass ein Benutzer den Dienst nutzen kann, ohne Zeitüberschreitungen zu erleben. Es spielt keine Rolle, wie lange es her ist, dass der Knoten ausgefallen ist.
Hohe Verfügbarkeit (HA) bedeutet, dass ein Benutzer möglicherweise Zeitüberschreitungen des Dienstes erlebt, falls einer der Knoten ausfällt; das System wird jedoch automatisch mit minimaler Ausfallzeit wiederhergestellt.
CA-Cluster ist ein Cluster mit kontinuierlicher Verfügbarkeit.
HA-Cluster ist ein Cluster mit hoher Verfügbarkeit.

Es sei erforderlich, einen Cluster mit 10 Knoten bereitzustellen, auf dem virtuelle Maschinen laufen. Das Ziel ist es, virtuelle Maschinen nach dem Serverausfall zu schützen. Dual-CPU-Server werden verwendet, um die Berechnungsdichte der Racks zu maximieren.

Auf den ersten Blick scheint die attraktivste Option für ein Unternehmen die Bereitstellung eines Clusters mit kontinuierlicher Verfügbarkeit zu sein, wenn ein Dienst auch nach dem Ausfall der Hardware weiterhin bereitgestellt wird. Tatsächlich ist kontinuierliche Verfügbarkeit ein Muss, wenn Sie den Betrieb eines Abrechnungssystems aufrechterhalten oder einen kontinuierlichen Produktionsprozess automatisieren müssen. Diese Vorgehensweise hat jedoch auch ihre Fallen und Tücken, die im Folgenden behandelt werden.

Kontinuierliche Verfügbarkeit

Die Kontinuität eines Dienstes ist nur möglich, wenn eine exakte Kopie einer physischen oder virtuellen Maschine mit diesem Dienst erstellt wird, die jederzeit verfügbar ist. Ein solches Redundanzmodell wird als 2N bezeichnet. Eine Kopie des Servers nach dem Ausfall der Hardware zu erstellen, würde Zeit in Anspruch nehmen, was zu einer Dienstzeitüberschreitung führen würde. Darüber hinaus wäre es in diesem Fall nicht möglich, den RAM-Dump vom ausgefallenen Server abzurufen, was bedeutet, dass alle dort enthaltenen Informationen verloren wären.

Es gibt zwei Methoden zur Bereitstellung von CA: auf Hardware- und Softwareebene. Lassen Sie uns jede von ihnen näher betrachten.

Die Hardwaremethode stellt einen doppelten Server dar, bei dem alle Komponenten dupliziert sind und Berechnungen gleichzeitig und unabhängig ausgeführt werden. Die Synchronisierung erfolgt durch einen speziellen Knoten, der die Ergebnisse beider Teile überprüft. Wenn der Knoten eine Abweichung feststellt, versucht er, das Problem zu definieren und Fehler zu beheben. Wenn der Fehler nicht behoben werden kann, schaltet das System das ausgefallene Modul ab.

Stratus, ein Hersteller von CA-Servern, garantiert, dass die Gesamtausfallzeit des Systems 32 Sekunden pro Jahr nicht überschreitet. Solche Ergebnisse können durch die Verwendung spezieller Hardware erreicht werden. Laut Stratus-Vertretern liegt der Preis für einen CA-Server mit dualen CPUs für jedes synchronisierte Modul bei etwa 160.000 USD, abhängig von den Spezifikationen. Der Gesamtpreis für den gesamten CA-Cluster würde in diesem Fall 1.600.000 USD betragen.

Die Softwaremethode

Das derzeit beliebteste Softwaretool zur Bereitstellung eines Clusters mit kontinuierlicher Verfügbarkeit ist VMware vSphere. Die Technologie zur kontinuierlichen Verfügbarkeit dieses Produkts wird als Fehlertoleranz bezeichnet.

Im Gegensatz zur Hardwaremethode hat diese Technologie bestimmte Anforderungen, wie die folgenden:

CPU auf dem physischen Host: - Intel mit Sandy Bridge-Architektur (oder neuer). Avoton wird nicht unterstützt.
AMD Bulldozer (oder neuer).
Maschinen mit Fehlertoleranz müssen mit einem 10-Gb-Netzwerk mit geringer Latenz verbunden sein. VMware empfiehlt dringend die Verwendung eines dedizierten Netzwerks.
Nicht mehr als 4 virtuelle CPUs pro VM.
Nicht mehr als 8 virtuelle CPUs pro physischem Host.
Nicht mehr als 4 virtuelle Maschinen pro physischem Host.
Snapshots virtueller Maschinen sind nicht verfügbar.
Storage vMotion ist nicht verfügbar.

Die vollständige Liste der Einschränkungen und Inkompatibilitäten finden Sie in der offiziellen Dokumentation.

Die Lizenzierung von vSphere basiert auf physischen CPUs. Der Preis beginnt bei 1750 USD pro Lizenz + 550 USD für jährliche Abonnements und Support. Die Automatisierung des Cluster-Managements erfordert ebenfalls VMware vCenter Server, der über 8000 USD kostet. Das 2N-Modell wird verwendet, um kontinuierliche Verfügbarkeit bereitzustellen, daher ist es erforderlich, 10 replizierte Server mit Lizenzen für jeden von ihnen zu erwerben, um einen Cluster mit 10 Knoten mit virtuellen Maschinen aufzubauen.

Die Gesamtkosten der Software würden 2[ Anzahl der CPUs pro Server ](10[ Anzahl der Knoten mit virtuellen Maschinen ]+10[ Anzahl der replizierten Knoten ])(1750+550)[ Lizenzkosten pro CPU ]+8000[ Kosten für VMware vCenter Server ]=100.000 USD betragen. Alle Preise sind gerundet.

Spezifische Knotenkonfigurationen werden in diesem Artikel nicht beschrieben, da die Serverkomponenten je nach Zweck des Clusters immer unterschiedlich sind. Netzwerkgeräte werden ebenfalls nicht beschrieben, da sie in jedem Fall identisch sein sollten. Dieser Artikel konzentriert sich auf die Komponenten, die sich definitiv unterscheiden würden, nämlich die Lizenzkosten.

Es ist auch wichtig, die Produkte zu erwähnen, die nicht mehr entwickelt und unterstützt werden.

Das Produkt namens Remus basiert auf der Xen-Virtualisierung. Es handelt sich um eine kostenlose Open-Source-Lösung, die die Mikrosnapshot-Technologie nutzt. Leider wurde die Dokumentation seit langem nicht mehr aktualisiert: Der Installationsleitfaden enthält Anweisungen für Ubuntu 12.10, dessen Lebensende 2014 angekündigt wurde. Selbst die Google-Suche fand kein Unternehmen, das Remus für seine Operationen verwendete.

Es wurden Versuche unternommen, QEMU zu modifizieren, um Cluster mit kontinuierlicher Verfügbarkeit auf dieser Technologie aufzubauen. Es gibt zwei Projekte, die ihre Arbeit in diese Richtung angekündigt haben.

Das erste ist Kemari, ein Open-Source-Produkt, das von Yoshiaki Tamura geleitet wird. Dieses Projekt beabsichtigte, die Live-QEMU-Migration zu nutzen. Der letzte Commit wurde im Februar 2011 gemacht, was darauf hindeutet, dass die Entwicklung in eine Sackgasse geraten ist und nicht fortgesetzt wird.

Das zweite Produkt ist Micro Checkpointing, ein Open-Source-Projekt, das von Michael Hines gegründet wurde. Im letzten Jahr wurde keine Aktivität in seinem Änderungsprotokoll gefunden, was dem Kemari-Projekt ähnelt.

Diese Fakten erlauben uns die Schlussfolgerung, dass es bis heute einfach keine Möglichkeit für kontinuierliche Verfügbarkeit auf KVM-Virtualisierung gibt.

Trotz aller Vorteile von Systemen mit kontinuierlicher Verfügbarkeit gibt es viele Hindernisse auf dem Weg zur Bereitstellung und zum Betrieb solcher Lösungen. Dennoch kann in einigen Fällen Fehlertoleranz erforderlich sein, jedoch ohne die Notwendigkeit, kontinuierlich verfügbar zu sein. Solche Szenarien erlauben die Verwendung von Clustern mit hoher Verfügbarkeit.

Hohe Verfügbarkeit

Ein Cluster mit hoher Verfügbarkeit bietet Fehlertoleranz, indem er automatisch erkennt, ob Hardware ausgefallen ist, und anschließend den Dienst auf dem verfügbaren Knoten startet.

Hohe Verfügbarkeit unterstützt nicht die Synchronisierung von CPUs, die auf Knoten gestartet werden, und erlaubt nicht immer die Synchronisierung lokaler Festplatten. Vor diesem Hintergrund wird empfohlen, die von Knoten verwendeten Laufwerke in einem separaten unabhängigen Speicher wie dem Netzwerk-Speicher zu platzieren.

Der Grund ist klar: Der Knoten kann nach seinem Ausfall nicht mehr erreicht werden, und Informationen von seinem Speichergerät können nicht abgerufen werden. Das Datenspeichersystem sollte ebenfalls fehlertolerant sein, andernfalls gibt es keine Möglichkeit für hohe Verfügbarkeit. Infolgedessen besteht der Cluster mit hoher Verfügbarkeit aus zwei Unterclustern:

Rechencluster, bestehend aus Knoten mit virtuellen Maschinen
Speichercluster mit Festplatten, die von Rechenknoten verwendet werden.

Derzeit werden die folgenden Lösungen verwendet, um Cluster mit hoher Verfügbarkeit mit virtuellen Maschinen auf Clusterknoten zu implementieren:

Heartbeat, Version 1.? mit DRBD;
Pacemaker;
VMware vSphere;
Proxmox VE;
XenServer;
OpenStack;
oVirt;
Red Hat Enterprise Virtualization;
Windows Server Failover Clustering mit Hyper-V-Serverrolle;
VMmanager Cloud.

Lassen Sie uns einen genaueren Blick auf VMmanager Cloud werfen.

VMmanager Cloud

VMmanager Cloud ist ein Produkt, das die Bereitstellung von Clustern mit hoher Verfügbarkeit ermöglicht und QEMU-KVM-Virtualisierung verwendet. Diese Technologie wurde ausgewählt, weil sie aktiv entwickelt und unterstützt wird und es ermöglicht, jedes Betriebssystem auf einer virtuellen Maschine zu installieren. Das Produkt verwendet Corosync, um die Verfügbarkeit des Clusters zu erkennen. Wenn einer der Server ausfällt, verteilt VMmanager seine virtuellen Maschinen nacheinander auf die verbleibenden Knoten.

In vereinfachter Form funktioniert dieser Mechanismus wie folgt:

Das System identifiziert den Clusterknoten mit der niedrigsten Anzahl von virtuellen Maschinen.
Es überprüft, ob genügend RAM vorhanden ist, um die Maschine unterzubringen.
Wenn genügend Speicher auf einem Knoten für die betreffende Maschine vorhanden ist, erstellt VMmanager eine neue virtuelle Maschine auf diesem Knoten.
Wenn nicht genügend Speicher vorhanden ist, überprüft das System die anderen Knoten mit mehr virtuellen Maschinen.

Tests mehrerer Hardwarekonfigurationen und Anfragen bei vielen aktuellen VMmanager Cloud-Nutzern haben ergeben, dass es normalerweise 45-90 Sekunden dauert, um alle VMs vom ausgefallenen Knoten zu verteilen und den Betrieb wiederherzustellen, abhängig von der Leistung der Hardware.

Es wird empfohlen, einen oder mehrere Knoten als Sicherheitsmaßnahme gegen Notfälle zu widmen und während des regulären Betriebs keine VMs auf diesen Knoten bereitzustellen. Dies minimiert die Wahrscheinlichkeit, dass Ressourcen auf den aktiven Clusterknoten fehlen, um virtuelle Maschinen vom ausgefallenen Knoten hinzuzufügen. Falls nur ein Backup-Knoten verwendet wird, wird ein solches Sicherheitsmodell als N+1 bezeichnet.

VMmanager Cloud unterstützt die folgenden Speichertypen: Dateisystem, LVM, Netzwerk-LVM, iSCSI und Ceph [insbesondere RBD (RADOS Block Device), eine der Ceph-Implementierungen]. Letztere drei werden für hohe Verfügbarkeit verwendet.

Eine lebenslange Lizenz für zehn betriebsbereite Knoten und einen Backup-Knoten kostet 3520 €, oder 3865 $ bis zu diesem Datum (eine Lizenz kostet 320 € pro Knoten unabhängig von der Anzahl der CPUs). Die Lizenz umfasst ein Jahr kostenlose Updates; ab dem zweiten Jahr werden Updates im Abonnementmodell zum Preis von 880 € pro Jahr für den gesamten Cluster bereitgestellt.

Lassen Sie uns überprüfen, wie VMmanager Cloud bereits für die Bereitstellung von Clustern mit hoher Verfügbarkeit verwendet wurde.

FirstByte

FirstByte begann im Februar 2016 mit der Bereitstellung von Cloud-Hosting. Zunächst wurde ihr Cluster auf OpenStack aufgebaut; jedoch zwang der Mangel an Spezialisten für dieses System in Bezug auf sowohl deren Verfügbarkeit als auch Kosten sie dazu, nach einer alternativen Lösung zu suchen. Das neue System zum Aufbau eines Clusters mit hoher Verfügbarkeit sollte die folgenden Anforderungen erfüllen:

Fähigkeit zur Bereitstellung von KVM-virtuellen Maschinen.
Integration mit Ceph.
Integration mit einem Abrechnungssystem zur Bereitstellung der bestehenden Dienste.
Erschwingliche Lizenzkosten.
Unterstützung durch den Softwareentwickler.

VMmanager Cloud erfüllte alle Anforderungen.

Besondere Merkmale des FirstByte-Clusters:

Der Datentransfer basiert auf Ethernet-Technologie und Cisco-Ausrüstung.
Das Routing erfolgt mit Cisco ASR9001. Der Cluster verwendet etwa 50000 IPv6-Adressen.
Die Linkgeschwindigkeit zwischen Rechenknoten und Switches beträgt 10 Gbps.
Die Datenübertragungsgeschwindigkeit zwischen Switches und Speicherknoten beträgt 20 Gbps, mit zwei kombinierten Kanälen von jeweils 10 Gbps.
Ein separater 20-Gbps-Link wird zwischen Racks mit Speicherknoten für die Replikation verwendet.
SAS-Festplatten in Kombination mit SSDs sind auf allen Speicherknoten installiert.
Der Speichertyp ist RBD.

Das Systemlayout ist unten dargestellt:

Eine solche Konfiguration eignet sich für das Hosting beliebter Websites, Spieleserver und Datenbanken mit überdurchschnittlicher Last.

FirstVDS

FirstVDS bietet die Dienste eines fehlertoleranten Clusters an, der im September 2015 gestartet wurde.

VMmanager Cloud wurde für diesen Cluster aufgrund der folgenden Faktoren ausgewählt:

Solide Erfahrung mit ISPsystem-Kontrollpanelen.
Integration mit BILLmanager standardmäßig.
Hohe Qualität des technischen Supports.
Integration mit Ceph.

Ihr Cluster hat die folgenden Merkmale:

Der Datentransfer basiert auf einem Infiniband-Netzwerk mit einer Verbindungsgeschwindigkeit von 56 Gbps;
Das Infiniband-Netzwerk ist auf Mellanox-Ausrüstung aufgebaut;
Speicherknoten haben SSD-Laufwerke;
Der Speichertyp ist RBD.

Das System kann wie folgt angeordnet werden:

Im Falle eines Ausfalls des Infiniband-Netzwerks wird die Verbindung zwischen dem VM-Datenspeicher und den Rechenservern über ein Ethernet-Netzwerk, das auf Juniper-Ausrüstung bereitgestellt wird, hergestellt. Die neue Verbindung wird automatisch eingerichtet.

Aufgrund der hohen Geschwindigkeit der Kommunikation mit dem Speicher funktioniert dieser Cluster hervorragend für das Hosting von Websites mit ultrahohen Verkehr, Video- und Inhaltsstreaming sowie großen Datenmengen.

Fazit

Lassen Sie uns die wichtigsten Ergebnisse des Artikels zusammenfassen.

Der Cluster mit kontinuierlicher Verfügbarkeit ist ein Muss, wenn jede Sekunde Ausfallzeit erhebliche Verluste mit sich bringt. Wenn es erlaubt ist, eine Ausfallzeit von 5 Minuten zu haben, während virtuelle Maschinen auf einem Backup-Knoten bereitgestellt werden, kann der Cluster mit hoher Verfügbarkeit eine gute Option sein, um Hardware- und Softwarekosten zu senken.

Es ist auch wichtig, daran zu erinnern, dass der einzige Weg, Fehlertoleranz zu erreichen, Überfluss ist. Stellen Sie sicher, dass Sie Ihre Server, Datenkommunikationsgeräte und -verbindungen, Internetzugangskanäle und Strom replizieren. Replizieren Sie alles, was Sie können. Solche Maßnahmen ermöglichen es, Engpässe und potenzielle Ausfallpunkte zu beseitigen, die zu Ausfallzeiten des gesamten Systems führen können. Durch die oben genannten Maßnahmen können Sie sicher sein, dass Sie einen fehlertoleranten Cluster haben, der gegen Ausfälle resistent ist.

Wenn Sie denken, dass das Modell mit hoher Verfügbarkeit Ihren Anforderungen entspricht und VMmanager Cloud ein gutes Werkzeug zur Umsetzung ist, konsultieren Sie bitte das Installationshandbuch und die Dokumentation, um mehr über das System zu erfahren. Ich wünsche Ihnen fehlerfreie und kontinuierliche Betriebsabläufe!**