Gestione della computazione in Autonomous AI Database su un'infrastruttura Exadata dedicata

Autonomous AI Database on Dedicated Exadata Infrastructure offre due modelli di computazione durante la configurazione delle risorse di Autonomous AI Database. Sono:

• ECPU: un'ECPU è una misura astratta delle risorse di computazione. Le ECPU si basano sul numero di memorie Centrali allocate in modo elastico da un pool di server di computazione e storage. È necessario disporre di almeno 2 ECPU per eseguire il provisioning di un Autonomous AI Database.

  Durante il provisioning di un nuovo database, la duplicazione di un database esistente e lo scale-up o lo scale-down delle risorse CPU di un database esistente, per impostazione predefinita il conteggio delle CPU è pari a 2 ECPU, con incrementi di 1. Ad esempio, il successivo numero disponibile di ECPU sopra 2 è 3.

  Puoi creare istanze di Autonomous AI Database for Developers su container database basati su ECPU. Sono database AI autonomi gratuiti che gli sviluppatori possono utilizzare per creare e testare nuove applicazioni. Per ulteriori dettagli, consulta l'Autonomous AI Database for Developers.

• OCPU: una OCPU è una misura fisica delle risorse di computazione. Le OCPU si basano sulla memoria centrale fisica di un processore con hyperthreading abilitato.

  Nota: la OCPU è una metrica di fatturazione legacy ed è stata ritirata per Autonomous AI Database on Dedicated Exadata Infrastructure. Oracle consiglia di utilizzare le ECPU per tutte le implementazioni di Autonomous AI Database nuove ed esistenti. Per ulteriori informazioni, consultare il documento di supporto Oracle 2998755.1.

  Durante il provisioning di un nuovo database, la duplicazione di un database esistente e lo scale-up o lo scale-down delle risorse CPU di un database esistente:

  • Per impostazione predefinita, il conteggio delle CPU è pari a 1 OCPU, con incrementi di 1. Ad esempio, il successivo numero disponibile di OCPU sopra 1 è 2.

  • Per i database che non richiedono un'intera OCPU, puoi assegnare le OCPU da 0,1 a 0,9 con incrementi di 0,1 OCPU. Ciò consente di eseguire il provisioning eccessivo della CPU ed eseguire più database su ogni istanza dell'infrastruttura. Per ulteriori dettagli, vedere Overprovisioning CPU.

Il tipo di computazione del cluster VM Autonomous Exadata si applica a tutte le istanze Autonomous Container Database e Autonomous AI Database.

Gestione computazione

Le istanze di Autonomous AI Database vengono distribuite in un cluster VM Autonomous Exadata (AVMC) e in uno degli Autonomous Container Database (ACD) figlio. Le infrastrutture Exadata sono in grado di eseguire più AVMC. Le CPU allocate durante il provisioning di una risorsa AVMC saranno le totali CPU disponibili per i relativi database AI autonomi. Quando si creano più AVMC, ogni AVMC può avere il proprio valore per il totale delle CPU.

Più cluster VM Autonomous Exadata non è disponibile in alcuna distribuzione Oracle Public Cloud di risorse EI (Exadata Infrastructure) create prima dell'avvio della funzione Autonomous AI Database con più VM. Per le risorse dell'infrastruttura Exadata di generazione X8M e successive create dopo l'avvio della funzione AVMC multipla, ogni AVMC viene creato con un nodo cluster per ciascuno dei server della forma del sistema Exadata scelta. Per informazioni sulla limitazione di queste CPU totali tra gruppi diversi di utenti, vedere In che modo le quote compartimento influiscono sulla gestione della CPU.

Nota: il numero massimo di risorse AVMC e ACD che è possibile creare su una determinata infrastruttura Exadata varia in base alla generazione di hardware. Per i dettagli sui vincoli per ogni generazione, fai riferimento ai limiti delle risorse e alle caratteristiche delle forme dell'infrastruttura.

A livello AVMC o ACD, il numero totale di CPU disponibili per la creazione dei database è denominato CPU disponibili. A livello di risorsa AVMC, le CPU disponibili saranno uguali al totale delle CPU fino a quando non si crea il primo ACD. Dopo aver creato un ACD, 8 ECPU o 2 OCPU per nodo vengono allocate al nuovo ACD dalle CPU disponibili di AVMC. Pertanto, le CPU disponibili a livello di risorsa AVMC si riducono di conseguenza. Quando crei il primo Autonomous AI Database in tale ACD, il nuovo database utilizza le CPU inizialmente allocate (8 ECPU o 2 OCPU per nodo). Se il nuovo database richiede più di 8 ECPU o 2 OCPU, viene assegnato dalle CPU disponibili dell'AVMC padre, riducendo le CPU disponibili a livello di AVMC padre. Quando crei più ACD ed esegui il provisioning dei database AI autonomi all'interno di ogni ACD, il valore della CPU disponibile cambia di conseguenza.

