Jean FRANCOIS blog [Weblogic / Java EE / SOA]: avril 2009

mercredi 1 avril 2009

WLS (Bascule Instance Administration)

03:37 |

Publié par Jean FRANCOIS |

Modifier l'article

Procédure de bascule de l’instance d’administration d’une machine à l’autre en cas d’indisponibilité de la machine supportant celle-ci.

PRINCIPE

Les instances managées ont besoin des informations contenues dans le fichier config.xml pour déployer les ressource et applications. Pour cela elles utilisent l’instance d’administration via son URL. Si l’instance d’administration n’est pas présente, elle peut utiliser une copie locale du fichier config.xml automatiquement copié en local de chaque instance via l’option MSI en mode réplication.

Cependant, sans la présence de l’instance d’administration, aucune modification de la configuration du domaine ne peut être réalisée. Il faut donc relancer cette instance sur une machine valide.

PREREQUIS

L’élément impactant est l’URL de l’instance d’administration placée dans le scripte de démarrage des instances managées, et la présence des fichiers de configuration du domaine à l’endroit ou l’instance d’administration doit démarrer.

URL

-Dweblogic.management.server=http://IP:PORT

Fichiers à placer sur chaque machine pour démarrer l’instance d’administration

*.ldift	fichier nécessaire à la reconstruction du répertoire temporaire de l’instance d’administration
msi-config.xml	Fichier a jour (réalisé par Weblogic avec l’option MSI réplication activée en réplication)
*.dat	Fichier binaire
boot.properties	Mot de passe pour le démarrage des instances
running-managed-servers.xml	Fichier récapitulant toutes les instances sur lequel il faut se resynchroniser

Il faudra également paramètre l’instance d’administration en localhost de façon à ne pas modifier le paramétrage du domaine.

Pour que l’instance d’administration se resynchronise avec ses instances managées en cours, il faut positionner le paramètre suivant dans son scripte de démarrage.

-Dweblogic.management.discover=true

Dans le cas où l’ instance d’administration se resynchronise mal avec ses instances managées, on peut utiliser la commande suivante pour forcer cette action.

weblogic.Admin DISCOVERMANAGEDSERVER

ACTION

· Copier sur chaque machine les fichiers suivant au niveau du répertoire du domaine.

Fichiers à placer sur chaque machines

*.ldift	fichier nécessaire à la reconstruction du répertoire temporaire de l’instance d’administration
msi-config.xml	Fichier a jour (réalisé par Weblogic avec l’option MSI réplication activée en réplication)
*.dat	Fichier binaire
boot.properties	Mot de passe pour le démarrage des instances
running-managed-servers.xml	Fichier récapitulant toutes les instances sur lequel il faut se resynchroniser

· Placer le scripte de démarrage de l’instance d’administration sur chaque répertoire de domaine.

· Redémarrer l’instance d’administration si besoin sur une nouvelle machine (1 seul instance d’administration active au même moment). Il y a une resynchronisation automatique des instances.

· Paramétrer les scriptes de démarrage des instances managées de façon à redémarrer celle-ci avec la bonne URL (faire varier l’IP) (redémarrage si besoin).

-Dweblogic.management.server=http://IP:PORT

ALTERNATIVE

Vous pouvez utiliser la résolution DNS pour changer l’IP de l’instance d’administration sans avoir besoin de toucher aux scriptes de démarrage des instances managées.

Libellés : ARCHITECTURE, PARAMETER, WEBLOGIC |

0 commentaires

JVM (principes de paramétrage)

02:29 |

Publié par Jean FRANCOIS |

Modifier l'article

Cet article propose de dégager de façon globale des règles de paramétrage de JVM pour un environnement de production. Elles constituent un point d’entré pour obtenir une plate-forme stable, mais pas un tuning fin. Pour cela, il faudra composer avec les spécificités de chaque application et de leurs consommations mémoire, ainsi que les optimisations offertes sur chaque JVM fonction de l’éditeur.

La JVM est un composant mangeure dans l’architecture Weblogic car c’est elle qui permet d’accéder à la ressource machine via l’O.S ou une infrastructure de virtualisation. Si ce composant fonctionne mal, c’est la totalité de la plate-forme WLS qui est impactée.

