mardi 20 avril 2010
05:35 | 
Publié par
Jean FRANCOIS |
Quand on déploie une application sur Weblogic et que l’on veut requête cette application via un navigateur il faut utiliser l’URL suivante
Le nom de l’application étant le nom du package déployé ou du libellé précisé dans le descripteur associé au context root.
(weblogic.xml)
Pour l’exemple de notre application TestSession.war, l’URL de requêtage sera :
Si l’on veut utiliser une autre URL d’accès, voir plusieurs différente sur une même instance, il faut utiliser la notion de Virtual Host.
Le Virtual Host permet d’associer une adresse à une application particulière sur une instance ou un cluster.
Un cluster de deux instances est défini avec comme Listen Adresse localhost et port respectivement 7101, 7201. Un Apache avec le plugin Weblogic répartit la charge sur ces URL. On va définir un Virtual Host sur montestcluster targeter sur ce cluster et déclarer montestcluster dans le hosts. L’application sera déployée sur ce Virtual Hosts.
Pour cela, il faut définir une résolution réseau dans votre fichier hosts (ou DNS) pour router le nom montestcluster vers le proxy Apache.
Sur windows sous C:\WINDOWS\system32\drivers\etc\hosts
127.0.0.1 localhost
127.0.0.1 montestcluster
Sur le proxy Apache, il faut définir un filtre via le plugin Weblogic pour router tous les appels vers le cluster
Créer un Virtual Host via la console Weblogic
${domaine}àEnvironmentàVirtual Hostà New
Name : VirtualHost-TestSession
Virtual Host Names: montestcluster
cluster
(weblogic.xml)
${domaine}àDeploymentàInstallà${emplacement du WAR}à${fichier WAR}àNext
Virtual Hosts : VirtualHost-TestSession
Puis Finish
Et enfin activer : Start à Service all request
Maintenant en targetant l’application sur le cluster, nous avons l’erreur suivante :
Tue Apr 20 11:56:41 2010 <633612717574015> Connect returns -1, and error no set to 10035, msg 'Unknown error'
Tue Apr 20 11:56:41 2010 <633612717574015> EINPROGRESS in connect() - selecting
Tue Apr 20 11:56:41 2010 <633612717574015> Local Port of the socket is 2448
Tue Apr 20 11:56:41 2010 <633612717574015> Remote Host 127.0.0.1 Remote Port 7201
Tue Apr 20 11:56:41 2010 <633612717574015> created a new connection to preferred server '127.0.0.1/7201' for '/', Local port:2448
Tue Apr 20 11:56:41 2010 <633612717574015> URL::parseHeaders: CompleteStatusLine set to [HTTP/1.1 404 Not Found]
Tue Apr 20 11:56:41 2010 <633612717574015> URL::parseHeaders: StatusLine set to [404 Not Found]
Tue Apr 20 11:56:41 2010 <633612717574015> parsed all headers OK
Libellés :
vendredi 16 avril 2010
Un domaine Weblogic est un ensemble d’instances regroupé en cluster ou non dans lequel on déclare des ressources JEE comme des files JMS.
La notion de target ou cible de déploiement s’applique aux instances, clusters et serveur JMS.
Un serveur JMS étant le composant logiciel responsable du fonctionnement de l’infrastructure JMS. C’est une ressource co localisée sur une instance. Chaque instance pouvant recevoir (ou pas) un et un seul serveur JMS.
Les ressources JMS étant :
JMS Module | Regroupement de ressources associées à des instances ou cluster. |
Sub Deployment | Regroupement de ressources au sein d’un même JMS module. |
Ressources locales | Queue/Topic |
Ressources distribuées | Connection Factory/Uniformed Distributed Queue/Foreigne Server |
Le JMS Module est un groupe d’association constitué d’instances et/ou de clusters. Les ressources déclarées dans ce module doivent être targeter sur les serveurs JMS des instances ou cluster appartenant au groupe du JMS module (sous peine d’erreur lors de la création de la ressource).
Au sein d’un même JMS module, on peut regrouper les ressources par SubSeployment afin d’assurer un couplage lâche sur le domaine (un SubDeployment par cluster, par exemple). Un SubSeployment étant targeter sur les clusters ou serveur JMS des instances appartenant au JMS module.
Les ressources type queue ou topic ne peuvent être targeter que sur un serveur JMS unique, alors que les connection factory, uniformed distributed queue destination et foreigne server peuvent être associé à des clusters .
Conseil :
ü Créer un serveur JMS par instance.
ü Créer un JMS module pour regrouper les cibles de target commun. Choisir les groupes par critère techniques (ensemble de cluster ou ensemble d’instance stand alone) ou fonctionnel (ensemble d’instance partageant les mêmes applications).
ü Créer des SubDeployment sur les clusters dans le cas de cluster et créer des ressources associées à ce SubDeployment (Distributed Queue, etc …)
ü Créer des SubDeployment sur des serveurs JMS dans le cas d’instance hors cluster, et associer les ressources créées sur les serveurs JMS des instances (ne pas prendre l’instance comme cible).
ü Prendre des noms JNDI sans caractère spéciaux avec un prefix en « jms/»
ü Dans le cas d’un Store type JDBC, créer un datasource par JDBCStore non XA.
ü Préférer déclarer les ressources JMS via la console (system modules) plutôt que le déclarer dans les applications via les descripteurs JEE (application modules) car non visible pour le monitoring dans ce cas.
mercredi 14 avril 2010
Pour valider une plateforme JEE vous devez vous assurer que toutes les couches traversées fonctionnent correctement. La vérification passe par la validation des versions utilisées, le paramétrage, les testes techniques et fonctionnels, les tests de charges associés. Une architecture sécurisée est avant tout une architecture scalable et redondante afin d’anticiper les charges et incidents.
Une check liste peut être établit afin de ne pas oublier certaines parties de l’architecture ou point technique qui pourrait faire écroulé l’édifice.
ü Socle de version en accord avec le support
ü Validation réseau
ü Tuning OS
ü Tuning JVM
ü Architecture
ü Tuning WLS
ü Monitoring
ü Application
ü Validation des composants externes
ü Bench
ü Formation des équipes en charge de la plateforme
Pour isoler les risques, vous devez passer au préalable par une phase d’industrialisation de plateforme afin de sécuriser tous les éléments que vous allez mettre en place dans votre architecture.
Le fait de définir des briques de développements validés et maitrisés par tous les intervenants peut par exemple rendre plus fluide la phase de validation. De même que l’utilisation de scripting normalisé ou l’utilisation d’une virtualisation peut éviter des erreurs dans la réplication des environnements, etc ….
Il est en général recommandé de prendre les dernières versions pour embarquer un maximum de correctif et d’évolution, mais renseignez-vous sur la stabilité des nouveautés auprès des supports respectifs ou réalisés des POC.
Le plus simple étant d’établir un socle validé en interne dans le cas de l’industrialisation si la structure le permet.
Valider donc cette partie avec un expert Système en prenant en référence le guide de tuning proposé dans les documentations éditeur comme point de départ.
Valider ensuite le sizing mémoire par rapport à la machine et les options de GC à utiliser pour éviter les contentions et dysfonctionnement (GC non approprié, taille mémoire trop petite pour la charge utilisateur ou trop grande par rapport à la mémoire physique de la machine).
Concernant le JIT, toujours utiliser la version serveur qui est dédiée à un environnement de production.
Vérifier en cas d’utilisation de cluster que les composants utilisés par celui-ci fonctionnent correctement et réaliser des testes techniques (validation des load balancing, failover/failback, dialogue cluster, etc …).
On peut par contre jouer sur les pools ou cache pour obtenir des gains en temps de réponse, mais ces temps sont directement imputables au temps d’exécution JAVA du code applicatif et du backend (excepté les situations de lock).
La 1er chose à valider est le mode de fonctionnement Weblogic. Toujours prendre un domaine en mode PRODUCTION, jamais en mode DEVELOPPEMENT. En effet, ce mode spécifique aux modifications répétées de l’application permet de prendre ceux-ci en compte automatiquement. Les mécanismes mis en jeux sont trop couteux pour un environnement de production en charge et peuvent faire écroulé les temps de réponse.
· Le mode de déploiement est également important. Assurer vous que les applications sont précompilées et que le mode de déploiement est adéquat (stage/external stage/side by side)
· Rationaliser les logs générés par le serveur pour éviter trop d’écriture et mieux exploiter leurs contenus.
· Mettre en place des procédures pour être alertes en cas de défaillance de certaines ressources types threads ou datasource.
· Tailler vos pools pour assurer la charge.
· Valider les différends timeout
Fonctionnel | Pour valider que la plateforme réponde bien à la demande fonctionnelle. |
De charge | Pour valider que la plateforme va tenir la charge de production. |
De non-régression | Dans le cas d’une plate-forme mise à jour, valider que celle-ci n’a pas subit régression par rapport à la version d’avant |
Aux limites | Voir jusqu’où on peut aller (capacity planing) |
De vieillissement | Voir s’il n’y a pas de fuite mémoire |
De robustesse | Voir le comportement de la plate-forme en cas de panne ou d’incident dégradant la plate-forme. |
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