Le CPU disponibili a livello di cluster VM Autonomous Exadata si applicano a tutti i relativi Autonomous Container Database. Questo conteggio delle CPU disponibili per il container database diventa importante se si utilizza la funzione di scala automatica, come descritto in Allocazione CPU durante la scala automatica.

Analogamente, quando si esegue manualmente lo scale up delle CPU di un Autonomous AI Database, le CPU vengono consumate dalle CPU disponibili a livello di AVMC padre e il relativo valore cambia di conseguenza.

Quando crei un Autonomous AI Database, per impostazione predefinita Oracle riserva CPU aggiuntive per garantire che il database possa essere eseguito con almeno il 50% di capacità anche in caso di errori dei nodi. Durante il provisioning di un ACD, puoi modificare la percentuale di CPU riservate tra i nodi allo 0% o al 25%. Per istruzioni, vedere Prenotazione del failover del nodo in Creare un Autonomous Container Database. Queste CPU aggiuntive non sono incluse nella fatturazione.

Quando un Autonomous AI Database è in esecuzione, ti verrà fatturato il numero di CPU attualmente allocate al database, specificate durante la creazione iniziale o in seguito da un'operazione di ridimensionamento manuale. Inoltre, se il ridimensionamento automatico è abilitato per il database, viene fatturato ogni secondo per eventuali CPU aggiuntive utilizzate dal database come risultato del ridimensionamento automatico. Per ulteriori informazioni su come viene misurata e calcolata la fatturazione, vedere Dettagli fatturazione CPU.

Quando un Autonomous AI Database viene arrestato, non viene fatturato alcun importo. Tuttavia, il numero di CPU ad esso allocate non viene restituito alle CPU disponibili al livello AVMC padre per la distribuzione complessiva.

Quando un Autonomous AI Database viene arrestato o ridimensionato, il numero di CPU ad esso allocate non viene immediatamente restituito alle CPU disponibili a livello AVMC padre per la distribuzione complessiva. Continuano a essere incluse nel conteggio delle CPU disponibili per il container database padre fino al riavvio del container database padre. Queste CPU sono denominate CPU recuperabili. Le CPU recuperabili a livello di AVMC padre sono la somma delle CPU recuperabili di tutti i relativi ACD. Quando un ACD viene riavviato, restituisce tutte le relative CPU recuperabili alle CPU disponibili a livello di AVMC padre.

Il riavvio di un Autonomous Container Database (ACD) è un'operazione in linea, eseguita in sequenza nel cluster e non comporterà tempi di inattività delle applicazioni se configurata in base alle procedure ottimali per utilizzare la continuità di applicazione trasparente.

Suggerimento: è possibile tenere traccia dei diversi attributi di computazione (CPU) descritti in questo articolo dalla pagina Dettagli di un cluster VM Autonomous Exadata (AVMC) o di Autonomous Container Database (ACD). Per istruzioni, vedere Registrazione uso risorse.

Allocazione CPU durante ridimensionamento automatico

La funzione di scala automatica consente a un Autonomous AI Database di utilizzare fino a tre volte più risorse CPU e I/O rispetto al conteggio di CPU allocato. In caso di overprovisioning della CPU, se tre volte il conteggio della CPU risulta in un valore inferiore a 1, verrà arrotondato al numero intero successivo. L'overprovisioning della CPU è supportato solo con OCPU. Per ulteriori dettagli, vedere Overprovisioning CPU.

Per garantire che nessun singolo Autonomous AI Database possa eseguire la scala automatica fino al consumo di tutte le CPU disponibili nel pool per la distribuzione complessiva, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata utilizza Autonomous Container Database come controllo limitante.

Durante il provisioning di un Autonomous AI Database abilitato per il ridimensionamento automatico in un ACD, se le CPU disponibili in tale ACD sono inferiori al valore CPU 3 volte del nuovo database, in tale ACD verranno riservate ulteriori CPU. Queste CPU sono denominate CPU riservate. Le CPU riservate garantiscono che le CPU disponibili a livello di ACD siano sempre maggiori o uguali al valore 3x della CPU del database abilitato per il ridimensionamento automatico più grande in tale ACD. Queste CPU riservate possono comunque essere utilizzate per creare o ridimensionare manualmente i database AI autonomi in questo ACD.

