View a markdown version of this page

Considerazioni sull’utilizzo dei cluster con provisioning Amazon Redshift - Amazon Redshift
Considerazioni su regioni e zone di disponibilitàManutenzione del cluster

Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dalla Patch 198. Le UDF Python esistenti continueranno a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il post del blog.

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à.

Considerazioni sull’utilizzo dei cluster con provisioning Amazon Redshift

Dopo avere creato il cluster, in questa sezione puoi trovare informazioni sulle Regioni in cui sono disponibili funzionalità, attività di manutenzione, tipi di nodi e limiti di utilizzo.

Considerazioni su regioni e zone di disponibilità

Amazon Redshift è disponibile in diverse AWS regioni. Per impostazione predefinita, Amazon Redshift effettua il provisioning del cluster in una zona di disponibilità (AZ) selezionata casualmente all'interno della AWS regione scelta. Viene effettuato il provisioning di tutti i nodi del cluster nella stessa zona di disponibilità.

Facoltativamente, è possibile richiedere una zona di disponibilità specifica se Amazon Redshift è disponibile in tale zona. Ad esempio, se si dispone già di un'istanza Amazon EC2 in esecuzione in una zona di disponibilità, potrebbe essere necessario creare il proprio cluster Amazon Redshift nella stessa zona per ridurre la latenza. D'altra parte, potrebbe essere necessario scegliere un'altra zona di disponibilità con una maggiore disponibilità. Amazon Redshift potrebbe non essere disponibile in tutte le zone di disponibilità all'interno di una AWS regione.

Per un elenco delle AWS regioni supportate in cui è possibile effettuare il provisioning di un cluster Amazon Redshift, consulta gli endpoint Amazon Redshift nel. Riferimenti generali di Amazon Web Services

Manutenzione del cluster

Amazon Redshift esegue periodicamente la manutenzione per applicare aggiornamenti al cluster. Durante questi aggiornamenti, il cluster Amazon Redshift non è disponibile per le operazioni normali. Esistono diversi modi per controllare come poter effettuare la manutenzione del cluster. Ad esempio, puoi controllare come distribuire gli aggiornamenti sui cluster. Puoi anche scegliere se il cluster esegue sempre la versione di rilascio più recente o quella precedente alla più recente. Infine, puoi anche decidere di posticipare gli aggiornamenti di manutenzione non obbligatori.

Finestre di manutenzione

Amazon Redshift assegna una finestra di manutenzione di 30 minuti a caso su un periodo di 8 ore per AWS regione, in un giorno casuale della settimana (dal lunedì alla domenica, inclusi).

Finestre di manutenzione predefinite

