Pool replicati (predefinito)

La configurazione ODF predefinita utilizza la replica a tre vie. Ogni dato viene archiviato in 3 copie su nodi diversi e garantisce protezione contro un massimo di 2 guasti simultanei di dischi o nodi.

• Vantaggi: architettura semplice, letture veloci, ripristino rapido e latenza prevedibile.
• Aumento dell'utilizzo: 3x di spazio di archiviazione grezzo per ogni byte di dati utilizzabili.

Cosa succede in caso di smarrimento delle copie ( rep3 ):

Il parametro min_size controlla il numero minimo di copie che devono essere disponibili prima che Ceph permetta l'I/O. ODF imposta per impostazione predefinita il parametro " min_size=2 " per i pool " rep3 " e tale impostazione viene applicata tramite " requireSafeReplicaSize: true"; ciò significa che, quando sono disponibili 2 o 3 copie, le operazioni di lettura e scrittura procedono normalmente. Quando è disponibile una sola copia, Ceph blocca le operazioni di I/O per evitare ulteriori incongruenze nei dati.

Questo comportamento è un meccanismo di sicurezza intenzionale che privilegia l'integrità dei dati rispetto alla disponibilità.

Il periodo che intercorre tra la perdita della seconda copia e il completamento della re-replicazione è quello più pericoloso. Durante questo periodo, un terzo guasto causa la perdita permanente dei dati. Ecco perché la pianificazione della capacità è importante: la velocità di replica di Ceph dipende dalla larghezza di banda disponibile del cluster e dallo spazio libero. Un cluster sovraccarico o quasi pieno impiega più tempo a eseguire la replicazione, il che prolunga il periodo di vulnerabilità.

Per le pool “ rep2 ”, la progressione è più aggressiva. Se 1 copia viene persa, ne rimane solo 1. Con l'opzione " min_size=2 " (impostazione predefinita), l'I/O viene immediatamente bloccato sui PG interessati fino al ritorno dell'OSD mancante o alla replica di una nuova copia. Con l'opzione " min_size=1", le operazioni di I/O proseguono sull'unica copia rimasta, ma un secondo guasto comporta la perdita definitiva dei dati.

Il componente aggiuntivo ODF di Red Hat OpenShift Kubernetes Service crea automaticamente solo pool rep3 con ocs-storagecluster-cephblockpool. Rep2 I pool non vengono creati dall'add-on. È necessario creare manualmente un file personalizzato “ CephBlockPool ” contenente “ replicated.size: 2 ” e un file corrispondente “ StorageClass ”. Per ulteriori informazioni, consultare la sezione " Creazione di un file " StorageClass " personalizzato per la virtualizzazione".

Poiché rep2 offre una tolleranza ai guasti inferiore rispetto a rep3, valutate se il risparmio in termini di spazio di archiviazione giustifichi il maggiore rischio per il vostro carico di lavoro.

IBM raccomanda la replica a tre vie per tutti i carichi di lavoro di virtualizzazione in produzione, al fine di garantire la disponibilità e la durabilità dei dati.

Piscine con codifica a cancellazione

Per gli ambienti in cui l'efficienza della capacità di archiviazione è una priorità, ODF supporta anche i pool con codice di cancellazione (EC). EC suddivide i dati in blocchi di dati ( k ) e blocchi di parità ( m ), riducendo così l'utilizzo di spazio di archiviazione grezzo rispetto alla replica, pur garantendo comunque la tolleranza ai guasti.

Stato del supporto: la codifica a cancellazione per RBD e CephFS in ODF è una funzionalità in anteprima per sviluppatori, introdotta per la prima volta in ODF 4.20. Le funzionalità della versione Developer Preview non sono supportate per l'uso in produzione. Inoltre, non rientrano nella gestione dei casi del Portale clienti Red Hat. Prima dell'ODF 4.20, era disponibile solo l'EC RGW (object storage) come anteprima per sviluppatori (da ODF 4.16 ). Sebbene il motore di storage Ceph sottostante supporti le sovrascritture EC per RBD dalla release Luminous (2017), l'operatore ODF e il suo modello di distribuzione gestita non certificano ancora i pool EC per i carichi di lavoro di storage a blocchi di produzione. Si consiglia di utilizzare pool replicati ( rep2 o rep3 ) per tutti gli ambienti di produzione VM e di archiviazione e di valutare i pool EC solo per gli ambienti non di produzione in cui le limitazioni della versione Developer Preview sono accettabili.

La tabella seguente mette a confronto tutti i tipi di pool disponibili, a titolo di riferimento.

I seguenti elenchi illustrano gli aspetti fondamentali da considerare nella codifica a cancellazione.

• I pool EC presentano una latenza di scrittura maggiore rispetto ai pool replicati a causa del calcolo della parità e della necessità di scrivere un numero maggiore di blocchi per ogni operazione.
• I pool EC offrono un throughput di lettura sequenziale competitivo, ma potrebbero mostrare IOPS di scrittura casuali ridotti.
• Il numero di domini di errore deve essere almeno pari a k+m. Su un cluster a 3 nodi, sono possibili solo rep2, rep3 e ec-2-1.
• Per un cluster a 6 nodi, sono disponibili tutti i tipi di pool elencati in precedenza.

Pool con replica singola (non resiliente, solo per sviluppo e test)

A partire dalla versione del componente aggiuntivo ODF 4.14, Red Hat OpenShift Kubernetes Service supporta un pool di singole repliche ( rep1 ) attraverso il parametro addSingleReplicaPool. Questo parametro crea un pool di blocchi Ceph non resiliente, senza replica dei dati, in cui ogni blocco di dati viene memorizzato una sola volta.

Per abilitare il pool a replica singola durante l'implementazione di ODF, utilizzare il seguente comando

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

Questo comando crea un ulteriore StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: Archiviazione a blocchi a replica singola con legatura dei volumi WaitForFirstConsumer.

