{"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. La base \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 apriamo un ciclo che parler\u00e0 del sistema iperconvergente AERODISK vAIR sviluppato da noi. Inizialmente volevamo trattare tutto sin da subito, ma il sistema \u00e8 piuttosto complesso, quindi lo affronteremo a pezzi. <\/p>\n

<\/p>\n

Iniziamo il racconto dalla storia della creazione del sistema, approfondiremo il file system ARDFS, che \u00e8 la base di vAIR, e discuteremo un po' del posizionamento di questa soluzione nel mercato russo. <\/p>\n

<\/p>\n

Negli articoli successivi parleremo pi\u00f9 dettagliatamente dei vari componenti architetturali (cluster, ipervisore, bilanciatore di carico, sistema di monitoraggio, ecc.), del processo di configurazione, affronteremo le questioni relative alle licenze, presenteremo test di stress e, naturalmente, scriveremo riguardo al testing delle prestazioni e al sizing. Dedicheremo anche un articolo specifico alla versione community di vAIR.<\/p>\n

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

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

<\/p>\n

L'idea di creare la nostra iperconvergenza ci \u00e8 venuta attorno al 2010. All'epoca non esistevano n\u00e9 AERODISK n\u00e9 soluzioni simili (sistemi iperconvergenti commerciali) sul mercato. Il nostro compito era il seguente: trasformare un insieme di server con dischi locali, connessi tramite interconnect in protocollo Ethernet, in uno storage distribuito e avviare l\u00ec macchine virtuali e una rete software. Tutto questo doveva essere realizzato senza SAN (perch\u00e9 non avevamo fondi per le SAN e le relative infrastrutture, e non avevamo ancora inventato la nostra SAN).<\/p>\n

<\/p>\n

Abbiamo sperimentato 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, avendo risolto quel problema, non abbiamo proseguito nello sviluppo dell'idea di trasformare il risultato del nostro lavoro in un prodotto a pieno titolo. <\/p>\n

<\/p>\n

Dopo quel caso ci siamo allontanati dall'idea, ma non ci ha comunque mai abbandonato la sensazione che quel problema fosse affrontabile e che i benefici di una simile soluzione fossero pi\u00f9 che evidenti. In seguito, i prodotti HCI lanciati da aziende straniere hanno solo confermato questa sensazione. <\/p>\n

<\/p>\n

Pertanto, nel mezzo del 2016, abbiamo ripreso questo compito nel contesto della creazione di un prodotto completo. All'epoca non avevamo ancora alcuna relazione con gli investitori, quindi abbiamo dovuto acquistare il nostro stand di sviluppo con i nostri pochi soldi. Dopo aver cercato su Avito server e switch usati, ci siamo messi al lavoro.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Il compito iniziale principale era la creazione di un proprio, anche se semplice, sistema di file che potesse distribuire automaticamente e uniformemente i dati sotto forma di blocchi virtuali su un numero n di nodi del cluster, uniti tra loro tramite interconnessione Ethernet. Inoltre, il sistema di file doveva essere scalabile e facilmente indipendente da sistemi adiacenti, ovvero doveva essere trasferibile da vAIR come semplice 'storage'.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Il primo concetto di vAIR<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Abbiamo deliberatamente rinunciato all'uso di soluzioni open source pronte per organizzare uno storage distribuito (come Ceph, Gluster, Lustre e simili) a favore dello sviluppo interno, poich\u00e9 avevamo gi\u00e0 accumulato molta esperienza progettuale con essi. \u00c8 innegabile che queste soluzioni siano eccellenti e, prima di lavorare su Aerodisk, abbiamo realizzato diversi progetti di integrazione con esse. Ma un conto \u00e8 realizzare un compito specifico per un cliente, formare il personale e, forse, acquistare il supporto di un grande fornitore; un altro conto \u00e8 creare un prodotto facilmente replicabile che sar\u00e0 utilizzato per compiti diversi, di cui, come fornitore, potremmo anche non sapere nulla. Per questo secondo obiettivo, i prodotti open source esistenti non erano adatti, quindi abbiamo deciso di sviluppare noi stessi il sistema di file distribuito.
\nDopo due anni, grazie all'impegno di alcuni sviluppatori (che combinavano il lavoro su vAIR con quello sulla classica SAN Engine), abbiamo raggiunto un risultato significativo.<\/p>\n

<\/p>\n

Entro il 2018 avevamo scritto un sistema di file molto semplice e l'avevamo completato con il necessario supporto. Il sistema univa, tramite interconnessione interna, dischi fisici (locali) provenienti da diversi server in un unico pool piatto e li 'tagliava' in blocchi virtuali; successivamente, dai blocchi virtuali venivano creati dispositivi a blocchi con vari livelli di tolleranza ai guasti, su cui venivano create ed eseguite macchine virtuali tramite l'ipercontrollore KVM. <\/p>\n

<\/p>\n

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

<\/p>\n

Questo prototipo appariva bene (non visivamente, ovviamente, poich\u00e9 non c'era ancora design visivo) 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 matura l'architettura generale della soluzione, che fino ad oggi non ha subito cambiamenti significativi.<\/p>\n

<\/p>\n

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

<\/p>\n

ARDFS \u00e8 la base di vAIR, che fornisce un'archiviazione dei dati distribuita e tollerante ai guasti per l'intero cluster. Una delle (ma non l'unica) caratteristiche distintive di ARDFS \u00e8 che non utilizza alcuna forma di dei server dedicati<\/a> sottosistema e gestione. Era stato concepito fin dall'inizio per semplificare la configurazione della soluzione e per 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 tutta la capacit\u00e0 disco disponibile. \u00c8 importante comprendere che un pool non \u00e8 ancora dati e nemmeno uno spazio formattato, ma semplicemente una segmentazione, cio\u00e8 qualsiasi nodo con vAIR installato, aggiunto al cluster, viene automaticamente integrato nel pool comune di ARDFS e le risorse disco diventano automaticamente condivise per l'intero cluster (e disponibili per future archiviazioni di dati). Questo approccio consente di aggiungere e rimuovere nodi al volo senza alcun impatto serio sul sistema gi\u00e0 funzionante. Cio\u00e8, il sistema \u00e8 molto facile da scalare<\/p>\n

<\/p>\n

Sopra il pool di ARDFS vengono aggiunti dischi virtuali (oggetti di archiviazione per le macchine virtuali), costruiti da blocchi virtuali delle dimensioni di 4 megabyte. I dati sono memorizzati direttamente sui dischi virtuali. A livello di dischi virtuali viene definito anche uno schema di tolleranza ai guasti. <\/p>\n

<\/p>\n

Come si pu\u00f2 gi\u00e0 intuire, per garantire l'affidabilit\u00e0 del sistema di archiviazione, non utilizziamo il concetto di RAID (Array ridondante di dischi indipendenti), ma utilizziamo RAIN (Array ridondante di nodi indipendenti). Vale a dire, l'affidabilit\u00e0 \u00e8 misurata, automatizzata e gestita in base ai nodi, e non ai dischi. I dischi, senza dubbio, sono anch'essi oggetti di archiviazione; vengono monitorati come tutto il resto e con essi \u00e8 possibile eseguire tutte le operazioni standard, inclusa la creazione di un RAID hardware locale, ma il cluster opera proprio sui nodi. <\/p>\n

<\/p>\n

In una situazione in cui si desidera fortemente RAID (ad esempio, in uno scenario che supporta guasti multipli su piccoli cluster), nulla impedisce di utilizzare controller RAID locali e sopra creare uno storage distribuito e un'architettura RAIN. Questo scenario \u00e8 assolutamente pratico e supportato da noi, quindi ne parleremo nell'articolo sui casi d'uso tipici di vAIR.<\/p>\n

<\/p>\n

Schemi di affidabilit\u00e0 dello storage<\/h3>\n

<\/p>\n

Possono esserci due schemi di affidabilit\u00e0 per i dischi virtuali in vAIR:<\/p>\n

<\/p>\n

1) Fattore di replicazione o semplicemente replicazione \u2013 questo metodo di affidabilit\u00e0 \u00e8 semplice \"come un bastone e una corda\". Viene eseguita una replicazione sincrona tra i nodi con un fattore di 2 (2 copie nel cluster) o 3 (3 copie, rispettivamente). RF-2 consente al disco virtuale di resistere al guasto di un nodo nel cluster, ma \"consuma\" met\u00e0 della capacit\u00e0 utile, mentre RF-3 resister\u00e0 al guasto di 2 nodi nel cluster, ma riserver\u00e0 gi\u00e0 2\/3 della capacit\u00e0 utile per i propri bisogni. Questo schema assomiglia molto a RAID-1, quindi un disco virtuale configurato in RF-2 \u00e8 resistente al guasto di qualsiasi nodo del cluster. In questo caso, i dati saranno al sicuro e anche l'input\/output non si fermer\u00e0. Quando il nodo guasto torner\u00e0 in funzione, 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 di 8 MB di dati unici (utili) che opera su 4 nodi vAIR. \u00c8 chiaro che nella realt\u00e0 un volume cos\u00ec ridotto \u00e8 difficile da trovare, ma per uno schema che rifletta la logica di funzionamento di ARDFS, questo esempio \u00e8 il pi\u00f9 chiaro. AB sono blocchi virtuali di 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\" sui nodi, evitando la sovrapposizione degli stessi dati su un nodo, cio\u00e8 la copia A1 non sar\u00e0 presente 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 \u00e8 presente la copia B1), questa copia viene automaticamente attivata su un nodo dove non \u00e8 presente una copia della sua copia (cio\u00e8 la copia B2). <\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Pertanto, il disco virtuale (e la VM, di conseguenza) pu\u00f2 facilmente resistere al guasto di un nodo nel schema RF-2.<\/p>\n

<\/p>\n

Lo schema di replica, pur nella sua semplicit\u00e0 e affidabilit\u00e0, presenta la stessa problematica del RAID1: poco spazio utile.<\/p>\n

<\/p>\n

2) L'errore di codifica o 'erasure coding' (noto anche come 'coding ridondante', 'coding cancellativo' o 'codice di ridondanza') \u00e8 stato creato proprio per risolvere il problema sopra. EC \u00e8 uno schema di ridondanza che garantisce un'alta disponibilit\u00e0 dei dati con minori costi di archiviazione 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 suddivide il blocco virtuale (per impostazione predefinita 4 MB) in diversi 'pezzi di dati' pi\u00f9 piccoli, 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 'pezzi di dati' 'pezzi di parit\u00e0' della dimensione massima di una delle parti precedentemente suddivise. Durante la decodifica, l'EC genera i pezzi mancanti leggendo i dati 'sopravvissuti' in tutto il cluster. <\/p>\n

<\/p>\n

Ad esempio, un disco virtuale con schema EC 2 + 1, implementato su 4 nodi di un cluster, resister\u00e0 tranquillamente al guasto di un nodo nel cluster, proprio come RF-2. In questo caso, i costi operativi saranno inferiori: il rapporto di utilizzo utile in RF-2 \u00e8 2, mentre in EC 2+1 sar\u00e0 1,5. <\/p>\n

<\/p>\n

In parole semplici, il concetto \u00e8 che il blocco virtuale viene suddiviso in 2-8 'pezzi' (il motivo per cui da 2 a 8 lo si vedr\u00e0 pi\u00f9 avanti) e per questi pezzi vengono calcolati 'pezzi' di parit\u00e0 di volume simile. <\/p>\n

<\/p>\n

Alla fine, i dati e la parit\u00e0 vengono distribuiti uniformemente su tutti i nodi del cluster. Inoltre, come per la replica, ARDFS distribuisce automaticamente i dati sui nodi in modo da evitare di memorizzare dati identici (copia dei dati e della loro parit\u00e0) su un unico nodo, per escludere la possibilit\u00e0 di perdere dati poich\u00e9 i dati e la loro parit\u00e0 si troverebbero improvvisamente su un unico nodo di archiviazione, che si guasta. <\/p>\n

<\/p>\n

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

<\/p>\n

I blocchi A e B sono divisi in due parti ciascuna di 2 MB (due perch\u00e9 2+1), ovvero 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 di 4MB, ciascuno contenente due pezzi da due megabyte. Successivamente, per ciascuno di questi set viene calcolata la parit\u00e0, con un volume non superiore a un pezzo (cio\u00e8 2 MB), ottenendo ulteriormente + 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\" sui nodi in modo che i dati non si sovrappongano alla loro parit\u00e0. Cio\u00e8, A1 e A2 non saranno memorizzati nello stesso nodo di A-P.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

In caso di guasto di un nodo (supponiamo, anche il terzo), il blocco B1 sar\u00e0 automaticamente ripristinato dalla parit\u00e0 B-P, che \u00e8 memorizzata sul nodo n. 2, e sar\u00e0 attivato sul nodo dove non \u00e8 presente la parit\u00e0 B, cio\u00e8 il pezzo B-P. In questo esempio, si tratta del nodo n. 1.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Sono sicuro che il lettore avr\u00e0 una domanda:<\/p>\n

<\/p>\n

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

E poi ci saranno interessanti caratteristiche del funzionamento di ARDFS.<\/p>\n

<\/p>\n

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

<\/p>\n

Inizialmente abbiamo previsto uno schema di EC piuttosto flessibile X+Y, dove X varia da 2 a 8 e Y da 1 a 8, ma sempre minore o uguale a X. Questo schema \u00e8 previsto per garantire flessibilit\u00e0. Aumentando il numero di pezzi di dati (X) in cui \u00e8 suddiviso il blocco virtuale, si riducono i costi generali, cio\u00e8 si aumenta lo spazio utile.
\nAumentando il numero di pezzi di parit\u00e0 (Y), si aumenta l'affidabilit\u00e0 del disco virtuale. Maggiore \u00e8 il valore di Y, maggiore \u00e8 il numero di nodi del cluster che possono guastarsi. Ovviamente, aumentando il volume della parit\u00e0 si riduce la capacit\u00e0 utile, ma questo \u00e8 il prezzo da pagare per l'affidabilit\u00e0. <\/p>\n

<\/p>\n

La dipendenza delle prestazioni dagli schemi EC \u00e8 quasi diretta: pi\u00f9 \u00abpezzi\u00bb ci sono, minori saranno le prestazioni, qui \u00e8 chiaro che ci vuole uno sguardo equilibrato. <\/p>\n

<\/p>\n

Questo approccio consente agli amministratori di configurare in modo flessibile lo storage distribuito. All'interno del pool ARDFS possono essere utilizzati qualsiasi schema di tolleranza ai guasti e le loro combinazioni, il che \u00e8, a nostro avviso, molto utile. <\/p>\n

<\/p>\n

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

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

Dalla tabella si evince che anche la combinazione EC 8+7, che consente di perdere fino a 7 nodi simultaneamente nel cluster, \u00abconsuma\u00bb meno spazio utile (1,875 contro 2) rispetto alla replica standard, proteggendo allo stesso tempo 7 volte meglio. Questo rende questo 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 scarsit\u00e0 di spazio su disco. \u00c8 importante comprendere che ogni \u00abpi\u00f9\u00bb a X o Y comporter\u00e0 un ulteriore costo sulle prestazioni, quindi nel triangolo tra affidabilit\u00e0, economia e prestazioni bisogna fare una scelta molto attenta. Per questo motivo, dedicheremo un articolo separato al dimensionamento della codifica del cancellamento.<\/p>\n

<\/p>\n

\"Soluzione<\/p>\n

<\/p>\n

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

<\/p>\n

ARDFS viene avviato localmente su tutti i nodi del cluster e sincronizza i propri mezzi attraverso interfacce Ethernet dedicate. Un aspetto importante \u00e8 che ARDFS sincronizza autonomamente non solo i dati, ma anche i metadati relativi allo storage. Durante il lavoro su ARDFS, abbiamo contemporaneamente esaminato una serie di soluzioni esistenti e abbiamo scoperto che molti fanno la sincronizzazione dei metadati del file system tramite un DBMS distribuito esterno, che utilizziamo anch'esso per la sincronizzazione, ma solo delle configurazioni e non dei metadati del FS (di questo e di altri sistemi adiacenti parleremo nel prossimo articolo). <\/p>\n

<\/p>\n

La sincronizzazione dei metadati del FS tramite un DBMS esterno \u00e8 sicuramente una soluzione valida, ma in tal caso la consistenza dei dati memorizzati su ARDFS dipenderebbe dal DBMS esterno e dal suo comportamento (e, diciamolo chiaramente, \u00e8 una signora capricciosa), il che a nostro avviso \u00e8 negativo. Perch\u00e9? Se i metadati del FS venissero danneggiati, anche i dati stessi del FS potrebbero dire \"addio\", 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, e vive completamente indipendente dai sottosistemi adiacenti. Cio\u00e8, nessun altro sottosistema pu\u00f2 danneggiare i dati di ARDFS. A nostro avviso, questo \u00e8 il percorso pi\u00f9 affidabile e corretto, e se sia veramente cos\u00ec, lo dir\u00e0 il tempo. Inoltre, tale approccio presenta un ulteriore vantaggio. ARDFS pu\u00f2 essere utilizzato indipendentemente da vAIR, semplicemente come un archivio espanso, cosa che certamente utilizzeremo nei prodotti futuri.<\/p>\n

<\/p>\n

Di conseguenza, sviluppando ARDFS, abbiamo ottenuto un file system flessibile e affidabile, che offre la scelta su dove risparmiare in capacit\u00e0 o dedicare tutto alla performance, o rendere l'archivio super affidabile a un costo moderato, riducendo per\u00f2 le esigenze prestazionali. <\/p>\n

<\/p>\n

Insieme a una semplice politica di licenza e a un modello di fornitura flessibile (anticipando, vAIR \u00e8 licenziato per nodi e fornito sia come software che come PAC), questo consente di adattare molto precisamente la soluzione alle pi\u00f9 varie esigenze dei clienti e di mantenere facilmente questo equilibrio in futuro. <\/p>\n

<\/p>\n

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

<\/p>\n

Da un lato, si potrebbe dire che ci sono gi\u00e0 attori sul mercato con soluzioni serie nel campo dell'iperconvergenza, e dove, in fondo, stiamo cercando di inserirci. Sembra che questa affermazione sia corretta, MA...<\/p>\n

<\/p>\n

D'altro canto, uscendo \"sul campo\" e interagendo 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 queste soluzioni esistessero, in altri sembrava costoso, ci sono stati test fallimentari di soluzioni alternative, e in alcuni casi addirittura \u00e8 vietato acquistare, a causa delle sanzioni. In generale, il campo si \u00e8 rivelato inesplorato, quindi abbiamo deciso di coltivare l'ignoto))). <\/p>\n

