Die neue Private Cloud aus der Sicht eines Architekten

Dieser Beitrag erschien ursprünglich auf The New Stack .

Einige Jahre lang hatte der Begriff „Private Cloud“ eine negative Konnotation. Aber wie wir wissen, ist Technologie eher ein Rad als ein Pfeil, und wie gerufen erhält die Private Cloud jede Menge Aufmerksamkeit, und das alles nur positiv. Die Statistiken sprechen eine klare Sprache: In der 2023 Infrastructure Cloud Survey von Forrester gaben 79 % der 1.300 Unternehmensentscheider an, dass sie Private Clouds implementieren. Laut einer Citrix-Bericht in Großbritannien , waren 94 % der IT-Leiter an einer Repatriierungsmaßnahme beteiligt. Das ehrwürdige IDC stellte fest, dass 80 % der Unternehmen einige oder alle ihrer Daten innerhalb eines Jahres nach der Verlagerung in die Cloud repatriierten. So viel zu den Behauptungen des Cloud-Industriekomplexes, dass es hier „nichts zu sehen gibt …“

Die Gründe dafür sind vielfältig und wir werden sie im Detail erläutern. Noch wichtiger ist jedoch, welche Architektur ist die richtige für die Umstellung? Was sind die grundlegenden technischen Prinzipien der privaten Cloud? Und schließlich: Wie gestalte ich die Dateninfrastrukturanforderungen der KI?

Das Warum hinter der Repatriierung in die Private Cloud

Der Hauptgrund für die Rückführung von Unternehmen sind die Kosten. Durch die Rückführung sparen sie bis zu 70 %. Dies wurde öffentlich von Unternehmen so unterschiedlich wie 37 Signale , X Und Ahrefs .

Damit verwandt, aber nicht dasselbe, ist die Vorhersagbarkeit. Private Clouds bieten weniger Elastizität, aber eine höhere Vorhersagbarkeit (wir gehen weiter unten auf einige Elastizitäts-Hacks ein). Für die meisten CIOs, die ihre Arbeitslasten verstehen, lohnt sich dieser Kompromiss. Für CFOs ist es eine noch einfachere Wahl.

Sicherheitsprobleme kommen an dritter Stelle. Das heißt nicht, dass die öffentliche Cloud grundsätzlich unsicher ist, das ist sie nicht. Es bedeutet jedoch, dass CISOs ihren öffentlichen Cloud-Partnern in dieser Hinsicht nicht vollkommen vertrauen (tatsächlich behalten sich die meisten Cloud-Anbieter das Recht vor, in Ihre Buckets zu schauen). Im Zeitalter der KI wird der Einsatz nur noch höher.

In einem damit verbundenen Zusammenhang steht Kontrolle auf der Liste jedes CIO. Neben Kosteneinsparungen, Vorhersehbarkeit und Sicherheit haben Sie nicht nur die volle Kontrolle über Ihre KI-Dateninfrastruktur, sondern diese Daten sind auch für alle Ihre Anwendungen greifbar. So können Sie Ihre Modelle auf einer KI-Dateninfrastruktur hosten, wo Sie und Ihr Team Sicherheitsstandards festlegen können, die Ihren individuellen Sicherheitsanforderungen entsprechen – sogar beim physischen Zugriff.

Auch die Reife spielt eine Rolle. Die moderne Cloud ist ein Betriebsmodell, kein Standort. Dieses Modell, einst exklusiv den großen öffentlichen Clouds vorbehalten, ist heute überall zu finden – vom Rand bis zum Kern. Containerisierung, Orchestrierung, Microservices, softwaredefinierte Infrastruktur, RESTful APIs sind Standardbetriebsverfahren. Es spielt keine Rolle, wo Sie sie ausführen – und wenn es keine Rolle spielt, warum sollten Sie dann das Zwei- bis Dreifache bezahlen?

Auch Vorschriften spielen eine Rolle, insbesondere wenn sie sich weiterentwickeln. Manche Architekturen, manche Regionen, manche Einsatzszenarien (Militär/Geheimdienst) erforderten ursprünglich keine privaten Clouds, heute jedoch schon.

