Jean FRANCOIS blog [Weblogic / Java EE / SOA]

Oracle Configuration Manager est un outil du support Oracle qui permet d’effectuer des captures d’une configuration machine produit et instance à destination du support Oracle. Les captures peuvent se faire automatiquement et envoyé directement au support ou manuellement via un fichier de configuration à enregistrer sur le site via un SR spécifique.

Produit supporté :

Version :

Cet outil en ligne de commande peut se coupler avec le Grid Control afin de centraliser l’ensemble des configurations de l’entreprise qui sont ensuite centralisées et visibles à partir du site support.

L’objectif étant de pousser les informations des plateformes client vers le support de façon automatisé et globalisé afin de diminuer les échanges lors de la création des SR. Il permet également d’être notifié de nouveau PATCH associé aux éléments déployés sur les plateformes (proactif). On pourra également appliquer les PATCH automatiquement du site du support vers la plateforme cible.

Lors d’envoi régulier, l’historique des captures est géré par le site et permet de voir les écarts de configuration dans le temps. C’est également une référence pour le support lors des investigations (information qu’ils ne pourraient avoir que sur site).

Cet outil est récupérable et installable sur toutes les plateformes, s’il ne l’est pas déjà nativement. Vous pouvez le récupérer sur le site du support sous l’onglet support.

Une vidéo explique le fonctionnement et les fonctionnalités associées :

FAQ :

L’installation présentée ici est basé sur une plateforme linux Red Hat 64 bits avec une capture en mode déconnecté. Une fois le binaire récupère sur la machine (si pas déjà présent) et le répertoire de-zipper, lancer l’installation. Les prés requis sur machine Unix/linux étant la présence de GCC en version 32 et 64 bits avec toutes les libraires associées.

La version 11G des produits Fusion Middelware embarque déjà l’outil sous ${FMW_HOME}/utils/ccr (Une phase d’upgrade de l’outil peut être mise en place dans le cas de FMW11GR1 How to Upgrade OCM to the Latest Version?). 

Certaines variables d’environnement doivent être positionnées avant de lancer les commandes OCM. Vous pouvez les charger via le scripte de chargement d’environnement de la distribution FMW.

Renseigner l’endroit ou se trouve OCM via la variable ORACLE_HOME.

Positionner vous sous le répertoire de l’outil OCM dans le cas d’une capture d’installation de produit.

Afin d’utiliser le produit, vous devez lancer la commande setupCCR ou configCCR (pour modification). Dans cette phase on y précise une fois pour tout  l’ID client (Customer Support Identifier) avec lequel on va ouvrir les SR, le mail du responsable et la langue. L’option –s –d permet une installation en mode déconnecté (dans le cas ou la machine de production n’a pas accès au WEB).

Commande de vérification de l’installation.

Pour collecter, il suffit de rentre la commande suivante pour que l’outil SCANNE les répertoires.

Deux possibilités, vous n’avez pas déclaré de domaine et vous souhaitez faire des captures de votre installation. Vous pouvez prendre dans ce cas le setEnv de la distribution.

Dans le cas d’un domaine, prenez le setEnv de celui-ci pour charger votre environnement d’exécution (instance weblogic montée).

Renseigner l’endroit ou se trouve OCM via la variable ORACLE_HOME.

Positionner vous sous le répertoire de l’outil OCM dans le cas d’une capture d’installation de produit ou sous le domaine dans le cas où il y a domaine à capture.

Puis lancer la commande de capture.

Vous pouvez ensuite récupérer le JAR de capture à envoyer au support.

