{"id":37528,"date":"2019-10-31T22:18:10","date_gmt":"2019-10-31T19:18:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor\/"},"modified":"2019-10-31T22:18:10","modified_gmt":"2019-10-31T19:18:10","slug":"hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","title":{"rendered":"Speicher in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Speicher in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor\" src=\"\/wp-content\/uploads\/2019\/08\/304037eee8371c64de73ae0fc42f05ac.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><strong>Aktualisierung!<\/strong>. In den Kommentaren hat ein Leser vorgeschlagen, es mit <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linbit.com\/en\/linstor\/\">Linstor<\/a><\/noindex> zu versuchen (vielleicht arbeitet er selbst daran), also habe ich einen Abschnitt \u00fcber diese L\u00f6sung hinzugef\u00fcgt. Ich habe auch einen <noindex><a rel=\"nofollow\" href=\"http:\/\/vitobotta.com\/2019\/08\/07\/linstor-storage-with-kubernetes\/\">Beitrag dar\u00fcber geschrieben, wie man es installiert<\/a><\/noindex>, weil der Prozess sich stark von den anderen unterscheidet.<\/p>\n<p><\/p>\n<p>Um ehrlich zu sein, habe ich aufgegeben und mich entschieden, auf <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/\">Kubernetes<\/a><\/noindex> zu verzichten (zumindest vorerst). Ich werde <noindex><a rel=\"nofollow\" href=\"https:\/\/www.heroku.com\/\">Heroku<\/a><\/noindex>benutzen. Warum? Wegen des Speichers! Wer h\u00e4tte gedacht, dass ich mich mehr mit Speicherl\u00f6sungen besch\u00e4ftigen w\u00fcrde als mit Kubernetes selbst. Ich benutze <noindex><a rel=\"nofollow\" href=\"https:\/\/www.hetzner.com\/cloud\">Hetzner Cloud<\/a><\/noindex>, weil es g\u00fcnstig ist und die Leistung gut ist, und von Anfang an habe ich Cluster mit Hilfe von <noindex><a rel=\"nofollow\" href=\"https:\/\/rancher.com\/\">Rancher<\/a><\/noindex>bereitgestellt. Ich habe die verwalteten Kubernetes-Dienste von Google\/Amazon\/Microsoft\/DigitalOcean und \u00e4hnlichen nicht ausprobiert, weil ich alles selbst lernen wollte. Au\u00dferdem bin ich sparsam.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Also ja, ich habe viel Zeit damit verbracht, zu entscheiden, welches Speicherangebot ich w\u00e4hlen soll, als ich die m\u00f6glichen Stacks f\u00fcr Kubernetes durchdachte. Ich bevorzuge Open-Source-L\u00f6sungen, und das nicht nur wegen des Preises, sondern ich habe ein paar kostenpflichtige Optionen aus Neugierde untersucht, weil sie kostenlose Versionen mit Einschr\u00e4nkungen haben. Ich habe ein paar Zahlen aus den letzten Tests notiert, als ich verschiedene Optionen verglichen habe, und die k\u00f6nnten f\u00fcr diejenigen von Interesse sein, die sich mit Speicher in Kubernetes besch\u00e4ftigen. Obwohl ich pers\u00f6nlich momentan mit Kubernetes aufgeh\u00f6rt habe. Ich m\u00f6chte auch <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hetznercloud\/csi-driver\">den CSI-Treiber<\/a><\/noindex>erw\u00e4hnen, mit dem man direkt Volumes f\u00fcr Hetzner Cloud vorbereiten kann, aber ich habe ihn noch nicht ausprobiert. Ich habe cloudbasierte softwaredefinierte Speicherl\u00f6sungen untersucht, weil ich Replikation und die M\u00f6glichkeit ben\u00f6tigte, persistent Volumes schnell an jedem Knoten zu verbinden, insbesondere im Falle von Knotenausf\u00e4llen und \u00e4hnlichen Situationen. Einige L\u00f6sungen bieten zeitbasierte Snapshots und Off-Site-Backups an, was praktisch ist.<\/p>\n<p><\/p>\n<p>Ich habe 6\u20137 Speicherl\u00f6sungen getestet:<\/p>\n<p><\/p>\n<h3 id=\"openebshttpsopenebsio\"><noindex><a rel=\"nofollow\" href=\"https:\/\/openebs.io\/\">OpenEBS<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>Wie ich bereits gesagt habe, <noindex><a rel=\"nofollow\" href=\"http:\/\/vitobotta.com\/2019\/07\/03\/openebs-tips\/\">in einem fr\u00fcheren Beitrag.<\/a><\/noindex>, stoppte ich nach dem Testen der meisten Optionen auf der Liste zun\u00e4chst bei OpenEBS. OpenEBS l\u00e4sst sich sehr einfach installieren und nutzen, aber um ehrlich zu sein, entt\u00e4uschte mich die Leistung nach Tests mit echten Daten unter Last. Es ist Open Source, und die Entwickler auf ihrem <noindex><a rel=\"nofollow\" href=\"https:\/\/openebs-community.slack.com\/\">Slack-Kanal<\/a><\/noindex> Sie haben immer sehr geholfen, wenn ich Unterst\u00fctzung brauchte. Leider hat er eine sehr niedrige Leistung im Vergleich zu anderen Optionen, daher musste ich die Tests neu durchf\u00fchren. Momentan hat OpenEBS 3 Speichermotoren, aber ich ver\u00f6ffentliche die Benchmark-Ergebnisse f\u00fcr cStor. Bisher habe ich keine Zahlen f\u00fcr Jiva und LocalPV.<\/p>\n<p><\/p>\n<p>Kurz gesagt, Jiva ist etwas schneller, w\u00e4hrend LocalPV insgesamt schnell ist, nicht schlechter als der Benchmark f\u00fcr direktes Disk-Access. Das Problem mit LocalPV ist, dass der Zugriff nur auf dem Knoten m\u00f6glich ist, auf dem es vorbereitet wurde, und es gibt \u00fcberhaupt keine Replikation. Ich hatte einige Probleme mit der Wiederherstellung des Backups \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/velero.io\/\">Velero<\/a><\/noindex> auf einem neuen Cluster, da die Knotennamen unterschiedlich waren. Wenn es um Backups geht, hat cStor einen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openebs\/velero-plugin\">Plugin f\u00fcr Velero<\/a><\/noindex>, 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 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/vitobotta\/velero-openebs-backup\">einige Skripte<\/a><\/noindex>, um die Verwaltung von Backups und Wiederherstellungen mit diesem Plugin zu erleichtern. Insgesamt gef\u00e4llt mir OpenEBS sehr gut, aber die Leistung&#8230;<\/p>\n<p><\/p>\n<h3 id=\"rookhttpsrookio\"><noindex><a rel=\"nofollow\" href=\"https:\/\/rook.io\/\">Rook<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>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\u00fchrt, wie zum Beispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/ceph.io\/\">Ceph<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/edgefs.io\/\">EdgeFS<\/a><\/noindex> und andere, was die Arbeit erheblich erleichtert. Ich hatte vor einigen Monaten Probleme mit EdgeFS, also habe ich haupts\u00e4chlich 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\u00f6glichkeit, die Daten eines Volumes \u00fcber mehrere Festplatten zu verteilen, damit das Volume mehr Speicherplatz nutzen kann, als auf einer einzelnen Festplatte m\u00f6glich ist. Das ist praktisch. Eine weitere coole Funktion ist, dass beim Hinzuf\u00fcgen von Festplatten zum Cluster die Daten automatisch auf alle Festplatten neu verteilt werden.<\/p>\n<p><\/p>\n<p>Ceph verf\u00fcgt \u00fcber Snapshots, aber soweit ich wei\u00df, k\u00f6nnen diese nicht direkt in Rook\/Kubernetes verwendet werden. Allerdings habe ich mich nicht ausf\u00fchrlich damit besch\u00e4ftigt. 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 \u2013 es verbirgt fast alle komplexen Dinge und bietet Tools, um direkt mit Ceph zur Probleml\u00f6sung zu kommunizieren. Leider hatte ich bei dem Stresstest der Ceph-Volumes st\u00e4ndig <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rook\/rook\/issues\/3132\">dieses Problem<\/a><\/noindex>, 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\u00e4ndig gel\u00f6st. Ceph bietet eine gute Leistung, wie in den Benchmarks unten zu sehen ist. Au\u00dferdem hat es ein gutes \u00dcberwachungsdashboard.<\/p>\n<p><\/p>\n<h3 id=\"rancher-longhornhttpsgithubcomlonghornlonghorn\"><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/longhorn\/longhorn\">Rancher Longhorn<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>Ich mag Longhorn sehr. Meiner Meinung nach ist es eine vielversprechende L\u00f6sung. Die Entwickler selbst (Rancher Labs) geben jedoch zu, dass es f\u00fcr eine Produktionsumgebung derzeit nicht geeignet ist, und das ist offensichtlich. Es hat einen offenen Quellcode und eine anst\u00e4ndige Leistung (obwohl sie sich noch nicht um die Optimierung gek\u00fcmmert 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\u00dfen Backups oder einem Upgrade der Arbeitslast. Es gibt Snapshots und Offsite-Backups dieser Snapshots, aber diese gelten nur f\u00fcr Volumes, sodass man dennoch etwas wie Velero f\u00fcr die Sicherung der \u00fcbrigen Ressourcen ben\u00f6tigt. Die Backups und Wiederherstellungen sind sehr zuverl\u00e4ssig, 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 \u00dcberwachungsdashboard zur Verwaltung von Longhorn. Ich habe schon gesagt, dass ich Longhorn mag, aber es muss noch gr\u00fcndlich bearbeitet werden.<\/p>\n<p><\/p>\n<h3 id=\"storageoshttpsstorageoscom\"><noindex><a rel=\"nofollow\" href=\"https:\/\/storageos.com\/\">StorageOS<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>StorageOS ist das erste kostenpflichtige Produkt auf der Liste. Es gibt eine Entwicklerversion mit einer begrenzten verwalteten Speicherkapazit\u00e4t 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\u00fcr 1 TB beginnen, wenn ich mich richtig erinnere. Es gibt ein grundlegendes Dashboard und eine benutzerfreundliche CLI, aber die Leistung scheint merkw\u00fcrdig zu sein: In einigen Benchmarks ist sie recht ordentlich, aber im Stresstest der Volumes gefiel mir die Geschwindigkeit \u00fcberhaupt nicht. Insgesamt wei\u00df ich nicht, was ich sagen soll. Daher habe ich mich nicht besonders damit besch\u00e4ftigt. Es gibt keine Offsite-Backups, und ich werde Velero mit Restic f\u00fcr die Sicherung der Volumes verwenden m\u00fcssen. Seltsam, denn das Produkt ist kostenpflichtig. Und au\u00dferdem waren die Entwickler nicht sehr daran interessiert, in Slack zu kommunizieren.<\/p>\n<p><\/p>\n<h3 id=\"robinhttpsrobinio\"><noindex><a rel=\"nofollow\" href=\"https:\/\/robin.io\/\">Robin<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>Ich habe von Robin \u00fcber Reddit von ihrem technischen Direktor erfahren. Davor hatte ich noch nie von ihm geh\u00f6rt. Vielleicht, weil ich kostenlose L\u00f6sungen gesucht habe, w\u00e4hrend Robin kostenpflichtig ist. Sie haben eine recht gro\u00dfz\u00fcgige 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\u00dflich Volumes und anderer Ressourcen, sodass man ohne Velero auskommen kann. Und alles w\u00e4re wunderbar, wenn da nicht eine kleine Detail w\u00e4re: Wenn man eine Anwendung auf einem neuen Cluster wiederherstellt (oder \u201eimportiert\u201c, wie es bei Robin genannt wird) \u2013 zum Beispiel im Fall einer Wiederherstellung nach einem Ausfall \u2013 funktioniert die Wiederherstellung nat\u00fcrlich, aber das Backup der Anwendung kann nicht fortgesetzt werden. In dieser Version ist das einfach unm\u00f6glich, und die Entwickler haben dies best\u00e4tigt. 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\u00e4chsten 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\u00fchrt, ist die Lesegeschwindigkeit viel h\u00f6her 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\u00e4uscht \u00fcber das Problem mit der Wiederherstellung und dem Backup \u2013 ich hatte das Gef\u00fchl, dass ich endlich die passende L\u00f6sung gefunden hatte, und ich war sogar bereit, daf\u00fcr zu zahlen, wenn ich mehr Speicherplatz oder mehr Server ben\u00f6tige.<\/p>\n<p><\/p>\n<h3 id=\"portworxhttpsportworxcom\"><noindex><a rel=\"nofollow\" href=\"https:\/\/portworx.com\/\">Portworx<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>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\u00df nicht, ob es g\u00fcnstiger wird, wenn man direkt kauft. Auf jeden Fall kann ich mir das nicht leisten, also war ich sehr und sehr entt\u00e4uscht, dass die Entwicklerversion (bis zu 1 TB und 3 Nodes) praktisch nutzlos mit Kubernetes ist, es sei denn, man begn\u00fcgt 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\u00e4ndlich und eingeschr\u00e4nkt. Ich bevorzuge nat\u00fcrlich Open Source, aber h\u00e4tte ich das Geld, w\u00fcrde ich mich definitiv f\u00fcr Portworx entscheiden. Bisher kann seine Leistung einfach nicht mit anderen Optionen verglichen werden.<\/p>\n<p><\/p>\n<h3 id=\"linstorhttpswwwlinbitcomenlinstor\"><noindex><a rel=\"nofollow\" href=\"https:\/\/www.linbit.com\/en\/linstor\/\">Linstor<\/a><\/noindex><\/h3>\n<p><\/p>\n<p>Ich habe diesen Abschnitt bereits nach der Ver\u00f6ffentlichung des Beitrags hinzugef\u00fcgt, als ein Leser vorschlug, Linstor auszuprobieren. Ich habe es getestet und mir gef\u00e4llt es! Aber ich muss noch weiter forschen. Jetzt kann ich sagen, dass die Leistung ganz ordentlich ist (Benchmark-Ergebnisse habe ich weiter unten hinzugef\u00fcgt). Im Grunde genommen habe ich die gleiche Leistung erzielt wie bei einer direkten Verbindung zum Datentr\u00e4ger, und das ganz ohne zus\u00e4tzliche Kosten. (Fragt nicht, warum die Zahlen bei Portworx besser sind als der Benchmark des Datentr\u00e4gers 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\u00fcr Thin Provisioning und Snapshot-Unterst\u00fctzung au\u00dferhalb von Kubernetes direkt auf dem Host einrichten, danach musste ich die Ressourcen erstellen, die ben\u00f6tigt werden, um Speicher aus Kubernetes zu nutzen. Es hat mich gest\u00f6rt, dass es nicht auf CentOS funktionierte und ich Ubuntu verwenden musste. Ist nicht schlimm, nat\u00fcrlich, aber es ist ein bisschen l\u00e4stig, weil in der Dokumentation (die \u00fcbrigens ausgezeichnet ist) einige Pakete erw\u00e4hnt 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\u00fcr die Backup von Volumes verwenden. Ich w\u00fcrde Snapshots anstelle von Backups auf Dateiebene bevorzugen, aber das ist verkraftbar, wenn die L\u00f6sung leistungsf\u00e4hig und zuverl\u00e4ssig ist. Linstor ist Open Source, bietet aber kostenpflichtigen Support an. Wenn ich richtig verstehe, kann man es ohne Einschr\u00e4nkungen nutzen, auch wenn man keinen Supportvertrag hat, aber das m\u00fcsste ich noch kl\u00e4ren. Ich wei\u00df nicht, wie gut Linstor f\u00fcr Kubernetes getestet ist, aber das Speichersystem selbst liegt au\u00dferhalb von Kubernetes und anscheinend gibt es die L\u00f6sung nicht erst seit gestern, also wurde sie wahrscheinlich bereits in der Praxis erprobt. Gibt es hier eine L\u00f6sung, die mich umdenken l\u00e4sst und mich zur\u00fcck zu Kubernetes bringt? Ich wei\u00df es nicht, ich wei\u00df es nicht. Ich muss noch weiter st\u00f6bern und die Replikation studieren. Mal sehen. Aber der erste Eindruck ist gut. Ich w\u00fcrde 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\u00fcber schreiben.<\/p>\n<p><\/p>\n<h3 id=\"benchmarki\">Benchmarks<\/h3>\n<p><\/p>\n<p>Leider habe ich nur wenige Aufzeichnungen \u00fcber die Vergleiche gespeichert, da ich nicht daran gedacht habe, dass ich dar\u00fcber schreiben w\u00fcrde. Ich habe nur die Ergebnisse der grundlegenden Benchmarks von fio und nur f\u00fcr Cluster mit einem Knoten, sodass ich noch keine Zahlen f\u00fcr replizierte Konfigurationen habe. Aber aus diesen Ergebnissen kann man eine ungef\u00e4hre 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\u00e4tzlichen 100-GB-Festplatte f\u00fcr die getesteten Volumes. Ich habe die Benchmarks dreimal f\u00fcr jede L\u00f6sung durchlaufen und den Durchschnitt berechnet, au\u00dferdem habe ich die Servereinstellungen f\u00fcr jedes Produkt zur\u00fcckgesetzt. 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.<\/p>\n<p><\/p>\n<p>F\u00fcr den Benchmark der Volumes habe ich dieses Manifest verwendet:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">kind: PersistentVolumeClaim\napiVersion: v1\nmetadata:\n  name: dbench\nspec:\n  storageClassName: ...\n  accessModes:\n    - ReadWriteOnce\n  resources:\n    requests:\n      storage: 5Gi\n---\napiVersion: batch\/v1\nkind: Job\nmetadata:\n  name: dbench\nspec:\n  template:\n    spec:\n      containers:\n      - name: dbench\n        image: sotoaster\/dbench:latest\n        imagePullPolicy: IfNotPresent\n        env:\n          - name: DBENCH_MOUNTPOINT\n            value: \/data\n          - name: FIO_SIZE\n            value: 1G\n        volumeMounts:\n        - name: dbench-pv\n          mountPath: \/data\n      restartPolicy: Never\n      volumes:\n      - name: dbench-pv\n        persistentVolumeClaim:\n          claimName: dbench\n  backoffLimit: 4<\/code><\/pre>\n<p><\/p>\n<p>Zuerst habe ich ein Volume mit der entsprechenden Speicherklasse erstellt und anschlie\u00dfend das Job mit fio im Hintergrund gestartet. Ich nahm 1 GB, um die Leistung abzusch\u00e4tzen und nicht zu lange zu warten. Hier sind die Ergebnisse:<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/nm\/i_\/4h\/nmi_4holmvcqehuigcoespgeure.png\"><img decoding=\"async\" alt=\"Speicher in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor\" src=\"\/wp-content\/uploads\/2019\/08\/41e91c4e299759817bba6a2a8e9ff14e.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Ich habe die besten Werte f\u00fcr jeden Parameter gr\u00fcn und die schlechtesten rot markiert.<\/p>\n<p><\/p>\n<h3 id=\"zaklyuchenie\">Fazit<\/h3>\n<p><\/p>\n<p>Wie Sie sehen, hat sich Portworx in den meisten F\u00e4llen besser geschlagen als die anderen. Aber f\u00fcr mich ist es teuer. Ich wei\u00df nicht, was Robin kostet, aber dort gibt es eine gro\u00dfartige kostenlose Version, sodass Sie, wenn Sie ein kostenpflichtiges Produkt brauchen, es ausprobieren k\u00f6nnen (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.<\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/464987\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435!. \u0412 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0445 \u043e\u0434\u0438\u043d \u0438\u0437 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u043b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c Linstor (\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043e\u043d \u0441\u0430\u043c \u043d\u0430\u0434 \u043d\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u0442\u0430\u043a \u0447\u0442\u043e \u044f \u0434\u043e\u0431\u0430\u0432\u0438\u043b \u0440\u0430\u0437\u0434\u0435\u043b \u043e\u0431 \u044d\u0442\u043e\u043c \u0440\u0435\u0448\u0435\u043d\u0438\u0438. \u0415\u0449\u0435 \u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u043f\u043e\u0441\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0435\u0433\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u044c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0441\u0438\u043b\u044c\u043d\u043e \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u043e\u0442 \u043e\u0441\u0442\u0430\u043b\u044c\u043d\u044b\u0445. \u0415\u0441\u043b\u0438 \u0447\u0435\u0441\u0442\u043d\u043e, \u044f \u0441\u0434\u0430\u043b\u0441\u044f \u0438 \u043e\u0442\u043a\u0430\u0437\u0430\u043b\u0441\u044f \u043e\u0442 Kubernetes (\u0432\u043e \u0432\u0441\u044f\u043a\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435, \u043f\u043e\u043a\u0430). \u0411\u0443\u0434\u0443 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Heroku. \u041f\u043e\u0447\u0435\u043c\u0443? [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28163,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37528","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0425\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0432 Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:18:10+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:18:10+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Speichersysteme in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0425\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0432 Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:10+00:00","article:modified_time":"2019-10-31T19:18:10+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37528","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:13:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:25:26","updated":"2026-01-23 18:13:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37528","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=37528"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37528\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/28163"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=37528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=37528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=37528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}