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 stimare la quantità di diritti necessaria per un ambiente Red Hat OpenShift. Informazioni più precise 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. Corrisponde a due core fisici o quattro unità di elaborazione centrale 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.
• Nodo bare metal: è un altro concetto su cui si basano le sottoscrizioni della versione autogestita di OpenShift. È necessaria una sottoscrizione basata su nodo bare metal per ogni server fisico. Una singola sottoscrizione basata su nodo bare metal non può coprire più di un server, e lo stesso vale per i core in una sottoscrizione.
• 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) discrete, unità di elaborazione tensoriali (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 spesso 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 è necessario scegliere un accordo sul livello del servizio (SLA, Service Level Agreement) per il supporto. Gli accordi 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 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 open source, 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 di Red Hat 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. Gli utenti controllano gli upgrade, gestiscono il livello inferiore dell'infrastruttura e garantiscono 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 e sulla modernizzazione di quelle esistenti.

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

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

Tutte le versioni 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.

Versioni autogestite del software OpenShift:

• Red Hat OpenShift Kubernetes Engine: motore di runtime Kubernetes di livello enterprise per il cloud ibrido, che fornisce le principali funzionalità di Red Hat 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: 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: piattaforma di cloud ibrido utilizzabile per la creazione, il deployment, l'esecuzione e la gestione di applicazioni intelligenti in modo scalabile, su più cluster e in vari ambienti cloud. Più livelli di sicurezza, gestibilità e automazione assicurano 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: 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 enterprise affidabile per il deployment, la gestione e la scalabilità delle VM. Composta da una selezione di funzionalità di OpenShift, questa versione è 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 sottoscrizioni

Per la versione autogestita di OpenShift esistono due tipi di sottoscrizione (basata su coppia di core e basata su nodo 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 nodi 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.
• I contratti sono disponibili con i livelli di supporto Standard (8/5) o Premium (24/7).

2. Nodo bare metal (1 nodo fisico) 

• Un nodo fisico corrisponde a un server, indipendentemente dal numero di socket CPU presenti nel server o dal numero di core delle CPU.
• Questa opzione di sottoscrizione è disponibile per tutte le versioni 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.
• I contratti sono disponibili con i livelli di supporto Standard (8/5) o Premium (24/7).

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 il rendering delle immagini e non per l'accelerazione dell'IA.
• I contratti sono disponibili con i livelli di supporto Standard (8/5) o Premium (24/7). Lo SLA deve corrispondere a quello della sottoscrizione basata su coppia di core o su nodo 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 utilizzate anche su dispositivi o server bare metal, senza hypervisor. Esiste in genere una determinata densità del pod di calcolo per la quale le sottoscrizioni basate su nodo bare metal possono essere più convenienti in termini economici.

Quando la piattaforma di virtualizzazione dedicata è OpenShift Virtualization Engine, puoi scegliere di coprire i container OpenShift in esecuzione sulle VM con sottoscrizioni basate su coppia di core, in aggiunta a quelle basate su nodo bare metal per l'hypervisor stesso. 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 nodo 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 nodo bare metal

Le sottoscrizioni basate su nodo 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 su 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 versioni autogestite di OpenShift. 

Ogni sottoscrizione basata su nodo bare metal copre un singolo nodo fisico, indipendentemente dal numero totale di socket o core della CPU.

Considerata la peculiare architettura di Kubernetes, ogni server bare metal fisico che utilizza diritti per nodo 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 basate su nodo includono OpenShift Virtualization e le sottoscrizioni necessarie per qualsiasi cluster OpenShift virtuale dello stesso tipo di prodotto distribuito al loro interno. 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 coprire le VM con sottoscrizioni basate su coppia di core per la versione autogestita di OpenShift. Con maggiori densità, puoi invece scegliere di acquistare una sottoscrizione basata su nodo 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 più 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 nodo. Ad esempio, non puoi disporre di un singolo cluster bare metal con alcuni nodi OpenShift Virtualization Engine per l'hosting delle VM e altri nodi coperti da sottoscrizioni OpenShift Platform Plus per l'hosting di applicazioni containerizzate e istanze 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 quattro dispositivi GPU fisici richiederebbe quattro sottoscrizioni AI Accelerator in aggiunta alle sottoscrizioni basate su coppia di core o su nodo della CPU che coprono il nodo di elaborazione.
• Un singolo nodo di calcolo virtuale con 1 dispositivo GPU fisico esposto 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 considerato un nodo infrastrutturale e usufruire del diritto incluso, le istanze devono eseguire esclusivamente componenti a supporto del cluster e non appartenenti ad applicazioni degli utenti finali. Ad esempio:

• Registro OpenShift.
• OpenShift Ingress Router (ingress locale, globale e multicluster).
• OpenShift Observability.
• Istanze basate su HAProxy utilizzate per il traffico in ingresso al 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.
• Ansible Automation Platform, se utilizzato esclusivamente per la gestione dei cluster.

Sui nodi dell'infrastruttura si possono distribuire ed eseguire anche agenti e strumenti personalizzati e 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 personalizzati e di terze parti.
• Driver e controller (plug-in) CNI (Container Network Interface) e CSI (Container Storage Interface).
• Acceleratori per l'abilitazione dell'hardware o della virtualizzazione.
• Pod di controllo per le definizioni delle risorse personalizzate (CRD) e gli operatori Kubernetes (software personalizzati o di terze parti).

Su un nodo infrastrutturale che usufruisce dei diritti inclusi non possono essere eseguite altre istanze o tipologie di applicazioni per 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. Tuttavia, 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 di container di bootstrap per il mirroring delle immagini container 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 è concepito come un registro generico in grado di operare su scala arbitraria. È tuttavia consentito memorizzare un insieme limitato di immagini personalizzate contenenti il software ausiliario necessario, ad esempio agenti e immagini container per carichi di lavoro infrastrutturali qualificati. Ecco alcuni esempi:

• Agenti di monitoraggio.
• Provider CNI e CSI.
• Agenti per l'abilitazione dell'hardware o della virtualizzazione.
• Operatori a supporto dei servizi di fornitori di software indipendenti (ISV).
• Operatori personalizzati utilizzati 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 nodo 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 carichi di lavoro qualificati che non richiedono una sottoscrizione.

Eccezione 2: deployment di cluster compatti

Nei deployment di cluster compatti, come OpenShift 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 OpenShift a nodo singolo distribuisce tutti i servizi OpenShift e le applicazioni degli utenti finali su un unico nodo fisico o virtuale, con ottimizzazioni che riducono l'occupazione delle risorse e massimizzano quelle disponibili per le 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: a caldo, intermedio e a freddo. Solo il ripristino di emergenza a caldo richiede sottoscrizioni Red Hat OpenShift a pagamento.

• I sistemi di DR a caldo sono sistemi pienamente operativi e attivi contemporaneamente ai sistemi di produzione. Sono pronti a ricevere immediatamente il traffico e a subentrare in caso di emergenza nell'ambiente primario. I volumi di dati attivamente replicati tra i cluster, sia in modalità sincrona che asincrona tramite software defined storage ospitato su OpenShift, 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 devono partecipare alla replica attiva dei volumi di dati tra cluster, né in modalità sincrona né asincrona, quando il sito secondario (DR) monta tali dati in carichi di lavoro dei container attivamente in esecuzione sul cluster. I dispositivi di storage esterni che eseguono la replica dei volumi sono comunque considerati DR intermedi. Per il software defined storage ospitato su OpenShift, il ripristino DR intermedio richiede che i dati del cliente vengano recuperati da una risorsa esterna al cluster e ripristinati sull'hardware del cluster esistente.
• I sistemi DR a freddo hanno un'infrastruttura già predisposta, ma non presentano tutte le risorse tecnologiche (hardware, software e dati) necessarie per ripristinare il 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. La riattivazione temporanea di un cluster in ibernazione per attività di manutenzione ordinaria o test non richiede sottoscrizioni aggiuntive per nessuno dei componenti delle offerte software Red Hat 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. Consulta la documentazione relativa al migration toolkit for containers.

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. 

Per 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, l'utilizzo dei core ai fini delle sottoscrizioni Red Hat OpenShift viene calcolato 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, non i thread CPU logici.

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

Nota: sebbene d'ora in avanti il documento faccia riferimento solo a IBM Z, tutte le informazioni relative a IBM Z si applicano anche a IBM LinuxONE.

È possibile eseguire Red Hat OpenShift Container Platform anche su sistemi Aem, 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. Le sottoscrizioni Red Hat OpenShift bare metal basate su socket non possono essere utilizzate con le piattaforme IBM Z e IBM Power. 

Per i cluster Arm, i diritti vengono determinati secondo le stesse regole applicate ai cluster 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, un Integrated Facility for Linux (IFL) richiede una sottoscrizione OpenShift per core (IBM Z è l'unica architettura in cui la sottoscrizione si basa su un singolo core). In questa architettura non esiste il concetto di vCPU. In assenza di partizionamento, è possibile identificare fino a 3 IFL per cluster OpenShift per i servizi del piano di controllo o dell'infrastruttura in esecuzione sull'host. Per essere considerati idonei, questi IFL devono essere utilizzati attivamente per i servizi del piano di controllo e/o dell'infrastruttura e non richiedono diritti OpenShift. Nei deployment di cluster compatti a tre nodi, tutti gli IFL devono invece essere coperti da un diritto. 

Per IBM Power, si utilizza il modello di sottoscrizione basato su coppia di core. In questa architettura non esiste il concetto di vCPU.

I componenti della sottoscrizione Red Hat OpenShift Platform Plus presentano livelli di supporto diversi per le architetture alternative (non x86). Consulta l'articolo "Tabella di disponibilità dei componenti per più architetture Red Hat OpenShift Container Platform 4.19" sul Red Hat Customer Portal (è necessario effettuare l'accesso). 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 esclusivamente sui 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 per i container Windows Server è disponibile come sottoscrizione standalone, con un prezzo calcolato per core.

Per il deployment e la gestione dei nodi di calcolo Windows Server è possibile utilizzare un'infrastruttura formata da Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform e Red Hat OpenShift Kubernetes Engine. 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 sono indicativi e potrebbe essere possibile ottimizzare l'ambiente effettivo per utilizzare meglio le risorse o ridurne le dimensioni complessive. I clienti che utilizzano OpenShift Platform Plus devono tenere conto anche delle esigenze delle applicazioni software supplementari (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security e Red Hat Quay), incluse le risorse di storage e di calcolo, anche se tali applicazioni potrebbero non richiedere sottoscrizioni aggiuntive per il calcolo.

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

Red Hat OpenShift Platform Plus include, oltre a OpenShift Container Platform, software aggiuntivo che consente di gestire e proteggere gli ambienti Red Hat OpenShift in modo scalabile su più cluster e cloud. Per OpenShift Platform Plus sono disponibili entrambi i modelli di sottoscrizione (basata su coppia di core e su nodo bare metal), con le limitazioni indicate in precedenza.

I software aggiuntivi inclusi con Red Hat OpenShift Platform Plus sono generalmente limitati alla gestione dei nodi coperti da sottoscrizioni 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. 

Anche le sottoscrizioni software aggiuntive non sono separabili dalla sottoscrizione 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 possono essere utilizzati esclusivamente per gestire gli stessi 200 core su cui è installato il software OpenShift Platform Plus di base.

Regole specifiche per ciascun prodotto aggiunto:

• Red Hat Advanced Cluster Management for Kubernetes: le sottoscrizioni 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 per componenti aggiuntivi 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 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 per componenti aggiuntivi 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 OpenShift Platform Plus consentono di installare Red Hat Quay in qualsiasi cluster autorizzato con OpenShift Platform Plus, senza alcun limite al numero di deployment di Quay. È 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 Software-as-a-Service (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 scegliere di aggiungere funzionalità e aumentare la capacità tramite sottoscrizioni aggiuntive. Per ulteriori informazioni, vedi la Guida alla sottoscrizione di OpenShift Data Foundation (è necessario accedere al Customer Portal) o contatta un rappresentante commerciale Red Hat.
• Argo CD Agent: le sottoscrizioni OpenShift Platform Plus consentono di installare il componente Argo CD Agent di Red Hat OpenShift GitOps su qualsiasi cluster coperto da una sottoscrizione OpenShift Platform Plus. Argo CD Agent può essere eseguito su Red Hat OpenShift o in ambienti Kubernetes supportati (Red Hat OpenShift GitOps è incluso in OpenShift Container Platform).

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. Questi clienti si concentrano esclusivamente sulla virtualizzazione e possono adottare funzionalità moderne per lo sviluppo delle applicazioni e la containerizzazione secondo i propri tempi.

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 nodo bare metal sui server fisici supportati e sulle istanze bare metal degli hyperscaler supportati. Quando gli utenti sono pronti per l'upgrade al portafoglio più ampio, possono adeguare la propria sottoscrizione senza dover eseguire nuovamente il deployment dei cluster esistenti.

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 Datacenters o per VM distinte).

Red Hat Advanced Cluster Management e Red Hat Ansible® Automation Platform supportano entrambi OpenShift Virtualization Engine. Per questi prodotti sono disponibili sottoscrizioni per componenti aggiuntivi dedicate esclusivamente agli scenari di utilizzo di virtualizzazione, a un costo inferiore rispetto alla versione completa. 

Per i clienti esistenti di Red Hat 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 per componenti aggiuntivi indicate. 

Per i clienti che non hanno installato le applicazioni centrali Red Hat Advanced Cluster Management o Ansible Automation Platform, 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 Red Hat 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, Red Hat 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 stimare i diritti necessari 

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 distribuito su Red Hat OpenShift (ad esempio database, server statici front end o istanza di VM).

Questa cifra può essere un valore approssimativo, utilizzato per stimare le dimensioni dell'ambiente Red Hat OpenShift. È possibile affinare ulteriormente questa stima tenendo conto della CPU, dell'oversubscription della memoria, delle quote, dei limiti e di altre funzionalità.

Tabella 1. Domande sul dimensionamento di istanze e applicazioni

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

Una volta individuati i requisiti per un'istanza applicativa e il numero di istanze applicative, non è difficile stabilire la quantità totale di risorse necessarie in termini di calcolo e memoria. 

A questo punto, devi determinare l'utilizzo massimo desiderato per i nodi di calcolo, prevedendo anche il carico gestionale di OpenShift (ulteriori informazioni sono reperibili nella documentazione, ma in genere si tratta di 1 core o 1 vCPU e di 1 GB di memoria RAM per nodo di calcolo) e la normale variabilità dell'applicazione prima che sia necessaria la scalabilità automatica. Può essere necessario tenere esplicitamente conto dei requisiti di sovraccarico di OpenShift nel calcolo delle risorse di memoria e core se prevedi un utilizzo intensivo (superiore all'80%).

Negli scenari di virtualizzazione, vanno considerati fattori come l'overcommit di CPU e memoria, la ridondanza, l'alta disponibilità e l'architettura complessiva dell'ambiente. Nell'Esempio 3 è illustrato un caso di dimensionamento.

Tabella 2. Domande relative all'utilizzo preferenziale massimo dei nodi OpenShift

Utilizzo massimo = % scelta dall'architetto

Core (o vCPU) totali necessari = "Core per 1 applicazione" X "numero di istanze applicative" X 1 / "percentuale di utilizzo"

Memoria totale necessaria = "Memoria per 1 applicazione" X "numero di istanze applicative" X 1 / "percentuale di utilizzo"

Passaggio 3. Seleziona un nodo di calcolo standard (VM, istanza cloud o server bare metal)

Ora disponi del numero totale di core e della quantità di memoria che soddisfano le tue esigenze. Devi quindi scegliere un nodo di calcolo standard per distribuire i nodi di lavoro delle tue applicazioni. 

L'ambiente dell'infrastruttura di virtualizzazione può consentirti di scegliere la configurazione delle macchine virtuali che serviranno come nodo di calcolo, oppure potresti dover selezionare uno tra i tanti tipi di VM con dimensioni standard. 

In un cloud hyperscaler, la scelta ricade in genere su un tipo di istanza di cloud con calcolo, memoria e accesso diversi a dispositivi facoltativi, come gli acceleratori di IA. 

Se il deployment avviene su bare metal, che sia in sede o in un'istanza hyperscaler bare metal, potresti avere una configurazione del server standard; in alcuni casi puoi specificare la configurazione. 

Se possibile, scegli i nodi di calcolo che corrispondono meglio al rapporto tra i requisiti di core e quelli di memoria. Se, ad esempio, il requisito totale per i container è di 400 vCPU e di 1600 GB di RAM, i migliori rapporti di consolidamento medio si ottengono scegliendo nodi di calcolo con un rapporto 1:4 tra vCPU e memoria. 

Tabella 3. Domande sul dimensionamento di VM e hardware

Passaggio 4. Calcola le sottoscrizioni totali necessarie

Infine, puoi determinare il numero delle sottoscrizioni Red Hat OpenShift necessarie sulla base dei dati raccolti nei precedenti passaggi da 1 a 3. Per le sottoscrizioni su istanze di VM o di cloud hyperscaler, devi utilizzare il modello di sottoscrizione basato su coppia di core. Per i server bare metal, devi calcolare la sottoscrizione servendoti di entrambi i modelli, confrontare le differenze in termini di costo e flessibilità di entrambi e quindi scegliere quello più adatto alle tue esigenze. 

Per il modello di sottoscrizione basato su coppia di core

• Numero di sottoscrizioni basate su coppia di core della versione autogestita di OpenShift¹ 

= Core totali / 2, con arrotondamento per eccesso o

= vCPU totali / 4, con arrotondamento per eccesso

Per il modello di sottoscrizione basato su nodo bare metal

• Innanzitutto, calcola il numero di sottoscrizioni basate su coppia di core necessarie per la tua applicazione, perché puoi utilizzare questo modello di sottoscrizione in un'installazione bare metal
• In secondo luogo, determina il numero di sottoscrizioni bare metal: ogni server fisico richiede una sottoscrizione basata su nodo bare metal (è necessaria una sottoscrizione per nodo).
• Infine, confronta le differenze di costo e flessibilità tra i due modelli.
  • Dal punto di vista economico:
    • Probabilmente un modello di sottoscrizione risulterà più costoso dell'altro per l'ambiente dimensionato.
    • In futuro, si potrebbe arrivare a un punto di equilibrio delle capacità, superato il quale sarà l'altro modello ad essere migliore dal punto di vista economico.
  • Dal punto di vista architetturale:
    • Le sottoscrizioni basate su coppia di core possono essere utilizzate per qualsiasi elemento dell'ambiente (VM, istanze cloud, server bare metal), mentre quelle basate su nodo bare metal possono essere utilizzate esclusivamente sui server bare metal.
    • Le sottoscrizioni basate su coppia di core su server bare metal richiedono l'esecuzione dei container su bare metal e l'utilizzo di un unico cluster.
    • Puoi scegliere di installare OpenShift Virtualization Engine sui server bare metal e quindi aggiungere le sottoscrizioni OpenShift basate su coppia di core per i container (OpenShift-on-OpenShift). Questo approccio è adatto agli ambienti di VM misti con un numero contenuto di OpenShift per server.
    • Nel caso in cui sia necessaria un'elevata densità di carichi di lavoro Red Hat OpenShift su un server bare metal, la sottoscrizione basata su nodo bare metal ti consente di utilizzare un numero illimitato di container OpenShift direttamente su bare metal oppure, mediante la funzionalità OpenShift Virtualization, all'interno delle VM in esecuzione sul server.

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

Aggiungi tutte le sottoscrizioni AI Accelerator indicate sopra. Ti occorre una sottoscrizione AI Accelerator per ogni acceleratore fisico on premise o su server bare metal. In un ambiente cloud hyperscaler, i tipi di istanza per il calcolo accelerato elencano il numero di GPU o acceleratori fisici inclusi in quel tipo di istanza. Ricorda di associare lo SLA della sottoscrizione AI Accelerator alla sottoscrizione Red Hat OpenShift corrispondente.

Nota: 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 sono indicativi e potrebbe essere possibile ottimizzare l'ambiente effettivo per utilizzare meglio le risorse o ridurne le dimensioni complessive. 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 sempre influisce 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. 

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 ricavate dal passaggio 1:

• Utilizzo massimo = 80%
• vCPU totali necessarie = 1 vCPU X 200 X 1/80% = 250 vCPU
• Memoria totale necessaria = 4 GB X 200 X 1/80% = 1000 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 nostro rapporto vCPU:memoria è 250 vCPU:1000 GB, ovvero 1:4. Fortunatamente, sono disponibili numerosi tipi di istanze con questo rapporto. 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 coppia 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 con arrotondamento per eccesso

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, sarebbero 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 è pari all'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 ricavate dal passaggio 1:

• Utilizzo massimo = 80%
• vCPU totali necessarie = 1 vCPU X 200 X 1/80% = 250 vCPU
• Memoria totale necessaria = 4 GB X 200 X 1/80% = 1000 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 nodo bare metal. Le calcoleremo entrambe:

Sottoscrizioni totali basate su coppia di core = vCPU totali necessarie / 4, con arrotondamento per eccesso 
250 vCPU / 4 = 62,5, o 63 con arrotondamento per eccesso

Totale sottoscrizioni basate su nodo = Numero totale di server fisici

• Numero totale di server necessari = 250 vCPU / 128 vCPU per server, con arrotondamento per eccesso = 2 server
• 2 server x 1 sottoscrizione/server = 2 sottoscrizioni basate su nodo bare metal

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

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 nodo 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 = 1700
• vCPU totali = 4000 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 ricavate dal passaggio 1:

• Memoria totale necessaria = 20.800 GB + 423 GB di sovraccarico = 21.223 GB
• vCPU totali necessari = 4000 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 = 4000 vCPU x 1/4 x 1 core/vCPU = 1000 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 nodo bare metal.

Sottoscrizioni basate su nodo totali = 

• Numero totale di server necessari = 20
• 20 server x 1 sottoscrizione/server = 20 sottoscrizioni basate su nodo 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 nodo 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 (comunemente utilizzate con Red Hat 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 Advanced Developer Suite
• 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 Data Foundation Advanced
• Red Hat OpenShift Developer Hub (la build 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.