Quando si esegue lo scale-up automatico di un Autonomous AI Database, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata cerca CPU inattive nel container database padre. Se sono disponibili CPU inattive, viene eseguito lo scale up di Autonomous AI Database. In caso contrario, non lo è. I database hanno intrinsecamente molto tempo di inattività, quindi il ridimensionamento automatico è un modo per massimizzare l'uso delle risorse, controllando al contempo i costi e preservando un buon isolamento dai database in altri Autonomous Container Database.

Se la CPU utilizzata per ridimensionare automaticamente un Autonomous AI Database proviene da un altro Autonomous AI Database in esecuzione che viene caricato leggermente e quindi non utilizza tutte le CPU allocate, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata ridimensiona automaticamente il database con scala automatica se il carico aumenta sull'altro database e richiede la riconversione della CPU allocata.

Prendi in considerazione l'esempio di un Autonomous Container Database che ospita quattro database AI autonomi a 4 CPU in esecuzione, il tutto con la scala automatica abilitata. Il conteggio delle CPU disponibili per il container database ai fini della scala automatica è 12. Se uno di questi database deve essere ridimensionato automaticamente oltre le 4 CPU a causa dell'aumento del carico, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata eseguirà l'operazione di ridimensionamento automatico solo se uno o più degli altri database vengono caricati leggermente e non utilizzano tutte le CPU allocate. Il costo di fatturazione di questo esempio è di 16 CPU al minimo perché tutti e quattro i database 4 CPU sono sempre in esecuzione.

Al contrario, prendi in considerazione l'esempio di un Autonomous Container Database che ospita quattro Autonomous AI Database con 2 CPU in esecuzione, il tutto con la scala automatica abilitata e un Autonomous AI Database con 8 CPU arrestate. Il conteggio delle CPU disponibili per il container database ai fini della scala automatica è di nuovo 16. Se uno dei database in esecuzione deve essere ridimensionato automaticamente a causa dell'aumento del carico delle oltre 2 CPU, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata può eseguire l'operazione utilizzando le CPU allocate al database 8-CPU arrestato. In questo esempio, i quattro database in esecuzione possono utilizzare fino a un totale di 8 CPU aggiuntive contemporaneamente senza consumare le CPU allocate l'una dell'altra. Il costo di fatturazione di questo esempio è di sole 8 CPU al minimo perché solo i quattro database da 2 CPU sono sempre in esecuzione.

Per qualsiasi istanza del servizio Autonomous Data Guard, locale o tra più aree, il prezzo aggiuntivo sarà il numero di ECPU o OCPU prenotate quando hai creato o ridimensionato in modo esplicito l'istanza del servizio primario, indipendentemente dal fatto che la scala automatica sia abilitata o meno. Il consumo di ECPU o OCPU correlato alla scala automatica nelle istanze del servizio primario non si verifica nelle istanze del servizio di standby Autonomous Data Guard.

In che modo le quote compartimento influiscono sulla gestione della CPU

In genere, quando crei o esegui lo scale up di un Autonomous AI Database, la capacità di Oracle Autonomous AI Database su un'infrastruttura Exadata dedicata di soddisfare la tua richiesta dipende solo dalla disponibilità di CPU non allocate nel singolo pool di CPU nell'intera distribuzione.

Tuttavia, puoi utilizzare la funzione di quote di compartimento di Oracle Cloud Infrastructure per limitare ulteriormente, in un compartimento per compartimento, il numero di CPU disponibili per creare, ridimensionare manualmente e ridimensionare automaticamente i database AI autonomi di ogni tipo di carico di lavoro (Autonomous AI Lakehouse o Autonomous AI Transaction Processing) singolarmente.

In breve, è possibile utilizzare la funzione Quote di compartimento creando istruzioni dei criteri set, unset e zero per limitare la disponibilità di una determinata risorsa in un determinato compartimento. Per informazioni e istruzioni dettagliate, vedere Quote di compartimento.

Modalità di impatto dei nodi del cluster VM sulla gestione della CPU

La discussione precedente relativa alla gestione e all'allocazione della CPU indica che è possibile creare più risorse del cluster VM Autonomous Exadata (AVMC) scegliendo il conteggio di CPU per nodo durante il provisioning della risorsa AVMC.

Questa sezione tratterà dettagli granulari su come Oracle Cloud Infrastructure posiziona i database AI autonomi nei nodi del cluster VM e sulle conseguenze di tale posizionamento sul ridimensionamento automatico e sull'elaborazione parallela.

