Individuell abgestimmte Verwaltung der Storage-Kapazitäten und Auto-Skalierung Datenmanagement mit intelligentem Tiering und Autoscaling

Datenmanagement im Storage-Bereich ist einer der am schnellsten wachsenden Bereiche in der Storage-Software-Entwicklung. Denn mit einem intelligenten und ausgefeilten, individuell angepassten Datenmanagement lassen sich erhebliche Kosten einsparen. Cloud-Service-Provider wie Rubrik, Amazon Web Services oder MS Azure können mit ausgefeilten Angeboten aufwarten, die bis zum Schutz vor Ransomware reichen.

Anbieter zum Thema

Dell GmbH

PoINT Software & Systems GmbH

DataCore Software GmbH

Intelligentes Tiering

Die Storage-Architektur eines Unternehmens umfasst schnelle und langsame Medien, neue und alte Daten sowie unterschiedlich gewichtete Workloads. Diese drei Vorgaben lassen sich dazu nutzen, um ein individuell gestaltetes und zugleich kostenoptimiertes Tiering von Storage-Kapazitäten zu realisieren.

Medien

Schnelle Medien sind Flash-Speichersysteme wie SSDs und All-Flash-Arrays. Langsamere Medien sind Festplatten, die inzwischen hinsichtlich ihrer Kapazität stark zugelegt haben. Das langsamste Medium sind Bandlaufwerke und Tape-Libraries. Diese weisen pro Medium die niedrigsten Kosten pro Gigabyte auf, aber mitunter die höchsten Kapazitäten.

Tapes werden in erster Linie für die Archivierung genutzt, Festplatten für längerfristig wertvolle Daten und Flash-Speicher für Daten mit sehr hohem I/O wie etwa Streaming, aber auch für die „heißesten“ Daten wie etwa für NoSQL-Datenbanken, die IoT- und ähnliche Daten speichern und verarbeiten. Nur DRAM ist schneller als Flash-Speicher, und diese Entwicklung wird massiv vorangetrieben.

Speicherdauer

Wenn ein Unternehmen eine Public Cloud wie Azure nutzt, so werden Daten wie etwa Backup-Snapshots als Block-Storage-Objekte (BLOBs) abgelegt. Sie landen zunächst auf dem „Instant Tier“, sind also „heiß“ – und ihre Speicherung verursacht je nach Medium (Flash, Festplatte, Tape) entsprechend hohe Gebühren. Um diese Gebühren zu vermeiden, kann der Nutzer festlegen, dass solche Daten sofort auf die kostengünstigste Ebene, nämlich „Archive Tier“, verschoben werden. Microsoft gibt an, dass durch intelligentes Tiering 95 Prozent Kosteneinsparung gegenüber nicht-organisiertem Tiering erzielt werden können.

Der Nachteil beim Archive Tier besteht darin, dass die Dauer der Abfrage oder Wiederherstellung, formuliert als Recovery Time Objective (RTO), erheblich länger ist als etwa bei einer mittelfristigen Speicherung: Laut Microsoft-Handbuch kann dies bis zu 15 Stunden dauern. Das ist aber bei Azures Mitbewerbern nicht viel anders.

Im Zweifelsfall ist es empfehlenswert, auf den Archive Tier (Azure-Minimumdauer: 180 Tage) zu verzichten und den Cool Tier (Azure-Minimumdauer 30 Tage) zu wählen. Diese Fristen sollte man auf jeden Fall beachten, denn sie variieren von Anbieter zu Anbieter. Wer nämlich seine Daten zu früh, also vor Ablauf der Minimumspeicherdauer, abruft und wiederherstellt, der zahlt eine Vorzeitigkeitsstrafe. Fast wie bei einem vorzeitig abgelösten Darlehen, bei dem die Bank dann Vorfälligkeitsgebühren geltend macht. Am besten vereinbart man solche Fristen in den Service Level Agreements (SLAs). Die SLAs lassen sich durch Einsatz von Algorithmen einhalten, und für jede Domain können andere SLA-Vorgaben oder -Richtlinien implementiert werden. Wie sinnvoll das ist, zeigt sich bei den Workloads.

Workloads

Intelligentes oder „Smart“ Tiering berücksichtigt aber nicht nur das Alter der Daten und die Geschwindigkeit von Medien, sondern auch Workloads. Manche Workloads erfordern schnelle Medien, anderen reichen langsame Medien. Manche haben einen hohen Datendurchsatz (Streaming, IoT, Security), andere wenig (Cool Tier), wieder andere gar keinen (Archivierung). Jede Workload benötigt also ihre optimalen Kapazitäten und Ressourcen.

Damit der Storage-Admin entlastet wird, lässt sich Intelligentes Workload Tiering mithilfe der oben erwähnten Algorithmen automatisch einrichten. Noch schlauer sind Machine-Learning-Modelle, die lernfähig sind und sich infolgedessen einem Wandel im Workload-Bedarf anpassen können. Da die Modelle auch nur mit Algorithmen arbeiten, braucht man keinen Data-Scientist für ihre Erstellung.

