{"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 diffuso nel campo dell'hardware server. Nella pratica, tuttavia, le soluzioni iperconvergenti (dove tutto \u00e8 in uno) sono necessarie per molti motivi. Storicamente, le prime architetture furono sviluppate da Amazon e Google per i loro servizi. All'epoca l'idea era di creare una fattoria di calcolo composta da nodi identici, ognuno dei quali dispone di dischi propri. Tutto questo veniva unito tramite un certo software di sistema (iper-vvisor) e suddiviso in macchine virtuali. L'obiettivo principale era ridurre al minimo gli sforzi per la gestione di un nodo e minimizzare i problemi durante la scalabilit\u00e0: bastava acquistare un migliaio di server simili e collegarli accanto. Nella pratica, questi sono casi isolati, e pi\u00f9 spesso si parla di un numero inferiore di nodi e un'architettura leggermente diversa. <\/p>\n

Ma il vantaggio rimane lo stesso: un'incredibile semplicit\u00e0 di scalabilit\u00e0 e gestione. Lo svantaggio \u00e8 che diversi compiti consumano risorse in modi diversi, e in alcuni casi ci saranno molti dischi locali, in altri poca memoria e cos\u00ec via, quindi con compiti diversi si verificher\u00e0 una diminuzione dell'utilizzazione delle risorse. <\/p>\n

Si scopre che si paga il 10-15% in pi\u00f9 per la comodit\u00e0 della configurazione. Questo ha generato il mito del titolo. Abbiamo cercato a lungo dove la tecnologia sarebbe stata utilizzata in modo ottimale, e l'abbiamo trovata. Il fatto \u00e8 che Cisco non aveva i propri sistemi di archiviazione, ma voleva coprire l'intero mercato dei server. Cos\u00ec hanno realizzato Cisco Hyperflex: una soluzione con archiviazione locale sui nodi. <\/p>\n

Da ci\u00f2 \u00e8 emerso improvvisamente un'ottima soluzione per i data center di backup (Disaster Recovery). Perch\u00e9 e come \u2014 ora lo racconter\u00f2. E mostrer\u00f2 i test del cluster. <\/a><\/noindex><\/p>\n

Dove serve<\/h3>\n

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

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

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

    Nella nostra azienda sono molto richiesti progetti di progettazione di data center di backup, e spesso viene scelta proprio la soluzione iperconvergente per la moltitudine di opzioni di replica (fino al metrocluster) disponibili out of the box. <\/p>\n

    Nel caso dei data center di riserva, si parla solitamente di un sito remoto situato all'altro capo della citt\u00e0 o addirittura in un'altra citt\u00e0. Questo consente di ripristinare sistemi critici in caso di guasti parziali o totali del data center principale. I dati vengono continuamente replicati dal server di produzione e questa replicazione pu\u00f2 avvenire a livello applicativo o a livello di dispositivo di memorizzazione (storage condiviso).<\/p>\n

    Pertanto, ora parler\u00f2 della configurazione del sistema e dei test, e poi di alcuni scenari di applicazione reale con dati sui risparmi. <\/p>\n

    Test<\/h3>\n

    \nIl nostro esempio \u00e8 composto da quattro server, ognuno dei quali ha 10 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 chiaramente acerba (secondo le recensioni), la seconda era ancora un po' incongruente, la terza \u00e8 gi\u00e0 abbastanza stabile, mentre questa pu\u00f2 essere considerata un rilascio dopo la fine dei test beta per il grande pubblico. Durante il periodo di prova non ho riscontrato problemi, tutto funziona come un orologio.<\/p>\n

    Cambiamenti in v4<\/b>Correzione di numerosi bug. <\/p>\n

    Inizialmente, la piattaforma poteva funzionare solo con il hypervisor VMware ESXi e supportava un numero limitato di nodi. Inoltre, il processo di implementazione spesso non si concludeva con successo, era necessario riavviare alcuni passaggi, c'erano problemi con l'aggiornamento dalle versioni precedenti, i dati nell'interfaccia grafica non venivano sempre visualizzati correttamente (anche se ora non sono entusiasta della visualizzazione dei grafici delle prestazioni), a volte si presentavano problemi legati alla virtualizzazione.<\/p>\n

    Ora tutte le malattie infantili sono state corrette, HyperFlex supporta sia ESXi che Hyper-V, in aggiunta a questo \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 i server).<\/li>\n
    3. Possibilit\u00e0 di lavorare con storage condiviso 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 abbiamo reinventato la ruota. Tutto ci\u00f2 funziona su una piattaforma di virtualizzazione VMware o Hyper-V. A livello hardware viene installato su server sviluppati internamente da Cisco UCS. Ci sono quelli che odiano la piattaforma per la relativa complessit\u00e0 della configurazione iniziale, il gran numero di pulsanti, un sistema di modelli e dipendenze non triviale, ma ci sono anche quelli che hanno raggiunto il zen, si sono appassionati all'idea e non vogliono pi\u00f9 lavorare con altri server. <\/p>\n

      Esamineremo specificamente la soluzione per VMware, poich\u00e9 \u00e8 stata originariamente creata per essa e ha un funzionalit\u00e0 maggiore; Hyper-V \u00e8 stato migliorato nel tempo per non rimanere indietro rispetto ai concorrenti e per soddisfare le aspettative del mercato.<\/p>\n

      C'\u00e8 un cluster di server, dotato 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 per la cache. Quando i dati vengono scritti nel datastore, vengono salvati nella layer di caching (un SSD dedicato e RAM della VM di service). Parallelamente, il blocco di dati viene inviato ai nodi nel cluster (il numero di nodi dipende dal fattore di replicazione del cluster). Dopo la conferma di scrittura da tutti i nodi, la conferma della scrittura viene inviata all'hypervisor e poi alla VM. I dati scritti vengono deduplicati, compressi e registrati su dischi di archiviazione in background. In questo modo, su dischi di archiviazione viene sempre scritto un grande blocco in modo sequenziale, riducendo 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 della RAM. Se \u00e8 configurata una configurazione ibrida, anche la lettura viene memorizzata nella 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 uniformemente tutti i dischi e le interfacce di rete. C'\u00e8 un evidente svantaggio: non possiamo ridurre al minimo la latenza della lettura, poich\u00e9 non c'\u00e8 garanzia che i dati siano locali. Ma ritengo che sia un sacrificio trascurabile rispetto ai benefici ottenuti. Inoltre, le latenze di rete hanno raggiunto valori tali da non influenzare praticamente il risultato complessivo.<\/p>\n

      Per tutta la logica di funzionamento del sottosistema di archiviazione risponde una speciale VM di servizio Cisco HyperFlex Data Platform controller, 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, il che non \u00e8 affatto poco. Ricordo che l'host stesso dispone di 28 core fisici e 512 GB di RAM.<\/p>\n

      La VM di servizio ha accesso ai dischi fisici direttamente tramite il passaggio del controller SAS nella VM. La comunicazione con l'iper-V avviene attraverso un modulo speciale IOVisor, che intercetta le operazioni di input-output, e tramite un agente che consente di inviare comandi all'API dell'iper-V. L'agente si occupa della gestione degli snapshot HyperFlex e dei cloni.<\/p>\n

      Nel hypervisor, le risorse discali sono montate come NFS o SMB share (a seconda del tipo di hypervisor, indovinate quale dove). Sotto il cofano c'\u00e8 un file system distribuito, che consente di aggiungere funzionalit\u00e0 da veri sistemi di archiviazione: allocazione 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 di 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 datastore, ad esempio, \u00e8 pi\u00f9 comodo crearli da una web separata, se avete gi\u00e0 passato all'interfaccia veloce HTML5, oppure utilizzare un client Flash completo con piena integrazione. Nella web di servizio \u00e8 possibile consultare le prestazioni e lo stato dettagliato del sistema.<\/p>\n

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

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

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