Vous pouvez également voir le détaille dans le répertoire suivant :

 <Targets>  
  <Target TYPE="host" NAME="localhost.localdomain" >  
  </Target>  
 <Target TYPE="oracle_home" NAME="/logiciels/bea/weblogic_11gR1PS3/oracle_common" VERSION="1.0">  
  <Property NAME="host" VALUE="localhost.localdomain" />  
  <Property NAME="Location" VALUE="/logiciels/bea/weblogic_11gR1PS3/oracle_common" />  
  <Property NAME="HomeName" VALUE="OH2128292267" />  
  <Property NAME="Type" VALUE="O" />  
  <Property NAME="Index" VALUE="0" />  
  <Property NAME="OUI_Platform" VALUE="2000" />  
  <Property NAME="Clonable" VALUE="Y" />  
 </Target>  
 <Target TYPE="oracle_home" NAME="/logiciels/bea/weblogic_11gR1PS3/osb" VERSION="1.0">  
  <Property NAME="host" VALUE="localhost.localdomain" />  
  <Property NAME="Location" VALUE="/logiciels/bea/weblogic_11gR1PS3/osb" />  
  <Property NAME="HomeName" VALUE="OH1200108345" />  
  <Property NAME="Type" VALUE="O" />  
  <Property NAME="Index" VALUE="0" />  
  <Property NAME="OUI_Platform" VALUE="2000" />  
  <Property NAME="Clonable" VALUE="Y" />  
 </Target>  
 <Target TYPE="oracle_home" NAME="/logiciels/bea/weblogic_11gR1PS3/coherence_3.6" VERSION="1.0">  
  <Property NAME="host" VALUE="localhost.localdomain" />  
  <Property NAME="Location" VALUE="/logiciels/bea/weblogic_11gR1PS3/coherence_3.6" />  
  <Property NAME="HomeName" VALUE="Unknown" />  
  <Property NAME="Type" VALUE="O" />  
  <Property NAME="Index" VALUE="0" />  
  <Property NAME="OUI_Platform" VALUE="46" />  
  <Property NAME="Clonable" VALUE="Y" />  
 </Target>  
 <Target TYPE="oracle_home" NAME="/logiciels/bea/weblogic_11gR1PS3/wlserver_10.3" VERSION="1.0">  
  <Property NAME="host" VALUE="localhost.localdomain" />  
  <Property NAME="Location" VALUE="/logiciels/bea/weblogic_11gR1PS3/wlserver_10.3" />  
  <Property NAME="HomeName" VALUE="Unknown" />  
  <Property NAME="Type" VALUE="O" />  
  <Property NAME="Index" VALUE="0" />  
  <Property NAME="OUI_Platform" VALUE="46" />  
  <Property NAME="Clonable" VALUE="Y" />  
 </Target>  
 <Target NAME="Oracle Configuration Manager" TYPE="oracle_livelink">  
   <Property NAME="livelink_home" VALUE="/logiciels/bea/weblogic_11gR1PS3/utils/ccr"/>  
 </Target>  
 </Targets>  

Ou

 <?xml-stylesheet type="text/xsl" href="/logiciels/bea/weblogic_11gR1PS3/utils/ccr/admin/xsl/preview_targets.xsl"?>  
 <Targets collection_time="2011-10-24 11:24:35" host_name="localhost.localdomain">  
  <Target name="localhost.localdomain" type="Host">  
   <Collection name="ll_host_config" file="632220B3E27D0E23272272388F7F490E-ll_host_config.xml" collection_timestamp="2011-10-24 11:24:35 Europe/Paris"/>  
  </Target>  
  <Target name="Oracle Configuration Manager" type="Oracle Configuration Manager">  
   <Collection name="livelink_config" file="18C5F0E75FBA45C2F26B6875756CC095-livelink_config.xml" collection_timestamp="2011-10-24 11:24:41 Europe/Paris"/>  
  </Target>  
  <Target name="/logiciels/bea/weblogic_11gR1PS3/osb" type="Oracle Home">  
   <Collection name="oracle_home_config" file="E467DF634AF09E46B27038E895597EC9-oracle_home_config.xml" collection_timestamp="2011-10-24 11:24:41 Europe/Paris"/>  
  </Target>  
  <Target name="/logiciels/bea/weblogic_11gR1PS3/oracle_common" type="Oracle Home">  
   <Collection name="oracle_home_config" file="FE0C9257EF1902E4FCC6AAD44CE3C15B-oracle_home_config.xml" collection_timestamp="2011-10-24 11:24:41 Europe/Paris"/>  
  </Target>  
  <Target name="/logiciels/bea/weblogic_11gR1PS3/wlserver_10.3" type="Oracle Home">  
   <Collection name="oracle_home_config" file="74DF426C81802519B07C903AB47D0EEF-oracle_home_config.xml" collection_timestamp="2011-10-24 11:24:42 Europe/Paris"/>  
  </Target>  
  <Target name="/logiciels/bea/weblogic_11gR1PS3/coherence_3.6" type="Oracle Home">  
   <Collection name="oracle_home_config" file="84D962D5FA0E96EC2F99D964DC910923-oracle_home_config.xml" collection_timestamp="2011-10-24 11:24:42 Europe/Paris"/>  
  </Target>  
 </Targets>  

