S3-Objektspeicher-Team hat einen Artikel über die wichtigsten Kriterien bei der Auswahl eines Objektspeichers übersetzt. Im Folgenden der Text aus der Perspektive des Autors.
Wenn es um Objektspeicher geht, denken die meisten Menschen oft nur an eines — die Kosten pro TB/GB. Sicherlich ist diese Kennzahl wichtig, doch sie führt zu einer einseitigen Betrachtung und reduziert den Objektspeicher auf ein Archivierungstool. Zudem mindert dieser Ansatz die Bedeutung des Objektspeichers innerhalb des technologischen Stacks eines Unternehmens.
Bei der Auswahl eines Objektspeichers sollte man auf fünf Eigenschaften achten:
- Leistung;
- Skalierbarkeit;
- S3-Kompatibilität;
- Reaktion auf Ausfälle;
- Integrität.
Diese fünf Eigenschaften sind neue Kennzahlen für Objektspeicher, neben den Kosten. Lassen Sie uns alle genauer betrachten.
Leistung
Traditionelle Objektspeicher zeichnen sich nicht gerade durch hohe Leistung aus. Anbieter haben diese oft zugunsten niedriger Preise geopfert. Mit modernen Objektspeichern sieht das jedoch ganz anders aus.
Die Geschwindigkeit verschiedener Speicherlösungen erreicht annähernd Hadoop oder übertrifft sie sogar. Moderne Anforderungen an die Lese- und Schreibgeschwindigkeit liegen zwischen 10 GB/s für HDDs und bis zu 35 GB/s für NVMe.
Diese Bandbreite reicht aus für Spark, Presto, TensorFlow, Teradata, Vertica, Splunk und andere moderne Berechnungsframeworks im Analyse-Stack. Die Tatsache, dass MPP-Datenbanken auf Objektspeicher ausgerichtet sind, zeigt, dass dieser zunehmend als Hauptspeicher genutzt wird.
Wenn Ihr Speichersystem nicht die erforderliche Geschwindigkeit bietet, können Sie keine Daten nutzen und keinen Mehrwert daraus schöpfen. Selbst wenn Sie Daten aus dem Objektspeicher in eine In-Memory-Verarbeitung extrahieren, ist trotzdem Bandbreite erforderlich, um Daten im und aus dem Speicher zu übertragen. Veraltete Objektspeicher verfügen nicht über ausreichend Kapazität.
Das ist der entscheidende Punkt: Die neue Leistungsmetrik ist die Bandbreite, nicht die Latenz. Sie wird für skalierbare Daten benötigt und ist der Standard in der modernen Dateninfrastruktur.
Obwohl Leistungstests eine gute Methode zur Bestimmung der Performance sind, ist es unmöglich, diese genau zu messen, bevor die Anwendung in einer produktiven Umgebung läuft. Erst danach kann man sagen, wo genau der Engpass liegt: im Softwarebereich, bei den Festplatten, im Netzwerk oder auf der Rechenebene.
Skalierbarkeit
Mit Skalierbarkeit ist die Anzahl der Petabytes gemeint, die in einen einzigen Namensraum passen. Anbieter behaupten oft, dass ihre Skalierbarkeit mühelos ist, verschweigen jedoch, dass massive monolithische Systeme mit zunehmender Skalierung anfällig, komplex, instabil und kostspielig werden.
Eine neue Metrik für Skalierbarkeit ist die Anzahl der Namensräume oder Kunden, die Sie bedienen können. Diese Kennzahl wird direkt von Hyperscalern übernommen, bei denen die Speicherbausteine klein sind, aber auf Milliarden von Einheiten skalierbar. Im Allgemeinen handelt es sich hierbei um eine Cloud-Metrik.
Wenn Standard-Blocks klein sind, lassen sie sich leichter optimieren. Das bedeutet, dass Sicherheit, Zugriffskontrolle, Richtlinienmanagement, Lebenszyklus und Updates ohne Unterbrechung des Betriebs gewährleistet werden können. Letztendlich führt dies zu einer verbesserten Leistung. Die Größe des Bausteins ist eine Funktion der Verfügbarkeitsverwaltbarkeit, und genau so werden hochverfügbare Systeme aufgebaut.
Die Multitenancy hat zahlreiche Merkmale. Während dieser Aspekt beschreibt, wie Organisationen den Zugriff auf Daten und Anwendungen ermöglichen, bezieht er sich auch auf die Anwendungen selbst und die Logik ihrer Isolation voneinander.
Merkmale des modernen Ansatzes zur Multitenancy:
- Die Anzahl der Kunden kann in kurzer Zeit von mehreren Hundert auf mehrere Millionen steigen.
- Die Kunden sind vollständig voneinander isoliert. Dies ermöglicht ihnen, verschiedene Versionen derselben Software auszuführen und Objekte mit unterschiedlichen Konfigurationen, Berechtigungen, Funktionen, Sicherheitsstufen und Wartungsoptionen zu speichern. Dies ist notwendig, wenn neue Server, Updates und geografische Regionen skaliert werden.
- Die Speicherung passt sich flexibel an, Ressourcen werden nach Bedarf bereitgestellt.
- Jede Operation wird über eine API gesteuert und automatisiert ohne menschliches Eingreifen.
- Software kann in Containern bereitgestellt und mit Standard-Orchestrierungssystemen wie Kubernetes verwendet werden.
Kompatibilität mit S3
Die Amazon S3 API ist praktisch der Standard für Objektspeicher. Jeder Anbieter von Objektspeicher-Software gibt an, mit ihr kompatibel zu sein. Die Kompatibilität mit S3 ist binär: Sie ist entweder vollständig implementiert oder gar nicht.
In der Praxis gibt es Hunderte und Tausende von Grenzfällen, bei denen bei der Nutzung des Objektspeichers etwas schiefgeht. Dies gilt insbesondere für Anbieter von proprietärer Software und Dienstleistungen. Die Hauptanwendungsfälle sind direkte Archivierung oder Backup, weshalb es nur wenige Gründe für API-Aufrufe gibt; die Nutzungsszenarien sind homogen.
Open-Source-Software bietet erhebliche Vorteile. Sie deckt die meisten Grenzfälle ab und berücksichtigt dabei die Größe und Vielfalt von Anwendungen, Betriebssystemen und Hardwarearchitekturen.
All dies ist für App-Entwickler wichtig, daher lohnt es sich, die Anwendung mit Speicheranbietern zu testen. Open Source vereinfacht diesen Prozess – es ist einfacher zu verstehen, welche Plattform am besten für Ihre Anwendung geeignet ist. Der Anbieter kann als zentrale Anlaufstelle für die Speicherdienste fungieren – das bedeutet, dass er Ihre Anforderungen erfüllt.
Open Source bedeutet: Anwendungen sind nicht an einen Anbieter gebunden und sind transparenter. Dies sorgt für einen langen Lebenszyklus der Anwendung.
Und noch einige Hinweise zu Open Source und S3.
Wenn Sie eine Anwendung zur Verarbeitung großer Datenmengen betreiben, steigert S3 SELECT erheblich die Leistung und Effizienz. Dies wird erreicht, indem SQL verwendet wird, um nur die Objekte aus dem Speicher zu extrahieren, die Sie benötigen.
Ein entscheidender Aspekt ist die Unterstützung von Bucket-Benachrichtigungen. Diese Benachrichtigungen erleichtern serverlose Berechnungen – ein wesentlicher Bestandteil jeder als Dienst angebotenen Microservice-Architektur. Da Object Storage in der Tat Cloud-Speicher darstellt, wird diese Funktion entscheidend, wenn Cloud-Anwendungen auf Object Storage zugreifen.
Schließlich sollte die Implementierung von S3 die von Amazon S3 bereitgestellten Server-seitigen Verschlüsselungs-APIs unterstützen: SSE-C, SSE-S3, SSE-KMS. Noch besser wäre es, wenn S3 auch tatsächlich sichere Zugriffsschutzmaßnahmen bietet.
Reaktion auf Fehler
Ein oft übersehener Aspekt ist, wie das System mit Ausfällen umgeht. Ausfälle können aus verschiedenen Gründen auftreten, und Object Storage muss alle handhaben können.
Zum Beispiel kann es einen einzigen Punkte des Ausfalls geben, dessen Metrik gleich null ist.
Leider verwenden viele Object Storage-Systeme spezielle Knoten, die aktiviert werden müssen, damit der Cluster korrekt funktioniert. Dazu gehören Namens- oder Metadatenserver – was einen einzigen Punkt des Ausfalls schafft.
Selbst bei mehreren redundanten Punkten steht die Fähigkeit, katastrophale Ausfälle zu bewältigen, an oberster Stelle. Festplatten fallen aus, Server fallen aus. Der entscheidende Punkt ist die Entwicklung von Software, die dafür ausgelegt ist, Fehler als normalen Zustand zu behandeln. Bei einem Ausfall von Festplatte oder Knoten wird diese Software weiterhin ohne Unterbrechungen arbeiten.
Integrierter Schutz gegen Datenverlust und -degradation stellt sicher: Sie können so viele Festplatten oder Knoten verlieren, wie Sie Paritätsblöcke haben — normalerweise ist das die Hälfte der Festplatten. Erst dann kann die Software keine Daten mehr zurückgeben.
Ausfälle werden selten unter Last getestet, aber solche Tests sind unerlässlich. Das Simulieren eines Ausfalls unter Last zeigt die Gesamtkosten, die nach einem Ausfall entstehen.
Konsistenz
Ein Konsistenzwert von 100 % wird auch als strenge Konsistenz bezeichnet. Konsistenz ist ein Schlüsselfaktor in jedem Speichersystem, jedoch ist strenge Konsistenz recht selten. Zum Beispiel ist Amazon S3 ListObject nicht streng konsistent, sondern nur am Ende konsistent.
Was versteht man unter strenger Konsistenz? Für alle Vorgänge nach einer bestätigten PUT-Operation muss Folgendes gelten:
- Der aktualisierte Wert ist beim Lesen von jedem Knoten sichtbar.
- Das Update ist durch Failover des Knotens abgesichert.
Das bedeutet: Wenn der Stecker mitten im Vorgang gezogen wird, gehen keine Daten verloren. Das System gibt niemals beschädigte oder veraltete Daten zurück. Dies ist eine hohe Messlatte, die in vielen Szenarien von Bedeutung ist: von transaktionsbasierten Anwendungen bis hin zu Backup und Wiederherstellung.
Fazit
Dies sind neue Metriken für Objektspeicher, die Nutzungsmuster in modernen Organisationen widerspiegeln, in denen Leistung, Konsistenz, Skalierbarkeit, Ausfalldomänen und Kompatibilität mit S3 die Bausteine für Cloud-Anwendungen und Big Data-Analysen sind. Ich empfehle, diese Liste zusammen mit dem Preis beim Aufbau moderner Datenstacks zu verwenden.
Über den Objektspeicher von Mail.ru Cloud Solutions: .
Weitere Leseempfehlungen:
- .
- .
- .
Quelle: habr.com
