Das ist ein weit verbreiteter Mythos im Bereich Serverhardware. In der Praxis sind hyperkonvergente Lösungen (alles in einem) für viele Anwendungen notwendig. Historisch gesehen wurden die ersten Architekturen von Amazon und Google für ihre eigenen Dienste entwickelt. Die Idee war, einen Rechenhof aus identischen Knoten zu schaffen, von denen jeder über eigene Festplatten verfügt. All dies wurde durch eine Art systembildende Software (Hypervisor) verbunden und in virtuelle Maschinen aufgeteilt. Die Hauptaufgabe besteht darin, den Aufwand für die Wartung eines Knotens zu minimieren und Probleme beim Skalieren zu reduzieren: Man kauft einfach noch ein paar Tausend solcher Server zu und schließt sie an. In der Praxis sind dies jedoch Einzelfälle, und viel häufiger geht es um eine kleinere Anzahl von Knoten und eine etwas andere Architektur.
Der Vorteil bleibt jedoch derselbe – unglaubliche Einfachheit in Bezug auf Skalierung und Verwaltung. Der Nachteil ist, dass verschiedene Aufgaben unterschiedliche Ressourcen benötigen, und es kann vorkommen, dass an einem Ort viele lokale Festplatten und an einem anderen wenig RAM vorhanden sind, was bedeutet, dass die Ressourcenauslastung bei unterschiedlichen Aufgabentypen sinkt.
Es stellt sich heraus, dass Sie 10–15 % mehr für die einfache Einrichtung zahlen. Das hat den Mythos aus der Überschrift hervorgerufen. Wir haben lange gesucht, wo die Technologie am besten eingesetzt werden kann, und schließlich gefunden. Cisco hatte keine eigenen Speicherlösungen, wollte aber den gesamten Servermarkt bedienen. Daher entwickelten sie Cisco Hyperflex – eine Lösung mit lokalen Speichern auf den Knoten.
Plötzlich ergab sich daraus eine sehr gute Lösung für Backup-Rechenzentren (Disaster Recovery). Warum und wie – das erkläre ich jetzt. Zudem werde ich die Tests des Clusters zeigen.
Wo es erforderlich ist
Hyperkonvergenz ist:
- Übertragung von Festplatten in die Recheneinheiten.
- Umfassende Integration des Speichersystems mit dem Virtualisierungssystem.
- Übertragung/Integration mit dem Netzwerk-Subsystem.
Diese Kombination ermöglicht es, viele Funktionen des Speichersystems auf Virtualisierungsebene zu realisieren – alles über eine einzige Verwaltungsoberfläche.
In unserem Unternehmen sind Projekte zur Planung von Backup-Rechenzentren sehr gefragt. Oft wird genau die hyperkonvergente Lösung ausgewählt, da sie eine Vielzahl von Optionen für die Replikation (bis hin zu Metro-Clustern) direkt out of the box bietet.
Bei Backup-Rechenzentren handelt es sich in der Regel um einen externen Standort, der sich am anderen Ende der Stadt oder sogar in einer anderen Stadt befindet. Diese ermöglichen es, kritische Systeme im Falle eines teilweisen oder vollständigen Ausfalls des Hauptrechenzentrums wiederherzustellen. Daten werden kontinuierlich vom Produktionsstandort repliziert, und diese Replikation kann auf Anwendungsebene oder auf Ebene des Blockgeräts (Storage Area Network) erfolgen.
Deshalb werde ich jetzt über die Systemarchitektur und die Tests berichten, gefolgt von einigen Szenarien aus der Praxis mit Daten zur Einsparung.
Tests
Unser Setup besteht aus vier Servern, von denen jeder mit 10 SSDs zu je 960 GB ausgestattet ist. Es gibt eine dedizierte Festplatte zum Caching von Schreiboperationen und zur Speicherung einer Service-VM. Die Lösung selbst ist die vierte Version. Die erste war eindeutig unausgereift (laut Meinungen), die zweite war ebenfalls fehlerbehaftet, die dritte bereits relativ stabil, und diese kann man als Release nach Abschluss der umfangreichen Beta-Tests bezeichnen. Während der Testphase habe ich keine Probleme festgestellt; alles funktioniert reibungslos.
Änderungen in v4Eine Vielzahl an Bugs wurde behoben.
Anfänglich konnte die Plattform nur mit dem Hypervisor VMware ESXi arbeiten und unterstützte nur eine geringe Anzahl an Nodes. Auch der Bereitstellungsprozess war nicht immer erfolgreich, sodass einige Schritte wiederholt werden mussten. Es gab Probleme beim Upgrade von älteren Versionen, und die Daten im GUI wurden nicht immer korrekt angezeigt (obwohl ich auch jetzt nicht begeistert von der Darstellung der Leistungsdiagramme bin). Manchmal traten Probleme beim Schnittstellenmanagement der Virtualisierung auf.
Jetzt sind alle anfänglichen Probleme behoben, HyperFlex unterstützt sowohl ESXi als auch Hyper-V und bietet zudem folgende Möglichkeiten:
- Erstellung eines verteilten Clusters.
- Ein Cluster für Büros ohne Verwendung von Fabric Interconnect, mit zwei bis vier Nodes (wir kaufen nur die Server).
- Die Möglichkeit, mit externen SANs zu arbeiten.
- Unterstützung für Container und Kubernetes.
- Erschaffung von Verfügbarkeitszonen.
- Integration mit VMware SRM, falls die integrierte Funktionalität nicht ausreicht.
Die Architektur unterscheidet sich nicht wesentlich von den Lösungen der Hauptkonkurrenten, und es wurde kein Rad neu erfunden. Es basiert auf der Virtualisierungsplattform VMware oder Hyper-V. Die Hardware wird auf Servern der eigenen Entwicklung Cisco UCS betrieben. Es gibt Nutzer, die die Plattform aufgrund der relativ komplexen Anfangskonfiguration, der Vielzahl an Tasten sowie des nicht triviale Systems von Vorlagen und Abhängigkeiten als schwierig empfinden. Doch es gibt auch diejenigen, die den Zen gefunden haben, die Idee schätzen und nicht mehr mit anderen Servern arbeiten möchten.
Wir werden uns speziell die Lösung für VMware ansehen, da sie ursprünglich dafür entwickelt wurde und über umfangreichere Funktionen verfügt. Hyper-V wurde im Laufe der Zeit angepasst, um nicht hinter den Wettbewerbern zurückzubleiben und den Erwartungen des Marktes zu entsprechen.
Es gibt einen Cluster aus Servern, die mit Festplatten ausgestattet sind. Sie haben die Wahl zwischen SSD- oder HDD-Laufwerken zur Datenspeicherung, und ein SSD-Laufwerk dient zur Zwischenspeicherung. Beim Schreiben von Daten auf den Datenspeicher werden die Informationen im Caching Layer (dediziertes SSD-Laufwerk und RAM der Service-VM) gespeichert. Gleichzeitig wird der Datenblock an die Knoten im Cluster gesendet (die Anzahl der Knoten hängt von dem Replikationsfaktor des Clusters ab). Nach der Bestätigung von allen Knoten über den erfolgreichen Schreibvorgang wird die Bestätigung an den Hypervisor und dann an die VM gesendet. Die geschriebenen Daten werden im Hintergrund dedupliziert, komprimiert und auf die Speichermedien geschrieben. Dabei wird immer ein großer Block nacheinander auf die Speichermedien geschrieben, was die Belastung der Laufwerke reduziert.
Deduplication und Kompression sind ständig aktiviert und können nicht deaktiviert werden. Das Lesen von Daten erfolgt direkt von den Speichermedien oder dem RAM-Cache. Bei einer Hybridkonfiguration wird das Lesen auch auf dem SSD-Laufwerk zwischengespeichert.
Die Daten sind nicht an den aktuellen Standort der virtuellen Maschine gebunden und werden gleichmäßig zwischen den Knoten verteilt. Dieser Ansatz ermöglicht es, alle Festplatten und Netzwerkschnittstellen gleichmäßig zu belasten. Ein offensichtlicher Nachteil ist, dass wir die Latenz beim Lesen nicht auf ein Minimum reduzieren können, da keine Garantie für die lokale Verfügbarkeit der Daten besteht. Ich denke jedoch, dass dies ein geringfügiges Opfer im Vergleich zu den gewonnenen Vorteilen ist. Zumal die Netzwerkverzögerungen inzwischen so gering sind, dass sie praktisch keinen Einfluss auf das Gesamtergebnis haben.
Für die gesamte Logik der Funktionsweise des Speichersystems ist eine spezielle Service-VM, der Cisco HyperFlex Data Platform Controller, verantwortlich, die auf jedem Speicherknoten erstellt wird. In unserer Konfiguration wurde der Service-VM acht vCPUs und 72 GB RAM zugewiesen, was keineswegs wenig ist. Ich erinnere daran, dass der Host über 28 physische Kerne und 512 GB RAM verfügt.
Die Serviceressource hat direkten Zugriff auf die physischen Festplatten über den Durchleitung von SAS-Controllern in der VM. Die Kommunikation mit dem Hypervisor erfolgt über ein spezielles Modul namens IOVisor, das die Eingabe- und Ausgabeoperationen abfängt. Zudem wird ein Agent verwendet, der die Übertragung von Befehlen an die API des Hypervisors ermöglicht. Der Agent ist verantwortlich für die Verwaltung von HyperFlex-Snapshots und Klonen.
Die Speicherressourcen werden im Hypervisor als NFS- oder SMB-Freigaben eingebunden (abhängig vom Typ des Hypervisors). Unter der Haube handelt es sich um ein verteiltes Dateisystem, das Funktionen einer vollwertigen Speicherlösung bietet: Feinzuweisung von Volumen, Komprimierung und Deduplizierung, Snapshots mittels Redirect-on-Write-Technologie sowie synchroner/asynchroner Replikation.
Die Serviceressource bietet Zugriff auf die WEB-Oberfläche zur Verwaltung des HyperFlex-Subsystems. Es gibt eine Integration mit vCenter, sodass die meisten täglichen Aufgaben darüber erledigt werden können. Für das Erstellen von Datastores ist es jedoch oft praktischer, dies über eine separate Weboberfläche zu tun, insbesondere wenn Sie bereits auf die schnelle HTML5-Oberfläche umgestiegen sind, oder den vollwertigen Flash-Client mit vollständiger Integration zu nutzen. In der Service-Weboberfläche können Sie die Systemleistung und den detaillierten Status einsehen.
Es gibt eine weitere Art von Knoten im Cluster – Rechenknoten. Dies können Rack- oder Blade-Server ohne integrierte Festplatten sein. Auf diesen Servern können VM betrieben werden, deren Daten auf Servers mit Festplatten gespeichert sind. Aus Sicht des Datenzugriffs gibt es keinen Unterschied zwischen den Knotenarten, da die Architektur eine Abstraktion vom physischen Speicherort der Daten vorgibt. Das maximale Verhältnis von Rechenknoten zu Speicherknoten liegt bei 2:1.
Der Einsatz von Rechenknoten erhöht die Flexibilität beim Skalieren der Clusterressourcen: Wir müssen keine Knoten mit Festplatten kaufen, wenn wir nur CPU/RAM benötigen. Außerdem können wir ein Blade-Gehäuse hinzufügen und dadurch Kosten für die Unterbringung der Server im Rack sparen.
Das Ergebnis ist eine hyperkonvergente Plattform mit den folgenden Funktionen:
- Bis zu 64 Knoten im Cluster (bis zu 32 Speicherknoten).
- Die minimale Anzahl von Knoten im Cluster beträgt drei (zwei für den Edge-Cluster).
- Mechanismus zur Datenredundanz: Spiegelung mit einem Replikationsfaktor von 2 und 3.
- Metro-Cluster.
- Asynchrone Replikation von VMs auf einen anderen HyperFlex-Cluster.
- Orchestrierung des VM-Wechsels in ein entferntes Rechenzentrum.
- Native Snapshots mit Redirect-on-Write-Technologie.
- Bis zu 1 PB nutzbarer Speicherplatz bei einem Replikationsfaktor von 3, ohne Deduplikation zu berücksichtigen. Replikationsfaktor 2 wird nicht berücksichtigt, da dies keine Option für ernsthafte Verkäufe darstellt.
Ein weiterer großer Vorteil ist die Einfachheit der Verwaltung und Bereitstellung. Alle komplizierten Einstellungen der UCS-Server übernimmt eine spezialisierte VM, die von Cisco-Ingenieuren vorbereitet wurde.
Konfiguration des Teststandes:
- 2 x Cisco UCS Fabric Interconnect 6248UP als Verwaltungscluster und Netzwerkkomponenten (48 Ports, die im Ethernet 10G/FC 16G-Betrieb arbeiten).
- Vier Cisco UCS HXAF240 M4 Server.
Server-Spezifikationen:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Netzwerk
UCSC-MLOM-CSC-02 (VIC 1227). 2 Ports 10G Ethernet
Storage HBA
Cisco 12G Modular SAS Pass-through Controller
Speicherplatten
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Weitere KonfigurationsmöglichkeitenNeben der gewählten Hardware sind derzeit folgende Optionen verfügbar:
- HXAF240c M5.
- Ein oder zwei CPUs von Intel Silver 4110 bis Intel Platinum I8260Y. Zweite Generation verfügbar.
- 24 Speicherslots, Module von 16 GB RDIMM 2600 bis 128 GB LRDIMM 2933.
- Von 6 bis 23 Datenträgern, ein Cachelaufwerk, ein Systemlaufwerk und ein Bootlaufwerk.
Kapazitätslaufwerke
- HX-SD960G61X-EV 960GB 2.5-Zoll Enterprise Value 6G SATA SSD (1X Ausdauer) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5-Zoll Enterprise Value 6G SATA SSD (1X Ausdauer) SAS 3.8 TB.
- Caching-Laufwerke
- HX-NVMEXPB-I375 375GB 2.5-Zoll Intel Optane Laufwerk, Extreme Leistung & Ausdauer.
- HX-NVMEHW-H1600* 1.6TB 2.5-Zoll Ent. Perf. NVMe SSD (3X Ausdauer) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5-Zoll Ent. Perf. 12G SAS SSD (10X Ausdauer) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5-Zoll Ent. Perf. 12G SAS SED SSD (10X Ausdauer) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5-Zoll Enterprise Performance 12G SAS SSD (3X Ausdauer).
System- / Log-Laufwerke
- HX-SD240GM1X-EV 240GB 2.5-Zoll Enterprise Value 6G SATA SSD (Upgrade erforderlich).
Boot-Laufwerke
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Netzwerkverbindung über 40G, 25G oder 10G Ethernet-Ports.
Als FI können HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) verwendet werden.
Der Test selbst
Für die Testung des Speichersystems habe ich HCIBench 2.2.1 verwendet. Dies ist ein kostenloses Tool, das die Lastgenerierung aus mehreren virtuellen Maschinen automatisiert. Die Last selbst wird mit der üblichen fio generiert.
Unser Cluster besteht aus vier Knoten, Replikationsfaktor 3, alle Laufwerke sind Flash.
Für die Tests habe ich vier Datenspeicher und acht virtuelle Maschinen erstellt. Für die Schreibtests wird angenommen, dass die Cache-Laufwerke nicht überlaufen.
Die Testergebnisse sind wie folgt:
100 % Lesen 100 % Zufällig
0 % Lesen 100% Zufällig
Block/Tiefe der Warteschlange
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2,47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IOPS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376484 IOPS
5,47 ms 373176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Die fett markierten Werte zeigen, ab wann keine Leistungssteigerung mehr erfolgt, teilweise ist sogar eine Abnahme sichtbar. Dies liegt daran, dass wir an der Leistungsgrenze des Netzwerks/der Controller/der Festplatten stoßen.
- Sequenzielles Lesen 4432 MB/s.
- Sequenzielle Schreibgeschwindigkeit 804 MB/s.
- Beim Ausfall eines Controllers (Ausfall einer virtuellen Maschine oder eines Hosts) sinkt die Leistung um die Hälfte.
- Beim Ausfall der Speicherdisk sinkt die Leistung um ein Drittel. Der Rebuild der Festplatte benötigt 5 % der Ressourcen jedes Controllers.
Bei einem kleinen Block stoßen wir an die Leistungsgrenze des Controllers (virtuelle Maschine), ihre CPU ist zu 100 % ausgelastet. Bei einer Erhöhung des Blocks erreichen wir die Bandbreite der Ports. 10 Gbit/s reichen nicht aus, um das Potenzial von AllFlash-Systemen vollständig auszuschöpfen. Leider erlauben die Parameter des bereitgestellten Demostands keinen Testbetrieb bei 40 Gbit/s.
Nach meinem Eindruck aus den Tests und der Analyse der Architektur erhalten wir durch den Algorithmus, der die Daten zwischen allen Hosts verteilt, eine skalierbare und vorhersehbare Leistung. Dies stellt jedoch auch eine Einschränkung beim Lesen dar, da von lokalen Festplatten mehr Leistung zu schöpfen wäre. Hier könnte ein leistungsfähigeres Netzwerk helfen, zum Beispiel stehen FI mit 40 Gbit/s zur Verfügung.
Eindeutig kann auch eine einzelne Festplatte für Caching und Deduplizierung ein Limit darstellen. Tatsächlich können wir in diesem Stand auf vier SSDs schreiben. Es wäre großartig, die Anzahl der Caching-Laufwerke zu erhöhen und den Unterschied zu sehen.
Echte Nutzung
Für die Einrichtung eines Backup-Rechenzentrums können zwei Ansätze verwendet werden (die Platzierung eines Backups an einem entfernten Standort bleibt unberücksichtigt):
- Active-Passive. Alle Anwendungen werden im primären Rechenzentrum gehostet. Die Replikation kann synchron oder asynchron erfolgen. Im Falle eines Ausfalls des primären Rechenzentrums müssen wir das Backup aktivieren. Dies kann manuell, über Skripte oder Orchestrierungsanwendungen erfolgen. Hier erhalten wir einen RPO, der mit der Replikationsfrequenz vergleichbar ist, und das RTO hängt von der Reaktionsgeschwindigkeit und den Fähigkeiten des Administrators sowie von der Qualität der Entwicklung und Überprüfung des Failover-Plans ab.
- Active-Active. In diesem Szenario erfolgt ausschließlich die synchrone Replikation, die Verfügbarkeit der Rechenzentren wird durch ein Quorum / einen Schiedsrichter bestimmt, der strikt an einem dritten Standort untergebracht ist. RPO = 0, während RTO 0 erreichen kann (wenn die Anwendung dies zulässt) oder der Zeit für die Bearbeitung des Ausfalls eines Knotens im Virtualisierungscluster entspricht. Auf der Virtualisierungsebene wird ein ausgedehnter (Metro) Cluster erstellt, der eine Active-Active-Speichereinheit erfordert.
In der Regel verzeichnen wir bei unseren Kunden bereits eine etablierte Architektur mit klassischem SAN im Hauptrechenzentrum. Daher planen wir einen weiteren zur Replikation. Wie bereits erwähnt, bietet Cisco HyperFlex asynchrone Replikation und die Möglichkeit zur Erstellung eines verteilten Virtualisierungsclusters. Dabei benötigen wir kein dediziertes SAN der Midrange-Klasse oder höher mit kostspieligen Replikationsfunktionen und Active-Active-Datenzugriff auf zwei SANs.
Szenario 1: Wir verfügen über ein primäres und ein Backup-Rechenzentrum sowie eine Virtualisierungsplattform auf VMware vSphere. Alle produktiven Systeme sind im primären Rechenzentrum untergebracht, während die Replikation der virtuellen Maschinen auf Hypervisor-Ebene erfolgt. Dadurch müssen die VMs im Backup-Rechenzentrum nicht ständig eingeschaltet sein. Datenbanken und spezielle Anwendungen replizieren wir mit integrierten Mitteln und halten die VMs eingeschaltet. Im Falle eines Ausfalls des primären Rechenzentrums aktivieren wir die Systeme im Backup-Rechenzentrum. Wir schätzen, dass wir etwa 100 virtuelle Maschinen haben. Solange das primäre Rechenzentrum betriebsbereit ist, können im Backup-Rechenzentrum Testumgebungen und andere Systeme gestartet werden, die im Falle eines Umschaltens auf das primäre Rechenzentrum abgeschaltet werden können. Es besteht auch die Möglichkeit, dass wir eine bidirektionale Replikation verwenden. Ausgestattet bleibt alles gleich.
Bei klassischer Architektur statten wir jedes Rechenzentrum mit einem hybriden Speicher-Backend mit FibreChannel-Zugang, Tiering, Deduplizierung und Kompression (aber nicht online) aus, 8 Servern pro Standort, 2 FibreChannel- und 10G Ethernet-Switches. Für die Replikation und das Switching-Management in der klassischen Architektur können wir VMware-Tools (Replication + SRM) oder kostengünstigere und manchmal bequemere Drittanbieter-Tools verwenden.
Die Abbildung zeigt das Schema.
Im Falle der Verwendung von Cisco HyperFlex ergibt sich folgende Architektur:
Für HyperFlex habe ich Server mit großen CPU/RAM-Ressourcen verwendet, da ein Teil der Ressourcen für die VM des HyperFlex-Controllers verwendet wird. Bei CPU und Speicher habe ich sogar etwas mehr in der HyperFlex-Konfiguration eingeplant, um nicht zu Cisco zu tendieren und Ressourcen für andere VMs zu garantieren. Dadurch können wir auf die FibreChannel-Switches verzichten, und es sind keine Ethernet-Ports für jeden Server erforderlich, da der lokale Verkehr innerhalb des FI verwaltet wird.
Insgesamt ergibt sich folgende Konfiguration für jedes Rechenzentrum:
Server
8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
Speicher-System
Hybrides Speicher-Backend mit FC Front-End (20 TB SSD, 130 TB NL-SAS)
—
LAN
2 x Ethernet-Switch 10G mit 12 Ports
—
SAN
2 x FC Switch 32/16Gb 24 Ports
2 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
Replikation und/oder Orchestrierung des VM-Wechsels
VMware Ent Plus
Für Hyperflex habe ich keine Lizenzkosten für die Replikationssoftware eingeplant, da dies bei uns standardmäßig verfügbar ist.
Für die klassische Architektur habe ich einen Anbieter gewählt, der sich als qualitativ hochwertig und kostengünstig erwiesen hat. Bei beiden Optionen habe ich den marktüblichen Rabatt für die jeweilige Lösung angewendet und reale Preise erhalten.
Die Lösung auf Cisco HyperFlex ist um 13 % günstiger ausgefallen.
Szenario 2: Erstellung von zwei aktiven Rechenzentren. In diesem Szenario entwerfen wir einen verteilten Cluster auf VMware.
Die klassische Architektur besteht aus Virtualisierungsservern, SAN (FC-Protokoll) und zwei Speichersystemen, die in der Lage sind, zwischen ihnen zu lesen und zu schreiben. Auf jedem Speichersystem legen wir nützlichen Speicherplatz für die Lokation an.
Bei HyperFlex erstellen wir einfach einen Stretch-Cluster mit der gleichen Anzahl an Knoten an beiden Standorten. In diesem Fall wird ein Replikationsfaktor von 2+2 verwendet.
Folgende Konfiguration ist entstanden:
Klassische Architektur
HyperFlex
Server
16 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
Speicher-System
2 x AllFlash Speichersysteme (150 TB SSD)
—
LAN
4 x Ethernet Switch 10G 24 Ports
—
SAN
4 x FC Switch 32/16Gb 24 Ports
4 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
VMware Ent Plus
In meinen Berechnungen habe ich die Netzwerkinfrastruktur, die Kosten für das Rechenzentrum usw. nicht berücksichtigt: diese werden sowohl für die klassische Architektur als auch für die Lösung auf HyperFlex gleich sein.
Die Kosten für HyperFlex lagen um 5 % höher. Dabei ist zu erwähnen, dass ich bei den CPU/RAM-Ressourcen für Cisco einen Ungleichgewicht hatte, da ich die Kanäle der Memory-Controller gleichmäßig gefüllt habe. Die Kosten sind etwas höher, aber nicht im Übermaß, was eindeutig darauf hinweist, dass Hyperkonvergenz nicht unbedingt "ein Spielzeug für Reiche" ist, sondern mit dem Standardansatz für den Bau von Rechenzentren konkurrieren kann. Dies könnte auch für diejenigen interessant sein, die bereits Cisco UCS-Server und die entsprechende Infrastruktur dafür besitzen.
Zu den Vorteilen gehören das Fehlen von Kosten für die Verwaltung von SAN und Speichersystemen, Online-Kompression und Deduplizierung, einen einheitlichen Zugangspunkt für den Support (Virtualisierung, Server, auch Speichersysteme), Platzersparnis (aber nicht in allen Szenarien) und eine Vereinfachung des Betriebs.
Was die Unterstützung betrifft, erhalten Sie diese von einem Anbieter – Cisco. Basierend auf meinen Erfahrungen mit Cisco UCS-Servern bin ich überzeugt von ihrer Qualität; ich musste HyperFlex nicht einmal öffnen, alles funktionierte wie erwartet. Die Ingenieure reagieren schnell und können nicht nur Standardprobleme, sondern auch komplexe Grenzfälle lösen. Manchmal wende ich mich mit Fragen an sie: „Kann man das so machen, dies anschließen?“ oder „Ich habe hier etwas konfiguriert und es funktioniert nicht. Können Sie mir helfen?“ – Geduldig finden sie die passende Anleitung und weisen auf die richtigen Schritte hin, sie werden nicht antworten: „Wir lösen nur Hardwareprobleme.“
Links
- Meine E-Mail – StGeneralov@croc.ru
Quelle: habr.com
