Pour quelles raisons des problèmes de connectivité intermittente se produisent-ils avec mon cluster Amazon Redshift ?

Brève description

Les facteurs suivants peuvent provoquer des problèmes de connectivité intermittente dans un cluster Amazon Redshift :

• Accès restreint à une adresse IP ou un bloc CIDR particulier
• Mises à jour des fenêtres de maintenance
• Défaillances des nœuds ou tâches d’administration planifiées
• Rotations des clés de chiffrement
• Trop grand nombre de connexions réseau actives
• Utilisation élevée du processeur du nœud principal
• Problèmes de connexion côté client

Résolution

Accès restreint à une adresse IP ou un bloc CIDR particulier

Vérifiez si l’accès à une adresse IP ou à un bloc d’adresses CIDR en particulier est restreint dans votre groupe de sécurité. En raison de la configuration DHCP, l’adresse IP de votre client peut changer et entraîner des problèmes de connectivité. De plus, si vous n’utilisez pas d’adresses IP élastiques pour votre cluster Amazon Redshift, l’adresse IP gérée par AWS des nœuds de votre cluster peut changer. Par exemple, votre adresse IP peut changer lorsque vous supprimez un cluster et que vous le recréez à partir d’un instantané ou lorsque vous reprenez un cluster interrompu.

Remarque : Les adresses IP publiques font l’objet d’une rotation lorsque le cluster Amazon Redshift est supprimé puis recréé. Les adresses IP privées changent chaque fois que des nœuds sont remplacés.

Pour résoudre les éventuelles restrictions de réseau, effectuez l’une des actions suivantes :

• Si votre application met en cache l’adresse IP publique située derrière un point de terminaison de cluster, utilisez ce point de terminaison pour votre connexion Amazon Redshift. Pour garantir la stabilité et la sécurité de votre connexion réseau, n’utilisez pas de cache DNS pour votre connexion.
• Il est recommandé d’utiliser une adresse IP élastique pour votre cluster Amazon Redshift. Une adresse IP élastique vous permet de modifier votre configuration sous-jacente sans affecter l’adresse IP avec laquelle les clients se connectent à votre cluster. Cette approche est utile si vous souhaitez restaurer un cluster après une panne. Pour plus d’informations, consultez la section Gestion des clusters dans un VPC.
• Si vous vous connectez à un nœud principal ou à un nœud de calcul à l’aide d’une adresse IP privée, utilisez la nouvelle adresse IP dans vos paramètres. Par exemple, si vous avez effectué une ingestion SSH ou si votre configuration Amazon EMR utilise le nœud de calcul, mettez à jour votre adresse IP. Après le remplacement d’un nœud, le nouveau nœud se voit attribuer une nouvelle adresse IP privée.

Mises à jour des fenêtres de maintenance

Vérifiez la fenêtre de maintenance de votre cluster Amazon Redshift. Pendant une fenêtre de maintenance, un cluster Amazon Redshift ne peut pas traiter les opérations de lecture ou d’écriture. Si un événement de maintenance est prévu pour une semaine spécifique, il démarre pendant la fenêtre de maintenance de 30 minutes attribuée. Lorsqu’Amazon Redshift effectue une maintenance, toutes les requêtes et autres opérations en cours sont interrompues. Vous pouvez modifier la fenêtre de maintenance planifiée depuis la console Amazon Redshift.

Défaillances des nœuds ou tâches d’administration planifiées

Dans la console Amazon Redshift, consultez l’onglet Événements pour détecter toute défaillance de nœud ou toute tâche d’administration planifiée, telle qu’un redimensionnement ou un redémarrage de cluster.

En cas de panne matérielle, Amazon Redshift peut être indisponible pendant une courte période et les requêtes peuvent ne pas aboutir. Lorsqu’une requête échoue, une description des événements s’affiche, telle que la suivante :

« Un problème matériel a été détecté sur le cluster Amazon Redshift [nom du cluster]. Une demande de remplacement a été initiée à [heure]. »

Ou, si un administrateur de compte a planifié une opération de redémarrage ou de redimensionnement de votre cluster Amazon Redshift, des problèmes de connectivité intermittente peuvent survenir. Une description des événements similaire à la suivante s’affiche :

« Le cluster [nom du cluster] a commencé à redémarrer à [heure]. »« Le cluster [nom du cluster] a terminé le redémarrage à [heure]. »

Pour plus d’informations, consultez les catégories d’événements et les messages Amazon Redshift.

Rotations des clés de chiffrement

Vérifiez les paramètres de gestion des clés de votre cluster Amazon Redshift pour déterminer si vous utilisez le chiffrement des clés AWS Key Management Service (AWS KMS) et la rotation du chiffrement des clés.

Si votre clé de chiffrement est activée et qu’elle fait l’objet d’une rotation, cela signifie que votre cluster Amazon Redshift n’est pas disponible pendant cette période. Si vous recevez alors le message d’erreur suivant :

« pg_query() : La requête a échoué : Erreur SSL SYSCALL : EOF détecté »

