Récepteurs lents dans un système réparti de gestion de données

Un récepteur lent est un noeud de système réparti qui ne peut pas traiter les messages reçus à cause d'une limitation due à la bande passante, à l'UC, aux E/S, ou à une combinaison de ces causes. Dans tous les cas, le récepteur lent, soit ne parvient pas à récupérer les données des tampons de réception, ce qui provoque l'engorgement du réseau, soit ne parvient pas à transmettre les acquittements de niveau application ou protocole qui autorisent l'émetteur à poursuivre la transmission.

Les récepteurs lents provoquent un problème de performance du système réparti. Lorsque TCP ou la multidiffusion sont utilisés, la présence d'un récepteur lent provoque le ralentissement des autres membres du système réparti et, dans les cas extrêmes, l'effondrement complet du débit du système.

Pour les protocoles en mode connecté, tels que TCP, l'émetteur doit copier les données dans les tampons mémoire système et les transmettre individuellement à chaque récepteur. La fonction de transmission (send) ne se termine que lorsque les données ont été déposées dans les tampons système des sockets du récepteur. Si les tampons des sockets du récepteur sont pleins, la fonction send se bloque jusqu'à ce que des tampons deviennent disponibles, ceci ralentit les autres récepteurs qui ne peuvent pas recevoir de messages de la part de cet émetteur car celui-ci est bloqué en émission de messages vers le récepteur lent.

Pour les protocoles en mode non connecté, tels que la multidiffusion fiable, l'émetteur transmet les données vers le réseau de multidiffusion en les copiant une seule fois sur la carte Ethernet et en les transmettant ensuite sur le réseau, avec les paramètres de durée de vie appropriés. L'émetteur n'est pas bloqué par les récepteurs au niveau des tampons réseau.

La fiabilité du protocole est assurée en imposant à l'émetteur de maintenir un tampon de messages émis et en attente de messages ACK issus des récepteurs qui indiquent la bonne réception d'un message particulier. Les tampons des émetteurs deviennent le facteur limitatif lorsque se produisent des retransmissions vers des récepteurs qui ne parviennent pas à prélever assez rapidement les données et qui de ce fait réclament à l'émetteur une retransmission des données perdues. Même dans ce cas, on se rend compte que les émetteurs finissent par consommer du temps UC et des ressources mémoire ce qui tend à ralentir les récepteurs et finit par provoquer l'effondrement du débit du système. Les récepteurs lents sont souvent appelés les récepteurs "crybaby" (bébés pleureurs) dans le jargon réseau.

La possibilité de recevoir et de traiter chaque fragment des données pertinentes est une propriété critique du bon fonctionnement d'un cache réparti. On suppose que les messages reçus sont pertinents pour le récepteur et, afin de maintenir la cohérence du cache, il est essentiel de tenter de traiter les données reçues et d'assurer une cohérence de cache pour l'application consommatrice.

Dans le même temps, ce souhait de recevoir et de traiter chaque message peut se traduire par un système qui fonctionne à la vitesse du consommateur le plus lent - ce qui est clairement une situation que la plupart des applications réparties ne peuvent pas tolérer.

La solution est de définir un degré de cohérence des éléments du cache nécessaire à une application et, ensuite, de fournir une solution qui traite les problèmes de ralentissement des récepteurs. Cependant, avant de regarder les solutions, commençons par examiner les situations qui se traduisent par la présence de récepteurs lent.

Pour chaque message émis d'un émetteur vers un récepteur, l'émetteur met à jour des statistiques sur le temps moyen total de transmission. Lorsque le temps de transmission total commence à montrer une tendance à l'accroissement et franchit un seuil, l'émetteur note ce récepteur comme récepteur lent. Ce type de détection fonctionne bien dans un environnement à communications en mode connecté où l'émetteur et le récepteur partagent une connexion.

Dans les environnements à communication en mode non connecté, l'émetteur doit mettre à jour des statistiques sur le nombre de retransmissions demandées par le récepteur, et lorsque celui-ci franchit un seuil, il marque le récepteur comme récepteur lent.

Une troisième classe de détection de récepteurs lents n'en n'est pas réellement une. En réalité, un récepteur lent, lorsqu'il ne parvient plus à soutenir le rythme du reste du système ou lorsqu'il détecte un usage excessif de sa mémoire par ses applications se déclare lui-même comme récepteur lent, permettant ainsi au reste du système d'adopter une politique préprogrammée pour les récepteurs lents.

Lorsqu'il s'agit des récepteurs lents, il n'y a pas de solutions magiques qui fonctionnent dans toutes les situations (qui fonctionnent bien, en tout cas). Les choix que peut effectuer un système lorsqu'il rencontre un récepteur lent dépendent de la politique de cohérence des données. Ce que cela implique est qu'un noeud a défini certaines attentes en termes de cohérence des données de la part des autres membres du système. Ces attentes jouent un rôle majeur dans la façon dont sera traité le membre une fois qu'il se trouvera en mode récepteur lent.

Le récepteur lent peut choisir d'éliminer des données, d'envoyer des signalements de pertes de données aux applications et de se récupérer si le problème n'était que temporaire. Cela implique que les mises à jour parvenant au système ne requièrent pas un traitement dans l'ordre d'arrivée et que si une application a besoin de récupérer une donnée du cache, celle-ci sera récupérée des autres noeuds à la demande.

Le récepteur lent peut transmettre une notification aux autres noeuds, signalant qu'il n'est plus en mesure d'accepter de données jusqu'à nouvel ordre. Les noeuds restants ignoreront alors le membre jusqu'à réception d'une notification indiquant que le membre est à nouveau prêt à traiter les demandes. Des échecs de cache sur les autres noeuds ne seront pas transmises à ce noeud et les données du récepteur lent seront considérées comme suspectes par le reste du système, bien que le cache local sur le récepteur lent continue à assurer un service aux applications et aux clients qui lui sont reliés.

Le système peut mettre le récepteur lent en quarantaine, isolant ainsi le reste du système des effets néfastes du récepteur lent. Les émetteurs peuvent avoir à traiter, stocker et transmettre des modèles pour mises à jour vers ce récepteur lent. Appliquer des mises à jour imbriquées issues d'éditeurs multiples pourrait constituer un problème dans un système où les éditeurs sont tous considérés comme égaux. Dans un système à éditeur unique pour une information donnée, cela fonctionnerait bien.

Une autre possibilité est d'utiliser la notion de propriété de donnée. Cela permet au récepteur lent d'appliquer des mises à jour provenant du propriètaire de la donnée sans se préoccuper des mises à jour reçues des autres noeuds.

Une possibilité moins souhaitable est que le système ne fasse rien et fonctionne à la vitesse du récepteur lent. Si le problème est temporaire, le récepteur lent sort de ce mode et la performance du système s'améliore.

Ainsi, les possibilités de traitement des récepteurs lents se résument à celles-ci :

Dans la section précèdente, nous avons considéré le scénario d'un problème dans un système de gestion de données. Une fabrique de données d'entreprise (FDE) fournit des mécanismes pour la détection de récepteurs lents dans un système réparti par recensement de statistiques sur l'activité réseau du système; de plus, comme la FDE est une plateforme active de gestion de données, elle peut être configurée pour prendre des décisions en temps réel. Ces décisions peuvent être basées sur les applications qui se partagent les données au sein de la fabrique de données et sur le besoin de cohérence des données traitées par de multiples applications. Elle peut aussi être basée sur les rôles joués par les diffèrentes applications dans la fabrique de données et sur la criticité de l'acheminement de données aux applications dans le cas d'un comportement de type récepteur lent du système.

Un système réparti de gestion de données est une entité complexe et son déploiement dans un environnement de production requiert une planification et une analyse minutieuses. Comme nous avons affaire à des données datées et à de la cohérence de données, il est important d'avoir une bonne compréhension de l'environnement réseau dans lequel fonctionne l'application.

Tout système réparti doit posséder des règles de gestion des récepteurs lents. Ces règles doivent être élaborées en gardant à l'esprit les caractéristiques de charge du système, les garanties de cohérence des données, les notifications de pertes de données et les besoins en débit du système. Le réglage du réseau pour atteindre les objectifs du système, en incluant le débit et le retard doivent faire partie de la conception d'ensemble du système lorsqu'on envisage le déploiement d'une fabrique de données d'entreprise.

Une planification dès le départ pour s'assurer que les ressources matèrielles telles que la bande passante du réseau, le partitionnement du réseau, l'UC, la mémoire, et les caractéristiques E/S des noeuds faisant partie du réseau réparti, sera un réel atout pour éviter des ralentissements inutiles et des perturbations de la performance globale du système. Il est également important de comprendre les caractéristiques de congestion du réseau pour s'assurer que le système dans son ensemble est équipé pour gérer des pointes de trafic et des indisponibilités temporaires. Prévoir une redondance du système, l'utilisation des disques et le nombres d'applications ou d'exemplaires qui entrent en compétition pour les ressources du système sont des facteurs qui aident à éviter des problèmes de récepteurs lents et qui se traduisent par des systèmes au fonctionnement plus fluide.

Une bonne idée est également de demander au fournisseur du système réparti de gestion des données quelles sont ses offres en matière de récepteurs lents. En ce qui concerne la gestion des récepteurs lents dans une fabrique de données répartie, la question n'est pas « si », mais « quand ».