View a markdown version of this page

Considérations relatives à l’utilisation des clusters alloués Amazon Redshift - Amazon Redshift
Considérations sur les régions et les zones de disponibilitéMaintenance du cluster

Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement jusqu’au 30 juin 2026. Pour plus d’informations, consultez le billet de blog .

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Considérations relatives à l’utilisation des clusters alloués Amazon Redshift

Une fois votre cluster créé, vous trouverez dans cette section des informations sur les régions où les fonctionnalités sont disponibles, les tâches de maintenance, les types de nœuds et les limites d’utilisation.

Considérations sur les régions et les zones de disponibilité

Amazon Redshift est disponible dans plusieurs AWS régions. Par défaut, Amazon Redshift approvisionne votre cluster dans une zone de disponibilité (AZ) sélectionnée au hasard au sein de la AWS région que vous avez choisie. Tous les nœuds de cluster sont alloués dans la même zone de disponibilité.

Vous pouvez éventuellement demander une zone de disponibilité spécifique si Amazon Redshift est disponible dans cette zone. Par exemple, si vous avez déjà une instance Amazon EC2 en exécution dans une zone de disponibilité, vous pouvez créer votre cluster Amazon Redshift dans la même zone pour réduire la latence. D’autre part, vous pouvez choisir une autre zone de disponibilité pour une plus grande disponibilité. Amazon Redshift n'est peut-être pas disponible dans toutes les zones de disponibilité d'une AWS région.

Pour obtenir la liste des AWS régions prises en charge dans lesquelles vous pouvez provisionner un cluster Amazon Redshift, consultez la section Points de terminaison Amazon Redshift dans le. Référence générale d'Amazon Web Services

Maintenance du cluster

Amazon Redshift effectue régulièrement une maintenance pour appliquer les mises à niveau à votre cluster. Au cours de ces mises à jour, votre cluster Amazon Redshift n’est pas disponible pour les opérations normales. Il existe plusieurs manières de contrôler la gestion de votre cluster. Par exemple, vous pouvez contrôler le déploiement des mises à jour sur vos clusters. Vous pouvez également choisir si votre cluster est exécuté sur la version la plus récente ou sur la version publiée juste avant celle-ci. Enfin, vous avez également la possibilité de reporter les mises à jour de maintenance non obligatoires pendant une certaine période.

Fenêtres de maintenance

Amazon Redshift attribue une fenêtre de maintenance de 30 minutes au hasard sur une période de 8 heures par AWS région, survenant un jour aléatoire de la semaine (du lundi au dimanche inclus).

Fenêtres de maintenance par défaut

