Comment redimensionner un cluster Amazon Redshift ?

Solution

Il existe quatre façons de redimensionner un cluster Amazon Redshift :

• Redimensionnement élastique : si le redimensionnement élastique est disponible en option, utilisez-le pour modifier le type de nœud, le nombre de nœuds ou les deux. Notez que lorsque vous modifiez uniquement le nombre de nœuds, les requêtes sont temporairement suspendues et les connexions restent ouvertes. Un redimensionnement élastique prend entre 10 et 15 minutes. Pendant une opération de redimensionnement, le cluster est en lecture seule.
• Redimensionnement classique : utilisez le redimensionnement classique pour changer le type de nœud, le nombre de nœuds, ou les deux. Choisissez cette option lorsque vous redimensionnez une configuration qui n'est pas disponible via le redimensionnement élastique. Une opération de redimensionnement prend deux heures ou plus, ou peut durer plusieurs jours en fonction de la taille de vos données. Pendant l'opération de redimensionnement, le cluster source est en lecture seule.
• Instantané, restauration et redimensionnement : pour vous assurer que le cluster est disponible pendant une opération de redimensionnement classique, faites une copie du cluster existant. Ensuite, redimensionnez le nouveau cluster. Si des données sont écrites dans le cluster source après la prise d'un instantané, les données doivent être copiées manuellement. La copie manuelle des données vers le cluster cible nouvellement créé doit avoir lieu après la fin de la migration.
• Redimensionnement classique rapide : le redimensionnement classique rapide est aussi rapide que le redimensionnement élastique et fonctionne de manière similaire au redimensionnement classique. Cette opération de redimensionnement comporte deux étapes principales. Dans l'étape 1 (chemin critique), les données sont migrées du cluster source vers un cluster cible et le cluster est en mode lecture seule. Dans l'étape 2 (hors chemin critique), la redistribution des données, effectuée dans le style de distribution de données précédent, est achevée en arrière-plan. La durée de cette étape dépend du volume à distribuer et de la charge de travail du cluster.

Pour plus d'informations, consultez Présentation de la gestion des clusters dans Amazon Redshift.

Conditions préalables au redimensionnement

Pour vérifier si votre cluster est éligible au redimensionnement élastique, exécutez la commande AWS CLI ou AWS CloudShell suivante :

aws redshift describe-node-configuration-options --cluster-identifier <cluster-id> --action-type resize-cluster

Remarque : si vous recevez des erreurs lors de l'exécution de commandes de l'interface de la ligne de commande AWS (AWS CLI), assurez-vous d'utiliser la version la plus récente de l'AWS CLI.

Si le cluster est éligible au redimensionnement élastique, la sortie est similaire à ce qui suit dans AWS CLI :

{
    "NodeConfigurationOptionList": [
        {
            "NodeType": "dc2.large",
            "NumberOfNodes": 2,
            "EstimatedDiskUtilizationPercent": 0.01
      },
        {
            "NodeType": "ra3.16xlarge",
            "NumberOfNodes": 2,
            "EstimatedDiskUtilizationPercent": 0.01
        }
]    
    }

Si le cluster n'est pas éligible au redimensionnement élastique, la sortie est similaire à ce qui suit dans l'AWS CLI :

{
    "NodeConfigurationOptionList": []
}

Test comparatif de performances

Avant un redimensionnement, vous pouvez effectuer un test comparatif de performances sur les charges de travail de cluster existantes et les charges de travail de cluster cibles pour prendre des décisions concernant le redimensionnement.

Vitesse d'une opération de redimensionnement

Si le redimensionnement élastique est utilisé pour redimensionner un cluster avec le même type de nœud, l'opération ne crée pas de nouveau cluster. En conséquence, l'opération se termine rapidement. Le temps nécessaire pour effectuer un redimensionnement classique ou une opération de capture instantanée et de restauration peut varier, en fonction des facteurs suivants :

• La charge de travail sur le cluster source.
• Le nombre et la taille des tables transférées du cluster source au cluster cible.
• Le degré d'uniformisation des données à travers les nœuds de calcul et les tranches.
• La configuration des nœuds dans les clusters source et cible.

Remarque : si vous effectuez un redimensionnement classique sur un cluster avec un grand volume de données et que les nœuds ne sont pas RA3, la migration des données peut être lente. La migration d'un cluster contenant plusieurs téraoctets (To) de données peut prendre plusieurs jours. Le transfert des données pour les nœuds RA3 s'effectue plus rapidement.

Optimisation de la vitesse des opérations

