Dies ist ein Mythos, der im Bereich der Server-Hardware weit verbreitet ist. In der Praxis werden für viele Dinge hyperkonvergente Lösungen (wenn alles in einem ist) benötigt. Historisch gesehen wurden die ersten Architekturen von Amazon und Google für ihre Dienste entwickelt. Damals bestand die Idee darin, eine Computerfarm aus identischen Knoten zu erstellen, von denen jeder über eigene Festplatten verfügte. All dies wurde durch eine systembildende Software (Hypervisor) vereint und in virtuelle Maschinen unterteilt. Das Hauptziel ist ein minimaler Aufwand für die Wartung eines Knotens und ein Minimum an Problemen bei der Skalierung: Kaufen Sie einfach weitere tausend oder zwei der gleichen Server und verbinden Sie sie in der Nähe. In der Praxis handelt es sich hierbei um Einzelfälle, und viel häufiger spricht man von einer geringeren Anzahl an Knoten und einer etwas anderen Architektur.
Das Plus bleibt jedoch dasselbe: die unglaublich einfache Skalierung und Verwaltung. Der Nachteil besteht darin, dass verschiedene Aufgaben Ressourcen unterschiedlich verbrauchen und an einigen Stellen viele lokale Festplatten vorhanden sind, an anderen nur wenig RAM usw., d. h. für verschiedene Arten von Aufgaben nimmt die Ressourcennutzung ab.
Es stellt sich heraus, dass Sie für eine einfachere Einrichtung 10–15 % mehr bezahlen. Daraus entstand der Mythos im Titel. Wir haben lange nach dem optimalen Einsatzort der Technologie gesucht und sind fündig geworden. Tatsache ist, dass Cisco keine eigenen Speichersysteme hatte, sondern einen vollständigen Servermarkt wollte. Und sie haben Cisco Hyperflex entwickelt – eine Lösung mit lokalem Speicher auf Knoten.
Und das stellte sich plötzlich als sehr gute Lösung für Backup-Rechenzentren (Disaster Recovery) heraus. Warum und wie, erzähle ich dir jetzt. Und ich zeige Ihnen die Clustertests.
Wo benötigt
Hyperkonvergenz ist:
- Übertragen von Festplatten an Rechenknoten.
- Vollständige Integration des Speichersubsystems mit dem Virtualisierungssubsystem.
- Übertragung/Integration mit dem Netzwerksubsystem.
Diese Kombination ermöglicht Ihnen die Implementierung vieler Speichersystemfunktionen auf Virtualisierungsebene und das alles über ein einziges Steuerungsfenster.
In unserem Unternehmen besteht eine große Nachfrage nach Projekten zur Gestaltung redundanter Rechenzentren, und aufgrund einer Reihe von sofort einsatzbereiten Replikationsoptionen (bis hin zu einem Metrocluster) wird häufig eine hyperkonvergente Lösung gewählt.
Bei Backup-Rechenzentren handelt es sich in der Regel um eine Remote-Einrichtung an einem Standort am anderen Ende der Stadt oder in einer anderen Stadt. Es ermöglicht Ihnen, kritische Systeme im Falle eines teilweisen oder vollständigen Ausfalls des Hauptrechenzentrums wiederherzustellen. Dort werden Verkaufsdaten ständig repliziert, und diese Replikation kann auf Anwendungsebene oder auf Blockgeräteebene (Speicher) erfolgen.
Deshalb werde ich jetzt über das Systemdesign und die Tests sprechen und dann über ein paar reale Anwendungsszenarien mit Einsparungsdaten.
Tests
Unsere Instanz besteht aus vier Servern, von denen jeder über 10 SSD-Laufwerke mit 960 GB verfügt. Es gibt eine dedizierte Festplatte zum Zwischenspeichern von Schreibvorgängen und zum Speichern der virtuellen Dienstmaschine. Die Lösung selbst ist die vierte Version. Das erste ist ehrlich gesagt grob (den Bewertungen nach zu urteilen), das zweite ist feucht, das dritte ist bereits recht stabil und dieses hier kann als Veröffentlichung nach dem Ende des Betatests für die breite Öffentlichkeit bezeichnet werden. Beim Testen habe ich keine Probleme festgestellt, alles funktioniert wie am Schnürchen.
Änderungen in v4Eine Reihe von Fehlern wurden behoben.
Anfangs konnte die Plattform nur mit dem VMware ESXi-Hypervisor arbeiten und unterstützte eine kleine Anzahl von Knoten. Außerdem wurde der Bereitstellungsprozess nicht immer erfolgreich abgeschlossen, einige Schritte mussten neu gestartet werden, es gab Probleme beim Update von älteren Versionen, Daten in der GUI wurden nicht immer korrekt angezeigt (obwohl ich mit der Anzeige der Leistungsdiagramme immer noch nicht zufrieden bin ) traten manchmal Probleme an der Schnittstelle zur Virtualisierung auf.
Da nun alle Kinderprobleme behoben sind, kann HyperFlex sowohl ESXi als auch Hyper-V verarbeiten, außerdem ist Folgendes möglich:
- Erstellen eines gestreckten Clusters.
- Erstellen eines Clusters für Büros ohne Verwendung von Fabric Interconnect, von zwei bis vier Knoten (wir kaufen nur Server).
- Fähigkeit, mit externen Speichersystemen zu arbeiten.
- Unterstützung für Container und Kubernetes.
- Erstellung von Verfügbarkeitszonen.
- Integration mit VMware SRM, wenn die integrierte Funktionalität nicht zufriedenstellend ist.
Die Architektur unterscheidet sich nicht wesentlich von den Lösungen seiner Hauptkonkurrenten; sie haben kein Fahrrad geschaffen. Alles läuft auf der Virtualisierungsplattform VMware oder Hyper-V. Die Hardware wird auf proprietären Cisco UCS-Servern gehostet. Es gibt diejenigen, die die Plattform wegen der relativen Komplexität der Ersteinrichtung, der vielen Schaltflächen und eines nicht trivialen Systems von Vorlagen und Abhängigkeiten hassen, aber es gibt auch diejenigen, die Zen gelernt haben, sich von der Idee inspirieren lassen und nicht mehr wollen um mit anderen Servern zu arbeiten.
Wir werden die Lösung für VMware in Betracht ziehen, da die Lösung ursprünglich für VMware entwickelt wurde und über mehr Funktionalität verfügt; Hyper-V wurde im Laufe der Zeit hinzugefügt, um mit der Konkurrenz mitzuhalten und die Markterwartungen zu erfüllen.
Es gibt einen Servercluster voller Festplatten. Es gibt Festplatten zur Datenspeicherung (SSD oder HDD – ganz nach Ihrem Geschmack und Bedarf), es gibt eine SSD-Festplatte zum Caching. Beim Schreiben von Daten in den Datenspeicher werden die Daten auf der Caching-Ebene (dedizierte SSD-Festplatte und RAM der Dienst-VM) gespeichert. Parallel dazu wird ein Datenblock an Knoten im Cluster gesendet (die Anzahl der Knoten hängt vom Cluster-Replikationsfaktor ab). Nach der Bestätigung aller Knoten über die erfolgreiche Aufzeichnung wird die Bestätigung der Aufzeichnung an den Hypervisor und dann an die VM gesendet. Die aufgezeichneten Daten werden im Hintergrund dedupliziert, komprimiert und auf Speicherplatten geschrieben. Gleichzeitig wird immer ein großer Block nacheinander auf die Speicherplatten geschrieben, was die Belastung der Speicherplatten verringert.
Deduplizierung und Komprimierung sind immer aktiviert und können nicht deaktiviert werden. Die Daten werden direkt von Speicherplatten oder aus dem RAM-Cache gelesen. Bei Verwendung einer Hybridkonfiguration werden die Lesevorgänge auch auf der SSD zwischengespeichert.
Die Daten sind nicht an den aktuellen Standort der virtuellen Maschine gebunden und werden gleichmäßig zwischen den Knoten verteilt. Mit diesem Ansatz können Sie alle Festplatten und Netzwerkschnittstellen gleichmäßig belasten. Es gibt einen offensichtlichen Nachteil: Wir können die Leselatenz nicht so weit wie möglich reduzieren, da es keine Garantie für die Datenverfügbarkeit vor Ort gibt. Aber ich glaube, dass dies im Vergleich zu den erzielten Vorteilen ein geringfügiges Opfer ist. Darüber hinaus haben Netzwerkverzögerungen solche Werte erreicht, dass sie das Gesamtergebnis praktisch nicht beeinflussen.
Ein spezieller Service-VM-Controller der Cisco HyperFlex Data Platform, der auf jedem Speicherknoten erstellt wird, ist für die gesamte Betriebslogik des Festplattensubsystems verantwortlich. In unserer Service-VM-Konfiguration wurden acht vCPUs und 72 GB RAM zugewiesen, was gar nicht so wenig ist. Ich möchte Sie daran erinnern, dass der Host selbst über 28 physische Kerne und 512 GB RAM verfügt.
Die Dienst-VM hat direkten Zugriff auf physische Festplatten, indem sie den SAS-Controller an die VM weiterleitet. Die Kommunikation mit dem Hypervisor erfolgt über ein spezielles Modul IOVisor, das E/A-Vorgänge abfängt, und über einen Agenten, der es Ihnen ermöglicht, Befehle an die Hypervisor-API zu senden. Der Agent ist für die Arbeit mit HyperFlex-Snapshots und -Klonen verantwortlich.
Festplattenressourcen werden im Hypervisor als NFS- oder SMB-Freigaben bereitgestellt (je nach Typ des Hypervisors, raten Sie mal, welcher sich wo befindet). Und unter der Haube befindet sich ein verteiltes Dateisystem, mit dem Sie Funktionen vollwertiger Speichersysteme für Erwachsene hinzufügen können: Thin-Volume-Zuweisung, Komprimierung und Deduplizierung, Snapshots mithilfe der Redirect-on-Write-Technologie, synchrone/asynchrone Replikation.
Die Service-VM bietet Zugriff auf die WEB-Verwaltungsschnittstelle des HyperFlex-Subsystems. Es gibt eine Integration mit vCenter und die meisten alltäglichen Aufgaben können von dort aus ausgeführt werden, aber Datenspeicher lassen sich beispielsweise bequemer von einer separaten Webcam aus schneiden, wenn Sie bereits auf eine schnelle HTML5-Oberfläche umgestiegen sind oder einen vollwertigen Flash-Client verwenden mit voller Integration. In der Service-Webcam können Sie die Leistung und den detaillierten Status des Systems einsehen.
Es gibt einen anderen Knotentyp in einem Cluster – Rechenknoten. Dabei kann es sich um Rack- oder Blade-Server ohne eingebaute Festplatten handeln. Auf diesen Servern können VMs ausgeführt werden, deren Daten auf Servern mit Festplatten gespeichert sind. Aus Sicht des Datenzugriffs gibt es keinen Unterschied zwischen den Knotentypen, da die Architektur eine Abstraktion vom physischen Speicherort der Daten beinhaltet. Das maximale Verhältnis von Rechenknoten zu Speicherknoten beträgt 2:1.
Der Einsatz von Rechenknoten erhöht die Flexibilität bei der Skalierung von Clusterressourcen: Wir müssen keine zusätzlichen Knoten mit Festplatten kaufen, wenn wir nur CPU/RAM benötigen. Darüber hinaus können wir einen Blade-Käfig hinzufügen und so bei der Platzierung von Servern im Rack sparen.
Dadurch verfügen wir über eine hyperkonvergente Plattform mit folgenden Funktionen:
- Bis zu 64 Knoten in einem Cluster (bis zu 32 Speicherknoten).
- Die Mindestanzahl an Knoten in einem Cluster beträgt drei (zwei für einen Edge-Cluster).
- Datenredundanzmechanismus: Spiegelung mit Replikationsfaktor 2 und 3.
- Metro-Cluster.
- Asynchrone VM-Replikation auf einen anderen HyperFlex-Cluster.
- Orchestrierung des Wechsels von VMs zu einem Remote-Rechenzentrum.
- Native Snapshots mit Redirect-on-Write-Technologie.
- Bis zu 1 PB nutzbarer Speicherplatz bei Replikationsfaktor 3 und ohne Deduplizierung. Den Replikationsfaktor 2 berücksichtigen wir nicht, da dies für seriöse Verkäufe keine Option ist.
Ein weiterer großer Pluspunkt ist die einfache Verwaltung und Bereitstellung. Die gesamte Komplexität der Einrichtung von UCS-Servern wird von einer speziellen VM übernommen, die von Cisco-Ingenieuren vorbereitet wurde.
Prüfstandskonfiguration:
- 2 x Cisco UCS Fabric Interconnect 6248UP als Management-Cluster und Netzwerkkomponenten (48 Ports im Ethernet 10G/FC 16G-Modus).
- Vier Cisco UCS HXAF240 M4-Server.
Servereigenschaften:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz-RDIMM/PC4-19200/Dual-Rank/x4/1.2 V
Netzwerk
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G-Ethernet-Ports
Speicher-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öglichkeitenZusätzlich zur ausgewählten Hardware stehen derzeit folgende Optionen zur Verfügung:
- HXAF240c M5.
- Eine oder zwei CPUs von Intel Silver 4110 bis Intel Platinum I8260Y. Zweite Generation verfügbar.
- 24 Speichersteckplätze, Streifen von 16 GB RDIMM 2600 bis 128 GB LRDIMM 2933.
- Von 6 bis 23 Datenfestplatten, einer Caching-Festplatte, einer Systemfestplatte und einer Startfestplatte.
Kapazitätslaufwerke
- HX-SD960G61X-EV 960 GB 2.5 Zoll Enterprise Value 6G SATA SSD (1X Endurance) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 Zoll Enterprise Value 6G SATA SSD (1X Endurance) SAS 3.8 TB.
- Laufwerke zwischenspeichern
- HX-NVMEXPB-I375 375 GB 2.5-Zoll-Intel Optane-Laufwerk, extreme Leistung und Ausdauer.
- HX-NVMEHW-H1600* 1.6 TB 2.5 Zoll Ent. Perf. NVMe SSD (3X Ausdauer) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 Zoll Ent. Perf. 12G SAS SSD (10-fache Ausdauer) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 Zoll Ent. Perf. 12G SAS SED SSD (10X Ausdauer) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 Zoll Enterprise Performance 12G SAS SSD (3-fache Ausdauer).
System-/Protokolllaufwerke
- HX-SD240GM1X-EV 240 GB 2.5 Zoll Enterprise Value 6G SATA SSD (Upgrade erforderlich).
Boot-Laufwerke
- HX-M2-240GB 240 GB SATA M.2 SSD SATA 240 GB.
Stellen Sie über 40G-, 25G- oder 10G-Ethernet-Ports eine Verbindung zum Netzwerk her.
Der FI kann HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) sein.
Der Test selbst
Zum Testen des Festplattensubsystems habe ich HCIBench 2.2.1 verwendet. Dies ist ein kostenloses Dienstprogramm, mit dem Sie die Erstellung einer Last von mehreren virtuellen Maschinen automatisieren können. Die Last selbst wird durch das übliche FIO erzeugt.
Unser Cluster besteht aus vier Knoten, Replikationsfaktor 3, alle Festplatten sind Flash.
Zum Testen habe ich vier Datenspeicher und acht virtuelle Maschinen erstellt. Bei Schreibtests wird davon ausgegangen, dass die Caching-Festplatte nicht voll ist.
Die Testergebnisse sind wie folgt:
100 % gelesen, 100 % zufällig
0 % Lesen 100 % zufällig
Block-/Warteschlangentiefe
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 IPOS
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 376,484 IOPS
5,47 ms 373,176 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
Fett markiert Werte, ab denen keine Steigerung der Produktivität mehr erfolgt, manchmal ist sogar eine Verschlechterung sichtbar. Dies liegt daran, dass wir durch die Leistung des Netzwerks/der Controller/Festplatten begrenzt sind.
- Sequentielles Lesen 4432 MB/s.
- Sequentielles Schreiben 804 MB/s.
- Fällt ein Controller aus (Ausfall einer virtuellen Maschine oder eines Hosts), kommt es zu einem doppelten Leistungsabfall.
- Wenn die Speicherplatte ausfällt, beträgt die Inanspruchnahme 1/3. Die Festplattenwiederherstellung beansprucht 5 % der Ressourcen jedes Controllers.
Bei einem kleinen Block sind wir durch die Leistung des Controllers (der virtuellen Maschine) begrenzt, seine CPU wird zu 100 % ausgelastet, und wenn der Block größer wird, sind wir durch die Portbandbreite begrenzt. 10 Gbit/s reichen nicht aus, um das Potenzial des AllFlash-Systems auszuschöpfen. Die Parameter des bereitgestellten Demostandes erlauben es uns leider nicht, den Betrieb mit 40 Gbit/s zu testen.
Nach meinen Tests und dem Studium der Architektur erhalten wir aufgrund des Algorithmus, der Daten zwischen allen Hosts platziert, eine skalierbare, vorhersehbare Leistung, aber das stellt auch eine Einschränkung beim Lesen dar, da es möglich wäre, mehr aus lokalen Festplatten herauszuholen. Hier kann ein produktiveres Netzwerk eingespart werden, beispielsweise steht FI mit 40 Gbit/s zur Verfügung.
Außerdem kann eine Festplatte für Caching und Deduplizierung eine Einschränkung darstellen; tatsächlich können wir in dieser Testumgebung auf vier SSD-Festplatten schreiben. Es wäre großartig, die Anzahl der Caching-Laufwerke erhöhen zu können und den Unterschied zu sehen.
Echter Nutzen
Um ein Backup-Rechenzentrum zu organisieren, können Sie zwei Ansätze verwenden (wir erwägen nicht, ein Backup an einem Remote-Standort zu platzieren):
- Aktiv passiv. Alle Anwendungen werden im Hauptrechenzentrum gehostet. Die Replikation erfolgt synchron oder asynchron. Wenn das Hauptrechenzentrum ausfällt, müssen wir das Backup-Rechenzentrum aktivieren. Dies kann manuell/Skripts/Orchestrierungsanwendungen erfolgen. Hier erhalten wir einen RPO, der der Replikationsfrequenz entspricht, und der RTO hängt von der Reaktion und den Fähigkeiten des Administrators sowie der Qualität der Entwicklung/Debugging des Switching-Plans ab.
- Aktiv-Aktiv. In diesem Fall gibt es nur eine synchrone Replikation; die Verfügbarkeit von Rechenzentren wird durch ein Quorum/Schiedsrichter bestimmt, der sich ausschließlich am dritten Standort befindet. RPO = 0 und RTO kann 0 erreichen (sofern die Anwendung dies zulässt) oder gleich der Failover-Zeit eines Knotens in einem Virtualisierungscluster sein. Auf der Virtualisierungsebene wird ein ausgedehnter (Metro-)Cluster erstellt, der Aktiv-Aktiv-Speicher erfordert.
Normalerweise sehen wir, dass Kunden bereits eine Architektur mit einem klassischen Speichersystem im Hauptrechenzentrum implementiert haben, also entwerfen wir eine andere für die Replikation. Wie bereits erwähnt, bietet Cisco HyperFlex asynchrone Replikation und die Erstellung erweiterter Virtualisierungscluster. Gleichzeitig benötigen wir kein dediziertes Speichersystem der Midrange-Ebene und höher mit teuren Replikationsfunktionen und Active-Active-Datenzugriff auf zwei Speichersysteme.
1-Skript: Wir verfügen über ein primäres und ein Backup-Rechenzentrum sowie eine Virtualisierungsplattform auf VMware vSphere. Alle produktiven Systeme befinden sich im Hauptrechenzentrum und die Replikation virtueller Maschinen erfolgt auf Hypervisor-Ebene. Dadurch wird vermieden, dass VMs im Backup-Rechenzentrum eingeschaltet bleiben. Wir replizieren Datenbanken und spezielle Anwendungen mithilfe integrierter Tools und halten die VMs eingeschaltet. Wenn das Hauptrechenzentrum ausfällt, starten wir Systeme im Backup-Rechenzentrum. Wir gehen davon aus, dass wir etwa 100 virtuelle Maschinen haben. Während das primäre Rechenzentrum in Betrieb ist, können im Standby-Rechenzentrum Testumgebungen und andere Systeme ausgeführt werden, die heruntergefahren werden können, wenn das primäre Rechenzentrum umschaltet. Es ist auch möglich, dass wir eine bidirektionale Replikation verwenden. Aus Hardware-Sicht wird sich nichts ändern.
Bei klassischer Architektur installieren wir in jedem Rechenzentrum ein Hybridspeichersystem mit Zugriff über FibreChannel, Tiering, Deduplizierung und Komprimierung (jedoch nicht online), 8 Server pro Standort, 2 FibreChannel-Switches und 10G-Ethernet. Für die Replikations- und Switching-Verwaltung in einer klassischen Architektur können wir VMware-Tools (Replikation + SRM) oder Tools von Drittanbietern verwenden, was etwas günstiger und manchmal auch bequemer ist.
Die Abbildung zeigt das Diagramm.
Bei Verwendung von Cisco HyperFlex wird die folgende Architektur erhalten:
Für HyperFlex habe ich Server mit großen CPU-/RAM-Ressourcen verwendet, weil... Ein Teil der Ressourcen geht an die HyperFlex-Controller-VM; hinsichtlich CPU und Speicher habe ich die HyperFlex-Konfiguration sogar ein wenig umkonfiguriert, um nicht mit Cisco mitzuspielen und Ressourcen für die verbleibenden VMs zu garantieren. Aber wir können auf FibreChannel-Switches verzichten und benötigen nicht für jeden Server Ethernet-Ports; der lokale Datenverkehr wird innerhalb von FI geswitcht.
Das Ergebnis war die 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)
SHD
Hybridspeichersystem mit FC-Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet-Switch 10G 12 Ports
-
SAN
2 x FC-Switch 32/16 GB, 24 Ports
2 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
Replikation und/oder Orchestrierung des VM-Switchings
VMware Ent Plus
Ich habe keine Replikationssoftwarelizenzen für Hyperflex bereitgestellt, da diese für uns sofort einsatzbereit ist.
Für die klassische Architektur habe ich mich für einen Anbieter entschieden, der sich als hochwertiger und preiswerter Hersteller etabliert hat. Bei beiden Optionen habe ich den Standardrabatt für eine bestimmte Lösung angewendet und als Ergebnis echte Preise erhalten.
Die Cisco HyperFlex-Lösung erwies sich als 13 % günstiger.
2-Skript: Schaffung von zwei aktiven Rechenzentren. In diesem Szenario entwerfen wir einen ausgeweiteten Cluster auf VMware.
Die klassische Architektur besteht aus Virtualisierungsservern, einem SAN (FC-Protokoll) und zwei Speichersystemen, die auf dem dazwischen liegenden Volume lesen und schreiben können. Auf jedem Speichersystem legen wir eine nutzbare Speicherkapazität fest.
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.
Das Ergebnis ist die folgende Konfiguration:
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)
SHD
2 x AllFlash-Speichersysteme (150 TB SSD)
-
LAN
4 x Ethernet-Switch 10G 24 Ports
-
SAN
4 x FC-Switch 32/16 GB, 24 Ports
4 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
VMware Ent Plus
Bei allen Berechnungen habe ich die Netzwerkinfrastruktur, die Rechenzentrumskosten usw. nicht berücksichtigt: Sie werden für die klassische Architektur und für die HyperFlex-Lösung gleich sein.
Was die Kosten angeht, erwies sich HyperFlex als 5 % teurer. An dieser Stelle ist anzumerken, dass ich hinsichtlich der CPU-/RAM-Ressourcen eine Vorliebe für Cisco hatte, da ich in der Konfiguration die Kanäle des Speichercontrollers gleichmäßig gefüllt habe. Die Kosten sind etwas höher, jedoch nicht um eine Größenordnung, was deutlich zeigt, dass Hyperkonvergenz nicht unbedingt ein „Spielzeug für die Reichen“ ist, sondern mit dem Standardansatz für den Aufbau eines Rechenzentrums konkurrieren kann. Dies könnte auch für diejenigen interessant sein, die bereits über Cisco UCS-Server und die entsprechende Infrastruktur dafür verfügen.
Zu den Vorteilen gehören das Fehlen von Kosten für die Verwaltung von SAN- und Speichersystemen, Online-Komprimierung und Deduplizierung, ein einziger Einstiegspunkt für den Support (Virtualisierung, Server, sie sind auch Speichersysteme), Platzersparnis (aber nicht in allen Szenarien), Vereinfachung der Bedienung.
Was den Support betrifft, erhalten Sie ihn hier von einem Anbieter – Cisco. Nach meiner Erfahrung mit Cisco UCS-Servern zu urteilen, gefällt es mir; ich musste es nicht auf HyperFlex öffnen, alles funktionierte genauso. Ingenieure reagieren zeitnah und können nicht nur typische Probleme, sondern auch komplexe Randfälle lösen. Manchmal wende ich mich mit Fragen an sie: „Ist das möglich, scheiß drauf?“ oder „Ich habe hier etwas konfiguriert und es will nicht funktionieren.“ Helfen!" - Sie werden dort geduldig die notwendige Anleitung finden und die richtigen Maßnahmen aufzeigen; sie werden nicht antworten: „Wir lösen nur Hardwareprobleme.“
Referenzen
- Meine Post - [E-Mail geschützt]
Source: habr.com