{"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
\nDas ist ein weit verbreiteter Mythos im Bereich Serverhardware. In der Praxis sind hyperkonvergente L\u00f6sungen (alles in einem) f\u00fcr viele Anwendungen notwendig. Historisch gesehen wurden die ersten Architekturen von Amazon und Google f\u00fcr ihre eigenen Dienste entwickelt. Die Idee war, einen Rechenhof aus identischen Knoten zu schaffen, von denen jeder \u00fcber eigene Festplatten verf\u00fcgt. All dies wurde durch eine Art systembildende Software (Hypervisor) verbunden und in virtuelle Maschinen aufgeteilt. Die Hauptaufgabe besteht darin, den Aufwand f\u00fcr die Wartung eines Knotens zu minimieren und Probleme beim Skalieren zu reduzieren: Man kauft einfach noch ein paar Tausend solcher Server zu und schlie\u00dft sie an. In der Praxis sind dies jedoch Einzelf\u00e4lle, und viel h\u00e4ufiger geht es um eine kleinere Anzahl von Knoten und eine etwas andere Architektur. <\/p>\n

Der Vorteil bleibt jedoch derselbe \u2013 unglaubliche Einfachheit in Bezug auf Skalierung und Verwaltung. Der Nachteil ist, dass verschiedene Aufgaben unterschiedliche Ressourcen ben\u00f6tigen, 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. <\/p>\n

Es stellt sich heraus, dass Sie 10\u201315 % mehr f\u00fcr die einfache Einrichtung zahlen. Das hat den Mythos aus der \u00dcberschrift hervorgerufen. Wir haben lange gesucht, wo die Technologie am besten eingesetzt werden kann, und schlie\u00dflich gefunden. Cisco hatte keine eigenen Speicherl\u00f6sungen, wollte aber den gesamten Servermarkt bedienen. Daher entwickelten sie Cisco Hyperflex \u2013 eine L\u00f6sung mit lokalen Speichern auf den Knoten. <\/p>\n

Pl\u00f6tzlich ergab sich daraus eine sehr gute L\u00f6sung f\u00fcr Backup-Rechenzentren (Disaster Recovery). Warum und wie \u2013 das erkl\u00e4re ich jetzt. Zudem werde ich die Tests des Clusters zeigen. <\/a><\/noindex><\/p>\n

Wo es erforderlich ist<\/h3>\n

\nHyperkonvergenz ist: <\/p>\n

    \n
  1. \u00dcbertragung von Festplatten in die Recheneinheiten.<\/li>\n
  2. Umfassende Integration des Speichersystems mit dem Virtualisierungssystem.<\/li>\n
  3. \u00dcbertragung\/Integration mit dem Netzwerk-Subsystem.<\/li>\n<\/ol>\n

    \nDiese Kombination erm\u00f6glicht es, viele Funktionen des Speichersystems auf Virtualisierungsebene zu realisieren \u2013 alles \u00fcber eine einzige Verwaltungsoberfl\u00e4che.<\/p>\n

    In unserem Unternehmen sind Projekte zur Planung von Backup-Rechenzentren sehr gefragt. Oft wird genau die hyperkonvergente L\u00f6sung ausgew\u00e4hlt, da sie eine Vielzahl von Optionen f\u00fcr die Replikation (bis hin zu Metro-Clustern) direkt out of the box bietet. <\/p>\n

    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\u00f6glichen es, kritische Systeme im Falle eines teilweisen oder vollst\u00e4ndigen Ausfalls des Hauptrechenzentrums wiederherzustellen. Daten werden kontinuierlich vom Produktionsstandort repliziert, und diese Replikation kann auf Anwendungsebene oder auf Ebene des Blockger\u00e4ts (Storage Area Network) erfolgen.<\/p>\n

    Deshalb werde ich jetzt \u00fcber die Systemarchitektur und die Tests berichten, gefolgt von einigen Szenarien aus der Praxis mit Daten zur Einsparung. <\/p>\n

    Tests<\/h3>\n

    \nUnser 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\u00f6sung 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\u00e4hrend der Testphase habe ich keine Probleme festgestellt; alles funktioniert reibungslos.<\/p>\n

    \u00c4nderungen in v4<\/b>Eine Vielzahl an Bugs wurde behoben. <\/p>\n

    Anf\u00e4nglich konnte die Plattform nur mit dem Hypervisor VMware ESXi arbeiten und unterst\u00fctzte 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 \u00e4lteren 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.<\/p>\n

    Jetzt sind alle anf\u00e4nglichen Probleme behoben, HyperFlex unterst\u00fctzt sowohl ESXi als auch Hyper-V und bietet zudem folgende M\u00f6glichkeiten:<\/p>\n

      \n
    1. Erstellung eines verteilten Clusters. <\/li>\n
    2. Ein Cluster f\u00fcr B\u00fcros ohne Verwendung von Fabric Interconnect, mit zwei bis vier Nodes (wir kaufen nur die Server).<\/li>\n
    3. Die M\u00f6glichkeit, mit externen SANs zu arbeiten.<\/li>\n
    4. Unterst\u00fctzung f\u00fcr Container und Kubernetes.<\/li>\n
    5. Erschaffung von Verf\u00fcgbarkeitszonen.<\/li>\n
    6. Integration mit VMware SRM, falls die integrierte Funktionalit\u00e4t nicht ausreicht.<\/li>\n<\/ol>\n

      Die Architektur unterscheidet sich nicht wesentlich von den L\u00f6sungen 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\u00e4ngigkeiten als schwierig empfinden. Doch es gibt auch diejenigen, die den Zen gefunden haben, die Idee sch\u00e4tzen und nicht mehr mit anderen Servern arbeiten m\u00f6chten. <\/p>\n

      Wir werden uns speziell die L\u00f6sung f\u00fcr VMware ansehen, da sie urspr\u00fcnglich daf\u00fcr entwickelt wurde und \u00fcber umfangreichere Funktionen verf\u00fcgt. Hyper-V wurde im Laufe der Zeit angepasst, um nicht hinter den Wettbewerbern zur\u00fcckzubleiben und den Erwartungen des Marktes zu entsprechen.<\/p>\n

      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\u00e4ngt von dem Replikationsfaktor des Clusters ab). Nach der Best\u00e4tigung von allen Knoten \u00fcber den erfolgreichen Schreibvorgang wird die Best\u00e4tigung 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\u00dfer Block nacheinander auf die Speichermedien geschrieben, was die Belastung der Laufwerke reduziert.<\/p>\n

      Deduplication und Kompression sind st\u00e4ndig aktiviert und k\u00f6nnen 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.<\/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 Netzwerkschnittstellen gleichm\u00e4\u00dfig zu belasten. Ein offensichtlicher Nachteil ist, dass wir die Latenz beim Lesen nicht auf ein Minimum reduzieren k\u00f6nnen, da keine Garantie f\u00fcr die lokale Verf\u00fcgbarkeit der Daten besteht. Ich denke jedoch, dass dies ein geringf\u00fcgiges Opfer im Vergleich zu den gewonnenen Vorteilen ist. Zumal die Netzwerkverz\u00f6gerungen inzwischen so gering sind, dass sie praktisch keinen Einfluss auf das Gesamtergebnis haben.<\/p>\n

      F\u00fcr 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 \u00fcber 28 physische Kerne und 512 GB RAM verf\u00fcgt.<\/p>\n

      Die Serviceressource hat direkten Zugriff auf die physischen Festplatten \u00fcber den Durchleitung von SAS-Controllern in der VM. Die Kommunikation mit dem Hypervisor erfolgt \u00fcber ein spezielles Modul namens IOVisor, das die Eingabe- und Ausgabeoperationen abf\u00e4ngt. Zudem wird ein Agent verwendet, der die \u00dcbertragung von Befehlen an die API des Hypervisors erm\u00f6glicht. Der Agent ist verantwortlich f\u00fcr die Verwaltung von HyperFlex-Snapshots und Klonen.<\/p>\n

      Die Speicherressourcen werden im Hypervisor als NFS- oder SMB-Freigaben eingebunden (abh\u00e4ngig vom Typ des Hypervisors). Unter der Haube handelt es sich um ein verteiltes Dateisystem, das Funktionen einer vollwertigen Speicherl\u00f6sung bietet: Feinzuweisung von Volumen, Komprimierung und Deduplizierung, Snapshots mittels Redirect-on-Write-Technologie sowie synchroner\/asynchroner Replikation.<\/p>\n

      Die Serviceressource bietet Zugriff auf die WEB-Oberfl\u00e4che zur Verwaltung des HyperFlex-Subsystems. Es gibt eine Integration mit vCenter, sodass die meisten t\u00e4glichen Aufgaben dar\u00fcber erledigt werden k\u00f6nnen. F\u00fcr das Erstellen von Datastores ist es jedoch oft praktischer, dies \u00fcber eine separate Weboberfl\u00e4che zu tun, insbesondere wenn Sie bereits auf die schnelle HTML5-Oberfl\u00e4che umgestiegen sind, oder den vollwertigen Flash-Client mit vollst\u00e4ndiger Integration zu nutzen. In der Service-Weboberfl\u00e4che k\u00f6nnen Sie die Systemleistung und den detaillierten Status einsehen.<\/p>\n

      \"Admin
      \n
      \nEs gibt eine weitere Art von Knoten im Cluster \u2013 Rechenknoten. Dies k\u00f6nnen Rack- oder Blade-Server ohne integrierte Festplatten sein. Auf diesen Servern k\u00f6nnen 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\u00e4ltnis von Rechenknoten zu Speicherknoten liegt bei 2:1.<\/p>\n

      Der Einsatz von Rechenknoten erh\u00f6ht die Flexibilit\u00e4t beim Skalieren der Clusterressourcen: Wir m\u00fcssen keine Knoten mit Festplatten kaufen, wenn wir nur CPU\/RAM ben\u00f6tigen. Au\u00dferdem k\u00f6nnen wir ein Blade-Geh\u00e4use hinzuf\u00fcgen und dadurch Kosten f\u00fcr die Unterbringung der Server im Rack sparen.<\/p>\n

      Das Ergebnis ist eine hyperkonvergente Plattform mit den folgenden Funktionen:<\/p>\n