Guida alla sottoscrizione della versione autogestita di Red Hat OpenShift

Questo documento ti aiuta a comprendere il modello di sottoscrizione per le offerte autogestite di Red Hat® OpenShift® e fornisce istruzioni dettagliate per determinare la quantità di diritti necessaria per un ambiente Red Hat OpenShift. Informazioni più specifiche sul dimensionamento sono disponibili su richiesta.

Iniziamo illustrando alcuni termini che è necessario comprendere prima di procedere:

• Coppia di core: è uno dei concetti su cui si basano le sottoscrizioni della versione autogestita di OpenShift ed è definita come 2 core fisici o 4 core virtuali (vCPU). In un sistema bare metal, il termine fa sempre riferimento al core fisico, indipendentemente dall'impiego o meno di una tecnologia di hyperthreading o di multithreading simmetrico. Se l'hyperthreading è abilitato, 2 core fisici che si presentano come 4 vCPU vengono comunque conteggiati come una singola coppia di core. Nei deployment su hyperscaler come AWS, Azure e GCP, 4 vCPU vengono sempre considerati come una singola coppia di core. Essendo conteggiate a livello di cluster, le sottoscrizioni basate su coppia di core possono estendersi a più istanze cloud, macchine virtuali (VM) e server fisici.
• Coppia di socket bare metal: è l'altro concetto su cui si basano le sottoscrizioni della versione autogestita di OpenShift. Per ogni server è necessaria almeno una sottoscrizione basata su coppia di socket bare metal, che copre un massimo di 128 core. Una singola sottoscrizione basata su coppia di socket bare metal non può coprire più di un server, e lo stesso vale per i core in una sottoscrizione. Per coprire un numero di core e di socket più elevato è possibile accumulare più sottoscrizioni basate su coppia di socket bare metal.
• AI Accelerator: il numero di sottoscrizioni Red Hat AI Accelerator necessarie si basa sul numero di dispositivi hardware fisici aggiuntivi utilizzati per accelerare determinate funzioni di calcolo all'esterno delle CPU. Può trattarsi, a titolo esemplificativo, di unità di elaborazione grafica (GPU) distinte, unità di elaborazione sensoriali (TPU), unità di elaborazione dati (DPU), field-programmable gate array (FPGA), circuiti integrati specifici dell'applicazione (ASIC) e unità di elaborazione di rete (NPU) installate come componenti aggiuntivi. Non sono inclusi gli acceleratori integrati con la CPU principale, ad esempio GPU, NPU e altri tipi di acceleratori integrati. Benché questi possano essere virtualizzati e presentati a più di una istanza o VM e possano disporre di uno o di molti core simili ai core della CPU, la sottoscrizione si basa sul numero di dispositivi fisici.
• SLA: per le sottoscrizioni Red Hat sono necessari i contratti di servizio (SLA, Service Level Agreement). I contratti sono disponibili con i livelli di supporto Standard (8/5) o Premium (24/7).
• Nodo di calcolo: si tratta delle istanze (host bare metal o VM) di Red Hat Enterprise Linux® o Red Hat Enterprise Linux CoreOS in cui vengono eseguiti i pod delle applicazioni per gli utenti finali. Gli ambienti OpenShift possono includere numerosi nodi di calcolo per i quali sono necessarie le sottoscrizioni OpenShift. Per i nodi del piano di controllo e per quelli dell'infrastruttura che supportano i nodi di calcolo non sono necessarie sottoscrizioni. Tali nodi tuttavia possono implicare costi di infrastruttura aggiuntivi.
• Nodi del piano di controllo: si tratta di istanze (host bare metal o VM) di Red Hat Enterprise Linux CoreOS utilizzate come agenti di orchestrazione Kubernetes o come livello di gestione per Red Hat OpenShift. I diritti dei nodi del piano di controllo sono compresi nelle sottoscrizioni della versione autogestita di OpenShift e non devono essere conteggiati per determinare il numero di sottoscrizioni da acquistare. Per ulteriori informazioni, vedi la sezione dedicata ai nodi dell'infrastruttura e del piano di controllo di Red Hat OpenShift.
• Nodi dell'infrastruttura: sono i nodi che eseguono i pod di supporto dell'infrastruttura cluster di OpenShift e non le istanze dell'applicazione. Ad esempio, sono i nodi che eseguono il bilanciamento del carico basato su HAProxy per il traffico in entrata. I diritti dei nodi dell'infrastruttura sono inclusi nelle sottoscrizioni della versione autogestita di OpenShift e non devono essere conteggiati per determinare il numero di sottoscrizioni da acquistare, a condizione che non eseguano istanze applicative degli utenti.
• Cluster: un cluster OpenShift Kubernetes formato da un piano di controllo, dai nodi dell'infrastruttura facoltativi e da uno o più nodi di calcolo.

Istanza applicativa: una "applicazione" può corrispondere a una singola istanza di pod oppure può essere distribuita su più istanze di pod che formano un servizio applicativo. Ad esempio, un servizio applicativo ad alta disponibilità può essere formato da due o più pod. Le istanze applicative devono sempre essere eseguite su nodi di calcolo autorizzati con sottoscrizioni Red Hat OpenShift.

Red Hat OpenShift offre una piattaforma coerente per lo sviluppo e la gestione delle applicazioni in un ambiente di cloud ibrido e aperto, oltre a supportare le infrastrutture on premise, virtuali e fisiche, così come i deployment nei cloud pubblici, privati e all'edge. La piattaforma Red Hat OpenShift può essere gestita e utilizzata in due modi, ovvero come ambiente autogestito oppure come una serie di servizi cloud OpenShift completamente gestiti. Questa guida prende in esame la versione autogestita di OpenShift.

La versione autogestita di OpenShift offre i massimi livelli di controllo, flessibilità e personalizzazione sull'installazione, sull'utilizzo e sulla gestione di Red Hat OpenShift, consentendoti di gestire il tuo ambiente specifico a partire dall'infrastruttura. È possibile utilizzare la versione autogestita di OpenShift negli ambienti on premise che utilizzano server fisici, negli ambienti virtualizzati e nei cloud privati, oltre che negli ambienti di cloud pubblico supportati, controllando gli upgrade, gestendo il livello inferiore dell'infrastruttura e garantendo la conformità agli accordi sul livello del servizio (SLA).

I servizi cloud OpenShift gestiti , invece, vengono completamente gestiti ed eseguiti da Red Hat e dai suoi partner, nei cloud pubblici più importanti. L'infrastruttura e i servizi principali di Red Hat OpenShift vengono gestiti e curati da un team di site reliability engineering (SRE) dedicato, per consentire ai tuoi team DevSecOps interni di concentrarsi sullo sviluppo e sul deployment delle nuove applicazioni, o sul rinnovo di quelle esistenti.

Di seguito l'offerta di servizi cloud OpenShift e le indicazioni per reperire ulteriori informazioni:

• Red Hat OpenShift Dedicated: è un servizio gestito di Red Hat OpenShift e ospitato su Amazon Web Services (AWS) e Google Cloud Platform.
• Microsoft Azure Red Hat OpenShift: è un servizio Red Hat OpenShift completamente gestito, disponibile su Microsoft Azure, che viene fornito congiuntamente da Red Hat e Microsoft.
• Red Hat OpenShift Service on AWS: è un servizio Red Hat OpenShift completamente gestito, disponibile su Amazon Web Services, che viene fornito congiuntamente da Red Hat e AWS.
• Red Hat OpenShift Service on IBM Cloud: è un servizio Red Hat OpenShift completamente gestito, disponibile su IBM Cloud, che viene fornito congiuntamente da Red Hat e IBM.

Tutte le edizioni di Red Hat OpenShift offrono un'esperienza operativa e di sviluppo coerente in tutti gli ambienti, permettendoti di sfruttare le tue competenze e trasferire le tue applicazioni negli ambienti cloud che garantiscono la massima efficienza di esecuzione.

Le versioni autogestite di OpenShift (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine e Red Hat OpenShift Virtualization Engine) possono essere utilizzate in qualunque ambiente supportato e certificato per la versione a 64 bit di Red Hat Enterprise Linux. Consulta  la documentazione per saperne di più su metodi di deployment e tipi di infrastrutture supportate per OpenShift.

Edizioni software OpenShift autogestite:

• Red Hat OpenShift Kubernetes Engine: è un motore di runtime Kubernetes di livello enterprise per il cloud ibrido, che fornisce le principali funzionalità di OpenShift per il deployment e l'esecuzione delle applicazioni. Può essere installato e gestito in un datacenter, negli ambienti di cloud pubblico o all'edge.
• Red Hat OpenShift Container Platform:   è una piattaforma applicativa Kubernetes di livello enterprise per il cloud ibrido, ricca di funzionalità per la creazione, il deployment e l'esecuzione delle applicazioni. Può essere installata e gestita in un datacenter, negli ambienti di cloud pubblico e all'edge.
• Red Hat OpenShift Platform Plus:  è una piattaforma di cloud ibrido utilizzabile per la creazione, il deployment, l'esecuzione e la gestione di applicazioni intelligenti su vasta scala, su più cluster e in vari ambienti cloud. Offre diversi livelli di sicurezza, gestibilità e automazione che garantiscono la coerenza lungo l'intera catena di distribuzione del software. Le sottoscrizioni OpenShift Platform Plus sono disponibili solo per cluster x86.
• Red Hat OpenShift Virtualization Engine: è un'infrastruttura di virtualizzazione esclusivamente bare metal basata su Red Hat OpenShift e sull'hypervisor open source Kernel-based Virtual Machine (KVM), appositamente progettata per fornire una soluzione di livello enterprises affidabile per il deployment, la gestione e la scalabilità delle VM. Composta da una selezione di funzionalità di OpenShift, questa edizione è destinata esclusivamente ai carichi di lavoro delle macchine virtuali, con servizi per l'infrastruttura supportati solo in container; non prevede alcun supporto per i container delle applicazioni degli utenti finali.

Tipi di sottoscrizione

Per la versione autogestita di OpenShift esistono due tipi di sottoscrizione (basata su coppia di core e basata su coppia di socket bare metal), ognuna con due livelli di supporto disponibili.

Per i nodi di calcolo presenti nell'ambiente sono necessarie le relative sottoscrizioni, i cui diritti possono essere assegnati per coppie di core o per coppie di socket bare metal.

1. Coppia di core (2 core o 4 vCPU)
   • Questa opzione di sottoscrizione è disponibile per OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus. Le sottoscrizioni basate su coppia di core  non sono applicabili a OpenShift Virtualization Engine.
   • Quando si quantificano i diritti per i core delle CPU, occorre considerare il numero aggregato di core fisici o vCPU presenti su tutti i nodi di calcolo OpenShift eseguiti in tutti i cluster OpenShift a cui si intende assegnare i diritti tramite sottoscrizioni basate su coppia di core.
   • È disponibile con il supporto Standard (8/5) o Premium (24/7).
2. Coppia di socket bare metal (1-2 socket con un massimo di 128 core)
   • Questa opzione di sottoscrizione è disponibile per tutte le edizioni autogestite di OpenShift ed è l'unica opzione per OpenShift Virtualization Engine.
   • È disponibile solo per nodi x86 e nodi fisici bare metal ARM nei quali OpenShift è installato direttamente nell'hardware. Non consente l'utilizzo di hypervisor di terze parti.
   •  Non si tratta di una sottoscrizione "Virtual Datacenter" come Red Hat Enterprise Linux for Virtual Datacenters, in cui una singola sottoscrizione consente installazioni illimitate del sistema operativo guest della VM su qualsiasi host hypervisor.
   • È disponibile con il supporto Standard (8/5) o Premium (24/7).
   • Questo tipo di sottoscrizione è cumulabile per i server bare metal con più di 2 socket o con più di 128 core, ma una singola sottoscrizione non può coprire più server bare metal.

In aggiunta, per gli acceleratori presenti nell'ambiente sono necessarie le sottoscrizioni Red Hat AI Accelerator:

1. AI Accelerator (1 acceleratore)
   • Questa sottoscrizione è necessaria per le schede degli acceleratori (GPU, TPU, NPU, FPGA, DPU, ecc.) che forniscono l'accelerazione di calcolo per i carichi di lavoro di IA che sono componenti aggiuntivi distinti e non fanno parte del pacchetto della CPU.
   • Si utilizza la stessa sottoscrizione per ogni AI Accelerator fisico, indipendentemente dalla versione di Red Hat OpenShift.
   • Se Red Hat OpenShift e OpenShift AI sono entrambi installati sul cluster, è sufficiente un'unica sottoscrizione AI Accelerator.
   • La sottoscrizione non è necessaria se la capacità dell'acceleratore non è utilizzata per accelerare il calcolo, come nel caso delle DPU utilizzate come SmartNIC per l'accelerazione della rete (solo se dispongono di core ARM indirizzabili), o delle GPU utilizzate per accelerare il rendering delle immagini e non per l'accelerazione di IA.
   • È disponibile con il supporto Standard (8/5) o Premium (24/7). Lo SLA deve corrispondere a quello della sottoscrizione basata su coppia di core o su coppia di socket bare metal supportata.

Quando scegliere le sottoscrizioni basate su coppia di core

In genere, le sottoscrizioni basate su coppia di core sono da preferire quando si distribuisce la versione autogestita di OpenShift su hyperscaler nel cloud pubblico, in un'infrastruttura IaaS di cloud privato, o su hypervisor come VMware vSphere, Red Hat OpenStack® Platform o Nutanix.

Tali sottoscrizioni consentono di evitare di associare le sottoscrizioni ai server fisici e permettono di distribuire liberamente i pod nel cloud ibrido.

Le sottoscrizioni basate su coppia di core possono essere utilizzante anche su dispositivi e server bare metal, senza hypervisor. Esiste in genere una determinata densità del pod di calcolo per la quale le sottoscrizioni basate su coppia di socket bare metal possono essere più convenienti in termini economici.

Quando la piattaforma di virtualizzazione dedicata è OpenShift Virtualization Engine, è possibile associare i container OpenShift delle VM utilizzando le sottoscrizioni basate su coppia di core, in aggiunta a quelle basate su coppia di socket bare metal dell'hypervisor. Occorre acquistare le sottoscrizioni basate su coppia di core della versione autogestita di OpenShift e assegnarle alle VM dell'ambiente, proprio come per qualsiasi altra applicazione acquistata ed eseguita come VM. In questo caso, esiste una densità di core per cui potrebbe essere più conveniente il passaggio alla sottoscrizione basata su coppia di socket bare metal per la versione autogestita di OpenShift, poiché questa include container OpenShift illimitati sul server bare metal e il supporto per la loro esecuzione su VM OpenShift.

Le sottoscrizioni basate su coppia di core possono essere distribuite in modo da coprire tutti i nodi di calcolo OpenShift in esecuzione su tutti i cluster OpenShift. Ad esempio, 100 sottoscrizioni di Red Hat OpenShift Platform Plus basate su coppia di core corrispondono a 200 core (400 vCPU) che possono essere utilizzati sui nodi di calcolo OpenShift di tutti i cluster OpenShift in esecuzione negli ambienti di cloud ibrido.

Quando scegliere le sottoscrizioni basate su coppia di socket bare metal

Le sottoscrizioni basate su coppia di socket bare metal sono un'opzione esclusiva per i nodi di calcolo di OpenShift distribuiti su server fisici dedicati, che si trovino nel datacenter, in un cloud privato in hosting in un'offerta bare metal supportata o con un hyperscaler nell'ambito di un'offerta bare metal supportata. Sono l'unica opzione disponibile per OpenShift Virtualization Engine, e sono necessarie per supportare la funzionalità OpenShift Virtualization nelle altre edizioni di OpenShift autogestite.

Ogni sottoscrizione basata coppia di socket bare metal autorizza un massimo di 128 core fisici nella coppia di socket. Queste sottoscrizioni sono cumulabili sia per coprire le coppie di socket con oltre 128 core totali, sia i server fisici con più di una coppia di socket.

Per autorizzare un server fisico, si deve acquistare un numero di sottoscrizioni sufficiente a coprire il numero totale di socket o di core fisici di cui è dotato il server (il numero più alto fra i due). Si prenda come esempio un server con 2 socket con 48 core in ogni CPU, per un totale di 96 core. Una sottoscrizione è necessaria perché il server è dotato di 1 o 2 socket e di meno di 128 core. Per un secondo server con 2 socket e 192 core totali, sarebbero necessarie 2 sottoscrizioni. Per coprire 192 core occorrono due sottoscrizioni, perché una singola sottoscrizione copre al massimo 128 core. Non è possibile suddividere su più host fisici una singola sottoscrizione basata su coppia di socket bare metal, ad esempio per coprire 2 server ognuno con un solo socket o più core su server distinti.

