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 :
Inscription à :
Publier les commentaires (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
0 commentaires:
Enregistrer un commentaire