Electronique Mag - Le journal de l'électronique.

L’émergence des modèles informatiques en «  nuage » en réponse aux exigences et aux coûts de service des déploiements de réseaux de périphériques de grande taille, soulève des questions sur les caractéristiques des performances des infrastructures « cloud » pour les applications orientées périphériques. Comment ces performances sont-elles mesurées ? Quelles sont les indicateurs de mesure des performances adéquats ? Quels sont les niveaux de performance nécessaires pour les déploiements à très grande échelle ? En l’absence de réponses à ces questions, le succès des décisions relatives au choix de la plate-forme reste en grande partie aléatoire. Cet article présente le contexte et offre un modèle à partir duquel définir et mesurer ce composant stratégique d’une solution d’application de réseau de périphériques.

En 2011, une grande majorité (70 %) des responsables informatiques déclarent qu’ils utilisent déjà, ou ont l’intention d’utiliser au cours des 12 prochains mois, des solutions « cloud ». Marc Benioff, fondateur et PDG de Salesforce.com, auquel le rôle de leader de ce mouvement est souvent attribué, a déclaré que l’affrontement avec les applications d’entreprise était terminé sur le marché des logiciels commerciaux. Selon lui, « la manière dont nous menons notre vie a définitivement changé ». D’autres leaders éminents du secteur des logiciels partagent le sentiment de M. Benioff. Dès 2005, Apple s’est déjà orienté vers les services « cloud » avec iTunes. Cette année-là, lorsqu’on lui a demandé, lors d’une conférence informatique nationale, ce qu’Apple ferait pour soutenir les applications d’entreprise, Steve Jobs a simplement répondu : « Rien ». L’année dernière, Steve Ballmer, le PDG de Microsoft, a annoncé que « 90 % de l’ensemble des activités de R&D de Microsoft s’effectueront sur des solutions « cloud » dès la fin 2011 ». Récemment, Microsoft a lancé sa campagne marketing « To the Cloud » (Migration vers l’informatique en nuage).

Quels sont les moteurs de cette évolution vers les solutions « cloud » ? L’adoption de services « cloud » offre de nombreux avantages, dont le principal est le coût du service. De nombreuses études récentes présentent les économies significatives découlant des services « cloud  ». La virtualisation des ressources informatiques permises par des technologies commercialisées par VMWare, Citrix et d’autres permet de réduire considérablement le coût global du traitement, de la mémoire, du stockage et de l’infrastructure. Le graphique suivant compare coût total de possession/service d’une solution de gestion de périphériques.

Le fond du problème est le suivant :

Le coût des services « cloud » est considérablement inférieur à celui des applications d’entreprise, qui nécessitent également des investissements matériels, en logiciels complémentaires, d’infrastructure et de support opérationnel et informatique continu. Le coût de nombreux services «  cloud » est si faible qu’ils peuvent être fournis sous la forme de services « gratuits » favorisant des modèles commerciaux basés sur les impressions ou le trafic.

Quelles sont les principales fonctionnalités des services « cloud » ?

Lors du développement d’une application reposant sur l’informatique en « nuage », quatre fonctionnalités stratégiques ont un impact positif ou négatif sur l’expérience utilisateur : l’évolutivité, la disponibilité du ser vice, la confidentialité et les performances. Chacun de ces quatre domaines doit répondre à des normes spécifiques, sans quoi leurs avantages seront sévèrement compromis.

Évolutivité - La nature de l’informatique en « nuage », en raison de sa capacité de virtualisation des ressources, est de créer une image abstraite des ressources allouées en fonction des besoins. Lorsque la demande de traitement, de stockage ou de communication évolue, le « cloud » adapte automatiquement et en toute transparence sa configuration par rapport à la demande  ; l’utilisation de logiciels n’est donc pas sujette à des limites techniques ou de licence. Au fur et à mesure des augmentations et des diminutions de la demande, les ressources s’adaptent, de par leur élasticité apparente. Cependant, comme tout ensemble de ressources, aucune d’entre elles n’est infinie. Les développeurs de logiciels doivent donc connaître la portée et le rythme de l’évolutivité du « cloud ».

Disponibilité du service

Les applications, les services Web ou les applications mobiles ont une caractéristique commune : ils sont disponibles à tout moment et de quasiment n’importe où. En raison de ses caractéristiques, la disponibilité de service ou les « heures d’exploitation  » constituent un facteur stratégique. À quelques exceptions près, les prestations de logiciels en tant que service (Software as a Service) reposent sur un modèle de « disponibilité permanente ». Cette exigence commerciale entraîne une exigence de disponibilité de service annuelle totale mesurée en prenant en compte un temps d’indisponibilité non planifié annuel inférieur à 1 %. Les développeurs de logiciels requièrent habituellement une disponibilité des services de 99,9 % à 99,999 % mesurée en fonction d’une valeur absolue de 100 %.