I seguenti attributi determinano quando e in che modo un Autonomous AI Database viene posizionato su più nodi:

• Soglia di divisione: il valore della CPU oltre il quale Oracle Cloud Infrastructure apre un Autonomous AI Database su più nodi. La soglia di suddivisione predefinita è 64 per le ECPU e 16 per le OCPU, ma se i cluster VM vengono creati con i conteggi dei nodi CPU inferiori al valore predefinito, il valore predefinito viene sostituito dalla dimensione del conteggio dei nodi del cluster VM. È inoltre possibile impostare il valore di divisione in modo esplicito utilizzando l'attributo Soglia di divisione durante il provisioning di un Autonomous Container Database (ACD).

  I database AI autonomi creati con un valore CPU inferiore al valore di divisione verranno aperti su un nodo del cluster e quelli creati con un valore CPU maggiore del valore di soglia di divisione verranno aperti su più nodi.

  • Si supponga di creare un ACD con una soglia di suddivisione predefinita (64 ECPU) in un AVMC con due nodi e 40 ECPU per nodo. Poiché 40 è inferiore a 64, qualsiasi Autonomous AI Database con un requisito CPU maggiore di 40 verrà diviso e aperto su più nodi, consentendo richieste DML in tali nodi. Tuttavia, se l'AVMC è stato creato con due nodi e 80 ECPU per nodo, qualsiasi database con un requisito ECPU maggiore di 64 verrà diviso e aperto su più nodi.

  • Si supponga di creare un ACD in un cluster VM con due nodi e 40 ECPU per nodo e di impostare esplicitamente il valore della soglia di suddivisione su un valore molto più piccolo, ad esempio 20 ECPU. Qualsiasi Autonomous AI Database con un requisito CPU maggiore di 20 verrà diviso e aperto su più nodi e i database con un requisito CPU minore di 20 verranno aperti su un singolo nodo.

    L'impostazione della soglia di suddivisione su un numero molto più piccolo del valore predefinito aumenta le possibilità di apertura dei database con conteggi di CPU più piccoli su più nodi, a condizione che il conteggio di CPU sia superiore al valore di divisione impostato. Ogni volta che un database viene creato o ridimensionato a una dimensione maggiore di questo valore di divisione, viene aperto su più nodi. Ciò è utile quando si desidera che i database vengano aperti su più nodi per controllare il deterioramento delle prestazioni in caso di guasto di un nodo o manutenzione pianificata. Con i database suddivisi su più nodi in cluster RAC più grandi, se un nodo qualsiasi non riesce o quando si verifica la manutenzione pianificata, puoi continuare ad avere prestazioni più elevate anziché degradare a un profilo delle prestazioni del 50%.

  • Si supponga di impostare esplicitamente la soglia di suddivisione su un valore molto più alto del valore predefinito, ad esempio 80 ECPU, in un AVMC con due nodi e 40 ECPU. Qualsiasi Autonomous AI Database con un requisito CPU maggiore di 40 verrà diviso e aperto su più nodi e i database con un requisito CPU minore di 40 verranno aperti su un singolo nodo.

    L'impostazione della soglia di suddivisione su un valore molto superiore a quello predefinito fa sì che il DML del database rimanga su un singolo nodo RAC ed elimini la possibilità di conflitti di attesa del cluster.

  • Quando si ridimensiona manualmente un Autonomous AI Database, il nuovo valore della CPU verrà applicato al modello di suddivisione esistente. In altre parole, se il nuovo valore è inferiore alla soglia di frazionamento, verrà aperto su un nodo e se il valore è maggiore della soglia di frazionamento, verrà aperto su più nodi.

• Affinità di distribuzione: determina il numero di nodi su cui verrà aperto un Autonomous AI Database una volta superata la soglia di divisione.

  Si supponga, ad esempio, di aver creato una risorsa AVMC con 4 nodi e 80 ECPU per nodo e di aver creato un ACD in questo AVMC con Soglia di divisione del database impostata su 64. La creazione di un Autonomous AI Database con un requisito ECPU pari a 120 dividerà e aprirà il database su più nodi come 120 maggiore di 64 (Soglia di divisione).

  • Se l'affinità di distribuzione è impostata su Nodi minimi, Oracle Cloud Infrastructure tenta di creare il database su 2 nodi con 60 ECPU su ciascun nodo. Se ciò non è possibile, verrà diviso in 3 nodi con 40 ECPU ciascuno. Se anche questo non è possibile, Oracle Cloud Infrastructure cercherà di aprire il database su 4 nodi con 30 ECPU ciascuno.

  • Se specifichi l'affinità di distribuzione ai nodi massimi, Oracle Cloud Infrastructure tenta di creare il database diviso su tutti i 4 nodi con 30 ECPU ciascuno. Se ciò non fosse possibile, verrà suddivisa in tre nodi con 40 ECPU ciascuno. Se anche questo non è possibile, Oracle Cloud Infrastructure cercherà di aprire il database su 2 nodi con 60 ECPU ciascuno.