Auch hier sind die Gründe unterschiedlich, aber der Effekt ist der gleiche. Die private Cloud ist wieder im Trend. Die Frage ist: Was hat sich in den letzten Jahren geändert?

Das beliebteste Designmuster der Private Cloud ist der moderne Data Lake

Wie oben erwähnt, läuft die private Cloud, genau wie die öffentliche Cloud, auf dem Cloud-Betriebsmodell. Die Edge-Cloud läuft auf dem Cloud-Betriebsmodell. Colocation läuft auf dem Cloud-Betriebsmodell.

Dieses Betriebsmodell definiert eine bestimmte Architektur und immer wieder macht diese Architektur den modernen Datensee möglich. Natürlich gibt es auch andere Architekturen, aber wenn Unternehmen die private Cloud zum Aufbau ihres modernen Datensees verwenden, zahlen sie nur für das, was sie benötigen. Wenn ihr Unternehmen wächst, ist die Skalierung so einfach wie das Hinzufügen weiterer Ressourcen zu einem Cluster. Eine Neugestaltung ist nicht erforderlich. KI/ML wird unterstützt. Erweiterte Analysen – unterstützt. Protokollanalyse/Bedrohungsanalyse – unterstützt. HDFS-Ersatz/Migration — unterstützt.

Ein moderner Data Lake ist zur Hälfte Data Warehouse und zur Hälfte Data Lake und verwendet Objektspeicher für alles. Die Objektspeicherschicht ist softwaredefiniert, skalierbar, Cloud-nativ und leistungsstark. Die Leistung kann durch die Auswahl der Hardware (NVMe) und Netzwerk (100 GbE oder höher) , die bequem von Anbietern wie Supermicro, Dell und HPE ab Lager erhältlich sind.

Die Verwendung von Objektspeichern mit dem Data Lake ist Standard, die Verwendung mit dem Data Warehouse ist neu und wird durch Open Table Formats (OTFs) wie Apache Iceberg, Apache Hudi und Delta Lake ermöglicht. Es gibt viele Details zu dieser Architektur, die über den Rahmen dieses Artikels hinausgehen. Dafür empfehle ich die Lektüre von Keith Pijanowskis vollständigem Artikel zum modernen Data Lake . Hier ist die Architektur:

Diese Architektur ist darauf ausgelegt, die folgenden zentralen Betriebsprinzipien der Cloud und damit auch die Kernprinzipien der privaten Cloud bereitzustellen:

Hohe Leistung: Während die Private Cloud auf Kapazität ausgelegt werden kann, zielt die moderne Private Cloud auf skalierbare Leistung ab. Diese Architektur priorisiert Tools, die Geschwindigkeit und Effizienz betonen. Wie Jeff Bezos sagt: Wer möchte mehr bezahlen und länger warten, um es zu bekommen? Hier gelten die gleichen Prinzipien: Wer möchte es langsamer?

Entkoppelte Datenverarbeitung und Speicherung: Durch die Trennung dieser Komponenten erhalten Sie mehr Flexibilität und Skalierbarkeit, sodass die von Ihnen gewählte Infrastruktur, Dienste und Tools in ihren jeweiligen Fachgebieten herausragende Leistungen erbringen können.

Offene Standards: Offene Standards fördern nicht nur die Interoperabilität, sondern machen Ihre Investitionen auch zukunftssicher. Dies umfasst nicht nur Open-Source-Lösungen, sondern auch offene Tabellenformate, wie wir noch untersuchen werden. Bauen Sie aus diesen Gründen keine private Cloud mit einem Speichergerät auf (und auch nicht, weil sie nie Cloud-nativ sein werden).

Kompatibilität mit RESTful-APIs: Interkonnektivität ist ein Muss. Ihre Tools sollten eine gemeinsame Sprache verwenden, wobei S3 als Lingua Franca für Cloud-Speicher dienen sollte. Bauen Sie Ihre private Cloud deshalb nicht mit einer POSIX-zentrierten Lösung auf, selbst wenn diese behauptet, S3 zu unterstützen. Entscheiden Sie sich für das Original.