Con questo strumento viene ancora creato il pool standard " replica-3 " (ocs-storagecluster-cephblockpool). Il pool non resiliente è un'opzione separata e opt-in.

Un singolo pool di repliche presenta i seguenti casi d'uso.

• Ambienti di sviluppo e di test, in cui la durata dei dati non è fondamentale e la priorità è data al risparmio sui costi di archiviazione.
• Applicazioni con replica integrata: queste applicazioni gestiscono autonomamente la ridondanza dei dati a livello di applicazione. Queste applicazioni mantengono più copie distribuite tra i nodi, il che significa che la replica a livello di archiviazione è ridondante.

Il singolo pool di repliche offre una tolleranza di errore pari a zero. Il guasto di un singolo OSD o nodo comporta la perdita permanente e irrecuperabile di tutti i dati presenti su quell'OSD. Non è disponibile una seconda copia per il ripristino. La documentazione di IBM Cloud avverte esplicitamente che questa opzione aumenta il rischio di perdita di dati, corruzione dei dati e potenziale instabilità del sistema. Per ulteriori informazioni, consultare la documentazione di Ceph.

Limitazioni:

• Solo archiviazione a blocchi: l'archiviazione dei file non è supportata con una singola replica.
• Richiede dischi aggiuntivi: almeno un disco NVMe utilizzabile in più per ogni nodo, oltre a quelli utilizzati dal pool “ replica-3 ”. Senza questo disco aggiuntivo, gli OSD di replica-1 non si avviano e il cluster di archiviazione rimane in uno stato di avanzamento.
• Un pool per dominio di guasto: ODF crea un CephBlockPool non resiliente per dominio di guasto, con volumi vincolati utilizzando WaitForFirstConsumer per convalidare la localizzazione dei dati.
• Non è raccomandato per i dischi root dei carichi di lavoro delle macchine virtuali: Se l'OSD che ospita un disco root si guasta, il carico di lavoro della macchina virtuale viene definitivamente perso. Utilizzate il pool non resiliente solo per i dischi di dati usa e getta nei carichi di lavoro delle macchine virtuali dev o di prova.

Per i carichi di lavoro di virtualizzazione in ambiente di produzione, utilizzare sempre pool " replica-3 " (o, come minimo, " replica-2 ").

VMware vSAN confronto tra le migrazioni

Per i team che stanno effettuando la migrazione da VMware vSAN™, questi tipi di pool Ceph corrispondono alle politiche di archiviazione vSAN già note:

Le principali differenze rispetto a vSAN:

• Minimo di host: Ceph separa il quorum del cluster dal posizionamento dei dati. Un pool “ rep3 ” richiede solo 3 host perché ogni host memorizza una copia completa. vSAN RAID-1 FTT=2 richiede 5 host.
• rep2 corrisponde allo standard vSAN RAID-1: La maggior parte delle implementazioni di vSAN utilizza FTT=1, che memorizza 2 copie. L' rep2 " di Ceph è l'equivalente diretto.
• ec-3-1 corrisponde a vSAN e RAID-5:. Entrambe utilizzano una configurazione 3+1 e raggiungono un utilizzo pari a 1.33x, l'opzione più efficiente in termini di spazio per la tolleranza a un singolo guasto.
• ec-4-2 corrisponde a vSAN e RAID-6:. Entrambe utilizzano una configurazione 4+2 e garantiscono un utilizzo del tipo " 1.5x " con tolleranza a doppio guasto.
• ec-2-1 e " ec-2-2 " non hanno un equivalente diretto in " vSAN ": configurazioni Ceph EC più piccole con un numero inferiore di blocchi di dati, che comportano un maggiore utilizzo per byte ma richiedono un numero inferiore di host. Sacrificano l'efficienza di archiviazione a favore di requisiti di numero di host inferiori.

Capacità di pianificazione

Quando si progetta il proprio cluster ODF, occorre tenere conto dello spazio di archiviazione lordo richiesto dalla politica di protezione dei dati scelta. La capacità utilizzabile è inferiore alla capacità NVMe grezza totale.

La formula della capacità utile è Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor.

Si veda il seguente esempio di calcoli per un cluster a 3 nodi con 8 x 3.2 TB di unità NVMe per nodo ( 76.8 TB in totale):

Stima della capacità del carico di lavoro della macchina virtuale: Un tipico carico di lavoro di una macchina virtuale con un disco root da 30 GB e un disco dati da 100 GB utilizza 130 GB di spazio di archiviazione utilizzabile. Con rep3, quel carico di lavoro della macchina virtuale richiede 390 GB di spazio di archiviazione grezzo. Sul cluster a 3 nodi descritto in precedenza, è possibile allocare circa 196 carichi di lavoro di macchine virtuali di queste dimensioni. In pratica, l'utilizzo di Ceph deve essere inferiore al 75% per mantenere le prestazioni e supportare le operazioni di ripristino.

Le prestazioni di Ceph si riducono con l'aumento dell'utilizzo del cluster. ODF genera l'avviso " CephOSDNearFull " ( Prometheus ) quando l'utilizzo di un qualsiasi OSD supera il 75%. All'85%, Ceph imposta il flag OSD nativo " nearfull " (mon_osd_nearfull_ratio) e ODF genera l'avviso " CephOSDCriticallyFull ". Al 90%, Ceph interrompe le operazioni di backfill e di recupero sull’OSD interessato (mon_osd_backfillfull_ratio). Al 95%, Ceph contrassegna l’OSD come “ full ” (mon_osd_full_ratio), blocca tutte le operazioni di scrittura ed emette un’ HEALTH_ERR. Pianificate la capacità in modo che il utilizzo rimanga al di sotto del 70% durante il normale funzionamento, lasciando un margine per il recupero dei dati e il ribilanciamento in caso di manutenzione o guasti dei nodi.