L'elenco seguente mostra i blocchi temporali per ciascuna AWS regione a partire dai quali vengono assegnate le finestre di manutenzione predefinite:

  • Regione Stati Uniti orientali (Virginia settentrionale): 03:00-11:00 UTC

  • Regione Stati Uniti orientali (Ohio): 03:00 - 11:00 UTC

  • Regione Stati Uniti occidentali (California settentrionale): 06:00-14:00 UTC

  • Regione Stati Uniti occidentali (Oregon): 06:00 - 14:00 UTC

  • Regione Africa (Città del Capo): 20:00 - 04:00 UTC

  • Regione Asia Pacifico (Hong Kong): 13:00 - 21:00 UTC

  • Regione Asia Pacifico (Hyderabad): 16:30-00:30 UTC

  • Regione Asia Pacifico (Jakarta): 15:00 – 23:00 UTC

  • Regione Asia Pacifico (Malesia): 14:00 - 22:00 UTC

  • Regione Asia Pacifico (Melbourne): 12:00 - 20:00 UTC

  • Regione Asia Pacifico (Mumbai): 16:30 - 00:30 UTC

  • Regione Asia Pacifico (Nuova Zelanda): 10:00 - 18:00 UTC

  • Regione Asia Pacifico (Tokyo): 13:00 – 21:00 UTC

  • Regione Asia Pacifico (Seoul): 13:00 – 21:00 UTC

  • Regione Asia Pacifico (Singapore): 14:00-22:00 UTC

  • Regione Asia Pacifico (Sydney): 12:00 - 20:00 UTC

  • Regione Asia Pacifico (Taipei): 14:00 - 22:00 UTC

  • Regione Asia Pacifico (Thailandia): 15:00 - 23:00 UTC

  • Regione Asia Pacifico (Tokyo): 13:00-21:00 UTC

  • Regione Canada (Centrale): 03:00 - 11:00 UTC

  • Regione Canada occidentale (Calgary): 04:00 - 12:00 UTC

  • Regione Cina (Pechino): 13:00 - 21:00 UTC

  • Regione Cina (Ningxia): 13:00 - 21:00 UTC

  • Regione Europa (Francoforte): 06:00 - 14:00 UTC

  • Regione Europa (Irlanda): 22:00-06:00 UTC

  • Regione Europa (Londra): 22:00 - 06:00 UTC

  • Regione Europa (Milano): 21:00 - 05:00 UTC

  • Regione Europa (Parigi): 23:00 - 07:00 UTC

  • Regione Europa (Stoccolma): 23:00 - 07:00 UTC

  • Regione Europa (Zurigo): 22:00-04:00 UTC

  • Regione di Israele (Tel Aviv): 20:00 — 04:00 UTC

  • Regione Messico (Centrale): 04:00 - 12:00 UTC

  • Regione Europa (Spagna): 21:00-05:00 UTC

  • Regione Medio Oriente (Bahrein): 13:00 - 21:00 UTC

  • Regione Medio Oriente (EAU): 18:00–02:00 UTC

  • Regione Sud America (San Paolo): 19:00 - 03:00 UTC

Se in una determinata settimana è pianificato un evento di manutenzione, tale evento viene avviato durante la finestra di manutenzione di 30 minuti assegnata. Mentre Amazon Redshift esegue la manutenzione, verranno terminate le query e tutte le altre operazioni in corso. I tempi di inattività subiti durante la manutenzione pianificata non sono considerati tempi di inattività mensili o indisponibilità nell'ambito del Service Level Agreement di Amazon Redshift. La maggior parte del processo di manutenzione viene completato durante la finestra di manutenzione di 30 minuti, ma l'esecuzione di alcune attività di manutenzione potrebbe continuare anche dopo la chiusura della finestra. Se non sono previste attività di manutenzione da eseguire durante una finestra di manutenzione pianificata, il cluster continuerà a funzionare normalmente fino alla successiva finestra di manutenzione pianificata.

È possibile cambiare la finestra di manutenzione programmata modificando il cluster a livello di codice o utilizzando la console Amazon Redshift. Puoi trovare la finestra di manutenzione e impostare il giorno e l’ora in cui si verifica per il cluster nella scheda Manutenzione.

È possibile riavviare un cluster al di fuori di una finestra di manutenzione. Questo può avvenire per alcuni motivi. Un motivo più comune è che è stato rilevato un problema nel cluster e sono in corso operazioni di manutenzione per riportarlo a uno stato integro. Per ulteriori informazioni consulta l'articolo Why did my Amazon Redshift cluster reboot outside of the maintenance window?, che fornisce dettagli sul motivo per cui ciò potrebbe verificarsi.

Posticipazione della manutenzione

Per riprogrammare la finestra di manutenzione del cluster, puoi posticipare la manutenzione fino a 60 giorni. Ad esempio, se la finestra di manutenzione del cluster è impostata a mercoledì 8:30 - 9:00 UTC ed è necessario accedere al cluster in quel periodo, puoi posticipare la manutenzione impostandola a un periodo successivo.

Se rinvii la manutenzione, Amazon Redshift continuerà ad applicare aggiornamenti hardware o altri aggiornamenti di sicurezza obbligatori al cluster. Durante questi aggiornamenti il cluster non è disponibile.