Confidentialité - La sécurité des données est primordiale. La cybersécurité est une association de technologies, de processus et de politiques. Afin d’assurer une sécurité efficace des données confidentielles, le « cloud » doit employer de nombreuses tactiques pour empêcher l’accès non autorisé, détecter les activités non autorisées, répondre aux menaces détectées et évaluer le respect des politiques de sécurité. Plusieurs associations professionnelles et gouvernementales ont développé des normes de cybersécurité. Les développeurs de logiciels exigent habituellement que leur infrastructure « cloud  » certifie le respect d’une ou plusieurs de ces normes. Performances - Bien que ce concept soit généralement bien compris, les performances du « cloud » peuvent être considérées selon plusieurs points de vue. Ce document pour objectif de développer un modèle de méthode pratique de mesure des performances d’une solution «  cloud » pour un type spécifique d’application. À savoir, les applications utilisées dans les réseaux de périphériques ou d’ordinateurs. Les solutions « cloud » ont été popularisées par les applications commerciales et d’entreprise utilisées sur le réseau « populaire » dénommé Internet. Les applications ont toutes des besoins transactionnels différents. L’indicateur de performances d’un type d’application peut s’avérer inadapté à une autre. La section suivante passe en revue des exemples d’exigences transactionnelles différentes pour plusieurs applications.

Comment mesurer les performances de réseaux de périphériques en « cloud » ?

Des types innombrables d’applications réseau pour périphériques ou ordinateurs apparaissent sur le marché. Elles incluent notamment le suivi des ressources mobiles, la mesure des conditions environnementales, la gestion des équipements médicaux et le contrôle à distance des appareils de restauration.

Les solutions de gestion énergétique commencent également à être déployées en masse. L’exemple d’application de gestion énergétique du schéma 2 démontre qu’elle transmet ou lit fréquemment des données à partir d’un réseau domestique comportant plusieurs périphériques. Occasionnellement, ces données déclenchent une action de l’application et le renvoi d’une commande au réseau de périphériques. Dans cet exemple, les lectures sont 100 fois plus nombreuses que les écritures. Le temps de réponse des lectures est mesuré en secondes ou minutes, tandis que la réponse aux commandes envoyées survient dans un délai de 2 à 10 secondes. Les solutions de gestion énergétique et d’autres solutions basées sur un réseau de périphériques sont habituellement connectées à un très grand nombre de périphériques, ce qui entraîne des lectures fréquentes et des écritures occasionnelles. En raison de la fréquence des lectures par rapport aux écritures, le nombre de lectures par périphérique, par seconde, devient la principale mesure des performances. L’indicateur défini est le DPRS (Device Reads Per Second), soit le nombre de lectures de périphériques par seconde (Read : Drips). Les deux variables multipliées pour augmenter le taux de DRPS sont la fréquence des lectures de périphériques et le nombre de périphériques connectés.

Définition d’une lecture de périphériques Tels que précédemment démontré, la définition des transactions n’est pas constante et dépend fortement du type d’application. Il est donc pratique de définir une lecture de périphériques dans le contexte de ce document.

Le graphique ci-dessous affiche les trois types de requêtes ou transactions :

 Transaction - Une requête de lecture ou d’écriture vers un dossier ou une base de données en cache.

 Transaction périphérique - Une requête de lecture ou d’écriture vers un dispositif périphérique via la plateforme.

 Transaction de périphérique - Une requête de lecture ou d’écriture vers un dispositif terminal via la plateforme et le dispositif périphérique.

Le schéma 4 démontre comment la transaction de périphériques doit transiter via la plate-forme et le dispositif périphérique pour produire le retour souhaité. Cela signifie que la transaction de périphérique est, par nature, plus difficile à produire aux taux de réponse souhaités. Cependant, cet exemple repose sur l’hypothèse que l’application initie l’ensemble des transactions. Une autre approche d’obtention du taux DRPS souhaité est d’intégrer, à la plate-forme et/ou au dispositif périphérique, une fonctionnalité initiant les transactions de périphérique indépendamment de l’application, mais anticipant les besoins de cette dernière. Dans l’exemple suivant, le dispositif périphérique extrait des données de périphériques terminales toutes les 5 secondes, puis transmet l’ensemble des données collectées à la plateforme toutes les 10 minutes. L’application lit un fichier agrégé contenant les données provenant du dispositif terminal, par incréments de 5 secondes, toutes les 15 minutes. La distribution de la charge de travail transactionnelle à différents composants du réseau réduit les tâches requises à l’application pour satisfaire à ses exigences de données.

L’exemple d’architecture de messagerie distribuée ci-dessus démontre qu’il est possible d’obtenir la lecture du périphérique de différentes manières, tant que l’application a la possibilité d’interroger la plate-forme et de recevoir des données au taux DRPS souhaité. Rendez-vous sur www.idigi.com pour en savoir plus sur les réseaux de périphériques en « cloud ».