<\/p>\n

Quando \u00e8 meglio avere un SCD rispetto a un GCS?<\/h3>\n

<\/p>\n

Nel corso del nostro lavoro con il mercato, ci viene spesso chiesto quando sia meglio utilizzare lo schema classico con lo storage a disco (S\u0425\u0414) e quando optare per le soluzioni iperconvergenti. Molte aziende produttrici di G\u041a\u0421 (soprattutto quelle che non hanno nello loro offerta S\u0425\u0414) affermano: \u00abL'S\u0425\u0414 \u00e8 obsoleta, solo soluzione iperconvergente!\u00bb. \u00c8 un'affermazione audace, ma non riflette del tutto la realt\u00e0. <\/p>\n

<\/p>\n

A dire il vero, il mercato S\u0425\u0414 sta davvero migrando verso l'iperconvergente e soluzioni simili, ma c'\u00e8 sempre un \u00abma\u00bb.<\/p>\n

<\/p>\n

In primo luogo, i data center e le infrastrutture IT costruiti secondo lo schema classico con S\u0425\u0414 non possono essere semplicemente riconvertiti, quindi la modernizzazione e l'espansione di tali infrastrutture rappresentano un'eredit\u00e0 di altri 5-7 anni.<\/p>\n

<\/p>\n

In secondo luogo, le infrastrutture che vengono attualmente costruite nella maggior parte (si fa riferimento alla RF) sono realizzate secondo lo schema classico con l'uso della S\u0425\u0414 e non perch\u00e9 le persone non conoscano l'iperconvergente, ma perch\u00e9 il mercato dell'iperconvergente \u00e8 nuovo, le soluzioni e gli standard non sono ancora consolidati, gli IT manager non sono ancora formati, c'\u00e8 poca esperienza, e bisogna costruire i data center qui e ora. Questa tendenza durer\u00e0 ancora per 3-5 anni (e poi ci sar\u00e0 ancora eredit\u00e0, vedere punto 1).<\/p>\n