Pour réduire le temps nécessaire à un redimensionnement classique ou à une opération d'instantané et de restauration :

• Migrez vers le type de nœud RA3, car le redimensionnement est plus rapide.
• Exécutez le script d'inspection de table depuis AWS Labs pour identifier les tables asymétriques. Pour réparer les tables asymétriques, sélectionnez une clé de distribution appropriée. Pour plus d'informations, consultez la section Amazon Redshift Engineering's Advanced Table Design Playbook: Distribution Styles and Distribution Keys (Playbook de conception de table avancée d'ingénierie Amazon Redshift : styles de distribution et clés de distribution).
• Supprimez les tables non utilisées. Pour identifier les tables non utilisées, exécutez le script de récapitulatif des tables non scannées depuis AWS Labs. Remarque : le récapitulatif des tables non scannées montre uniquement l'historique récent (entre 2 et 5 jours). Utilisez l'utilitaire System Object Persistence Utility pour capturer les données d'utilisation sur une période plus longue.
• Identifiez les tables dont les statistiques sont manquantes dans AWS Labs et exécutez la commande ANALYZE sur ces tables.

Pour plus d'informations sur l'optimisation de vos performances de redimensionnement, consultez Top 10 performance tuning techniques for Amazon Redshift.

Pour vérifier le statut de votre opération de redimensionnement à l'aide de la console Amazon Redshift, sélectionnez l'onglet Status (Statut) sur la page des détails du cluster. L'onglet Statut indique le taux moyen de transfert, le temps écoulé et le temps restant.

Dépannage

• Lors d'une opération de redimensionnement, la taille de votre table augmente ou diminue. Ce comportement est normal. Pour plus d'informations, consultez Pourquoi une table d'un cluster Amazon Redshift utilise-t-elle plus ou moins d'espace de stockage sur disque que prévu ?
• Si l'état de votre cluster est NONE dans l'AWS CLI, le cluster cible est encore en cours d'approvisionnement. Lorsque votre cluster cible est alloué, il n'a pas encore été copié. Une fois que le cluster cible est alloué, la statut passe à IN_PROGRESS.
• Si le redimensionnement de votre AWS CloudFormation StackSets a échoué avec l'erreur « An internal error has occurred. Please try your query again at a later time » (Une erreur interne s'est produite. Veuillez réessayer votre requête ultérieurement). Vérifiez si le cluster est éligible au redimensionnement élastique. La pile CloudFormation utilise le redimensionnement élastique où Classic:false est défini par défaut.
• Si vous recevez un message d'erreur vous invitant à « Please choose a larger target cluster » (Veuillez choisir un cluster cible plus grand), vos données ne rentrent pas dans le cluster cible. Redimensionnez votre cluster Amazon Redshift avec plus de nœuds ou un type de nœud différent.
• Pour annuler une opération de redimensionnement avant qu'elle ne se termine, sélectionnez cancel resize (annuler le redimensionnement) depuis la liste des clusters dans la console Amazon Redshift. Pour plus d'informations, consultez la rubrique Capture instantanée, restauration et redimensionnement.

Facturation pour les clusters redimensionnés

• Au cours des opérations de redimensionnement, vous êtes facturé pour les clusters disponibles. Par exemple, au cours d'une opération de redimensionnement, vous êtes facturé pour la configuration du cluster source. Une fois que le redimensionnement est terminé, vous n'êtes plus facturé pour la configuration du cluster source. La facturation commence pour la configuration du cluster cible dès que son statut est available (disponible).
• Lorsque vous redimensionnez des types de nœuds plus petits (grands, xlarge) en types de nœuds plus grands (8xlarge), votre cluster nécessite plus de stockage par nœud. Plus vous avez de stockage par nœud, plus les métadonnées sont écrites lorsque vous exécutez la commande COMMIT. Cela signifie que le coût de base pour une seule opération COMMIT est plus élevé pour les nœuds plus grands. Si vous exécutez plusieurs petites opérations COMMIT simultanément, il se peut que vous constatiez une diminution des performances. Pour améliorer les performances, regroupez plusieurs modifications en une seule opération COMMIT.
• Si vous avez acheté des instances réservées, la facturation dépend de la configuration des clusters redimensionnés, des types de nœuds réservés et du nombre de nœuds réservés. Pour plus d'informations, voir Comment fonctionnent les nœuds réservés.

---

Informations connexes

Redimensionnement des clusters dans Amazon Redshift

Résolution des problèmes de connexion dans Amazon Redshift

Création de tests comparatifs de performances de haute qualité pour Amazon Redshift à l'aide de SQLWorkbench et psql