{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Soluzione iperconvergente AERODISK vAIR. Alla base c'\u00e8 il file system ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Soluzione<\/p>\n

<\/p>\n

Ciao, lettori di Habr. Con questo articolo inauguriamo un ciclo dedicato al sistema iperconvergente AERODISK vAIR, da noi sviluppato. Inizialmente volevamo spiegare tutto nella prima articolo, ma la struttura \u00e8 piuttosto complessa, quindi ci occuperemo di essa a pezzettini. <\/p>\n

<\/p>\n

Cominceremo raccontando la storia della creazione del sistema, approfondendo il file system ARDFS, che \u00e8 alla base di vAIR, e discuteremo un po' del posizionamento di questa soluzione sul mercato russo. <\/p>\n

<\/p>\n

Negli articoli futuri parleremo pi\u00f9 in dettaglio dei diversi componenti architettonici (cluster, hypervisor, bilanciatore di carico, sistema di monitoraggio, ecc.), del processo di configurazione, affronteremo le questioni relative alle licenze, mostreremo separatamente i crash test e, naturalmente, discuteremo sul load testing e sul sizing. Dedicaremo anche un articolo alla versione community di vAIR.<\/p>\n

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

AERODISK \u00e8 una sorta di storia sulle storage system? O perch\u00e9 abbiamo iniziato a occuparci di hyperconvergenza?<\/h2>\n

<\/p>\n

L'idea di creare un nostro sistema iperconvergente \u00e8 nata intorno al 2010. All'epoca non c'erano n\u00e9 Aerodisk n\u00e9 soluzioni simili (sistemi iperconvergenti commerciali) sul mercato. Il nostro obiettivo era: a partire da un insieme di server con dischi locali, interconnessi tramite protocollo Ethernet, creare uno storage distribuito e avviare virtual machines e una rete software. Tutto ci\u00f2 doveva essere realizzato senza un sistema di storage (poich\u00e9 non avevamo i fondi per un SAN, e all'epoca non avevamo ancora inventato il nostro).<\/p>\n

<\/p>\n

Abbiamo provato molte soluzioni open source e alla fine abbiamo risolto il problema, ma la soluzione era molto complessa e difficile da replicare. Inoltre, era una di quelle soluzioni del tipo \"Funziona? Non toccare!\". Pertanto, dopo aver risolto quel problema, abbiamo deciso di non sviluppare ulteriormente l'idea di trasformare il risultato del nostro lavoro in un prodotto completo. <\/p>\n

<\/p>\n

Dopo quell'episodio ci siamo allontanati da questa idea, ma ci sentivamo comunque convinti che il problema fosse risolvibile e i benefici di tale soluzione fossero pi\u00f9 che evidenti. In seguito, i prodotti HCI delle aziende straniere hanno solo confermato questa sensazione. <\/p>\n

<\/p>\n

Nel corso del 2016, siamo tornati a questo compito nell'ambito della creazione di un prodotto completo. All'epoca non avevamo alcuna relazione con gli investitori, quindi ci siamo trovati a dover acquistare la nostra attrezzatura per lo sviluppo con fondi piuttosto limitati. Abbiamo cercato server e switch usati su Avito e ci siamo messi al lavoro.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Il nostro obiettivo iniziale era creare un file system, anche se semplice, ma di nostra propriet\u00e0, capace di distribuire automaticamente e uniformemente i dati in frammenti virtuali su un numero variabile di nodi nel cluster, interconnessi tramite Ethernet. Il file system doveva essere facilmente scalabile e indipendente da altri sistemi, cio\u00e8 doveva operare come un semplice sistema di archiviazione.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

La prima concezione di vAIR<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Abbiamo scelto di non utilizzare soluzioni open source preconfezionate per creare uno storage distribuito (come Ceph, Gluster, Lustre e simili) a favore del nostro sviluppo, dato che avevamo gi\u00e0 accumulato molta esperienza progettuale con esse. Certamente, queste soluzioni sono eccellenti di per s\u00e9, e prima di lavorare su Aerodisk abbiamo realizzato diversi progetti di integrazione con esse. Tuttavia, c\u2019\u00e8 una grande differenza tra soddisfare le esigenze specifiche di un cliente, formare il personale e, eventualmente, acquistare supporto da un grande fornitore, e l\u2019ideazione di un prodotto scalabile che possa essere utilizzato per diverse applicazioni, che potremmo persino non conoscere come fornitori. Per quest'ultimo scopo, i prodotti open source esistenti non erano adatti, quindi abbiamo deciso di sviluppare noi stessi un sistema di file distribuiti.
\nDopo due anni, un gruppo di sviluppatori (che combinavano il lavoro su vAIR con lo sviluppo di storage tradizionali Engine) ha raggiunto dei risultati concreti.<\/p>\n