La liste suivante indique les plages horaires pour chaque AWS région à partir de laquelle les fenêtres de maintenance par défaut sont attribuées :

  • Région USA Est (Virginie du Nord) : 03:00 – 11:00 UTC

  • Région USA Est (Ohio) : 03:00 – 11:00 UTC

  • Région USA Ouest (Californie du Nord) : 06:00 – 14:00 UTC

  • Région USA Ouest (Oregon) : 06:00 – 14:00 UTC

  • Région Afrique (Le Cap) : 20:00 – 04:00 UTC

  • Région Asie-Pacifique (Hong Kong) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Hyderabad) : 16:30 – 00:30 UTC

  • Région Asie-Pacifique (Jakarta) : 15:00 – 23:00 UTC

  • Région Asie-Pacifique (Malaisie) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Melbourne) : 12:00 – 20:00 UTC

  • Région Asie-Pacifique (Mumbai) : 16:30 – 03:00 UTC

  • Région Asie-Pacifique (Nouvelle Zélande) : 10:00 – 18:00 UTC

  • Région Asie-Pacifique (Osaka) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Seoul) : 13:00 – 21:00 UTC

  • Région Asie-Pacifique (Singapour) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Sydney) : 12:00 – 20:00 UTC

  • Région Asie-Pacifique (Taipei) : 14:00 – 22:00 UTC

  • Région Asie-Pacifique (Thaïlande) : 15:00 – 23:00 UTC

  • Région Asie-Pacifique (Tokyo) : 13:00 – 021:00 UTC

  • Région Canada (Centre) : 03:00 – 11:00 UTC

  • Région Canada Ouest (Calgary) : 4 h 00–12 h 00 UTC

  • Région Chine (Beijing) : 13:00 – 21:00 UTC

  • Région Chine (Ningxia) : 13:00 – 21:00 UTC

  • Région Europe (Francfort) : 06:00 – 14:00 UTC

  • Région Europe (Irlande) : 22:00 – 06:00 UTC

  • Région Europe (Londres) : 22:00 – 06:00 UTC

  • Région Europe (Milan) : 21:00 – 05:00 UTC

  • Région Europe (Paris) : 23:00 – 07:00 UTC

  • Région Europe (Stockholm) : 23:00 – 07:00 UTC

  • Région Europe (Zurich) : 20:00 – 04:00 UTC

  • Région Israël (Tel Aviv) : 20:00 – 04:00 UTC

  • Région Mexique (Centre) : 04:00 – 12:00 UTC

  • Région Europe (Espagne) : 21:00 – 05:00 UTC

  • Région Moyen-Orient (Bahreïn) : 13:00 – 21:00 UTC

  • Région Moyen-Orient (EAU) : 18:00 – 02:00 UTC

  • Région Amérique du Sud (São Paulo) : 19:00 – 03:00 UTC

Si un événement de maintenance est planifié pour une semaine donnée, il démarre pendant la fenêtre de maintenance de 30 minutes attribuée. Pendant qu’Amazon Redshift effectue la maintenance, il met fin à toutes les requêtes ou autres opérations en cours. Les interruptions de service survenues lors de la maintenance planifiée ne sont pas considérées comme des interruptions mensuelles ou des indisponibilités dans le cadre du contrat de niveau de service Amazon Redshift. La plus grande partie de la maintenance s’effectue pendant la fenêtre de maintenance de 30 minutes, mais certaines tâches de maintenance peuvent continuer à s’exécuter après la fermeture de la fenêtre. S’il n’y a aucune tâche de maintenance à effectuer pendant la fenêtre de maintenance planifiée, votre cluster continue à fonctionner normalement jusqu’à la prochaine fenêtre de maintenance.

Vous pouvez modifier la fenêtre de maintenance planifiée en modifiant le cluster, soit de manière programmatique, soit en utilisant la console Amazon Redshift. Vous pouvez trouver la fenêtre de maintenance et définir le jour et l’heure auxquels elle se produit pour le cluster sous l’onglet Maintenance.

Il est possible qu’un cluster redémarre en dehors d’une fenêtre de maintenance. Cela peut se produire pour plusieurs raisons. Une des raisons les plus courantes est qu’un problème a été détecté avec le cluster et que des opérations de maintenance sont en cours pour le ramener à un état sain. Pour plus d’informations, consultez l’article Pourquoi mon cluster Amazon Redshift a-t-il redémarré en dehors de la fenêtre de maintenance ?, qui fournit des détails sur les raisons pour lesquelles cela peut se produire.

Report de la maintenance

Pour replanifier la fenêtre de maintenance de votre cluster, vous pouvez reporter la maintenance jusqu'à 60 jours. Par exemple, si la fenêtre de maintenance de votre cluster est définie sur mercredi 8 h 30 – 9 h UTC, mais que vous devez accéder à votre cluster à ce moment précis, vous pouvez reporter la maintenance.

Si vous reportez la maintenance, Amazon Redshift appliquera toujours les mises à jour matérielles ou autres mises à jour de sécurité obligatoires à votre cluster. Votre cluster n’est pas disponible au cours de ces mises à jour.