Se durante la prossima finestra di manutenzione è pianificato un aggiornamento hardware o un altro aggiornamento di sicurezza obbligatorio, Amazon Redshift ti invia notifiche anticipate nella categoria In sospeso. Per ulteriori informazioni sulle notifiche di eventi In sospeso, consulta Notifiche di eventi del cluster con provisioning Amazon Redshift.

Puoi anche scegliere di ricevere notifiche tramite SMS da Amazon Simple Notification Service (Amazon SNS). Per ulteriori informazioni sulla sottoscrizione alle notifiche eventi di Amazon SNS, consulta Abbonamenti alle notifiche di eventi del cluster Amazon Redshift.

Se posticipi la manutenzione del cluster, la finestra di manutenzione successiva al periodo di posticipazione non può essere posticipata.

Nota

Non è possibile posticipare la manutenzione dopo che è iniziata.

Per ulteriori informazioni sulla manutenzione dei cluster, consulta la documentazione seguente:

Selezione delle tracce di manutenzione del cluster

Quando è disponibile una nuova versione del cluster Amazon Redshift, il cluster viene aggiornato durante la relativa finestra di manutenzione. Puoi controllare se il cluster è aggiornato alla versione più recente o alla versione precedente.

La traccia controlla quale versione del cluster viene applicata durante una finestra di manutenzione. Quando Amazon Redshift rilascia una nuova versione del cluster, quella versione viene assegnata alla traccia corrente e la versione precedente viene assegnata alla traccia finale.

Per ulteriori informazioni sulle tracce del cluster, consulta Tracce per cluster con provisioning e gruppi di lavoro serverless Amazon Redshift.

Comprendere come i nodi RG e RA3 separano elaborazione e storage

Queste sezioni descrivono in dettaglio le attività disponibili per i tipi di nodi RG e RA3, mostrandone l'applicabilità a una raccolta di casi d'uso e descrivendone in dettaglio i vantaggi rispetto ai tipi di nodi precedentemente disponibili.

Vantaggi e disponibilità dei nodi RG e RA3

I nodi RG e RA3 offrono i seguenti vantaggi:

  • Sono flessibili per aumentare la capacità di elaborazione senza aumentare i costi di storage. Ridimensionano lo storage senza un eccessivo provisioning della capacità di elaborazione.

  • Utilizzano SSD ad alte prestazioni per i dati hot e Amazon S3 per i dati cold. Pertanto offrono facilità d'uso, storage conveniente ed elevate prestazioni di query.

  • Utilizzano reti ad alta larghezza di banda basate sul sistema AWS Nitro per ridurre ulteriormente il tempo necessario per scaricare e recuperare i dati da Amazon S3.

Prendi in considerazione la possibilità di scegliere i tipi di nodi RG e RA3 in questi casi:

  • Hai bisogno di flessibilità per scalare e pagare il calcolo separatamente dallo storage.

  • Esegui query su una frazione dei dati totali.

  • Il volume di dati cresce rapidamente o prevedi cresca rapidamente.

  • Desideri la flessibilità per dimensionare il cluster solo in base alle esigenze di prestazioni.

Considerazioni sull'elaborazione delle query sui data lake: sui cluster con provisioning DC2 e RA3, le query sui data lake vengono eseguite su Redshift Spectrum, che utilizza server Amazon Redshift dedicati indipendenti dal cluster. Nei cluster con provisioning RG, le query sui data lake vengono eseguite sulle risorse di elaborazione proprie del cluster e condividono tali risorse con altri carichi di lavoro. Per i carichi di lavoro con un uso intensivo delle query sul data lake, tenete conto di questo aspetto quando dimensionate il cluster RG.

Per utilizzare i tipi di nodi RG, la tua AWS regione deve supportare RG. Per ulteriori informazioni, consulta Disponibilità del tipo di nodo RG in AWS Regioni.

