{"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\/it\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","title":{"rendered":"Storage 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=\"Storage 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>Aggiornamento!<\/strong>. Nei commenti uno dei lettori ha suggerito di provare <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linbit.com\/en\/linstor\/\">Linstor<\/a><\/noindex> (forse ci sta lavorando da solo), quindi ho aggiunto una sezione su questa soluzione. Ho anche scritto <noindex><a rel=\"nofollow\" href=\"http:\/\/vitobotta.com\/2019\/08\/07\/linstor-storage-with-kubernetes\/\">un post su come installarlo<\/a><\/noindex>, perch\u00e9 il processo \u00e8 molto diverso rispetto agli altri.<\/p>\n<p><\/p>\n<p>Se devo essere onesto, ho gettato la spugna e ho rinunciato a <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/\">Kubernetes<\/a><\/noindex> (almeno per ora). Utilizzer\u00f2 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.heroku.com\/\">Heroku<\/a><\/noindex>. Perch\u00e9? A causa dello storage! Chi l'avrebbe mai detto che avrei trascorso pi\u00f9 tempo a gestire lo storage piuttosto che Kubernetes stesso. Sto utilizzando <noindex><a rel=\"nofollow\" href=\"https:\/\/www.hetzner.com\/cloud\">Hetzner Cloud<\/a><\/noindex>, perch\u00e9 \u00e8 economico e le prestazioni sono buone, e sin dall'inizio ho dispiegato cluster usando <noindex><a rel=\"nofollow\" href=\"https:\/\/rancher.com\/\">Rancher<\/a><\/noindex>. Non ho provato i servizi Kubernetes gestiti di Google\/Amazon\/Microsoft\/DigitalOcean e simili, perch\u00e9 volevo imparare tutto da solo. Inoltre, sono parsimonioso.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Quindi, s\u00ec, ho speso molto tempo cercando di decidere quale storage scegliere mentre valutavo il possibile stack su Kubernetes. Preferisco soluzioni open source, non solo per il prezzo, ma ho esplorato un paio di opzioni a pagamento per curiosit\u00e0, poich\u00e9 hanno versioni gratuite con limitazioni. Ho annotato alcuni dati dai miei ultimi test mentre confrontavo diverse opzioni, e potrebbero interessare chi studia lo storage in Kubernetes. Anche se personalmente, per ora, ho detto addio a Kubernetes. Vorrei anche menzionare <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hetznercloud\/csi-driver\">il driver CSI<\/a><\/noindex>, con cui \u00e8 possibile preparare direttamente i volumi di Hetzner Cloud, ma non l'ho ancora provato. Ho studiato soluzioni di storage cloud-defined, perch\u00e9 avevo bisogno di replica e della possibilit\u00e0 di connettere rapidamente volumi persistenti su qualsiasi nodo, soprattutto in caso di guasti dei nodi e situazioni simili. Alcune soluzioni offrono snapshot di momenti specifici e backup off-site, ed \u00e8 molto comodo.<\/p>\n<p><\/p>\n<p>Ho testato 6-7 soluzioni di storage:<\/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>Come ho gi\u00e0 detto <noindex><a rel=\"nofollow\" href=\"http:\/\/vitobotta.com\/2019\/07\/03\/openebs-tips\/\">nel post precedente.<\/a><\/noindex>, dopo aver testato la maggior parte delle opzioni della lista, inizialmente mi sono fermato su OpenEBS. OpenEBS \u00e8 molto semplice da installare e utilizzare, ma, per essere onesto, dopo i test con dati reali sotto carico, le sue prestazioni mi hanno deluso. \u00c8 open source, e gli sviluppatori sul loro <noindex><a rel=\"nofollow\" href=\"https:\/\/openebs-community.slack.com\/\">canale Slack<\/a><\/noindex> sono sempre stati molto d'aiuto quando avevo bisogno di assistenza. Purtroppo, ha prestazioni molto basse rispetto ad altre opzioni, quindi ho dovuto ripetere i test. Attualmente OpenEBS ha 3 motori di archiviazione, ma pubblico i risultati del benchmark per cStor. Al momento non ho dati per Jiva e LocalPV.<\/p>\n<p><\/p>\n<p>In breve, Jiva \u00e8 un po' pi\u00f9 veloce, mentre LocalPV \u00e8 davvero veloce, non peggio di un benchmark diretto del disco. Il problema con LocalPV \u00e8 che l'accesso \u00e8 possibile solo sul nodo in cui \u00e8 stato preparato, e non c'\u00e8 replicazione. Ho avuto alcuni problemi con il ripristino del backup tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/velero.io\/\">Velero<\/a><\/noindex> sul nuovo cluster, perch\u00e9 i nomi dei nodi erano diversi. Parlando di backup, cStor ha <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openebs\/velero-plugin\">un plugin per Velero<\/a><\/noindex>, che consente di effettuare backup off-site degli snapshot a un preciso momento, cosa pi\u00f9 comoda rispetto ai backup a livello di file con Velero-Restic. Ho scritto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/vitobotta\/velero-openebs-backup\">alcuni script<\/a><\/noindex>, per semplificare la gestione delle copie di backup e dei ripristini con questo plugin. In generale, mi piace molto OpenEBS, ma la sua performance...<\/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 ha anche codice sorgente aperto, e si differenzia dagli altri opzioni nella lista per il fatto che \u00e8 un orchestratore di archiviazione, in grado di gestire compiti complessi di gestione dello storage con diversi backend, come ad esempio <noindex><a rel=\"nofollow\" href=\"https:\/\/ceph.io\/\">Ceph<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/edgefs.io\/\">EdgeFS<\/a><\/noindex> e altri, semplificando notevolmente il lavoro. Ho avuto problemi con EdgeFS quando l'ho provato alcuni mesi fa, quindi ho testato principalmente con Ceph. Ceph offre non solo archiviazione di blocchi, ma anche archiviazione di oggetti compatibile con S3\/Swift e un file system distribuito. Ci\u00f2 che mi piace di Ceph \u00e8 la possibilit\u00e0 di distribuire i dati del volume su pi\u00f9 dischi, in modo che il volume possa utilizzare pi\u00f9 spazio di archiviazione di quanto possa contenere un singolo disco. \u00c8 molto comodo. Un'altra funzione utile \u00e8 che, quando aggiungi dischi al cluster, i dati vengono automaticamente ridistribuiti su tutti i dischi.<\/p>\n<p><\/p>\n<p>In Ceph ci sono snapshot, ma, per quanto ne so, non possono essere utilizzati direttamente in Rook\/Kubernetes. In realt\u00e0, non mi sono approfondito. Non ci sono backup off-site, quindi dovr\u00f2 usare qualcosa come Velero\/Restic, ma l\u00ec ci sono solo backup a livello di file e non snapshot a un certo punto nel tempo. Tuttavia, in Rook mi \u00e8 piaciuto molto il lavoro semplice con Ceph: nasconde quasi tutte le cose complesse e offre strumenti per comunicare direttamente con Ceph per la risoluzione dei problemi. Purtroppo, nei test di stress sui volumi Ceph ho sempre avuto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rook\/rook\/issues\/3132\">questo problema<\/a><\/noindex>, che rende Ceph instabile. Non \u00e8 chiaro se sia un bug in Ceph stesso o se sia un problema di come Rook gestisce Ceph. Ho giocato con le impostazioni della memoria e ho notato un miglioramento, ma il problema non \u00e8 completamente risolto. Ceph offre buone prestazioni, come si vede nei benchmark qui sotto. Ha anche un buon pannello di monitoraggio.<\/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>Mi piace molto Longhorn. Penso sia una soluzione promettente. Tuttavia, gli stessi sviluppatori (Rancher Labs) ammettono che attualmente non \u00e8 adatto per un ambiente di produzione, e questo \u00e8 evidente. Ha codice sorgente aperto e buone prestazioni (anche se non si sono ancora occupati dell'ottimizzazione), ma i volumi impiegano molto tempo per collegarsi al pod, e nei casi peggiori ci vogliono dai 15 ai 16 minuti, specialmente dopo il ripristino di un grande backup o l'aggiornamento di un carico di lavoro. Ha snapshot e backup off-site di questi snapshot, ma si applicano solo ai volumi, quindi avrai comunque bisogno di qualcosa come Velero per il backup delle altre risorse. I backup e i ripristini sono molto affidabili, ma incredibilmente lenti. Sul serio, semplicemente ridicolmente lenti. L'uso delle risorse della CPU e il carico di sistema spesso aumentano durante il lavoro con volume di dati medio in Longhorn. C'\u00e8 un comodo pannello di monitoraggio per gestire Longhorn. Ho gi\u00e0 detto che mi piace Longhorn, ma c'\u00e8 bisogno di lavorarci seriamente.<\/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 \u00e8 il primo prodotto a pagamento della lista. Ha una versione per sviluppatori con un limite di capacit\u00e0 di archiviazione gestita di 500 GB, ma, a quanto pare, il numero di nodi non \u00e8 limitato. Nel reparto vendite mi hanno detto che il costo parte da $125 al mese per 1 TB, se ho ricordato bene. C'\u00e8 un pannello di controllo di base e un'interfaccia CLI comoda, ma la prestazione ha qualcosa di strano: in alcuni benchmark \u00e8 piuttosto buona, ma nel test di stress dei volumi la velocit\u00e0 non mi \u00e8 piaciuta affatto. Insomma, non so cosa dire. Perci\u00f2 non mi sono approfondito particolarmente. Non ci sono backup off site e dovr\u00f2 utilizzare Velero con Restic per il backup dei volumi. \u00c8 strano, visto che il prodotto \u00e8 a pagamento. Inoltre, gli sviluppatori non sembrano molto desiderosi di comunicare su Slack.<\/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>Ho scoperto Robin su Reddit dal loro direttore tecnico. Prima non ne avevo mai sentito parlare. Forse perch\u00e9 cercavo soluzioni gratuite, mentre Robin \u00e8 a pagamento. Hanno una versione gratuita piuttosto generosa con 10 TB di spazio di archiviazione e tre nodi. Nel complesso, il prodotto \u00e8 abbastanza valido e con funzionalit\u00e0 piacevoli. Hanno un ottimo CLI, ma la cosa pi\u00f9 interessante \u00e8 che si pu\u00f2 creare snapshot e backup dell'intera applicazione (nel selettore delle risorse \u00e8 chiamato release Helm o \"flex apps\"), inclusi volumi e altre risorse, quindi si pu\u00f2 fare a meno di Velero. E tutto sarebbe fantastico, se non fosse per un piccolo particolare: se si ripristina (o \"importa\", come si dice in Robin) l'applicazione su un nuovo cluster \u2014 ad esempio in caso di ripristino dopo un guasto \u2014 il ripristino funziona, ovviamente, ma non si pu\u00f2 continuare a fare backup dell'applicazione. In questa release \u00e8 semplicemente impossibile, e gli sviluppatori lo hanno confermato. \u00c8, per dirla in modo gentile, strano, soprattutto considerando gli altri vantaggi (ad esempio, backup e ripristini incredibilmente veloci). Gli sviluppatori promettono di risolvere tutto per la prossima release. Le prestazioni, in generale, sono buone, ma ho notato una stranezza: se si esegue un benchmark direttamente su un volume collegato all'host, la velocit\u00e0 di lettura \u00e8 molto pi\u00f9 alta rispetto allo stesso volume, ma dall'interno del pod. Tutti gli altri risultati sono identici, ma in teoria non dovrebbe esserci differenza. Anche se ci stanno lavorando, sono rimasto deluso per il problema con il ripristino e il backup \u2014 mi sembrava di aver finalmente trovato una soluzione adeguata, e ero anche pronto a pagare per essa quando avrei avuto bisogno di pi\u00f9 spazio o pi\u00f9 server.<\/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>Qui non ho molto da dire. \u00c8 un prodotto a pagamento, altrettanto fantastico e costoso. Le prestazioni sono semplicemente straordinarie. Finora \u00e8 il miglior risultato. In Slack mi hanno detto che il prezzo parte da $205 al mese per nodo, come indicato nel Google GKE Marketplace. Non so se sar\u00e0 pi\u00f9 economico se acquisto direttamente. In ogni caso, non posso permettermi una spesa del genere, quindi sono rimasto molto deluso che la licenza sviluppatore (fino a 1 TB e 3 nodi) sia praticamente inutile con Kubernetes, a meno che non ti accontenti di una preparazione statica. Speravo che la licenza aziendale si riducesse automaticamente al livello sviluppatore alla fine del periodo di prova, ma non \u00e8 successo. La licenza sviluppatore pu\u00f2 essere utilizzata solo direttamente con Docker, mentre la configurazione in Kubernetes \u00e8 molto ingombrante e limitata. Certo, preferisco l'open source, ma se avessi i soldi, sceglierei sicuramente Portworx. Finora le sue prestazioni non possono competere con altre opzioni.<\/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>Ho aggiunto questa sezione dopo la pubblicazione del post, quando un lettore ha suggerito di provare Linstor. L'ho provato e mi \u00e8 piaciuto! Ma c'\u00e8 ancora del lavoro da fare. Adesso posso dire che le prestazioni non sono male (ho aggiunto i risultati del benchmark qui sotto). In sostanza, ho ottenuto le stesse prestazioni che avrei avuto con un disco direttamente, senza perdite. (Non chiedetemi perch\u00e9 i numeri di Portworx siano migliori rispetto al benchmark del disco direttamente. Non ne ho idea. Magia, suppongo.) Quindi, Linstor sembra molto efficace. Installarlo non \u00e8 proprio difficile, ma non \u00e8 facile come altre opzioni. All'inizio ho dovuto installare Linstor (modulo del kernel e strumenti\/servizi) e configurare LVM per thin provisioning e supporto agli snapshot al di fuori di Kubernetes, direttamente sull'host, e poi creare le risorse necessarie per utilizzare lo storage da Kubernetes. Non mi \u00e8 piaciuto che non funzionasse su CentOS e ho dovuto usare Ubuntu. Non \u00e8 un grosso problema, ma \u00e8 un po' fastidioso, perch\u00e9 nella documentazione (che tra l'altro \u00e8 ottima) vengono menzionati diversi pacchetti che non si possono trovare nei repository Epel indicati. In Linstor ci sono snapshot, ma non backup off-site, quindi ho dovuto usare di nuovo Velero con Restic per il backup dei volumi. Preferirei snapshot invece di backup a livello di file, ma si pu\u00f2 tollerare se la soluzione \u00e8 performante e affidabile. Linstor \u00e8 open source, ma c'\u00e8 supporto a pagamento. Se ho capito bene, pu\u00f2 essere utilizzato senza limitazioni, anche se non si ha un contratto di supporto, ma questo va verificato. Non so quanto Linstor sia stato testato per Kubernetes, ma il livello di storage \u00e8 esterno a Kubernetes e, a quanto pare, la soluzione non \u00e8 arrivata ieri, quindi probabilmente \u00e8 gi\u00e0 stata testata in ambienti reali. C'\u00e8 una soluzione qui che mi far\u00e0 cambiare idea e tornare a Kubernetes? Non lo so, non lo so. C'\u00e8 ancora bisogno di esplorare, studiare la replicazione. Vedremo. Ma la prima impressione \u00e8 buona. Sicuramente preferirei usare i miei cluster Kubernetes invece di Heroku, per avere pi\u00f9 libert\u00e0 e imparare cose nuove. Dato che l'installazione di Linstor non \u00e8 cos\u00ec semplice come le altre, presto scriver\u00f2 un post su questo.<\/p>\n<p><\/p>\n<h3 id=\"benchmarki\">Benchmark<\/h3>\n<p><\/p>\n<p>Sfortunatamente, ho registrato poche annotazioni sul confronto, perch\u00e9 non ho pensato di scriverne. Ho solo i risultati dei benchmark di base fio e solo per i cluster con un nodo, quindi per le configurazioni replicate non ho ancora numeri. Ma da questi risultati \u00e8 possibile farsi un'idea di cosa aspettarsi da ogni opzione, poich\u00e9 li ho confrontati su server cloud identici, 4 core, 16 GB di RAM, con un disco aggiuntivo da 100 GB per i volumi testati. Ho eseguito i benchmark tre volte per ogni soluzione e ho calcolato il risultato medio, oltre a ripristinare le impostazioni del server per ogni prodotto. Tutto ci\u00f2 non \u00e8 affatto scientifico, serve solo per darvi un'idea generale. In altri test ho copiato 38 GB di foto e video da e su un volume per testare lettura e scrittura, ma sfortunatamente non ho salvato i numeri. In breve: Portworx \u00e8 stato molto pi\u00f9 veloce.<\/p>\n<p><\/p>\n<p>Per il benchmark dei volumi ho usato questo manifesto:<\/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>Prima ho creato un volume con la classe di archiviazione appropriata, poi ho avviato il job con fio in background. Ho scelto 1 GB per stimare le prestazioni e non dover aspettare troppo a lungo. Ecco i risultati:<\/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=\"Storage 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>Ho evidenziato il miglior valore per ciascun indicatore in verde e il peggiore in rosso.<\/p>\n<p><\/p>\n<h3 id=\"zaklyuchenie\">Conclusione<\/h3>\n<p><\/p>\n<p>Come potete vedere, nella maggior parte dei casi Portworx si \u00e8 comportato meglio degli altri. Ma per me \u00e8 costoso. Non so quanto costi Robin, ma hanno una grande versione gratuita, quindi se avete bisogno di un prodotto a pagamento, potete provare (spero che risolvano presto il problema del ripristino e dei backup). Tra i tre gratuiti, ho avuto meno problemi con OpenEBS, anche se le sue prestazioni sono scarse. Peccato non aver salvato pi\u00f9 risultati, ma spero che i numeri forniti e i miei commenti vi possano aiutare.<\/p>\n<p>Fonte: <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\/it\/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=\"it_IT\" \/>\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\/it\/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\udd47Archiviazione in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/37528","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37528"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37528\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28163"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}