Requisiti in termini di risorse per la piattaforma di destinazione - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Requisiti in termini di risorse per la piattaforma di destinazione

Si consiglia di dimensionare l'ambiente del database di destinazione in AWS base all'utilizzo di Exadata di origine, non alla configurazione. Molti clienti acquistano sistemi Exadata con capacità aggiuntiva per far fronte alla crescita prevista per i prossimi tre-cinque anni. In genere, quando si esegue la migrazione dei carichi di lavoro Exadata AWS, vengono distribuite meno risorse rispetto alla configurazione del sistema Exadata di origine, quindi è fuorviante utilizzare quella configurazione originale per prevedere le risorse AWS.

Per stimare le risorse richieste nell'istanza di destinazione, puoi utilizzare gli strumenti descritti nella sezione precedente, come AWR, database views, OEM e CellCLI. Inoltre AWS, è possibile aumentare o ridurre le risorse più facilmente rispetto alla piattaforma Exadata di origine. Le sezioni seguenti illustrano le migliori pratiche per la stima di risorse come CPU, memoria e IOPS per la piattaforma di destinazione. Inoltre, i team di account AWS e gli specialisti di database che hanno una vasta esperienza nell'assistenza ai clienti nelle loro migrazioni Exadata possono aiutarti a dimensionare il tuo ambiente di destinazione. AWS dispone di strumenti interni che il team dell'account AWS può utilizzare per stimare le risorse richieste e dimensionare correttamente l'ambiente di destinazione su AWS.

Requisiti di CPU e memoria

Quando migri i tuoi carichi di lavoro Exadata verso un'opzione di distribuzione del database Oracle attiva AWS, come Amazon RDS for Oracle, non dovresti basare le risorse del livello di calcolo (CPU e memoria) solo sulle statistiche di utilizzo dei server di database Exadata. Il carico di lavoro beneficia anche di funzionalità specifiche di Exadata come Smart Scan e gli indici di archiviazione, che trasferiscono l'elaborazione alle celle di storage e utilizzano le risorse dei server di storage. Pertanto, è necessario fornire al livello di elaborazione dell'istanza di destinazione risorse di CPU e memoria aggiuntive in base all'utilizzo delle funzionalità specifiche di Exadata e al grado di ottimizzazione del carico di lavoro che potrebbe essere possibile durante la migrazione.

È difficile stimare con precisione le risorse CPU aggiuntive richieste. Utilizzate i risultati della scoperta come punto di partenza per il dimensionamento dell'ambiente di destinazione. Per un calcolo approssimativo, prendi in considerazione l'inclusione di una vCPU aggiuntiva per ogni 500 MBps di carichi di lavoro Smart Scan nel totale delle vCPU richieste per il livello di elaborazione.

Un altro approccio consiste nel considerare l'utilizzo della CPU sui server di storage. Come punto di partenza, è possibile aggiungere circa il 20 percento del totale delle CPU utilizzate sui server di storage alle vCPU totali richieste per il livello di elaborazione. È possibile regolare questa percentuale in base all'utilizzo delle funzionalità di Exadata, come determinato da strumenti come AWR e CellCLI. Ad esempio, per un utilizzo ridotto, è possibile aggiungere il 10 percento per un utilizzo basso, il 20 percento per un utilizzo medio e il 40 percento per un utilizzo elevato. Se utilizzi un numero totale di 20 thread CPU su tutti i server di storage e l'utilizzo delle funzionalità Exadata viene considerato medio, potresti prendere in considerazione 4 vCPU aggiuntive per compensare le funzionalità Exadata mancanti nell'ambiente di destinazione.

Dopo queste stime iniziali, è necessario condurre anche dei test delle prestazioni sull'ambiente di destinazione per determinare se è necessario scalare le risorse allocate. I test delle prestazioni potrebbero inoltre rivelare ulteriori opportunità di ottimizzazione del carico di lavoro in grado di ridurre le risorse richieste.

Potrebbe essere necessario aumentare l'allocazione di memoria all'istanza Oracle per migliorare il rapporto di accesso alla cache e ridurre l'ingombro di I/O. La piattaforma Exadata di origine potrebbe non disporre di memoria sufficiente per allocazioni SGA di grandi dimensioni, specialmente in uno scenario consolidato. Ciò potrebbe non causare problemi di prestazioni in Exadata, poiché le operazioni di I/O sono generalmente veloci. Ti consigliamo di iniziare con un'istanza che supporti la seguente allocazione di memoria:

Target memory required = larger of (8 GB per vCPUs required, two times the SGA+PGA allocation in the source) SGA+PGA allocation = ~80% of available memory on the instance

Durante i test delle prestazioni, puoi utilizzare le funzionalità di Oracle come buffer pool advisory, SGA Target Advisory e PGA Memory Advisory per ottimizzare l'allocazione SGA e PGA per soddisfare i requisiti del carico di lavoro.