Per utilizzare i tipi di nodi RA3, la AWS regione deve supportare RA3. Per ulteriori informazioni, consulta Disponibilità del tipo di nodo RA3 in AWS Regioni.

Importante

È possibile utilizzare i tipi di nodo ra3.xlplus solo con la versione del cluster 1.0.21262 o successiva. È possibile visualizzare la versione di un cluster esistente con la console Amazon Redshift. Per ulteriori informazioni, consulta Determinazione della versione del gruppo di lavoro o del cluster.

Assicurati di utilizzare la nuova console Amazon Redshift quando lavori con tipi di nodi RG o RA3.

Inoltre, per utilizzare i tipi di nodi RG o RA3 con operazioni Amazon Redshift che utilizzano la traccia, il valore della traccia di manutenzione deve essere impostato su una versione del cluster che supporti RG o RA3. Per ulteriori informazioni sulle tracce, consulta Selezione delle tracce di manutenzione del cluster.

Considerare quanto segue quando si utilizzano tipi di nodi RA3 a nodo singolo.

  • I produttori e i consumatori di datasharing sono supportati.

  • Per modificare i tipi di nodi, è supportato solo il ridimensionamento classico. La modifica del tipo di nodo con il ridimensionamento elastico o il ripristino dello snapshot non è supportata. Sono supportati gli scenari seguenti:

    • Ridimensionamento classico di un dc2.xlarge a 1 nodo a un ra3.xlplus a 1 nodo e viceversa.

    • Ridimensionamento classico di un dc2.xlarge a 1 nodo su un ra3.xlplus a nodo multiplo e viceversa.

    • Ridimensionamento classico di un dc2.xlarge a più nodi ra3.xlplus a 1 nodo e viceversa.

Utilizzo dello spazio di archiviazione gestito di Amazon Redshift

Con l'archiviazione gestita di Amazon Redshift, è possibile archiviare ed elaborare tutti i dati in Amazon Redshift ottenendo una maggiore flessibilità per scalare separatamente la capacità di calcolo e quella di archiviazione. I dati continuano a essere inseriti con il comando COPY o INSERT. Per ottimizzare le prestazioni e gestire il posizionamento dei dati automatico nei vari livelli di storage, Amazon Redshift si avvale di ottimizzazioni quali temperatura di blocco dei dati, età di blocco dei dati e modelli di carichi di lavoro. Quando necessario, Amazon Redshift dimensiona automaticamente l'archiviazione in Amazon S3 senza richiedere alcuna azione manuale.

Per ulteriori informazioni sui costi di archiviazione, consultare Prezzi di Amazon Redshift.

Gestione dei tipi di nodi RG o RA3

Per trarre vantaggio dalla separazione dell'elaborazione dallo storage, puoi creare o aggiornare il cluster con il tipo di nodo RG o RA3. Per utilizzare i tipi di nodi RG o RA3, crea i cluster in un cloud privato virtuale (). EC2-VPC

Per modificare il numero di nodi del cluster Amazon Redshift con un tipo di nodo RG o RA3, esegui una delle seguenti operazioni:

  • Aggiungere o rimuovere nodi con l'operazione di ridimensionamento elastico. In alcune situazioni, la rimozione di nodi da un cluster RG o RA3 non è consentita con il ridimensionamento elastico. Ad esempio, quando un aggiornamento del numero di nodi 2:1 imposta il numero di sezioni per nodo su 32. Per ulteriori informazioni, consulta Ridimensionamento di un cluster. Se il ridimensionamento elastico non è disponibile, utilizzare il ridimensionamento classico.

  • Aggiungere o rimuovere nodi con l'operazione di ridimensionamento classico. Scegliere questa opzione quando si sta ridimensionando una configurazione che non è disponibile tramite il ridimensionamento elastico. Il ridimensionamento elastico è più veloce del ridimensionamento classico. Per ulteriori informazioni, consulta Ridimensionamento di un cluster.

Disponibilità del tipo di nodo RG in AWS Regioni

