Thought Leadership
Cloud-Dateien lassen sich nicht ohne weiteres zu einem anderen Provider migrieren, erklärt Gerald Sternagl, Business Unit Manager Storage, EMEA bei Red Hat. Unternehmen stehen auf Dauer vor dem Problem sich für den zentralen Standort Cloud entscheiden zu müssen. Billig wird dies nicht. Konsistente Datenhaltung und Disaster-Recovery-Fähigkeiten stehen gegen die Kosten für synchrone Replikation und Netzwerktransfers.
Filesysteme müssen in absehbarer Zeit viele PByte an Daten verwalten. Wie kann man Filesysteme schneller machen, damit Anwender und Applikationen nicht ewig auf Ergebnisse warten müssen?
Gerald Sternagl, Red HatSternagl: Alle führenden modernen Filesysteme, die in der Lage sind, Datenmengen im PByte-Bereich zu verwalten, beruhen auf verteilten Scale-Out-Architekturen. Es gibt keine echte Alternative zu dieser Architektur, wenn es darum geht, massive Skalierbarkeit, Performance und Kosteneffizienz zu kombinieren.
Erste verteilte Filesysteme verwalten Dateien in Private und Public Clouds. Wie schaffen es solche Global Name Spaces, dass manuelle oder automatische Kopieraktionen von Dateien konsistent für das Dateisystem erfolgen?
Sternagl: Ein globaler Namespace kann mit Storage-Services aus der Cloud um einen zusätzlichen Storage-Tier erweitert werden. Der leistungslimitierende Faktor ist nicht die Storage-Performance in der Public-Cloud, die ähnlich zu der einer On-Premise-Umgebung sein kann, sondern die Netzwerkverbindung zu den externen Services. Den Datenzugriff auf die Public-Cloud On-Premise zu cachen, trägt typischerweise dazu bei, diesen Zugriff zu beschleunigen. Anstatt ein Filesystem von der On-Premise-Umgebung bis zur Public-Cloud zu spannen, empfehlen wir jedoch zwei andere Möglichkeiten:
Erstens können Administratoren ein verteiltes Filesystem erstellen, das nur in der Public-Cloud und in verschiedenen Availability-Zones (Verfügbarkeitszonen) hinweg läuft, um die Verfügbarkeit und Redundanz aufrechtzuerhalten. Dieses Filesystem wird vorwiegend auch von Applikationen genutzt, die in der Public-Cloud laufen. Dadurch bleiben die Latenzen niedriger und die Sicherheit lässt sich besser überwachen.
Zweitens können Administratoren die Public-Cloud als Disaster-Recovery-Kopie eines On-Premise betreiben, verteilte Filesystems nutzen, auf die beim Ausfall eines lokalen Rechenzentrums umgeschaltet werden kann. Wir setzen in diesem Szenarium auf eine asynchrone Replikation, da sie eine bessere Performance bietet.
Welche Fähigkeiten von globalen Dateisystemen für eine Multi-Cloud-Umgebung sind zukünftig unverzichtbar oder wird die einzelne Datei hinter einer Objektspeicherung versteckt werden?
Sternagl: Da jeder Public-Cloud-Provider seine eigenen proprietären Storage-Services und APIs nutzt, bedeutet dies, dass Anwender, die diese Services nutzen, an einen bestimmten Cloud-Provider gebunden sind. Der Wechsel des Cloud-Providers und die Migration riesiger Datenmengen werden so zu einer echten Herausforderung. Wir empfiehlen daher den Einsatz einer offenen Technologie wie Red Hat GlusterFS, um Daten in der Cloud zu verwalten und um von den verschiedenen zugrundeliegenden Storage-Services jedes Cloud-Providers zu entkoppeln. Eine entscheidende Rolle bei der Speicherung von Unternehmensdaten in der Cloud spielen auch die In-Transit- und At-Rest Datenverschlüsselung.
Wozu brauchen wir künstliche Intelligenz im Dateisystem?
Sternagl: Aktuell nutzen die führenden Anbieter verteilter Filesysteme und Lösungen praktisch keine echten KI-Technologien. Red Hat setzt in seinen Produkten eine große Zahl sich selbst verwaltender Funktionen ein, da sie die Administration riesiger Datenmengen deutlich vereinfachen. Dies könnte als KI vermarktet werden, aber was hier fehlt, ist die Selbstlernfähigkeit von KI.
Ich kann mir vorstellen, dass KI in Zukunft in einer Vielzahl von Bereichen moderner verteilter Filesysteme eingesetzt werden kann, beispielsweise zur Verbesserung der Hot-Spot- und Fehlererkennung und -korrektur, für Performance-Tuning, für selbstlernendes adaptives Load-Balancing, sowie für das Sicherheits- und Schwachstellen-Management.
.
