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

Gazette Linux n°144 — Novembre 2007

Article paru dans le n°144 de la Gazette Linux de novembre 2007.

Traduction française par Alain Boulé. .

Relecture de la traduction française par Deny .

Article publié sous Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.


Table des matières

Les récepteurs lents expliqués
récepteurs lents et cohérence de cache
Détection d'un récepteur lent
Traitement des récepteurs lents
Traitement de récepteur lent dans une fabrique de données d'entreprise
Conclusion

Les récepteurs lents expliqués

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.

récepteurs lents et cohérence de cache

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.

  • récepteur lent de naissance — Considérons un système composé de 16 serveurs et d'un ordinateur de bureau qui doit recevoir des données de la part d'un ou de plusieurs serveurs. Si l'ordinateur de bureau est configuré comme pair, il est clair que son UC devra être capable de supporter le flot des messages en provenance des serveurs. Après un certain temps (environ deux secondes pour de tels systèmes), les tampons des sockets des applications de l'ordinateur de bureau se remplissent, ce qui provoque la paralysie des serveurs de publication, bien qu'il existe par ailleurs des serveurs consommateurs qui sont capables de supporter le rythme de publication.

  • Dégradation progressive en une réception ralentie — Dans ce système, tous les noeuds sont égaux au départ. Les niveaux d'activité des diffèrents noeuds ont cependant tendance à varier et l'un des noeuds finit par devoir traiter un problème de fragmentation de tas ou de libération de mémoire, ou alors un de ses threads finit par surchauffer. Dans ce type de système, le déclin de performance est graduel et il se passe plus de temps avant que ses effets ne se manifestent pour le reste du système - mais le résultat final est le même, de toutes façons.

  • Applications mal programmées — Cette catégorie de récepteurs lents posséde en génèral deux composants  le composant qui récupère les données des tampons des sockets et les transmet pour traitement et le composant qui réalise le véritable traitement. Le premier peut fonctionner correctement alors que le second peut ne pas soutenir le rythme. Ce type de récepteur lent meurt en génèral rapidement mais les effets se font sentir plus tard. Si l'application morte est un serveur, les clients dont il traitait les données se rabattent rapidement vers les autres serveurs, ce qui diminue leurs débits.

  • récepteur vivant en milieu hostile — Les applications TCP sont en génèral des conducteurs urbains polis : ils cédent le passage aux autres, roulent à la même vitesse que les autres et ménent génèralement une vie paisible pour ce qui concerne l'utilisation de la bande passante. Lorsqu'une application de multidiffusion investit la localité TCP, à moins que l'application de multidiffusion n'ait été conçue avec un rythme limité par contrôle de groupe, le réseau ressemble subitement aux rues encombrées des grandes villes où la politesse n'est plus la norme. Dans de tels cas, un récepteur TCP, qui était auparavant discipliné, commence à être perdu comme un récepteur lent qui ralentit l'ensemble du système.

Détection d'un récepteur 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.

Traitement des 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 :

  • Mettre le récepteur lent en quarantaine jusqu'à son rétablissement. Enregistrer et transmettre les messages vers des mécanismes à base de disques et laisser fonctionner le récepteur lent.

  • Le récepteur lent élimine les messages, récupère le rythme et transmet les notifications appropriées aux applications et clients connectés.

  • Alerter l'administrateur du système à propos du récepteur lent de façon à ce qu'une action correctrice soit mise en place.

  • Eliminer les messages destinés aux récepteurs lents et les laisser fonctionner tout en avertissant les administrateurs système.

Traitement de récepteur lent dans une fabrique de données d'entreprise

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.

Conclusion

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 ».

Sudhir Menon, Directeur de l'ingénierie, Gemstone systems

Avec plus de 17 années d'expèrience en logiciel de pointe pour des entreprises prestigieuses comme Gemstone, Intel, EDS et CenterSpan communications, Sudhir Menon est l'un des architectes clés de la Fabrique de données Gemfire. Sudhir est le directeur de l'ingènierie de Gemstone systems, Inc; il collabore étroitement avec diverses équipes de développement (locales ou offshore) qui travaillent sur la fabrique de données Gemfire. Son expertise dans la gestion de données réparties s'étend à plusieurs langages (Java, C++ et .NET) et à de multiples plateformes; il a défini l'architecture et réalisé le développement de piles de protocole depuis plus de 10 ans. A CenterSpan communications il a été l'un des architectes clés ayant réalisé la plus grande plateforme sécurisée de distribution de contenu en pair à pair sur Internet.

Adaptation française de la Gazette Linux

L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.

Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://wiki.traduc.org/Gazette_Linux.

Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.