La fréquence de rotation de vos clés dépend des stratégies et des normes de votre environnement en matière de sécurité des données. Procédez à une rotation des clés aussi souvent que nécessaire ou chaque fois que la clé chiffrée est susceptible d’être compromise. Assurez-vous également de disposer d’un plan de gestion des clés qui répond à vos besoins en matière de sécurité et de disponibilité.

Trop grand nombre de connexions actives

Dans Amazon Redshift, toutes les connexions à votre cluster sont envoyées au nœud principal, mais il existe une limite maximale pour les connexions actives. Le type de nœud détermine le quota maximal que votre cluster Amazon Redshift peut prendre en charge et non le nombre de nœuds.

Lorsqu’il y a un trop grand nombre de connexions actives dans votre cluster Amazon Redshift, le message d’erreur suivant s’affiche :

« [Amazon](500310) Opération non valide : limite de « 500 » connexions dépassée pour les utilisateurs n’utilisant pas Bootstrap »

Si vous recevez l’erreur Opération non valide lorsque vous vous connectez à votre cluster Amazon Redshift, cela signifie que vous avez atteint le quota de connexions. Pour vérifier le nombre de connexions actives de votre cluster, consultez la métrique DatabaseConnections dans Amazon CloudWatch.

Si vous remarquez un pic de connexions à votre base de données, il se peut qu’un certain nombre de connexions soient inactives dans votre cluster Amazon Redshift. Pour vérifier le nombre de connexions inactives, exécutez la requête SQL suivante :

select process, trim(a.user_name) as user_name, a.usesysid, a.starttime,
  datediff(s,a.starttime,sysdate) as session_dur, b.last_end,
 datediff(s,case when b.last_end is not null then b.last_end else
 a.starttime end,sysdate) idle_dur
     FROM
    (select starttime,process,u.usesysid,user_name
     from stv_sessions s, pg_user u
     where
     s.user_name = u.usename
      and u.usesysid>1
and process NOT IN (select pid from stv_inflight where userid>1
 union select pid from stv_recents where status != 'Done' and
  userid>1)
    ) a
     LEFT OUTER JOIN (select
 userid,pid,max(endtime) as last_end from svl_statementtext where
  userid>1 and sequence=0 group by 1,2) b ON a.usesysid = b.userid AND
 a.process = b.pid
    WHERE (b.last_end > a.starttime OR b.last_end is null)
    ORDER BY idle_dur;

Vous obtiendrez une sortie de ce type :

 process | user_name  | usesysid |      starttime      | session_dur | last_end | idle_dur
---------+------------+----------+---------------------+-------------+----------+----------
   14684 | myuser     |      100 | 2020-06-04 07:02:36 |           6 |          |        6
(1 row)

Lorsque les connexions inactives sont identifiées, utilisez la syntaxe de commande suivante pour arrêter la connexion :

select pg_terminate_backend(process);

Vous obtiendrez une sortie de ce type :

pg_terminate_backend ----------------------
                    1
(1 row)

Utilisation élevée du processeur du nœud principal

Tous les clients utilisent un nœud principal pour se connecter à un cluster Amazon Redshift. Une utilisation élevée du processeur du nœud principal peut entraîner des problèmes de connexion intermittente.

Si vous essayez de vous connecter à votre cluster Amazon Redshift et que le nœud principal utilise le processeur de façon excessive, le message d’erreur suivant s’affiche :

« Erreur lors du paramétrage ou de la fermeture de la connexion »

Pour vérifier si le nœud principal atteint un taux d’utilisation élevé du processeur, consultez la métrique CPUUtilization dans Amazon CloudWatch. Pour plus d’informations, consultez la section Métriques Amazon Redshift.

Problèmes de connexion côté client

Vérifiez l’existence d’un problème de connexion entre le client, tel que Workbench/J ou PostgreSQL, et votre cluster Amazon Redshift. Si le client essaie d’envoyer une requête depuis un port qui a été libéré, une réinitialisation de la connexion côté client peut se produire. La réinitialisation de la connexion peut alors entraîner des problèmes de connexion intermittente.

Pour éviter ces problèmes de connexion côté client, prenez l’une des mesures suivantes :

• Utilisez la fonctionnalité keepalive d’Amazon Redshift pour vérifier que la connexion entre le client et le serveur fonctionne correctement. La fonctionnalité keepalive permet également d’empêcher la rupture d’un lien de connexion. Pour vérifier ou configurer les valeurs de keepalive, consultez Modifier les paramètres de délai d’expiration TCP/IP et Modifier les paramètres de délai d’expiration DSN.
• Si les requêtes semblent être en cours d’exécution mais ne répondent plus dans l’outil client SQL, vérifiez l’unité de transition maximale (MTU). Les requêtes peuvent ne pas s’afficher dans Amazon Redshift en raison d’un abandon de paquets. Un abandon de paquets se produit lorsqu’il existe différentes tailles de MTU dans les chemins réseau entre deux hôtes IP. Pour plus d’informations sur la gestion des problèmes d’abandon de paquets, consultez la section Les requêtes semblent ne plus répondre et parfois ne parviennent pas à atteindre le cluster.