{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin senza mani = iperconvergenza?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nQuesto \u00e8 un mito piuttosto comune nel campo dell'hardware server. Nella pratica, per\u00f2, le soluzioni iperconvergenza (quando tutto \u00e8 in uno) sono necessarie per molte ragioni. Storicamente, le prime architetture furono sviluppate da Amazon e Google per i loro servizi. L'idea era quella di creare una fattoria computazionale composta da nodi identici, ognuno dei quali aveva i propri dischi. Tutto ci\u00f2 era unito da un software sistemico (hypervisor) e suddiviso in macchine virtuali. L'obiettivo principale era ridurre al minimo gli sforzi per la manutenzione di un nodo e ridurre al minimo i problemi durante la scalabilit\u00e0: bastava acquistare un altro migliaio di server simili e collegarli. Nella pratica, questi casi sono isolati, e pi\u00f9 frequentemente si parla di un numero minore di nodi e di un'architettura leggermente diversa. <\/p>\n

Tuttavia, il vantaggio rimane lo stesso: una semplicit\u00e0 straordinaria nella scalabilit\u00e0 e nella gestione. Lo svantaggio \u00e8 che diversi compiti consumano risorse in modi diversi, e in alcune situazioni ci saranno molti dischi locali, in altre poca RAM, e cos\u00ec via, quindi con diversi tipi di compiti ci sar\u00e0 una riduzione dell'utilizzo delle risorse. <\/p>\n

Risulta che paghi il 10\u201315% in pi\u00f9 per la comodit\u00e0 di configurazione. \u00c8 cos\u00ec che \u00e8 nato il mito del titolo. Abbiamo cercato a lungo dove questa tecnologia fosse ottimale e abbiamo trovato la risposta. Il punto \u00e8 che Cisco non aveva il proprio storage, ma voleva entrare in pieno nel mercato dei server. Cos\u00ec hanno creato Cisco Hyperflex: una soluzione con storage locali sui nodi. <\/p>\n

E da questo \u00e8 emersa, sorprendentemente, una soluzione molto valida per i data center di backup (Disaster Recovery). Perch\u00e9 e come \u2014 lo racconter\u00f2 ora. E mostrer\u00f2 i test del cluster. <\/a><\/noindex><\/p>\n

Dove \u00e8 necessario<\/h3>\n

\nL'iperconvergenza \u00e8: <\/p>\n

    \n
  1. Trasferimento dei dischi nei nodi di calcolo.<\/li>\n
  2. Integrazione completa del sottosistema di storage con il sottosistema di virtualizzazione.<\/li>\n
  3. Trasferimento\/integrazione con il sottosistema di rete.<\/li>\n<\/ol>\n

    \nQuesta combinazione consente di implementare molte funzionalit\u00e0 dello storage a livello di virtualizzazione e tutto da un'unica interfaccia di gestione.<\/p>\n

    Nella nostra azienda, i progetti per la progettazione di data center di backup sono molto richiesti, e spesso si sceglie proprio una soluzione iperconvergente per la moltitudine di opzioni di replica (fino al metrocluster) incluse di default. <\/p>\n

    In caso di data center di backup, si tratta solitamente di una struttura situata in un'altra parte della citt\u00e0 o addirittura in un'altra citt\u00e0. Questo consente il recupero di sistemi critici in caso di guasto parziale o totale del data center principale. I dati vengono continuamente replicati, e questa replicazione pu\u00f2 avvenire a livello di applicazione o a livello di dispositivo di archiviazione (SAN).<\/p>\n

    Quindi, ora parler\u00f2 della struttura del sistema e delle prove, e poi di alcuni scenari di utilizzo reale con dati sui risparmi. <\/p>\n

    Test<\/h3>\n

    \nIl nostro esemplare \u00e8 composto da quattro server, ognuno con 10 dischi SSD da 960 GB. C'\u00e8 un disco dedicato per la cache delle operazioni di scrittura e per la memorizzazione della macchina virtuale di servizio. La soluzione stessa \u00e8 la quarta versione. La prima era piuttosto grezza (stando ai feedback), la seconda era ancora un po' acerba, la terza era gi\u00e0 abbastanza stabile, e questa pu\u00f2 essere considerata la versione finale dopo la beta-test pubblica. Durante il periodo di prova non ho riscontrato problemi, tutto funziona a meraviglia.<\/p>\n

    Modifiche nella v4<\/b>Corretti numerosi bug. <\/p>\n

    Inizialmente, la piattaforma funzionava solo con il hypervisor VMware ESXi e supportava un numero limitato di nodi. Inoltre, il processo di distribuzione non sempre si concludeva con successo; a volte era necessario riavviare alcuni passaggi e c'erano problemi nell'aggiornamento da versioni precedenti. I dati nell'interfaccia grafica non venivano sempre visualizzati correttamente (anche se ora non sono ancora del tutto soddisfatto della visualizzazione dei grafici delle prestazioni) e talvolta si verificavano problemi legati alla virtualizzazione.<\/p>\n

    Ora tutte le problematiche iniziali sono state risolte, HyperFlex supporta sia ESXi che Hyper-V, e in aggiunta \u00e8 possibile:<\/p>\n

      \n
    1. Creare un cluster distribuito. <\/li>\n
    2. Creare un cluster per uffici senza utilizzare Fabric Interconnect, da due a quattro nodi (acquistiamo solo server).<\/li>\n
    3. Possibilit\u00e0 di lavorare con storage esterni.<\/li>\n
    4. Supporto per contenitori e Kubernetes.<\/li>\n
    5. Creazione di zone di disponibilit\u00e0.<\/li>\n
    6. Integrazione con VMware SRM, se le funzionalit\u00e0 integrate non sono soddisfacenti.<\/li>\n<\/ol>\n

      L'architettura non si discosta molto dalle soluzioni dei principali concorrenti; non \u00e8 stata creata una bicicletta. Funziona tutto su piattaforma di virtualizzazione VMware o Hyper-V. A livello hardware, \u00e8 ospitato su server progettati internamente da Cisco UCS. Ci sono quelli che odiano la piattaforma per la relativa complessit\u00e0 della configurazione iniziale, per la moltitudine di pulsanti, per il sistema di modelli e dipendenze non banale, ma ci sono anche coloro che hanno raggiunto il zen, abbracciato l'idea e non vogliono pi\u00f9 lavorare con altri server. <\/p>\n

      Considereremo specificamente la soluzione per VMware, poich\u00e9 \u00e8 stata originariamente sviluppata per essa e offre funzionalit\u00e0 superiori; Hyper-V \u00e8 stato migliorato nel tempo per non rimanere indietro rispetto ai concorrenti e soddisfare le aspettative di mercato.<\/p>\n

      C'\u00e8 un cluster di server dotati di dischi. Ci sono dischi per l'archiviazione dei dati (SSD o HDD, a seconda delle tue preferenze e necessit\u00e0) e un disco SSD dedicato per la cache. Quando i dati vengono scritti nel datastor, vengono salvati prima nel livello di cache (disco SSD dedicato e RAM della VM di servizio). Contemporaneamente, il blocco di dati viene inviato ai nodi nel cluster (il numero di nodi dipende dal fattore di replica del cluster). Dopo aver ricevuto conferma da tutti i nodi riguardo alla scrittura avvenuta con successo, la conferma viene inviata all'iper-vista e successivamente alla VM. I dati registrati vengono deduplicati, compressi e scritti sui dischi di archiviazione in background. Durante questo processo, i dati vengono sempre scritti in blocchi grandi e in modo sequenziale, il che riduce il carico sui dischi di archiviazione.<\/p>\n

      La deduplicazione e la compressione sono sempre attive e non possono essere disattivate. La lettura dei dati avviene direttamente dai dischi di archiviazione o dalla cache RAM. Se \u00e8 configurato un sistema ibrido, anche la lettura viene messa in cache su disco SSD.<\/p>\n

      I dati non sono legati alla posizione attuale della macchina virtuale e vengono distribuiti uniformemente tra i nodi. Questo approccio consente di caricare in modo equivalente tutti i dischi e le interfacce di rete. Ne deriva un chiaro svantaggio: non possiamo ridurre al minimo la latenza di lettura, poich\u00e9 non c'\u00e8 alcuna garanzia della presenza locale dei dati. Tuttavia, ritengo che questo sia un sacrificio trascurabile rispetto ai benefici ottenuti. Inoltre, le latenza di rete hanno raggiunto valori tali da avere praticamente un effetto trascurabile sul risultato complessivo.<\/p>\n

      La logica di funzionamento del sistema di archiviazione \u00e8 gestita da una VM di servizio speciale, il controller della piattaforma Cisco HyperFlex Data, che viene creata su ogni nodo di archiviazione. Nella nostra configurazione, alla VM di servizio sono stati assegnati otto vCPU e 72 GB di RAM, che non sono pochi. Ricordo che l'host stesso dispone di 28 core fisici e 512 GB di RAM.<\/p>\n

      La VM di servizio ha accesso diretto ai dischi fisici tramite il pass-through del controllore SAS nella VM. La comunicazione con l'ipervisor avviene tramite un modulo speciale IOVisor, che intercetta le operazioni di input\/output, e attraverso un agente che consente di inviare comandi all'API dell'ipervisor. L'agente gestisce il lavoro con gli snapshot e i cloni di HyperFlex.<\/p>\n

      Nel hypervisor, le risorse disco vengono montate come condivisioni NFS o SMB (a seconda del tipo di hypervisor, indovinate quale sia quale). Ma sotto il cofono si tratta di un file system distribuito, che consente di aggiungere funzionalit\u00e0 di livelli enterprise: assegnazione sottile dei volumi, compressione e deduplicazione, snapshot con tecnologia Redirect-on-Write, replica sincrona\/asincrona.<\/p>\n

      La VM di servizio fornisce accesso all'interfaccia WEB per la gestione del sottosistema HyperFlex. C'\u00e8 integrazione con vCenter, e gran parte delle attivit\u00e0 quotidiane pu\u00f2 essere eseguita da l\u00ec, ma i data store, ad esempio, sono pi\u00f9 facili da gestire tramite una web app separata, se sei gi\u00e0 passato all'interfaccia HTML5 rapida, o utilizzare il client Flash completo con integrazione totale. Nella web app di servizio puoi visualizzare le prestazioni e lo stato dettagliato del sistema.<\/p>\n

      \"Admin
      \n
      \nEsiste un altro tipo di nodi nel cluster: i nodi di calcolo. Questi possono essere server rack o blade privi di dischi integrati. Su questi server \u00e8 possibile eseguire VM i cui dati sono memorizzati su server con dischi. Dal punto di vista dell'accesso ai dati, non ci sono differenze tra i tipi di nodi, poich\u00e9 l'architettura prevede l'astrazione dalla posizione fisica dei dati. Il rapporto massimo tra nodi di calcolo e nodi di archiviazione \u00e8 di 2:1.<\/p>\n

      L'uso dei nodi di calcolo aumenta la flessibilit\u00e0 nella scalabilit\u00e0 delle risorse del cluster: non \u00e8 necessario acquistare nodi con dischi se abbiamo bisogno solo di CPU\/RAM. Inoltre, possiamo aggiungere un blade enclosures e ottenere risparmi sullo spazio dei server nel rack.<\/p>\n

      In conclusione, abbiamo una piattaforma iperconvergente con le seguenti funzionalit\u00e0:<\/p>\n