Effectuer d'autres tâches de cycle de vie
Un cluster étendu Oracle Fusion Middleware (FMW) fonctionne comme un cluster WebLogic standard. Son architecture et son comportement fondamentaux sont cohérents avec ceux des environnements WebLogic standard. En conséquence, la plupart des procédures de maintenance et d'exploitation suivies pour les systèmes WebLogic réguliers sont tout aussi pertinentes et applicables aux clusters étirés. Cela inclut, sans toutefois s'y limiter, les approches d'application de patches, d'exécution de mises à niveau non simultanées, de surveillance de l'état du système, de gestion des ressources et de dépannage. Bien qu'il puisse y avoir des considérations supplémentaires en raison de la répartition géographique inhérente à un cluster étendu, les paradigmes de maintenance de base restent les mêmes que ceux utilisés dans les déploiements WebLogic conventionnels.
Tenir à jour la configuration WebLogic
La plupart de cette configuration se trouve généralement sous le répertoire de domaine du serveur d'administration. Cette configuration est propagée automatiquement vers les autres noeuds du même domaine au démarrage des serveurs gérés ou lors de l'implémentation d'une modification.
Les autres artefacts résidant dans la configuration partagée, qui est locale pour chaque région, ne sont pas automatiquement synchronisés car ils ne sont pas gérés par WebLogic. Ces artefacts sont les suivants :
- Fichiers de fichiers de clés Java résidant dans le fichier
KEYSTORE_HOME - Plans de déploiement résidant dans
DEPLOY_PLAN_HOME - Fichier
Tnsnames.ora, s'il n'est pas géré à l'aide des modules DBClientData dans WebLogic. - Tout autre fichier personnalisé stocké sur le stockage partagé.
Si vous apportez des modifications à ces fichiers dans une région, copiez-les dans l'autre région pour assurer la cohérence de la configuration.
Appliquer des patches
Dans la mesure du possible, utilisez l'application de patches non simultanée pour réduire les temps d'arrêt.
Pour l'application de patches à une base de données, suivez les meilleures pratiques de Data Guard en appliquant d'abord le patch à la base de données de secours, le cas échéant. Le temps d'arrêt et la procédure d'application de patches requis pour la base de données varient en fonction du type de patch concerné.