Si une mise à jour matérielle ou une autre mise à jour de sécurité obligatoire est planifiée pendant la prochaine fenêtre de maintenance, Amazon Redshift vous envoie des notifications anticipées dans la catégorie En attente. Pour en savoir plus sur les notifications d’événements En attente, consultez Notifications d’événement d’un cluster alloué Amazon Redshift.

Vous pouvez également choisir de recevoir des notifications d’événements d’Amazon Simple Notification Service (Amazon SNS). Pour plus d’informations sur l’abonnement à la notification d’événements Amazon RDS, consultez Abonnements aux notifications d’événements de cluster Amazon Redshift.

Si vous reportez la maintenance de votre cluster, la fenêtre de maintenance suivant la période de report ne peut pas être reportée.

Note

Vous ne pouvez pas reporter une opération de maintenance une fois celle-ci entamée.

Pour plus d’informations sur la maintenance du cluster, consultez la documentation suivante :

Sélection du suivi de maintenance des clusters

Lorsque Amazon Redshift publie une nouvelle version du cluster, votre cluster est mis à jour pendant sa fenêtre de maintenance. Vous pouvez vérifier si votre cluster est mis à jour par rapport à la dernière version ou à la précédente.

Le suivi contrôle la version du cluster qui est appliquée au cours d’une fenêtre de maintenance. Lorsqu’Amazon Redshift publie une nouvelle version du cluster, cette version est assignée au suivi Current (Actuellle) et la version précédente est assignée au suivi Trailing (Précédente).

Pour plus d’informations sur le suivi du cluster, consultez Suivi des clusters alloués Amazon Redshift et des groupes de travail sans serveur.

Comprendre comment les nœuds RG et RA3 séparent le calcul du stockage

Ces sections détaillent les tâches disponibles pour les types de nœuds RG et RA3, en montrant leur applicabilité à un ensemble de cas d'utilisation et en détaillant leurs avantages par rapport aux types de nœuds précédemment disponibles.

Avantages et disponibilité des nœuds RG et RA3

Les nœuds RG et RA3 présentent les avantages suivants :

  • Ils sont flexibles pour augmenter votre capacité de calcul sans augmenter vos coûts de stockage. De plus, ils adaptent votre stockage sans surprovisionner la capacité de calcul.

  • Ils utilisent des disques SSD haute performance pour vos données sensibles (hot data) et Amazon S3 pour les données non sensibles (cold data). Ils offrent ainsi une facilité d’utilisation, un stockage économique et des performances de requête élevées.

  • Ils utilisent un réseau à haut débit basé sur le système AWS Nitro afin de réduire davantage le temps nécessaire au déchargement et à la récupération des données vers Amazon S3.

Pensez à choisir les types de nœuds RG et RA3 dans les cas suivants :

  • Si vous avez besoin de la flexibilité nécessaire pour dimensionner et payer le calcul indépendamment du stockage.

  • Vous interrogez une fraction de vos données totales.

  • Votre volume de données augmente rapidement ou devrait croître rapidement.

  • Vous souhaitez avoir la flexibilité nécessaire pour dimensionner le cluster uniquement en fonction de vos besoins en performances.

Considérations relatives au calcul des requêtes de lac de données — Sur les clusters provisionnés en DC2 et RA3, les requêtes de lac de données sont exécutées sur Redshift Spectrum, qui utilise des serveurs Amazon Redshift dédiés indépendants de votre cluster. Sur les clusters provisionnés par RG, les requêtes du lac de données s'exécutent sur les propres ressources de calcul du cluster et partagent ces ressources avec d'autres charges de travail. Pour les charges de travail impliquant une utilisation intensive des requêtes de lac de données, considérez cela lors du dimensionnement de votre cluster RG.

Pour utiliser les types de nœuds RG, votre AWS région doit prendre en charge le RG. Pour de plus amples informations, veuillez consulter Disponibilité du type de nœud RG dans AWS Régions.

Pour utiliser les types de nœuds RA3, votre AWS région doit prendre en charge le RA3. Pour de plus amples informations, veuillez consulter Disponibilité du type de nœud RA3 dans AWS Régions.

