{"id":40729,"date":"2020-02-03T14:42:16","date_gmt":"2020-02-03T11:42:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage"},"modified":"2020-02-03T14:42:16","modified_gmt":"2020-02-03T11:42:16","slug":"kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage","title":{"rendered":"Confronto sintetico dell'architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Questo articolo \u00e8 stato scritto per aiutarti a scegliere la soluzione pi\u00f9 adatta e a comprendere le differenze tra SDS come Gluster, Ceph e Vstorage (Virtuozzo).<\/p>\n<p>Nel testo sono presenti collegamenti ad articoli che approfondiscono ulteriormente determinati problemi, pertanto le descrizioni saranno il pi\u00f9 concise possibile, focalizzandosi sui punti chiave senza inutili divagazioni e informazioni introduttive che potrai cercare autonomamente su Internet. <\/p>\n<p>In realt\u00e0, gli argomenti trattati richiedono un certo tono di scrittura, ma nel mondo moderno sempre pi\u00f9 persone non amano leggere molto))), quindi si pu\u00f2 dare una lettura veloce per prendere una decisione, e se qualcosa non \u00e8 chiaro, puoi seguire i link o cercare su Google le parole poco chiare))), e questo articolo funge da involucro trasparente per queste tematiche profonde, mettendo in evidenza i principali punti chiave di ogni soluzione.<\/p>\n<h3>Gluster<\/h3>\n<p>\nIniziamo con Gluster, che \u00e8 ampiamente utilizzato dai produttori di piattaforme iperconvergenti con SDS basato su open source per ambienti virtuali e pu\u00f2 essere trovato sul sito di RedHat nella sezione storage, dove viene offerta la possibilit\u00e0 di scegliere tra due opzioni di SDS: Gluster o Ceph.<\/p>\n<p>Gluster \u00e8 composto da uno stack di traduttori \u2013 servizi che svolgono tutte le operazioni di distribuzione dei file, ecc. Brick \u2013 \u00e8 il servizio che gestisce un singolo disco, Volume \u2013 \u00e8 il volume (pool) che unisce questi brick. Successivamente, c'\u00e8 il servizio di distribuzione dei file in gruppi grazie alla funzione DHT (distributed hash table). Non includeremo la spiegazione del servizio Sharding poich\u00e9 nelle link seguenti sar\u00e0 descritta la problematica ad esso correlata.<\/p>\n<p><img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/0c54588b5b09c9069ffbd0c5161c5e34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuando si scrive, il file viene interamente collocato nel brick e una sua copia viene scritta in parallelo in un brick su un secondo server. Successivamente, un secondo file sar\u00e0 registrato in un secondo gruppo di due brick (o pi\u00f9) su server diversi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex> <br \/>\nSe i file sono di dimensioni simili e il volume consiste solo in un gruppo, va tutto bene, ma in altre condizioni emergono dai descrittivi i seguenti problemi: <\/p>\n<ul>\n<li>lo spazio nei gruppi viene utilizzato in modo non uniforme, a seconda delle dimensioni dei file, e se non c'\u00e8 spazio sufficiente in un gruppo per scrivere un file, riceverai un errore; il file non verr\u00e0 scritto e non verr\u00e0 ridistribuito in un altro gruppo;<\/li>\n<li>durante la scrittura di un file, l'IO avviene solo su un gruppo, mentre gli altri rimangono inattivi;<\/li>\n<li>non \u00e8 possibile ottenere l'IO dell'intero volume durante la scrittura di un singolo file;<\/li>\n<li>e l'intera concezione sembra meno performante a causa dell'assenza di distribuzione dei dati su blocchi, dove \u00e8 pi\u00f9 semplice effettuare il bilanciamento e risolvere il problema della distribuzione uniforme, piuttosto che come ora il file si posi interamente in un brick.<\/li>\n<\/ul>\n<p>\nDalla descrizione ufficiale <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.gluster.org\/en\/latest\/Quick-Start-Guide\/Architecture\/\">architettura<\/a><\/noindex> viene anche involontariamente la comprensione che Gluster funziona come un'archiviazione file sopra un tradizionale RAID hardware. Ci sono stati tentativi di sviluppare la frammentazione (Sharding) dei file in blocchi, ma tutto ci\u00f2 \u00e8 un'aggiunta che comporta perdite di prestazioni al gi\u00e0 esistente approccio architetturale, oltre all'uso di componenti open-source con limitazioni di prestazioni come Fuse. Non ci sono servizi di metadata, il che limita le capacit\u00e0 di prestazioni e resilienza dell'archiviazione durante la distribuzione dei file su blocchi. Risultati di prestazioni migliori possono essere osservati nella configurazione \u201cDistributed Replicated\u201d e il numero di nodi deve essere almeno 6 per organizzare una replica affidabile di 3 con ottimale distribuzione del carico.<\/p>\n<p>Queste conclusioni sono anche correlate alla descrizione dell'esperienza di utilizzo <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/croccloudteam\/blog\/353666\/\">Gluster<\/a><\/noindex> e nel confronto con <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/croccloudteam\/blog\/430474\/\">Ceph<\/a><\/noindex>, ed \u00e8 presente anche una descrizione dell'esperienza che porta alla comprensione di questa configurazione pi\u00f9 performante e pi\u00f9 affidabile <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linux.org.ru\/forum\/general\/13316001\">\u201cReplicated Distributed\u201d.<\/a><\/noindex><br \/>\n<img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/6868ddf69e18bec0b50ae5aeba74440d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNell'immagine \u00e8 mostrata la distribuzione del carico durante la scrittura di due file, dove le copie del primo file sono distribuite tra i primi tre server, che sono riuniti nel volume 0 gruppo, e tre copie del secondo file sono allocate nel secondo gruppo volume1 di tre server. Ogni server ha un disco.<\/p>\n<p>La conclusione generale \u00e8 che Gluster pu\u00f2 essere utilizzato, ma con la consapevolezza che ci saranno limitazioni in termini di prestazioni e resilienza, che creano difficolt\u00e0 in determinate condizioni di soluzioni iper-convergenti, dove le risorse sono necessarie anche per i carichi computazionali degli ambienti virtuali. <\/p>\n<p>Ci sono anche alcuni indicatori di prestazioni di Gluster che possono essere raggiunti in determinate condizioni limitandosi in <noindex><a rel=\"nofollow\" href=\"http:\/\/moo.nac.uci.edu\/~hjm\/Performance_in_a_Gluster_Systemv6F.pdf\"> resilienza.<\/a><\/noindex><\/p>\n<h3>Ceph<\/h3>\n<p>\nOra esaminiamo Ceph dalle descrizioni dell'architettura che sono riuscito a <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/313644\/\">trovare.<\/a><\/noindex> C'\u00e8 anche un confronto tra <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/croccloudteam\/blog\/430474\/\">Glusterfs e Ceph<\/a><\/noindex>, dove si pu\u00f2 subito capire che Ceph \u00e8 preferibile distribuito su server separati, poich\u00e9 i suoi servizi richiedono tutte le risorse dell'hardware in caso di carico. <\/p>\n<p>Architettura <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ceph.com\/docs\/mimic\/architecture\/\">Ceph<\/a><\/noindex> \u00e8 pi\u00f9 complesso di Gluster e ci sono servizi come i servizi di metadata, ma l'intero stack di componenti \u00e8 piuttosto complicato e non molto flessibile per l'uso in soluzioni di virtualizzazione. I dati vengono memorizzati in blocchi, il che sembra pi\u00f9 produttivo, ma ci sono perdite e latenza nella gerarchia di tutti i servizi (componenti) in determinate condizioni di carico e di emergenza, per esempio nel seguente <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/431536\/\">l'articolo.<\/a><\/noindex><\/p>\n<p>Dalla descrizione dell'architettura, il cuore \u00e8 rappresentato da CRUSH, che determina il luogo di memorizzazione dei dati. Successivamente c'\u00e8 PG - questa \u00e8 l'astrazione pi\u00f9 complessa (gruppo logico) da comprendere. I PG sono necessari affinch\u00e9 CRUSH sia pi\u00f9 efficace. L'obiettivo principale dei PG \u00e8 raggruppare gli oggetti per ridurre il consumo di risorse, aumentare le prestazioni e la scalabilit\u00e0. L'indirizzamento diretto di oggetti, singolarmente, senza raggrupparli in PG sarebbe molto costoso. OSD \u00e8 il servizio per ogni singolo disco.<\/p>\n<p><img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/b7d59066a01db9bbb55bbd87c6e5053a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/a86622bc051ab820d42a8aa08a3fc759.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn cluster pu\u00f2 avere uno o pi\u00f9 pool di dati di diversi scopi e con diverse impostazioni. I pool sono suddivisi in placement group. Nelle placement group vengono memorizzati gli oggetti a cui accedono i clienti. A questo livello logico si conclude, e inizia quello fisico, poich\u00e9 a ogni placement group \u00e8 associato un disco principale e diversi dischi replica (quanti dipende dal fattore di replica del pool). In altre parole, a livello logico, un oggetto \u00e8 memorizzato in una specifica placement group, mentre a livello fisico - sui dischi a esso associati. I dischi possono essere fisicamente situati su nodi diversi o persino in data center diversi.<\/p>\n<p>In this scheme, placement groups appear as a necessary level for the flexibility of the entire solution, but at the same time they also act as an unnecessary link in this chain, inevitably raising thoughts about performance loss. For example, when writing data, the system needs to break it down into these groups and then at the physical level onto the main disk and onto the replica disks. This means that the hash function works during the search and insertion of an object, but there is a side effect \u2013 there are very high costs and limitations on restructuring the hash (when adding or removing a disk). Another issue with the hash is its rigid data location, which cannot be changed. So, if a disk is under increased load, the system cannot choose not to write to it (by selecting another disk), because the hash function forces data to be placed according to this rule, regardless of how poorly the disk is performing. Therefore, Ceph uses a lot of memory when restructuring PGs in case of self-healing or storage expansion. The conclusion is that Ceph works well (albeit slowly), but only when there is no scaling, emergency situations, or updates.<\/p>\n<p>There are, of course, options to improve performance through caching and cache tiers, but this requires good hardware, and there will still be losses. Overall, though, Ceph appears more attractive than Gluster for production. Additionally, using these products requires considering an important factor \u2013 a high level of competence, experience, and professionalism with a strong focus on Linux, as it is crucial to deploy, configure, and maintain everything correctly, which places even more responsibility and pressure on the administrator. <\/p>\n<h3>Vstorage<\/h3>\n<p>\nAn even more interesting architecture is seen in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/virtuozzo\/blog\/334724\/\">Virtuozzo storage (Vstorage)<\/a><\/noindex>, which can be used together with the hypervisor on the same nodes, on the same <noindex><a rel=\"nofollow\" href=\"http:\/\/samag.ru\/archive\/article\/3794\">hardware<\/a><\/noindex>, but it is very important to configure everything correctly in order to achieve good performance. This means that deploying such a product straight from the box on any configuration without considering recommendations according to the architecture will be very easy, but not productive.<\/p>\n<p>Cosa pu\u00f2 coesistere per l'archiviazione accanto ai servizi del hypervisor kvm-qemu? Si tratta solo di pochi servizi, dove si trova una gerarchia di componenti ottimale e compatta: il servizio cliente montato tramite FUSE (modificato, non open source), il servizio di metadati MDS (Metadata service) e il servizio di blocchi dati Chunk service, che a livello fisico corrisponde a un disco e questo \u00e8 tutto. Per velocit\u00e0, \u00e8 naturalmente ottimale utilizzare uno schema fault-tolerant in due repliche, ma se si utilizza la cache e i log su dischi SSD, la codifica resistente ai guasti (erase coding o raid6) pu\u00f2 essere significativamente accelerata su uno schema ibrido o anche meglio su all flash. Con EC (erase coding) c'\u00e8 un certo svantaggio: quando un blocco di dati viene modificato, \u00e8 necessario ricalcolare le somme di parit\u00e0. Per evitare perdite in questa operazione, Ceph scrive in EC in modo ritardato e ci possono essere problemi di performance con una certa richiesta, quando ad esempio \u00e8 necessario leggere tutti i blocchi, mentre nel caso di Virtuozzo Storage la registrazione dei blocchi modificati avviene utilizzando l'approccio del 'file system strutturato a log', che minimizza i costi di calcolo della parit\u00e0. Per farsi un'idea approssimativa delle opzioni di accelerazione del lavoro con e senza EC, c'\u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.virtuozzo.com\/products\/virtuozzo-storage\/storage-calculator\">un calcolatore.<\/a><\/noindex> I numeri possono essere approssimativi e dipendono dal coefficiente di precisione del produttore dell'hardware, ma i risultati dei calcoli aiutano a pianificare bene la configurazione.<\/p>\n<p>Uno schema semplice dei componenti di archiviazione non significa che questi componenti non consumino <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.virtuozzo.com\/virtuozzo_7_installation_guide\/preparing-for-installation\/planning-storage-cli.html#hardware-requirements\">risorse hardware,<\/a><\/noindex> ma se si calcolano tutte le spese in anticipo, si pu\u00f2 contare su una cooperazione vicina all'hypervisor. <br \/>\nC'\u00e8 uno schema di confronto del consumo di risorse hardware da parte dei servizi Ceph e Virtuozzo storage.<\/p>\n<p><img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/27de0ab0cc61c2fab6d741bc3105b6cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe in passato confrontare Gluster e Ceph era possibile attraverso vecchi articoli, utilizzando le righe pi\u00f9 importanti di essi, con Virtuozzo \u00e8 pi\u00f9 complicato. Gli articoli su questo prodotto non sono molti e le informazioni possono essere reperite solo dalla documentazione su <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.virtuozzo.com\/master\/index.html\">inglese<\/a><\/noindex> o in russo se si considera Vstorage come storage utilizzato in alcune soluzioni iperconvergenti in aziende come <noindex><a rel=\"nofollow\" href=\"http:\/\/rosplatforma.ru\/#downloads\">Rospatforma<\/a><\/noindex> e Acronis.<\/p>\n<p>Cercher\u00f2 di aiutarti a descrivere questa architettura, quindi il testo sar\u00e0 un po' pi\u00f9 lungo, ma per capire la documentazione ci vorr\u00e0 molto tempo, e la documentazione esistente pu\u00f2 essere utilizzata solo come riferimento consultando l'indice o ricercando parole chiave. <\/p>\n<p>Prendiamo in considerazione il processo di scrittura in una configurazione ibrida dell'hardware con i componenti descritti sopra: la scrittura inizia sul nodo da cui \u00e8 stata avviata dal client (servizio di punto di montaggio FUSE), ma il componente master del servizio metadati (MDS) ovviamente indirizzer\u00e0 il client direttamente al servizio di chunk necessario (servizio di archiviazione blocchi CS), cio\u00e8 il MDS non partecipa al processo di scrittura, ma semplicemente guida al servizio di chunk richiesto. In generale, si pu\u00f2 fare un'analogia della scrittura con il versamento dell'acqua in botti. Ogni botte \u00e8 un blocco di dati di 256 MB.<\/p>\n<p><img decoding=\"async\" alt=\"Confronto sintetico dell&#039;architettura SDS o ricerca di una piattaforma di archiviazione appropriata (GlusterVsCephVsVirtuozzoStorage)\" src=\"\/wp-content\/uploads\/2020\/02\/8f10333f1573226fbb50a40377eafc93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuindi un disco \u00e8 un certo numero di queste botti, ovvero la capacit\u00e0 del disco divisa per 256 MB. Ogni copia viene versata su un nodo, la seconda quasi parallelamente su un altro nodo, ecc... Se abbiamo tre repliche e ci sono dischi SSD, per la cache (per lettura e registrazione dei log), la conferma della scrittura avverr\u00e0 dopo che il log \u00e8 stato scritto su SSD, e lo scarico parallelo da SSD continuer\u00e0 su HDD, come in modalit\u00e0 background. Nel caso di tre repliche, il commit della scrittura avverr\u00e0 dopo la conferma dall'SSD del terzo nodo. Potrebbe sembrare che la somma della velocit\u00e0 di scrittura dei tre SSD possa essere divisa per tre, ottenendo cos\u00ec la velocit\u00e0 di scrittura di una singola replica, ma la scrittura delle copie avviene in parallelo e la latenza della rete \u00e8 generalmente superiore a quella degli SSD, pertanto la prestazione di scrittura dipender\u00e0 dalla rete. Di conseguenza, per vedere reali IOPS \u00e8 necessario caricare correttamente l'intero Vstorage secondo <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.virtuozzo.com\/pdf\/virtuozzo_infrastructure_platform_3_benchmarking_guide.pdf\">il metodo<\/a><\/noindex>, cio\u00e8 testare il carico reale, e non la memoria e la cache, dove \u00e8 necessario considerare la giusta dimensione del blocco dati, il numero di thread, ecc. <\/p>\n<p>Il registro menzionato sopra su SSD funziona in modo tale che non appena i dati vengono inseriti, vengono immediatamente letti dal servizio e scritti su HDD. Ci sono pi\u00f9 servizi di metadati (MDS) per cluster e il loro numero \u00e8 definito dal quorum che opera secondo l'algoritmo Paxos. Dal punto di vista del cliente, il punto di montaggio FUSE \u00e8 una cartella di storage del cluster visibile a tutti i nodi. Ogni nodo ha un client montato in questo modo, quindi questo storage \u00e8 accessibile a ciascun nodo.<\/p>\n<p>Per le prestazioni di uno qualsiasi degli approcci sopra descritti, \u00e8 fondamentale, nella fase di pianificazione e implementazione, configurare correttamente la rete, dove ci sar\u00e0 un bilanciamento tramite aggregazione e una larghezza di banda di rete adeguatamente selezionata. Nell'aggregazione, \u00e8 importante adeguare correttamente la modalit\u00e0 di hashing e le dimensioni dei frame. C'\u00e8 anche una differenza significativa rispetto agli SDS descritti sopra, con FUSE e la tecnologia fast path in Virtuozzo Storage. A differenza delle altre soluzioni open source, questa offre un FUSE modernizzato che aumenta significativamente gli IOPS e consente di non limitarsi alla scalabilit\u00e0 orizzontale o verticale. In generale, rispetto alle architetture descritte, questa appare pi\u00f9 potente, ma per tale beneficio \u00e8 necessario acquistare licenze, a differenza di Ceph e Gluster. <\/p>\n<p>In sintesi, il podio delle architetture per prestazioni e affidabilit\u00e0 vede al primo posto Virtuozzo Storage, al secondo Ceph e al terzo Gluster. <\/p>\n<p>I criteri che hanno portato alla scelta di Virtuozzo Storage sono un insieme ottimale di componenti architetturali, un FUSE modernizzato con fast path, un set di configurazione hardware flessibile, minore consumo di risorse e la possibilit\u00e0 di condivisione con le attivit\u00e0 computazionali (virtualizzazione), rendendolo perfettamente idoneo per una soluzione iperconvergente, di cui fa parte. Al secondo posto Ceph, poich\u00e9 \u00e8 un'architettura pi\u00f9 performante rispetto a Gluster, grazie alla gestione di blocchi e a scenari pi\u00f9 flessibili, oltre alla possibilit\u00e0 di operare in cluster di maggiori dimensioni.<\/p>\n<p>Nel piano c'\u00e8 la volont\u00e0 di scrivere un confronto tra vSAN, Space Direct Storage, Vstorage e Nutanix Storage, testando Vstorage su hardware HPE, Huawei, oltre a scenari di integrazione di Vstorage con sistemi di archiviazione esterni. Quindi, se ti \u00e8 piaciuto l'articolo, sarebbe utile ricevere i tuoi feedback, che potrebbero rafforzare la motivazione per nuovi articoli tenendo conto delle tue osservazioni e desideri.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/486392\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0430 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043c\u043e\u0447\u044c \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0438 \u043f\u043e\u043d\u044f\u0442\u044c \u043e\u0442\u043b\u0438\u0447\u0438\u044f \u043c\u0435\u0436\u0434\u0443 \u0442\u0430\u043a\u0438\u043c\u0438 SDS \u043a\u0430\u043a Gluster, Ceph \u0438 Vstorage (Virtuozzo). \u0412 \u0442\u0435\u043a\u0441\u0442\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0441\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0441\u0442\u0430\u0442\u044c\u0438 \u0441 \u0431\u043e\u043b\u0435\u0435 \u0434\u0435\u0442\u0430\u043b\u044c\u043d\u044b\u043c \u0440\u0430\u0441\u043a\u0440\u044b\u0442\u0438\u0435\u043c \u0442\u0435\u0445 \u0438\u043b\u0438 \u0438\u043d\u044b\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u0431\u0443\u0434\u0443\u0442 \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043a\u0440\u0430\u0442\u043a\u0438\u043c\u0438 \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043a\u043b\u044e\u0447\u0435\u0432\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u043e\u0432 \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0435\u0439 \u0432\u043e\u0434\u044b \u0438 \u0432\u0432\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0432\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40730,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0430 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043c\u043e\u0447\u044c \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0438 \u043f\u043e\u043d\u044f\u0442\u044c \u043e\u0442\u043b\u0438\u0447\u0438\u044f \u043c\u0435\u0436\u0434\u0443 \u0442\u0430\u043a\u0438\u043c\u0438 SDS \u043a\u0430\u043a Gluster, Ceph \u0438 Vstorage (Virtuozzo). \u0412 \u0442\u0435\u043a\u0441\u0442\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0441\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0441\u0442\u0430\u0442\u044c\u0438 \u0441 \u0431\u043e\u043b\u0435\u0435.\" \/>\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\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage\" \/>\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\u041a\u0440\u0430\u0442\u043a\u043e\u0435 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b SDS \u0438\u043b\u0438 \u043f\u043e\u0438\u0441\u043a \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f (GlusterVsCephVsVirtuozzoStorage) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0430 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043c\u043e\u0447\u044c \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0438 \u043f\u043e\u043d\u044f\u0442\u044c \u043e\u0442\u043b\u0438\u0447\u0438\u044f \u043c\u0435\u0436\u0434\u0443 \u0442\u0430\u043a\u0438\u043c\u0438 SDS \u043a\u0430\u043a Gluster, Ceph \u0438 Vstorage (Virtuozzo). \u0412 \u0442\u0435\u043a\u0441\u0442\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0441\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0441\u0442\u0430\u0442\u044c\u0438 \u0441 \u0431\u043e\u043b\u0435\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage\" \/>\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=\"2020-02-03T11:42:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-03T11:42:16+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\udd47 Confronto rapido dell'architettura SDS o ricerca della piattaforma di archiviazione adatta (GlusterVsCephVsVirtuozzoStorage) | ProHoster","description":"Questo articolo \u00e8 stato scritto per aiutarti a scegliere la soluzione pi\u00f9 adatta e comprendere le differenze tra SDS come Gluster, Ceph e Vstorage (Virtuozzo). Nel testo sono incluse delle riferimenti a articoli pi\u00f9 approfonditi.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage","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\u041a\u0440\u0430\u0442\u043a\u043e\u0435 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b SDS \u0438\u043b\u0438 \u043f\u043e\u0438\u0441\u043a \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f (GlusterVsCephVsVirtuozzoStorage) | ProHoster","og:description":"\u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0430 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043c\u043e\u0447\u044c \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u0438 \u043f\u043e\u043d\u044f\u0442\u044c \u043e\u0442\u043b\u0438\u0447\u0438\u044f \u043c\u0435\u0436\u0434\u0443 \u0442\u0430\u043a\u0438\u043c\u0438 SDS \u043a\u0430\u043a Gluster, Ceph \u0438 Vstorage (Virtuozzo). \u0412 \u0442\u0435\u043a\u0441\u0442\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0441\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0441\u0442\u0430\u0442\u044c\u0438 \u0441 \u0431\u043e\u043b\u0435\u0435.","og:url":"https:\/\/prohoster.info\/it\/blog\/kratkoe-sravnenie-arhitektury-sds-ili-poisk-podhodyashhej-platformy-hraneniya-glustervscephvsvirtuozzostorage","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":"2020-02-03T11:42:16+00:00","article:modified_time":"2020-02-03T11:42:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40729","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:32:40","updated":"2022-09-29 09:23:33","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\/40729","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=40729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/40729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/40730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=40729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=40729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=40729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}