Per verificare l'utilizzo attuale del cluster, eseguire il seguente comando:

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

Numero di nodi di lavoro e topologia

La topologia dei domini di errore utilizzata dal componente aggiuntivo ODF di IBM Cloud dipende dalla configurazione del cluster:

• Cluster multizona (3 zone di disponibilità): il dominio di errore è impostato su zone. I nodi di lavoro sono distribuiti tra le zone e l'ODF deve crescere in multipli di 3 per mantenere l'equilibrio tra le zone. Per garantire disponibilità, prestazioni e sicurezza dei dati ottimali, utilizzare 3, 6 o 9 nodi nel cluster di storage ODF: ogni zona riceve lo stesso numero di nodi.
• Cluster a zona singola o cluster con meno di 3 zone di disponibilità: il ridimensionamento flessibile viene abilitato automaticamente e il dominio di errore è impostato su host. Puoi iniziare con 3 nodi e aggiungerne uno alla volta.

Tutti i nodi che partecipano al cluster di storage ODF devono essere bare metal. Non è supportata la combinazione di nodi virtualizzati e nodi bare-metal all'interno dello stesso cluster ODF.

Per i cluster multizona: l'aggiunta di un numero di nodi che non sia un multiplo di 3 crea uno squilibrio tra le zone. Con 4 nodi, una zona ne riceve 2 mentre le altre ne ricevono 1 ciascuna, il che comporta una distribuzione non uniforme del carico sugli OSD, un posizionamento dei dati non ottimale, un utilizzo disomogeneo e OSD parzialmente inattivi.

Per i cluster multizona, scalare sempre in multipli di 3 per mantenere una topologia delle zone equilibrata.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

Piani di abbonamento ODF

Scegli il piano più adatto alle tue esigenze:

• Essentials

  • Costo ridotto
  • Solo implementazione in modalità interna
  • Non supporta il ripristino di emergenza, i cluster estesi né le implementazioni in modalità esterna
  • Ideale per ambienti di test e sviluppo, prove di fattibilità o implementazioni su piccola scala

• Avanzate

  • Set completo di funzionalità che include il ripristino di emergenza, i cluster estesi, l'implementazione in modalità esterna, la crittografia granulare avanzata e il supporto multi-cluster
  • Consigliato per carichi di lavoro di virtualizzazione di produzione con macchine virtuali

Entrambi i piani includono la compressione “ BlueStore ” sui pool di blocchi, il thin provisioning, le istantanee e la clonazione. Le differenze tra i piani riguardano il ripristino di emergenza, il livello di granularità della crittografia e la flessibilità di implementazione, piuttosto che le funzionalità relative all'efficienza dello storage.

ODF supporta la deduplicazione solo per lo storage degli oggetti attraverso il Multicloud Object Gateway (MCG). Lo storage a blocchi non supporta la deduplicazione. Questo servizio di assistenza è valido sia per il piano Essentials che per quello Advanced. La deduplicazione Ceph upstream per RBD rimane sperimentale e non è certificata per l'uso in ODF.

Per ulteriori informazioni, consultare la sezione “ODF: nozioni di base e nozioni avanzate ”.

Tipo di archiviazione

• Selezionare Archiviazione locale.
• Lo storage locale utilizza lo storage di istanza NVMe locale disponibile sui nodi worker bare metal.
• Le unità NVMe offrono una latenza ridotta e elevate prestazioni in termini di IOPS, caratteristiche indispensabili per i dischi destinati ai carichi di lavoro delle macchine virtuali.

Profilo della risorsa ODF

ODF fornisce tre profili di allocazione delle risorse che controllano la CPU e la memoria riservata ai demoni Ceph.

• Lean: allocazione minima delle risorse. Il profilo Lean è adatto ad ambienti con risorse limitate, a test, sviluppo e prove di concetto. L'approccio Lean non è consigliato per i carichi di lavoro relativi alla virtualizzazione della produzione.
• Bilanciato: Il profilo predefinito su Red Hat OpenShift Kubernetes Service. Il profilo Balanced offre un equilibrio tra consumo di risorse e prestazioni per carichi di lavoro generici.
• Prestazioni: assegna una maggiore quantità di CPU e memoria ai daemon di Ceph, riducendo così il rischio di colli di bottiglia a livello dei daemon. Ideale per carichi di lavoro con elevato numero di IOPS, grandi quantità di server virtuali e applicazioni esigenti.

Per le implementazioni bare-metal con unità NVMe locali, utilizzare il profilo di risorse “Performance ”. I nodi bare-metal con 8 o più unità NVMe per nodo generano un numero elevato di OSD per host. Con il profilo “Balanced”, i limiti di CPU e memoria del daemon Ceph vengono spesso raggiunti prima che l’hardware NVMe sottostante raggiunga la saturazione, il che limita gli IOPS e aumenta la latenza. Il profilo "Performance" è il profilo minimo consigliato per i carichi di lavoro di virtualizzazione di Red Hat OpenShift in ambiente di produzione su bare-metal.

I requisiti di risorse mostrati nella console web Red Hat OpenShift durante l'installazione di ODF sono calcolati dinamicamente in base al conteggio degli OSD del cluster. Pertanto, i cluster con un numero maggiore di unità NVMe richiedono proporzionalmente più risorse. I valori non sono fissi. Verificare sempre i requisiti visualizzati nella console per la configurazione specifica del cluster.

Il profilo viene selezionato durante la creazione di StorageSystem attraverso la schermata Configure Performance della console web Red Hat OpenShift. I daemon Ceph con risorse insufficienti possono diventare un collo di bottiglia nascosto, causando una riduzione degli IOPS o una latenza superiore a quella che l'hardware di archiviazione sottostante è in grado di garantire.

Abbinate i profili dei server bare metal ai requisiti di risorse indicati per il profilo scelto: IBM Cloud Profili di server bare metal VPC.