Considerata la peculiare architettura di Kubernetes, ogni server bare metal fisico che utilizza diritti basati su socket può essere impiegato esclusivamente come singolo nodo OpenShift. Poiché in Kubernetes ogni nodo può appartenere solo a un singolo cluster, tutti i container di un server bare metal si troveranno sullo stesso cluster. La sottoscrizione risulta quindi adatta ai carichi di lavoro a elevato consumo di risorse come OpenShift Virtualization (in cui ogni carico di lavoro esegua una VM completa), ma non ad altri. Mentre OpenShift supporta fino a 2.500 container su un singolo nodo, ci sono situazioni in cui, per motivi prestazionali o architetturali, è preferibile suddividere i container tra diversi nodi o diversi cluster. Per farlo, è necessario avvalersi della virtualizzazione per creare nodi di calcolo distinti sul server bare metal.

Un modello di deployment per container molto diffuso prevede la creazione di numerosi cluster contenenti ognuno piccole quantità di container. Questo approccio è comune negli ambienti hyperscaler; nel datacenter è possibile utilizzare un hypervisor per creare le VM che diventeranno i nodi di calcolo sui quali verranno distribuiti i container. Per hypervisor quali VMware vSphere, Red Hat OpenStack Platform e Nutanix, è necessario utilizzare le sottoscrizioni basate su coppia di core se OpenShift è distribuito sulle VM.

I cluster OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus distribuiti su bare metal e associati a sottoscrizioni a coppia di socket includono OpenShift Virtualization e le sottoscrizioni per qualsiasi cluster OpenShift virtuale dello stesso tipo di prodotto in essi distribuito. Ad esempio, i cluster OpenShift virtuali distribuiti su un cluster OpenShift Container Platform bare metal ereditano le sottoscrizioni OpenShift Container Platform dal cluster bare metal che li ospita.

È importante notare che la sottoscrizione OpenShift Virtualization Engine non include il supporto per le istanze applicative containerizzate, ad eccezione dei carichi di lavoro dell'infrastruttura definiti più avanti, nella sezione relativa a OpenShift Virtualization Engine. Se intendi eseguire i carichi di lavoro della tua applicazione containerizzata con OpenShift Virtualization Engine, devi associare le VM utilizzando le sottoscrizioni basate su coppia di core per la versione autogestita di OpenShift. Con maggiori densità, puoi invece scegliere di acquistare una sottoscrizione per coppia di socket bare metal per le versioni autogestite di OpenShift Kubernetes Engine, OpenShift Container Platform o OpenShift Platform Plus. In questo modo puoi eseguire in modo nativo le applicazioni containerizzate sul cluster bare metal o sulle sottoscrizioni ereditate dai cluster virtuali, come descritto nel paragrafo precedente.

Non è possibile combinare tipi di prodotti OpenShift nello stesso cluster e tutti i nodi devono avere sottoscrizioni per lo stesso tipo di prodotto OpenShift Virtualization Engine, OpenShift Kubernetes Engine, OpenShift Container Platform o OpenShift Platform Plus. In un singolo cluster è tuttavia possibile utilizzare sottoscrizioni basate su coppia di core e su coppia di socket. Ad esempio, non puoi disporre di un singolo cluster bare metal con alcuni nodi di OpenShift Virtualization Engine per l'hosting delle VM e altri nodi sottoscritti tramite OpenShift Platform Plus per l'hosting di applicazioni containerizzate e istanze di OpenShift virtuali.

Come conteggiare le sottoscrizioni AI Accelerator

Negli ultimi anni, sono emerse sul mercato tecnologie hardware specifiche che consentono l'esecuzione più veloce di alcuni carichi di lavoro di calcolo. Queste tipologie di dispositivi hardware vengono collettivamente indicate come acceleratori o acceleratori di IA in alcuni documenti di Red Hat. Numerosi tipi di dispositivi hardware utilizzabili con i moderni server possono essere classificati come acceleratori, tra cui GPU, TPU, ASIC, NPU e FPGA.

Può trattarsi di schede o altri dispositivi fisici che possono occupare gli slot PCI di un server, di solito nella quantità unitaria che l'utente acquista dal fornitore del dispositivo di accelerazione. Ciò significa che in un server definito dal fornitore come "dotato di 8 GPU", si trovano verosimilmente 8 acceleratori fisici.

Ogni sottoscrizione AI Accelerator copre un dispositivo di accelerazione fisico. Ad esempio, concentriamoci solo sulle sottoscrizioni AI Accelerator:

• Un nodo di calcolo fisico con 4 dispositivi GPU fisici richiederebbe 4 sottoscrizioni AI Accelerator in aggiunta alle sottoscrizioni basate su coppia di core o coppia di socket della CPU che coprono il nodo di calcolo.
• Un singolo nodo di calcolo virtuale con 1 dispositivo GPU fisico presentato alle VM come più vGPU richiederebbe una sottoscrizione AI Accelerator, perché il conteggio si basa sugli acceleratori fisici e non su quelli virtuali.

Gli acceleratori vengono conteggiati solo se utilizzati per eseguire un carico di lavoro di calcolo. Un carico di lavoro viene considerato di calcolo quando il suo scopo principale non è quello di rappresentare in modo attivo e in tempo reale i pixel sullo schermo di un utente o di spostare i dati in una rete.

È importante fare questa distinzione perché le applicazioni per gli effetti speciali e per lo streaming possono utilizzare le GPU e altri acceleratori hardware, ma in questi casi la finalità è inerente ai pixel sullo schermo. Un carico di lavoro non è considerato di calcolo anche nelle situazioni in cui la sua funzione principale è lo spostamento di dati in una rete, come nel caso delle unità di elaborazione dati dedicate alle funzioni di rete.

Sono esempi di carichi di lavoro di calcolo:

• Applicazioni software tradizionali, come Java, Python e Perl.
• LLM o altri software a utilizzo intensivo di risorse di calcolo.
• Addestramento e ottimizzazione di modelli di data science.
• Modellazioni e simulazioni in ambito scientifico o fisico, utilizzate ad esempio per elaborare il ripiegamento proteico o la dinamica dei fluidi.

Nodi dell'infrastruttura e del piano di controllo di Red Hat OpenShift

Tutte le sottoscrizioni della versione autogestita di Red Hat OpenShift includono diritti per Red Hat OpenShift e per altri componenti correlati a OpenShift. OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus includono diritti per Red Hat Enterprise Linux per i nodi dell'infrastruttura e di calcolo. Red Hat OpenShift Virtualization Engine non supporta i nodi di lavoro o dell'infrastruttura standard di Red Hat Enterprise Linux, ma solo il sistema operativo Red Hat Enterprise Linux CoreOS che fa parte dei diritti di OpenShift.

Questi diritti sono inclusi per eseguire il piano di controllo e l'infrastruttura OpenShift richiesta, ma non entrano nel conteggio che determina il numero di sottoscrizioni Red Hat necessarie.

Le sottoscrizioni Red Hat OpenShift Platform Plus includono anche la gestione di tutti i nodi da parte di Red Hat Advanced Cluster Security for Kubernetes e Red Hat Advanced Cluster Management for Kubernetes.

Un'installazione tipica distribuisce un piano di controllo OpenShift ad alta disponibilità formato da tre nodi del piano di controllo, in aggiunta a un minimo di due nodi di calcolo di OpenShift necessari per eseguire le applicazioni degli utenti finali. Per impostazione predefinita, i componenti del piano di controllo Kubernetes (ad esempio il server API, etcd e l'utilità di pianificazione) e i servizi cluster di supporto (ad esempio il servizio di monitoraggio e il registro) vengono installati nei nodi del piano di controllo di OpenShift. È comunque possibile trasferire alcuni dei servizi cluster di supporto su nodi dedicati dell'infrastruttura.

Per essere considerate nodi dell'infrastruttura e usufruire dei diritti inclusi, le istanze devono eseguire esclusivamente i componenti necessari per il supporto del cluster, e non componenti che fanno parte delle applicazioni per gli utenti finali. Ad esempio:

• Registro di OpenShift.
• Router di ingresso di OpenShift (ingresso multicluster, locale e globale).
• OpenShift Observability
• Istanze basate su HAProxy per il traffico in entrata nel cluster.
• Red Hat Quay.
• Red Hat OpenShift Data Foundation.
• Red Hat Advanced Cluster Management for Kubernetes.
• Red Hat Advanced Cluster Security for Kubernetes.
• Red Hat OpenShift GitOps.
• Red Hat OpenShift Pipelines.
• Piani di controllo in hosting per Red Hat OpenShift.