Important

Vous pouvez utiliser les types de nœuds ra3.xlplus uniquement avec la version de cluster 1.0.21262 ou ultérieure. Vous pouvez consulter la version d’un cluster existant avec la console Amazon Redshift. Pour de plus amples informations, veuillez consulter Déterminer la version du groupe de travail ou du cluster.

Assurez-vous d'utiliser la nouvelle console Amazon Redshift lorsque vous travaillez avec des nœuds de type RG ou RA3.

En outre, pour utiliser des types de nœuds RG ou RA3 avec des opérations Amazon Redshift qui utilisent le suivi, la valeur du suivi de maintenance doit être définie sur une version de cluster prenant en charge le RG ou le RA3. Pour plus d’informations sur le suivi, consultez Sélection du suivi de maintenance des clusters.

Prenez en compte les points suivants lorsque vous utilisez des types de nœuds RA3 à nœud unique.

  • Les producteurs et consommateurs d’unités de partage des données sont pris en charge.

  • Pour modifier les types de nœuds, seul le redimensionnement classique est pris en charge. La modification du type de nœud avec le redimensionnement élastique ou la restauration d’instantané n’est pas prise en charge. Les scénarios suivants sont pris en charge :

    • Redimensionnement classique de dc2.xlarge à 1 nœud vers ra3.xlplus à 1 nœud, et vice versa.

    • Redimensionnement classique de dc2.xlarge à 1 nœud vers ra3.xlplus à nœuds multiples, et vice versa.

    • Redimensionnement classique de dc2.xlarge à nœuds multiples vers ra3.xlplus à 1 nœud, et vice versa.

Utilisation du stockage géré Amazon Redshift

Avec le stockage géré d’Amazon Redshift, vous pouvez stocker et traiter toutes vos données dans Amazon Redshift tout en bénéficiant d’une plus grande flexibilité pour faire évoluer séparément la capacité de calcul et de stockage. Vous continuez à ingérer des données avec la commande COPY ou INSERT. Pour optimiser les performances et gérer le placement automatique des données sur les différents niveaux de stockage, Amazon Redshift tire parti d’optimisations telles que la température des blocs de données, leur âge et les modèles de charge de travail. Lorsque cela est nécessaire, Amazon Redshift met automatiquement à niveau le stockage vers Amazon S3 sans nécessiter d’action manuelle.

Pour plus d’informations sur les coûts de stockage, consultez Tarification Amazon Redshift.

Gestion des types de nœuds RG ou RA3

Pour tirer parti de la séparation entre le calcul et le stockage, vous pouvez créer ou mettre à niveau votre cluster avec le type de nœud RG ou RA3. Pour utiliser les types de nœuds RG ou RA3, créez vos clusters dans un cloud privé virtuel ()EC2-VPC.

Pour modifier le nombre de nœuds du cluster Amazon Redshift avec un type de nœud RG ou RA3, effectuez l'une des opérations suivantes :

  • Ajoutez ou supprimez des nœuds avec l’opération de redimensionnement élastique. Dans certains cas, la suppression de nœuds d'un cluster RG ou RA3 n'est pas autorisée avec le redimensionnement élastique. Par exemple, lorsqu’une mise à niveau du nombre de nœuds 2:1 place le nombre de tranches par nœud à 32. Pour plus d’informations, consultez Redimensionnement d’un cluster. Si le redimensionnement élastique n’est pas disponible, utilisez le redimensionnement classique.

  • Ajoutez ou supprimez des nœuds avec l’opération de redimensionnement classique. Choisissez cette option lorsque vous effectuez un redimensionnement sur une configuration qui ne permet pas le redimensionnement Elastic Le redimensionnement élastique est plus rapide que le redimensionnement classique. Pour de plus amples informations, veuillez consulter Redimensionnement d’un cluster.

Disponibilité du type de nœud RG dans AWS Régions

