OpenShift Virtualization è la soluzione di Red Hat per le aziende che puntano alla modernizzazione adottando un'architettura containerizzata per le applicazioni, ma ritengono che la virtualizzazione sia ancora una parte necessaria della strategia di deployment dei data center.
Alcune applicazioni non possono ancora essere containerizzate, ma va bene così. OpenShift Virtualization risolve questo problema fornendo un paradigma più moderno, che gestisce in modo coerente la necessità di container e macchine virtuali in una piattaforma unificata.
Una delle questioni che noi di Red Hat dobbiamo affrontare è: oltre a garantire funzionalità dello stesso livello, come possiamo mantenere un'esperienza del cliente simile a quella dei prodotti e delle configurazioni a cui è abituato, in modo che l'adozione della nuova soluzione sia sostanzialmente indolore?
Quando le persone lavorano all'interno di un ecosistema IT in cui si sentono a proprio agio, in genere cercano di adattare principi familiari ai nuovi sistemi. Per molti amministratori di sistema, VMware vSphere è stata una soluzione comune per la virtualizzazione dei data center. Le persone che lavorano in questo ambiente hanno presentato molte soluzioni di progettazione che sono state adottate come procedure consigliate per il deployment e la configurazione di macchine virtuali o data center virtuali. Per chi lavora in questo settore dell'IT, spesso queste decisioni progettuali sembrano istintive e probabilmente cercherebbero di applicarne di simili agli altri ambienti che stanno pianificando.
Questa serie di articoli del blog analizzerà le differenze tra il modo in cui le aziende e gli amministratori della virtualizzazione interagivano con gli ambienti hypervisor precedenti e come possono aspettarsi di eseguire azioni o configurazioni simili nel mondo di OpenShift Virtualization.

In primo luogo, concentriamoci sulla progettazione di reti multiple, molto diffusa con altre soluzioni di virtualizzazione, come VMware vSphere. Chi ha familiarità con questo ambiente sa che è proprio qui che gli host ESXi supportano varie reti e, all'interno del data center virtuale, ogni rete virtuale è dedicata a uno scopo diverso. Questa segregazione della rete può essere eseguita in diversi modi, dal cablaggio di diverse NIC fisiche sugli host a diversi switch o reti upstream o tramite il trunking di VLAN aggiuntive su un uplink e la verifica che stiano applicando tag appropriati sul vSwitch o sul Distributed vSwitch all'interno dell'hypervisor stesso per indicare lo scopo desiderato. Nella maggior parte dei casi, la rete è suddivisa almeno nel modo seguente:
- Una rete di gestione per gli host ESXi e la macchina virtuale vCenter, nonché per altri host di gestione di terze parti che possono essere distribuiti.
- Una rete di migrazione degli host per gli host ESXi per supportare la migrazione a caldo dei guest, nota come vMotion, tra host per fornire alta disponibilità.
- Una rete di storage host che consente agli host ESXi di accedere alle risorse che forniscono storage di backup o lo storage mappato ai guest per le macchine virtuali.
- Una rete di macchine virtuali che fornisce connettività di rete ai guest virtuali stessi.
Oltre alle reti sopra elencate, è comune imbattersi in configurazioni e finalità di rete univoche a seconda degli scenari di utilizzo di quel particolare ambiente del cliente. Lo switch virtuale, per sua natura, consente di implementare facilmente un gran numero di configurazioni diverse. Non stupisce che chi ha l'abitudine di definire le proprie reti in base ai metodi comuni possa avere delle sorprese quando decide di adottare una soluzione come OpenShift Virtualization, che opera in modo diverso.
Le sezioni seguenti esaminano ciascuno degli scenari di utilizzo principali sopra identificati e illustrano in che modo OpenShift Virtualization soddisfa queste esigenze.
Per impostazione predefinita, OpenShift Virtualization viene installato con una singola rete pod interna. Come qualsiasi altra applicazione distribuita in un ambiente Kubernetes, questa rete interna viene utilizzata per comunicare con il pod stesso per l'intera durata del suo ciclo di vita. Utilizzando la console OpenShift, l'utility CLI virtctl o il comando oc, si possono eseguire tutte le funzioni di gestione essenziali per i guest virtuali sulla rete API interna. In sostanza, questa rete in OpenShift Virtualization esegue le stesse azioni che un amministratore si aspetta dalla propria rete di gestione interna in VMware vSphere.