<\/p>\n

In terzo luogo, esiste un vincolo tecnico puro con piccoli ritardi aggiuntivi di 2 millisecondi nella scrittura (senza considerare la cache locale, ovviamente), che sono il prezzo per l'archiviazione distribuita. <\/p>\n

<\/p>\n

E non dimentichiamo l'uso di grandi server fisici, che amano la scalabilit\u00e0 verticale del sottosistema di archiviazione.<\/p>\n

<\/p>\n

Ci sono molte attivit\u00e0 necessarie e popolari, dove la S\u0425\u0414 si comporta meglio rispetto alla G\u041a\u0421. Certamente, chi produce G\u041a\u0421 e non ha S\u0425\u0414 nella propria offerta non sar\u00e0 d'accordo, ma siamo pronti a discutere in modo argomentato. Naturalmente, come sviluppatori di entrambi i prodotti, in una delle prossime pubblicazioni condurremo un confronto tra S\u0425\u0414 e G\u041a\u0421, dove dimostreremo chiaramente le condizioni ottimali per ciascuna soluzione.<\/p>\n

<\/p>\n

E dove le soluzioni iperconvergenti funzioneranno meglio della S\u0425\u0414?<\/h3>\n

<\/p>\n

Partendo dalle affermazioni precedenti, si possono trarre tre conclusioni ovvie: <\/p>\n