Sui nodi dell'infrastruttura si possono distribuire ed eseguire anche agenti e strumenti personalizzati o di terze parti (come gli agenti di virtualizzazione), per il monitoraggio, la raccolta e l'inoltro dei dati dei log, i driver hardware e l'integrazione dell'infrastruttura, senza pregiudicare l'idoneità del nodo alla licenza per l'infrastruttura. Questa possibilità è limitata esclusivamente agli agenti e ai componenti correlati, inclusi i pod di controllo per gli operatori, e non si applica alle suite software personalizzate o di terze parti. Ecco alcuni esempi di prodotti software non Red Hat idonei come carichi di lavoro infrastrutturali:

• Agenti di monitoraggio di terze parti o personalizzati.
• Driver e controller (o plugin) CNI (Container Network Interface) e CSI (Container Storage Interface).
• Acceleratori a supporto di virtualizzazione e hardware.
• Pod di controllo per le definizioni delle risorse personalizzate (CRD) e gli operatori Kubernetes (software di terze parti o personalizzati).

Sui nodi dell'infrastruttura che utilizzano i diritti inclusi non è possibile eseguire altri tipi di istanze applicative né applicazioni per gli utenti finali. Gli altri carichi di lavoro dell'infrastruttura da eseguire come istanze applicative su Red Hat OpenShift dovranno essere eseguiti sui normali nodi applicativi, con sottoscrizioni Red Hat OpenShift valide. Per verificare se un determinato servizio o app è idoneo come carico di lavoro dell'infrastruttura, puoi contattare Red Hat. 

Diritti per Red Hat Enterprise Linux

I diritti Red Hat Enterprise Linux per i nodi di calcolo e dell'infrastruttura per OpenShift sono inclusi in OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus. Quest'ultimo include anche i pod con diritti per le applicazioni e i diritti del sistema operativo guest per le VM. Le sottoscrizioni Red Hat OpenShift non includono altri diritti per i nodi Red Hat Enterprise Linux, con la seguente eccezione:

• Un nodo Red Hat Enterprise Linux espressamente utilizzato per il provisioning IPI bare metal.

OpenShift Virtualization Engine non include Red Hat Enterprise Linux né per i nodi di calcolo o di infrastruttura né per i diritti del sistema operativo guest delle VM. Per i guest Red Hat Enterprise Linux su OpenShift Virtualization Engine è necessaria una sottoscrizione Red Hat Enterprise Linux for Virtual Datacenters o le sottoscrizioni per VM.

Non sono inclusi i diritti di Red Hat Enterprise Linux per i nodi esterni che ospitano i servizi da cui dipende OpenShift, come i proxy Internet, i servizi di bilanciamento del carico o il mirror registry. Red Hat Satellite non è incluso nei diritti.

Registro del container di avvio per il mirroring delle immagini container di OpenShift

Il mirror registry per OpenShift è un diritto Quay che ha unicamente lo scopo di semplificare il processo di mirroring del contenuto necessario per l'avvio dei cluster OpenShift disconnessi ed è incluso nella sottoscrizione Red Hat OpenShift. Si tratta di un diritto di supporto limitato per un deployment minimo di Quay creato da un programma di installazione specifico, che consente di eseguire un registro Quay in un host Red Hat Enterprise Linux già predisposto e gestito dal cliente.

Nota: puoi usare Quay come mirror del registro unicamente per il mirroring del payload di rilascio di OpenShift, del contenuto di OperatorHub, delle immagini di esempio degli operatori, dell'immagine grafica di Cincinnati e delle immagini correlate alle offerte Red Hat OpenStack Platform, inclusi Red Hat OpenStack Services on OpenShift e Red Hat OpenShift Data Foundation.

Il mirror registry per OpenShift non deve essere utilizzato come registro generico utilizzabile su una scala arbitraria. Consente tuttavia di memorizzare un insieme limitato di immagini personalizzate, contenente gli agenti ausiliari software necessari come gli agenti e le immagini container di carichi di lavoro di infrastruttura qualificati. Ecco alcuni esempi:

• Agenti di monitoraggio.
• Provider CNI e CSI.
• Agenti a supporto di virtualizzazione e hardware.
• Operatori che supportano i servizi degli ISV (Independent Software Vendor).
• Operatori personalizzati come controller di deployment.

Piani di controllo in hosting

Un'infrastruttura OpenShift classica richiede un minimo di tre nodi del piano di controllo per ogni cluster OpenShift. In alternativa, puoi utilizzare i piani di controllo in hosting, nei quali i piani di controllo sono eseguiti in un cluster del piano di controllo centrale e forniscono il piano di controllo logico ai cluster OpenShift. I nodi del piano di controllo e quelli dell'infrastruttura non devono esser conteggiati per le sottoscrizioni, ma occorre tenerne conto per l'architettura.

È possibile eseguire i piani di controllo in hosting su qualsiasi cluster OpenShift bare metal, tuttavia i nodi di calcolo di tali cluster devono disporre dei diritti associati all'infrastruttura sulla quale vengono eseguiti. Ad esempio, per i cluster virtuali in hosting su OpenShift Virtualization Engine sono necessarie le sottoscrizioni basate su coppia di core per i nodi di calcolo, mentre per un cluster il cui piano di controllo è in hosting su un cluster di OpenShift Virtualization Engine e che utilizza nodi di calcolo bare metal sono necessarie sottoscrizioni basate su coppia di socket bare metal.

Eccezione 1: se scegli di eseguire istanze applicative su nodi del piano di controllo o dell'infrastruttura

I nodi del piano di controllo di OpenShift non vengono utilizzati come nodi di calcolo e, per impostazione predefinita, non eseguono istanze applicative. Per stabilire se un nodo del piano di controllo richiede o meno una sottoscrizione Red Hat OpenShift completa, è necessario capire se esegue soltanto componenti di supporto per i cluster OpenShift o anche applicazioni per gli utenti finali. Se scegli di utilizzare un nodo del piano di controllo per l'hosting di qualsiasi applicazione per gli utenti finali, saranno necessarie le sottoscrizioni per tutti i core. Nella sezione relativa ai nodi dell'infrastruttura trovi informazioni per identificare i nodi idonei che non richiedono una sottoscrizione.

Eccezione 2: deployment su cluster compatto

In un cluster come OpenShift compatto a 3 nodi, i carichi di lavoro delle applicazioni per gli utenti finali vengono eseguiti sui nodi del piano di controllo. Per le sottoscrizioni Red Hat OpenShift è necessario conteggiare i core presenti sui 3 nodi, qualunque sia il loro ruolo.

Un'istanza di OpenShift a nodo singolo distribuisce tutti i servizi OpenShift e le applicazioni per gli utenti finali su un singolo nodo fisico o virtuale, applicando ottimizzazioni che riducono l'ingombro e massimizzano le risorse a disposizione delle applicazioni. Come avviene per i cluster compatti con 3 nodi illustrati in precedenza, non sono previste condizioni speciali per questo modello di deployment ed è necessario autorizzare tutti i core del nodo.

Ripristino di emergenza

Red Hat distingue gli ambienti di ripristino di emergenza (DR) in tre diverse categorie: caldo, intermedio e freddo. Solo il ripristino di emergenza a caldo richiede sottoscrizioni Red Hat OpenShift a pagamento.

• I sistemi DR a caldo sono sistemi completamente operativi che vengono eseguiti contemporaneamente a quelli di produzione. Nel caso di problemi nell'ambiente principale, sono pronti a ricevere il traffico e sostituire l'ambiente corrotto. I volumi di dati attivamente replicati tra i cluster, sia in modalità sincrona che asincrona, vengono considerati sistemi DR a caldo.
• I sistemi DR intermedi sono già predisposti e pronti per il deployment e l'hosting di un carico di lavoro containerizzato sufficientemente simile a quello trovato nel sito principale, ma che non contiene i carichi di lavoro del cliente disponibili nei cluster di origine. I sistemi DR intermedi non dovrebbero prendere parte alla replica dei volumi dati attiva sul cluster, che sia sincrona o asincrona. Per il ripristino DR intermedio, i dati del cliente devono essere ripristinati sull'hardware del cluster esistente, disponibile all'esterno del cluster.
• I sistemi DR a freddo sono sistemi che dispongono dell'infrastruttura, ma non includono tutti i componenti hardware e software, né i dati necessari per il ripristino del servizio.