<\/p>\n

Entro il 2018 abbiamo sviluppato un semplice file system e lo abbiamo completato con l'interfaccia necessaria. Il sistema combinava i dischi fisici (locali) di diversi server in un unico pool piatto tramite un'interconnessione interna e li 'segmentava' in blocchi virtuali, dai quali venivano creati dispositivi a blocchi con vari livelli di tolleranza ai guasti, sui quali venivano create ed eseguite macchine virtuali tramite l'hypervisor KVM. <\/p>\n

<\/p>\n

Non ci siamo particolarmente preoccupati del nome del file system e l'abbiamo chiamato ARDFS (indovinate cosa significa))<\/p>\n

<\/p>\n

Questo prototipo sembrava valido (non visivamente, naturalmente, poich\u00e9 non c'era ancora un'interfaccia grafica) e mostrava buoni risultati in termini di prestazioni e scalabilit\u00e0. Dopo il primo risultato reale, abbiamo dato il via a questo progetto, organizzando un ambiente di sviluppo completo e un team separato che si occupava solo di vAIR.<\/p>\n

<\/p>\n

Proprio in quel periodo \u00e8 stata sviluppata l'architettura generale della soluzione, che non ha subito cambiamenti significativi fino ad oggi.<\/p>\n

<\/p>\n

Entriamo nel file system ARDFS<\/h2>\n

<\/p>\n

ARDFS \u00e8 alla base di vAIR, che fornisce uno storage dati distribuito e resiliente per l'intero cluster. Una delle (ma non l'unica) caratteristiche distintive di ARDFS \u00e8 che non richiede alcun ulteriore di server dedicati<\/a> sotto meta e gestione. Questo \u00e8 stato progettato fin dall'inizio per semplificare la configurazione della soluzione e garantirne l'affidabilit\u00e0. <\/p>\n

<\/p>\n

Struttura di archiviazione<\/h3>\n

<\/p>\n

All'interno di tutti i nodi del cluster, ARDFS organizza un pool logico di tutto lo spazio disco disponibile. \u00c8 importante comprendere che il pool non \u00e8 ancora dati n\u00e9 spazio formattato, ma semplicemente un markup; quindi, qualsiasi nodo con vAIR installato, quando aggiunto al cluster, viene automaticamente incluso nel pool comune di ARDFS e le risorse disco diventano automaticamente condivise per l'intero cluster (e disponibili per la futura archiviazione dei dati). Questo approccio consente di aggiungere e rimuovere nodi al volo senza alcun serio impatto sul sistema gi\u00e0 in funzionamento. Vale a dire, il sistema \u00e8 molto facile da scalare a \"mattoncini\", aggiungendo o rimuovendo nodi nel cluster secondo necessit\u00e0.<\/p>\n

<\/p>\n

Sopra il pool ARDFS si aggiungono dischi virtuali (oggetti di archiviazione per le macchine virtuali), costruiti da blocchi virtuali di dimensione 4 megabyte. I dati vengono archiviati direttamente sui dischi virtuali. A livello dei dischi virtuali viene anche definito lo schema di tolleranza ai guasti. <\/p>\n

<\/p>\n

Come si poteva gi\u00e0 dedurre, per la tolleranza ai guasti del sottosistema di archiviazione non utilizziamo il concetto di RAID (Redundant array of independent Disks), ma utilizziamo RAIN (Redundant array of independent Nodes). Cio\u00e8, la tolleranza ai guasti viene misurata, automatizzata e gestita in base ai nodi, non ai dischi. I dischi, ovviamente, sono anch'essi oggetti di archiviazione, vengono monitorati come tutto il resto e si possono eseguire tutte le operazioni standard, incluso la creazione di un RAID hardware locale, ma il cluster opera effettivamente su nodi. <\/p>\n