Copier le JAR de capture sur une machine qui a un accès internet. Connecter vous au site du support avec un compte qui a un accès Support Identifier précisé lors de l’installation du produit (CSI).

Le fichier ocmconfig.jar est affiché dans la section ‘Files Uploaded‘. Aussitôt que le JAR est téléchargé, le SR est sauvegardé en DRAFT. Vous pouvez arrêter la saisie à ce nouveau avec un Cancel (il ne faut  conserver le SR en DRAFT et pas le confirmer)

Vous pouvez vérifier le fichier téléchargé en éditant le SR en DRAFT via la Home Page du site support en éditant le SR. Vous pouvez également voir quelques minutes après la capture prise en compte sur l’onglet suivant (Attention, la 1^er capture peut être longue : 24 à 48 H ).

Une capture permet de remonter toutes les informations dans la vue Targets. La vue Systems ne remontant que les informations associées aux domaines. La vue Projets étant un regroupement d’informations Systems à définir manuellement via l’IHM de metalink. Ces vues sont visibles via l’onglet Dashboard (si elles n’apparaissent pas, il faut customiser la vue pour les faires apparaîtrais).

Si cette vue n’apparaît pas, il vous faut customiser l’IHM pour le faire apparaître.

Si votre capture n’est toujours pas téléchargée au bout de quelques heures, vous pouvez ouvrir un autre SR pour qu’un ingénieur support examine le problème.

Un système est décrit de manière générique comme une collection de composants logiciels et matériels. Un système peut s'étendre sur plusieurs machines physiques. Mais généralement pour Fusion Middleware, un système correspond à un ORACLE_HOME ou un domaine WebLogic.

L’exemple présenté ci-dessous montre une capture d’un domaine OSB avec une instance d’administration montée lors de la capture.

  

Le détail d’un domaine permet de voir les instances associées.

  

Vue Hosts

  

Ainsi que le détail sur l’instance et les problèmes potentiels

Nous pouvons également voir les composants déployés sur le domaine.

  

Composant logiciel installé. C’est l’élément de granularité la plus fine des captures. On y voit les produits comme les librairies utilisées dans les domaines.

Vous pouvez définir un projet afin de regrouper les informations de capture, intervenant et date de mise en place (customiser la vue du DashBoard pour faire apparaître la fenêtre si pas déjà présente).

Un Projet est un regroupement de System. Il faut donc avoir une capture contenant des informations sur les domaines (voir Capture).

  

Cela permet de synthétiser les remontées d’information issue du support sur l’ensemble des captures effectué associé au projet. On peut également ouvrir un SR associé au projet sans devoir redéclarer les informations de la plateforme.

La vue PATCH (à customiser dans l’onglet Dashboard si pas déjà présente) permet de voir les PATCH à appliquer globalement sur l’ensemble des plateformes issues des différentes captures.

  

Ou spécifique à une entrée d’une vue Projet Target ou System.

Avec la possibilité de valider si les PATCH trouvés sont en conflit avec la plateforme cible et de récupérer un ensemble de PATCH à appliquer en les regroupant.

 COMPARAISON

Sur plusieurs captures, vous pouvez vérifier les différences de plateforme avec l’option de comparaison d’historique.

  

