Performance d’une application dans un environnement mutualisé

Les précédents articles de la catégorie ont permis de visualiser un certain nombre de cas figures liés aux réseaux (WAN + LAN). Mais les serveurs eux-mêmes sont la cause de différences de performances notables. D’où la nécessité de superviser ces performances, en particulier sur les environnements mutualisés comme les clusters de machines virtuelles. Voici quelques exemples.

 

140519_VM-cluster

Dans cette première illustration, il s’agit d’un serveur applicatif Tomcat, sur une VM Linux. Il est en phase de tests, sans volume d’utilisateur. Sa performance de base en périodes creuses (la nuit, le week-end) se situe aux environs de 300ms. Ce n’est pas excellent mais acceptable si on remarque que ce temps de réponse inclut la négociation HTTPS.

Mais on note aussi les variations de performances durant les « heures ouvertes », avec des temps de réponse dépassant la seconde.

Comme il n’y a pas d’utilisateurs, toutes ces fluctuations sont uniquement dues à la capacité de réponse du cluster qui abrite les VM. A travers cet exemple, on voit clairement que virtualiser un datacenter conduit naturellement à la supervision des performances, fait bien connu des hébergeurs d’environnements mutualisés.

140516_2vCPU

Ce suivi contribue également à dimensionner ces VM, comme le montre ce nouvel exemple. Il s’agit d’une autre application dont les temps de réponse initiaux ne sont pas bons, à la fois parce qu’ils sont longs mais aussi parce qu’ils varient significativement. Ajouter un vCPU de plus dans les paramètres de la machine virtuelle apporte des temps de réponse nettement plus stables.

Publié dans Non classé

Un service SaaS qui a du mal à ternir la charge

Nouvel article dans la série : surveillance des réseaux et services

Vous avez choisi de basculer vers une messagerie en mode SaaS. L’offre commerciale était alléchante et les performances bonnes lors de la phase de sourcing. Les mois passent avec les déploiements au siège puis sur site distants. Et les utilisateurs commencent à se plaindre. Le service est « lent », avec rapport de « déconnexion ».

Les sites distants étant les plus bruyants à se plaindre, le réseau est le premier accusé. Pas facile de faire le point.

140425_load-webmail

Graphiques en main, le constat devient plus clair : les autres trafics ne connaissent pas de ralentissements de même nature. Mais ce service est effectivement lent.

Explication : l’offre a rencontré un certain succès et le fournisseur a accumulé les utilisateurs sur les mêmes clusters. Si les performances (ici mesurées depuis le siège) sont excellentes la nuit ( !), dès que les utilisateurs se connectent en nombre, les temps de réponse se détériorent. Il est temps d’avoir une discussion avec le fournisseur.

Publié dans Non classé

Ce service web est lent, ou pas !

Nouvel article dans la série : surveillance des réseaux et services

Quand un utilisateur signale un problème avec un site web, il est toujours facile de lui dire que le problème ne touche que lui. Mais lorsque ce n’est pas le cas, on n’a fait que jeter de lui sur le feu !

Illustrons avec ce nouvel extrait de statistiques. Google (le moteur de recherche) est déjà en soi un bon baromètre des accès Internet. Mais lorsqu’on voit vers 9h50, que tous les temps de réponse de Google, Salesforce et Webex s’envolent tous, on peut facilement répondre à un utilisateur que son problème n’était pas unique.

Selon le cas, il reste à investiguer (en croisant avec d’autres indicateurs) quelle est la cause de ce ralentissement (proxy, lien d’accès). A suivre dans d’autres épisodes

140331_internet-access-events

Publié dans Non classé

SLA « 100% »

Nouvel article dans la série : surveillance des réseaux et services

Dans les négociations commerciales, il y a toujours un décalage certain entre le discours des brochures

  • « Datacenter Tier-3 »
  • « architecture hautement redondante »
  • Etc.

Et le moment des engagements sur les chiffres de disponibilité, SLA et éventuellement pénalités.

Le problème est foncièrement difficile parce que :

  • Le client Entreprise n’a pas toujours de surveillance en propre
  • Les causes hardware sont rarement celles qui dominent comme le rappelle ce rapport du PTS , l’équivalent suédois de l’ARCEP autorité de régulation des télécoms (pour ceux qui lisent l’anglais mieux que le suédois, les causes sont par ordre décroissant 1. Software, 2. Overload, 3. Cable cut, 4. Hardware, 5. Power/electricity)
  • outre les gros incidents, francs et nets, il y a une myriade de micro-coupures d’origine diverses et souvent « logicielles », des reconfigurations.

140424_restart