<\/p>\n

In situazioni in cui si desidera un RAID (ad esempio, uno scenario che supporta guasti multipli su piccoli cluster), non c'\u00e8 nulla che impedisca di utilizzare controller RAID locali, implementando sopra uno storage espanso e un'architettura RAIN. Tale scenario \u00e8 del tutto valido e supportato da noi, quindi ne parleremo nell'articolo sui casi d'uso standard di vAIR.<\/p>\n

<\/p>\n

Schemi di tolleranza ai guasti dello storage<\/h3>\n

<\/p>\n

Ci possono essere due schemi di tolleranza ai guasti dei dischi virtuali in vAIR:<\/p>\n

<\/p>\n

1) Il fattore di replica, o semplicemente replica, \u00e8 un metodo di tolleranza ai guasti semplice \"come un bastone e una corda\". Viene eseguita la replica sincronizzata tra i nodi con un fattore di 2 (2 copie nel cluster) o 3 (3 copie, rispettivamente). L'RF-2 consente al disco virtuale di mantenere il servizio anche in caso di guasto di un nodo nel cluster, ma \"consuma\" met\u00e0 della capacit\u00e0 utile, mentre l'RF-3 tollerar\u00e0 il guasto di 2 nodi nel cluster, ma riserva gi\u00e0 2\/3 della capacit\u00e0 utile per i propri bisogni. Questo schema ricorda molto RAID-1, ovvero un disco virtuale configurato in RF-2 \u00e8 resistente al guasto di un qualsiasi nodo del cluster. In questo caso, i dati saranno al sicuro e anche le operazioni di input-output non si fermeranno. Quando il nodo guasto sar\u00e0 di nuovo operativo, inizier\u00e0 il ripristino\/sincronizzazione automatica dei dati. <\/p>\n

<\/p>\n

Di seguito sono riportati esempi di distribuzione dei dati RF-2 e RF-3 in condizioni normali e in situazioni di guasto.<\/p>\n

<\/p>\n

Abbiamo una macchina virtuale con 8 MB di dati unici (utili) che opera su 4 nodi vAIR. \u00c8 chiaro che nella realt\u00e0 \u00e8 improbabile avere un volume cos\u00ec ridotto, ma per rappresentare la logica di funzionamento di ARDFS, questo esempio \u00e8 il pi\u00f9 chiaro. AB rappresenta blocchi virtuali da 4 MB contenenti dati unici della macchina virtuale. Con RF-2, vengono create due copie di questi blocchi A1+A2 e B1+B2, rispettivamente. Questi blocchi vengono \"distribuiti\" tra i nodi, evitando la sovrapposizione degli stessi dati su un nodo, ovvero la copia A1 non si trover\u00e0 mai sullo stesso nodo della copia A2. Lo stesso vale per B1 e B2.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

In caso di guasto di uno dei nodi (ad esempio, il nodo n. 3, dove si trova la copia B1), questa copia verr\u00e0 automaticamente attivata su un nodo dove non \u00e8 presente la copia della sua copia (cio\u00e8 la copia B2). <\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Cos\u00ec, il disco virtuale (e la VM, di conseguenza) facilmente superer\u00e0 il guasto di un nodo nello schema RF-2.<\/p>\n

<\/p>\n

Lo schema di replicazione, nonostante la sua semplicit\u00e0 e affidabilit\u00e0, presenta lo stesso problema del RAID1: poco spazio utile.<\/p>\n

<\/p>\n

2) L'erasure coding o codifica di cancellazione (noto anche come \u00abcodifica ridondante\u00bb, \u00abcodifica di cancellazione\u00bb o \u00abcodice di ridondanza\u00bb) esiste proprio per risolvere il problema sopra. EC \u00e8 uno schema di ridondanza che garantisce un'alta disponibilit\u00e0 dei dati con minori costi di spazio su disco rispetto alla replica. Il principio di funzionamento di questo meccanismo \u00e8 simile a RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Nel processo di codifica, l'EC divide un blocco virtuale (di default 4 MB) in pi\u00f9 \u00abpezzi di dati\u00bb a seconda dello schema EC (ad esempio, lo schema 2+1 divide ogni blocco da 4 MB in 2 pezzi da 2 MB). Successivamente, il processo genera per i \u00abpezzi di dati\u00bb dei \u00abpezzi di parit\u00e0\u00bb di dimensioni non superiori a una delle parti precedentemente divise. Durante la decodifica, l'EC genera i pezzi mancanti leggendo i dati \u00absopravvissuti\u00bb nell'intero cluster. <\/p>\n