L'istanza Amazon EC2 o Amazon RDS deve disporre di risorse di CPU, memoria e I/O adeguate per gestire il carico di lavoro del database previsto. Ti consigliamo di utilizzare una classe di istanza dell'attuale generazione su cui ospitare il tuo carico di lavoro. AWS I tipi di istanze della generazione attuale, ad esempio le istanze basate sul sistema Nitro, supportano macchine virtuali hardware (HVM). Per sfruttare i vantaggi di una rete avanzata e di una maggiore sicurezza, puoi utilizzare Amazon Machine Images (AMI) per HVM. Amazon RDS for Oracle attualmente supporta fino a 128 vCPU e 3.904 GB di memoria. Consulta le classi di istanze DB nella documentazione di Amazon RDS per informazioni sulle specifiche hardware delle classi di istanze disponibili per Amazon RDS for Oracle Consulta i tipi di istanze Amazon EC2 per un elenco di istanze EC2 con dettagli sulle risorse.

Requisiti di I/O

L'utilizzo dei report AWR per stimare i requisiti di risorse richiede familiarità con i modelli di carico di lavoro per i tempi di carico di picco, non di punta e medi. Per stimare i requisiti IOPS per il carico di lavoro sulla base di un rapporto AWR raccolto durante i periodi di punta, procedi nel seguente modo:

  1. Esamina il rapporto AWR per identificare le richieste I/O di lettura fisica, le richieste I/O di scrittura fisica, i byte totali di lettura fisica e i byte totali di scrittura fisica.

    Questi parametri tengono conto dei vantaggi delle funzionalità specifiche di Exadata, come gli indici di storage, in modo da indicare i valori di IOPS e di throughput effettivi che è possibile utilizzare per dimensionare il livello di I/O di storage dell'ambiente AWS di destinazione.

  2. Nella sezione del profilo I/O del rapporto AWR, esamina i valori ottimizzati delle richieste di lettura fisiche e delle richieste di scrittura fisiche per determinare se Smart Scan e altre funzionalità di Exadata relative all'I/O, come l'I/O salvato dagli indici di archiviazione, la cache colonnare o la cache Smart Flash, vengono utilizzate. Se vedi richieste ottimizzate nel profilo I/O AWR, esamina le statistiche di sistema per ottenere i dettagli di Smart Scan e delle metriche dell'indice di archiviazione, come i byte di I/O fisici delle celle idonei per l'offload dei predicati, i byte di interconnessione I/O fisici delle celle restituiti da Smart Scan e i byte di I/O fisici delle celle salvati dall'indice di archiviazione.

    Sebbene queste metriche non vengano utilizzate direttamente per dimensionare l'ambiente di destinazione, sono utili per comprendere quanto I/O viene risparmiato dalle funzionalità e dalle tecniche di ottimizzazione specifiche di Exadata per ottimizzare il carico di lavoro.

    Total IOPS required for the workload = physical read IO requests + physical write IO requests Total throughput = physical read bytes + physical write bytes

Le statistiche AWR: le richieste I/O di lettura fisica, le richieste I/O di scrittura fisica, i byte di lettura fisici e i byte di scrittura fisici riflettono le attività di I/O del carico di lavoro, escluso l'I/O fornito da componenti non applicativi come il backup RMAN e altre utilità come expdp o sqlldr. In questi casi, puoi prendere in considerazione le statistiche AWR, le richieste I/O totali di lettura fisica, le richieste I/O totali in scrittura fisica, i byte totali di lettura fisica e i byte totali di scrittura fisica per stimare i requisiti di IOP e di throughput.

I database eseguiti su Exadata in genere producono centinaia di migliaia di IOPS e un throughput molto elevato (oltre 50 Gbps) a causa dei fattori discussi nelle sezioni precedenti. Tuttavia, nella maggior parte dei casi, le tecniche di tuning e l'ottimizzazione del carico di lavoro riducono drasticamente l'ingombro I/O del carico di lavoro.

Se i requisiti di I/O sono molto elevati, tieni presente le limitazioni di Amazon EC2 e Amazon RDS. Per un throughput di volume Amazon EBS elevato, prendi in considerazione l'utilizzo di classi di istanze Amazon EC2 come x2iedn, x2idn e r5b, che supportano fino a 260.000 IOPS con un throughput di 10.000 MBps. Consulta le istanze ottimizzate per Amazon EBS nella documentazione di Amazon EC2 per esaminare gli IOPS e il throughput massimi supportati dalle varie istanze. Per Amazon RDS for Oracle, la classe di istanze rb5 supporta fino a 256.000 IOPS con un throughput di 4.000 MBps. Consulta le classi di istanze DB per esaminare le istanze ottimizzate per Amazon EBS disponibili per Amazon RDS for Oracle.

È inoltre necessario comprendere come vengono misurati gli IOPS e il throughput nel caso di diversi volumi EBS disponibili per l'ambiente di destinazione. In alcuni casi, Amazon EBS divide o unisce le operazioni di I/O per massimizzare il throughput. Per ulteriori informazioni, consulta le caratteristiche di I/O e il monitoraggio nella documentazione di Amazon EC2 e Come posso ottimizzare le prestazioni dei miei volumi IOPS di Amazon EBS Provisioned? nel Knowledge Center. AWS