Ce cas est illustré avec une cible de surveillance interne sur notre site web. Suite à une attaque de notre site, une règle un peu stricte d’autoprotection empêchait certaines fonctions (envoi de CV). Résultat : il a fallu redémarrer le proxy/WAF (apache/mod-security pour être précis), en pleine journée !

Evidemment le baromètre automatisé de suivi ne loupe rien… comme les utilisateurs.

Publié dans Non classé

DDoS sur un service SaaS

Nouvel article dans la série : surveillance des réseaux et services

Rien de tel que des exemples pour illustrer ce qu’apporte un système de suivi des performances comme celui que nous préparons [annonce]. Premier exemple, le fournisseur SaaS qui subit une attaque DDoS.

140404-DoS

Comme souvent cela démarre un lundi matin. Les performances de bases sont déjà moyennes (temps de réponse supérieur à 0,5s car le service est hébergé aux US, et utilise https ce qui ralentit la latence à première connexion) mais les accès deviennent franchement lents ( >1s ) et surtout un certain nombre de requêtes ne trouvent pas de réponse. Rapidement le blog du fournisseur fait état d’une attaque par déni de service, attaque avec demande de rançon. Pour ne pas céder à ce chantage, il décide publiquement de ne pas céder (au prix d’une souffrance des utilisateurs pendant quelques jours).

Le bras de fer durera une semaine avant que la situation redeviendra complètement normale.

Intérêt de la surveillance continue : obliger chaque acteur à la transparence, à savoir rapidement si vous êtes les seuls touchés.

Publié dans Non classé

Quelle est la qualité des réseaux dans vos agences et sites distants ?

Comme conseil spécialisé, nous sommes appelés à étudier & architecturer des réseaux IP, quotidiennement. Et certains constats se répètent.

  • Lorsqu’on interroge les utilisateurs, particulièrement sur sites distants ou en agences, ils se plaignent de lenteurs.
  • Lorsqu’on interviewe les administrateurs réseaux, ils montrent des graphes d’utilisations des liens. Parfois ils grommellent : si les tuyaux n’étaient pas remplis de flux YouTube, il y aurait moins d’incidents ; c’est par manque de budget si les liens sont insuffisamment dimensionnés…

Le problème est qu’il n’est pas facile de faire un lien entre les graphes et les plaintes. Le taux de remplissage est un mauvais indicateur parce qu’on se heurte facilement à des contre-exemples.

  • lorsque la QoS (DSCP) est correctement mise en œuvre (un gros si, il faut en convenir), la ToIP traverse sans peine un WAN, même saturé à ses accès.
  • inversement, si le tri entre flux n’est pas fait, ou l’application sur-réagit à de légers « défauts » du réseau (ils sont en partie intrinsèques puisque TCP détecte la saturation par les pertes de paquets, rappelons-le), on peut avoir des lenteurs majeures pour les utilisateurs avec des tuyaux peu remplis.
  • et pour finir, les lenteurs qu’on attribue au « réseau » – cet « éther » de l’informatique –  sont aussi causées par des limites des serveurs (processeurs, disques), des protocoles (verrous de base de données, non-streamlining des requêtes), voire des postes client (c’est incroyable comment on peut « accélérer » le réseau en remplaçant des PC équipés de disques durs traditionnels, par des PC équipés de SSD !). Il s’ensuit donc un jeu de ping-pong de responsabilité entre équipes ou prestataires qui pourrait être drôle si les utilisateurs n’attendaient pas…

Pour éviter que les redimensionnements se pratiquent par crise, pour que les budgets se mobilisent (ou inversement ne se consument pas en sur-capacité pour rien, car c’est le versant le moins visible de la difficulté de dimensionner sans points de repère), il faut apporter des éléments factuels des performances observées depuis les sites distants. Techniquement des mesures de la latence des services.

Sur le papier, les capacités de métrologie ne manquent pas. Par exemple, les routeurs Cisco peuvent être activés comme sondes de tests. Les fonctions IP-SLA permettent de lancer des requêtes http depuis un site distant, des ping marqués DSCP, de mesure la gigue, etc. Mais je pense que si Cisco avait les moyens comme Microsoft avec Office de mesurer le taux d’usage par fonction embarquée, on ferait le constat qu’IP-SLA est mis en œuvre sur moins de 1% du parc.

Les PC aussi peuvent servir de sonde, comme nous l’avons fait en 2011 avec des scripts mais les déploiements sont malaisés :

  • Les laptops changement de point de connexion avec les réseaux, même les desktops ne sont pas allumés en permanence
  • Les utilisateurs n’ont pas envie d’avoir un agent de plus qui consomme CPU, mémoire, etc.
  • Windows remet à zéro les champs DSCP
  • Etc.