Softwaregesteuert/Infrastruktur als Code: Automatisieren Sie die Orchestrierung Ihrer Infrastruktur und überlassen Sie sie Kubernetes. So können Sie die Komplexität der manuellen Verwaltung abstrahieren und eine schnelle und effiziente Skalierbarkeit erreichen.

Verbesserte Sicherheit und Compliance: Da private Clouds eine dedizierte Infrastruktur bieten, bieten sie mehr Kontrolle über Daten und verbesserte Sicherheitsmaßnahmen. Dies ist insbesondere für Branchen von Vorteil, in denen vertrauliche Informationen verarbeitet werden, wie etwa im Finanz- und Gesundheitswesen.

Einhaltung gesetzlicher Vorschriften: Diese Architektur kann die Einhaltung gesetzlicher Vorschriften unterstützen, indem sie anpassbare Sicherheitseinstellungen und Prüfkontrollen bereitstellt, um bestimmte Industriestandards zu erfüllen.

Bringen Sie Ihre private Cloud ins Spiel

Wir haben eine Reihe von Ansätzen zur Optimierung der privaten Cloud kennengelernt. Alle können funktionieren. Es hängt wirklich vom Unternehmen und dem Anwendungsfall ab.

• Ein zeitlich begrenztes Hybridmodell, bei dem einige Daten und Anwendungen in der öffentlichen Cloud verbleiben, während die private Cloud hydratisiert wird.
• Vollständige Rückführung von der Public Cloud in eine Private Cloud.
• Greenfield-Aufbau einer privaten Cloud. Dies ist besonders beliebt, wenn Unternehmen ihre KI-Experimente in die Produktion bringen.
• Brownfield-Repatriierung: Sie verschieben Ihre öffentlichen Cloud-Daten und -Infrastruktur zurück in eine vorhandene private Cloud-Bereitstellung. Dieser Ansatz ist zwar kostengünstig, hat aber auch einige Nachteile.
• Die Kategorie „Sonstiges“ (Bursting- und externe Tabellen).

Zeitlich begrenzter Hybridansatz: Der zeitlich begrenzte Hybridansatz verwandelt die öffentliche Cloud im Wesentlichen in einen Cold Storage und baut Ihren Private-Cloud-Footprint über einen bestimmten Zeitraum (Monate/Quartale, nicht Jahre) aus. Dies beinhaltet den Kauf und die Konfiguration Ihrer Infrastruktur und Ihres Software-Stacks in der Private Cloud. Dann richten Sie Ihre Datenpipeline auf die Private Cloud aus, nicht auf die öffentliche Cloud. Es kann einen Zeitraum geben, in dem Sie beides tun. Das Ziel ist jedoch, die öffentliche Cloud als mehrstufigen Cold Storage und die private Cloud als Hot Storage zu verwenden. Im Laufe der Zeit wird die öffentliche Cloud von Cold zu Frozen Storage, während die private Cloud zum primären und dominierenden Speichertyp wird.

Genau das hat ein führender Akteur im Bereich Cybersicherheit getan. Er begann mit der Einrichtung einer privaten Cloud in Zusammenarbeit mit MinIO und Equinix und richtete dann den Datenschwall, der täglich 250 Tebibyte (TiB) umfasst, in diese Richtung. Da Log-Analysen hinsichtlich ihres operativen Werts eine hohe Zerfallsfunktion aufweisen, dauerte es nicht lange, bis die neue private Cloud zur primären Quelle für Daten zur Bedrohungssuche wurde. Diese private Cloud ist auf fast ein Exabyte angewachsen (und wird diese Schwelle bald überschreiten) und die Entscheidung, diese Workloads (tatsächlich das Kerngeschäft) in eine private Cloud zu verlagern (mit Betriebskosten, nicht Investitionskosten), verbesserte die Bruttomarge des Unternehmens um mehr als 2 %. Infolgedessen verfügt dieses Unternehmen über ein Bewertungsmultiplikator, um den es seine Konkurrenten beneiden können.