Un leggero eccesso di risorse è spesso accettabile su un server bare metal. Tuttavia, non assegnare mai risorse significativamente inferiori ai requisiti minimi indicati, poiché ciò compromette le prestazioni e la stabilità di ODF.

Numero di dischi OSD per nodo

• Determinare il numero di unità NVMe locali disponibili su ciascun server bare metal.
• Assicurarsi che il numero di OSD configurati per nodo non superi il numero di unità NVMe utilizzabili.
• La configurazione consigliata prevede 1 OSD per ogni unità NVMe, al fine di garantire prestazioni ottimali e l'isolamento dei guasti.
• Assicurarsi che il numero di dischi OSD corrisponda, in linea di massima, al numero di unità NVMe per ogni nodo bare metal. Il calcolo della capacità di archiviazione visualizzato nell'interfaccia utente non riflette la capacità effettiva utilizzabile per le configurazioni di archiviazione locale e può essere ignorato.

Quando si selezionano i nodi durante la creazione di un cluster di tipo " StorageSystem ", evitare di selezionare tutti i nodi del cluster. Selezionando tutti i nodi si crea un sistema di bilanciamento del carico ( LocalVolumeSet, LVS) senza nodeSelector. Qualsiasi nodo di lavoro che verrà aggiunto al cluster in futuro verrà rilevato automaticamente da ODF, anche se non è destinato allo storage. I nodi rilevati in modo imprevisto devono essere rimossi manualmente dall'LVS. Per evitare che ciò accada, seleziona solo i nodi presenti nel tuo pool di worker di archiviazione dedicato oppure assicurati che tali nodi abbiano l'etichetta " cluster.ocs.openshift.io/openshift-storage " prima di creare un StorageSystem.

StorageClass predefinito per il cluster

Una volta completata l'implementazione di ODF, vengono solitamente creati i file di configurazione del sistema di gestione delle risorse ( followingStorageClasses ):

• ocs-storagecluster-ceph-rbd: Archiviazione a blocchi
• ocs-storagecluster-cephfs: Archiviazione dei file
• ocs-storagecluster-ceph-rgw: Memorizzazione degli oggetti

Per consentire ai carichi di lavoro di utilizzare automaticamente uno storage a blocchi persistente ad alte prestazioni basato su ODF senza necessità di ulteriori configurazioni, selezionare "Usa dispositivo a blocchi Ceph RADOS (RBD) " come classe di storage predefinita oppure impostare manualmente RBD (ocs-storagecluster-ceph-rbd) come classe di storage predefinita ( StorageClass ) per il cluster dopo l'installazione del componente aggiuntivo ODF.

1. Contrassegnare RBD come predefinito:

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. Se necessario, rimuovere l'impostazione predefinita precedentemente configurata:

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

Lista di controllo della configurazione di ODF