<\/p>\n

Ad esempio, un disco virtuale con schema EC 2 + 1, implementato su 4 nodi del cluster, pu\u00f2 facilmente sopportare il guasto di un nodo nel cluster cos\u00ec come fa RF-2. Allo stesso tempo, le spese generali saranno inferiori, con un coefficiente di capacit\u00e0 utile di 2 per RF-2, mentre per EC 2+1 sar\u00e0 1,5. <\/p>\n

<\/p>\n

In parole semplici, la questione fondamentale \u00e8 che un blocco virtuale viene suddiviso in 2-8 \"pezzi\" (perch\u00e9 da 2 a 8, vedi sotto), e per questi pezzi vengono calcolati i \u201cpezzi\u201d di parit\u00e0 di corrispondente volume. <\/p>\n

<\/p>\n

Di conseguenza, i dati e la parit\u00e0 vengono distribuiti uniformemente tra tutti i nodi del cluster. In questo modo, proprio come nella replica, ARDFS distribuisce automaticamente i dati tra i nodi in modo da evitare che dati identici (copia dei dati e parit\u00e0) si trovino su un unico nodo, escludendo cos\u00ec la possibilit\u00e0 di perdere dati a causa della coincidenza di dati e parit\u00e0 su un nodo di archiviazione che potrebbe guastarsi. <\/p>\n

<\/p>\n

Di seguito un esempio, con la stessa macchina virtuale di 8 MB e 4 nodi, ma gi\u00e0 con lo schema EC 2+1. <\/p>\n

<\/p>\n

I blocchi A e B vengono suddivisi in due parti da 2 MB ciascuna (due perch\u00e9 2+1), quindi in A1+A2 e B1+B2. A differenza della replica, A1 non \u00e8 una copia di A2, ma \u00e8 un blocco virtuale A suddiviso in due parti, lo stesso vale per il blocco B. In totale otteniamo due set da 4 MB, ognuno dei quali contiene due pezzi da due megabyte. Successivamente, per ciascuno di questi set viene calcolata la parit\u00e0, che ha una dimensione massima di un pezzo (cio\u00e8 2 MB), ottenendo cos\u00ec ulteriori 2 pezzi di parit\u00e0 (A-P e B-P). In totale abbiamo 4\u00d72 dati + 2\u00d72 parit\u00e0.<\/p>\n

<\/p>\n

Successivamente, i pezzi vengono \"distribuiti\" tra i nodi in modo tale che i dati non si sovrappongano alla loro parit\u00e0. Cio\u00e8, A1 e A2 non si troveranno nello stesso nodo di A-P.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

In caso di guasto di un nodo (supponiamo, il terzo), il blocco B1 andato perso verr\u00e0 automaticamente ripristinato dalla parit\u00e0 B-P, che \u00e8 memorizzata nel nodo n\u00b02, e verr\u00e0 attivato in un nodo dove non \u00e8 presente la parit\u00e0 B, cio\u00e8 il pezzo B-P. In questo esempio, si tratta del nodo n\u00b01.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Sono sicuro che il lettore si star\u00e0 chiedendo:<\/p>\n

<\/p>\n

\u00abTutto ci\u00f2 che hai descritto \u00e8 gi\u00e0 stato implementato dai concorrenti e nelle soluzioni open source, qual \u00e8 la differenza della vostra implementazione EC in ARDFS?\u00bb<\/p><\/blockquote>\n

E poi seguiranno le interessanti peculiarit\u00e0 del funzionamento di ARDFS.<\/p>\n

<\/p>\n

Erasure coding con focus sulla flessibilit\u00e0<\/h3>\n

<\/p>\n