Vollständige Rückführung : Es gibt Fälle, in denen es keine Option ist, die Anwendungen und Daten sowohl in der öffentlichen als auch in der privaten Cloud zu behalten. In diesen Fällen müssen Sie sich von Ihrem Cloud-Anbieter trennen. Das ist schwierig und selbst durch die Abschaffung der Ausstiegsgebühren wird es schmerzhaft (im Kleingedruckten steht im Grunde, dass alles weg muss, um eine Ermäßigung der Ausstiegsgebühren zu erhalten). Es ist durchaus machbar; es erfordert nur etwas mehr Planung und etwas mehr geschäftliche Reibung. Stellen Sie in diesem Fall Ihre Colocation- oder private Cloud und Ihren Anwendungsstapel bereit. Sichern Sie dann den Datentruck oder leasen Sie das Netzwerk, um die Daten in Ihre private Cloud-Dateninfrastruktur zu übertragen. An diesem Punkt sind Sie frei, aber rechnen Sie damit, für ein oder zwei Monate das Doppelte zu zahlen, wenn Sie der Typ sind, der sich absichert. Eines der führenden Streaming-Unternehmen verfolgte diesen Ansatz, als es die öffentliche Cloud verließ. Es hat ein halbes Exabyte in die neue private Cloud verschoben, einschließlich aller Filme, Shows, Dokumentationen usw. Der Prozess dauerte etwa drei Quartale. Die Auszahlung war jedoch enorm und die Komplexität wurde für das Team, das den Dienst verwaltet, erheblich reduziert. Sie genossen auch den Nebeneffekt eines netten Pop-Ins „ Zeit bis zum ersten Byte “ – eine Schlüsselkennzahl in diesem Bereich.

Private Greenfield-Cloud:

Dies ist ein ziemlich unkomplizierter Vorschlag, und im Allgemeinen muss alles neu sein. Das Projekt ist neu, die Projektdaten sind neu (oder relativ neuartig) oder werden aus einer Quelle generiert, die gerade online geht (wie einer riesigen Fertigungsanlage oder einem neuen Cloud-Video-on-Demand-Dienst). Hier bemessen Sie die Arbeitslast – Sie können sie sogar in der öffentlichen Cloud testen –, aber die Idee ist, dass sie von Anfang an in der privaten Cloud ausgeführt wird. Wir sehen dies recht häufig bei KI-Dateninfrastrukturen. Die ersten Experimente finden in der öffentlichen Cloud statt. Die Daten sind nicht so aussagekräftig. Die GPU-Verfügbarkeit ist ziemlich gut. Nichtsdestotrotz weiß das Unternehmen, dass die Arbeitslast für die Produktion in der privaten Cloud liegen muss – sowohl aus Skalierbarkeitsgründen als auch aus Gründen der Sicherheit, Privatsphäre und Kontrolle. Einer der weltweit führenden Automobilhersteller hat seine Initiative für vollständig autonomes Fahren kürzlich von einem regelbasierten System auf ein System umgestellt, das auf dem Verhalten tatsächlicher Fahrer basiert.

Dieses Verhalten wird aus Millionen und Abermillionen von Videos und Protokolldateien „gelernt“, die von seinen Fahrzeugen stammen. Gute Fahrer, schlechte Fahrer, durchschnittliche Fahrer. Nicht nur aus dem Video, sondern auch aus anderen Elementen der Fahrzeugtelemetrie wie Bremsen, Beschleunigung, Lenkdrehmoment usw. Der regelbasierte ML-Ansatz hatte eine Größenordnung von Petabyte; das Video hat eine Größenordnung von Exabyte. Das Unternehmen gibt diese Daten an niemanden weiter (tatsächlich haben zwei der öffentlichen Clouds konkurrierende Initiativen). Diese KI-Arbeitslast – alle über 300 Server – war immer eine private Cloud-Initiative.