I tipi di nodi RG sono disponibili solo nelle seguenti regioni: AWS

  • Regione Stati Uniti orientali (Virginia settentrionale) (us-east-1)

  • Regione Stati Uniti orientali (Ohio) (us-east-2)

  • Regione Stati Uniti occidentali (California settentrionale) (us-west-1)

  • Regione Stati Uniti occidentali (Oregon) (us-west-2)

  • Regione Asia Pacifico (Hong Kong) (ap-east-1)

  • Regione Asia Pacifico (Taipei) (ap-east-2)

  • Regione Asia Pacifico (Tokyo) (ap-northeast-1)

  • Regione Asia Pacifico (Seoul) (ap-northeast-2)

  • Regione Asia Pacifico (Osaka) (ap-northeast-3)

  • Regione Asia Pacifico (Mumbai) (ap-south-1)

  • Regione Asia Pacifico (Hyderabad) (ap-south-2)

  • Regione Asia Pacifico (Singapore) (ap-southeast-1)

  • Regione Asia Pacifico (Sydney) (ap-southeast-2)

  • Regione Asia Pacifico (Jakarta) (ap-southeast-3)

  • Regione Asia Pacifico (Melbourne) (ap-southeast-4)

  • Regione Asia Pacifico (Malesia) (ap-southeast-5)

  • Regione Canada (Centrale) (ca-central-1)

  • Regione Europa (Francoforte) (eu-central-1)

  • Regione Europa (Stoccolma) (eu-north-1)

  • Regione Europa (Milano) (eu-south-1)

  • Regione Europa (Spagna) (eu-south-2)

  • Regione Europa (Irlanda) (eu-west-1)

  • Regione Europa (Londra) (eu-west-2)

  • Regione Europa (Parigi) (eu-west-3)

  • Regione Sud America (San Paolo) (sa-east-1)

Disponibilità del tipo di nodo RA3 in AWS Regioni

I tipi di nodi RA3 sono disponibili solo nelle seguenti regioni: AWS

  • Regione Stati Uniti orientali (Virginia settentrionale) (us-east-1)

  • Regione Stati Uniti orientali (Ohio) (us-east-2)

  • Regione Stati Uniti occidentali (California settentrionale) (us-west-1)

  • Regione Stati Uniti occidentali (Oregon) (us-west-2)

  • Regione Africa (Città del Capo) (af-south-1)

  • Regione Asia Pacifico (Hong Kong) (ap-east-1)

  • Regione Asia Pacifico (Hyderabad) (ap-south-2)

  • Regione Asia Pacifico (Jakarta) (ap-southeast-3)

  • Regione Asia Pacifico (Malesia) (ap-southeast-5)

  • Regione Asia Pacifico (Melbourne) (ap-southeast-4)

  • Regione Asia Pacifico (Mumbai) (ap-south-1)

  • Regione Asia Pacifico (Nuova Zelanda) (ap-southeast-6)

  • Regione Asia Pacifico (Osaka) (ap-northeast-3)

  • Regione Asia Pacifico (Seoul) (ap-northeast-2)

  • Regione Asia Pacifico (Singapore) (ap-southeast-1)

  • Regione Asia Pacifico (Sydney) (ap-southeast-2)

  • Regione Asia Pacifico (Taipei) (ap-east-2)

  • Regione Asia Pacifico (Thailandia) (ap-southeast-7)

  • Regione Asia Pacifico (Tokyo) (ap-northeast-1)

  • Regione Canada (Centrale) (ca-central-1)

  • Regione Canada occidentale (Calgary) (ca-west-1)

  • Regione Cina (Pechino) (cn-north-1)

  • Regione Cina (Ningxia) (cn-northwest-1)

  • Regione Europa (Francoforte) (eu-central-1)

  • Regione Europa (Zurigo) (eu-central-2)

  • Regione Europa (Irlanda) (eu-west-1)

  • Regione Europa (Londra) (eu-west-2)

  • Regione Europa (Milano) (eu-south-1)

  • Regione Europa (Spagna) (eu-south-2)

  • Regione Europa (Parigi) (eu-west-3)

  • Regione Europa (Stoccolma) (eu-north-1)

  • Regione di Israele (Tel Aviv) (il-central-1)

  • Regione Messico (Centrale) (mx-central-1)

  • Regione Medio Oriente (Bahrein) (me-south-1)

  • Regione Medio Oriente (EAU) (me-central-1)

  • Regione Sud America (San Paolo) (sa-east-1)

  • AWS GovCloud (US-East) (us-gov-east-1)

  • AWS GovCloud () (us-gov-west-1) US-West

