{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin ohne H\u00e4nde = Hyperkonvergenz?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nDies ist ein Mythos, der im Bereich der Serverhardware weit verbreitet ist. In der Praxis sind hyperkonvergente L\u00f6sungen (alles in einem) jedoch f\u00fcr viele Zwecke erforderlich. Historisch gesehen wurden die ersten Architekturen von Amazon und Google f\u00fcr ihre eigenen Dienste entwickelt. Die Idee war damals, einen Rechenfarm aus identischen Knoten zu schaffen, von denen jeder eigene Festplatten hat. All dies wurde mit einer Art systembildenden Software (Hypervisor) verbunden und dann in virtuelle Maschinen unterteilt. Die Hauptaufgabe besteht darin, den Aufwand f\u00fcr die Wartung eines einzelnen Knotens auf ein Minimum zu reduzieren und Probleme beim Skalieren zu vermeiden: Man kauft einfach eine weitere tausend oder zwei solcher Server und schlie\u00dft sie daneben an. In der Praxis sind dies jedoch Einzelf\u00e4lle, und viel h\u00e4ufiger geht es um eine geringere Anzahl von Knoten und eine leicht andere Architektur. <\/p>\n

Der Vorteil bleibt derselbe \u2013 unglaubliche Einfachheit beim Skalieren und Verwalten. Der Nachteil ist, dass verschiedene Aufgaben unterschiedlich Ressourcen verbrauchen, sodass es irgendwo viele lokale Festplatten, woanders wenig RAM und so weiter gibt. Das hei\u00dft, bei verschiedenen Arten von Aufgaben wird die Ressourcennutzung sinken. <\/p>\n

Es stellte sich heraus, dass man f\u00fcr den Komfort der Einrichtung 10-15% mehr bezahlt. Das hat den Mythos aus der \u00dcberschrift hervorgerufen. Wir haben lange gesucht, wo diese Technologie optimal eingesetzt werden kann, und sie gefunden. Tatsache ist, dass Cisco keine eigenen Speicherl\u00f6sungen hatte, aber den vollst\u00e4ndigen Servermarkt wollte. Und so haben sie Cisco Hyperflex geschaffen \u2013 eine L\u00f6sung mit lokalen Speichern auf den Knoten. <\/p>\n

Und damit hat sich pl\u00f6tzlich eine sehr gute L\u00f6sung f\u00fcr Backup-Rechenzentren (Disaster Recovery) ergeben. Warum und wie \u2013 das werde ich jetzt erkl\u00e4ren. Und ich werde die Cluster-Tests zeigen. <\/a><\/noindex><\/p>\n

Wo n\u00f6tig<\/h3>\n

\nHyperkonvergenz ist: <\/p>\n

    \n
  1. Verschiebung der Festplatten in die Rechenknoten.<\/li>\n
  2. Vollst\u00e4ndige Integration des Storage-Subsystems mit dem Virtualisierungs-Subsystem.<\/li>\n
  3. Verschiebung\/Integration mit dem Netzwerk-Subsystem.<\/li>\n<\/ol>\n

    \nSolch eine Kombination erm\u00f6glicht die Umsetzung vieler Funktionen von Speichersystemen auf der Ebene der Virtualisierung und alles aus einem einzigen Verwaltungsfenster.<\/p>\n

    In unserem Unternehmen sind Projekte zur Planung von Backup-Rechenzentren sehr gefragt, und oft wird tats\u00e4chlich eine hyperkonvergente L\u00f6sung wegen der Vielzahl an Replikationsoptionen (bis hin zu Metro-Clustern) aus der Box gew\u00e4hlt. <\/p>\n

    Bei redundanten Rechenzentren handelt es sich in der Regel um einen entfernten Standort an einem anderen Ende der Stadt oder sogar in einer anderen Stadt. Es erm\u00f6glicht die Wiederherstellung kritischer Systeme im Falle eines teilweisen oder vollst\u00e4ndigen Ausfalls des prim\u00e4ren Rechenzentrums. Daten werden kontinuierlich von der Produktionsumgebung repliziert, und diese Replikation kann auf Anwendungsebene oder auf Ebene des Blockspeichers (SAN) erfolgen.<\/p>\n

    Deshalb werde ich jetzt \u00fcber die Systemarchitektur und Tests sprechen, und danach \u00fcber einige Szenarien f\u00fcr den praktischen Einsatz mit Daten zu Einsparungen. <\/p>\n

    Tests<\/h3>\n

    \nUnser Exemplar besteht aus vier Servern, in jedem davon befinden sich 10 SSD-Laufwerke mit 960 GB. Es gibt eine dedizierte Festplatte zum Caching von Schreibvorg\u00e4ngen und zur Speicherung der Dienstvirtualmaschine. Die L\u00f6sung selbst ist die vierte Version. Die erste war offensichtlich unausgereift (laut Feedback), die zweite war noch etwas unausgereift, die dritte bereits ausreichend stabil, und diese kann man als Release nach Abschluss der \u00f6ffentlichen Betatests bezeichnen. W\u00e4hrend der Testphase habe ich keine Probleme festgestellt, alles funktioniert einwandfrei.<\/p>\n

    \u00c4nderungen in v4<\/b>Eine Menge Bugs wurden behoben. <\/p>\n

    Urspr\u00fcnglich konnte die Plattform nur mit dem Hypervisor VMware ESXi arbeiten und unterst\u00fctzte nur eine geringe Anzahl von Knoten. Au\u00dferdem endete der Bereitstellungsprozess nicht immer erfolgreich, man musste einige Schritte neu starten, es gab Probleme beim Aktualisieren von \u00e4lteren Versionen, die Daten im GUI wurden nicht immer korrekt angezeigt (obwohl ich auch jetzt nicht begeistert von der Darstellung der Leistungsdiagramme bin), manchmal traten Probleme mit der Virtualisierung auf.<\/p>\n

    Derzeit sind alle Kinderkrankheiten behoben. HyperFlex unterst\u00fctzt sowohl ESXi als auch Hyper-V, au\u00dferdem ist Folgendes m\u00f6glich:<\/p>\n

      \n
    1. Erstellung eines ausgedehnten Clusters. <\/li>\n
    2. Erstellung eines Clusters f\u00fcr B\u00fcros ohne Verwendung von Fabric Interconnect, von zwei bis vier Knoten (wir kaufen nur die Server).<\/li>\n
    3. M\u00f6glichkeit zur Arbeit mit externen Speichersystemen.<\/li>\n
    4. Unterst\u00fctzung f\u00fcr Container und Kubernetes.<\/li>\n
    5. Erstellung von Verf\u00fcgbarkeitszonen.<\/li>\n
    6. Integration mit VMware SRM, wenn die integrierte Funktionalit\u00e4t nicht ausreicht.<\/li>\n<\/ol>\n

      Die Architektur unterscheidet sich nicht wesentlich von den L\u00f6sungen der Hauptkonkurrenten, das Rad wurde nicht neu erfunden. Alles l\u00e4uft auf der Virtualisierungsplattform VMware oder Hyper-V. Hardwareseitig kommt es auf Cisco UCS-Servern zum Einsatz, die intern entwickelt wurden. Es gibt diejenigen, die die Plattform wegen der relativen Komplexit\u00e4t der Ersteinrichtung, der Vielzahl an Kn\u00f6pfen, des nicht-trivialen Systems von Vorlagen und Abh\u00e4ngigkeiten hassen, aber es gibt auch die, die ihre Zen-Erleuchtung erreicht haben, sich mit der Idee identifizieren und nicht mehr mit anderen Servern arbeiten wollen. <\/p>\n

      Wir betrachten hier die L\u00f6sung f\u00fcr VMware, da diese urspr\u00fcnglich daf\u00fcr entwickelt wurde und mehr Funktionalit\u00e4t bietet. Hyper-V wurde nachtr\u00e4glich angepasst, um mit den Konkurrenten Schritt zu halten und den Markterwartungen zu entsprechen.<\/p>\n

      Es gibt einen Cluster aus Servern, die mit Festplatten ausgestattet sind. Es sind Festplatten f\u00fcr die Datenspeicherung vorhanden (SSD oder HDD \u2013 je nach Vorliebe und Bedarf), und es gibt eine SSD-Festplatte f\u00fcr das Caching. Bei der Datenspeicherung auf dem Datenspeicher erfolgt die Sicherung der Daten auf der Cache-Ebene (dedizierte SSD-Festplatte und RAM der Service-VM). Parallel wird der Datenblock an die Knoten im Cluster gesendet (die Anzahl der Knoten h\u00e4ngt vom Replikationsfaktor des Clusters ab). Nach der Best\u00e4tigung aller Knoten \u00fcber die erfolgreiche Speicherung wird die Best\u00e4tigung an den Hypervisor und weiter an die VM gesendet. Die gespeicherten Daten werden im Hintergrund dedupliziert, komprimiert und auf die Speichermedien geschrieben. Dabei wird immer ein gro\u00dfer Block an die Speichermedien sequenziell geschrieben, was die Belastung der Speichermedien reduziert.<\/p>\n

      Deduplizierung und Kompression sind st\u00e4ndig aktiviert und k\u00f6nnen nicht deaktiviert werden. Der Datenzugriff erfolgt direkt von den Speichermedien oder aus dem RAM-Cache. Wenn eine hybride Konfiguration verwendet wird, wird der Zugriff auch auf der SSD-Festplatte zwischengespeichert.<\/p>\n

      Die Daten sind nicht an den aktuellen Standort der virtuellen Maschine gebunden und werden gleichm\u00e4\u00dfig zwischen den Knoten verteilt. Dieser Ansatz erm\u00f6glicht es, alle Festplatten und Netzwerkinterfaces gleichm\u00e4\u00dfig zu belasten. Ein offensichtlicher Nachteil ergibt sich: Wir k\u00f6nnen die Leseverz\u00f6gerung nicht auf ein Minimum reduzieren, da keine Garantie besteht, dass die Daten lokal verf\u00fcgbar sind. Ich halte dies jedoch f\u00fcr ein geringf\u00fcgiges Opfer im Vergleich zu den erhaltenen Vorteilen. Zumal die Netzwerklatenzen mittlerweile derart sind, dass sie den Gesamtergebnis kaum beeinflussen.<\/p>\n

      Die gesamte Logik der Funktionsweise des Speichersystems wird von einer speziellen Service-VM, dem Cisco HyperFlex Data Platform Controller, \u00fcbernommen, die auf jeder Speicher-Node erstellt wird. In unserer Konfiguration wurden der Service-VM acht vCPU und 72 GB RAM zugewiesen, was nicht wenig ist. Ich erinnere daran, dass der Host \u00fcber 28 physische Kerne und 512 GB RAM verf\u00fcgt.<\/p>\n

      Die Service-VM hat direkten Zugriff auf die physischen Festplatten \u00fcber das Durchreichen des SAS-Controllers in die VM. Die Kommunikation mit dem Hypervisor erfolgt \u00fcber ein spezielles Modul namens IOVisor, das Eingabe- und Ausgabeoperationen abf\u00e4ngt, und \u00fcber einen Agenten, der es erm\u00f6glicht, Befehle an die API des Hypervisors zu senden. Der Agent ist zust\u00e4ndig f\u00fcr die Arbeit mit HyperFlex-Snapshots und Klonen.<\/p>\n

      Im Hypervisor werden die Speicherressourcen als NFS- oder SMB-Freigabe eingebunden (je nach Typ des Hypervisors, erraten Sie, welcher wo ist). Unter der Haube handelt es sich um ein verteiltes Dateisystem, das die Funktionen eines vollwertigen Speichersystems erm\u00f6glicht: Thin Provisioning, Kompression und Deduplication, Snapshots mit der Technologie Redirect-on-Write, synchrone\/asynchrone Replikation.<\/p>\n

      Die Service-VM bietet Zugang zu einer WEB-Oberfl\u00e4che zur Verwaltung des HyperFlex-Systems. Es gibt eine Integration mit vCenter, und die meisten allt\u00e4glichen Aufgaben k\u00f6nnen daraus durchgef\u00fchrt werden, aber Datastores lassen sich beispielsweise einfacher aus einer separaten Weboberfl\u00e4che abschneiden, wenn Sie bereits auf die schnelle HTML5-Oberfl\u00e4che umgestiegen sind, oder einen vollwertigen Flash-Client mit vollst\u00e4ndiger Integration verwenden. In der Service-Weboberfl\u00e4che kann die Leistung und der detaillierte Status des Systems eingesehen werden.<\/p>\n

      \"Admin
      \n
      \nEs gibt auch eine andere Art von Nodes im Cluster \u2013 Compute-Nodes. Dies k\u00f6nnen Rack- oder Blade-Server ohne integrierte Festplatten sein. Auf diesen Servern k\u00f6nnen VMs ausgef\u00fchrt werden, deren Daten auf Servern mit Festplatten gespeichert sind. Aus Sicht des Datenzugriffs gibt es keinen Unterschied zwischen den Typen von Nodes, da die Architektur eine Abstraktion vom physischen Standort der Daten vorsieht. Das maximale Verh\u00e4ltnis von Compute-Nodes zu Storage-Nodes betr\u00e4gt 2:1.<\/p>\n

      Die Nutzung von Compute-Nodes erh\u00f6ht die Flexibilit\u00e4t beim Skalieren der Clusterressourcen: Wir m\u00fcssen keine Nodes mit Festplatten zus\u00e4tzlich kaufen, wenn wir nur einen Bedarf an CPU\/RAM haben. Au\u00dferdem k\u00f6nnen wir ein Blade-Geh\u00e4use hinzuf\u00fcgen und dabei Kosten f\u00fcr die Unterbringung der Server im Rack sparen.<\/p>\n

      Somit haben wir eine hyperkonvergente Plattform mit folgenden Funktionen:<\/p>\n