I cluster in ibernazione che non sono espressamente configurati e progettati per il DR intermedio o a freddo, come quelli in esecuzione nei servizi cloud temporaneamente ibernati a causa di un calo della domanda, richiedono una sottoscrizione. Quando si riattiva dall'ibernazione un cluster DR intermedio o a freddo per l'esecuzione dei carichi di lavoro, è necessaria una sottoscrizione. Se un cluster viene temporaneamente riattivato dall'ibernazione per eseguire test o interventi di manutenzione ordinaria, non occorre una sottoscrizione aggiuntiva per nessuno dei componenti inclusi nelle offerte software OpenShift.

In caso di problemi, sia con il DR intermedio che con quello a freddo, è possibile trasferire le sottoscrizioni di Red Hat OpenShift dall'ambiente principale all'ambiente DR, allo scopo di ripristinare i servizi e rispettare i termini della sottoscrizione Red Hat.

Migrazione e upgrade swing

Red Hat OpenShift 4 fornisce aggiornamenti sul posto per le versioni secondarie. Se invece si desidera effettuare un upgrade da Red Hat OpenShift 3 o eseguire un upgrade swing fra due versioni secondarie di OpenShift 4 durante una finestra di manutenzione o per altri motivi, la sottoscrizione Red Hat OpenShift in uso copre sia l'infrastruttura di origine che quella di destinazione fino al termine della migrazione unidirezionale. Durante la migrazione gli strumenti di gestione delle sottoscrizioni Red Hat mostrano che, in base alle sottoscrizioni OpenShift acquistate, l'ambiente non è conforme. In occasione degli upgrade alle versioni principali, Red Hat estende temporaneamente la copertura delle sottoscrizioni per evitare ai clienti di acquistare ulteriori sottoscrizioni al fine di ripristinare la conformità. Infine, Red Hat OpenShift offre tutti gli strumenti necessari per semplificare tali migrazioni, oltre ai servizi Red Hat Consulting eventualmente richiesti dai clienti. Per saperne di più, consulta la documentazione relativa agli  strumenti di migrazione per i container.

Diritti per i core con hyperthreading

Per determinare se un particolare nodo OpenShift utilizza uno o più core fisici, occorre stabilire se in tale sistema sono abilitati più thread per core. Scopri come determinare se un sistema specifico supporta l'hyperthreading.

I nodi OpenShift virtualizzati che utilizzano thread CPU logici, un approccio noto come multithreading simultaneo (SMT) per le CPU AMD EPYC o come hyperthreading per le CPU Intel, calcolano l'utilizzo dei propri core per le sottoscrizioni Red Hat OpenShift in base al numero di core/CPU assegnati al nodo. Se vengono utilizzati thread CPU logici, tuttavia, ogni sottoscrizione copre 4 vCPU/core. Gli strumenti di gestione di Red Hat presuppongono che i thread CPU logici siano abilitati per impostazione predefinita su tutti i sistemi.

Per calcolare il numero di sottoscrizioni bare metal necessarie vengono conteggiati solo i core fisici; i thread CPU logici non vengono conteggiati.

Architetture alternative (ARM, IBM Z, IBM LinuxONE, IBM Power)

Importante: sebbene d'ora in avanti faremo riferimento solo a IBM Z, tutte le informazioni qui di seguito sono valide anche per IBM LinuxONE.

È possibile eseguire Red Hat OpenShift Container Platform anche su sistemi ARM, IBM Z e IBM Power, se i clienti usano tali sistemi come standard per la creazione e il deployment di microservizi e applicazioni cloud native. L'unico modello di sottoscrizione compatibile con le piattaforme IBM Z e IBM Power è quello basato su core.

Per l'autorizzazione dei cluster ARM valgono le stesse regole applicabili ai sistemi x86.

Per i clienti che usano IBM Z, Red Hat OpenShift non richiede l'autorizzazione dell'intero nodo fisico, ma solo quella dei core utilizzati da OpenShift, dando luogo alla cosiddetta autorizzazione a "capacità parziale". I clienti che per OpenShift Container Platform utilizzano solo un sottoinsieme dei core disponibili (capacità di calcolo) nel loro ambiente IBM Z devono acquistare soltanto le sottoscrizioni necessarie per il sottoinsieme utilizzato per i nodi di calcolo. Questo a prescindere dalla modalità di partizionamento della CPU, che può avvenire con raggruppamento, limitazione, partizioni logiche separate (LPAR) e così via.

Per IBM Z, 1 Integrated Facility for Linux (IFL) richiede una sottoscrizione OpenShift basata su coppia di core. Se non viene effettuato alcun partizionamento, per il piano di controllo o i servizi di infrastruttura eseguiti nell'host possono essere identificate fino a tre IFL, che risultano idonee solo se vengono utilizzate attivamente per il piano di controllo e/o i servizi di infrastruttura e non richiedono alcun diritto per OpenShift. Nei deployment con cluster compatti formati da tre nodi è necessario autorizzare tutte le IFL.

Attualmente i componenti di Red Hat OpenShift Platform Plus che non sono previsti per OpenShift Container Platform non sono compatibili con i sistemi IBM Z e IBM Power, con le seguenti eccezioni:

• Una sottoscrizione standalone di Red Hat Quay in esecuzione su architetture x86 offre un registro globale per diverse architetture, compresi i cluster IBM Z e IBM Power. Red Hat Quay non viene eseguito su IBM Z o IBM Power.
• È possibile installare Red Hat Advanced Cluster Management for Kubernetes negli ambienti  IBM Z o IBM Power, per gestire i nodi Red Hat OpenShift in esecuzione al loro interno.
• Con Red Hat Advanced Cluster Security for Kubernetes, puoi proteggere i cluster in esecuzione su Red Hat OpenShift in IBM Z o IBM Power tramite l'operatore Red Hat Advanced Cluster Security.
• Red Hat OpenShift Data Foundation fornisce supporto completo per l'installazione su IBM Z o IBM Power.

I componenti della sottoscrizione Red Hat OpenShift Platform Plus presentano livelli di supporto diversi per le architetture alternative (non x86). Consulta la  Tabella di disponibilità dei componenti per più architetture Red Hat OpenShift Container Platform 4.16. Per informazioni sull'interoperabilità tra i componenti di OpenShift Platform Plus e le architetture non x86, vedi le tabelle di compatibilità per Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay e Red Hat OpenShift Data Foundation.

Red Hat OpenShift Kubernetes Engine e Red Hat OpenShift Virtualization Engine non sono supportati su IBM Z e IBM Power.

Supporto per i container Microsoft Windows Server

La versione autogestita di Red Hat OpenShift supporta un sottoinsieme di infrastrutture di installazione e funzionalità di OpenShift, tramite i container Microsoft Windows Server. I container Windows Server sono supportati solo nei nodi di calcolo basati su Microsoft Windows Server. I piani di controllo e infrastruttura dell'ambiente OpenShift devono essere eseguiti in un'infrastruttura x86 che utilizza Red Hat Enterprise Linux o Red Hat Enterprise Linux CoreOS. Per questo motivo il supporto tramite i container Windows Server è in vendita come sottoscrizione standalone, addebitata in base ai core.

Per il deployment e la gestione dei nodi di calcolo Windows Server è possibile utilizzare un'infrastruttura formata da Red Hat OpenShift Platform Plus e Red Hat OpenShift Container Platform. Il supporto dei container Microsoft Windows Server per le sottoscrizioni Red Hat OpenShift deve essere acquistato come componente aggiuntivo separato.

Red Hat Advanced Cluster Management e Red Hat Advanced Cluster Security non supportano la gestione dei nodi Microsoft Windows, ma Red Hat Quay in esecuzione su architetture x86 è in grado di gestire le immagini container per i carichi di lavoro basati su Windows Server.

Poiché ogni situazione è a sé stante, queste informazioni hanno il valore di linee guida e non di garanzia

Red Hat OpenShift supporta molte caratteristiche e funzioni che influiscono sulla scalabilità, la pianificazione dei pod, i tempi di inattività, le quote di risorsa o le funzionalità di limitazione. I calcoli precedenti vengono forniti solo come indicazione, ma tu puoi adattare il tuo ambiente reale in modo da ottimizzare l'utilizzo delle risorse o ridurre le dimensioni. I clienti che utilizzano OpenShift Platform Plus devono considerare anche l'aggiunta delle applicazioni software supplementari (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security e Red Hat Quay), comprese le risorse di calcolo e storage, anche se questo non influisce sempre sul numero delle sottoscrizioni necessarie.

