{"id":82495,"date":"2020-05-22T01:42:27","date_gmt":"2020-05-21T23:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii"},"modified":"2020-05-22T01:42:27","modified_gmt":"2020-05-21T23:42:27","slug":"ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","title":{"rendered":"oVirt in 2 ore. Parte 1. Piattaforma di virtualizzazione open-source e fault-tolerant","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h2>\n

\nProgetto open source oVirt<\/a><\/noindex> \u00e8 una piattaforma di virtualizzazione di livello enterprise gratuita. Scorrendo su Habr, ho scoperto che oVirt<\/a><\/noindex> non \u00e8 cos\u00ec ampiamente trattato come meriterebbe.
\noVirt \u00e8 infatti l'upstream per il sistema commerciale Red Hat Virtualization (RHV, precedentemente RHEV), in crescita sotto l'ala di Red Hat. Per evitare confusione, \u00e8 non<\/b> lo stesso paragone tra CentOS e RHEL, il modello \u00e8 pi\u00f9 simile a Fedora rispetto a RHEL.
\nSotto il cofano \u2014 KVM<\/a><\/noindex>, per la gestione si utilizza un'interfaccia web. Si basa su RHEL\/CentOS 7.
\noVirt pu\u00f2 essere utilizzato sia per la virtualizzazione server \u00abtradizionale\u00bb che per la virtualizzazione desktop (VDI); a differenza della soluzione VMware, entrambi i sistemi possono coesistere nello stesso ambiente.
\nIl progetto \u00e8 ben documentato<\/a><\/noindex>, ha raggiunto da tempo la maturit\u00e0 per un'applicazione produttiva ed \u00e8 pronto per carichi elevati.
\nQuesto articolo \u00e8 il primo di una serie su come costruire un cluster altamente disponibile. Seguendo queste indicazioni, in breve tempo (circa 2 ore) otterremo un sistema completamente funzionante, anche se alcuni temi, ovviamente, non potranno essere esplorati in dettaglio; cercher\u00f2 di trattarli nei prossimi articoli.<\/a><\/noindex>
\nLo utilizziamo da diversi anni, partendo dalla versione 4.1. Attualmente il nostro sistema industriale \u00e8 ospitato su HPE Synergy 480 e ProLiant BL460c di decima generazione con CPU Xeon Gold.
\nAl momento della scrittura, la versione attuale \u00e8 la 4.3. <\/p>\n

Articoli<\/h2>\n

<\/p>\n

    \n
  1. Introduzione (Siamo qui)<\/li>\n
  2. Installazione del gestore (ovirt-engine) e degli hypervisor (hosts)<\/a><\/noindex><\/li>\n
  3. Impostazioni aggiuntive<\/a><\/noindex><\/li>\n<\/ol>\n

    Caratteristiche funzionali<\/h2>\n

    \nIn oVirt ci sono 2 entit\u00e0 principali: ovirt-engine e ovirt-host(s). Per chi \u00e8 ben familiarizzato con i prodotti VMware, oVirt, nel suo complesso, \u00e8 come vSphere, l'ovirt-engine \u2014 il layer di gestione \u2014 svolge funzioni simili a vCenter, mentre l'ovirt-host funge da hypervisor, come ESX(i). Poich\u00e9 vSphere \u00e8 una soluzione molto popolare, a volte far\u00f2 un confronto con essa.
    \n\"oVirt
    \nFig. 1 \u2014 pannello di controllo oVirt.<\/p>\n

    La maggior parte delle distribuzioni Linux e delle versioni di Windows \u00e8 supportata come macchine guest. Per le macchine guest ci sono agenti e dispositivi virtuali e driver virtio ottimizzati, in particolare il controller di disco e l'interfaccia di rete.
    \nPer implementare una soluzione ad alta disponibilit\u00e0 e tutte le funzionalit\u00e0 interessanti sar\u00e0 necessario uno storage condiviso. Sono supportati storage sia a blocchi FC, FCoE, iSCSI, sia storage file NFS e altri. Per implementare una soluzione ad alta disponibilit\u00e0, il sistema di storage deve essere anch'esso ad alta disponibilit\u00e0 (almeno 2 controller, multipathing).
    \nL'uso di storage locali \u00e8 possibile, ma per un reale cluster sono adatte solo le soluzioni di storage condiviso. Gli storage locali rendono la sistemi un insieme disomogeneo di hypervisor e anche se \u00e8 presente uno storage condiviso, non sar\u00e0 possibile assemblare un cluster. Il percorso pi\u00f9 corretto \u00e8 l'uso di macchine senza disco con boot from SAN, oppure dischi di volume minimo. \u00c8 probabile che tramite un vdsm hook sia possibile assemblare storage definiti dal software (ad es. Ceph) usando dischi locali e presentarli a VM, ma non l'ho esaminato seriamente.<\/p>\n

    Architettura<\/h4>\n

    \n\"oVirt
    \nFig. 2 \u2014 architettura oVirt.
    \nPer ulteriori dettagli sull'architettura, puoi consultare il     documentazione<\/a><\/noindex> sviluppatore.<\/p>\n

    \"oVirt
    \nFig. 3 \u2014 oggetti oVirt.<\/p>\n

    L'elemento superiore nella gerarchia \u2014 Centro dati<\/b>. Determina se vengono utilizzati archivi condivisi (shared) o locali, oltre al set di funzionalit\u00e0 utilizzato (compatibilit\u00e0, da 4.1 a 4.3). Pu\u00f2 esserci uno o pi\u00f9 archivi. Per molte opzioni, pu\u00f2 essere utilizzato il Data Center predefinito \u2014 Default.
    \nIl Data Center consiste in uno o pi\u00f9 Cluster<\/b>. Un cluster definisce il tipo di processore, le politiche di migrazione e altro. Per installazioni di piccole dimensioni, si pu\u00f2 anche limitare a un cluster predefinito.
    \nUn cluster, a sua volta, \u00e8 composto da Host<\/b>‘\u043e\u0432, \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u044e\u0449\u0438\u0445 \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u2014 \u043e\u043d\u0438 \u043d\u0435\u0441\u0443\u0442 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u043c\u0430\u0448\u0438\u043d\u044b, \u043a \u043d\u0438\u043c \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0435\u043d\u044b \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u0412 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u0435\u0442\u0441\u044f 2 \u0438\u043b\u0438 \u0431\u043e\u043b\u0435\u0435 \u0445\u043e\u0441\u0442\u043e\u0432. \u0425\u043e\u0442\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440 \u0441 1-\u043c \u0445\u043e\u0441\u0442\u043e\u043c, \u043d\u043e \u044d\u0442\u043e \u043d\u0435 \u0438\u043c\u0435\u0435\u0442 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043f\u043e\u043b\u044c\u0437\u044b.<\/p>\n

    In oVirt sono supportate molte funzionalit\u00e0, tra cui la migrazione in tempo reale delle macchine virtuali tra hypervisor (live migration) e archivi (storage migration), virtualizzazione desktop (virtual desktop infrastructure) con pool di VM, VM statefull e stateless, supporto per NVidia Grid vGPU, importazione da vSphere, KVM, e offre potenti API<\/a><\/noindex> e molto altro. Tutte queste funzionalit\u00e0 sono disponibili senza costi di licenza, mentre il supporto pu\u00f2 essere acquistato da Red Hat tramite partner regionali.<\/p>\n

    Informazioni sui prezzi di RHV<\/h4>\n

    \nIl costo non \u00e8 elevato rispetto a VMware, si acquista solo il supporto \u2014 senza obbligo di acquistare la licenza stessa. Il supporto \u00e8 disponibile solo per gli hypervisor e ovirt-engine, a differenza di vCenter Server che non comporta spese.<\/p>\n

    Esempio di calcolo per il primo anno di utilizzo<\/h4>\n

    \nConsideriamo un cluster di 4 macchine a 2 socket e i prezzi al dettaglio (senza sconti di progetto).
    \nAbbonamento standard RHV     costa $999<\/a><\/noindex> per socket\/anno (premium 365\/24\/7 \u2014 $1499), totale 4*2*$999=$7992<\/b>.
    \n    Prezzo di vSphere<\/a><\/noindex>:<\/p>\n