Sebbene tutte le funzioni di rete in un ambiente OpenShift possano essere gestite sulla rete di pod predefinita, come le funzioni di gestione descritte sopra per una configurazione semplice, spesso questa operazione non è auspicabile. Alcune attività, come le migrazioni dei guest virtuali e l'accesso allo storage, traggono grandi vantaggi dall'accesso diretto su reti dedicate. Sebbene esistano metodi per ottimizzare le prestazioni di determinate azioni, come le migrazioni dei guest, tramite i criteri di migrazione, in modo da limitare la quantità di larghezza di banda utilizzata, la maggior parte degli utenti aziendali concorda sul fatto che disporre di reti dedicate per funzioni aggiuntive come le migrazioni dei guest, lo storage e l'accesso dei guest virtuali è sia desiderabile che più familiare per chi ha già operato in un ambiente VMware vSphere.
A tale scopo, OpenShift utilizza il plugin Multus CNI, che consente di configurare interfacce di rete aggiuntive, SR-IOV o dispositivi bridge Linux disponibili per i nodi di lavoro, consentendo di collegarli ai singoli pod in base alle esigenze.
Prima di installare Multus, il client deve configurare la rete alla base in modo appropriato. Nel caso dei bridge Linux, questa operazione viene eseguita utilizzando l'operatore nmstate. Per i dispositivi SR-IOV, bisogna utilizzare l'operatore SR-IOV. Una volta configurato l'ambiente di rete, l'amministratore può iniziare a configurare una definizione dell'allegato di rete, che indica a OpenShift come utilizzare interfacce fisiche aggiuntive, dispositivi SR-IOV o bridge Linux che li definiscono.

