Web-Skala vs. hyperkonvergiert: Verstehen Sie die Unterschiede

In letzter Zeit haben sich viele Anbieter für hyperkonvergente Architekturen eingesetzt, indem sie argumentiert haben, dass Titanen im Web-Maßstab wie Google und Facebook ähnliche Ansätze verfolgen. Das ist falsch. Es kann Gemeinsamkeiten zwischen Web-Scale- und hyperkonvergenten Architekturen geben, aber es gibt auch große Unterschiede.

Nur weil Unternehmen im Web-Maßstab keine hyperkonvergenten Systeme verwenden, bedeutet dies nicht, dass Sie den Ansatz nicht in Betracht ziehen sollten. Tatsächlich möchten Sie wahrscheinlich kein Rechenzentrum im Web-Maßstab, es sei denn, Sie müssen diesen Maßstab erreichen. Sie sollten sich jedoch hyperkonvergenten Architekturen mit sorgfältigen technischen Überlegungen nähern, anstatt sich an Google oder Facebook zu wenden.

Bevor wir uns mit der Architektur im Web-Maßstab befassen, sollten wir uns daran erinnern, dass das richtige Design für eine kleine Umgebung in einer großen Umgebung eindeutig nicht funktioniert. Das Gegenteil ist häufig der Fall. Systeme, die für große Umgebungen entwickelt wurden, funktionieren in kleinen Umgebungen häufig schlecht. Das System, das Sie entwerfen, sollte zu der Aufgabe passen, die Sie benötigen. Viele der von Anbietern im Web-Maßstab verwendeten Techniken wären ineffizient, wenn sie von Unternehmen mit kleineren Umgebungen versucht würden. Was für Google optimal ist, kann für ein großes Unternehmen durchaus nicht praktikabel sein.

Hyperkonvergente Systeme sind durch einige wichtige Architekturentscheidungen gekennzeichnet. Sie bieten eine zuverlässige Hardware-Abstraktion (die virtuelle Festplatte) durch Replikation zwischen Maschinen. Sie konsolidieren Speicher und rechnen auf denselben Computern. Sie sind für eine Umgebung konzipiert, die frei von kundenspezifischer Hardware ist. Sie dienen zur Entkopplung von Software und Hardware.

Wie ich weiter unten skizziere, treffen Titanen im Web-Maßstab keine dieser Architekturentscheidungen.

Unternehmen im Web-Maßstab verwenden keine zuverlässigen Hardware-Abstraktionen

Hyperkonvergierte Systeme bieten eine zuverlässige Hardwareabstraktion (die virtuelle Festplatte über SCSI oder SATA) mithilfe der systemübergreifenden Replikation. Diese zuverlässige Hardwareschicht befindet sich unter der Anwendungssoftware.

Im Gegensatz dazu bieten Anbieter im Web-Maßstab zuverlässige Software-Abstraktionen: Objekt, Dateisystem usw. Sie tun dies, weil Hardware-Abstraktionen, die für zentralisierte Umgebungen erstellt wurden, äußerst schwierig zu skalieren sind, da sie hohe Konsistenzanforderungen stellen. In der Zwischenzeit können Anbieter im Web-Maßstab Software-Abstraktionen erstellen, die eine reduzierte Konsistenz bieten, die auf eine bestimmte Arbeitslast abgestimmt ist, und somit skalieren und dabei Leistung und Verfügbarkeit beibehalten. Amazon S3, Google File System und HDFS sind Beispiele für verteilte Speichersysteme, die Schnittstellen bereitstellen, die speziell auf bestimmte Arten von Workloads abgestimmt sind. Beispielsweise bietet S3 eine eventuelle Konsistenz für meist gelesene Daten, während HDFS für Rechenframeworks mit sequentieller Verarbeitung wie MapReduce optimiert ist.

NoSQL-Datenbanken bieten eines der bekanntesten Beispiele für diesen Kompromiss. NoSQL-Datenbanken (wie MongoDB, HBase und Cassandra) lockern die Konsistenz, um hochverfügbare Großsysteme bereitzustellen und unzuverlässige einzelne Knoten zu erwarten. Im Gegensatz dazu bieten die meisten herkömmlichen SQL-Datenbanken (wie Oracle oder MySQL) eine starke ACID-Konsistenz, haben jedoch häufig Probleme bei der Skalierung über einen bestimmten Punkt hinaus.

Die Verwendung unzuverlässiger Hardware-Abstraktionen zur Bereitstellung zuverlässiger Software-Abstraktionen führt zu einem Anwendungsdesign, das häufig als "Viehanwendungen" bezeichnet wird. In einer solchen Anwendung sind die von virtuellen Maschinen (oder Containern) bereitgestellten Hardware-Abstraktionen unzuverlässig. Um Zuverlässigkeit zu gewährleisten, bauen Viehdienste Zuverlässigkeit in die Anwendungsschicht selbst ein. Beispielsweise speichert HDFS mehrere Kopien jedes Datenelements, die Daten werden jedoch auf der Dateisystemebene und nicht auf einer Laufwerksebene getrennt.

Web-Scale-Unternehmen kombinieren manchmal Computer und Speicher ...

... aber oft in verschiedene Dienste aufteilen.

Hyperkonvergierte Anbieter argumentieren, dass der Speicher für eine Anwendung mit dem Computer für diese Anwendung internalisiert und zusammen auf einer gemeinsamen Hardwarebasis ausgeführt werden sollte. Während Anbieter im Web-Maßstab die Berechnung und Speicherung für bestimmte Dienste sicherlich zusammenfassen, unterteilen sie Anwendungen in Mikrodienste, die durch das Netzwerk getrennt sind. Anbieter im Web-Maßstab unterscheiden im Allgemeinen stark zwischen Diensten, die einen dauerhaften Status speichern, und Diensten, die rechenintensiv und mehr oder weniger zustandslos sind.

In vielen Fällen verfügen verschiedene Dienste möglicherweise über vollständig separate Hardware, um einer bestimmten Anwendung zu entsprechen. Beispielsweise unterscheidet Amazon klar zwischen Instanzspeicher, der als Teil von EC2 gespeichert wird und kurzlebig ist, und Speicherdiensten. Sowohl EBS (ein Blockdienst) als auch S3 (ein Objektdienst) sind separate Dienste, auf die EC2-Instanzen über das Netzwerk zugreifen. Obwohl Amazon nicht explizit über die Hardware informiert ist, mit der sie ausgeführt werden, ist klar, dass zumindest keine Anstrengungen erforderlich sind, um EBS und EC2 auf nebeneinander angeordneten Knoten auszuführen.

In ähnlicher Weise haben Facebook, Google und Amazon öffentlich erklärt, dass sie heterogene Hardware für ihre Dienste verwenden, um die entsprechende Hardware an den entsprechenden Dienst anzupassen.

Während Anbieter im Web-Maßstab sicherlich die Berechnung und den Speicher für jeden Dienst gemeinsam lokalisieren, verwenden sie verschiedene Ansätze für die Anwendungserstellung und passen die Hardwareplattform häufig für eine Art von Dienst an, die von anderen getrennt ist.

Unternehmen im Web-Maßstab verwenden benutzerdefinierte Hardware

Hyperkonvergierte Anbieter argumentieren, dass Kunden nur serienmäßige Serienserver von einem Hardware-Integrator kaufen sollten, um die Kosten zu senken. Dies ist ein Kompromiss zwischen Kosten- und Leistungsgewinnen durch die Verwendung von kundenspezifischerer Hardware. Nahezu alle Anbieter, unabhängig davon, ob es sich um Appliance-Anbieter, hyperkonvergente Anbieter oder Titanen im Web-Maßstab handelt, verwenden Massenprodukte - Laufwerke, CPUs, RAM usw. -, um die Kosten für Anschaffung und Design zu senken.

Titanen im Web-Maßstab verwenden jedoch am wahrscheinlichsten entweder maßgeschneiderte oder stark angepasste Appliances. Sie tendieren dazu, benutzerdefinierte Geräte zu verwenden, entweder weil sie dadurch ihre Gesamtkosten senken können oder weil sie einen bestimmten Bedarf erfüllen. Da sie große Mengen an Hardware verbrauchen, können sie sich die anfänglichen Entwicklungskosten leisten.

Zum Beispiel hat Google öffentlich bekannt gegeben, dass es seine eigenen Server mit in das Motherboard eingebauten Batterien und mit der Hardware synchronisierten Uhren baut und seine eigenen benutzerdefinierten Netzwerk-Switches herstellt.

Facebook ist so weit gegangen, ein Open-Compute-Projekt zu erstellen, das die benutzerdefinierten Hardware-Designs des Unternehmens offenlegt, um eine Community anderer Unternehmen zu schaffen, die die benötigte Hardware verwenden und produzieren.

Amazon hat bekannt gegeben, dass es benutzerdefinierte Prozessoren, viele Hardwarekonfigurationen und benutzerdefinierte Switches verwendet, um eine enge Integration in seine Rechenzentrumsumgebungen zu erreichen.

Unternehmen im Web-Maßstab koppeln Software und Hardware eng miteinander

Hyperkonvergierte Anbieter argumentieren, dass Infrastruktursoftware (von einem Softwareanbieter geschrieben) von der darunter ausgeführten Hardware (von einem Integrator entworfen) und Anwendungssoftware (von einem App-Entwickler geschrieben) von der darunter liegenden Virtualisierungsinfrastruktur entkoppelt werden sollte.

Dies ist das Gegenteil der meisten Unternehmen im Web-Maßstab. Unternehmen im Web-Maßstab passen nicht nur ihre Hardware an, sondern erstellen auch Hardware, Infrastruktur und Anwendungen, die stark gekoppelt und speziell für ihre Umgebung entwickelt wurden.

