{"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":"

\"Storage<\/p>\n

<\/p>\n

Aggiornamento!<\/strong>. Nei commenti, uno dei lettori ha suggerito di provare Linstor<\/a><\/noindex> (forse sta lavorando a questo), cos\u00ec ho aggiunto una sezione su questa soluzione. Inoltre, ho scritto un post su come installarlo<\/a><\/noindex>, perch\u00e9 il processo \u00e8 molto diverso dagli altri.<\/p>\n

<\/p>\n

A dire la verit\u00e0, ho gettato la spugna e ho rinunciato a Kubernetes<\/a><\/noindex> (perlomeno, per ora). Continuer\u00f2 a usare Heroku<\/a><\/noindex>. Perch\u00e9? A causa dello storage! Chi avrebbe mai pensato che avrei passato pi\u00f9 tempo a occuparmi degli storage che di Kubernetes stesso. Sto usando Hetzner Cloud<\/a><\/noindex>, perch\u00e9 \u00e8 economico e le prestazioni sono buone, e fin dall'inizio ho distribuito i cluster usando Rancher<\/a><\/noindex>. Non ho provato i servizi Kubernetes gestiti di Google\/Amazon\/Microsoft\/DigitalOcean e cos\u00ec via, perch\u00e9 volevo imparare tutto da solo. E inoltre, sono piuttosto economico.<\/p>\n

<\/a><\/noindex><\/p>\n

Quindi s\u00ec, ho speso molto tempo cercando di capire quale sistema di storage scegliere mentre valutavo il possibile stack su Kubernetes. Preferisco soluzioni open source, non solo per il prezzo, ma ho anche esplorato un paio di opzioni a pagamento per curiosit\u00e0, poich\u00e9 hanno versioni gratuite con limitazioni. Ho annotato alcuni dati degli ultimi test confrontando diverse opzioni, e potrebbero interessare coloro che studiano lo storage su Kubernetes. Personalmente, per\u00f2, ho gi\u00e0 chiuso con Kubernetes. Vorrei anche menzionare il driver CSI<\/a><\/noindex>, che permette di preparare direttamente i volumi di Hetzner Cloud, ma non lo ho ancora provato. Ho esplorato gli storage definiti tramite software in cloud, poich\u00e9 avevo bisogno di replica e della possibilit\u00e0 di connettere rapidamente volumi persistenti su qualsiasi nodo, specialmente in caso di guasti dei nodi o situazioni simili. Alcune soluzioni offrono snapshot a un certo punto nel tempo e backup off-site, il che \u00e8 molto utile.<\/p>\n

<\/p>\n

Ho testato 6\u20137 soluzioni per lo storage:<\/p>\n

<\/p>\n

OpenEBS<\/a><\/noindex><\/h3>\n

<\/p>\n

Come ho gi\u00e0 detto 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, ad essere sincero, dopo i test con dati reali sotto carico, le sue prestazioni mi hanno deluso. \u00c8 open source, e gli sviluppatori sul loro canale Slack<\/a><\/noindex> sono sempre stati molto d'aiuto quando avevo bisogno di supporto. Sfortunatamente, ha prestazioni molto inferiori rispetto ad altre opzioni, quindi ho dovuto ripetere i test. Attualmente OpenEBS ha 3 motori di storage, ma pubblico i risultati del benchmark per cStor. Non ho ancora dati per Jiva e LocalPV.<\/p>\n

<\/p>\n

In breve, Jiva \u00e8 leggermente pi\u00f9 veloce, mentre LocalPV \u00e8 davvero veloce, non peggio del benchmark del disco direttamente. 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 nel ripristinare un backup tramite Velero<\/a><\/noindex> su un nuovo cluster, perch\u00e9 i nomi dei nodi erano diversi. Parlando di backup, cStor ha un plugin per Velero<\/a><\/noindex>, con cui \u00e8 possibile effettuare backup off-site di snapshot a un determinato punto nel tempo, il che \u00e8 pi\u00f9 comodo rispetto ai backup a livello di file con Velero-Restic. Ho scritto alcuni script<\/a><\/noindex>, \u0447\u0442\u043e\u0431\u044b \u0431\u044b\u043b\u043e \u043f\u0440\u043e\u0449\u0435 \u0443\u043f\u0440\u0430\u0432\u043b\u044f\u0442\u044c \u0431\u044d\u043a\u0430\u043f\u0430\u043c\u0438 \u0438 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f\u043c\u0438 \u0441 \u044d\u0442\u0438\u043c \u043f\u043b\u0430\u0433\u0438\u043d\u043e\u043c. \u0412 \u0446\u0435\u043b\u043e\u043c, \u043c\u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043d\u0440\u0430\u0432\u0438\u0442\u0441\u044f OpenEBS, \u043d\u043e \u0432\u043e\u0442 \u0435\u0433\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c…<\/p>\n

<\/p>\n

Rook<\/a><\/noindex><\/h3>\n

<\/p>\n

Rook ha anche il codice sorgente aperto e si distingue dalle altre opzioni nella lista per essere un orchestratore di storage che gestisce compiti complessi di gestione dello storage con diversi backend, come Ceph<\/a><\/noindex>, EdgeFS<\/a><\/noindex> e altri, il che semplifica notevolmente il lavoro. Ho avuto problemi con EdgeFS quando l'ho provato qualche mese fa, quindi l'ho testato principalmente con Ceph. Ceph offre non solo uno storage a blocchi, ma anche uno storage a oggetti compatibile con S3\/Swift e un file system distribuito. Ci\u00f2 che mi piace di Ceph \u00e8 la possibilit\u00e0 di suddividere i dati del volume su pi\u00f9 dischi, in modo che il volume possa utilizzare pi\u00f9 spazio su disco di quanto possa starci su un singolo disco. Questa \u00e8 una funzionalit\u00e0 utile. Un'altra funzione interessante \u00e8 che quando si aggiungono dischi al cluster, redistribuisce automaticamente i dati su tutti i dischi.<\/p>\n

<\/p>\n

In Ceph ci sono snapshot, ma, per quanto ne so, non possono essere utilizzati direttamente in Rook\/Kubernetes. Tuttavia, non ho approfondito molto. Non ci sono backup off-site, quindi dovr\u00f2 usare qualcosa come Velero\/Restic, ma questi supportano solo backup a livello di file, non snapshot nel momento del tempo. D'altra parte, mi \u00e8 piaciuto molto lavorare con Ceph in Rook \u2014 nasconde quasi tutte le complessit\u00e0 e offre strumenti per interagire direttamente con Ceph per la risoluzione dei problemi. Purtroppo, nella stress test delle volume Ceph, ho riscontrato continuamente questo problema<\/a><\/noindex>, che rende Ceph instabile. Non \u00e8 chiaro se si tratta di un bug in Ceph stesso o di un problema nel modo in cui Rook gestisce Ceph. Ho giocato con le impostazioni della memoria e ci sono stati miglioramenti, ma il problema non \u00e8 completamente risolto. Ceph ha ottime prestazioni, come si pu\u00f2 vedere nei benchmark qui sotto. Inoltre, ha un buon pannello di monitoraggio.<\/p>\n

<\/p>\n

Rancher Longhorn<\/a><\/noindex><\/h3>\n

<\/p>\n

Mi piace molto Longhorn. Penso che sia una soluzione promettente. Tuttavia, gli stessi sviluppatori (Rancher Labs) ammettono che al momento non \u00e8 adatto per ambienti di produzione, e questo \u00e8 evidente. Ha un codice sorgente aperto e buone prestazioni (anche se non si sono ancora occupati dell'ottimizzazione), ma i volumi si collegano molto lentamente al pod, e nei casi peggiori possono richiedere 15\u201316 minuti, specialmente dopo il ripristino di un grande backup o un aggiornamento del 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 lenti oltre ogni limite. L'uso delle risorse della CPU e il carico del sistema spesso aumentano durante la gestione di un volume medio di dati in Longhorn. C'\u00e8 un'interfaccia di monitoraggio intuitiva per gestire Longhorn. Ho gi\u00e0 detto che mi piace Longhorn, ma deve essere migliorato.<\/p>\n

<\/p>\n

StorageOS<\/a><\/noindex><\/h3>\n

<\/p>\n

StorageOS \u00e8 il primo prodotto a pagamento della lista. Esiste una versione per sviluppatori con una capacit\u00e0 di archiviazione gestita limitata a 500 GB, ma il numero di nodi, a quanto pare, non \u00e8 limitato. Nel reparto vendite mi hanno detto che il costo parte da 125 $ al mese per 1 TB, se non ricordo male. C'\u00e8 un pannello di monitoraggio di base e una CLI user-friendly, ma ci sono delle stranezze con le performance: in alcuni benchmark sono abbastanza buone, ma nei test di stress dei volumi non mi sono piaciute per niente. In generale, non so cosa dire. Perci\u00f2 non mi sono nemmeno impegnato a capire bene. Qui non ci sono backup off-site e dovr\u00f2 usare anche Velero con Restic per il backup dei volumi. \u00c8 strano, considerando che il prodotto \u00e8 a pagamento. Inoltre, gli sviluppatori non sembrano essere molto propensi a comunicare su Slack.<\/p>\n

<\/p>\n

Robin<\/a><\/noindex><\/h3>\n

<\/p>\n

Ho scoperto Robin su Reddit grazie al loro CTO. Non ne avevo mai sentito parlare prima, forse perch\u00e9 stavo cercando soluzioni gratuite, mentre Robin \u00e8 a pagamento. Hanno una versione gratuita piuttosto generosa con 10 TB di storage e tre nodi. In generale, il prodotto \u00e8 veramente valido e offre funzionalit\u00e0 interessanti. C'\u00e8 un'ottima interfaccia a riga di comando, ma la cosa migliore \u00e8 la possibilit\u00e0 di creare snapshot e backup dell'intera applicazione (nella selezione delle risorse sono chiamati release di Helm o \"flex apps\"), inclusi volumi e altre risorse, quindi \u00e8 possibile fare a meno di Velero. E tutto sarebbe perfetto se non fosse per un piccolo dettaglio: se si tenta di ripristinare (o \"importare\", come viene chiamato in Robin) l'applicazione su un nuovo cluster, ad esempio in caso di ripristino dopo un guasto, il ripristino funziona, ma non \u00e8 possibile continuare il backup dell'applicazione. In questa release, \u00e8 semplicemente impossibile, e gli sviluppatori lo hanno confermato. \u00c8, per cos\u00ec dire, strano, specialmente considerando gli altri vantaggi (come backup e ripristini incredibilmente rapidi). Gli sviluppatori promettono di risolvere tutto nella prossima release. Le prestazioni, in generale, sono buone, ma ho notato una stranezza: se eseguo un benchmark direttamente sul volume collegato all'host, la velocit\u00e0 di lettura \u00e8 molto superiore a quella dello stesso volume dall'interno del pod. Tutti gli altri risultati sono identici, ma in teoria non ci dovrebbe essere differenza. Anche se stanno lavorando su questo, sono rimasto deluso per il problema con il ripristino e il backup: mi sembrava finalmente di aver trovato una soluzione adatta, e ero addirittura pronto a pagare per essa quando avessi avuto bisogno di pi\u00f9 spazio o di pi\u00f9 server.<\/p>\n

<\/p>\n

Portworx<\/a><\/noindex><\/h3>\n

<\/p>\n

Qui non ho molto da dire. Si tratta di un prodotto a pagamento, di alta qualit\u00e0 e costoso. Le prestazioni sono straordinarie. Finora \u00e8 il miglior indicatore. In Slack mi hanno detto che il prezzo parte da 205 $ al mese per nodo, come indicato nel GKE Marketplace di Google. Non so se ci sar\u00e0 un prezzo inferiore acquistando direttamente. In ogni caso, non posso permettermi una cosa del genere, quindi sono rimasto molto deluso dal fatto che la licenza per sviluppatori (fino a 1 TB e 3 nodi) risulti praticamente inutilizzabile con Kubernetes, a meno che tu non sia soddisfatto di una preparazione statica. Speravo che la licenza aziendale scendesse automaticamente a livello di sviluppatore alla fine del periodo di prova, ma cos\u00ec non \u00e8 stato. La licenza per sviluppatori pu\u00f2 essere utilizzata solo direttamente con Docker, e la configurazione in Kubernetes \u00e8 molto ingombrante e limitata. Certo, preferisco l'open source, ma se avessi i soldi, sceglierei sicuramente Portworx. Fino ad ora, le sue prestazioni non hanno paragoni con altre opzioni.<\/p>\n

<\/p>\n

Linstor<\/a><\/noindex><\/h3>\n

<\/p>\n

Ho aggiunto questa sezione dopo la pubblicazione del post, quando un lettore ha suggerito di provare Linstor. L'ho provato e mi \u00e8 piaciuto! Tuttavia, c'\u00e8 ancora da approfondire. Al momento posso dire che le prestazioni sono buone (i risultati del benchmark sono aggiunti qui sotto). Fondamentalmente, ho ottenuto le stesse prestazioni di un disco direttamente, senza costi aggiuntivi. (Non chiedete perch\u00e9 i numeri di Portworx siano migliori rispetto a quelli del disco diretto. Non ne ho idea. Magia, probabilmente.) Quindi, Linstor sembra essere molto efficace per ora. Non \u00e8 difficile da installare, ma non \u00e8 cos\u00ec facile come le altre opzioni. All'inizio ho dovuto installare Linstor (modulo del kernel e strumenti\/servizi) e configurare LVM per il thin provisioning e supportare gli 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 eccellente) vengono menzionati alcuni pacchetti che non si trovano nei repository Epel indicati. In Linstor ci sono snapshot, ma non backup off-site, quindi qui 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 esiste anche supporto a pagamento. Se ho capito bene, pu\u00f2 essere utilizzato senza restrizioni, anche se non si ha un contratto di supporto, ma \u00e8 meglio chiarirlo. Non so quanto Linstor sia collaudato per Kubernetes, ma il livello di storage \u00e8 al di fuori di Kubernetes e, a quanto pare, la soluzione non \u00e8 recente, quindi probabilmente \u00e8 gi\u00e0 stata testata in condizioni reali. C\u2019\u00e8 una soluzione qui che mi convinca a tornare a Kubernetes? Non lo so, non lo so. \u00c8 necessario esplorare ulteriormente e studiare la replica. Vedremo. Ma la prima impressione \u00e8 positiva. Preferirei sicuramente utilizzare i miei cluster Kubernetes anzich\u00e9 Heroku per avere maggiore libert\u00e0 e imparare cose nuove. Poich\u00e9 Linstor non si installa cos\u00ec facilmente come gli altri, presto scriver\u00f2 un post al riguardo.<\/p>\n

<\/p>\n

Benchmark<\/h3>\n

<\/p>\n

Purtroppo, ho salvato poche registrazioni sulle comparazioni, perch\u00e9 non pensavo che avrei scritto a riguardo. Ho solo i risultati di benchmark di base fio e solo per cluster con un nodo, quindi per configurazioni replicate non ho dati al momento. Tuttavia, da questi risultati si pu\u00f2 avere un'idea approssimativa di cosa aspettarsi da ciascuna 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 ciascuna soluzione e calcolato la media dei risultati, pi\u00f9 ho ripristinato le impostazioni del server per ogni prodotto. Tutto ci\u00f2 non \u00e8 scientifico, ma \u00e8 solo per darvi un'idea generale. In altri test ho copiato 38 GB di foto e video da e su un volume per testare la lettura e la scrittura, ma sfortunatamente non ho salvato i dati. In breve: Portworkx era molto pi\u00f9 veloce.<\/p>\n

<\/p>\n

Per il benchmark dei volumi ho usato questo manifesto:<\/p>\n

<\/p>\n

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>\n
Per prima cosa, ho creato un volume con la classe di archiviazione appropriata e poi ho avviato un job con fio in background. Ho scelto 1 GB per valutare le prestazioni senza dover aspettare troppo a lungo. Ecco i risultati:<\/p>\n
<\/p>\n
\"Storage<\/a><\/noindex><\/p>\n
<\/p>\n
Ho evidenziato il valore migliore per ogni metrica in verde e il peggiore in rosso.<\/p>\n
<\/p>\n
Conclusione<\/h3>\n
<\/p>\n
Come potete vedere, nella maggior parte dei casi Portworx ha dimostrato di essere migliore degli altri. Ma per me \u00e8 costoso. Non so quanto costi Robin, ma c'\u00e8 un'ottima versione gratuita, quindi se avete bisogno di un prodotto a pagamento, potete provarlo (speriamo che risolvano presto il problema con il ripristino e i backup). Tra i tre gratuiti, ho avuto meno problemi con OpenEBS, ma le sue prestazioni sono scarse. Peccato che non abbia salvato pi\u00f9 risultati, ma spero che i numeri e i miei commenti forniti vi siano utili.<\/p>\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\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? […]<\/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\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Storage in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","description":"Aggiornamento! Nei commenti uno dei lettori ha suggerito di provare Linstor (forse lui stesso ci sta lavorando), quindi ho aggiunto una sezione su questa soluzione. Ho anche scritto un post su come installarlo, perch\u00e9 il processo \u00e8 molto diverso dagli altri. A dire il vero, ho gettato la spugna e ho abbandonato Kubernetes (almeno per ora). Utilizzer\u00f2 Heroku. Perch\u00e9?","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:description":"\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?","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"},"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}]}}