Aktualisieren!. In den Kommentaren schlug einer der Leser vor, es zu versuchen (Vielleicht arbeitet er selbst daran), deshalb habe ich einen Abschnitt über diese Lösung hinzugefügt. Ich habe auch geschrieben denn der Prozess ist ganz anders als der Rest.
Ehrlich gesagt habe ich aufgegeben und aufgegeben (Zumindest für jetzt). ich werde benützen . Warum? Wegen der Lagerung! Wer hätte gedacht, dass ich mich mehr mit dem Speicher herumschlagen würde als mit Kubernetes selbst? Ich verwende , weil es kostengünstig ist und eine gute Leistung bietet, und ich habe von Anfang an Cluster damit bereitgestellt . Ich habe verwaltete Kubernetes-Dienste von Google/Amazon/Microsoft/DigitalOcean usw. usw. noch nicht ausprobiert, weil ich alles selbst lernen wollte. Ich bin auch sparsam.
Also – ja, ich habe viel Zeit damit verbracht, mich für einen Speicher zu entscheiden, als ich über einen möglichen Stack auf Kubernetes nachdachte. Ich bevorzuge Open-Source-Lösungen, und das nicht nur wegen des Preises, sondern ich habe mir auch aus Neugier ein paar kostenpflichtige Optionen angesehen, weil es dort kostenlose Versionen mit Einschränkungen gibt. Als ich verschiedene Optionen verglichen habe, habe ich mir ein paar Zahlen aus aktuellen Benchmarks notiert, die für diejenigen von Interesse sein könnten, die sich mit Speicher in Kubernetes befassen. Obwohl ich mich persönlich bisher von Kubernetes verabschiedet habe. Ich möchte auch erwähnen , in dem man Hetzner Cloud-Volumes direkt bereitstellen kann, habe ich aber noch nicht ausprobiert. Ich habe mich mit Cloud-Software-Defined-Storage beschäftigt, weil ich Replikation und die Möglichkeit benötigte, persistente Volumes schnell auf jedem Knoten bereitzustellen, insbesondere bei Knotenausfällen und ähnlichen Situationen. Einige Lösungen bieten Point-in-Time-Snapshots und Off-Site-Backups, was praktisch ist.
Ich habe 6-7 Speicherlösungen getestet:
Wie ich schon sagte Nachdem ich die meisten Optionen aus der Liste getestet hatte, entschied ich mich zunächst für OpenEBS. OpenEBS ist sehr einfach zu installieren und zu verwenden, aber ehrlich gesagt hat mich die Leistung nach Tests mit realen Daten unter Last enttäuscht. Dies ist Open Source und die Entwickler sind auf sich allein gestellt Immer sehr hilfsbereit, wenn ich Hilfe brauchte. Leider ist die Leistung im Vergleich zu anderen Optionen sehr schlecht, sodass ich die Tests erneut durchführen musste. Derzeit verfügt OpenEBS über drei Speicher-Engines, ich veröffentliche jedoch Benchmark-Ergebnisse für cStor. Ich habe noch keine Zahlen für Jiva und LocalPV.
Kurz gesagt, Jiva ist etwas schneller und LocalPV ist im Allgemeinen schnell, nicht schlechter als der direkte Laufwerksbenchmark. Das Problem bei LocalPV besteht darin, dass auf das Volume nur auf dem Knoten zugegriffen werden kann, auf dem es bereitgestellt wurde, und dass überhaupt keine Replikation stattfindet. Ich hatte einige Probleme mit der Wiederherstellung eines Backups über auf dem neuen Cluster, da die Knotennamen unterschiedlich waren. Apropos Backups: cStor hat es , mit dem Sie externe Point-in-Time-Snapshot-Backups erstellen können, was bequemer ist als Backups auf Dateiebene mit Velero-Restic. Ich habe geschrieben um die Verwaltung von Sicherungen und Wiederherstellungen mit diesem Plugin zu vereinfachen. Insgesamt mag ich OpenEBS wirklich, aber seine Leistung ...
Rook ist ebenfalls Open Source und unterscheidet sich von den übrigen Optionen auf der Liste dadurch, dass es sich um einen Speicher-Orchestrator handelt, der beispielsweise komplexe Speicherverwaltungsaufgaben mit unterschiedlichen Backends ausführt , und andere, was die Arbeit erheblich vereinfacht. Ich hatte Probleme mit EfgeFS, als ich es vor ein paar Monaten ausprobierte, also habe ich es hauptsächlich mit Ceph getestet. Ceph bietet nicht nur Blockspeicher, sondern auch Objektspeicher, der mit S3/Swift und verteilten Dateisystemen kompatibel ist. Was mir an Ceph gefällt, ist die Möglichkeit, Volume-Daten auf mehrere Festplatten zu verteilen, sodass das Volume mehr Speicherplatz beanspruchen kann, als auf eine Festplatte passt. Das ist bequem. Eine weitere coole Funktion ist, dass beim Hinzufügen von Festplatten zum Cluster die Daten automatisch auf alle Festplatten neu verteilt werden.
Ceph hat Snapshots, aber meines Wissens können diese nicht direkt in Rook/Kubernetes verwendet werden. Zugegebenermaßen habe ich mich nicht intensiv damit beschäftigt. Aber es gibt keine Off-Site-Backups, also muss man etwas mit Velero/Restic verwenden, aber es gibt nur Backups auf Dateiebene, keine Point-in-Time-Snapshots. Was mir an Rook jedoch wirklich gefällt, ist die einfache Arbeit mit Ceph – es verbirgt fast alle komplexen Dinge und bietet Tools, mit denen man zur Fehlerbehebung direkt mit Ceph sprechen kann. Leider musste ich beim Stresstest der Ceph-Volumes immer mitmachen , was dazu führt, dass Ceph instabil wird. Es ist noch nicht klar, ob es sich dabei um einen Fehler in Ceph selbst oder um ein Problem bei der Verwaltung von Ceph durch Rook handelt. Ich habe an den Speichereinstellungen herumgefummelt und es wurde besser, aber das Problem wurde nicht vollständig gelöst. Ceph weist eine gute Leistung auf, wie aus den folgenden Benchmarks hervorgeht. Es hat auch ein gutes Dashboard.
Ich mag Longhorn wirklich. Ich denke, das ist eine vielversprechende Lösung. Zwar geben die Entwickler selbst (Rancher Labs) zu, dass es noch nicht für eine Produktionsumgebung geeignet ist, und das zeigt sich. Es ist Open Source und bietet eine anständige Leistung (obwohl es noch nicht optimiert wurde), aber das Anschließen der Volumes an den Pod dauert sehr lange und im schlimmsten Fall dauert es 15 bis 16 Minuten, insbesondere nach der Wiederherstellung eines großen Backups oder Erhöhen einer Arbeitslast. Es verfügt über Snapshots und externe Backups dieser Snapshots, diese gelten jedoch nur für Volumes, sodass Sie immer noch etwas wie Velero benötigen, um die restlichen Ressourcen zu sichern. Sicherungen und Wiederherstellungen sind sehr zuverlässig, aber unangemessen langsam. Im Ernst, einfach unerschwinglich langsam. Bei der Arbeit mit einer durchschnittlichen Datenmenge in Longhorn steigen die CPU-Auslastung und die Systemlast häufig an. Es gibt ein praktisches Dashboard zur Verwaltung von Longhorn. Ich habe bereits gesagt, dass ich Longhorn mag, aber es muss noch richtig bearbeitet werden.
StorageOS ist das erste kostenpflichtige Produkt auf der Liste. Es gibt eine Entwicklerversion mit einer begrenzten verwalteten Speichergröße von 500 GB, aber ich glaube nicht, dass die Anzahl der Knoten begrenzt ist. Die Vertriebsabteilung teilte mir mit, dass die Kosten für 125 TB bei 1 US-Dollar pro Monat beginnen, wenn ich mich recht erinnere. Es gibt ein einfaches Dashboard und eine praktische CLI, aber mit der Leistung passiert etwas Seltsames: In einigen Benchmarks ist sie recht ordentlich, aber im Stresstest der Lautstärken gefiel mir die Geschwindigkeit überhaupt nicht. Im Allgemeinen weiß ich nicht, was ich sagen soll. Also ich habe es nicht wirklich verstanden. Hier gibt es keine Off-Site-Backups und Sie müssen auch Velero mit Restic verwenden, um Volumes zu sichern. Es ist seltsam, weil das Produkt bezahlt wird. Und die Entwickler hatten keine Lust, in Slack zu kommunizieren.
Ich habe von ihrem CTO auf Reddit von Robin erfahren. Ich hatte noch nie von ihm gehört. Vielleicht, weil ich nach kostenlosen Lösungen gesucht habe und Robin bezahlt wird. Sie haben eine ziemlich großzügige kostenlose Version mit 10 TB Speicher und drei Knoten. Im Allgemeinen ist das Produkt recht ordentlich und verfügt über nette Funktionen. Es gibt eine tolle CLI, aber das Coolste ist, dass Sie einen Snapshot und ein Backup der gesamten Anwendung (in der Ressourcenauswahl Helm-Releases oder „Flex-Apps“ genannt) erstellen können, einschließlich Volumes und anderer Ressourcen, sodass Sie auf Velero verzichten können. Und alles wäre wunderbar, wenn es nicht ein kleines Detail gäbe: Wenn Sie eine Anwendung auf einem neuen Cluster wiederherstellen (oder „importieren“, wie es in Robin heißt) – zum Beispiel im Falle einer Notfallwiederherstellung – die Wiederherstellung von Natürlich funktioniert es, aber es ist verboten, die Anwendung weiterhin zu sichern. In dieser Version ist dies einfach nicht möglich, und die Entwickler haben es bestätigt. Das ist gelinde gesagt seltsam, insbesondere wenn man andere Vorteile berücksichtigt (z. B. unglaublich schnelle Backups und Wiederherstellungen). Die Entwickler versprechen, bis zum nächsten Release alles zu beheben. Die Leistung ist im Allgemeinen gut, aber mir ist etwas Merkwürdiges aufgefallen: Wenn Sie den Benchmark direkt auf einem an den Host angeschlossenen Volume ausführen, ist die Lesegeschwindigkeit viel höher als auf demselben Volume, jedoch aus dem Inneren des Pods. Alle anderen Ergebnisse sind identisch, theoretisch sollte es jedoch keinen Unterschied geben. Obwohl sie daran arbeiten, frustrierte mich das Wiederherstellungs- und Backup-Problem – es schien mir, als hätte ich endlich eine passende Lösung gefunden, und ich war sogar bereit, dafür zu zahlen, wenn ich mehr Platz oder mehr Server brauchte.
Ich habe hier nicht viel zu sagen. Dies ist ein kostenpflichtiges Produkt, gleichermaßen cool und teuer. Die Leistung ist einfach unglaublich. Bisher ist dies der beste Indikator. Slack teilte mir mit, dass die Preise bei 205 US-Dollar pro Monat und Knoten beginnen, wie auf dem GKE Marketplace von Google aufgeführt. Ich weiß nicht, ob es günstiger wird, wenn man direkt kauft. Ich kann es mir jedenfalls nicht leisten und war daher sehr, sehr enttäuscht, dass eine Entwicklerlizenz (bis zu 1 TB und 3 Knoten) mit Kubernetes praktisch nutzlos ist, es sei denn, man begnügt sich mit statischer Bereitstellung. Ich hatte gehofft, dass die Volumenlizenz am Ende des Testzeitraums automatisch auf Entwickler heruntergestuft würde, aber das ist nicht geschehen. Die Entwicklerlizenz kann nur direkt mit Docker genutzt werden und die Einrichtung in Kubernetes ist sehr umständlich und eingeschränkt. Natürlich bevorzuge ich Open Source, aber wenn ich Geld hätte, würde ich mich auf jeden Fall für Portworx entscheiden. Bisher ist seine Leistung einfach nicht mit anderen Optionen vergleichbar.
Ich habe diesen Abschnitt nach der Veröffentlichung des Beitrags hinzugefügt, nachdem ein Leser Linstor empfohlen hatte. Ich habe es ausprobiert und war begeistert! Allerdings muss ich noch etwas genauer recherchieren. Bis jetzt kann ich sagen, dass die Performance recht gut ist (die Benchmark-Ergebnisse habe ich weiter unten angehängt). Tatsächlich habe ich die gleiche Performance wie mit einem direkten Festplatten-Benchmark erzielt, ohne zusätzlichen Overhead. (Fragen Sie nicht, warum die Werte von Portworx besser sind als die des direkten Festplatten-Benchmarks. Ich habe keine Ahnung. Vermutlich Magie.) Linstor scheint also bisher sehr effektiv zu sein. Die Einrichtung ist nicht gerade schwierig, aber auch nicht so einfach wie bei anderen Optionen. Zuerst musste ich Linstor (Kernelmodul und Tools/Services) installieren und LVM für Thin Provisioning und Snapshot-Unterstützung außerhalb von Kubernetes, direkt auf dem Host, einrichten. Anschließend musste ich die Ressourcen erstellen, die für die Nutzung des Speichers in Kubernetes benötigt werden. Ich war nicht zufrieden damit, dass es nicht funktionierte auf CentOS und musste benutzen UbuntuEs ist natürlich keine große Sache, aber etwas ärgerlich, da die (übrigens hervorragende) Dokumentation mehrere Pakete erwähnt, die in den angegebenen EPEL-Repositories nicht verfügbar sind. Linstor bietet Snapshots, aber keine externen Backups, weshalb ich für Volume-Backups wieder Velero mit Restic verwenden musste. Snapshots wären mir lieber als Backups auf Dateiebene, aber das ist akzeptabel, solange die Lösung performant und zuverlässig ist. Linstor ist Open Source, bietet aber kostenpflichtigen Support. Soweit ich weiß, kann man es auch ohne Supportvertrag uneingeschränkt nutzen, das müsste ich aber noch einmal überprüfen. Ich weiß nicht, wie gut Linstor für Kubernetes getestet ist, aber die Speicherschicht selbst ist außerhalb von Kubernetes angesiedelt, und da es Linstor schon länger gibt, wurde es wahrscheinlich bereits unter realen Bedingungen getestet. Gibt es eine Lösung, die mich zum Umdenken und zur Rückkehr zu Kubernetes bewegen könnte? Ich weiß es nicht. Ich muss mich noch etwas genauer mit dem Thema Replikation auseinandersetzen. Mal sehen. Der erste Eindruck ist aber gut. Ich würde definitiv meine eigenen Kubernetes-Cluster Heroku vorziehen, um mehr Freiheit zu haben und Neues zu lernen. Da Linstor nicht so einfach zu installieren ist wie andere Anbieter, werde ich demnächst einen Beitrag darüber schreiben.
Benchmarks
Leider habe ich nur wenige Aufzeichnungen über den Vergleich geführt, da ich nicht glaubte, dass ich darüber schreiben würde. Ich habe nur FIO-Baseline-Benchmark-Ergebnisse und nur für Einzelknoten-Cluster, daher habe ich noch keine Zahlen für replizierte Konfigurationen. Aber anhand dieser Ergebnisse können Sie eine ungefähre Vorstellung davon bekommen, was Sie von den einzelnen Optionen erwarten können, da ich sie auf denselben Cloud-Servern, 4 Kernen, 16 GB RAM und einer zusätzlichen 100-GB-Festplatte für die getesteten Volumes verglichen habe. Ich habe die Benchmarks für jede Lösung dreimal durchgeführt und das durchschnittliche Ergebnis berechnet sowie die Servereinstellungen für jedes Produkt zurückgesetzt. Das alles ist völlig unwissenschaftlich, nur damit Sie es allgemein verstehen. In anderen Tests habe ich 38 GB Fotos und Videos vom Volume kopiert und das Lesen und Schreiben getestet, aber leider habe ich die Zahlen nicht gespeichert. Kurz gesagt: Portworkx war viel schneller.
Für den Volumen-Benchmark 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: 4Ich habe zunächst ein Volume mit der entsprechenden Speicherklasse erstellt und den Job dann mit fio im Hintergrund ausgeführt. Ich habe 1 GB genommen, um die Leistung abzuschätzen und nicht zu lange zu warten. Hier sind die Ergebnisse:
Ich habe den besten Wert für jede Metrik grün und den schlechtesten rot hervorgehoben.
Fazit
Wie Sie sehen, schnitt Portworx in den meisten Fällen besser ab als andere. Aber für mich ist es teuer. Ich weiß nicht, wie viel Robin kostet, aber es gibt eine tolle kostenlose Version. Wenn Sie also ein kostenpflichtiges Produkt benötigen, können Sie es ausprobieren (ich hoffe, dass das Problem mit Wiederherstellungen und Backups bald behoben wird). Von den drei kostenlosen Versionen hatte ich mit OpenEBS die wenigsten Probleme, aber die Leistung ist miserabel. Es tut mir leid, dass ich keine weiteren Ergebnisse gespeichert habe, aber ich hoffe, dass die Zahlen und meine Kommentare Ihnen helfen werden.
Source: habr.com