Aggiornamento ai tipi di nodo RG o RA3

Per aggiornare il tipo di nodo esistente a RG o RA3, sono disponibili le seguenti opzioni per modificare il tipo di nodo:

  • Ripristino da uno snapshot: Amazon Redshift utilizza lo snapshot più recente del cluster e lo ripristina per creare un nuovo cluster RG o RA3. Non appena la creazione del cluster è completa (di solito entro pochi minuti), i nodi RG o RA3 sono pronti per eseguire l'intero carico di lavoro di produzione. Poiché il calcolo è separato dallo storage, i dati hot vengono trasferiti nella cache locale a velocità elevate grazie all'ampia larghezza di banda di rete. Se si esegue il ripristino dall'ultima istantanea DC2, RG e RA3 conservano le informazioni relative agli hot block del carico di lavoro DC2 e popolano la cache locale con i blocchi più caldi. Per ulteriori informazioni, consulta Ripristino di un cluster da uno snapshot.

    Per mantenere lo stesso endpoint per le applicazioni e gli utenti, è possibile rinominare il nuovo cluster RG o RA3 con lo stesso nome del cluster DC2 originale. Per rinominare il cluster, modificare il cluster nella console Amazon Redshift o con l'operazione API ModifyCluster. Per ulteriori informazioni, consultare Ridenominazione di un cluster o Operazione API ModifyCluster nella Guida di riferimento dell'API di Amazon Redshift.

  • Ridimensionamento elastico: ridimensiona il cluster utilizzando il ridimensionamento elastico. Quando si utilizza il ridimensionamento elastico per modificare il tipo di nodo, Amazon Redshift crea automaticamente uno snapshot, crea un nuovo cluster, elimina il cluster precedente e rinomina il nuovo cluster. L'operazione di ridimensionamento elastico può essere eseguita on demand o pianificata per l'esecuzione in un secondo momento. È possibile aggiornare rapidamente i cluster di tipo nodo DC2 esistenti a RG o RA3 con il ridimensionamento elastico. Per ulteriori informazioni, consulta Elastic resize (Ridimensionamento elastico).

Nota

Per migrare i cluster RA3 e DC2 esistenti su RG, la versione del cluster di origine deve essere P201 o successiva.

La tabella seguente mostra i consigli per l'aggiornamento ai tipi di nodi RG. (Queste raccomandazioni si applicano anche ai nodi riservati.)

I suggerimenti in questa tabella riguardano i tipi e le dimensioni iniziali dei nodi del cluster, ma dipendono dai requisiti di calcolo del carico di lavoro. Per valutare meglio i requisiti, prendi in considerazione la possibilità di condurre un proof of concept (POC) che utilizzi Test Drive per eseguire potenziali configurazioni. Esegui il provisioning di un cluster per il data warehouse POC anziché Redshift serverless. Per ulteriori informazioni sull’esecuzione di un proof of concept, consulta Eseguire un proof of concept (POC) per Amazon Redshift nella Guida per sviluppatori di database di Amazon Redshift.

Tipo di nodo esistente Numero di nodi esistenti Nuovo tipo di nodo consigliato Operazione di aggiornamento

ra3.4xl

2-64

gr. 4 x grande

Inizia con 3 nodi di rg.4xlarge per ogni 4 nodi di ra3.4xlarge 1.