• Prenotazione failover nodo (%): il numero di CPU accantonate sui nodi adiacenti (nodi in cui il software del database è presente ma non aperto) nell'AVMC per eventi di errore e manutenzione localizzati. La riserva di failover del nodo si applica alle distribuzioni di database non di tipo Split. Per impostazione predefinita, esiste una riserva del 50%, ovvero durante un evento di errore o una manutenzione, l'esecuzione continuerà ma al 50% della CPU allocata.

  • Per database o database non critici con un utilizzo molto leggero, puoi impostare la prenotazione del failover del nodo su un valore inferiore in modo da poter creare e consolidare un numero maggiore di database sull'infrastruttura Exadata dedicata.

  • È possibile impostare questo valore su zero per l'ambiente di sviluppo e i database in cui è accettabile un periodo di inattività durante la manutenzione.

  • In una certa misura, la riserva di failover del nodo può anche essere controllata garantendo che un database venga suddiviso in più di 2 nodi, utilizzando la soglia di divisione e l'affinità di distribuzione. Prendi in considerazione uno scenario in cui un Autonomous AI Database viene suddiviso in 4 nodi. Rimuovendo un nodo alla volta in sequenza mentre è in corso un'attività di manutenzione, hai sempre 3 nodi ancora attivi e prendi traffico, mantenendo la tua riserva di prestazioni in modo efficace del 75%, piuttosto che del solito 50%. Con cluster più grandi, puoi aumentare ulteriormente questa riserva, ad esempio con una riserva dell'87,5% su un cluster a 8 nodi.

La modalità di distribuzione della CPU di un Autonomous AI Database tra i nodi del cluster VM influisce sulle operazioni riportate di seguito.

• Scala automatica:

  • Il ridimensionamento automatico può verificarsi all'interno di un singolo nodo cluster VM per DML non personalizzabile e tra i nodi del cluster VM se il DML è parallelizzabile.

  • Più sessioni simultanee con query non personalizzabili possono essere instradate a tutti i nodi del cluster, consentendo in modo efficace il ridimensionamento automatico su tutti i nodi in un database multi-nodo.

• Elaborazione parallela:

  • L'elaborazione parallela delle istruzioni SQL si verifica all'interno dei nodi del cluster VM Autonomous Exadata aperti, prima all'interno di un singolo nodo e quindi in nodi aperti adiacenti, che come descritto in precedenza dipenderanno dalle dimensioni del cluster VM Autonomous Exadata.

In base all'utilizzo delle risorse su ogni nodo; non tutti i valori delle CPU disponibili possono essere utilizzati per eseguire il provisioning o ridimensionare i database AI autonomi. Si supponga, ad esempio, di disporre di 20 CPU disponibili a livello AVMC, che non sia possibile utilizzare tutti i valori da 1 a 20 CPU per eseguire il provisioning o ridimensionare i database AI autonomi a seconda della disponibilità delle risorse a livello di nodo. La lista di valori CPU che possono essere utilizzati per eseguire il provisioning o ridimensionare un Autonomous AI Database è denominata CPU con provisioning eseguito.

Quando provi a eseguire il provisioning o a ridimensionare un Autonomous AI Database dalla console OCI, il campo CPU ti fornirà un elenco a discesa con la lista di CPU di cui è possibile eseguire il provisioning. In alternativa, è possibile utilizzare le seguenti API per ottenere la lista dei valori CPU provvisori:

• GetAutonomousContainerDatabase restituisce una lista di valori CPU di cui è possibile eseguire il provisioning che possono essere utilizzati per creare un nuovo Autonomous AI Database nell'Autonomous Container Database specificato. Per ulteriori dettagli, consulta la sezione GetAutonomousContainerDatabase.

• GetAutonomousDatabase restituisce una lista di valori CPU di cui è possibile eseguire il provisioning che possono essere utilizzati per il ridimensionamento di un determinato Autonomous AI Database. Per ulteriori dettagli, consulta GetAutonomousDatabase.

Contenuto correlato

• Fatturazione di Autonomous AI Database su un'infrastruttura Exadata dedicata