• Il cluster contiene almeno un pool di server bare metal
• Red Hat OpenShift versione 4.17 o successive
• Il componente aggiuntivo e l'operatore ODF sono installati e funzionanti
• I server bare metal dispongono di un numero sufficiente di unità NVMe locali utilizzabili
• Il profilo di risorsa selezionato corrisponde alla capacità del nodo
• Il cluster di archiviazione ODF richiede un minimo di 3 nodi; i cluster multizona devono avere un numero di nodi multiplo di 3 (3, 6, 9, …) per mantenere l'equilibrio della zona
• Tutti i nodi partecipanti a ODF sono bare metal
• L'RBD StorageClass viene creato e preferibilmente impostato come predefinito
• Lo stato del cluster ODF è "Pronto" (oc get storagecluster -n openshift-storage)
• Lo stato di integrità di Ceph è HEALTH_OK (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

Prerequisiti: installare l'operatore di virtualizzazione " Red Hat OpenShift "

Prima di utilizzare la virtualizzazion Red Hat OpenShift su IBM Cloud, verificare che l'operatore di virtualizzazione Red Hat OpenShift sia installato nel proprio cluster Red Hat OpenShift Kubernetes Service.

L’operatore di virtualizzazione “ Red Hat OpenShift ” consente la gestione dei carichi di lavoro delle macchine virtuali native dell’ Kubernetes. Fornisce inoltre i controller, i CRD e le integrazioni con i componenti di storage e di rete necessari.

Per ulteriori informazioni, vedere Red Hat OpenShift Virtualization su IBM Cloud.

Utilizzo dello storage ODF per i carichi di lavoro delle macchine virtuali

Red Hat OpenShift Data Foundation (ODF) fornisce uno storage persistente e definito dal software per i carichi di lavoro di virtualizzazione che girano su Red Hat OpenShift. Quando si utilizza ODF come backend di archiviazione per le macchine virtuali, la scelta del StorageClass corretto è fondamentale per garantire prestazioni, stabilità e piena compatibilità delle funzionalità.

È necessario specificare l' StorageClass e appropriato nelle seguenti situazioni:

• Vengono creati i server virtuali
• I server virtuali vengono importati o clonati
• I server virtuali vengono migrati su un cluster Red Hat OpenShift Kubernetes Service

Virtualizzazione predefinita StorageClass

Una volta installato l’ Red Hat OpenShift Virtualization Operator e quando è disponibile un cluster ODF, viene creato automaticamente un StorageClass ottimizzato per i carichi di lavoro di virtualizzazione:

• ocs-storagecluster-ceph-rbd-virtualization

Questo StorageClass è:

• Ottimizzato per i modelli di I/O del disco, come letture e scritture casuali e throughput sostenuto
• Convalidato per le operazioni del ciclo di vita della virtualizzazione, come avvio, arresto, migrazione live e snapshot
• Completamente supportato e raccomandato per gli ambienti di virtualizzazione Red Hat OpenShift in produzione

Per la maggior parte dei casi d'uso, utilizzare questo StorageClass senza modifiche.

Requisiti di archiviazione per la migrazione live

La migrazione live sposta il carico di lavoro di una macchina virtuale in esecuzione da un nodo worker a un altro senza tempi di inattività. Per una migrazione live riuscita, lo storage deve essere accessibile contemporaneamente sia dal nodo di origine che da quello di destinazione. La migrazione live richiede le seguenti configurazioni.

• ReadWriteMany modalità di accesso sui PVC dei carichi di lavoro delle macchine virtuali. Ceph RBD supporta RWX in modalità blocco, che è la configurazione predefinita per la virtualizzazione ODF StorageClass.
• ocs-storagecluster-ceph-rbd-virtualization StorageClass è preconfigurato con il supporto per l' ReadWriteMany, tramite la modalità a blocchi RBD. I server virtuali che utilizzano questo StorageClass possono migrare senza ulteriori configurazioni.
• Il generico ocs-storagecluster-ceph-rbd StorageClass utilizza la modalità di accesso ReadWriteOnce per impostazione predefinita. I server virtuali che utilizzano PVC RWO non possono eseguire la migrazione live. La migrazione non riesce perché il PVC non può essere montato sul nodo di destinazione mentre è collegato all'origine.

Se si creano dei " customStorageClasses " (PVC) per server virtuali che richiedono la migrazione in tempo reale, verificare che i PVC siano creati con le opzioni " accessModes: [ReadWriteMany] " e " volumeMode: Block".

La migrazione live richiede anche:

• Configurazione dell'Operatore di virtualizzazione Red Hat OpenShift con una politica di migrazione adeguata
• Verifica della disponibilità di CPU e memoria sufficienti sul nodo di destinazione

Specifico per la virtualizzazione rispetto all'RBD generico StorageClass

Sebbene le macchine virtuali possano utilizzare un RBD Ceph generico StorageClass,, il disco specifico per la virtualizzazione StorageClass è ottimizzato per le caratteristiche uniche di I/O e del ciclo di vita dei dischi dei carichi di lavoro delle macchine virtuali.

L'RBD generico StorageClasses rimane adatto ai carichi di lavoro dei container, ma per gli ambienti di virtualizzazione di produzione si consiglia l' StorageClass, specifico per la virtualizzazione.

Creare un StorageClass personalizzato per la virtualizzazione

In alcuni scenari, potrebbe essere necessario un StorageClass personalizzato per soddisfare requisiti specifici di prestazioni, resilienza o capacità.

Per creare un requisito personalizzato StorageClass, è necessario prima creare un requisito personalizzato CephBlockPool. Quando si crea un pool personalizzato, è necessario impostare targetSizeRatio sul pool. Senza questa impostazione, lo scalatore automatico dei gruppi di collocazione di Ceph assegna al pool un solo gruppo di collocazione. Questa configurazione provoca un collo di bottiglia di tutte le operazioni di I/O su un singolo OSD, con conseguente peggioramento delle prestazioni rispetto al pool predefinito.

Quando si crea un sito StorageClass personalizzato per i carichi di lavoro di virtualizzazione, verificare che i seguenti parametri siano configurati correttamente.

• Provveditore

  L' StorageClass e deve utilizzare il provisioner CSI Ceph RBD fornito da ODF:

  openshift-storage.rbd.csi.ceph.com
  

  Questo provisioner consente il provisioning dinamico dei volumi Ceph RBD che sono supportati dal cluster ODF.

• Pool di archiviazione

  Specificare il sito CephBlockPool che esegue il backup dei dischi del carico di lavoro della macchina virtuale. È possibile selezionare una delle seguenti opzioni:

  • Pool di blocchi predefinito. Il pool di blocchi Ceph replicato a 3 vie predefinito creato da ODF:

      ocs-storagecluster-cephblockpool
      ```
  
  - Piscina in blocco personalizzata. Un sito definito dall'utente CephBlockPool. Il pool deve includere le seguenti impostazioni per evitare problemi di prestazioni:
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• Caratteristiche dell'immagine

  Il sito StorageClass deve includere le caratteristiche dell'immagine RBD che sono fondamentali per le prestazioni del carico di lavoro:

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  Caratteristiche dell'immagine RBD e loro scopo

  Funzione	Scopo
  exclusive-lock	Abilita la cache di writeback e le ottimizzazioni per un singolo writer. Senza questa funzione, gli IOPS in scrittura possono peggiorare fino a 7x.
  object-map	Abilita il tracciamento bitmap degli oggetti allocati per le immagini rade.
  fast-diff	Accelera le operazioni di snapshot diff e DataVolume clone per velocizzare i tempi di avvio.
  deep-flatten	Rende i cloni completamente indipendenti dopo l'appiattimento.
  layering	Abilita la clonazione copy-on-write, necessaria per la clonazione DataVolume.

• Opzioni della mappa

  mapOptions: krbd:rxbounce
  

  Questa opzione risolve i problemi di danneggiamento dei dati che si verificano quando si utilizza il driver RBD del kernel con i server virtuali Windows. Costringe il kernel a utilizzare un buffer di rimbalzo per i dati ricevuti, al fine di garantire la compatibilità. Questa opzione deve essere configurata su tutti i carichi di lavoro StorageClasses.

• Esempio completo di StorageClass personalizzato

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  Per trovare clusterID per il proprio cluster, eseguire il seguente comando:

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  Per i pool con codifica di cancellazione (solo in anteprima per sviluppatori), consultare la sezione "Informazioni sulla protezione dei dati", aggiungere dataPool in modo che punti al pool EC e mantenere pool in modo che punti al pool replicato predefinito:

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

Compressione

ODF supporta la compressione in linea BlueStore sui pool di blocchi Ceph, che può ridurre lo storage grezzo utilizzato dai dischi. La compressione viene applicata in modo trasparente a livello di OSD, pertanto il carico di lavoro della macchina virtuale e il suo sistema operativo guest non si accorgono che i dati vengono compressi.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

Crittografia

ODF supporta la crittografia dei dati a riposo a più livelli, che possono essere attivati in modo indipendente.

• IBM Cloud Crittografia dell'infrastruttura: crittografia completa del disco su unità NVMe fisiche - gestita da IBM Cloud.
• Crittografia a livello di cluster ODF: tutti i dischi OSD di Ceph sono crittografati con dm-crypt a livello di dispositivo. Abilitato tramite encryption.clusterWide: true sul cluster di archiviazione CR. Protegge dal furto di dischi fisici.
• Crittografia ODF per volume: i singoli volumi RBD vengono crittografati con LUKS2, ciascuno con la propria chiave di crittografia dei dati. Garantisce l'isolamento dei tenant e una gestione granulare delle chiavi.

Su Red Hat OpenShift Kubernetes Service, ODF si integra con IBM Key Protect come servizio di gestione delle chiavi esterne per la crittografia a livello di cluster e per volume. Quando la codifica per volume è abilitata, ODF crea automaticamente le varianti -encrypted StorageClass (ad esempio, ocs-storagecluster-ceph-rbd-encrypted).

Ottimizzazione delle prestazioni di Ceph per sistemi bare-metal NVMe

La configurazione predefinita di Ceph è ottimizzata per carichi di lavoro generici. I seguenti valori dei parametri sono stati verificati sul profilo bare-metal " mx2d.metal.96x768 " e aumentano in modo significativo gli IOPS, riducendo al contempo la latenza per i carichi di lavoro su disco " VM " su tale profilo. Se stai utilizzando un profilo bare-metal diverso, considera questi valori come punto di riferimento iniziale e modificali in base al numero di unità NVMe e alla CPU disponibile nel tuo profilo specifico.

Applicare ciascun parametro utilizzando il comando ceph config set dal pod “Ceph toolbox”:

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

Dopo aver effettuato la richiesta, verifica che la configurazione sia stata accettata:

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

Non è necessario riavviare i pod OSD per apportare modific ceph config set i. Ceph applica la configurazione in modo dinamico. Tuttavia, le modifiche alla cache di “ BlueStore ” (osd_memory_target) hanno pieno effetto solo dopo che ogni pod OSD è stato riciclato. È possibile riciclare le capsule OSD una alla volta durante una finestra di manutenzione senza interrompere le operazioni di I/O.

Riferimento benchmark: i test interni condotti su un cluster mx2d.metal.96x768 a 3 nodi con 200 macchine virtuali e IOPS illimitate hanno dimostrato che la combinazione di 16 shard, 8 GB di memoria OSD e un buffer di scrittura " RocksDB " da 256 MB ha raggiunto circa 194.000 IOPS e un throughput di 758 MB/s. L'aumento del numero di shard da 8 a 16 ha prodotto costantemente il miglioramento più significativo in termini di IOPS in tutte le configurazioni di test.

Backup basato su istantanee

ODF supporta Kubernetes VolumeSnapshots per i volumi Ceph RBD. Per creare un'istantanea di un disco, utilizzare il seguente comando:

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots sono copia su scrittura e la loro creazione è quasi istantanea. È possibile utilizzarli per ripristinare lo stato precedente di un carico di lavoro di una macchina virtuale o per clonare un disco. La virtualizzazione di Red Hat OpenShift offre inoltre una funzione integrata denominata “ VM API per l'acquisizione di snapshot e il ripristino ” che acquisisce, in un’unica operazione, lo stato completo del carico di lavoro della macchina virtuale, compresa la configurazione e tutti i dischi.

Quiescing dei carichi di lavoro delle macchine virtuali per snapshot coerenti con le applicazioni

Quando si acquisisce un’istantanea di un carico di lavoro su una macchina virtuale in esecuzione, i dati presenti sul disco devono trovarsi in uno stato coerente. Senza quiescenza, lo snapshot cattura tutto ciò che si trova sul disco in quell'istante, comprese le transazioni parzialmente scritte, i buffer sporchi e l'I/O in volo. Questo processo genera un’istantanea coerente in caso di arresto anomalo, che potrebbe richiedere un ripristino a livello di applicazione al momento del ripristino.

Per ottenere snapshot coerenti con le applicazioni, è necessario bloccare il file system del sistema ospite prima di creare lo snapshot e sbloccarlo in seguito. Red Hat OpenShift La virtualizzazione automatizza questo processo utilizzando l’agente ospite QEMU.

Il controller snapshot rileva l'agente guest QEMU. Prima di acquisire lo snapshot, esegue il comando “ guest-fsfreeze-freeze ”, che blocca tutte le operazioni di I/O dei file system. L’ VolumeSnapshot e viene acquisito mentre il file system è bloccato. Dopo il completamento dell'istantanea, un comando guest-fsfreeze-thaw ripristina l'I/O. Lo stato dello snapshot indica il livello di coerenza raggiunto. Per conoscere il significato di ciascuno stato, consultare la tabella seguente.

Si consiglia di installare l'agent guest di QEMU su tutte le macchine virtuali di produzione. Per gli ospiti di Linux, utilizzare il seguente comando.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Per gli ospiti Windows, installare il pacchetto di driver VirtIO, che include il servizio QEMU guest agent.

Hook personalizzati di congelamento/scongelamento per le applicazioni: per i database e altre applicazioni con stato che richiedono un’ulteriore sospensione oltre al congelamento del file system, inserire script di hook personalizzati all’interno del carico di lavoro della macchina virtuale ospite all’indirizzo /etc/qemu-ga/fsfreeze-hook.d/. Questi script vengono eseguiti automaticamente dall’agente guest con l’argomento “ freeze ” prima del congelamento del file system e con l’argomento “ thaw ” dopo lo sblocco del file system. I registri di esecuzione degli hook vengono scritti su /var/log/qga-fsfreeze-hook.log.

Ad esempio, il seguente gancio di congelamento PostgreSQL può essere collocato in /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware Confronto: questo esempio è analogo allo script “ VMware ” (prima del congelamento e dopo lo scongelamento) utilizzato con VMware Tools per creare snapshot coerenti con l’applicazione. L'agente guest di QEMU svolge la stessa funzione degli Strumenti d VMware i per la sospensione degli snapshot.

Modificate le limitazioni del tracciamento dei blocchi

Il monitoraggio dei blocchi modificati (Changed Block Tracking) consente di eseguire backup incrementali, individuando solo i blocchi che sono stati modificati dall'ultimo backup. VMware Il VADP ( vStorage: API per la protezione dei dati) utilizza questo meccanismo per garantire backup incrementali efficienti.

Il CBT non è disponibile per ODF e Ceph RBD su Red Hat OpenShift Virtualization. Attualmente i backup si basano su snapshot completi, il che potrebbe comportare tempi di backup più lunghi e un maggiore utilizzo dello spazio di archiviazione.

Lo sviluppo della CBT è in corso a più livelli:

Sebbene Ceph RBD supporti la funzionalità sottostante “ rbd diff ” per identificare i blocchi modificati tra uno snapshot e l’altro, tale funzionalità non è ancora disponibile tramite l’API CSI “Changed Block Tracking” di Kubernetes. Finché lo stack completo non sarà pronto (API CSI CBT + supporto driver Ceph CSI + integrazione KubeVirt ), i backup incrementali a livello di blocco non saranno disponibili.

Soluzioni di backup

Diversi fornitori di soluzioni di backup offrono soluzioni per la virtualizzazione “ Red Hat OpenShift ” che funzionano nell’ambito dell’attuale modello basato sugli snapshot:

• Veeam® Kasten: Kubernetes-protezione nativa dei dati con supporto alla virtualizzazione Red Hat OpenShift e funzionalità di snapshot incrementale per ODF. Per ulteriori informazioni, consultare l'architettura di riferimento di Veeam Kasten.
• Trilio per Kubernetes: Backup e ripristino per i carichi di lavoro di Red Hat OpenShift Virtualization con integrazione ODF. Per ulteriori informazioni, vedere il supporto di Trilio Red Hat OpenShift Virtualization.
• Veritas NetBackup: Enterprise backup con supporto per la virtualizzazione Red Hat OpenShift. Per ulteriori informazioni, consultare il sito NetBackup- Protezione completa dei dati aziendali.

Raccomandazioni per le migrazioni su VMware

Se il vostro attuale ambiente VMware si basa su backup incrementali basati su CBT, considerate le seguenti raccomandazioni:

• Pianificare backup full-snapshot. Valuta le finestre di backup e i requisiti di archiviazione basandoti su backup completi ( VolumeSnapshots ) anziché su backup incrementali.
• Valutare gli strumenti di backup nativi di Kubernetes. Veeam Kasten e Trilio sono progettati per la virtualizzazione “ Kubernetes ” e “ Red Hat OpenShift ” e operano nell’ambito dell’attuale modello di snapshot.
• Utilizzare l'efficienza delle istantanee Ceph. Gli snapshot RBD di Ceph funzionano secondo il principio "copy-on-write" e utilizzano spazio di archiviazione solo per i blocchi modificati dopo la creazione dello snapshot, il che rende l'archiviazione degli snapshot in corso più efficiente rispetto alle copie complete.

Monitorare lo stato di salute di ODF e Ceph

Il monitoraggio regolare del cluster di storage ODF è essenziale per mantenere la disponibilità e le prestazioni. La sezione seguente descrive i comandi principali e i relativi risultati.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

Aggiornamento di ODF su Red Hat OpenShift Kubernetes Service

Il componente aggiuntivo Data Foundation (ODF) di IBM Cloud Red Hat OpenShift applica automaticamente gli aggiornamenti z-stream all’interno della stessa versione minore. Questi aggiornamenti sono gestiti da IBM Cloud.

Tuttavia, gli aggiornamenti di versione principali e secondari (ad esempio, da 4.18 a 4.19 ) non avvengono automaticamente. Seguire la procedura di aggiornamento manuale per garantire la sicurezza dei dati e la stabilità del cluster.

L'aggiornamento di ODF in un cluster Red Hat OpenShift Kubernetes Service consiste in due fasi principali, entrambe necessarie per la buona riuscita dell'aggiornamento.

1. Aggiornare o sostituire i nodi worker ODF.

   • ODF si basa su nodi worker dedicati o etichettati per ospitare i componenti di archiviazione.
   • Durante un aggiornamento maggiore o minore, questi nodi worker devono essere aggiornati o sostituiti per allinearsi alle versioni Red Hat OpenShift e ODF di destinazione.
   • Questo processo aiuta a garantire che i pod ODF (come gli OSD, i MON e i manager Ceph) vengano riprogrammati correttamente e continuino a funzionare senza perdita di dati.
   • Prima di procedere con questa fase, assicurarsi che la capacità sia adeguata e che i nodi funzionino correttamente, al fine di garantire la disponibilità dello storage.

2. Aggiornare il componente aggiuntivo ODF.

   • Dopo l'aggiornamento o la sostituzione dei nodi worker, aggiornare il componente aggiuntivo ODF.
   • Questo passaggio consente di aggiornare gli operatori ODF, i driver CSI e i relativi componenti alla versione di destinazione.
   • Al termine dell'aggiornamento del componente aggiuntivo, il cluster riconcilia automaticamente le risorse ODF e applica le modifiche richieste.

   Eseguire la verifica post-aggiornamento per confermare:

   • Salute del cluster ODF e Ceph
   • StorageClasses disponibilità
   • Operazioni di lettura e scrittura di PVC eseguite con successo dalle applicazioni

Per ulteriori informazioni, vedere Aggiornamento di ODF sui cluster VPC.

Ampliare lo spazio di archiviazione ODF su Red Hat OpenShift Kubernetes Service

Di conseguenza, con l'aumentare dei carichi di lavoro e delle esigenze di archiviazione, diventa fondamentale ampliare l'infrastruttura di archiviazione. L'espansione in ODF è un'operazione chiave del Giorno 2 che consente di aumentare la capacità di storage, migliorare le prestazioni e mantenere la resilienza senza interrompere le applicazioni in esecuzione.

Negli ambienti IBM Cloud Red Hat OpenShift Kubernetes Service, l'espansione comporta tipicamente l'ampliamento del pool di storage worker. Questa operazione viene eseguita con tempi di inattività minimi, consentendo una crescita continua del cluster di storage.

1. Aggiungi nodi di lavoro al tuo cluster VPC. Per i cluster multizona in cui il cluster di storage si estende su 3 zone di disponibilità, aggiungere nodi di lavoro in multipli di 3 per mantenere l'equilibrio tra le zone (ad esempio, 3, 6 o 9). Per i cluster a zona singola con il ridimensionamento flessibile abilitato, è possibile aggiungere i nodi uno alla volta.

2. Una volta aggiunti i nodi, registrarli su ODF. Se ODF è in esecuzione su tutti i nodi di lavoro del cluster, i nuovi nodi vengono aggiunti automaticamente alla topologia di archiviazione. Se ODF è in esecuzione solo su un sottoinsieme di nodi di lavoro, passare al passaggio successivo.

3. Se ODF viene eseguito su tutti i nodi worker del cluster, i nuovi nodi worker vengono aggiunti automaticamente alla topologia del cluster di storage ODF. Se ODF viene eseguito solo su un sottoinsieme di nodi di lavoro, specificare i parametri nella risorsa personalizzata OcsCluster. Aggiungere i nomi dei nuovi nodi worker alla distribuzione ODF modificando la definizione di risorsa personalizzata. Modificare la risorsa personalizzata " OcsCluster " come segue:

   • Trova ocscluster

     oc get ocscluster
     

   • Modifica il file delle risorse personalizzate di ocscluster e aggiungi nuovi nodi di lavoro

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • Salva il file delle risorse personalizzate " OcsCluster " per riapplicarlo al tuo cluster.

4. Aumenta il valore di 'numOfOsd' nella risorsa personalizzata OcsCluster per consentire a OCS di distribuire i componenti ODF sui nodi di lavoro appena aggiunti e di provisionare ulteriori OSD nel cluster di archiviazione.

   La regolazione dell' 'numOfOsd' e dipende sia dal numero di dischi OSD per nodo sia dal numero di nodi aggiunti. Ad esempio, se ogni nodo dispone di 8 dischi NVMe dedicati agli OSD, l'aggiunta di 3 nodi aumenta il numero di " 'numOfOsd' " di 8, mentre l'aggiunta di 6 nodi lo aumenta di 16.

5. Verifica il risultato eseguendo il seguente comando:

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. Verificare che i nuovi nodi di lavoro siano stati aggiunti e distribuiti in modo uniforme tra le varie zone (nel caso di cluster multizona) oppure che appaiano come singoli bucket di host (nel caso di cluster a scalabilità flessibile con una sola zona), insieme al numero corrispondente di OSD assegnati a ciascun nodo.

Per ulteriori informazioni, consulta la sezione " Espansione di ODF tramite l'aggiunta di nodi di lavoro al cluster VPC ".

Ridimensionamento flessibile

Il componente aggiuntivo ODF di IBM Cloud utilizza diverse topologie dei domini di errore a seconda della configurazione del cluster:

• Cluster multizona (3 zone di disponibilità): il dominio di errore è impostato su zone. Gli OSD vengono configurati in multipli di 3, un set per zona, per garantire la replica dei dati e l'alta disponibilità tra le zone. Il cluster di archiviazione deve espandersi in multipli di 3 per mantenere l'equilibrio tra le zone.
• Cluster a zona singola o cluster con meno di 3 zone di disponibilità: il ridimensionamento flessibile viene abilitato automaticamente. Il dominio di guasto è impostato su host, il che significa che ogni singolo nodo costituisce un dominio di guasto distinto. È possibile aggiungere un nodo alla volta e scalare lo spazio di archiviazione in modo granulare.

A partire da ODF 4.21, il comportamento di scalabilità flessibile viene determinato automaticamente al momento dell'implementazione iniziale in base alla topologia del cluster e non può essere modificato in seguito.

In un'implementazione a zona singola o con scalabilità flessibile, un pool di replica-3 resiste alla perdita di qualsiasi singolo host. In un'implementazione multizona, un pool di replica-3 resiste alla perdita di un'intera zona. Prima di implementare ODF in ambiente di produzione, verificare che la topologia del cluster e la relativa tolleranza ai guasti soddisfino i requisiti di resilienza.

Per l'elenco completo dei parametri aggiuntivi e le istruzioni di installazione tramite console, consultare la guida " Distribuzione di OpenShift Data Foundation su cluster VPC".

Prestazioni durante l'espansione dei nodi: l'aggiunta di un nodo a un cluster ODF a scalabilità flessibile innesca il ribilanciamento dei dati di Ceph. Nel test interno descritto di seguito, gli IOPS e il throughput sono rimasti stabili, mentre la latenza in scrittura ha registrato un aumento temporaneo. Durante i test interni condotti su un cluster a 3 nodi con 100 macchine virtuali a 50.000 IOPS, sono stati osservati i seguenti risultati:

La latenza di scrittura torna ai valori di riferimento al termine del ribilanciamento. Se i tuoi carichi di lavoro sono sensibili ai picchi di latenza in scrittura, pianifica l’aggiunta di nodi durante i periodi di minore attività dell’ VM.