Les types de nœuds RG ne sont disponibles que dans les AWS régions suivantes :

  • Région USA Est (Virginie du Nord) (us-east-1)

  • Région USA Est (Ohio) (us-east-2)

  • Région US Ouest (Californie du Nord) (us-west-1)

  • Région USA Ouest (Oregon) (us-west-2)

  • Région Asie-Pacifique (Hong Kong) (ap-east-1)

  • Région Asie-Pacifique (Taipei) (ap-east-2)

  • Région Asie-Pacifique (Tokyo) (ap-northeast-1)

  • Région Asie-Pacifique (Séoul) (ap-northeast-2)

  • Région Asie-Pacifique (Osaka) (ap-northeast-3)

  • Région Asie-Pacifique (Mumbai) (ap-south-1)

  • Région Asie-Pacifique (Hyderabad) (ap-south-2)

  • Région Asie-Pacifique (Singapour) (ap-southeast-1)

  • Région Asie-Pacifique (Sydney) (ap-southeast-2)

  • Région Asie-Pacifique (Jakarta) (ap-southeast-3)

  • Région Asie-Pacifique (Melbourne) (ap-southeast-4)

  • Région Asie-Pacifique (Malaisie) (ap-southeast-5)

  • Région Canada (Centre) (ca-central-1)

  • Région Europe (Francfort) (eu-central-1)

  • Région Europe (Stockholm) (eu-north-1)

  • Région Europe (Milan) (eu-south-1)

  • Région Europe (Espagne) (eu-south-2)

  • Région Europe (Irlande) (eu-west-1)

  • Région Europe (Londres) (eu-west-2)

  • Région Europe (Paris) (eu-west-3)

  • Région Amérique du Sud (Sao Paulo) (sa-east-1)

Disponibilité du type de nœud RA3 dans AWS Régions

Les types de nœuds RA3 ne sont disponibles que dans les AWS régions suivantes :

  • Région USA Est (Virginie du Nord) (us-east-1)

  • Région USA Est (Ohio) (us-east-2)

  • Région US Ouest (Californie du Nord) (us-west-1)

  • Région USA Ouest (Oregon) (us-west-2)

  • Région Afrique (Le Cap) (af-south-1)

  • Région Asie-Pacifique (Hong Kong) (ap-east-1)

  • Région Asie-Pacifique (Hyderabad) (ap-south-2)

  • Région Asie-Pacifique (Jakarta) (ap-southeast-3)

  • Région Asie-Pacifique (Malaisie) (ap-southeast-5)

  • Région Asie-Pacifique (Melbourne) (ap-southeast-4)

  • Région Asie-Pacifique (Mumbai) (ap-south-1)

  • Région Asie-Pacifique (Nouvelle Zélande) (ap-southeast-6)

  • Région Asie-Pacifique (Osaka) (ap-northeast-3)

  • Région Asie-Pacifique (Séoul) (ap-northeast-2)

  • Région Asie-Pacifique (Singapour) (ap-southeast-1)

  • Région Asie-Pacifique (Sydney) (ap-southeast-2)

  • Région Asie-Pacifique (Taipei) (ap-east-2)

  • Région Asie-Pacifique (Thaïlande) (ap-southeast-7)

  • Région Asie-Pacifique (Tokyo) (ap-northeast-1)

  • Région Canada (Centre) (ca-central-1)

  • Région Canada Ouest (Calgary) (ca-west-1)

  • Région Chine (Beijing) (cn-north-1)

  • Région Chine (Ningxia) (cn-northwest-1)

  • Région Europe (Francfort) (eu-central-1)

  • Région Europe (Zurich) (eu-central-2)

  • Région Europe (Irlande) (eu-west-1)

  • Région Europe (Londres) (eu-west-2)

  • Région Europe (Milan) (eu-south-1)

  • Région Europe (Espagne) (eu-south-2)

  • Région Europe (Paris) (eu-west-3)

  • Région Europe (Stockholm) (eu-north-1)

  • Région Israël (Tel Aviv) (il-central-1)

  • Région Mexique (Centre) (mx-central-1)

  • Région Moyen-Orient (Bahreïn) (me-south-1)

  • Région Moyen-Orient (Émirats arabes unis) (me-central-1)

  • Région Amérique du Sud (Sao Paulo) (sa-east-1)

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

  • AWS GovCloud (US-West) (US-GOV-West-1)

