mercredi 7 avril 2010
08:02 | 
Publié par
Jean FRANCOIS |
L’industrialisation de plate-forme passe par une définition d’architecture type (cluster ou non, n tiers, etc … ) et de composant d’infrastructure (Cache Objet, Framework infrastructure [Log4J, etc …] / Framework Composant [Portal, etc …] ) a intégré dans des socles de version associée à du scripting d’installation et de maintenance.
L’objectif étant de définir un contrat normalisé entre les différents acteurs des projets sur la solution mise en place. Cela passe par :
ü Mise en place de bonne pratique d’utilisation des composants.
ü Packaging et paramétrage exploitable dans tous les environnements.
ü Validation en bench sur des composants déjà référencés.
ü Automatisation des mises en place et exploitation des solutions.
ü Monitoring outillage et gestion des trouble shooting maitrisés par l’ensemble des acteurs.
Le paramétrage des ressources en amont et en aval du domaine doit être transparent sur la mise en place de redondance ou de répartition de charge afin de conserver la neutralité de la plate-forme Weblogic (Oracle RAC, LDAP réparti).
Le domaine peut héberger n instances réparties sur m clusters (ou non) déployant une ou plusieurs applications divisées en x tiers d’architecture (Frontal Web ou WS/Couche métier EJB).
La répartition des applications et instances sur les machines et la façon de déployer l’architecture va impacter l’industrialisation de la plate-forme. Il faut pour cela que les applications déployées puissent se conformer aux contraintes de la plate-forme et puissent être sectorisées suivant différents critères afin d’appliquer une règle de déploiement:
Recommandation de développement :
ü Pages statiques séparées pour déploiement sur le frontal HTTP.
ü Sérialisation des objets mises en session et déclaration des primitifs clusters dans les descripteurs J2EE.
ü Définition de timeout sur les flux sortant avec un paramétrage externe pour éviter les contentions.
ü Utilisation des framework référencés en suivant les recommandations (d’implémentation et de paramétrage).
ü Packaging unique (EAR normé)
ü Paramétrage applicatif prenant en compte le multi-instance (properties par instance, etc … )
Composants utilisés :
ü JMS
ü LDAP
ü JDBC
ü EJB
ü WS
ü Type de framework
Typage de l’application :
ü Criticité (important, mineur)
ü Charge (traitement lourd, batch, passe-plat, métier)
ü Audience (internet, intranet, utilisation sur plage horaire, (fréquentation)
ü Mutualisation (des composants)
ü Accès (aux mêmes types de ressource)
ü Type (banque/assurance)
Il faut également avoir une souplesse de déploiement des instances afin de mieux gérer les charges induites et donc d’être renseigné sur ceux-ci (monitoring). Dans le cadre d’une mutualisation, on doit prendre en compte le compartimentage des ressources pour gérer les criticistes (mémoire/CPU-Threads/pool).
La répartition des instances sur les machines physiques doit suivre des règles de base afin d’éviter les engorgements de ressource (thread CPU, mémoire, disque)
ü Ne pas dépasser 70% d’occupation mémoire pour les instances
ü Ne déployer que des instances WLS sur la machine pour ne pas polluer la consommation des ressources.
ü Déployer les instances d’administration sur des machines dédiées.
ü Essayer de dissocier les ‘file system’.
ü Virtualiser pour compartimenter la ressource CPU
Les besoins d’un projet peuvent être multiples et impactant sur la plate-forme Weblogic à déployer suivant différent critères de criticiste ou d’utilisation de ressources. Il faut donc définir plusieurs types d’architecture Weblogic mettant en place un certain nombre de ressource et de fonctionnalités pour ensuite fournir les éléments d’industrialisation nécessaire a chaque spécificité d’environnement.
Les considérations d’architecture Weblogic sont à plusieurs niveaux de contraintes :
ü Utilisation d’un cluster ou non et répartition des instances dans le domaine.
ü Déclaration et utilisation des ressources utilisées par l’infrastructure.
ü Utilisation de framework ou non (ressource spécifique à déployer et administrer).
ü Mode de déploiement des projets (contraintes spécifiques).
CLUSTER : Pour les projets critiques, il est souhaitable de définir une architecture redondée via les clusters. Le cluster regroupant les notions de :
ü Failover (reprendre les données utilisateur en cas de crash)
ü LoadBalancing (répartition de la charge sur plusieurs ressources (instance/CPU/mémoire))
ü Scalability (étendre les ressources en cas d’un accroissement de charge)
Pour l’utilisation de certaines ressources comme JMS ou EJB, framework, il est fortement recommandé, voir nécessaire d’utilisé le cluster Weblogic afin de rendre les ressources accessibles quelque soit le nœud du cluster utilisé (vue unique de la ressource)
L’impact d’un cluster Weblogic concerne la mise en place de l’environnement le paramétrage et le déploiement des ressources.
NON CLUSTER : Dans le cas où le cluster n’est pas nécessaire, on conservera cette notion de multiinstance pour garantir un service 24/7. Nous n’aurons plus que la notion de failover. Le loadbalancing sera toujours assuré par le frontal HTTP, mais de façon statique. Ce type d’architecture ne pourra donc pas héberger d’application utilisant JMS (ou EJB).
FRAMEWORK: Pour les applications utilisant un framework, il faudra déclarer des domaines spécifiques déclarants les ressources associées (domaine spécifique avec pré paramétrage de ressource et d’application). Il est préférable d’utiliser ces domaines en mode cluster, car mettant en jeux des mécanismes type JMS et Singleton Service.
DEPLOIEMENT : Le mode de déploiement peut également impacter sur l’architecture à mettre en place. Certaines applications ne supportant pas le déploiement multi-instance ou un déploiement de plusieurs applications sur une même instance (pour des raisons de paramétrage ou de déploiement générique). On peut ainsi dégager trois types de contraintes de déploiement :
ü Déploiement mono-instance Œ (une seule instance sur le domaine)
ü Déploiement multi-instance exclusif Ž (plusieurs instances, mais une application par instance)
ü Déploiement multi-instance inclusif (pas de dépendance, possibilité de cohabitation)
| |
|
FRAMEWORK INSFRASTRUCTURE : Certaines applications peuvent nécessiter des composants d’infrastructure spécifique positionnés dans le domaine et communs à toutes les instances. Cela créer donc une dépendance par rapport au domaine (Coherence, Log4J, etc …). Il faudra donc regrouper ces applications sur ces domaines spécifiques afin d’éviter des impactes non maitriser sur le déploiement et l’exécution des projets (problèmes de CLASSPATH ou ressources en conflits).
SPECIFIQUE : certaines applications nécessitent des environnements devant respecter des contraintes métier (bancaire/assurance). Le mélange de ces types d’application ne peut donc pas se faire sous peine d’assumer la charge d’un environnement qui n’a pas lieu d’être (normalisation de paramétrage, contrainte de sécurité, indisponibilité de plate-forme liée à des changements, mise en place de composant incompatible)
COMPARTIMENTE : dans le cas de déploiement mutualisé, les ressources sont partagées entre plusieurs applications (certaines applications étant plus prioritaires que d’autre). Toutes les applications sont consommatrice de ressource par rapport à une complexité de code ou à un requêtage spécifique (variable ou non dans le temps). Dans le cadre de cette cohabitation d’espace et de temps, il est nécessaire de mettre en place des mécanismes de partitionnement variable afin d’étanchéifier les contextes applicatifs sur la consommation des ressources. Ces mécanismes doivent donc être pris en compte dans l’architecture mise en place.
DEPLOIEMENT : Les applications peuvent avoir des contraintes de déploiements (mono/multi instance, exclusif/inclusif). Il faut donc spécifier le type de déploiement nécessaire.
TYPE : Une application est spécifique par rapport à son domaine (banque/assurance).
CRITICITE : Elle peut être critique ou non.
CHARGE RESSOURCE : Elle peut consommer fortement les ressources par complexité de code ou par charge induite.
FRAMEWORK: Elle peut utiliser un framework avec des ressources spécifiques.
FRAMEWORK INFRASTRUCTURE : Elle peut utiliser des ressources d’infrastructure à déclarer spécifiquement dans l’environnement BEA (en dehors de tout packaging)
RESSOURCE JMS/EJB : Utilisation de ressources JMS/EJB
Libellés :
Pour monitorer les métriques des instances, on a la possibilité d’activer une extension de la console d’administration.
En Weblogic 10.3.3, vous pouvez avoir accès directement via la console :
En Weblogic de version inférieure, vous devez copier un JAR issu du répertoire de l’installation de Weblogic, de le copier dans le domaine et de redémarrer l’instance d’administration.
cp ${WL_HOME}/server/lib/console-ext/diagnostics-console-extension.jar ${DOMAIN_HOME}/ console-ext/
Cette console permet de visualiser des données MBean server collecté depuis WLDF. Elle offre une vue du domaine complet avec un client riche basé sur SWING. Elle offre un framework pluggable de customisation et supporte le :
ü Drag-n-Drop.
ü Customisation des vues.
ü Graphiques.
ü Jauges
Le thread permet d’exécuter le code JAVA sur la CPU comme les processus sur le serveur (unité d’exécution). Le serveur d’applications permet de fournir un certain nombre de thread pour traiter les requêtes utilisateur (à une URL correspond un code JAVA spécifié par les descripteurs J2EE). Ces threads peuvent prendre du temps ou être mises en contention due au code qui s’exécute. Deux cas de contention peuvent se présenter :
ü Attente d’une ressource externe (attente sur une table en lock, lock du code JAVA).
ü Exécution de façon anormalement longue (boucle, appels multiples)
Pour détecter qu’un thread est long ou en contention, plusieurs méthodes peuvent être mises en œuvre à différents niveaux. L’instance Weblogic reçoit les requêtes utilisateur ‹ via le réseauŒ, le pool de threads et le Workmanager exécuter ces requêtes en déclenchant le code applicatifŽ.
Cinq points de mesure peuvent donc être mise en place :
ü Temps de réponse client ‹
ü Temps des requêtes Œ
ü Temps des threads
ü Temps des méthodes Ž
ü Temps des requêtes sur le backend.
Concernant les requêtes, nous pouvons utiliser les access log, pour les threads nous pouvons observer les comportements via les MBean du pool de thread et des WorkManager. Pour l’application, il faudra passer par du profiling JAVA. Pour la partie client, ou pourra utiliser des outils sur le navigateur type http Watch ou IE Watch.
L’objectif étant de fractionner le temps global en temps intermédiaires associés à chaque tiers traversé, afin de définir les responsabilités sur des dégradations de temps de réponse sachant que l’architecture est une composée d’éléments hétérogènes.
Les temps constatés sont dans un premier temps relevés du côté client avec une objectivité toute relative. Il faut donc un outil impartial pour notifier ces temps et observer les requêtes HTTP les plus couteuses.
Dans le cas d’un client Web on pourra utiliser un outil type HTTP Watch ou IE Watch afin de récupérer ces temps par URL et d’investiguer sur les trames retour.
Pour un client JAVA lourd, il faudra passer par les temps d’exécution du processus où instrumenter le code client pour obtenir ces informations.
Dans le cas d’un test de charge, c’est l’outil d’injection qui se charge de relever les temps unitaire et moyen.
Pour ajouter ce temps de requêtage, il suffit de se positionner via la console Weblogic :
EnvironnementàServersà${le serveur}àLoggingàHTTP
Format : Extended
Extended Logging Format Fields : date time cs-method cs-uri sc-status time-taken
Extraction de la documentation
Time taken for transaction to complete in seconds, field has type , as defined in the W3C specification.
Exemple sans le champs time-taken
127.0.0.1 - - [30/juil./2009:11:45:12 -0430] "GET /em/images/EM_Loginarea_Background.png HTTP/1.1" 200 3610
Avec le mode extened log et le time-taken
#Version: 1.0
#Fields: date time cs-method cs-uri sc-status time-taken
#Software: WebLogic
#Start-Date: 2009-10-09 04:35:08
2009-10-09 04:35:08 GET /TestSession/ 200 0.172
2009-10-09 04:35:09 GET /TestSession/ 200 0.015
2009-10-09 04:35:09 GET /TestSession/ 200 0.0
2009-10-09 04:35:09 GET /TestSession/ 200 0.0
2009-10-09 04:35:09 GET /TestSession/ 200 0.0
2009-10-09 04:35:09 GET /TestSession/ 200 0.0
2009-10-09 04:35:17 GET /TestSession/ 200 0.0
2009-10-09 04:35:18 GET /TestSession/ 200 0.0
2009-10-09 04:35:18 GET /TestSession/ 200 0.0
2009-10-09 04:35:18 GET /TestSession/ 200 0.0
2009-10-09 04:35:18 GET /TestSession/ 200 0.0
2009-10-09 04:35:19 GET /TestSession/ 200 0.0
2009-10-09 04:35:19 GET /TestSession/ 200 0.0
2009-10-09 04:35:19 GET /TestSession/ 200 0.016
Vous pouvez utiliser ce log avec l’outil WLSAccessLogReport.ou effectuer une macro Excel.
Vue Excel de l’outil WLSAccessLogReport.
Côté serveur d’applications, c’est le temps d’exécution des threads qui peut nous informer sur les temps passés dans les requêtes. Concernant les temps dégradés, on pourra activer des options de Weblogic afin d’être notifié et d’agir sur cet événement.
Trois possibilités nous sont offertes pour observer les contentions :
ü Œ Le pool de thread avec un monitoring.
ü Le WorkManager nécessitant un paramétrage spécifique.
ü Ž La notification via le log Weblogic.
POOL THREADS
Weblogic analyse les temps passés dans les threads pour décider d’en allouer d’autre. Les threads non occupés depuis un certain temps sont mis dans un état Standy et les threads qui statistiquement ont une durée d’exécution plus longue que la moyenne sont mis en état Hogging. C’est ce paramètre qui permet de nous alerter sur un début de contention.
Il suffit donc de monitorer celui-ci pour avoir une vue sur les threads de durée de vie anormalement longue (normale ou non). Il n’y a pour cette métrique aucun paramètre possible pour fixer le seuil au bout duquel on considère qu’un thread est en contention. C’est le pool qui le renseigne par rapport au temps moyen.
${instance}àRuntimeServiceMBeanàServerRuntimeàThreadPoolRuntimeMBean
Métriques
CompletedRequestCount | Nombre de requêtage réalise depuis le démarrage de l’instance (prendre la valeur d’avant pour calculer le throughtput) | 141415 |
ExecuteThreadIdleCount | Nombre de threads inoccupé (libre) | 0 |
ExecuteThreadTotalCount | Nombre total de threads dans le pool | 15 |
HoggingThreadCount | Nombre de thread utilisé par des requêtes trop lente | 5 |
MinThreadsConstraintsCompleted | 14126 | |
MinThreadsConstraintsPending | 0 | |
PendingUserRequestCount | Nombre de requête utilisateur en attente sur le pool de thread du serveur | 0 |
QueueLength | File d’attente des requêtes en utilisateur | 0 |
SharedCapacityForWorkManagers | 65536 | |
StandbyThreadCount | Nombre de threads plus utilisé et mise en attente (réserve pour éviter une trop grande activité de création de threads) | 9 |
Throughput | 3.5 |
Le nombre de actif = nombre de inoccupé + nombre de threads occupé
Le WorkManager est un composant d’infrastructure qui prend en charge les besoins de ressource CPU pour les composants déployés sur le serveur d’applications. Il embarque une intelligence et une possibilité de paramétrage afin de gérer dynamiquement les besoins selon l’évolution de la charge. Il se place donc entre le pool de threads et la ressource desservie.
Ce composant peut nous renseigner sur les blocages de thread associé à la ressource. Il permet également d’agir sur les contentions via les mécanismes l’Overload Protections.
Le paramétrage des Stuck Thread décrit dans le chapitre suivant sur la partie log, permet de notifier le paramètre MBean StuckThreadCount sur les thread en contention spécifique sur la ressource associé. Cette métrique peut être remontée via un outil de monitoring avec possibilité de remontée d’alerte.
${instance}àRuntimeServiceMBeanàServerRuntimeà${instance}àApplicationRuntimesà${application}àWorkManagerRuntimesà${nom du workmanager}
Activité de chaque workmanager
ApplicationName | String | TestFreez |
CompletedRequests | Long | 0 |
ModuleName | String | null |
PendingRequests | Integer | 0 |
StuckThreadCount | Integer | 0 |
Via les mécanismes d’Overload Protection, on pourra définir sur quelle condition de blocage de la ressource Threads on déclare l’instance défaillante.
Globalement via la console Weblogic.
EnvironnementàServersàConfigurationàOverload
Spécifiquement en créant un WorkManager et en ajoutant dans les descripteurs JEE cette partie.
weblogic.xml
LOG
Modifier le paramétrage Weblogic sur le StuckThreadMaxTime qui permet à Weblogic de remonter les Threads en contention via les logs Weblogic (également via les WorkManager). Il faut modifier les paramètres suivants pour changer la valeur par défaut de 10 minutes à 1 minute.
EnvironnementàServersàConfigurationàTuning
Stuck Thread Max Time : 600 à 60
Stuck Thread Timer Intervel : 60
Exemple d’un log Weblogic sur un StuckThread
####<23 juil. 2009 03 h 14 VET> <[ACTIVE] ExecuteThread: '72' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1248335056672> <[STUCK] ExecuteThread: '64' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "44" seconds working on the request "weblogic.servlet.internal.ServletRequestImpl@b5839e[
GET /TestFreez/Freez.jsp HTTP/1.1
Accept: */*
Referer: http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=WebAppApplicationTestingPage&handle=com.bea.console.handles.AppDeploymentHandle%28%22com.bea%3AName%3DTestFreez%2CType%3DAppDeployment%22%29
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Connection: Keep-Alive
]", which is more than the configured time (StuckThreadMaxTime) of "30" seconds. Stack trace:
Thread-79 "[STUCK] ExecuteThread: '64' for queue: 'weblogic.kernel.Default (self-tuning)'" {
java.lang.Thread.sleep(Thread.java:???)
jsp_servlet.__freez._jspService(__freez.java:61)
weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:224)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:108)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:198)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3468)
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:308)
weblogic.security.service.SecurityManager.runAs(Unknown Source)
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2116)
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2038)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1372)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:198)
weblogic.work.ExecuteThread.run(ExecuteThread.java:165)
}
>
Utiliser un profiler JAVA type Wily ou AD4J.
Inscription à :
Articles (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