ra3.xlplus

2—32

gr.xlarge

Inizia con 1 nodo di rg.xlarge per ogni nodo di ra3.xlplus 1.

dc2.8xlarge

2-15

rg.4xlarge

Inizia con 3 nodi di rg.4xlarge per ogni 2 nodi di dc2.8xlarge 1.

dc2.large

5–15

rg.xlarge

Inizia con 3 nodi di rg.xlarge ogni 8 nodi di dc2.large 1.

dc2.large

16-32

rg.4xlarge

Inizia con 1 nodo di rg.4xlarge ogni 10 nodi di dc2.large 1.

1Nodi aggiuntivi potrebbero essere necessari a seconda dei requisiti del carico di lavoro. Aggiungere o rimuovere nodi in base ai requisiti di calcolo delle prestazioni delle query richieste.

Nella tabella seguente vengono illustrati i suggerimenti durante l'aggiornamento a tipi di nodo RA3. (Queste raccomandazioni si applicano anche ai nodi riservati.)

I suggerimenti in questa tabella riguardano i tipi e le dimensioni iniziali dei nodi del cluster, ma dipendono dai requisiti di calcolo del carico di lavoro. Per valutare meglio i requisiti, prendi in considerazione la possibilità di condurre un proof of concept (POC) che utilizzi Test Drive per eseguire potenziali configurazioni. Esegui il provisioning di un cluster per il data warehouse POC anziché Redshift serverless. Per ulteriori informazioni sull’esecuzione di un proof of concept, consulta Eseguire un proof of concept (POC) per Amazon Redshift nella Guida per sviluppatori di database di Amazon Redshift.

Tipo di nodo esistente Numero di nodi esistenti Nuovo tipo di nodo consigliato Operazione di aggiornamento

dc2.8xlarge

2-15

ra3.4xlarge

Inizia con 2 nodi di ra3.4xlarge per ogni nodo di dc2.8xlarge1.

dc2.8xlarge

16-128

ra3.16xlarge

Inizia con 1 nodo di ra3.16xlarge per ogni 2 nodi di dc2.8xlarge1.

dc2.large

1-4

ra3.large

Inizia con 1 nodo di ra3.large per ogni nodo di dc2.large1.

Inizia con 2 nodi di ra3.large per ogni 2 nodi di dc2.large1.

Inizia con 3 nodi di ra3.large per ogni 3 nodi di dc2.large1.

Inizia con 3 nodi di ra3.large per ogni 4 nodi di dc2.large1.

dc2.large

5–15

ra3.xlplus

Inizia con 3 nodi di ra3.xplus per ogni 8 nodi di dc2.large1.

dc2.large

16-32

ra3.4xlarge

Inizia con 1 nodo di ra3.4xlarge per ogni 8 nodi di dc2.large1,2.

1Nodi aggiuntivi potrebbero essere necessari a seconda dei requisiti del carico di lavoro. Aggiungere o rimuovere nodi in base ai requisiti di calcolo delle prestazioni delle query richieste.

2 I cluster con il tipo di nodo dc2.large sono limitati a 32 nodi.

Il numero minimo di nodi per alcuni tipi di nodo RA3 è due. Tenere presente questo aspetto quando si crea un cluster RA3.

Funzionalità di rete supportate dai nodi RG e RA3