Inizialmente abbiamo previsto uno schema EC X+Y piuttosto flessibile, dove X varia da 2 a 8 e Y da 1 a 8, ma sempre inferiore o uguale a X. Questo schema \u00e8 studiato per garantire flessibilit\u00e0. Aumentare il numero di pezzi di dati (X) in cui \u00e8 suddiviso un blocco virtuale consente di ridurre le spese generali, aumentando cos\u00ec lo spazio utile.
\nAumentare invece il numero di pezzi di parit\u00e0 (Y) aumenta l'affidabilit\u00e0 del disco virtuale. Maggiore \u00e8 il valore di Y, pi\u00f9 nodi nel cluster possono guastarsi. Naturalmente, un aumento del volume della parit\u00e0 riduce la capacit\u00e0 utile, ma \u00e8 un sacrificio necessario per avere maggiore affidabilit\u00e0. <\/p>\n

<\/p>\n

La dipendenza delle prestazioni dagli schemi EC \u00e8 quasi diretta: pi\u00f9 \"pezzi\" ci sono, minori sono le prestazioni; qui, chiaramente, \u00e8 necessaria una visione equilibrata. <\/p>\n

<\/p>\n

Questo approccio consente agli amministratori di configurare in modo flessibile lo storage distribuito. All'interno del pool ARDFS \u00e8 possibile utilizzare qualsiasi schema di tolleranza ai guasti e le loro combinazioni, cosa che consideriamo molto utile. <\/p>\n

<\/p>\n

Di seguito \u00e8 riportata una tabella di confronto di diversi (non tutti possibili) schemi RF ed EC.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

La tabella mostra che anche la combinazione pi\u00f9 \"robusta\" EC 8+7, che consente la perdita fino a 7 nodi in un cluster, occupa meno spazio utile (1,875 contro 2) rispetto alla replica standard, ma offre una protezione sette volte superiore. Questo rende il meccanismo di protezione, sebbene pi\u00f9 complesso, notevolmente pi\u00f9 attraente in situazioni in cui \u00e8 necessario garantire la massima affidabilit\u00e0 in caso di mancanza di spazio su disco. \u00c8 importante capire che ogni \"pi\u00f9\" a X o Y comporta un costo aggiuntivo in termini di prestazioni, quindi nel triangolo tra affidabilit\u00e0, economia e prestazioni, \u00e8 fondamentale scegliere con molta attenzione. Per questa ragione, dedicheremo un articolo separato al sizing della codifica rimovibile.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Affidabilit\u00e0 e autonomia del file system<\/h3>\n

<\/p>\n

ARDFS viene eseguito localmente su tutti i nodi del cluster e li sincronizza tramite interfacce Ethernet dedicate. Un aspetto importante \u00e8 che ARDFS sincronizza autonomamente non solo i dati, ma anche i metadati relativi allo storage. Durante lo sviluppo di ARDFS, abbiamo esaminato parallelamente diverse soluzioni esistenti e abbiamo scoperto che molte di esse effettuano la sincronizzazione dei metadati del file system utilizzando un DBMS distribuito esterno, che usiamo anche per la sincronizzazione, ma solo per le configurazioni, non per i metadati del FS (di questo e di altri sistemi correlati parleremo nel prossimo articolo). <\/p>\n

<\/p>\n

La sincronizzazione dei metadati del FS utilizzando un DBMS esterno \u00e8 sicuramente una soluzione funzionante, ma in tal caso la coerenza dei dati memorizzati su ARDFS dipenderebbe dal DBMS esterno e dal suo comportamento (che, a dirla tutta, \u00e8 una signora piuttosto capricciosa), il che, a nostro avviso, \u00e8 un aspetto negativo. Perch\u00e9? Se i metadati del FS vengono danneggiati, si potrebbe dire addio anche ai dati stessi del FS, quindi abbiamo deciso di intraprendere un percorso pi\u00f9 complesso ma affidabile. <\/p>\n

<\/p>\n

Abbiamo sviluppato autonomamente il sottosistema di sincronizzazione dei metadati per ARDFS, che opera in assoluta indipendenza rispetto ai sottosistemi adiacenti. Nessun altro sottosistema pu\u00f2 danneggiare i dati di ARDFS. A nostro avviso, questa \u00e8 la soluzione pi\u00f9 affidabile e corretta; solo il tempo dir\u00e0 se sia veramente cos\u00ec. Inoltre, questo approccio porta con s\u00e9 un ulteriore vantaggio. ARDFS pu\u00f2 essere utilizzato in modo indipendente da vAIR, semplicemente come uno storage esteso, un'opzione che sicuramente utilizzeremo nei nostri prodotti futuri.<\/p>\n