Se ti rivolgi anche a rivenditori di terze parti, consulta i termini e le condizioni relativi ai prodotti e servizi Red Hat. 

Oltre a OpenShift Container Platform, Red Hat OpenShift Platform Plus include ulteriori componenti software che consentono di gestire e proteggere gli ambienti OpenShift su vasta scala, che comprendono più cluster e si estendono su diversi cloud. Per Red Hat OpenShift Platform Plus sono disponibili entrambi i modelli di sottoscrizione (basata su coppia di core e su coppia di socket bare metal), con le limitazioni indicate in precedenza.

I componenti software aggiuntivi forniti con Red Hat OpenShift Platform Plus consentono di gestire solo i nodi autorizzati dalla sottoscrizione di OpenShift Platform Plus. Ad esempio, la sottoscrizione per Red Hat Advanced Cluster Management inclusa in OpenShift Platform Plus può essere utilizzata esclusivamente per gestire i nodi e i cluster autorizzati da OpenShift Platform Plus. I clienti che desiderano gestire anche i nodi e i cluster non autorizzati da OpenShift Platform Plus, ad esempio i cluster Red Hat OpenShift Services on AWS, devono acquistare altre sottoscrizioni per il componente aggiuntivo Red Hat Advanced Cluster Management, al fine di coprire tali cluster.

Le sottoscrizioni ai software aggiuntivi sono inscindibili dalla sottoscrizione di OpenShift Platform Plus. Questo significa ad esempio che non è possibile acquistare 100 sottoscrizioni OpenShift Platform Plus, installare 200 core per le sottoscrizioni Red Hat OpenShift Container Platform e utilizzare separatamente Red Hat Advanced Cluster Management per gestire 200 core di Azure Red Hat OpenShift con la stessa sottoscrizione. I software aggiuntivi si possono utilizzare soltanto sui 200 core dove è installato il software OpenShift Platform Plus base.

Regole specifiche per ciascun prodotto aggiunto:

• Red Hat Advanced Cluster Management for Kubernetes: le sottoscrizioni di OpenShift Platform Plus consentono di installare tutte le istanze centrali di Red Hat Advanced Cluster Management necessarie per la gestione dell'ambiente e coprono la gestione di tutti i nodi e i cluster autorizzati con OpenShift Platform Plus, inclusi i nodi del piano di controllo e quelli dell'infrastruttura. Se si desidera gestire nodi e cluster senza diritti OpenShift Platform Plus (ad esempio perché si dispone di cluster autorizzati tramite la versione autogestita di OpenShift Container Platform o Red Hat OpenShift Kubernetes Engine, oppure di cluster eseguiti in un cloud OpenShift completamente gestito o in ambienti Kubernetes di terze parti supportati da Red Hat Advanced Cluster Management), occorre acquistare le sottoscrizioni Red Hat Advanced Cluster Management aggiuntive necessarie per coprire tali ambienti. Puoi scegliere fra la gestione centralizzata dalla console di Red Hat Advanced Cluster Management installata su OpenShift Platform Plus e l'utilizzo di un'applicazione centrale separata che soddisfa le tue esigenze. Scopri di più sulle sottoscrizioni di Red Hat Advanced Cluster Management, sugli ambienti che supporta e sulle relative procedure consigliate.
• Red Hat Advanced Cluster Security for Kubernetes: le sottoscrizioni OpenShift Platform Plus consentono di installare tutte le applicazioni centrali di Red Hat Advanced Cluster Security necessarie per la gestione dell'ambiente e coprono la gestione di tutti i nodi e i cluster autorizzati con OpenShift Platform Plus, inclusi i nodi del piano di controllo e quelli dell'infrastruttura. Per gestire nodi e cluster senza diritti OpenShift Platform Plus (ad esempio perché si dispone di cluster autorizzati tramite la versione autogestita di OpenShift Container Platform o OpenShift Kubernetes Engine, oppure di cluster eseguiti in un cloud Red Hat OpenShift completamente gestito o in ambienti Kubernetes di terze parti supportati da Red Hat Advanced Cluster Security), occorre acquistare le sottoscrizioni Red Hat Advanced Cluster Security aggiuntive necessarie per coprire tali ambienti. Red Hat consiglia di utilizzare un'applicazione centrale Red Hat Advanced Cluster Security separata per gestire ciascun ambiente. Scopri di più sugli ambienti supportati da Red Hat Advanced Cluster Security.
• Red Hat Quay: le sottoscrizioni di OpenShift Platform Plus consentono di installare Red Hat Quay in qualsiasi cluster autorizzato con OpenShift Platform Plus e non prevedono alcun limite per il numero di deployment Quay installabili nei cluster Red Hat OpenShift Platform Plus. È possibile utilizzare Quay in tutti gli ambienti Kubernetes supportati, compresi l'ambiente OpenShift Platform Plus, altri cluster OpenShift autogestiti, i servizi OpenShift gestiti e le soluzioni Kubernetes di terze parti supportate. Per installare Quay in un ambiente diverso dall'ambiente OpenShift Platform Plus, è necessario acquistare una sottoscrizione Red Hat Quay separata. Red Hat Quay è disponibile anche come  offerta SaaS completamente gestita.
• Red Hat OpenShift Data Foundation. Le sottoscrizioni OpenShift Platform Plus consentono di installare Red Hat OpenShift Data Foundation Essentials in qualsiasi cluster autorizzato con OpenShift Platform Plus. Il diritto per Red Hat Data Foundation è limitato alle funzionalità disponibili in Essentials, e a 256 TB di storage dati per ogni cluster OpenShift. Puoi anche scegliere di estendere le funzionalità e le capacità aggiungendo altre sottoscrizioni. Per ulteriori informazioni, vedi la  Guida alla sottoscrizione di OpenShift Data Foundation (è necessario accedere al Customer Portal) o contatta un rappresentante commerciale Red Hat.

Per molto tempo, la funzionalità OpenShift Virtualization è stata inclusa nelle versioni autogestite di OpenShift, consentendo ai clienti di includere i carichi di lavoro delle VM nelle applicazioni cloud native per modernizzare le VM in container e microservizi.

Con le recenti innovazioni nel mercato della virtualizzazione, è aumentata la richiesta di piattaforme di virtualizzazione alternative, soprattutto se promuovono la modernizzazione. Non tutti i clienti richiedono tutte le capacità di OpenShift per la migrazione iniziale delle VM; molti preferiscono una versione autogestita alternativa, più semplice e meno costosa da utilizzare in specifici scenari.

Red Hat OpenShift Virtualization Engine è una versione autogestita di OpenShift pensata per i clienti interessati a una piattaforma di virtualizzazione alternativa per l'esecuzione delle VM. I diritti di OpenShift Virtualization Engine sono assegnati con sottoscrizioni basate su coppia di socket bare metal sui server fisici supportati e sulle istanze bare metal degli hyperscaler supportati.

OpenShift Virtualization Engine include solo le funzionalità necessarie per il deployment, la gestione e l'esecuzione delle macchine virtuali, ovvero:

• Un numero illimitato di VM sugli host sottoscritti.
• Non può essere utilizzato per eseguire istanze applicative (ad esempio software commerciale o applicazioni dei clienti) su container, ma solo su VM.
• Non include le sottoscrizioni per l'esecuzione di qualsiasi versione di Red Hat OpenShift nelle VM (è necessario acquistare sottoscrizioni basate su coppia di core distinte).
• Non sono inclusi i diritti guest per Red Hat Enterprise Linux per VM (è necessario acquistare sottoscrizioni Red Hat Enterprise Linux for Virtual Datacenter o per VM distinte).

Red Hat ha reso disponibili due prodotti aggiuntivi per OpenShift Virtualization Engine.

• Red Hat Advanced Cluster Management for Virtualization supporta la gestione e l'operatività del ciclo di vita della virtualizzazione e degli hypervisor a un costo inferiore rispetto alla versione completa di Advanced Cluster Management (1 sottoscrizione per OpenShift Virtualization Engine).
• Red Hat Ansible® Application Platform for Virtualization supporta il nodo hypervisor eseguito su OpenShift Virtualization Engine per la migrazione e le attività di configurazione (1 sottoscrizione per OpenShift Virtualization Engine).

Per i clienti esistenti di Advanced Cluster Management e di Ansible Application Platform puoi utilizzare le installazioni esistenti delle relative applicazioni centrali a supporto dell'intero ambiente e gestire gli host OpenShift Virtualization Engine acquistando le sottoscrizioni aggiuntive indicate.