Mise à niveau vers des types de nœuds RG ou RA3

Pour mettre à niveau votre type de nœud existant vers RG ou RA3, vous disposez des options suivantes pour modifier le type de nœud :

  • Restauration à partir d'un instantané : Amazon Redshift utilise l'instantané le plus récent de votre cluster et le restaure pour créer un nouveau cluster RG ou RA3. Dès que la création du cluster est terminée (généralement en quelques minutes), les nœuds RG ou RA3 sont prêts à exécuter votre charge de travail de production complète. Comme le calcul est séparé du stockage, les données chaudes sont introduites dans le cache local à des vitesses rapides grâce à une large bande passante réseau. Si vous effectuez une restauration à partir du dernier instantané DC2, RG et RA3 préservent les informations relatives aux hot blocks de la charge de travail DC2 et remplissent son cache local avec les blocs les plus chauds. Pour de plus amples informations, veuillez consulter Restauration d’un cluster à partir d’un instantané.

    Pour conserver le même point de terminaison pour vos applications et vos utilisateurs, vous pouvez renommer le nouveau cluster RG ou RA3 avec le même nom que le cluster DC2 d'origine. Pour renommer le cluster, modifiez le cluster dans la console Amazon Redshift ou via l’opération API ModifyCluster. Pour plus d’informations, consultez Renommer un cluster ou Opérations de l’API de ModifyCluster dans la Référence API Amazon Redshift.

  • Redimensionnement élastique – Redimensionner le cluster à l’aide du redimensionnement Elastic. Lorsque vous utilisez le redimensionnement Elastic pour changer de type de nœud, Amazon Redshift crée automatiquement un instantané, puis un nouveau cluster, supprime l’ancien cluster et renomme le nouveau cluster. L’opération de redimensionnement Elastic peut être exécutée à la demande ou programmée pour être exécutée plus tard. Vous pouvez rapidement mettre à niveau vos clusters de type nœud DC2 existants vers RG ou RA3 grâce au redimensionnement élastique. Pour de plus amples informations, veuillez consulter Elastic resize (Redimensionnement élastique).

Note

Pour migrer des clusters RA3 et DC2 existants vers RG, la version de votre cluster source doit être P201 ou une version ultérieure.

Le tableau suivant présente les recommandations relatives à la mise à niveau vers les types de nœuds RG. (Ces recommandations s’appliquent également aux nœuds réservés.)

Les recommandations de cette table concernent les types et tailles de nœuds de cluster de départ, mais dépendent des exigences informatiques de votre charge de travail. Pour mieux estimer vos besoins, envisagez de réaliser une preuve de concept (POC) qui utilise Test Drive pour exécuter des configurations potentielles. Allouez un cluster pour votre entrepôt de données POC au lieu de Redshift sans serveur. Pour plus d’informations sur la réalisation d’une preuve de concept, consultez Réaliser une preuve de concept (POC) pour Amazon Redshift dans le Guide du développeur de base de données Amazon Redshift.

Type de nœud existant Nombre de nœuds existants Nouveau type de nœud recommandé Action de mise à niveau

ra3.4xl

2-64

rg.4 x large

Commencez avec 3 nœuds de rg.4xlarge pour 4 nœuds de ra3.4xlarge 1.

ra3.xlplus

2—32

rg.xlarge

Commencez avec 1 nœud de rg.xlarge pour chaque nœud de ra3.xlplus 1.

dc2.8xlarge

2–15

rg.4 x large