<\/p>\n

Di conseguenza, sviluppando ARDFS, abbiamo ottenuto un file system flessibile e affidabile, che offre la scelta di risparmiare sulla capacit\u00e0 o di dedicare tutto alle prestazioni, oppure di rendere lo storage super affidabile a un costo moderato, riducendo al contempo le esigenze prestazionali. <\/p>\n

<\/p>\n

Insieme a una politica di licenza semplice e a un modello di fornitura flessibile (anticipando che la licenza di vAIR \u00e8 basata sui nodi e viene fornita sia come software che come PAC), questo consente di adattare con precisione la soluzione alle diverse esigenze dei clienti, mantenendo facilmente questo equilibrio in futuro. <\/p>\n

<\/p>\n

A chi serve questa meraviglia?<\/h2>\n

<\/p>\n

Da un lato, si pu\u00f2 dire che nel mercato ci sono gi\u00e0 attori con soluzioni serie nel campo dell'iperconvergenza, e a cui stiamo cercando di accedere. Sembra che questa affermazione sia vera, MA...<\/p>\n

<\/p>\n

Dall'altro lato, uscendo sul campo e comunicando con i clienti, noi e i nostri partner vediamo che non \u00e8 affatto cos\u00ec. Ci sono molte esigenze per l'iperconvergenza; in alcuni casi le persone semplicemente non sapevano che ci fossero soluzioni di questo tipo, in altri sembrava costoso, in alcuni ci sono stati test falliti di soluzioni alternative, e in altri casi l'acquisto \u00e8 addirittura vietato a causa delle sanzioni. Insomma, il campo si \u00e8 rivelato vergine, quindi abbiamo deciso di portare avanti la nostra iniziativa))) <\/p>\n

<\/p>\n

Quando le soluzioni tradizionali sono migliori dell'iperconvergenza?<\/h3>\n

<\/p>\n

Durante il nostro lavoro con il mercato, ci chiedono spesso quando sia meglio utilizzare un sistema tradizionale rispetto all'iperconvergenza. Molte aziende produttrici di sistemi iperconvergenti (soprattutto quelle che non hanno nel loro portafoglio sistemi tradizionali) dicono: \u00abI sistemi di archiviazione tradizionali stanno perdendo rilevanza, solo iperconvergenza!\u00bb. Questa \u00e8 una dichiarazione audace, ma non riflette completamente la realt\u00e0. <\/p>\n

<\/p>\n

A dire il vero, il mercato dei sistemi di archiviazione tradizionali si sta realmente spostando verso l'iperconvergenza e soluzioni simili, ma c'\u00e8 sempre un 'ma'.<\/p>\n

<\/p>\n

In primo luogo, non \u00e8 cos\u00ec semplice riprogettare i data center e le infrastrutture IT costruiti secondo schemi tradizionali con storage a blocchi, quindi la modernizzazione e l'adeguamento di tali infrastrutture rappresentano un'eredit\u00e0 di circa 5-7 anni.<\/p>\n

<\/p>\n

