Pourquoi suis-je confronté à des problèmes de connectivité intermittents avec mon cluster Amazon Redshift ?

Brève description

Les problèmes de connectivité intermittents dans votre cluster Amazon Redshift sont causés par les éléments suivants :

• Accès restreint pour une adresse IP particulière ou un bloc d’adresse CIDR
• Fenêtre de mises à jour de maintenance
• Échecs de nœud ou tâches d'administration planifiées
• Rotations de clés de chiffrement
• Trop de connexions réseau actives
• Utilisation CPU élevée du processeur du nœud principal
• Problèmes de connexion côté client

Résolution

Accès restreint pour une adresse IP particulière ou un bloc d’adresse CIDR

Vérifiez s'il existe un accès restreint pour une adresse IP ou un bloc d’adresse CIDR particulier dans votre groupe de sécurité. En raison de la configuration DHCP, l'adresse IP de votre client peut changer, ce qui peut causer des problèmes de connectivité. En outre, si vous n'utilisez pas d'adresses IP Elastic pour votre cluster Amazon Redshift, l'IP gérée par AWS de vos nœuds de cluster peut changer. Par exemple, votre adresse IP peut changer lorsque vous supprimez votre cluster, puis que vous le recréez à partir d'un instantané, ou lorsque vous reprenez un cluster mis en pause.

Remarque : Les adresses IP publiques sont tournées lorsque le cluster Amazon Redshift est supprimé et recréé. Les adresses IP privées changent chaque fois que les nœuds sont remplacés.

Pour résoudre les restrictions réseau, envisagez les approches suivantes :

• Si votre application met en cache l'adresse IP publique derrière un point de terminaison de cluster, veillez à utiliser ce point de terminaison pour votre connexion Amazon Redshift. Pour garantir la stabilité et la sécurité de votre connexion réseau, évitez d'utiliser un cache DNS pour votre connexion.
• Il est recommandé d'utiliser une adresse IP Elastic pour votre cluster Amazon Redshift. Une adresse IP Elastic vous permet de modifier votre configuration sous-jacente sans affecter l'adresse IP utilisée par les clients pour se connecter à votre cluster. Cette approche est utile si vous récupérez un cluster après une défaillance. Pour plus d'informations, consultez la section Gestion des clusters dans un VPC.
• Si vous utilisez une adresse IP privée pour vous connecter à un nœud principal ou à un nœud de calcul, veillez à utiliser la nouvelle adresse IP. Par exemple, si vous avez effectué une ingestion SSH ou si vous avez une configuration Amazon EMR qui utilise le nœud de calcul, mettez à jour vos paramètres avec la nouvelle adresse IP. Une nouvelle adresse IP privée est accordée aux nouveaux nœuds après le remplacement d'un nœud.

Fenêtre de mises à jour de maintenance

Vérifiez la fenêtre de maintenance de votre cluster Amazon Redshift. Au cours d'une fenêtre de maintenance, votre 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 donnée, il commence pendant la fenêtre de maintenance de 30 minutes qui lui a été attribuée. Pendant qu'Amazon Redshift effectue une maintenance, toutes les requêtes ou autres opérations en cours sont arrêtées. Vous pouvez modifier la fenêtre de maintenance planifiée à partir de la console Amazon Redshift.

Échecs de nœud ou tâches d'administration planifiées

Dans la console Amazon Redshift, vérifiez dans l'onglet Événements les échecs de nœud ou les tâches d'administration planifiées (telles qu'un redimensionnement ou un redémarrage de cluster).

En cas de panne matérielle, Amazon Redshift peut ne pas être disponible pendant une courte période, ce qui peut entraîner l'échec des requêtes. Lorsqu'une requête échoue, vous voyez une description des Événements telle que la suivante :

"A hardware issue was detected on Amazon Redshift cluster [cluster name]. A replacement request was initiated at [time]."

Ou, si un administrateur de compte a planifié une opération de redémarrage ou de redimensionnement sur votre cluster Amazon Redshift, des problèmes de connectivité intermittents peuvent se produire. La description de vos Événements indique alors ce qui suit :

"Cluster [cluster name] began restart at [time]."
"Cluster [cluster name] completed restart at [time]."

Pour plus d'informations, consultez la section Catégories et messages d'événements Amazon Redshift.

Rotations de clés de chiffrement

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

Si votre clé de chiffrement est activée et que la clé de chiffrement est en cours de rotation, votre cluster Amazon Redshift n'est pas disponible pendant cette période. Par conséquent, vous recevez le message d'erreur suivant :

"pg_query(): Query failed: SSL SYSCALL error: EOF detected"

La fréquence de la rotation de vos clés dépend des politiques de votre environnement en matière de sécurité des données et des standards. Faites pivoter les clés aussi souvent que nécessaire ou chaque fois que la clé cryptée risque d'être compromise. Assurez-vous également de disposer d'un plan de gestion des clés qui réponde à la fois à vos besoins en matière de sécurité et de disponibilité des clusters.

Trop de connexions actives

Dans Amazon Redshift, toutes les connexions à votre cluster sont envoyées au nœud principal, et il y a une limite maximale pour les connexions actives. La limite maximale que votre cluster Amazon Redshift peut prendre en charge est déterminée par type de nœud (au lieu du nombre de nœuds).

Lorsqu'il y a trop de connexions actives dans votre cluster Amazon Redshift, vous recevez l'erreur suivante :

"[Amazon](500310) Invalid operation: connection limit "500" exceeded for non-bootstrap users"

Si vous recevez une erreur d' opération non valide lors de la connexion à votre cluster Amazon Redshift, cela indique que vous avez atteint la limite de connexion. Vous pouvez vérifier le nombre de connexions actives pour votre cluster en regardant la métrique DatabaseConnections dans Amazon CloudWatch.

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

select 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;

La sortie ressemble à cet exemple :

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, la connexion peut être arrêtée à l'aide de la syntaxe de commande suivante :

select pg_terminate_backend(process);

La sortie ressemble à cet exemple :

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

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

Tous les clients se connectent à un cluster Amazon Redshift à l'aide d'un nœud principal. L’utilisation CPU élevée du processeur du nœud principal peut entraîner des problèmes de connexion intermittents.

Si vous essayez de vous connecter à votre cluster Amazon Redshift et que le nœud principal utilise beaucoup le CPU, vous recevez le message d'erreur suivant :

"Error setting/closing connection"

Pour confirmer si votre nœud principal a atteint une utilisation élevée du CPU, vérifiez la métrique Utilisation du CPU dans Amazon CloudWatch. Pour plus d'informations, consultez la section Métriques d'Amazon Redshift.

Problèmes de connexion côté client

Recherchez un problème de connexion entre le client (tel que Workbench/J ou PostgreSQL) et le serveur (votre cluster Amazon Redshift). Une réinitialisation de la connexion côté client peut se produire si votre client tente d'envoyer une demande à partir d'un port qui a été libéré. Par conséquent, la réinitialisation de la connexion peut causer des problèmes de connexion intermittents.

Pour éviter ces problèmes de connexion côté client, considérez les approches suivantes :

• Utilisez la fonctionnalité keepalive d'Amazon Redshift pour vérifier que la connexion entre le client et le serveur fonctionne correctement. La fonction keepalive permet également d'éviter que les liens de connexion ne soient rompus. Pour vérifier ou configurer les valeurs de keepalive, consultez les sections Modifier les paramètres de délai d'expiration TCP/IP et Modifier les paramètres de délai d'expiration DSN.
• Vérifiez l'unité de transition maximale (MTU) si vos requêtes semblent être en cours d'exécution mais se bloquent dans l'outil client SQL. Parfois, les requêtes n'apparaissent pas dans Amazon Redshift en raison d'une perte de paquet. Une perte de paquet 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 façon de gérer les problèmes de perte de paquets, consultez la section Les requêtes semblent se bloquer et parfois ne parviennent pas à atteindre le cluster.

</ul

---