Compte rendu du séminaire SpringSource tc Server du 28 Juillet à OCTO

le 03/08/2009 par Rudy Krol
Tags: Software Engineering

J’ai assisté au séminaire SpringSource tc Server qui a eu lieu le Mardi 28 Juillet dans les locaux d’OCTO. L'objectif principal de ce séminaire était de présenter deux produits SpringSource : tc Server et Hyperic HQ. Je vous propose un bref compte-rendu de la présentation menée par Chris Harris, consultant senior chez SpringSource.

SpringSource tc Server

Chris commence par positionner tc Server et Hyperic HQ sur la gamme de produits SpringSource, qui s'articule maintenant sur 3 axes :

  • build : Spring framework, Groovy/Grails et SpringSource Tool Suite
  • run : tc Server, dm Server et ERS
  • manage : Hyperic HQ

tc Server est défini par SpringSource comme une alternative low-cost à JE****E, basé sur un Tomcat, fournissant des fonctionnalités de monitoring et d'administration d’**applications d'**entreprise. Les gains qui ont été mis en avant sont donc essentiellement :

  • réduire la complexité (déploiement/management des applications, monitoring, etc.)
  • restreindre les coûts (licence, support, etc.)
  • améliorer la productivité (simplicité de la solution, temps de démarrage du serveur, etc.)

Le serveur fournit toutes les fonctionnalités existantes dans un Tomcat 6.0.19 (Servlet/JSP, clustering avec replication de session/contexte, etc.) et d’autres fonctionnalités orientés entreprise. En effet, la solution permet, entre autre :

  • un découplage entre le CATALINA_HOME et CATALINA_BASE (pour démarrer plusieurs instances sur une même installation de Tomcat mais des configurations différentes)
  • une release stable, construite, certifié et pré-tuné par SpringSource
  • une collecte automatique d’informations avant/pendant les incidents permettant de faciliter le diagnostic des incidents rencontrés en production

L’architecture tc Server est composée de 3 différentes briques :

  • une ou plusieurs instances tc Server
  • un ou plusieurs agents AMS : un agent par machine contenant une ou plusieurs instances tc Server. L'agent permet au serveur AMS de collecter des informations sur les ressources supervisées. Il permet également de contrôler les instances tc Server et applications suite aux actions déclenchées via le serveur AMS.
  • un serveur AMS : un serveur d'administration et de monitoring centralisé offrant un console d’administration et un ensemble de scripts

AMS (Application Management Suite) permet d'administrer et superviser des instances tc Server mais également d'autres types de ressources : apache http server, activeMQ, JVM, OS. A travers une console d’administration, l’outil permet d’effectuer différents type d’opérations distribuées :

  • gérer/monitorer des applications (basée sur le framework Spring pour plus de métriques)
  • gérer un cluster
  • découvrir automatiquement les ressources administrables/supervisables
  • gérer des alertes et déclencher des actions permettant de corriger l’état du système
  • générer des rapports
  • configurer et loguer des évènements
  • afficher des métriques
  • configurer des rôles d’accès à la console
  • exposer des actions JMX de métriques et notifications
  • etc.

Les applications peuvent être déployées/undeployées/démarrées/arrêtées sur un groupe d’instances tc Server qui lui-même peut être démarré/arrêté. Les instances tc Server peuvent également être configurées à travers la console d’administration AMS, par contre, elles ne peuvent pas être configurées de manière groupée.

Les optimisations disponibles sur tc Server «out of the box» sont principalement le paramétrage des options de JVM, des scripts de configuration adaptés à la production ou à un démarrage rapide, des scripts de démarrage des instances/agents AMS/serveur AMS et un service Windows. Quelques fonctionnalités avancées ont également été ajoutées à Tomcat comme par exemple le «Non-blocking (NIO) connector» (connecteur asynchrone) et le «High Concurrency JDBC Connection Pool».

Un des principaux avantages de la solution est de faciliter le d****iagnostic des incidents, notamment grâce à la détection de deadlocks de Threads, la génération de heap dump, les dumps d’exceptions, ou encore la corrélation URL/Thread. La solution offre également la possibilité de configurer des seuils permettant de lever des alertes. Les seuils configurés par défaut concernent :

  • l'activité du garbage collector
  • les temps de réponse de l'application
  • le temps d’exécution de requêtes JDBC
  • l'état du pool de connexions
  • l'état du pool de threads
  • etc.

Chris est ensuite passé à la démonstration durant laquelle il a illustré les features présentées précédemment. Il commence donc par une présentation de la console d’administration AMS avec son dashboard customisable via des portlets, une customisation qui peut être dédiée à différents type de rôles (production, développeurs, etc.). Nous avons ensuite parcouru les fonctions d’administration/monitoring des ressources (OS, groupe d’instance, application, pool de connexion/thread, etc.). Des ressources plus spécifiques à l'application peuvent être supervisées par simple exportation de MBeans JMX au niveau applicatif. Cette opération est simplifiée par l'utilisation du framework Spring permettant d'exporter des attributs/opérations/métriques de ressources via l'ajout d'annotations sur les classes Java : @ManagedResource, @ManageAttribute, @ManagesOperation et @ManagedMetric. Nous avons également vu comment configurer des alertes à travers un ensemble de conditions (principalement en cas de dépassement de seuil d’un indicateur) en prenant l’exemple de plusieurs types d’incident (arrêt de la base de donnée, requête JDBC trop lente avec détail de la requête en cause, trop de temps passé dans le garbage collector, etc.). Enfin, Chris nous a montré comment utiliser l’outil de script disponible dans AMS, appelé CLI (Command-Line Interface) pour effectuer les mêmes opérations d’administration que via la console web d’AMS.

Hyperic HQ

Après une courte pause, Chris enchaîne sur une présentation rapide du produit Hyperic HQ. A première vue Hyperic HQ ressemble à AMS... c’est normal, AMS a été construit sur la base d’Hyperic HQ suite au rachat de la société Hyperic par SpringSource. La principale différence entre les deux produits est que AMS est spécifique à Tomcat, alors que Hyperic HQ permet de monitorer une très grande variété de ressources :

  • OS
  • serveurs web et proxys
  • serveurs d’applications
  • bases de données
  • MOM
  • technologies Microsoft (AD, Exchange, .NET)
  • produits de virtualisation
  • ressources réseau
  • et bien d’autres comme Alfresco par exemple

Chris nous a montré comment rapidement installer la solution (5-10 minutes) et nous a présenté la console qui ressemble donc très fortement à la console AMS. L'outil n'est pas dédié aux développeurs mais aux exploitants.

En conclusion, cette demi-journée a permis de constater la richesse de l’offre SpringSource d’aujourd’hui, avec des outils qui paraissent complets, et une très forte volonté de conquête des environnements de production.