
Team des Objekt-S3-Speichers hat einen Artikel ĂŒbersetzt, der die wichtigen Kriterien bei der Auswahl eines Objektspeichers beschreibt. Im Folgenden der Text aus der Autorensicht.
Wenn es um Objektspeicher geht, denken die Leute in der Regel nur an eine Kennzahl â den Preis pro TB/GB. NatĂŒrlich ist diese Kennzahl wichtig, jedoch macht sie den Ansatz einseitig und stellt den Objektspeicher als ein Werkzeug zur Archivierung dar. AuĂerdem mindert dieser Ansatz die Bedeutung des Objektspeichers im Technologiestack eines Unternehmens.
Bei der Auswahl eines Objektspeichers sollten Sie auf fĂŒnf Merkmale achten:
- Leistung;
- Skalierbarkeit;
- KompatibilitÀt mit S3;
- Reaktion auf AusfÀlle;
- IntegritÀt.
Diese fĂŒnf Merkmale sind neue Kennzahlen fĂŒr Objektspeicher, gleichwertig mit den Kosten. Lassen Sie uns alle betrachten.
Leistung
Traditionelle Objektspeicher zeichnen sich nicht durch hohe Leistung aus. Dienstanbieter opferten stÀndig die Leistung im Streben nach niedrigen Preisen. Bei modernen Objektspeichern ist das jedoch anders.
Die Geschwindigkeit verschiedener Speichersysteme nĂ€hert sich Hadoop oder ĂŒbertrifft sie sogar. Moderne Anforderungen an Lese- und Schreibgeschwindigkeiten liegen bei 10 GB/s fĂŒr Festplatten bis zu 35 GB/s fĂŒr NVMe.Â
Eine solche Bandbreite reicht aus fĂŒr Spark, Presto, Tensorflow, Teradata, Vertica, Splunk und andere moderne Rechenframeworks im Analytics-Stack. Die Tatsache, dass MPP-Datenbanken auf Objektspeicher eingestellt werden, zeigt, dass sie zunehmend als primĂ€rer Speicher genutzt werden.
Wenn Ihr Speichersystem nicht die benötigte Geschwindigkeit bietet, können Sie die Daten nicht nutzen und daraus keinen Wert schöpfen. Selbst wenn Sie Daten aus dem Objektspeicher in eine In-Memory-Verarbeitung ĂŒberfĂŒhren, ist dennoch Bandbreite erforderlich, um Daten ins und aus dem Speicher zu ĂŒbertragen. Bei veralteten Objektspeichern gibt es dafĂŒr nicht genĂŒgend Bandbreite.
Das ist der entscheidende Punkt: Das neue LeistungsmaĂ 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 Möglichkeit zur Bestimmung der Leistung sind, lÀsst sie sich nicht genau messen, bevor die Anwendung in einer Umgebung gestartet wird. Erst danach kann gesagt werden, wo genau das Engpass liegt: in der Software, den Festplatten, dem Netzwerk oder auf der Ebene der Berechnungen.
Skalierbarkeit
Unter Skalierbarkeit versteht man die Menge an Petabyte, die in einen Namensraum passt. Anbieter geben an, dass sie leicht skalierbar sind, verschweigen jedoch, dass massive monolithische Systeme beim Wachstum brĂŒchig, komplex, instabil und teuer werden.
Der neue Skalierbarkeitsindikator ist die Anzahl der NamensrÀume oder Clients, die Sie bedienen können. Diese Metrik stammt direkt von Hyperscalern, bei denen die Speicherbausteine klein sind, sich jedoch bis zu Milliarden Einheiten skalieren lassen. Insgesamt ist dies eine Cloud-Metrik.
Wenn Standardbausteine klein sind, lassen sie sich leichter optimieren, das heiĂt, Sicherheit, Zugriffskontrolle, Richtlinienmanagement, Lebenszyklusmanagement und Aktualisierungen können ohne Unterbrechung der Dienste sichergestellt werden. Und letztendlich sorgt dies fĂŒr die Leistung. Die GröĂe des Bausteins ist eine Funktion der Manageability des Ausfallbereichs, so werden hochverfĂŒgbare Systeme gebaut.
Die Multitenancy hat viele Eigenschaften. WÀhrend der Parameter beschreibt, wie Organisationen Zugang zu Daten und Anwendungen gewÀhren, bezieht er sich auch auf die Anwendungen selbst und die Logik ihrer Isolation voneinander.
Die Merkmale des modernen Ansatzes zur Multitenancy:
- In kurzer Zeit kann die Anzahl der Clients von mehreren Hundert auf mehrere Millionen steigen.
- Die Clients sind vollstÀndig voneinander isoliert. Dies ermöglicht es ihnen, verschiedene Versionen derselben Software zu betreiben und Objekte mit unterschiedlichen Konfigurationen, Berechtigungen, Funktionen, Sicherheits- und Wartungslevels zu speichern. Dies ist notwendig, wenn neue Server, Updates und geografische Regionen skaliert werden.
- Der Speicher skalierbar elastisch, Ressourcen werden nach Bedarf bereitgestellt.
- Jede Operation wird ĂŒber eine API gesteuert und automatisiert ohne menschliches Eingreifen.
- Software kann in Containern bereitgestellt werden und standardisierte Orchestrierungssysteme wie Kubernetes nutzen.
KompatibilitÀt mit S3
Amazon S3 API â faktisch der Standard fĂŒr objektbasierte Speicher. Jeder Softwareanbieter fĂŒr objektbasierte Speicherung gibt seine KompatibilitĂ€t damit an. Die KompatibilitĂ€t mit S3 ist binĂ€r: entweder sie wird vollstĂ€ndig umgesetzt oder gar nicht.
In der Praxis gibt es Hunderte und Tausende von GrenzfĂ€llen, in denen bei der Nutzung von objektbasierter Speicherung etwas schiefgeht. Besonders bei Anbietern proprietĂ€rer Software und Dienste. Die Hauptverwendungszwecke sind direkte Archivierung oder Datensicherung, sodass es nur wenige GrĂŒnde fĂŒr die API-Nutzung gibt und die Nutzungsszenarien homogen sind.
Es gibt erhebliche Vorteile fĂŒr Software mit offenem Quellcode. Sie deckt die meisten GrenzfĂ€lle ab und berĂŒcksichtigt die GröĂe und Vielfalt von Anwendungen, Betriebssystemen und Hardwarearchitekturen.
Dies ist wichtig fĂŒr Anwendungsentwickler, daher sollte man die Funktionsweise der Anwendung mit verschiedenen Speicheranbietern testen. Offener Quellcode vereinfacht den Prozess â es ist leichter zu verstehen, welche Plattform fĂŒr Ihre Anwendung geeignet ist. Der Anbieter kann als ein einziger Einstiegspunkt zu den Speichern genutzt werden â das bedeutet, dass er Ihre Anforderungen erfĂŒllt.Â
Offener Quellcode bedeutet: Anwendungen sind nicht an einen Anbieter gebunden und sind transparenter. Dies gewÀhrleistet einen langen Lebenszyklus der Anwendung.
Und noch ein paar Anmerkungen zu offenem Quellcode und S3.Â
Wenn Sie eine Anwendung fĂŒr groĂe Datenmengen betreiben, verbessert S3 SELECT die Leistung und Effizienz erheblich. Dies geschieht durch die Verwendung von SQL, um nur die Objekte aus dem Speicher zu extrahieren, die Sie benötigen.
Ein wesentlicher Punkt ist die UnterstĂŒtzung von Bucket-Benachrichtigungen. Bucket-Benachrichtigungen vereinfachen serverlose Berechnungen â ein wichtiger Bestandteil jeder als Dienst bereitgestellten Mikrodienstarchitektur. Da der objektbasierte Speicher faktisch ein Cloud-Speicher ist, wird diese Funktion entscheidend, wenn cloudbasierte Anwendungen den objektbasierten Speicher verwenden.
SchlieĂlich sollte die Implementierung von S3 die Server-seitigen VerschlĂŒsselungsschnittstellen des Amazon S3 API unterstĂŒtzen: SSE-C, SSE-S3, SSE-KMS. Noch besser wĂ€re es, wenn S3 unbefugten Zugriff schĂŒtzt, der tatsĂ€chlich sicher ist.Â
Reaktion auf AusfÀlle
Ein Indikator, der wahrscheinlich oft ĂŒbersehen wird, ist, wie das System mit AusfĂ€llen umgeht. Fehler passieren aus verschiedenen GrĂŒnden, und der Objektspeicher muss sie alle verarbeiten können.
Beispielsweise gibt es einen einzigen Ausfallpunkt, dessen Metrik gleich null ist.
Leider verwenden viele Objektspeichersysteme spezielle Knoten, die aktiviert werden mĂŒssen, damit der Cluster richtig funktioniert. Dazu gehören Namensserver oder Metadaten-Server â das schafft einen einzigen Ausfallpunkt.
Selbst dort, wo mehrere Ausfallpunkte vorgesehen sind, ist die FĂ€higkeit, katastrophale AusfĂ€lle zu verkraften, von entscheidender Bedeutung. Festplatten fallen aus, Server fallen aus. Der SchlĂŒssel ist die Entwicklung von Software, die darauf ausgelegt ist, AusfĂ€lle als normalen Zustand zu behandeln. Bei einem Ausfall einer Festplatte oder eines Knotens wird diese Software weiterhin ohne Ănderungen funktionieren.
Der eingebaute Schutz gegen Datenverlust und -degradation garantiert: 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 wiederherstellen.
Ein Ausfall wird selten unter Last ĂŒberprĂŒft, aber eine solche ĂberprĂŒfung ist obligatorisch. Das Simulieren eines Ausfalls unter Last zeigt die kumulierten Kosten, die nach einem Ausfall entstehen.
Konsistenz
Ein Konsistenzindikator von 100 % wird auch als strikte Konsistenz bezeichnet. Konsistenz ist ein wesentlicher Bestandteil jedes Speichersystems, aber strikte Konsistenz kommt ziemlich selten vor. Zum Beispiel ist Amazon S3 ListObject nicht strikt konsistent, sondern nur am Ende konsistent.
Was bedeutet strikte Konsistenz? FĂŒr alle Operationen nach einer bestĂ€tigten PUT-Operation gilt Folgendes:
- Der aktualisierte Wert ist beim Lesen von jedem Knoten sichtbar.
- Das Update ist durch Ausfallschutz des Knotens gesichert.
Das bedeutet: Wenn der Stecker mitten im Schreiben gezogen wird, geht nichts verloren. Das System gibt niemals beschĂ€digte oder veraltete Daten zurĂŒck. Das ist eine hohe Messlatte, die fĂŒr viele Szenarien von Bedeutung ist: von Transaktionsanwendungen bis hin zu Backup und Wiederherstellung.
Fazit
Das sind neue Metriken fĂŒr Object Storage, die die Nutzungsmuster in modernen Organisationen widerspiegeln, in denen Leistung, Konsistenz, Skalierbarkeit, Ausfallbereiche und S3-KompatibilitĂ€t die Bausteine fĂŒr Cloud-Anwendungen und Big Data-Analysen sind. Ich empfehle, diese Liste zusĂ€tzlich zu den Preisen bei der Erstellung moderner Daten-Stacks zu verwenden.Â
Ăber das Object Storage von Mail.ru Cloud Solutions: .
Was Sie sonst noch lesen sollten:
- .
- .
- .Â
Quelle: habr.com