Per i clienti che non hanno installato le applicazioni centrali Advanced Cluster Management o Ansible Application Platforms, la tua sottoscrizione per i componenti aggiuntivi indicati include anche il supporto per l'installazione delle applicazioni centrali come container di infrastruttura negli host OpenShift Virtualization Engine. Consulta la documentazione di Advanced Cluster Management o Ansible Application Platform per informazioni sull'installazione delle applicazioni centrali e sulle procedure consigliate per le architetture.

Ansible Automation Platform è consigliata ai clienti che intendono automatizzare le attività di manutenzione sulle proprie VM. Oltre alle sottoscrizioni per il nodo hypervisor già elencate, è necessaria una sottoscrizione per nodo per ogni istanza di VM. Leggi la documentazione di Ansible Automation Platform per altre informazioni.

Mentre le autorizzazioni per OpenShift Virtualization Engine limitano le istanze applicative dei clienti alle sole VM, molti requisiti dell'infrastruttura, come i driver di storage, le applicazioni di backup, gli agenti di inoltro, Advanced Cluster Management e Ansible Automation Platform, vengono eseguiti come container di infrastruttura in Red Hat OpenShift. I diritti non consentono l'esecuzione di tali funzionalità dell'infrastruttura nei container. In aggiunta, nel diritto sono incluse le soluzioni storage software defined che forniscono lo storage per le VM, ma che a loro volta sono eseguite nei container. Le linee guida che qualificano questi container di infrastruttura sono le stesse che indicano quali carichi di lavoro sono consentiti nei nodi dell'infrastruttura delle altre versioni di Red Hat OpenShift. La sezione "Elementi non conteggiati" fornisce ulteriori informazioni sui nodi dell'infrastruttura. Per verificare se un determinato servizio o app è idoneo come carico di lavoro dell'infrastruttura per OpenShift Virtualization Engine, puoi contattare Red Hat.

Usa le domande e gli esempi riportati di seguito per determinare il numero di sottoscrizioni della versione autogestita di OpenShift (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform o Red Hat OpenShift Kubernetes Engine) e il numero di sottoscrizioni aggiuntive che ti servono.

Per riepilogare:

• Le applicazioni sono raggruppate in immagini di container o in VM.
• I container e le VM sono distribuiti come pod.
• I pod vengono eseguiti su nodi di calcolo di OpenShift, che sono gestiti tramite i nodi del piano di controllo di OpenShift.

Come valutare i requisiti relativi ai diritti

Le sottoscrizioni Red Hat OpenShift non prevedono alcun limite per il numero delle istanze applicative eseguibili nell'ambiente Red Hat OpenShift, purché l'hardware e l'infrastruttura sottostante siano in grado di supportarle. I sistemi hardware ad alta capacità possono eseguire molte istanze applicative su un numero limitato di host, mentre i sistemi hardware con capacità inferiore richiedono diversi host. Per poter dimensionare l'ambiente Red Hat OpenShift, bisogna innanzitutto stabilire il numero di pod o istanze applicative che saranno in esecuzione.

Passaggio 1. Identifica il numero e il tipo di istanze applicative necessarie

Inizia dalle applicazioni. Stabilisci il numero totale di istanze applicative o pod che prevedi di installare. Ai fini del dimensionamento, considera come istanza applicativa qualunque componente applicativo in esecuzione su Red Hat OpenShift (ad esempio database, server statici front end, istanza di VM).

Questa cifra può essere un valore approssimativo, utilizzato per stimare le dimensioni dell'ambiente Red Hat OpenShift. Per ottenere un dimensionamento più preciso, si possono aggiungere al calcolo anche la CPU, la sottoscrizione in eccesso di memoria, le quote e i limiti e altre funzionalità.

Tabella 1. Domande sul dimensionamento di istanze e applicazioni

La nostra applicazione è costituita da 200 istanze di container, ognuna delle quali consuma in media 1 vCPU e 4 GB di RAM. L'utilizzo preferenziale massimo è 80%. L'applicazione viene eseguita su AWS e ha accesso ai tipi di istanza EC2 M6i. L'applicazione non richiede alcun hardware o acceleratore di IA specifico. Abbiamo scelto Red Hat OpenShift Platform Plus come versione autogestita, e al momento ci occorre solo una stima del numero di sottoscrizioni necessarie.

Passaggio 1. Identifica il numero e il tipo di istanze applicative necessarie

Dalle informazioni del nostro esempio:

• Numero di istanze applicative = 200
• Utilizzo preferenziale massimo dei nodi = 80%
• Requisito di vCPU medio per applicazione = 1 vCPU
• Requisito di memoria medio per applicazione = 4 GB

Passaggio 2. Stabilisci la memoria totale e il numero di core totali necessari

Applichiamo ai nostri calcoli le cifre derivanti dal passaggio 1:

• Utilizzo massimo = 80%
• vCPU totali necessari = 1 vCPU X 200 X 1/80% = 250 vCPU
• Memoria totale necessaria  = 4 GB X 200 X 1/80% = 1.000 GB

Passaggio 3. Seleziona un nodo di calcolo standard

In base alle informazioni raccolte, non è necessario un tipo di istanza con GPU o hardware specializzato. Il rapporto vCPU:Memory è 250 vCPU:1.000 GB, o 1:4. I tipi di istanza di questo tipo sono fortunatamente numerosi. Dopo l'analisi degli altri fattori richiesti dall'applicazione, possiamo stabilire che il tipo di istanza  m6i.4xlarge è quello che meglio soddisfa le nostre esigenze. Ogni istanza ha 16 vCPU e 64 GB di memoria.

Passaggio 4. Calcola le sottoscrizioni totali necessarie

In questo caso, ci occorrono sottoscrizioni basate su coppie di core perché l'esecuzione avviene in un cloud hyperscaler, che utilizza vCPU; applichiamo pertanto la formula della sottoscrizione basata su coppia di core del passaggio 2.

Sottoscrizioni totali basate su coppia di core = vCPU totali necessarie / 4, approssimato

250 vCPU / 4 = 62,5, o 63 approssimato

Passaggio 5. Calcola le sottoscrizioni AI Accelerator necessarie (se applicabile)

In questo esempio di dimensionamento non utilizziamo AI Accelerator, perciò non è applicabile.

Risultato

Nell'esempio 1, sono necessarie 63 sottoscrizioni OpenShift Platform Plus basate su coppia di core.

Ora desideriamo eseguire la stessa applicazione on premise e su bare metal, con provisioning su nodi di calcolo di VM utilizzando la funzionalità OpenShift Virtualization inclusa di Red Hat OpenShift. L'applicazione è costituita da 200 istanze di container, ognuna delle quali consuma in media 1 vCPU e 4 GB di RAM. L'utilizzo preferenziale massimo è 80%. L'applicazione non richiede alcun hardware o acceleratore di IA specifico. Abbiamo scelto Red Hat OpenShift Platform Plus come versione autogestita, e al momento ci occorre solo una stima del numero di sottoscrizioni necessarie. Le configurazioni bare metal scelte ci concedono una certa flessibilità, ma utilizziamo configurazioni server standard.

Passaggio 1. Identifica il numero e il tipo di istanze applicative necessarie

Dalle informazioni del nostro esempio:

• Numero di istanze applicative = 200
• Utilizzo preferenziale massimo dei nodi = 80%
• Requisito di vCPU medio per applicazione = 1 vCPU
• Requisito di memoria medio per applicazione = 4 GB

Passaggio 2. Stabilisci la memoria totale e il numero di core totali necessari

Applichiamo ai nostri calcoli le cifre derivanti dal passaggio 1:

• Utilizzo massimo = 80%
• vCPU totali necessari = 1 vCPU X 200 X 1/80% = 250 vCPU
• Memoria totale necessaria  = 4 GB X 200 X 1/80% = 1.000 GB

Passaggio 3. Seleziona un nodo di calcolo standard

Il server bare metal standard in uso è un server a 2 socket con 32 core/64 vCPU per socket. Possiamo scegliere la RAM. Poiché il rapporto tra vCPU e RAM è 1:4, appronteremo server con 256 GB di RAM. Il server bare metal scelto è un server a 2 socket con 32 core/64 vCPU per socket (64 core/128 vCPU per server) e 256 GB di RAM.

Passaggio 4. Calcola le sottoscrizioni totali necessarie

In un server bare metal possiamo scegliere le sottoscrizioni basate su coppia di core o le sottoscrizioni basate su coppia di socket bare metal. Le calcoleremo entrambe:

Sottoscrizioni totali basate su coppia di core = vCPU totali necessarie / 4, approssimato

250 vCPU / 4 = 62,5, o 63 approssimato

Sottoscrizioni a coppia di socket totali =

• Numero totale di server necessari = 250 vCPU / 128 vCPU per server, approssimato = 2 server
• Numero totale di sottoscrizioni necessarie per server = Numero dei core per coppia di socket / 128, approssimato = 64/128 = 0,5 approssimato a 1 sottoscrizione
• 2 server x 1 sottoscrizione/server = 2 sottoscrizioni basate su coppia di socket bare metal

In questo caso, poiché abbiamo potuto selezionare un server per ottenere il rapporto corretto tra vCPU e memoria, non è necessario calcolare il numero di server necessari a soddisfare i requisiti di memoria, e possiamo utilizzare il valore maggiore tra i due. Se il server scelto avesse avuto una diversa quantità di RAM, avremmo dovuto tener conto della differenza.

Passaggio 5. Calcola le sottoscrizioni AI Accelerator necessarie (se applicabile)

In questo esempio di dimensionamento non utilizziamo AI Accelerator, perciò non è applicabile.

Risultato

In questo esempio, sono necessarie 63 sottoscrizioni OpenShift Platform Plus basate su coppia di core oppure 2 sottoscrizioni basate su coppia di socket bare metal . A questo punto la decisione terrà conto di aspetti come la situazione finanziaria e architetturale. 

Stiamo trasferendo le nostre macchine virtuali da un altro hypervisor a Red Hat. Si tratta di un ambiente misto nel quale abbiamo identificato il seguente numero di macchine virtuali di diverse dimensioni:

• 1.000 piccole = 1.000 vCPU, 4.000 GiB. Più 228 GiB di sovraccarico di memoria
• 300 medie = 600 vCPU, 2.400 GiB. Più 73 GiB di sovraccarico di memoria
• 200 grandi = 800 vCPU, 4.800 GiB. Più 58 GiB di sovraccarico di memoria
• 200 extra large = 1.600 vCPU, 9.600 GiB. Più 64 GiB di sovraccarico di memoria

Passaggio 1. Identifica il numero e il tipo di istanze applicative necessarie

Dalle informazioni del nostro esempio:

• Numero di istanze applicative = 1.700
• vCPU totali = 4.000 vCPU
• Memoria totale = 20.800 GB + 423 GB di sovraccarico = 21.223 GB
• Requisito di vCPU medio per applicazione = 2,4 vCPU
• Requisito di memoria medio per applicazione = 12,5 GB

Passaggio 2. Stabilisci la memoria totale e il numero di core totali necessari

Applichiamo ai nostri calcoli le cifre derivanti dal passaggio 1:

• Memoria totale necessaria = 20.800 GB + 423 GB di sovraccarico =  21.223 GB
• vCPU totali necessari = 4.000 vCPU

Il parametro relativo all'utilizzo massimo per la VM è un esercizio lievemente differente rispetto ai container, ma dovrebbe essere familiare agli amministratori della virtualizzazione.

In linea di massima, poiché l'overcommit della memoria non è consigliato per le VM, i requisiti di memoria totale sono in genere il fattore principale su cui si basa il numero di nodi di calcolo.

È previsto l'overcommit della CPU, perché mediamente la maggior parte delle VM non impiega tutte le risorse di calcolo disponibili. Il rapporto massimo di overcommit della CPU per OpenShift Virtualization è stabilito a 10:1; scegliere un rapporto 4:1 è una stima prudente. Dobbiamo anche scegliere se utilizzare core o thread (con il supporto per l'hyperthreading, ogni core può corrispondere a 2 thread) per corrispondere a una vCPU. Possiamo essere prudenti anche in questo caso e scegliere 1 vCPU = 1 core senza hyperthreading. Avremo quindi i seguenti requisiti:

• Memoria totale necessaria = 20.800 GB + 423 GB di sovraccarico =  21.223 GB
• Core totali richiesti = 4.000 vCPU x 1/4 x 1 core/vCPU = 1.000 core

Passaggio 3. Seleziona un nodo di calcolo standard

La scelta del nodo di calcolo bare metal per la virtualizzazione dipende da molti fattori, tra cui la ridondanza e i domini di errore, la dimensione dei cluster, ecc. On premise abbiamo diverse opzioni, incluso l'aumento della RAM per ogni server. Possiamo iniziare dalla memoria, sulla quale in genere si basano i requisiti del server.

Abbiamo 1.700 VM e scegliamo un server a 2 socket con 32 core per socket. Se utilizziamo il conteggio dei core in base al numero di server, ci serviranno:

• 1.000 core / 64 core/server, approssimato = 16 server

Con 16 server, avremmo bisogno di 21.223 GB / 16 server = 1.326 GB di RAM per server. Per il nostro server possiamo scegliere 1.536 GB di RAM. La nostra configurazione bare metal è:

• Un server a 2 socket con 32core/socket (64 core totali), 1.536 GB di RAM.

16 server con questa configurazione generano un totale di:

• 16 x 64 core = 1.024 core
• 16 x 1.536 GB = 24576 GB di memoria

Questa configurazione è sufficiente per eseguire i carichi delle VM, ma saranno necessari altri server per la ridondanza. Al momento non possiamo perdere alcun server per un'eventuale interruzione, perché inciderebbe fortemente sulle prestazioni. Gli amministratori della virtualizzazione suggeriscono di prevedere un 25% di capacità in più per il failover e la ridondanza. Ci serviranno pertanto:

• 16 server + (16 server * 25%) = 20 server totali

Le VM verranno suddivise su tutti i 20 server, in modo che anche con una perdita di 1-4 server, saremo in grado di soddisfare i requisiti delle VM. I requisiti in termini di resilienza della tua azienda possono variare.

Passaggio 4. Calcola le sottoscrizioni totali necessarie

Per uno scenario di sola virtualizzazione, utilizziamo OpenShift Virtualization Engine, disponibile solo con sottoscrizioni basate su coppia di socket bare metal.

Numero totale di sottoscrizioni basate su coppia di socket =

• Numero totale di server necessari = 20
• Numero totale di sottoscrizioni necessarie per server = 1 poiché i nostri server raggiungono un massimo di 64 core/coppie di socket
• 20 server x 1 sottoscrizione/server = 20 sottoscrizioni basate su coppia di socket bare metal

Passaggio 5. Calcola le sottoscrizioni AI Accelerator necessarie (se applicabile)

In questo esempio di dimensionamento non utilizziamo AI Accelerator, perciò non è applicabile.

Risultato

Per questo esempio, sono necessarie 20 sottoscrizioni basate su coppia di socket bare metal OpenShift Virtualization Engine . 

Tabella 1. Differenze tra le funzionalità delle diverse versioni di Red Hat OpenShift

Tabella 2. Differenze dettagliate tra le versioni di Red Hat OpenShift, inclusi gli operatori che forniscono le funzionalità corrispondenti

Nota 1. L'operatore OpenShift Elasticsearch incluso in Red Hat OpenShift è concesso in licenza solo a supporto delle esigenze di ricerca nell'infrastruttura interna del cluster OpenShift; non può essere utilizzato in modalità standalone per le applicazioni del cliente.

Software Red Hat comune non incluso nelle versioni di Red Hat OpenShift

Se non diversamente specificato, le seguenti offerte software di Red Hat, diffusamente utilizzate insieme a OpenShift, devono essere autorizzate separatamente. Red Hat OpenShift Platform Plus include Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay e Red Hat OpenShift Data Foundation Essentials. Altre sottoscrizioni della versione autogestita di OpenShift non includono questi prodotti aggiuntivi, che tuttavia possono essere acquistati separatamente. Altri software Red Hat utilizzati con Red Hat OpenShift ma non presi in considerazione in questa guida alla sottoscrizione sono:

• Red Hat Ansible Automation Platform
• Red Hat Application Foundations
• Red Hat Enterprise Linux AI
• L'offerta di integrazione di Red che include 3scale, AMQ, Camel K, Fuse, ecc.
• Red Hat JBoss EAP
• Pacchetti Red Hat Middleware
• Red Hat OpenShift Developer Hub (la versione Red Hat del progetto Backstage)
• Red Hat OpenShift AI
• Red Hat Satellite (per la gestione di Red Hat Enterprise Linux)
• IBM CloudPaks

Per saperne di più sulle offerte indicate, contatta il tuo partner o rivenditore Red Hat di riferimento.