Elle permet également de compartimenter ces ressources pour s’assurer d’un espace disponible mémoire dédié et une répartition des traitements simultanés sur la CPU (la virtualisation pouvant compartimenter la partie CPU).

L’impacte du paramétrage de JVM peut être influant sur les aspects suivants :

ü La gestion mémoire.

ü Le type de GC déclenché, leurs longueurs et l’impacte sur l’indisponibilité de la JVM.

ü L’optimisation du code généré.

Il faut s’assurer en premiers lieux du bon fonctionnement des ressources en dessous de la JVM, c’est à dire :

ü La machine s’assurer du bon choix de la CPU et du bon fonctionnement des périphériques.

ü Le réseau Vérifier les composants constitutifs et des temps d’accès.

ü L’O.S Valider l’optimisation et le paramétrage.

Chaque éditeur à sa propre version de noyau, mais implémente la même version de JDK. Le fonctionnement interne et l’optimisation peut donc varier d’une JVM à l’autre du fait de ces internes spécifique (en version et éditeur différent).

SYSTEM

Vérifier le bon fonctionnement réseau et machine, ainsi que les paramétrages OS afin d’obtenir le meilleur temps de réponse.

Valider les PATCH O.S fonction de l’éditeur en corrodante avec la version de JVM que vous voulez utiliser.

De préférence, prendre la dernière version de la JVM en accord avec les préconisations support Oracle afin d’embarquer les derniers correctifs et se prémunir de défaillance du noyau de la JVM.

J.I.T

La JVM compile le byte code en code compilé afin d’optimiser le temps d’exécution et se rapprocher le plus prés possible du code machine cible. Cette phase se fait au fur et à mesure des requêtage selon certaines stratégies. Cette procédure n’est pas persistance et doit être rejouée à chaque redémarrage de la JVM.

La plupart du temps on distingue deux types de compilation fonction de l’environnement utilisé.

ü Développement Il existe une compilation dédiée aux environnements de développement avec une phase d’optimisation rapide, mais peu performante. Ce type d’environnement impose des modifications relativement fréquentes du code java, ainsi qu’un redémarrage fréquent de la JVM, d’ou des contraintes particulières.

ü ¨Production Pour un environnement de production, le code est théoriquement modifié et déployé peu souvent avec des redémarrages de JVM à fréquence espacée. L’optimisation est donc plus longue, mais plus performante afin d’obtenir les meilleurs temps de réponse.

Le mode par défaut et le type de paramétrage peuvent varier d’une JVM à l’autre, et les phases d’optimisation sont spécifiques par rapport au noyau de l’éditeur et de la version.

Dans le cas de crash de JVM sans génération de log (arrêt brutal), le problème se trouve en général dans le code généré par la JVM qui fait crasher le processus. Trois solutions sont possibles :

ü Changer de version de JVM afin de corriger le bug.

ü Changer le type de JIT.

ü Désactiver complètement le JIT ou juste sur la classe incriminée (voir le dump généré).

MEMOIRE

· La JVM a la spécificité d’attribuer une zone mémoire physique dédiée à l’application (HeapSize). Cela permet de se prémunir contre les dépassements système des processus et d’allouer tout de suite un ensemble de blocs prêts à l’utilisation (gain de temps sur les allocations).

Cependant, le processus JAVA à également besoin en interne de mémoire pour fonctionner, et certaines zones issues de la partie applicative peuvent être alloué en dehors de la HeapSize. La taille de la HeapSize ne représente donc pas la taille réelle occupée par le processus.

En interne de la HeapSize le plus souvent deux zones sont créées. Une pour les nouveaux objets (nursery), l’autre pour les objets d’une durée de vie plus longue.

Globalement ou pourra appliquer le ratio suivant :

ü Prendre 70% de la mémoire physique pour les instances JAVA et 30% pour le système.

ü Pour l’instance, prévoir une HeapSize suffisante en sachant que le processus prend 30% en plus.

ü Répartir la HeapSize avec 30% de tenured et 70% de nursery (ne pas dépasser 70% sur la tenured)

HeapSize = Tenured 30% + Nursery 70%

Proc Java = HeapSize + 30%

Machine = System 30% + SUM (Proc Java ) 70%

· Concernant la mémoire globale, on peut distinguer la mémoire totale associé à la HeapSize, le footprint Œ qui correspond aux données résiduelles et la mémoire libre pour desservir la charge de création d’objet.