Commencez avec 3 nœuds de rg.4xlarge pour 2 nœuds de dc2.8xlarge 1.

dc2.large

5–15

rg.xlarge

Commencez avec 3 nœuds de rg.xlarge pour 8 nœuds de dc2.large 1.

dc2.large

16–32

rg.4 x large

Commencez avec 1 nœud de rg.4xlarge pour 10 nœuds de dc2.large 1.

1Des nœuds supplémentaires peuvent être nécessaires en fonction des exigences de charge de travail. Ajoutez ou supprimez des nœuds en fonction des besoins de calcul de vos performances de requête requises.

Le tableau suivant présente des recommandations lors de la mise à niveau vers des types de nœuds RA3. (Ces recommandations s’appliquent également aux nœuds réservés.)

Les recommandations de cette table concernent les types et tailles de nœuds de cluster de départ, mais dépendent des exigences informatiques de votre charge de travail. Pour mieux estimer vos besoins, envisagez de réaliser une preuve de concept (POC) qui utilise Test Drive pour exécuter des configurations potentielles. Allouez un cluster pour votre entrepôt de données POC au lieu de Redshift sans serveur. Pour plus d’informations sur la réalisation d’une preuve de concept, consultez Réaliser une preuve de concept (POC) pour Amazon Redshift dans le Guide du développeur de base de données Amazon Redshift.

Type de nœud existant Nombre de nœuds existants Nouveau type de nœud recommandé Action de mise à niveau

dc2.8xlarge

2–15

ra3.4xlarge

Commencez par 2 nœuds de ra3.4xlarge pour chaque nœud de dc2.8xlarge1.

dc2.8xlarge

16–128

ra3.16xlarge

Commencez par 1 nœud de ra3.16xlarge pour tous les 2 nœuds de dc2.8xlarge1.

dc2.large

1 – 4

ra3.large

Commencez par 1 nœud de ra3.large pour chaque nœud de dc2.large1.

Commencez par 2 nœuds de ra3.large tous les 2 nœuds de dc2.large1.

Commencez par 3 nœuds de ra3.large tous les 3 nœuds de dc2.large1.

Commencez par 3 nœuds de ra3.large tous les 4 nœuds de dc2.large1.

dc2.large

5–15

ra3.xlplus

Commencez par 3 nœuds de ra3.xlplus tous les 8 nœuds de dc2.large1.

dc2.large

16–32

ra3.4xlarge

Commencez par 1 nœud de ra3.4xlarge tous les 8 nœuds de dc2.large1,2.

1Des nœuds supplémentaires peuvent être nécessaires en fonction des exigences de charge de travail. Ajoutez ou supprimez des nœuds en fonction des besoins de calcul de vos performances de requête requises.

2Les clusters avec le type de nœud dc2.large sont limités à 32 nœuds.

Le nombre minimum de nœuds pour certains types de nœud RA3 est de deux nœuds. Prenez cela en compte lors de la création d’un cluster RA3.

Fonctionnalités réseau prises en charge par les nœuds RG et RA3