A questo punto, si può approfondire la configurazione per le migrazioni in tempo reale. Molti deployment di VMware vSphere hanno una rete dedicata definita per supportare vMotion, a causa delle esigenze di larghezza di banda della migrazione in tempo reale. Un evento di migrazione in tempo reale che si verifica in un'infrastruttura senza una rete dedicata a tale scopo può avere un'influenza negativa sulle risorse di rete condivise, come i guest virtuali. Inoltre, può incidere sulla gestione dell'ambiente stesso, nel caso in cui un nodo non fosse disponibile e più guest fossero costretti a eseguire la migrazione in simultanea. OpenShift Virtualization dispone di diverse opzioni che proteggono gli eventi di migrazione in tempo reale da effetti negativi sulla rete principale o sulle prestazioni del cluster.
La prima consiste nel definire una policy di migrazione che includa regole, anche per limitare la larghezza di banda disponibile per le migrazioni. È anche possibile definire una rete dedicata per le migrazioni in tempo reale modificando le impostazioni del cluster nelle impostazioni della panoramica di OpenShift Virtualization. In questo menu è possibile limitare il numero di migrazioni in tempo reale che possono essere eseguite in un dato momento, preservando la larghezza di banda. Si può anche modificare la rete utilizzata per le migrazioni in tempo reale.
Per farlo, occorre creare una definizione di appendice di rete per un'interfaccia di rete dedicata sui nodi di lavoro, definire una rete privata che consenta la connettività solo tra i nodi di lavoro configurati per supportare la virtualizzazione e selezionarla. In questo modo, quando un guest viene selezionato per la migrazione o un host viene sottoposto a manutenzione, costringendo tutti i guest a lasciare il servizio, verrà utilizzata la rete dedicata per le migrazioni in tempo reale, evitando così di aggiungere un ulteriore carico all'infrastruttura di rete OpenShift principale.
La rete per le risorse di storage dipende dal provider di storage utilizzato per il cluster OpenShift. Molti provider dispongono di driver nativi compatibili con CSI per i sistemi che applicano automaticamente le procedure consigliate specificate per la connettività dello storage.
Dal punto di vista di OpenShift Virtualization, ci sono alcune procedure consigliate per configurare le classi di storage per supportare i guest virtuali. Ad esempio, i volumi permanenti di cui è stato eseguito il provisioning per le VM devono essere in modalità RWX, in modo che altri nodi possano accedere al volume permanente nel caso in cui si debba eseguire la migrazione del guest virtuale su un altro nodo. Come per la migrazione, i nodi di lavoro possono essere configurati per accedere allo storage tramite la rete di gestione predefinita oppure collegati a una rete separata per fornire connettività per i volumi permanenti basati su NFS o iSCSI. In molti casi, la gestione o la rete pod predefinita in OpenShift ha il compito di inizializzare le chiamate API al sistema di storage indicato. Il driver CSI verificherà che il volume di cui è stato eseguito il provisioning sia mappato correttamente sulla rete di storage disponibile.
Infine, prendiamo in considerazione l'accesso pubblico alle applicazioni in esecuzione nella VM o direttamente alla macchina virtuale. Per gli utenti che non sono ancora pronti a containerizzare le proprie applicazioni, è possibile trattare le applicazioni attualmente in esecuzione su macchine virtuali come quelle che vengono eseguite insieme a loro nei container. A tale scopo, bisogna applicare un tag a una macchina virtuale che identifichi l'applicazione a cui si desidera fornire l'accesso. Usando quel tag per identificarla, si crea un servizio Kubernetes per le porte necessarie all'applicazione sulla macchina virtuale. Questo servizio può quindi essere esposto creando un percorso OpenShift e consentendo l'accesso direttamente all'applicazione anziché al guest virtuale nel suo insieme tramite la rete di pod OpenShift predefinita, proprio come un'applicazione containerizzata.
L'accesso a un guest virtuale in questo modo è un passaggio di transizione tra la virtualizzazione e la containerizzazione delle applicazioni. Coloro che desiderano un approccio più tradizionale con accesso diretto al sistema operativo guest di una macchina virtuale possono creare una definizione dell'allegato di rete e un'associazione a un bridge Linux o a un dispositivo SR-IOV disponibile su ogni nodo di lavoro abilitato per ospitare guest virtuali. Ciò conferma che al guest virtuale viene assegnato un IP esterno e che gli utenti possono connettersi direttamente al guest tramite SSH o usando il protocollo di accesso remoto preferito.
Quando si collegano reti aggiuntive ai guest virtuali occorre tenere a mente che il bridge Linux, le interfacce fisiche disponibili e i tag VLAN devono essere definiti in modo identico e disponibili su ogni nodo di lavoro nel cluster per supportare l'alta disponibilità delle macchine virtuali guest nel caso in cui sia necessario eseguire la migrazione a un nodo diverso del cluster.
Identificare i modi in cui si può configurare l'architettura di rete di una soluzione OpenShift Virtualization distribuita per fornire prestazioni e comportamenti simili ad altri ambienti hypervisor diffusi come VMware vSphere può aiutare i clienti a vivere un'esperienza coinvolgente con il prodotto. Noi di Red Hat riteniamo che le esperienze positive aumentino la soddisfazione dei clienti e l'adozione dei prodotti , cosa che a sua volta facilita la modernizzazione delle applicazioni.
Per saperne di più sulla modernizzazione delle applicazioni e sui vantaggi di OpenShift Virtualization, puoi partecipare a uno dei prossimi eventi dal vivo, come Red Hat Summit Connect o l'OpenShift Virtualization Road Show, in cui faremo una panoramica del prodotto e terremo un laboratorio pratico dedicato a OpenShift Virtualization.
Sull'autore
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit