Tribunes

SLA Applicatifs : Une nouvelle manne pour les fournisseurs de services ?

SLA Applicatifs : Une nouvelle manne pour les fournisseurs de services ?

PublicitéLes entreprises veulent aujourd'hui avoir la garantie que leurs applications leur offriront en permanence un niveau de performance optimal. Or comme bon nombre de ces applications métier sont déployées sur un réseau WAN, celui-ci joue un rôle clé pour répondre à cette exigence. Les fournisseurs de services doivent donc offrir un certain nombre de garanties quant aux performances des applications en réseau. Les contrats de service ou SLAs (Service Level Agreements) conclus entre les fournisseurs de services et leurs clients ont pour but de garantir les performances applicatives en réseau. Mais en général ces SLAs ne sont pas liés directement aux performances des applications critiques. Ainsi il peut arriver qu'un service réseau respecte en tout point le SLA alors même que l'entreprise souffre d'une mauvaise performance sur un module SAP important en raison de problèmes réseau. Les entreprises exigent de plus en plus des fournisseurs de services qu'ils leur assurent des prestations avec le plus haut niveau de qualité et de fiabilité. Alors qu'elles continuent à déployer des applications sur des réseaux WAN MPLS, elles se préoccupent de plus en plus de la performance de ces applications, en particulier celles qui ont un caractère critique pour leur métier. Les SLAs réseau traditionnels proposés aux entreprises par un grand nombre de fournisseurs de services de VPN sur IP présentent des limites qui tiennent principalement à la nature des indicateurs sur lesquels ils reposent et sur la façon de mesurer ces indicateurs. Les indicateurs utilisés dans le cadre de ces SLAs sont en général le délai de transit ou le pourcentage de paquets perdus sur les liens. Ils sont mesurés d'un routeur à l'autre via l'utilisation d'outils de type « ping » ou en faisant appel à des sondes Cisco Service Assurance Agent (SAA). Ces méthodes posent l'une comme l'autre trois problèmes : 1. Les SLAs qui en résultent ne traduisent pas la performance des applications mais uniquement celles des liens eux-mêmes. 2. Les SLAs ne traduisent pas les performances de LAN à LAN. La méthode ping ou SAA utilisée la plupart du temps entre les routeurs CPE du réseau ou des routeurs shadow ne prend pas pleinement en compte les problèmes de congestion dans l'entreprise. 3. Ces SLAs ne donnent qu'une estimation de la performance dans la mesure où les outils de ping et SAA reposent sur une simulation périodique du trafic. Les SLAs obtenus par les ping et SAA ne sont au final en rien le reflet de ce qui se passe réellement sur le terrain pour l'utilisateur final des applications WAN. Chaque SLA applicatif doit réunir les éléments suivants : 1. Un indicateur 2. Les seuils de cet indicateur (les objectifs) 3. Les règles de validité de cet indicateur A ces trois éléments doit bien entendu s'ajouter la technologie qui délivre concrètement le SLA. Comment choisir son indicateur ? Dans le cas d'un SLA applicatif, il faut choisir un indicateur qui soit représentatif des trois éléments suivants :  L'application  Les performances de LAN à LAN  Le niveau réel de la performance délivrée par le fournisseur Les seules métriques de base qui répondent à ces trois critères sont les métriques de flux unidirectionnelles et calculées de LAN à LAN pour le débit, le délai, la perte de paquets et la gigue. Cependant elles risquent d'être trop nombreuses et trop techniques pour être prises en charge dans le cadre d'un SLA applicatif. Quel que soit le SLA, il vaut mieux que le nombre d'indicateurs à manipuler soit le plus petit possible voire dans l'idéal limité à un seul. Pour la voix sur IP (VoIP), l'Union Internationale des Télécommunications (UIT) propose un modèle appelé modèle E qui permet aux fournisseurs de services de convertir les mesures unidirectionnelles en un score unique : le MOS (Mean Opinion Score). Celui-ci a été créé à l'origine afin d'évaluer la qualité d'expérience de la voix à partir de tests subjectifs. Les utilisateurs passaient des appels et notaient la qualité du son sur une échelle de 1 à 5. Avec l'avènement de la voix sur IP, l'UIT a par la suite proposé le modèle E qui prend en compte les métriques telles que le délai, les pertes de paquets, la gigue et le CODEC (codage-décodage) utilisé pour calculer un facteur intermédiaire, le facteur R (Rating) et en déduire directement une valeur MOS. Le besoin d'un équivalent du MOS pour toutes les applications et les limites de l'APDEX sont les raisons qui ont incité Ipanema à créer l'indicateur Application Quality ScoreTM ou AQS pour mesurer les performances des applications autres que la VoIP. Cet indicateur repose sur les mêmes principes que le modèle E. Il convertit les métriques de base du flux applicatif (débit, délai, perte et gigue) en un score plus représentatif, selon un modèle propriétaire. Ce modèle repose sur la comparaison des multiples caractéristiques du flux applicatif avec des seuils tirés d'une bibliothèque prédéfinie. Quels sont les seuils à définir ? La façon la plus simple de définir les seuils d'un SLA applicatif consiste à établir un rapprochement entre la disponibilité du réseau et celle des applications. Une entreprise peut considérer qu'une application est disponible tant que le service réseau est en mesure de la délivrer avec les ressources appropriées pendant une période donnée. La garantie de respect du SLA peut être délivrée pour tout le réseau ou pour chaque site. La deuxième solution est plus forte car lorsque la garantie porte sur l'ensemble du réseau, elle peut occulter des écarts mineurs par rapport au SLA d'un site donné. Il importe également de tenir compte du fait que le réseau étant partagé par un grand nombre d'applications, la notion de SLAs applicatif doit être réservée aux applications critiques uniquement et être associée à d'autres mécanismes permettant aux entreprises d'allouer en priorité les ressources réseau aux utilisateurs de ces applications. Par souci de simplicité, il est bon de regrouper dans un même SLA les applications ayant le même niveau de criticité. On définira par exemple un SLA applicatif pour les applications ayant une criticité « Top » et un autre pour celles ayant une criticité « High ». Les règles de validité des indicateurs, un facteur essentiel Les règles de validité des indicateurs définissent les circonstances dans lesquelles le fournisseur de service sera en mesure de garantir le respect du SLA applicatif. Fixer des règles de validité des indicateurs est une étape essentielle car les ressources réseau telles que la bande passante sont limitées. Aujourd'hui, dans la grande majorité des cas, la connectivité réseau d'un site est définie par la taille de son accès au WAN. La règle de validité la plus basique d'un SLA applicatif est tout simplement qu'il ne peut être respecté pendant les périodes où les utilisateurs des applications concernées ont besoin de plus de ressources réseau que ce qui a été prévu pour le site par l'entreprise. Il y a plusieurs façons de définir ces périodes. La première consiste à définir un nombre maximum d'utilisateurs simultanés pour chaque application ou groupe d'applications couvert par le SLA. Si la portion de bande passante correspondante est dépassée, le fournisseur de service ne peut garantir un niveau de qualité de service acceptable pour l'utilisateur final. Ipanema propose d'adopter la notion de « suractivité » pour définir avec extrême précision les cas où les utilisateurs des applications critiques demandent plus au réseau que ce qu'il ne peut fournir. La suractivité analyse à la fois :  ce que demandent les utilisateurs,  ce dont ils ont besoin,  ce que le réseau est en mesure de leur fournir. La suractivité peut être calculée en temps réel et alimenter ensuite les processus de reporting et de maintenance du SLA. Quels sont les avantages de la mise en place d'une plate-forme de mesure et de maîtrise des SLAs applicatifs ? Afin de combler le vide existant entre les priorités business et leur infrastructure réseau, les entreprises souhaitent bénéficier d'une solution qui gère et optimise automatiquement les performances des applications en réseau selon leur niveau de criticité. Les entreprises veulent obtenir des SLAs pertinents portant sur le maillon stratégique de la chaîne d'acheminement des applications que constitue le réseau. C'est pourquoi les fournisseurs de services doivent s'appuyer sur une solution qui leur permette de définir et mesurer des SLAs qui :  sont totalement alignés sur les besoins du client  couvrent clairement et précisément les différents maillons de la chaîne de livraison des applications  traduisent le niveau de qualité d'expérience réellement délivré à l'utilisateur final S'affranchir des limites traditionnelles des SLAs centrés sur le réseau et contrôler individuellement chaque session applicative devient de plus en plus primordial pour les fournisseurs de services. Ils veulent pouvoir mesurer les performances de chaque flux et plus seulement celles de la liaison, utiliser des mécanismes qui considèrent la performance au-delà du WAN et mesurer le trafic réel pour chaque utilisateur au lieu de procéder à des simulations. Les fonctionnalités de mesure et de maîtrise des SLAs applicatifs basées sur une technologie d'optimisation du trafic permettent aux fournisseurs de services de proposer à leurs clients une nouvelle génération de services centrés sur les applications. Les SLAs applicatifs sont totalement alignés sur les besoins du client et offrent aux fournisseurs de services une opportunité unique de gagner des parts de marché, d'augmenter leur chiffre d'affaires et de doper leurs résultats.

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis

    La question du moment
    Les contraintes de fonctionnement propres à votre entreprise imposent-elles des environnements IT au plus proche des utilisateurs ou des lieux de production ?