In secondo luogo, la maggior parte delle infrastrutture attualmente in costruzione (riferendosi alla Federazione Russa) segue schemi tradizionali con l'uso di storage a blocchi. Non \u00e8 che non si conosca il hyper-converged, ma il mercato dell'hyper-converged \u00e8 nuovo, le soluzioni e gli standard non sono ancora consolidati, gli IT staff non sono ancora formati, ci sono poche esperienze, e i data center devono essere costruiti qui e ora. Questa tendenza continuer\u00e0 per altri 3-5 anni (e poi ci sar\u00e0 ancora un'eredit\u00e0, vedi punto 1).<\/p>\n

<\/p>\n

In terzo luogo, c'\u00e8 un limite tecnico puramente legato a piccole latenze aggiuntive di 2 millisecondi per la scrittura (escludendo, naturalmente, la cache locale), che rappresentano il prezzo da pagare per lo storage distribuito. <\/p>\n

<\/p>\n

E non dimentichiamo l'uso di grandi server fisici, che richiedono un'espansione verticale del sistema di archiviazione.<\/p>\n

<\/p>\n

Ci sono molte situazioni necessarie e popolari in cui le soluzioni di storage condiviso si comportano meglio delle soluzioni iperconvergenti. Certamente, non saranno d'accordo con noi quei produttori che non hanno soluzioni di storage condiviso nel loro portafoglio, ma siamo pronti a discutere con argomentazioni solide. Naturalmente, come sviluppatori di entrambi i prodotti, in una delle prossime pubblicazioni, faremo un confronto tra storage condiviso e soluzioni iperconvergenti, in cui mostreremo chiaramente in quali condizioni ciascuno \u00e8 migliore.<\/p>\n

<\/p>\n

In quali situazioni le soluzioni iperconvergenti funzioneranno meglio delle soluzioni di storage condiviso?<\/h3>\n

<\/p>\n

Sulla base dei punti sopra, si possono trarre tre conclusioni ovvie: <\/p>\n

<\/p>\n

    \n
  1. Laddove ulteriori 2 millisecondi di latenza in scrittura, che si verificano costantemente in qualsiasi ambiente produttivo (non stiamo parlando di test sintetici, dove \u00e8 possibile mostrare anche nanosecondi), siano critici, le soluzioni iperconvergenti possono andare bene.<\/li>\n
  2. Laddove il carico proveniente da grandi server fisici pu\u00f2 essere trasformato in molte piccole risorse virtuali e distribuito su nodi, anche le soluzioni iperconvergenti si comporteranno bene.<\/li>\n
  3. Laddove la scalabilit\u00e0 orizzontale \u00e8 pi\u00f9 prioritaria rispetto a quella verticale, anche le soluzioni iperconvergenti si integreranno perfettamente.<\/li>\n<\/ol>\n

    <\/p>\n

    Quali sono queste soluzioni?<\/h3>\n

    <\/p>\n

      \n
    1. Tutti i servizi infrastrutturali standard (servizio directory, posta, DMS, server file, sistemi ERP e BI di piccole o medie dimensioni, ecc.). Li chiamiamo \"calcolo condiviso\". <\/li>\n
    2. Infrastruttura dei fornitori cloud, dove \u00e8 necessario espandere rapidamente in modo standardizzato in orizzontale e creare facilmente un gran numero di macchine virtuali per i clienti.<\/li>\n
    3. Infrastruttura scrivanie virtuali<\/a> (VDI), dove molte piccole macchine virtuali degli utenti vengono avviate e galleggiano tranquillamente all'interno di un cluster uniforme.<\/li>\n
    4. Reti filiali, dove in ciascuna filiale \u00e8 necessaria un'infrastruttura standard, resiliente e a basso costo composta da 15-20 macchine virtuali.<\/li>\n
    5. Qualsiasi calcolo distribuito (servizi big data, ad esempio). Dove il carico si espande \"in orizzontale\" piuttosto che \"in profondit\u00e0\". <\/li>\n
    6. Ambienti di test, dove sono ammesse piccole latenze aggiuntive, ma ci sono limitazioni di budget, poich\u00e9 si tratta di test.<\/li>\n<\/ol>\n

      <\/p>\n

      Attualmente, \u00e8 per queste esigenze che abbiamo creato AERODISK vAIR e su di esse ci concentriamo (fino ad ora con successo). Potrebbe cambiare presto, poich\u00e9 il mondo non si ferma.<\/p>\n

      <\/p>\n

      Quindi\u2026<\/h3>\n

      <\/p>\n

      Questa \u00e8 la prima parte di un ampio ciclo di articoli. Nel prossimo articolo parleremo dell'architettura della soluzione e dei componenti utilizzati.<\/p>\n

      <\/p>\n

      Siamo a disposizione per domande, suggerimenti e dibattiti costruttivi.<\/p>\n

      Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","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\udd47 Soluzione iperconvergente AERODISK vAIR. Alla base c'\u00e8 il file system ARDFS | ProHoster","description":"Ciao, lettori di Habr. Con questo articolo diamo il via a un ciclo che parler\u00e0 del nostro sistema iperconvergente AERODISK vAIR. Inizialmente volevamo raccontare tutto nella prima pubblicazione, ma il sistema \u00e8 piuttosto complesso, quindi affronteremo l'argomento a piccoli pezzi. Iniziamo con la storia della creazione del sistema, approfondendo il file system ARDFS, che \u00e8 la base di vAIR, e anche","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","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\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","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:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","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-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38542","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=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}