Private Brownfield-Cloud:

Wir sind ehrlich: Wir sehen das, aber wir sind nicht begeistert davon. Dazu gehört der Versuch, Hochleistungs-Workloads auf Festplatten auszuführen, um MinIO zu überlagern oben auf einem SAN/NAS (Storage Area Network/Network Attached Storage).

Es funktioniert, ist aber selten die optimale Lösung. Es ist wirtschaftlich (Sie verwenden Hardware wieder), es ist reibungslos (keine Beschaffung), aber es ist selten leistungsfähig. Trotzdem nehmen wir es hier auf, um es umfassend zu machen. Es wirft einen wichtigen Punkt auf. Wenn Sie Ihre private Cloud entwerfen, planen Sie in jedem der Szenarien Heterogenität ein. Es ist eine Garantie und sollte ehrlich gesagt Teil des Plans sein. In einem der oben genannten Szenarien stammt die Hälfte der Hardware von Supermicro. Die andere Hälfte von Dell. Wenn sich die Welt ändert und neue Technologien verfügbar werden, sollte das Ihrer Software egal sein.

Die Anderen:

Es gibt zwei weitere Szenarien, die weniger häufig vorkommen, aber dennoch berücksichtigt werden sollten. Das eine ist der Hybrid-Burst-Ansatz und das andere der Ansatz mit externen Tabellen. Beide beziehen sich auf die Hybrid-Option, sind aber möglicherweise nicht zeitgebunden. Beim Hybrid-Burst-Ansatz pflegen Sie eine private Cloud, während Sie sie so gestalten, dass sie nahtlos in die öffentliche Cloud erweitert oder „geburstet“ werden kann, um mehr Flexibilität zu bieten. Diese Strategie wird häufig angewendet, um zusätzliche GPU-Kapazität zu nutzen oder bestimmte Cloud-Dienste zu verwenden. In diesem Modell werden bestimmte Aufgaben vorübergehend zur Verarbeitung in die öffentliche Cloud übertragen. Sobald die Analyse abgeschlossen ist, werden die Ergebnisse an die private Cloud zurückgesendet und die Ressourcen der öffentlichen Cloud werden dann außer Betrieb genommen. Wir haben einen großen Kunden aus dem Finanzdienstleistungsbereich, der dies mit Kreditrisiko- und Marktrisikoberechnungen tut. Er verwendet die öffentliche Cloud für einige Rechenvorgänge und kombiniert sie mit einem privaten Cloud-Datensee, der MinIO und Dremio verwendet. Das Schöne am Cloud-Betriebsmodell ist, dass die Architektur Vorgänge an beiden Orten unterstützen sollte. Es ist praktisch eine Einbahnstraße.

Früher war es eine Einbahnstraße, aber die Welt hat sich geändert und Unternehmen haben nun Optionen. Mit der Option externer Tabellen können Unternehmen weiterhin von den Prinzipien des Cloud-Betriebsmodells profitieren, indem sie ihre vorhandenen Cloud-Data-Warehouses wie Snowflake und SQL Server in einen Data Lake integrieren, der auf der privaten Cloud basiert. Mit diesem Hybrid-Setup können Unternehmen von der Leistung, Datensicherheit und dem Open-Standard-Design eines modernen Data Lake profitieren und gleichzeitig von vorhandenen Investitionen in die Cloud-Infrastruktur profitieren. Jeder große Datenbankanbieter bietet mittlerweile Unterstützung für externe Tabellen. Mit dieser Funktion können Benutzer Daten im Objektspeicher überall abfragen, als wären sie eine normale Tabelle in der Datenbank, ohne dass eine Migration erforderlich ist. Ihre Daten bleiben in der privaten Cloud, werden aber überall dort bereitgestellt, wo sie benötigt werden.

Abschließende Gedanken und Ratschläge