Afin d’avoir une vue synthétique des captures réalisées (peut-être beaucoup de projets pour un même Customer ID) vous avez la possibilité de les regrouper et les filtrer par type.

  

Vous pouvez également filtrer par vue

Un Projet est rattaché à un Système qui correspond à un domaine est non à une installation Oracle. On ne peut donc pas créer de Projet générique à une installation, mais forcément à un projet déployé sur un domaine.

Les installations ne sont visibles que dans la vue Target sur les types Oracle Home et par déclinaison de produits (pas de Middleware Home global).

  

Pour simplifier le regroupement de paramétrage issu des collectes, nous pouvons les regrouper par projet (présenté dans les chapitres précédents). Activer la vue projet dans l’onglet Dashboard

  

Installer le produit SOA Suite, et créer un domaine associé déployant toutes les ressources issues du Framework éditeur. Effectuer une capture et remonter là dans Metalink. Une fois que la capture apparaît dans la vue Targets et Systems, créer une entrée dans la vue Projet.

  

  

Sélectionner les domaines capturés à associer au Projet :

  

  

Et les dates de début et fin de projet :

  

Vous obtenez ainsi un ensemble de configuration utilisable pour ouvrir des SR ou trouver des PATCH.

  

Pour ouvrir un SR, il suffit de d’aller dans un projet et de créer un SR

  

Pour les PATCH, il faut passer par la vue System ou Target.

---

Lors de l’utilisation d’une file JMS, les messages sont persistés dans une zone de sauvegarde appelée Store qui permet de conserver et reprendre les données lors de panne d’instance. Le message est sauvegardé lors de la mise en file, puis supprimé lors de sa consommation.

Nous avons deux types possibles :

ü  FileStore     Persistance en fichier.

ü  JDBCStore     Persistance en base.

---

Le JDBC Store nécessite la création d’un DataSource associé à la base qui va héberger les messages. Le DataSource à créer doit être non XA car c’est l’implémentation JMS Weblogic qui supporte l’aspect transactionnel (de toutes les façons, l’IHM de création d’un JDBCStore ne fait apparaître que les DataSource non XA).

Il faudra donc créer un DataSource spécifique pour le JDBCStore non partagé par les applications déployées. Prendre un driver non XA et décocher l’option Supports Global Transactions.

Le JDBCStore n’utilise qu’au maximum 3 connexions et en conserver 2 (connexion qu’il ne relâche jamais et ne remet donc pas dans le pool). Il faudra donc prévoir une taille de pool avec la considération de 3 connexions par JDBCStore.

Comme la connexion est maintenue par la ressource du Store, on pourra mettre un timeout sur la connexion avec le paramètre Statement Timeout afin de libérer celle-ci en cas de non-réponse de la base. Cela s’avère nécessaire lors de l’utilisation du MultiDataSource avec la perte d’un nœud RAC associé à la tombée d’une machine. Dans ce cas de figure, les threads associés à la gestion JMS sont bloqués sur l’accès base en non-réponse.

  

Dans le cas d’un MutliDataSource, ne pas mettre de load balancing, mais plutôt le failover. Dans le cas de forte volumétrie, dissocier les DataBase et multiplier les serveurs JMS et JDBC Store.

Un problème intervient sur les JDBC Store lorsque la base tombe u. Dans ce cas de figure, le DataSource passe en status Failed v et si un message passe sur la file, le Store se met en échec w. Lors de la remontée de la base x, le DataSource se remet automatiquement y, mais pas le Store z. Il faut dans ce cas remonter l’instance Weblogic.

Pour les indisponibilités passagères (problème réseau, etc ), lorsque la connexion du DataSource devient inaccessible, un mécanisme de retry de connexion du JDBCStore est mis en jeux. Par défaut, l’attente avant le retry est de 1s. On pourra modifier cette valeur avec un maximum de 15s avec le properties JAVA suivant. On pourra donc positionner cette valeur à 10.

Concernant les DataSource, il est préférable de les paramétrer avec un test systématique et un Trust de connexion à 0 (temps de durée de validation d’une connexion testé) afin d’être sur que la connexion utilisée est valide (sans échec possible de requêtage).

