Update! . In den Kommentaren schlug einer der Leser vor, Linstor auszuprobieren (vielleicht arbeitet er selbst daran), also fügte ich einen Abschnitt über diese Lösung hinzu. Ich habe auch einen Beitrag darüber geschrieben, wie man es installiert , weil der Prozess sich sehr von den anderen unterscheidet.
Um ehrlich zu sein, habe ich Kubernetes aufgegeben und aufgegeben (zumindest vorerst ). Ich werde Heroku benutzen. Warum? Wegen der Lagerung! Wer hätte gedacht, dass ich mich mehr mit Speicher als mit Kubernetes selbst anlegen würde? Ich verwende die Hetzner Cloud, weil sie kostengünstig und leistungsfähig ist, und habe von Anfang an Cluster mit Rancher bereitgestellt. Ich habe Kubernetes Managed Services von Google / Amazon / Microsoft / DigitalOcean usw. usw. nicht ausprobiert, weil ich alles selbst lernen wollte. Und ich bin sparsam.
Also - ja, ich habe viel Zeit damit verbracht, zu entscheiden, welchen Speicher ich wählen soll, als ich über einen möglichen Stapel auf Kubernetes nachdachte. Ich bevorzuge Open Source-Lösungen, nicht nur wegen des Preises, sondern ich habe aus Neugier ein paar kostenpflichtige Optionen studiert, weil sie kostenlose Versionen mit Einschränkungen haben. Ich habe einige Zahlen aus den letzten Tests aufgeschrieben, als ich verschiedene Optionen verglichen habe, und sie könnten für diejenigen von Interesse sein, die Speicher in Kubernetes studieren. Obwohl ich mich bisher persönlich von Kubernetes verabschiedet habe. Ich möchte auch den CSI-Treiber erwähnen, mit dem Sie Hetzner Cloud-Volumes direkt vorbereiten können, aber ich habe ihn noch nicht ausprobiert. Ich habe Cloud-basierten, softwaredefinierten Speicher studiert, weil ich Replikation und die Fähigkeit benötigte, persistente Volumes schnell auf jedem Knoten bereitzustellen, insbesondere im Falle eines Knotenausfalls und anderer ähnlicher Situationen. Einige Lösungen bieten Snapshots zu einem bestimmten Zeitpunkt und Backups außerhalb des Standorts, was praktisch ist.
Ich habe 6-7 Speicherlösungen getestet:
Wie ich bereits in einem früheren Beitrag sagte, habe ich mich nach dem Testen der meisten Optionen auf der Liste zunächst für OpenEBS entschieden. OpenEBS ist sehr einfach zu installieren und zu verwenden, aber um ehrlich zu sein, hat mich die Leistung nach dem Testen mit realen Daten unter Last enttäuscht. Dies ist eine Open Source-Version, und die Entwickler auf ihrem Slack-Kanal haben mir immer sehr geholfen, wenn ich Hilfe brauchte. Leider hat es im Vergleich zu anderen Optionen eine sehr geringe Leistung, so dass ich die Tests erneut ausführen musste. OpenEBS hat jetzt 3 Speicher-Engines, aber ich veröffentliche die Benchmark-Ergebnisse für cStor. Bisher habe ich keine Nummern für Jiva und LocalPV.
Kurz gesagt, Jiva ist etwas schneller und LocalPV ist im Allgemeinen schneller, nicht schlechter als der Benchmark des Laufwerks direkt. Das Problem mit LocalPV besteht darin, dass der Zugriff auf das Volume nur auf dem Knoten möglich ist, auf dem es vorbereitet wurde, und dass absolut keine Replikation stattfindet. Ich hatte einige Probleme beim Wiederherstellen des Backups über Velero in einem neuen Cluster, da die Knotennamen unterschiedlich waren. Wenn wir über Backups sprechen, hat cStor ein Plugin für Velero , mit dem Sie Off-Site-Backups von Snapshots gleichzeitig durchführen können. Dies ist bequemer als Backups auf Dateiebene mit Velero-Restic. Ich habe mehrere Skripte geschrieben , um die Verwaltung von Backups und Wiederherstellungen mit diesem Plugin zu vereinfachen. Im Allgemeinen mag ich OpenEBS sehr, aber seine Leistung ...
Rook verfügt auch über Open Source-Code und unterscheidet sich von den anderen Optionen in der Liste darin, dass es sich um einen Speicher-Orchestrator handelt, der komplexe Aufgaben zum Verwalten von Speicher mit verschiedenen Backends wie Ceph , EdgeFS und anderen ausführt , was die Arbeit erheblich vereinfacht. Ich hatte Probleme mit EfgeFS, als ich es vor einigen Monaten ausprobierte, also habe ich hauptsächlich mit Ceph getestet. Ceph bietet nicht nur Blockspeicher, sondern auch Objektspeicher, der mit S3 / Swift und dem verteilten Dateisystem kompatibel ist. Was mir an Ceph gefällt, ist die Möglichkeit, Datenträgerdaten auf mehrere Datenträger zu verteilen, sodass der Datenträger mehr Speicherplatz beanspruchen kann, als auf einen einzelnen Datenträger passen kann. Das ist bequem. Eine weitere coole Funktion ist, dass beim Hinzufügen von Datenträgern zu einem Cluster Daten automatisch auf alle Datenträger verteilt werden.
Es gibt Schnappschüsse in Ceph, aber soweit ich weiß, können sie nicht direkt in Rook / Kubernetes verwendet werden. Es stimmt, ich bin nicht darauf eingegangen. Außerhalb des Standorts gibt es jedoch keine Sicherungen, sodass Sie etwas mit Velero / Restic verwenden müssen. Es gibt jedoch nur Sicherungen auf Dateiebene, keine Snapshots. Aber in Rook hat mir die einfache Arbeit mit Ceph sehr gut gefallen - sie verbirgt fast alle komplexen Dinge und bietet Tools zur direkten Kommunikation mit Ceph zur Fehlerbehebung. Leider hatte ich beim Stresstest der Ceph-Volumina die ganze Zeit dieses Problem , wodurch Ceph instabil wurde. Es ist noch nicht klar, ob dies ein Fehler in Ceph selbst oder ein Problem bei der Steuerung von Ceph durch Rook ist. Ich habe mit den Speichereinstellungen gezaubert, und es wurde besser, aber das Problem wurde erst am Ende gelöst. Ceph hat eine gute Leistung, wie Sie in den folgenden Benchmarks sehen können. Er hat auch ein gutes Armaturenbrett.
Ich mag Longhorn wirklich. Meiner Meinung nach ist dies eine vielversprechende Lösung. Die Entwickler selbst (Rancher Labs) erkennen zwar an, dass es nicht für die Arbeitsumgebung geeignet ist, und dies kann gesehen werden. Es verfügt über Open Source-Code und eine gute Leistung (obwohl es noch nicht optimiert wurde), aber die Verbindung zum Herd dauert sehr lange, und im schlimmsten Fall dauert es 15 bis 16 Minuten, insbesondere nach dem Wiederherstellen einer großen Sicherungs- oder Upgrade-Workload. Er verfügt über Snapshots und Off-Site-Backups dieser Snapshots, die jedoch nur für Volumes gelten. Sie benötigen also noch etwas wie Velero, um andere Ressourcen zu sichern. Backups und Wiederherstellungen sind sehr zuverlässig, aber unangemessen langsam. Im Ernst, nur unerschwinglich langsam. Die CPU-Auslastung und die Systemauslastung springen häufig, wenn mit durchschnittlichen Daten in Longhorn gearbeitet wird. Es gibt ein praktisches Armaturenbrett zur Steuerung des Longhorns. Ich habe bereits gesagt, dass ich Longhorn mag, aber es muss daran gearbeitet werden.
StorageOS ist das erste bezahlte Produkt auf der Liste. Es gibt eine Version für Entwickler mit einem begrenzten verwalteten Speicher von 500 GB, aber die Anzahl der Knoten ist meiner Meinung nach nicht begrenzt. Die Verkaufsabteilung teilte mir mit, dass die Kosten für 1 TB bei 125 USD pro Monat beginnen, wenn ich mich richtig erinnere. Es gibt ein einfaches Dashboard und eine praktische CLI, aber mit der Leistung passiert etwas Seltsames: In einigen Benchmarks ist es recht anständig, aber die Geschwindigkeit im Stresstest der Volumes hat mir überhaupt nicht gefallen. Im Allgemeinen weiß ich nicht, was ich sagen soll. Daher habe ich nicht besonders verstanden. Es gibt keine externen Sicherungen, und Sie müssen Velero mit Restic auch zum Sichern von Volumes verwenden. Es ist seltsam, weil das Produkt bezahlt wird. Und die Entwickler wollten nicht unbedingt in Slack kommunizieren.
Ich habe Robin auf Reddit von ihrem technischen Direktor erfahren. Ich hatte noch nie von ihm gehört. Vielleicht, weil ich nach kostenlosen Lösungen suchte und Robin bezahlte. Sie haben eine ziemlich großzügige kostenlose Version mit 10 TB Speicher und drei Knoten. Im Allgemeinen ist das Produkt recht anständig und mit schönen Eigenschaften. Es gibt dort eine ausgezeichnete CLI, aber das Coole ist, dass Sie die gesamte Anwendung (in der Ressourcenauswahl als Helm-Releases oder „Flex-Apps“ bezeichnet), einschließlich Volumes und anderer Ressourcen, mit Snapshots und Backups 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 in einem neuen Cluster wiederherstellen (oder "importieren", wie Robin es nennt) - zum Beispiel im Falle einer Wiederherstellung nach einem Unfall -, funktioniert die Wiederherstellung natürlich, aber sichern Sie die Anwendung weiter nicht erlaubt. In dieser Version ist dies einfach nicht möglich, und die Entwickler haben dies bestätigt. Dies ist, gelinde gesagt, seltsam, insbesondere wenn Sie die anderen Vorteile berücksichtigen (z. B. unglaublich schnelle Sicherungen und Wiederherstellungen). Die Entwickler versprechen, alles für die nächste Version zu reparieren. Die Leistung ist im Allgemeinen gut, aber mir ist etwas Merkwürdiges aufgefallen: Wenn Sie den Benchmark direkt auf dem mit dem Host verbundenen Volume ausführen, ist die Lesegeschwindigkeit viel höher als bei demselben Volume, jedoch von innen. Alle anderen Ergebnisse sind identisch, aber theoretisch sollte es keinen Unterschied geben. Obwohl sie daran arbeiten, war ich wegen des Problems mit der Wiederherstellung und Sicherung verärgert - es schien mir, dass ich endlich eine geeignete Lösung gefunden hatte, und ich war sogar bereit, dafür zu bezahlen, wenn ich mehr Speicherplatz oder mehr Server benötigte.
Ich habe hier wirklich nichts zu sagen. Dies ist ein kostenpflichtiges Produkt, gleichermaßen cool und teuer. Leistung ist ein Wunder. Bisher ist dies der beste Indikator. Slack sagte mir, dass der Preis bei 205 USD pro Monat und Knoten beginnt, wie auf dem Google GKE Marketplace angegeben. Ich weiß nicht, ob es billiger ist, wenn Sie direkt kaufen. Auf jeden Fall kann ich es mir nicht leisten, daher war ich sehr, sehr enttäuscht, dass die Entwicklerlizenz (bis zu 1 TB und 3 Knoten) mit Kubernetes praktisch unbrauchbar ist, es sei denn, Sie geben sich mit der statischen Vorbereitung zufrieden. Ich hatte gehofft, dass die Volumenlizenz am Ende des Testzeitraums automatisch auf das Entwicklerniveau fallen würde, aber das war nicht der Fall. Die Entwicklerlizenz kann nur direkt mit Docker verwendet werden, und die Konfiguration in Kubernetes ist sehr umständlich und begrenzt. Natürlich bevorzuge ich Open Source, aber wenn ich Geld hätte, würde ich definitiv Portworx wählen. Bisher ist seine Leistung einfach nicht mit anderen Optionen zu vergleichen.
Ich habe diesen Abschnitt hinzugefügt, nachdem der Beitrag veröffentlicht wurde, als ein Leser vorschlug, Linstor auszuprobieren. Ich habe es versucht und es hat mir gefallen! Aber du musst noch graben. Jetzt kann ich sagen, dass die Leistung nicht schlecht ist (ich habe die Benchmark-Ergebnisse unten hinzugefügt). Tatsächlich habe ich die gleiche Leistung wie für das Laufwerk direkt erzielt, ohne jeglichen Overhead. (Fragen Sie nicht, warum Portworx direkt bessere Zahlen als der Benchmark des Laufwerks hat. Ich habe keine Ahnung. Magie wahrscheinlich.) Linstor scheint also immer noch sehr effektiv zu sein. Die Installation ist nicht so schwierig, aber nicht so einfach wie bei den anderen Optionen. Zuerst musste ich Linstor (das Kernelmodul und Tools / Services) installieren und LVM für Thin Provisioning konfigurieren und Snapshots außerhalb von Kubernetes direkt auf dem Host unterstützen und dann die Ressourcen erstellen, die für die Verwendung des Speichers von Kubernetes erforderlich sind. Mir hat es nicht gefallen, dass es unter CentOS nicht funktionierte und Ubuntu verwenden musste. Natürlich nicht beängstigend, aber ein wenig nervig, da in der Dokumentation (die übrigens hervorragend ist) mehrere Pakete erwähnt werden, die in den angegebenen Epel-Repositorys nicht zu finden sind. Linstor hat Snapshots, aber keine Off-Site-Backups, daher musste ich auch hier Velero mit Restic verwenden, um Volumes zu sichern. Ich würde Snapshots anstelle von Backups auf Dateiebene bevorzugen, aber dies kann toleriert werden, wenn die Lösung produktiv und zuverlässig ist. Linstor hat Open Source, aber es gibt kostenpflichtige Unterstützung. Wenn ich das richtig verstehe, kann es ohne Einschränkungen verwendet werden, auch wenn Sie keine Supportvereinbarung haben, dies muss jedoch geklärt werden. Ich weiß nicht, wie Linstor auf Kubernetes getestet wird, aber die Speicherebene selbst liegt außerhalb von Kubernetes, und anscheinend wurde die Lösung gestern nicht angezeigt, sodass sie wahrscheinlich bereits unter realen Bedingungen getestet 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. Es ist immer noch notwendig, tiefer zu graben, um die Replikation zu untersuchen. Mal sehen. Aber der erste Eindruck ist gut. Ich würde definitiv lieber meine eigenen Kubernetes-Cluster anstelle von Heroku verwenden, um mehr Freiheit zu gewinnen und neue Dinge zu lernen. Da Linstor nicht so einfach zu installieren ist wie andere, werde ich bald einen Beitrag darüber schreiben.
Benchmarks
Leider habe ich nur wenige Aufzeichnungen über den Vergleich geführt, weil ich nicht dachte, dass ich darüber schreiben würde. Ich habe nur die Ergebnisse der fio-Basis-Benchmarks und nur für Einzelknoten-Cluster. Für replizierte Konfigurationen habe ich also noch keine Zahlen. Aus diesen Ergebnissen können Sie sich jedoch eine ungefähre Vorstellung davon machen, was von jeder Option zu erwarten ist, da ich sie auf denselben Cloud-Servern, 4 Kernen, 16 GB RAM und einer zusätzlichen 100-GB-Festplatte für die zu testenden Volumes verglichen habe. Ich habe die Benchmarks dreimal für jede Lösung ausgeführt und das durchschnittliche Ergebnis berechnet sowie die Servereinstellungen für jedes Produkt zurückgesetzt. All dies ist völlig unwissenschaftlich, nur um Sie allgemein verständlich zu machen. In anderen Tests habe ich 38 GB Fotos und Videos von der Lautstärke kopiert und das Lesen und Schreiben getestet, aber leider habe ich die Zahlen nicht gespeichert. Kurzum: Portworkx war viel schneller.
Für den Benchmark der Volumina 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: 4
Zuerst habe ich ein Volume mit der entsprechenden Speicherklasse erstellt und dann die Aufgabe mit fio hinter den Kulissen gestartet. Ich habe 1 GB benötigt, um die Leistung abzuschätzen und nicht zu lange zu warten. Hier sind die Ergebnisse:
Ich habe den besten Wert für jeden Indikator 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 er lieb. Ich weiß nicht, wie viel Robin kostet, aber es gibt eine großartige kostenlose Version. Wenn Sie also ein kostenpflichtiges Produkt benötigen, können Sie es ausprobieren (ich hoffe, dass das Problem mit Wiederherstellung und Backups bald behoben wird). Von den drei kostenlosen hatte ich am wenigsten Probleme mit OpenEBS, aber die Leistung ist nicht zur Hölle. Schade, dass ich keine weiteren Ergebnisse gespeichert habe, aber ich hoffe, dass die angegebenen Zahlen und meine Kommentare Ihnen helfen.