Wir waren im Laufe der Jahre an vielen dieser Rückführungen/Neubauten in die Private Cloud beteiligt. Eine Sache, die die Teams überrascht, ist die erneute Verwaltung der Hardware. In der Cloud ist das transparent. DevOps und Site Reliability Engineers interagieren nur auf API-Ebene mit der Infrastruktur. Wenn eine VM Probleme macht, beenden Sie sie und starten Sie an ihrer Stelle eine neue. Leider müssen wir in der neuen Private Cloud die vorhandene Hardware zum Laufen bringen, anstatt sie einfach zu verschrotten und neue zu kaufen.

Infrastrukturmanagement ist eine Sache. Es gehört dazu. Es sollte nicht beängstigend sein, aber es sollte geplant werden. Es muss eine Abgrenzung der Verantwortlichkeiten zwischen der Softwareentwicklungs-/DevOps-Seite und dem Rechenzentrumsingenieur geben. Dieser SME (Fachexperte) in Rechenzentren sollte sich mit der gesamten Hardware bestens auskennen. Er ist für alles und jedes im Zusammenhang mit der Hardware verantwortlich, einschließlich Ausfällen, Ersatz und jeglicher Wartung.

Hier kommt es auf die Software an. Aus diesem Grund hat MinIO die Observability in seine globale Konsole integriert. In der Welt der privaten Cloud sollten Sie intelligente Software und einfache Hardware verwenden. Aber diese Software muss die operative Last dieses wirtschaftlichen Gewinns tragen. Die Hardware-Leute konnten die Observability-Schicht einfach nicht erstellen, das musste MinIO tun.

Wenn Sie eine Organisation sind, die einmal pro Woche Bereitstellungen durchführt, bedeutet das, dass jede Bereitstellung wahrscheinlich ein Spektakel ist. Das liegt daran, dass es bei seltenen Bereitstellungen schwierig ist, Fehler vorherzusagen und zu beheben. Wenn Bereitstellungen nicht wie geplant verlaufen, heißt es: Alle Mann an Deck. Im Allgemeinen würde der Ablauf wie folgt aussehen:

• Entwerfen Sie die Bereitstellung Ihrer Anwendung in einem verteilten Setup
• Testen Sie es in Ihrer lokalen Umgebung
• Weitere Validierung in einer Dev- und Stage-Umgebung
• Hinzufügen von Überwachung, Metriken, Nachverfolgung und Änderung
• Bereitstellen von On-Premise-, Hybrid- und Cloud-Umgebungen

Wenn diese CI/CD-Prinzipien in der Praxis angewendet werden, kann ein starker Rechenzentrumsingenieur, der eng mit einem anderen starken DevOps/SRE-Ingenieur zusammenarbeitet, problemlos über 5.000 Knoten in einer privaten Cloud oder einer Colocation-Einrichtung verwalten. Wir haben Kunden, die genau das tun. Wenn Sie die CI/CD-Grundprinzipien befolgen, kann und sollte fast alles automatisiert werden, und die Rechenzentrums- und DevOps-Ingenieure konzentrieren sich nur auf die Aufgaben, die nicht automatisiert werden können. Und schließlich, falls Sie es verpasst haben: Colocation ist gleichbedeutend mit unserer Definition der privaten Cloud.

Colocation bietet einen Mittelweg zwischen vollständig lokaler Infrastruktur und der öffentlichen Cloud und bietet die Vorteile beider Welten. Mit Zugang zu erstklassigen Netzwerken und der Nähe zu den öffentlichen Cloud-Anbietern ermöglichen Colocation-Anbieter Verbindungen mit geringer Latenz und Hybrid-Cloud-Setups, die eine effiziente Datenübertragung und -verarbeitung ermöglichen. Diese Flexibilität und das Potenzial für erfolgreiche Hybrid-Cloud-Bereitstellungen sind für Unternehmen, die ihre Abläufe optimieren und einen Wettbewerbsvorteil aufrechterhalten möchten, von entscheidender Bedeutung. Weitere Informationen dazu finden Sie in unserem MinIO- und Equinix-Seite .