Les nœuds RG et RA3 prennent en charge un ensemble de fonctionnalités réseau non disponibles pour les autres types de nœuds. Cette section fournit une brève description de chaque fonctionnalité et des liens vers de la documentation supplémentaire :

  • Provisioned-cluster Point de terminaison VPC : lorsque vous créez ou restaurez un cluster RG ou RA3, Amazon Redshift utilise un port compris entre 5431 et 5455 ou 8191-8215. Lorsque le cluster est défini sur un port de l'une de ces plages, Amazon Redshift crée automatiquement un point de terminaison VPC dans votre AWS compte pour le cluster et y attache une adresse IP privée. Si vous configurez le cluster pour qu’il soit accessible au public, Redshift crée une adresse IP Elastic dans votre compte AWS et l’attache au point de terminaison d’un VPC. Pour plus d’informations, consultez Configuration des paramètres de communication des groupes de sécurité pour un cluster Amazon Redshift ou un groupe de travail Amazon Redshift sans serveur

  • Single-subnet Clusters RG ou RA3 : vous pouvez créer un cluster RG ou RA3 avec un seul sous-réseau, mais il ne peut pas utiliser les fonctionnalités de reprise après sinistre. Une exception se produit si vous activez la relocalisation de cluster alors que le sous-réseau ne dispose pas de plusieurs zones de disponibilité (AZ).

  • Multi-subnet Clusters et groupes de sous-réseaux RG ou RA3 : vous pouvez créer un cluster RG ou RA3 avec plusieurs sous-réseaux en créant un groupe de sous-réseaux lorsque vous provisionnez le cluster dans votre cloud privé virtuel (VPC). Un groupe de sous-réseaux de cluster vous permet de spécifier un ensemble de sous-réseaux dans votre VPC et Amazon Redshift crée le cluster dans l’un d’entre eux. Après avoir créé un groupe de sous-réseaux, vous pouvez supprimer les sous-réseaux ajoutés précédemment ou en ajouter plus. Pour de plus amples informations, consultez Groupes de sous-réseaux de cluster Amazon Redshift.

  • Cross-account ou accès aux points de terminaison entre VPC : vous pouvez accéder à un cluster provisionné ou à un groupe de travail Amazon Redshift Serverless en configurant un point de terminaison VPC. Redshift-managed Vous pouvez le configurer en tant que connexion privée entre un VPC qui contient un cluster ou un groupe de travail et un VPC dans lequel vous exécutez un outil client, par exemple. Ainsi, vous pouvez accéder à l’entrepôt des données sans utiliser d’adresse IP publique ni acheminer le trafic sur Internet. Pour plus d'informations, consultez la section Utilisation des points de Redshift-managed terminaison VPC.

  • Relocalisation de cluster : vous pouvez déplacer un cluster vers une autre zone de disponibilité (AZ) sans subir la moindre de perte de données en cas d’interruption de service. Vous devez l’activer dans la console. Pour plus d’informations, consultez Relocalisation d’un cluster.

  • Nom de domaine personnalisé – Vous pouvez créer un nom de domaine personnalisé, également appelé URL personnalisée, pour votre cluster Amazon Redshift. Il s'agit d'un enregistrement DNS facile à lire qui achemine les SQL-client connexions vers le point de terminaison de votre cluster. Pour de plus amples informations, veuillez consulter Noms de domaine personnalisé pour les connexions client.

Éléments à prendre en compte lors de la mise à niveau vers les nœuds RG

Version du correctif

P201 est la version de correctif minimale requise pour migrer de RA3 ou DC2 vers RG. Avant de migrer, vérifiez que votre cluster est sur P201 ou version ultérieure et testez vos charges de travail en restaurant un instantané sur un cluster RG avant de déplacer le trafic de production. Pour en savoir plus, consultez Correctif 201 d'Amazon Redshift.

Charges de travail liées au spectre

Les clusters dont les charges de travail utilisent fortement Spectrum peuvent observer un ralentissement des performances de requête après la migration vers RG. Contrairement à RA3 et DC2, RG exécute le moteur de requête de lac de données intégré directement sur les nœuds de calcul du cluster plutôt que sur un parc Spectrum distinct. Si vous constatez une dégradation des performances de Spectrum, augmentez le nombre de nœuds de votre cluster RG ou migrez vers un type de nœud RG plus important.

Cursor-based charges de travail

Les nœuds RG ont une taille de curseur prise en charge différente de celle des nœuds RA3 et DC2. Reportez-vous à la section Contraintes du curseur pour connaître les limites de taille du curseur. Si votre charge de travail dépend fortement des curseurs et que la taille des curseurs est limitée, migrez vers un type de nœud RG plus important. Vous pouvez réduire le nombre de nœuds proportionnellement pour maintenir une taille et un coût de cluster totaux similaires.