Tatsächlich haben sowohl die Hersteller von Storage-Software als auch die Cloud-Provider selbst entsprechende KI-Modelle vorrätig. Sie haben ein Interesse daran, dass ihre Kunden sowohl mit der Leistung und Zuverlässigkeit der Storage-Services als auch mit den optimierten Kostenstrukturen zufrieden sind. Denn nur zufriedene Kunden zahlen monatliche Gebühren.

Autoscaling

Wenn es bereits eine Kubernetes-Infrastruktur, also einen K8S-Cluster, in der IT eines Unternehmens gibt, eröffnet sich eine ausgezeichnete Gelegenheit, auf KI-Schnickschnack zu verzichten und die Dienste eines Autoscalers in Anspruch zu nehmen. Der Use-Case: wenn Workloads inkonsistent sind, Spitzen aufweisen und allgemein schwer vorherzusagen sind. Dann versagen Regeln und Modelle. Dennoch lassen sich eindrucksvolle Cloud-Kostenvorteile erzielen.

So ein Autoscaler passt die nötigen Cloud-Ressourcen, wie etwa Storage und Compute, automatisch den angeforderten Workloads an, um so die On-demand-Nutzung von K8S-Ressourcen zu ermöglichen. Voraussetzung ist das Vorhandensein eines Kubernetes-Services: Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) oder Google Kubernetes Engine (GKE).

Beim Software-Hersteller Rubrik machten die IT-Mitarbeiter einen Versuch mit Autoscalern und erzielten im Compute-Bereich eine Einsparung von nicht weniger als 40 Prozent gegenüber der Nutzung ohne Autoscaler. Vom Ansatz, einen eigenen Autoscaler zu bauen, kam man bald ab, denn das Ergebnis sah den fertigen Autoscalern bei Google, AWS und Azure ziemlich ähnlich.

Der erste Einsatz des Azure-Autoscalers im AKS verlief bescheiden: Das ernüchternde Ergebnis lag im Compute-Bereich nur vier Prozent Kosteneinsparungen über dem Standard, weil der Autoscaler die „arbeitslosen“ Zyklen kaum reduzierte. Dies zwang die Mitarbeiter zu dem Schluss, dass auch ein Autoscaler noch etwas Nachhilfe braucht, nämlich individuelle Einstellungen.

Bei genauerem Hinsehen wurden zwei Modi für „Scale-Up“ und „Scale-Down“ ausgemacht, welche wiederum von mehreren Parametern abhängig sind, beispielsweise von den Messzeiten, den K8S-Pods und den maximalen beziehungsweise minimalen Pods pro Node. Um noch genauer bestimmen zu können, welche Ergebnisse erzielt werden sollen, wählten die Entwickler einen angepassten Kubernetes Scheduler.

Der Scheduler legt durch seine Policies fest, wie viele Pods einem Node zugewiesen werden, um eine Anwendung beziehungsweise deren Ressourcen auszuführen. Das Ergebnis: Es gab kaum noch Ruhephasen für die Ressourcen, und die Kosteneinsparung betrug über 40 Prozent. Die zweite Variante erlaubt die Steuerung langfristig laufender Workloads, etwa Metrik-Server oder System-Pods. Solche Tasks dürfen nicht heruntergefahren werden. Werden sie auf verschiedene Nodes verteilt, hindern sie diese an der Skalierung.

Der Workaround: Solche Tasks wurden mit Hilfe des Merkmals Node Affinity einem bestimmten Pod zugewiesen, der nicht skaliert zu werden brauchte oder anders terminiert wurde. Wird das Merkmal mehreren Pods zugewiesen, kann Scheduler automatisch unter diesen wählen, wo der Pod ausgeführt werden soll.

Es gibt allerdings servicespezifische Unterschiede. So ließen sich die Vorgaben für System-Pods des AKS nicht ändern. Die Autorin des Rubrik-Blogs schlägt die Nutzung von Multi-Node-Pools vor, in denen die jeweils nötigen Nodes und Pods spezifiziert werden könnten.

AWS hat seinen eigenen Blogpost zum Thema Autoscaler für EC2-Instanzen veröffentlicht. Auf GitHub findet sich eine Übersicht über verbreitete Autoscaler – und über ihre Bugs und Bugfixes.

Aktuelles eBook

SDS für den Mittelstand

Wie baut man heutzutage eine moderne Speicherinfrastruktur? Um den Anforderungen des Business zu genügen, müssen die Verantwortlichen softwarebasierte Lösungsansätze verfolgen. Wir stellen die vielversprechendsten für den Mittelstand vor.

Das eBook behandelt die folgenden Themen:

• SDS – wieso, wozu, was soll das?
• So baut man heute moderne Speicherinfrastrukturen. SDS ist nicht gleich SDS.
• So machen Sie Ihren Storage fit für die Zukunft. Wohin entwickelt sich SDS?
• Strategische Empfehlungen speziell für KMU. Ausgestaltung einer erfolgreichen Storage- und Datenstrategie.

eBook „SDS für den Mittelstand“ kostenlos downloaden

(ID:47975862)