Si la base n’est pas en RAC, vous pouvez mettre un Connection Creation Retry Frequency à 600 afin de se reconnecter ultérieurement (attention recommandation de la documentation Oracle mais impliquant une accumulation de transaction avec un dépassement de capacité mémoire ou autre dysfonctionnement possible)

Le JDBCStore utilise une table qu’il crée au démarrage de l’instance via des scriptes DDL contenu dans  MW_HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jar. On peut les créer manuellement comme le présente l’exemple suivant (en remplaçant le $TABLE par le nom de la table) :

Concernant le nom de la table la convention est la suivante :

Le Prefixe Name permet de n’avoir qu’une seule table distincte par Store.

Lorsque la base n’est plus disponible et que le Store passe en Failed, Les messages passent d’un status visible en send transaction. Il faut dans ce cas de figure, exporter les messages en mémoire dans un fichier puis les re importer après redémarrage de la base et de l’instance WLS.

---

Par défaut, Weblogic déclare un File Store même si l’on n’a pas déclaré de Store pour le serveur JMS (Store utilisé pour les transactions log JTA ainsi que les messages JMS). Ce Store par défaut se trouve dans le répertoire :

Lorsque l’on déclare un FileStore, on peut le spécifier dans un répertoire global à toutes les instances de préférence partagée par toutes les machines de façon à effectuer des reprises en cas de panne machine. Chaque instance devant utiliser un FileStore différent sous peine d’avoir des incohérences dans la diffusion des messages (il vaut mieux créer le répertoire au par avance avant de créer la ressource).

Le nom fichier du FileStore aura la convention suivante ou #### représente un nombre unique de différentiations (dans le cas de nom identique).

Le File Store définit 3 types de politiques d’écriture qui peut être conservée avec le mode par défaut qui est le Direct-Write (utilisant une librairie native I/O wlfileio2 ).

Pour le répertoire partagé, préférer un disque SAN plutôt que NFS qui n’a pas forcement de support pour les écritures directes et qui peuvent entraîner des lock d’écritures. Si vous avez la possibilité,  essayer de placer les fichiers sur des disques dédiés (voir plateaux) pour de la forte volumétrie afin de dissocier les accès disque.

La taille des fichiers issue du FileStore est gérée par le Store lui-même qui peut s’agrandir selon les besoins, mais jamais diminuer. Prévoir donc un FileSystem conséquent par rapport à votre charge.

---

L’action de persistance (File ou Base) est un paramétrage qui peut se définir à plusieurs niveaux.

ü  Dans le code client.

La durée de rétention est différente selon les cas. Dans le cas des Topic, le message est persisté jusqu’a ce que tous les souscripteurs ont consommé le message. Dans le cas des Queues, le message est retiré du Store une fois consommé. Dans tous les cas, le message est retiré en cas d’expiration ou suppression administrative.

Chose importante pour la volumétrie mémoire, les Header JMS sons conservés en mémoire, ainsi qu’un certain nombre de messages même s’ils sont persisté dans le Store (pour des considérations de performance).

---

Le choix entre les deux types de Store peut se résumer à un besoin de performance ou de fiabilité et de souplesse de reprise sur erreur.

Le mode File est plus performant et plus tolérant par rapport à une indisponibilité de base (à condition d’avoir un File System performant sans perte au niveau des caches en écriture). Il a le désavantage de devoir mettre en place un File System partagée pour les reprises en cas de panne machine. On le choisira pour de fortes volumétries et des contraintes de temps de réponse.

Le mode JDBC à l’avantage d’avoir un mode centralisé natif (via la database) et facilite les reprises en cas de panne machine, mais avec des temps moins performants par rapport au mode File. Il supporte difficilement les pertes momentanées des bases avec comme contrainte de devoir redémarrer les instances. On le choisira pour des besoins de sécurisation sans avoir de contrainte de temps de réponse (de préférence à utiliser avec une base clustérisée pour éviter les indisponibilités et redémarrage intempestif).