Zum Beispiel wurde Googles Spanner mit einer bestimmten Anforderung an synchronisierte Uhren auf Hardwareebene erstellt. Kubernetes geht davon aus, dass jeder Rechenknoten ein eigenes Subnetz erhält. Die Ressourcenzuweisung in Google Borg ist an die Kapazitätsplanung von Google gebunden, während Clusterdefinitionen in Borg unter anderem von den Netzwerktopologien von Google abhängen.

Die Lastausgleichsansätze von Facebook sind stark an eine Reihe von standortspezifischen Diensten gebunden. Memcache (von Facebook und anderen verwendet) setzt Hardware mit sehr viel RAM (oder in jüngerer Zeit Hochleistungs-Flash) voraus.

Die Zuverlässigkeitsentwürfe von Amazon basieren auf der synchronen Replikation zwischen geografisch nahen Rechenzentren.

Diese Art von Software ist eine „Installation“ im Gegensatz zu Unternehmensmodellen (und hyperkonvergierten Modellen), die Hardware und Software als tragbare, zusammensetzbare Einheiten betrachten. Ich leihe mir den Begriff „Installation“ aus der zeitgenössischen Kunst aus, wo einige neuere Künstler ortsspezifische „Installationskunstwerke“ entwerfen, die eng mit dem Ort verbunden sind, an dem sich die Kunst befindet.

Das Design im Installationsstil ist für Unternehmen ohne großen Umfang eine finanzielle Herausforderung. Für diejenigen mit der entsprechenden Skalierung vereinfacht ein Installationsansatz jedoch das Software- und Hardwaremanagement, da die Entwickler von Anwendungs- und Infrastruktursoftware die Möglichkeit haben, sich auf einen engen Hardwaresatz einzustellen. Auf diese Weise können Softwareentwickler die größtmögliche Leistung aus der vorhandenen Hardware herausholen und herausfordernde Softwareprobleme mithilfe geeigneter benutzerdefinierter Hardware lösen. Durch die Anpassung ihrer gesamten Umgebung können Unternehmen im Web-Maßstab vollständige Rechenzentrums-Appliances (auch als „Rechenzentrum als Computer“ bezeichnet) erstellen, anstatt einzelne Speicher- oder Computer-Appliances zu verwenden.

Zum Beispiel strukturiert Google seine Infrastruktur um Versandcontainer voller Hardware. Jeder Container verfügt über Kühlung, Berechnung, Speicherung und Netzwerk, die alle auf die spezifischen Anforderungen der Infrastruktur und Anwendungen von Google zugeschnitten sind. Die Entwickler von Google-Software-Frameworks wie Borg können sowohl das Layout beeinflussen als auch von angepasster Hardware für diese spezifische Konfiguration profitieren.

Unternehmen im Web-Maßstab sind nicht hyperkonvergiert

Zusammenfassend unterscheidet sich das Web-Scale-Design in mindestens vier wesentlichen Aspekten vom hyperkonvergenten Design.

  1. Hyperkonvergente Architekturen verwenden die Replikation über Knoten hinweg, um zuverlässige Hardware-Abstraktionen bereitzustellen, während Architekturen im Web-Maßstab Zuverlässigkeit in benutzerdefinierte Software-Abstraktionen integrieren, die von Anwendungen bereitgestellt werden.
  2. Hyperkonvergente Architekturen lokalisieren Speicher und Datenverarbeitung. Architekturen im Web-Maßstab lokalisieren häufig Rechen- und Speicherressourcen, verwenden jedoch eine Vielzahl von Techniken, um Speicher- und Rechenressourcen nach Bedarf zu kombinieren und zu trennen.
  3. Hyperkonvergente Architekturen basieren auf Standardhardware, während Web-Scale-Architekturen auf stark angepasster Hardware basieren.
  4. Hyperkonvergente Architekturen bieten eine starke Trennung zwischen Software und Hardware, während Architekturen im Web-Maßstab Software aggressiv an ein bestimmtes Rechenzentrumsdesign anpassen.

Dies bedeutet nicht, dass hyperkonvergente Architekturen eine schlechte Idee sind, sondern nur, dass sie sich stark von den in Web-Scale-Umgebungen verwendeten Architekturen unterscheiden. Die bei Anbietern im Web-Maßstab verwendeten Systeme sind auch mit Kompromissen verbunden. Bei der Entscheidung, welche Art von Architektur Sie in Ihrem Rechenzentrum benötigen, müssen Sie sorgfältig überlegen, was Sie benötigen, und nicht nur, was Google oder Facebook tun.

Brandon Salmon, Büro des CTO, ist seit 2009 bei Tintri. Er ist ein System-Typ, der gerne über die Benutzererfahrung nachdenkt, die er bei seiner Doktorarbeit bei Carnegie Mellon über verteilte Dateisysteme für zu Hause aufgegriffen hat. Er entwarf und implementierte Tintris anfängliche Algorithmen zum Verschieben von Daten zwischen Flash und Festplatte und hat seitdem an einer Reihe von Bereichen gearbeitet, zuletzt an Cloud-Technologien.

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]