Update!. In den Kommentaren hat einer der Leser vorgeschlagen, es mit zu versuchen (möglicherweise arbeitet er selbst daran), also habe ich einen Abschnitt über diese Lösung hinzugefügt. Außerdem habe ich , da der Prozess sich erheblich von den anderen unterscheidet.
Um ehrlich zu sein, habe ich aufgegeben und mich von (zumindest vorerst) distanziert. Ich werde nutzen. Warum? Wegen des Speichers! Wer hätte gedacht, dass ich mich mehr mit Speicherlösungen beschäftigen würde als mit Kubernetes selbst. Ich benutze , weil es günstig ist und die Leistung gut ist. Von Anfang an habe ich Cluster mit Hilfe von bereitgestellt. Ich habe die verwalteten Kubernetes-Dienste von Google/Amazon/Microsoft/DigitalOcean usw. nicht ausprobiert, weil ich alles selbst lernen wollte. Außerdem bin ich sparsam.
Ja, ich habe viel Zeit damit verbracht, herauszufinden, welches Speichersystem ich wählen soll, während ich die mögliche Stack-Konfiguration für Kubernetes geprüft habe. Ich bevorzuge Open-Source-Lösungen, und nicht nur wegen des Preises. Aus Neugier habe ich auch einige kostenpflichtige Optionen betrachtet, da viele von ihnen kostenlose Versionen mit Einschränkungen bieten. Ich habe einige Zahlen aus den letzten Tests notiert, als ich verschiedene Optionen verglichen habe, die für diejenigen interessant sein könnten, die sich mit Speicher in Kubernetes beschäftigen. Persönlich habe ich jedoch Kubernetes vorerst hinter mir gelassen. Ich möchte auch erwähnen , mit dem man direkt Volumen im Hetzner Cloud vorbereiten kann, den ich bisher noch nicht ausprobiert habe. Ich habe cloudbasierte softwaredefinierte Speicherlösungen untersucht, da ich Replikation und die Möglichkeit benötigte, permanente Volumen schnell an jedem Node anzuschließen, insbesondere im Falle von Node-Ausfällen und ähnlichen Situationen. Einige Lösungen bieten Snapshots zu einem bestimmten Zeitpunkt und Offsite-Backups an, was sehr praktisch ist.
Ich habe 6–7 Speichersysteme getestet:
Wie ich bereits gesagt habe , nachdem ich die meisten Optionen aus der Liste getestet habe, habe ich mich zunächst für OpenEBS entschieden. OpenEBS lässt sich sehr einfach installieren und nutzen, aber ehrlich gesagt war ich nach den Tests mit echten Daten unter Last von seiner Leistung enttäuscht. Es handelt sich um Open Source, und die Entwickler in ihrem haben immer sehr geholfen, wenn ich Unterstützung brauchte. Leider hat es eine sehr niedrige Leistung im Vergleich zu anderen Optionen, weshalb ich die Tests erneut durchführen musste. Momentan hat OpenEBS 3 Speicher-Engines, aber ich veröffentliche die Benchmark-Ergebnisse für cStor. Ich habe noch keine Zahlen für Jiva und LocalPV.
Kurz gesagt, Jiva ist etwas schneller, während LocalPV wirklich schnell ist, nicht schlechter als eine direkte Festplattenbenchmark. Das Problem mit LocalPV ist, dass der Zugriff nur von dem Knoten möglich ist, auf dem es vorbereitet wurde, und es gibt keine Replikation. Ich hatte einige Probleme beim Wiederherstellen eines Backups mit in einem neuen Cluster, weil die Knotennamen unterschiedlich waren. Wenn es um Backups geht, hat cStor einen , mit dem man Offsite-Backups der Snapshots zu einem bestimmten Zeitpunkt erstellen kann, was bequemer ist als Datei-basierte Backups mit Velero-Restic. Ich habe geschrieben , um die Verwaltung von Backups und Wiederherstellungen mit diesem Plugin zu erleichtern. Insgesamt gefällt mir OpenEBS sehr gut, aber die Leistung...
Rook hat ebenfalls Open Source und unterscheidet sich von den anderen Optionen in der Liste, da es ein Speichermanager ist, der komplexe Speicherverwaltungsaufgaben mit verschiedenen Backends ausführt, wie zum Beispiel , und andere, was die Arbeit erheblich vereinfacht. Ich hatte vor einigen Monaten Probleme mit EdgeFS, daher habe ich hauptsächlich mit Ceph getestet. Ceph bietet nicht nur Blockspeicher, sondern auch ein objektspeicher-kompatibles System mit S3/Swift und ein verteiltes Dateisystem. Was mir an Ceph gefällt, ist die Möglichkeit, die Daten eines Volumes über mehrere Festplatten zu verteilen, sodass das Volume mehr Speicherplatz verwenden kann, als auf einer Festplatte verfügbar ist. Das ist praktisch. Eine weitere coole Funktion ist, dass beim Hinzufügen von Festplatten zum Cluster die Daten automatisch auf alle Festplatten verteilt werden.
Ceph verfügt über Snapshots, aber meines Wissens können diese nicht direkt in Rook/Kubernetes verwendet werden. Das habe ich jedoch nicht näher untersucht. Off-Site-Backups fehlen, daher muss man auf Lösungen wie Velero/Restic zurückgreifen, die jedoch nur Datei-Backups und keine zeitgebundenen Snapshots ermöglichen. Positiv fand ich jedoch die einfache Handhabung von Ceph in Rook – es verbirgt nahezu alle komplexen Aspekte und bietet Werkzeuge, um direkt mit Ceph zu kommunizieren und Fehler zu beheben. Leider hatte ich während des Stresstests der Ceph-Volumes ständig , das Ceph instabil macht. Es ist noch unklar, ob dies ein Bug in Ceph selbst oder ein Problem damit ist, wie Rook Ceph verwaltet. Ich habe mit den Speichereinstellungen experimentiert und es wurde besser, aber das Problem ist nicht vollständig gelöst. Ceph bietet eine gute Leistung, wie die Benchmarks weiter unten zeigen. Zudem hat es ein ausgezeichnetes Dashboard zur Überwachung.
Ich bin ein großer Fan von Longhorn. Meiner Meinung nach ist es eine vielversprechende Lösung. Allerdings geben die Entwickler (Rancher Labs) zu, dass es für den produktiven Einsatz noch ungeeignet ist, was auch offensichtlich ist. Es hat einen Open-Source-Code und eine annehmbare Leistung (obwohl die Optimierung noch nicht stattgefunden hat), jedoch verbinden sich die Volumes sehr langsam mit dem Pod, und in den schlimmsten Fällen kann das 15–16 Minuten dauern, insbesondere nach der Wiederherstellung eines großen Backups oder einem Upgrade der Arbeitslast. Es verfügt über Snapshots und Offsite-Backups dieser Snapshots, aber diese beziehen sich nur auf Volumes, weshalb Sie trotzdem etwas wie Velero für die Sicherung der anderen Ressourcen benötigen müssen. Backups und Wiederherstellungen sind sehr zuverlässig, aber unangemessen langsam. Ernsthaft, einfach extrem langsam. Die Nutzung der CPU-Ressourcen und die Systemlast steigen oft an, wenn man mit einem mittleren Datenvolumen in Longhorn arbeitet. Es gibt ein praktisches Dashboard, um Longhorn zu verwalten. Ich habe bereits erwähnt, dass ich Longhorn mag, aber es bedarf definitiv noch weiterer Arbeit.
StorageOS ist das erste kostenpflichtige Produkt in der Liste. Es gibt eine Entwicklerversion mit einer begrenzten Größe des verwalteten Speichers von 500 GB, aber die Anzahl der Knoten ist meines Wissens unbegrenzt. Im Vertrieb wurde mir gesagt, dass die Kosten bei 125 $ pro Monat für 1 TB beginnen, wenn ich mich richtig erinnere. Es gibt ein grundlegendes Überwachungsdashboard und eine benutzerfreundliche CLI, aber die Leistung ist etwas seltsam: In einigen Benchmarks ist sie durchaus anständig, aber im Stresstest der Volumes hat mir die Geschwindigkeit überhaupt nicht gefallen. Insgesamt weiß ich nicht, was ich sagen soll. Deshalb habe ich mich nicht weiter eingearbeitet. Es gibt keine Offsite-Backups, und man muss auch Velero mit Restic für die Sicherung der Volumes verwenden. Seltsam, da das Produkt kostenpflichtig ist. Außerdem hatten die Entwickler nicht wirklich Lust, in Slack zu kommunizieren.
Ich habe von Robin auf Reddit durch ihren technischen Direktor erfahren. Zuvor hatte ich noch nie von ihnen gehört. Vielleicht, weil ich nach kostenlosen Lösungen gesucht habe, während Robin kostenpflichtig ist. Sie bieten jedoch eine recht großzügige kostenlose Version mit einem Speicher von 10 TB und drei Knoten. Insgesamt ist das Produkt durchaus anständig und bietet nützliche Funktionen. Es gibt eine großartige CLI, aber das Beste ist, dass man Snapshots und Backups der gesamten Anwendung erstellen kann (im Ressourcenmanager werden diese als Helm-Releases oder "flex apps" bezeichnet), einschließlich Volumen und anderen Ressourcen, sodass man ohne Velero auskommt. Alles wäre wunderbar, wenn da nicht ein kleines Detail wäre: Wenn man die Anwendung auf einem neuen Cluster wiederherstellt (oder "importiert", wie es bei Robin genannt wird) – zum Beispiel im Falle einer Notfallwiederherstellung – funktioniert die Wiederherstellung zwar, aber das Backup der Anwendung kann nicht fortgesetzt werden. In dieser Version ist das einfach nicht möglich, und die Entwickler haben dies bestätigt. Das ist milde ausgedrückt seltsam, besonders angesichts der anderen Vorteile (wie unglaublich schnelle Backups und Wiederherstellungen). Die Entwickler versprechen, alles im nächsten Release zu beheben. Die Leistung ist insgesamt gut, aber ich habe eine Eigenart bemerkt: Wenn man einen Benchmark direkt auf dem Volumen ausführt, das mit dem Host verbunden ist, ist die Lesegeschwindigkeit viel höher als beim gleichen Volumen, aber innerhalb des Pods. Alle anderen Ergebnisse sind identisch, aber theoretisch sollte es keinen Unterschied geben. Auch wenn sie daran arbeiten, war ich wegen des Problems mit der Wiederherstellung und dem Backup enttäuscht – ich hatte das Gefühl, dass ich endlich eine passende Lösung gefunden hatte, und ich war bereit, dafür zu bezahlen, wenn ich mehr Speicherplatz oder mehr Server benötige.
Ich habe nicht viel dazu zu sagen. Es ist ein kostenpflichtiges Produkt, das sowohl großartig als auch teuer ist. Die Leistung ist einfach beeindruckend. Bis jetzt ist es der beste Wert. Mir wurde im Slack gesagt, dass der Preis bei $205 pro Monat und Knoten beginnt, wie im Google GKE Marketplace angegeben. Ich weiß nicht, ob es günstiger wird, wenn man direkt kauft. In jedem Fall kann ich mir das nicht leisten, also war ich sehr enttäuscht, dass die Entwicklerlizenz (bis zu 1 TB und 3 Knoten) praktisch nutzlos mit Kubernetes ist, es sei denn, man begnügt sich mit einer statischen Bereitstellung. Ich hatte gehofft, dass die Unternehmenslizenz am Ende der Testphase automatisch auf die Entwicklerstufe herabgestuft wird, aber das ist nicht passiert. Die Entwicklerlizenz kann nur direkt mit Docker verwendet werden, und die Einrichtung in Kubernetes ist sehr umständlich und eingeschränkt. Ich bevorzuge natürlich Open Source, aber hätte ich das Geld, würde ich definitiv Portworx wählen. Bis jetzt ist die Leistung einfach unübertroffen im Vergleich zu anderen Optionen.
Ich habe diesen Abschnitt bereits nach der Veröffentlichung des Beitrags hinzugefügt, als ein Leser vorgeschlagen hat, Linstor auszuprobieren. Ich habe es getestet und mir gefällt es! Allerdings gibt es noch einiges zu erkunden. Momentan kann ich sagen, dass die Leistung solide ist (Benchmark-Ergebnisse finden Sie weiter unten). Im Grunde habe ich die gleiche Leistung erhalten, die ich auch direkt vom Laufwerk bekomme, ganz ohne Verluste. (Fragen Sie nicht, warum Portworx bessere Zahlen als der direkte Benchmark des Laufwerks hat. Ich habe keine Ahnung. Magie vielleicht.) Linstor scheint also bisher sehr effizient zu sein. Die Installation ist nicht kompliziert, aber auch nicht so einfach wie bei anderen Optionen. Zuerst musste ich Linstor (Kernel-Modul und Werkzeuge/Dienste) installieren und LVM für Thin Provisioning und Snapshots außerhalb von Kubernetes am Host einrichten, dann die Ressourcen erstellen, die erforderlich sind, um den Storage aus Kubernetes zu nutzen. Es hat mich gestört, dass es nicht auf CentOS funktioniert hat und ich Ubuntu verwenden musste. Es ist natürlich nicht schlimm, aber ein wenig ärgerlich, da in der hervorragenden Dokumentation mehrere Pakete erwähnt werden, die in den angegebenen Epel-Repositories nicht zu finden sind. Linstor bietet Snapshots, jedoch keine Offsite-Backups, sodass ich hier erneut Velero mit Restic für das Backup von Volumes verwenden musste. Ich würde Snapshots anstelle von Datei-level-Backups bevorzugen, aber das ist erträglich, sofern die Lösung leistungsfähig und zuverlässig ist. Linstor ist Open Source, bietet aber kostenpflichtigen Support. Soweit ich weiß, kann es ohne Einschränkungen genutzt werden, selbst wenn Sie keinen Supportvertrag haben, aber das muss noch geklärt werden. Ich weiß nicht, wie gut Linstor für Kubernetes getestet ist, aber die Speicher-Implementierung liegt außerhalb von Kubernetes und scheint nicht neu zu sein, also ist es wahrscheinlich, dass es bereits in der Praxis erprobt wurde. Gibt es hier eine Lösung, die mich dazu bringt, meine Meinung zu ändern und zu Kubernetes zurückzukehren? Ich weiß nicht, ich weiß nicht. Ich muss noch weiter forschen und die Replikation untersuchen. Wir werden sehen. Aber der erste Eindruck ist gut. Ich würde auf jeden Fall lieber eigene Kubernetes-Cluster statt Heroku verwenden, um mehr Freiheit zu gewinnen und Neues zu lernen. Da die Installation von Linstor nicht so einfach ist wie bei anderen, werde ich bald einen Beitrag darüber schreiben.
Benchmarks
Leider habe ich nur wenige Vergleichsaufzeichnungen gespeichert, da ich nicht dachte, dass ich darüber schreiben würde. Ich habe nur die Ergebnisse grundlegender fio-Benchmarks und nur für Cluster mit einem Knoten, sodass ich bisher keine Zahlen für replizierte Konfigurationen habe. Aber anhand dieser Ergebnisse kann man eine ungefähre Vorstellung davon bekommen, was man von jeder Option erwarten kann, denn ich habe sie auf identischen Cloud-Servern verglichen: 4 Kerne, 16 GB RAM, mit einer zusätzlichen Festplatte von 100 GB für die getesteten Volumes. Ich habe die Benchmarks dreimal für jede Lösung durchgeführt und den Durchschnitt berechnet, außerdem habe ich die Servereinstellungen für jedes Produkt zurückgesetzt. All dies ist absolut unwissenschaftlich, nur damit Sie einen allgemeinen Überblick bekommen. In anderen Tests habe ich 38 GB Fotos und Videos von und zu dem Volume kopiert, um Lesen und Schreiben zu testen, aber leider habe ich die Zahlen nicht gespeichert. Kurz gesagt: Portworx war deutlich schneller.
Für den Benchmark der Volumes habe ich dieses Manifest verwendet:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Zuerst habe ich ein Volume mit der entsprechenden Speicherklasse erstellt und dann im Hintergrund einen Job mit fio gestartet. Ich habe 1 GB genommen, um eine Einschätzung der Leistung zu bekommen, ohne zu lange warten zu müssen. Hier sind die Ergebnisse:
Ich habe den besten Wert für jede Metrik grün und den schlechtesten rot hervorgehoben.
Fazit
Wie Sie sehen können, hat sich Portworx in den meisten Fällen besser behauptet als andere. Aber für mich ist es zu teuer. Ich weiß nicht, wie viel Robin kostet, aber es gibt eine großartige kostenlose Version, also können Sie sie ausprobieren, wenn Sie ein kostenpflichtiges Produkt benötigen (ich hoffe, sie beheben bald das Problem mit der Wiederherstellung und den Backups). Von den drei kostenlosen Lösungen hatte ich mit OpenEBS die wenigsten Probleme, aber die Leistung ist nicht gerade überwältigend. Schade, dass ich nicht mehr Ergebnisse gespeichert habe, aber ich hoffe, die angegebenen Zahlen und meine Kommentare helfen Ihnen weiter.
Quelle: habr.com