I nodi RG e RA3 supportano una raccolta di funzionalità di rete non disponibili per altri tipi di nodi. Questa sezione fornisce brevi descrizioni di ciascuna funzionalità e i link a documentazione aggiuntiva:

  • Provisioned-cluster Endpoint VPC: quando crei o ripristini un cluster RG o RA3, Amazon Redshift utilizza una porta compresa tra 5431-5455 o 8191-8215. Quando il cluster è impostato su una porta in uno di questi intervalli, Amazon Redshift crea automaticamente un endpoint VPC nel tuo AWS account per il cluster e gli assegna un indirizzo IP privato. Se imposti il cluster come accessibile al pubblico, Redshift crea un indirizzo IP elastico nell’account AWS e lo collega all’endpoint VPC. Per ulteriori informazioni, consulta Configurazione delle impostazioni di comunicazione dei gruppi di sicurezza per un cluster Amazon Redshift o gruppo di lavoro Amazon Redshift serverless.

  • Single-subnet Cluster RG o RA3: puoi creare un cluster RG o RA3 con una singola sottorete, ma non può utilizzare funzionalità di disaster recovery. Si verifica un’eccezione se abiliti la rilocazione del cluster quando la sottorete non dispone di più zone di disponibilità (AZ).

  • Multi-subnet Cluster e gruppi di sottoreti RG o RA3: puoi creare un cluster RG o RA3 con più sottoreti creando un gruppo di sottoreti quando esegui il provisioning del cluster nel tuo cloud privato virtuale (VPC). Un gruppo di sottoreti del cluster consente di specificare un set di sottoreti nel VPC e Amazon Redshift crea il cluster in una di esse. Dopo avere creato un gruppo di sottoreti, puoi rimuovere le sottoreti aggiunte in precedenza o aggiungerne altre. Per ulteriori informazioni, consulta Gruppi di sottoreti del cluster Amazon Redshift.

  • Cross-account o accesso agli endpoint cross-VPC: puoi accedere a un cluster o a un gruppo di lavoro Serverless Amazon Redshift predisposto configurando un endpoint VPC. Redshift-managed Ad esempio, puoi configurarlo come connessione privata tra un VPC che contiene un cluster o un gruppo di lavoro e un VPC in cui esegui uno strumento client. Con questo approccio puoi accedere al data warehouse senza utilizzare un indirizzo IP pubblico o senza instradare il traffico su Internet. Per ulteriori informazioni, consulta Lavorare con gli Redshift-managed endpoint VPC.

  • Rilocazione del cluster: puoi spostare un cluster in un’altra zona di disponibilità (AZ) senza alcuna perdita di dati in caso di interruzione del servizio. Per attivarlo  nella console Per ulteriori informazioni, consulta Rilocazione di un cluster.

  • Nome di dominio personalizzato: puoi creare un nome di dominio personalizzato, noto anche come URL personalizzato, per il cluster Amazon Redshift. È un record DNS di facile lettura che indirizza le SQL-client connessioni all'endpoint del cluster. Per ulteriori informazioni, consulta Nomi di dominio personalizzati per le connessioni client.

Aspetti da considerare durante l'aggiornamento ai nodi RG

Versione patch

P201 è la versione patch minima richiesta per migrare da RA3 o DC2 a RG. Prima della migrazione, verifica che il cluster sia installato su P201 o versione successiva e testa i carichi di lavoro ripristinando un'istantanea su un cluster RG prima di spostare il traffico di produzione. Per informazioni dettagliate, vedi Patch Amazon Redshift 201.

Carichi di lavoro Spectrum

I cluster con carichi di lavoro che utilizzano pesantemente Spectrum potrebbero registrare prestazioni di query più lente dopo la migrazione a RG. A differenza di RA3 e DC2, RG esegue il motore di query integrato Data Lake direttamente sui nodi di elaborazione del cluster anziché su una flotta Spectrum separata. Se riscontri un peggioramento delle prestazioni di Spectrum, aumenta il numero di nodi nel tuo cluster RG o esegui la migrazione a un tipo di nodo RG più grande.

Cursor-based carichi di lavoro

I nodi RG hanno dimensioni del cursore supportate diverse rispetto a RA3 e DC2. Fate riferimento a Cursor Constraints per i limiti di dimensione del cursore. Se il tuo carico di lavoro dipende in larga misura dai cursori e riscontri limitazioni nelle dimensioni dei cursori, esegui la migrazione a un tipo di nodo RG più grande: puoi ridurre proporzionalmente il numero di nodi per mantenere dimensioni e costi totali del cluster simili.