Nous avons donc essayé de réfléchir à un dispositif alternatif pour répondre simplement à ces questions simples :

  • Quelles sont les temps de réponse effectifs depuis mes sites distants pour mes principaux services réseaux ?
  • Est-ce le réseau qui est lent, les systèmes (serveurs, PC) ou mon fournisseur SaaS ?
  • Puis-je avoir un suivi sur la durée, car les problèmes difficiles sont intermittents et les retours utilisateurs ne sont pas immédiats ?

Pour ne pas connaître un aussi faible usage que les moyens précédents, l’idée est de faire aussi simple que le déploiement des box opérateurs. Avec des millions de clients, ils sont devenus extrêmement rodés :

  1. Demande de livraison d’un boîtier sur site et configuration de quelques éléments spécifiques de configuration sur un portail web
  2. A l’arrivée du boitier, connexion plug-and-play sur une prise LAN RJ45 et une prise électrique

Le portail permet ensuite le suivi via graphes et alertes sur performances.

Nous en sommes actuellement à l’état de quelques prototypes. Nous envisageons d’ouvrir une première expérimentation opérationnelle de services en juin et vous tiendrons informé sur ce blog. En attendant, vous pouvez nous contacter si vous voulez influencer le développement, nous indiquer quel serait le coût à ne pas dépasser ou toute autre remarque.

A bientôt.

Publié dans Non classé

Etes vous bien préparés au SPAM

spamLa sécurité d’un système est impactée par le plus faible de ses maillons, nous le savons tous. Alors pourquoi ne prend-on pas plus au sérieux la sécurité des courriels échangés, base de productivité de nombreuses activités des entreprises aujourd’hui ?

Le courriel, que nous utilisons tous les jours pour nos usages aussi bien professionnels que personnels, est un outil indispensable. Même s’il véhicule un grand nombre de messages futiles ou pas du tout adaptés à ce type de transport, la messagerie se doit de fonctionner en permanence. Nous avons notre client de messagerie ouvert sur notre écran d’ordinateur et, lorsque nous ne sommes pas devant ce dernier, le smartphone prend le relais. C’est ainsi. Alors pourquoi les entreprises n’investissent-elles pas un peu plus dans ce service ? La sécurisation de l’infrastructure est maîtrisée, le mail fonctionne la plupart du temps, mais la gestion de la sécurisation de l’acheminement n’est pas un sujet très commun dans les DSI et c’est bien dommage. Lire la suite

Publié dans Non classé

Une première dans les salles de marchés

stock_trading_screens_277277_h

Cela fait maintenant une bonne dizaine d’année que les entreprises migrent petit à petit vers la téléphonie sur IP. Les salles de marché s’y sont mis mais bien plus tard. En effet, les obligations techniques, fonctionnelles et réglementaires spécifiques au métier du trading ont ralenti la donne. On observe depuis quelques années la volonté de ces dernières de passer au tout IP pour se voir offrir de nouveaux services et remplacer les solutions devenues obsolètes.

Lire la suite

Publié dans Non classé

Salesforce se positionne sur les Communications Unifiées

En tant qu’observateur du SaaS et des Communications Unifiées, nous ne pouvons que noter l’acquisition de DimDim, nouvel entrant sur un marché dominé actuellement par WebEx, GotoMeeting et NetViewer (l‘acteur allemand lui-même acheté récemment par Citrix, maison mère de GotoMeeting).

Après Chatter, Salesforce semble donc vouloir se positionner sur les outils de collaboration. Un choix stratégique qui va le faire entrer en collision avec Google, mais il est vrai que leurs plateformes de développement Force.com et Google App Engine sont déjà concurrentes.

Après la fermeture des services, on peut donc parier sur une nouvelle poussée d’innovations.

Publié dans Non classé

Les puzzles du développement du Cloud et du SaaS

En tant que participant de la transformation SaaS, l’analyse du CIO de O’Reilly Media, l’éditeur bien connu, nous est apparu bien résumer plusieurs difficultés à surmonter dans cette évolution que l’IT traverse. Défis de haut niveau qu’il présente sous forme de puzzles :

  • Puzzle #1: Create flexibility by being less flexible
  • Puzzle #2: Determine the cost of an existing IT solution
  • Puzzle #3: Simplify the environment by introducing more complexity
  • Puzzle #4: Provide assurances of sustainability in a domain of uncertainty
  • Puzzle #5: Maintain security while reducing it

5 cloud computing conundrums

Publié dans Non classé