Aktualisierung!. In den Kommentaren hat ein Leser vorgeschlagen, es mit zu versuchen (vielleicht arbeitet er selbst daran), also habe ich einen Abschnitt über diese Lösung hinzugefügt. Ich habe auch einen , weil der Prozess sich stark von den anderen unterscheidet.
Um ehrlich zu sein, habe ich aufgegeben und mich entschieden, auf zu verzichten (zumindest vorerst). Ich werde benutzen. 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, und von Anfang an habe ich Cluster mit Hilfe von bereitgestellt. Ich habe die verwalteten Kubernetes-Dienste von Google/Amazon/Microsoft/DigitalOcean und ähnlichen nicht ausprobiert, weil ich alles selbst lernen wollte. Außerdem bin ich sparsam.
Also ja, ich habe viel Zeit damit verbracht, zu entscheiden, welches Speicherangebot ich wählen soll, als ich die möglichen Stacks für Kubernetes durchdachte. Ich bevorzuge Open-Source-Lösungen, und das nicht nur wegen des Preises, sondern ich habe ein paar kostenpflichtige Optionen aus Neugierde untersucht, weil sie kostenlose Versionen mit Einschränkungen haben. Ich habe ein paar Zahlen aus den letzten Tests notiert, als ich verschiedene Optionen verglichen habe, und die könnten für diejenigen von Interesse sein, die sich mit Speicher in Kubernetes beschäftigen. Obwohl ich persönlich momentan mit Kubernetes aufgehört habe. Ich möchte auch erwähnen, mit dem man direkt Volumes für Hetzner Cloud vorbereiten kann, aber ich habe ihn noch nicht ausprobiert. Ich habe cloudbasierte softwaredefinierte Speicherlösungen untersucht, weil ich Replikation und die Möglichkeit benötigte, persistent Volumes schnell an jedem Knoten zu verbinden, insbesondere im Falle von Knotenausfällen und ähnlichen Situationen. Einige Lösungen bieten zeitbasierte Snapshots und Off-Site-Backups an, was praktisch ist.
Ich habe 6–7 Speicherlösungen getestet:
Wie ich bereits gesagt habe, , stoppte ich nach dem Testen der meisten Optionen auf der Liste zunächst bei OpenEBS. OpenEBS lässt sich sehr einfach installieren und nutzen, aber um ehrlich zu sein, enttäuschte mich die Leistung nach Tests mit echten Daten unter Last. Es ist Open Source, und die Entwickler auf ihrem Sie haben immer sehr geholfen, wenn ich Unterstützung brauchte. Leider hat er eine sehr niedrige Leistung im Vergleich zu anderen Optionen, daher musste ich die Tests neu durchführen. Momentan hat OpenEBS 3 Speichermotoren, aber ich veröffentliche die Benchmark-Ergebnisse für cStor. Bisher habe ich keine Zahlen für Jiva und LocalPV.
Kurz gesagt, Jiva ist etwas schneller, während LocalPV insgesamt schnell ist, nicht schlechter als der Benchmark für direktes Disk-Access. Das Problem mit LocalPV ist, dass der Zugriff nur auf dem Knoten möglich ist, auf dem es vorbereitet wurde, und es gibt überhaupt keine Replikation. Ich hatte einige Probleme mit der Wiederherstellung des Backups über auf einem neuen Cluster, da die Knotennamen unterschiedlich waren. Wenn es um Backups geht, hat cStor einen , mit dem man Off-Site-Backups von Snapshots zu einem bestimmten Zeitpunkt machen kann, was bequemer ist als Datei-Backups mit Velero-Restic. Ich habe , um das Management von Backups und Wiederherstellungen mit diesem Plugin zu erleichtern. Insgesamt gefällt mir OpenEBS sehr gut, aber seine Leistung…
Rook hat auch Open Source und unterscheidet sich von den anderen Optionen in der Liste dadurch, dass es ein Speicherkordinator ist, der komplexe Aufgaben im Speichermanagement mit verschiedenen Backends ausführt, wie zum Beispiel , und andere, was die Arbeit erheblich erleichtert. Ich hatte vor einigen Monaten Probleme mit EdgeFS, also habe ich hauptsächlich mit Ceph getestet. Ceph bietet nicht nur Blockstorage, sondern auch ein objektorientiertes Speichersystem, das mit S3/Swift und einem verteilten Dateisystem kompatibel ist. Was ich an Ceph mag, ist die Möglichkeit, die Daten eines Volumes über mehrere Festplatten zu verteilen, damit das Volume mehr Speicherplatz nutzen kann, als auf einer einzelnen Festplatte möglich ist. Das ist praktisch. Eine weitere coole Funktion ist, dass beim Hinzufügen von Festplatten zum Cluster die Daten automatisch auf alle Festplatten neu verteilt werden.
Ceph verfügt über Snapshots, aber soweit ich weiß, können diese nicht direkt in Rook/Kubernetes verwendet werden. Allerdings habe ich mich nicht ausführlich damit beschäftigt. Offsite-Backups gibt es nicht, sodass ich etwas mit Velero/Restic verwenden muss, aber dort gibt es nur Backups auf Dateiebene und keine zeitlich festgelegten Snapshots. Allerdings hat mir die einfache Arbeit mit Ceph in Rook sehr gefallen – es verbirgt fast alle komplexen Dinge und bietet Tools, um direkt mit Ceph zur Problemlösung zu kommunizieren. Leider hatte ich bei dem Stresstest der Ceph-Volumes ständig , wodurch Ceph instabil wird. Derzeit ist unklar, ob es sich um einen Fehler in Ceph selbst handelt oder ob das Problem darin besteht, wie Rook Ceph verwaltet. Ich habe an den Speichereinstellungen etwas herumgebastelt, und es wurde besser, aber das Problem ist nicht vollständig gelöst. Ceph bietet eine gute Leistung, wie in den Benchmarks unten zu sehen ist. Außerdem hat es ein gutes Überwachungsdashboard.
Ich mag Longhorn sehr. Meiner Meinung nach ist es eine vielversprechende Lösung. Die Entwickler selbst (Rancher Labs) geben jedoch zu, dass es für eine Produktionsumgebung derzeit nicht geeignet ist, und das ist offensichtlich. Es hat einen offenen Quellcode und eine anständige Leistung (obwohl sie sich noch nicht um die Optimierung gekümmert haben), aber die Volumes verbinden sich sehr langsam mit dem Pod, und im schlimmsten Fall dauert dies 15-16 Minuten, insbesondere nach der Wiederherstellung eines großen Backups oder einem Upgrade der Arbeitslast. Es gibt Snapshots und Offsite-Backups dieser Snapshots, aber diese gelten nur für Volumes, sodass man dennoch etwas wie Velero für die Sicherung der übrigen Ressourcen benötigt. Die Backups und Wiederherstellungen sind sehr zuverlässig, aber unangemessen langsam. Im Ernst, sie sind einfach extrem langsam. Die Nutzung der CPU-Ressourcen und die Systemlast steigen oft bei der Arbeit mit durchschnittlichen Datenmengen in Longhorn. Es gibt ein praktisches Überwachungsdashboard zur Verwaltung von Longhorn. Ich habe schon gesagt, dass ich Longhorn mag, aber es muss noch gründlich bearbeitet werden.
StorageOS ist das erste kostenpflichtige Produkt auf der Liste. Es gibt eine Entwicklerversion mit einer begrenzten verwalteten Speicherkapazität von 500 GB, aber die Anzahl der Nodes scheint unbegrenzt zu sein. 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 Dashboard und eine benutzerfreundliche CLI, aber die Leistung scheint merkwürdig zu sein: In einigen Benchmarks ist sie recht ordentlich, aber im Stresstest der Volumes gefiel mir die Geschwindigkeit überhaupt nicht. Insgesamt weiß ich nicht, was ich sagen soll. Daher habe ich mich nicht besonders damit beschäftigt. Es gibt keine Offsite-Backups, und ich werde Velero mit Restic für die Sicherung der Volumes verwenden müssen. Seltsam, denn das Produkt ist kostenpflichtig. Und außerdem waren die Entwickler nicht sehr daran interessiert, in Slack zu kommunizieren.
Ich habe von Robin über Reddit von ihrem technischen Direktor erfahren. Davor hatte ich noch nie von ihm gehört. Vielleicht, weil ich kostenlose Lösungen gesucht habe, während Robin kostenpflichtig ist. Sie haben eine recht großzügige kostenlose Version mit einem Speicher von 10 TB und drei Knoten. Insgesamt ist das Produkt durchaus ansehnlich und bietet angenehme Funktionen. Es gibt ein hervorragendes CLI, aber das Beste ist, dass man Snapshots und Backups der gesamten Anwendung erstellen kann (im Ressourcen-Selector werden diese als Helm-Releases oder "flex apps" bezeichnet), einschließlich Volumes und anderer Ressourcen, sodass man ohne Velero auskommen kann. Und alles wäre wunderbar, wenn da nicht eine kleine Detail wäre: Wenn man eine Anwendung auf einem neuen Cluster wiederherstellt (oder „importiert“, wie es bei Robin genannt wird) – zum Beispiel im Fall einer Wiederherstellung nach einem Ausfall – funktioniert die Wiederherstellung natürlich, aber das Backup der Anwendung kann nicht fortgesetzt werden. In dieser Version ist das einfach unmöglich, und die Entwickler haben dies bestätigt. Das ist, gelinde gesagt, seltsam, insbesondere im Hinblick auf die anderen Vorteile (zum Beispiel unglaublich schnelle Backups und Wiederherstellungen). Die Entwickler versprechen, alles bis zur nächsten Version zu beheben. Die Leistung ist insgesamt gut, aber ich habe eine Eigenheit bemerkt: Wenn man einen Benchmark direkt auf dem Volume, das mit dem Host verbunden ist, ausführt, ist die Lesegeschwindigkeit viel höher als auf demselben Volume, aber aus dem Inneren des Pods. Alle anderen Ergebnisse sind identisch, aber theoretisch sollte es keinen Unterschied geben. Auch wenn sie daran arbeiten, war ich enttäuscht über das Problem mit der Wiederherstellung und dem Backup – ich hatte das Gefühl, dass ich endlich die passende Lösung gefunden hatte, und ich war sogar bereit, dafür zu zahlen, wenn ich mehr Speicherplatz oder mehr Server benötige.
Ich habe hier nicht viel zu sagen. Es ist ein kostenpflichtiges Produkt, das sowohl klasse als auch teuer ist. Die Leistung ist einfach ein Wunder. Bis jetzt ist das die beste Kennzahl. In Slack wurde mir gesagt, dass der Preis bei $205 pro Monat und Node beginnt, wie im Google GKE Marketplace angegeben. Ich weiß nicht, ob es günstiger wird, wenn man direkt kauft. Auf jeden Fall kann ich mir das nicht leisten, also war ich sehr und sehr enttäuscht, dass die Entwicklerversion (bis zu 1 TB und 3 Nodes) praktisch nutzlos mit Kubernetes ist, es sei denn, man begnügt sich mit statischem Setup. Ich hatte gehofft, dass die Unternehmenslizenz am Ende der Testphase automatisch auf die Entwicklerversion herabgestuft wird, aber das ist nicht passiert. Die Entwicklerversion 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 mich definitiv für Portworx entscheiden. Bisher kann seine Leistung einfach nicht mit anderen Optionen verglichen werden.
Ich habe diesen Abschnitt bereits nach der Veröffentlichung des Beitrags hinzugefügt, als ein Leser vorschlug, Linstor auszuprobieren. Ich habe es getestet und mir gefällt es! Aber ich muss noch weiter forschen. Jetzt kann ich sagen, dass die Leistung ganz ordentlich ist (Benchmark-Ergebnisse habe ich weiter unten hinzugefügt). Im Grunde genommen habe ich die gleiche Leistung erzielt wie bei einer direkten Verbindung zum Datenträger, und das ganz ohne zusätzliche Kosten. (Fragt nicht, warum die Zahlen bei Portworx besser sind als der Benchmark des Datenträgers direkt. Keine Ahnung. Wahrscheinlich Magie.) Somit scheint Linstor bisher sehr effizient zu sein. Es ist nicht so schwierig, es zu installieren, aber auch nicht so einfach wie die anderen Optionen. Zuerst musste ich Linstor installieren (Kernel-Modul sowie Werkzeuge/Dienste) und LVM für Thin Provisioning und Snapshot-Unterstützung außerhalb von Kubernetes direkt auf dem Host einrichten, danach musste ich die Ressourcen erstellen, die benötigt werden, um Speicher aus Kubernetes zu nutzen. Es hat mich gestört, dass es nicht auf CentOS funktionierte und ich Ubuntu verwenden musste. Ist nicht schlimm, natürlich, aber es ist ein bisschen lästig, weil in der Dokumentation (die übrigens ausgezeichnet ist) einige Pakete erwähnt werden, die in den angegebenen Epel-Repositories nicht zu finden sind. In Linstor gibt es Snapshots, aber keine Off-Site-Backups, schon wieder musste ich Velero mit Restic für die Backup von Volumes verwenden. Ich würde Snapshots anstelle von Backups auf Dateiebene bevorzugen, aber das ist verkraftbar, wenn die Lösung leistungsfähig und zuverlässig ist. Linstor ist Open Source, bietet aber kostenpflichtigen Support an. Wenn ich richtig verstehe, kann man es ohne Einschränkungen nutzen, auch wenn man keinen Supportvertrag hat, aber das müsste ich noch klären. Ich weiß nicht, wie gut Linstor für Kubernetes getestet ist, aber das Speichersystem selbst liegt außerhalb von Kubernetes und anscheinend gibt es die Lösung nicht erst seit gestern, also wurde sie wahrscheinlich bereits in der Praxis erprobt. Gibt es hier eine Lösung, die mich umdenken lässt und mich zurück zu Kubernetes bringt? Ich weiß es nicht, ich weiß es nicht. Ich muss noch weiter stöbern und die Replikation studieren. Mal sehen. Aber der erste Eindruck ist gut. Ich würde definitiv lieber meine eigenen Kubernetes-Cluster statt Heroku verwenden, um mehr Freiheit zu haben und Neues zu lernen. Da Linstor nicht so einfach zu installieren ist wie die anderen, werde ich bald einen Beitrag darüber schreiben.
Benchmarks
Leider habe ich nur wenige Aufzeichnungen über die Vergleiche gespeichert, da ich nicht daran gedacht habe, dass ich darüber schreiben würde. Ich habe nur die Ergebnisse der grundlegenden Benchmarks von fio und nur für Cluster mit einem Knoten, sodass ich noch keine Zahlen für replizierte Konfigurationen habe. Aber aus diesen Ergebnissen kann man eine ungefähre Vorstellung davon bekommen, was man von jeder Variante erwarten kann, da ich sie auf denselben Cloud-Servern verglichen habe, 4 Kerne, 16 GB RAM, mit einer zusätzlichen 100-GB-Festplatte für die getesteten Volumes. Ich habe die Benchmarks dreimal für jede Lösung durchlaufen und den Durchschnitt berechnet, außerdem habe ich die Servereinstellungen für jedes Produkt zurückgesetzt. Das Ganze ist absolut unwissenschaftlich, einfach damit ihr eine grobe Vorstellung bekommt. In anderen Tests habe ich 38 GB Fotos und Videos vom Volume kopiert und darauf, um die Lese- und Schreibgeschwindigkeit 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 anschließend das Job mit fio im Hintergrund gestartet. Ich nahm 1 GB, um die Leistung abzuschätzen und nicht zu lange zu warten. Hier sind die Ergebnisse:
Ich habe die besten Werte für jeden Parameter grün und die schlechtesten rot markiert.
Fazit
Wie Sie sehen, hat sich Portworx in den meisten Fällen besser geschlagen als die anderen. Aber für mich ist es teuer. Ich weiß nicht, was Robin kostet, aber dort gibt es eine großartige kostenlose Version, sodass Sie, wenn Sie ein kostenpflichtiges Produkt brauchen, es ausprobieren können (ich hoffe, sie beheben bald das Problem mit der Wiederherstellung und Backups). Von den drei kostenlosen hatte ich am wenigsten Probleme mit OpenEBS, aber die Leistung ist miserabel. Schade, dass ich nicht mehr Ergebnisse gespeichert habe, aber ich hoffe, die genannten Zahlen und meine Kommentare helfen Ihnen weiter.
Quelle: habr.com
