6 Nicht jeden Tag kann man auf der Welle eines grundlegenden technologischen Wandels reiten. Ich möchte ein wenig darüber erzählen, wie ich mich dabei über Wasser halte. Meine erste Begegnung mit gemeinsam genutztem Speicher war die ursprüngliche HP-EVA-Serie. Die Systeme waren ziemlich großartig: Über eine einzige, benutzerfreundliche Weboberfläche kam man in wenigen Stunden vom Einschalten bis zum Produktivbetrieb. LUNs (Logical Unit Numbers), so groß, dass sie über 20 virtuelle Maschinen beherbergen konnten, wurden automatisch auf Hunderte von Laufwerken verteilt und nutzten die gesamte Kapazität und Leistung, um das zu liefern, was man später „Private Clouds“ nennen sollte. Dedizierte, getrennte und redundante Fibre-Channel-Netzwerke (FC) garantierten selbst bei extremster Auslastung eine effiziente Datenbereitstellung. Im Lauf der Jahre sind diese Private Clouds exponentiell gewachsen. 20 virtuelle Maschinen kann heute jeder mit einer Kreditkarte und zehn zusätzlichen Minuten in der Mittagspause starten. Unstrukturierte Daten drehen seit Jahren ihre Runden um die herkömmlichen Daten, und die Ziellinie hat sich bis in den Exabyte-Bereich verschoben. Ich habe die Runde bei den Speicheranbietern für Großunternehmen gemacht und mit einigen der größten, schnellsten und coolsten Arrays überhaupt gearbeitet. Wuchtige Arbeitstiere mit Latenzen unter einer Millisekunde, die buchstäblich eine Kugel einstecken und weiterlaufen können, werden immer einen besonderen Platz in meinem Herzen haben. Doch vor Kurzem habe ich beschlossen, einen Sprung nach vorn zu wagen und auf den Zug des massiv skalierbaren, softwaredefinierten Speichers aufzuspringen. Ich bin weit davon entfernt, ein Guru zu sein, möchte Ihnen aber einige der gedanklichen Umstellungen vorstellen, die der Wechsel von der einen Welt in die andere erfordert. Ich lerne noch jeden Tag dazu, doch hier sind einige der größten mentalen Hürden, die ich nehmen musste: RAID ist ein Risiko. Früher gaben mir Paritätsfestplatten ein wohliges Gefühl, und Hot Spares ließen mich nachts ruhig schlafen. RAID-Schutz ist eine solide Entscheidung für ein einzelnes Speichersystem in einem einzelnen Rack in einem einzelnen Rechenzentrum, das Daten für eine einzelne Anwendung bereitstellt. Doch sobald skaliert wird, entstehen Probleme. Heute ist es üblich, Festplattengruppen aus Effizienzgründen zu Pools zusammenzufassen. Der Verlust einer einzelnen RAID-Gruppe in einem modernen FC-Array führt zum Ausfall des gesamten Systems – ich habe es selbst erlebt. Es reicht, wenn zwei oder drei Laufwerke gleichzeitig ausfallen, und jemand bekommt um 3 Uhr morgens einen Anruf, um sich um den Ausfall zu kümmern und ihn so schnell wie möglich zu beheben. Um dem vorzubeugen, müssen Systemadministratoren ihre Daten in einem primären Speichersystem mit RAID schützen und zugleich vollständig replizierte Kopien auf einem sekundären System vor Ort vorhalten. Sind die Daten kritisch, werden sie zusätzlich auf ein weiteres dediziertes System an einem anderen Standort repliziert. Das sind drei vollständige Kopien Ihrer Daten auf Systemen, die durch RAID 6 ohnehin schon 25 % ihrer Kapazität einbüßen. Konkret sieht das so aus: 100 TB nutzbare Kapazität auf einem gemeinsam genutzten Array mit RAID-6-Festplattengruppen (6+2) erfordern rund 133 TB Rohspeicher. Dieser muss lokal per Snapshot auf ein Standby-System im selben Rechenzentrum gesichert und für das Disaster Recovery an einen anderen Standort repliziert werden. Das sind 400 TB Rohspeicher für eine 100-TB-Anwendung. Hinzu kommen FC-Switches, der Verwaltungsaufwand für Clustering und Failover und womöglich sogar lokale Backups zum Schutz vor Beschädigungen, die sich über die Leitungen replizieren. Das ist eine Menge System für ein bisschen Daten. Seit Jahren wird an neuen Wegen zum Schutz von Daten gearbeitet, und die beiden sinnvollsten in einem verteilten System sind softwarebasiertes Erasure Coding und vollständige Replikate. Beide haben ihre Stärken und Schwächen, weshalb moderne Speichersysteme beide unterstützen sollten – mit einer automatisierten Zuweisung von Richtlinien auf Basis von Kriterien wie Dateigröße und Zugriffspunkt. Das wäre Stoff für einen eigenen Beitrag, doch wichtig ist: Wir können heute über Zahlen wie 28 % Overhead statt der oben genannten 300 % sprechen – bei einer Verfügbarkeit, die um mehrere Größenordnungen höher ist als bei herkömmlichem Speicher. Die Welt läuft nicht in Mikrosekunden. SAP HANA. Oracle. HPC. Diese Umgebungen leben von IOPS (Input/Output Operations per Second) und sehr niedriger Latenz. Die Systeme, die sie unterstützen, sind sehr cool und sehr teuer. Sie haben weiterhin einen wichtigen Platz im Rechenzentrum, doch diese Nische schrumpft – in den Schatten gestellt vom unglaublichen Ausmaß unstrukturierter Daten, die Nutzer weltweit erzeugen und konsumieren. Wenn ich mich hinsetze, um die neueste Folge von Game of Thrones zu streamen, will ich sie sofort sehen. Ich erwarte nicht, zehn Minuten lang ein Rad kreisen zu sehen, während der Inhalt genug puffert. Einen gewissen Spielraum toleriere ich aber – sagen wir etwa 20 ms, bis das Backend die ersten Bits abruft, und ein paar weitere Sekunden, bis das Licht quer durchs Land in mein Wohnzimmer gereist ist. Diese Art von Daten nimmt im Rechenzentrum immer mehr Raum ein, und Aspekte wie Zugänglichkeit, Verwaltbarkeit und einfache Skalierung haben Vorrang vor Leistungsanforderungen unter einer Millisekunde. Wir müssen anfangen, Leistung anders zu denken: als Fähigkeit eines Speichersystems, Inhalte so bereitzustellen, dass die Erwartungen der Endnutzer erfüllt oder übertroffen werden. „Objects per Second“ (OPS) ist ein Begriff, den Sie immer häufiger hören werden. Der Durchsatz bleibt eine zentrale Leistungskennzahl und ergibt sich als Produkt aus OPS und der Größe der bereitgestellten Daten. Spezialsysteme sind nicht der Heilige Gral. Anwendungsadministratoren und Speicherarchitekten sind sich nicht immer einig, arbeiten aber auf ein gemeinsames Ziel hin: Umsatz generieren und Risiken verringern. Manchmal geraten sie auf dem Weg zum selben Ziel aneinander: Die Anwendungsleute wollen, dass ihre Anwendung in der effizientesten, verfügbarsten und leistungsstärksten Umgebung läuft. Sie wollen mehr Anwendungsressourcen bereitstellen, wann sie wollen, und es soll einfach funktionieren. Die Speicherleute wollen ihre Service Level Agreements (SLAs) einhalten, ohne bei jeder neuen Initiative ein neues Rechenzentrum zu bauen. In den letzten Jahren haben die Anwendungsteams die klassischen Beschaffungsprozesse für Speicher umgangen und Systeme selbst gekauft. Sie haben Budget und Einfluss. In jüngster Zeit gehen Unternehmen gegen diese „Schatten-IT“ vor, und die Systeme landen wieder im Rechenzentrum – und raten Sie mal, wer sie verwalten muss? Genau, das Speicherteam. Wäre es nicht großartig, wenn das Speicherteam den Anwendungsleuten genau die Workloads bereitstellen könnte, die sie brauchen, über die gewünschten Protokolle und in einem Zeitrahmen, der niemandes Deadlines verschiebt? Einmalige Anschaffungen von Systemen, die nur eine Sache können, mögen im Notfall helfen, schaden aber den langfristigen Zielen aller Beteiligten. Eine universelle Multiprotokoll-Lösung auf Standardhardware, die die vielfältigen Anforderungen einer Branche abdeckt, IST der Heilige Gral – und sie ist schon heute verfügbar. Wie geht es weiter? Mit dem wachsenden Verhältnis unstrukturierter zu strukturierten Daten wird auch das Verhältnis von Speichersystemen für Erstere zu solchen für Letztere wachsen. Ich glaube nicht, dass dedizierte Speicher-Arrays verschwinden werden. Tatsächlich erwarte ich von den großen Speicheranbietern einige wirklich spannende Innovationen für größere und leistungsstärkere Systeme, die einige der Aufgaben übernehmen, die nötig sind, um aus all diesen unstrukturierten Daten echten Wert zu ziehen. Doch die Welt verändert sich, und wir müssen weiterhin anders denken, wenn wir relevant bleiben wollen. Denken Sie an Peer-to-Peer-Technologie. An Standardkomponenten. An die Verlagerung klassischer Funktionen von der Hardware in die Software, sodass eine anwendungszentrierte Umgebung entsteht, die mit der Zeit skaliert. Denken Sie an softwaredefinierten Speicher. Foto von Samuel Zeller (auf Englisch) auf Unsplash (auf Englisch)