<\/p>\n

    \n
  1. Laggi\u00f9, dove i 2 millisecondi di ritardo aggiuntivi nella scrittura, che si verificano stabilmente in qualsiasi sistema produttivo (al momento non stiamo parlando di sintesi, poich\u00e9 in sintesi si possono mostrare anche i nanosecondi), sono non critici, l'iperconvergente sar\u00e0 appropriato.<\/li>\n
  2. Dove il carico di grandi server fisici pu\u00f2 essere trasformato in molte piccole macchine virtuali e distribuito su nodi, l\u00ec l'iperconvergenza si inserir\u00e0 bene.<\/li>\n
  3. Dove la scalabilit\u00e0 orizzontale \u00e8 pi\u00f9 prioritaria rispetto a quella verticale, l\u00ec anche l'iperconvergenza si adatter\u00e0 perfettamente.<\/li>\n<\/ol>\n

    <\/p>\n

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

    <\/p>\n

      \n
    1. Tutti i servizi infrastrutturali standard (servizio directory, email, gestione documentale, server file, sistemi ERP e BI piccoli o medi, ecc.). Noi li chiamiamo \u00abcomputazione generale\u00bb. <\/li>\n
    2. L'infrastruttura dei fornitori di servizi cloud, dove \u00e8 necessario espandersi rapidamente e in modo standardizzato in orizzontale e creare facilmente un gran numero di macchine virtuali per i clienti.<\/li>\n
    3. Infrastruttura desktop virtuali<\/a> (VDI), dove molte piccole macchine virtuali per gli utenti vengono avviate e navigano tranquillamente all'interno di un cluster uniforme.<\/li>\n
    4. Reti filiali, dove ogni filiale necessita di un'infrastruttura standard, resistente ai guasti, ma al tempo stesso economica, composta da 15-20 macchine virtuali.<\/li>\n
    5. Qualsiasi computazione distribuita (servizi big data, per esempio). Dove il carico non va \u00abin profondit\u00e0\u00bb, ma \u00abin larghezza\u00bb. <\/li>\n
    6. Ambienti di test, dove sono ammesse piccole latenze aggiuntive, ma ci sono vincoli di budget, poich\u00e9 si tratta di test.<\/li>\n<\/ol>\n

      <\/p>\n

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

      <\/p>\n

      Quindi...<\/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

      Saremo lieti di ricevere domande, suggerimenti e discussioni costruttive.<\/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\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. La base \u00e8 il sistema di file ARDFS | ProHoster","description":"","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: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","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\/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}]}}