Une des questions qui revient souvent à propos du GridControl, c’est « Comment le sécuriser ou plutôt le fiabiliser ? ». Si vous aussi, vous vous posez cette question, voici quelques réflexions et liens qui vous seront utiles :
- Pour ce qui est du référentiel OMS (la base de données), on imagine des solutions très simplement comme RMAN, Flash Recovery Area, Data Guard, Clusterware, RAC… Rien à dire ! Tout ça doit marcher (en fait, ça marche même !) ; il y a toutefois 2 questions auxquelles il faut que vous répondiez :
- Que doit-on faire après un RECOVER PITR sur le référentiel OMS ? C’est à dire lorsqu’on a malgré tout perdu avec une baie de stockage, par exemple, plusieurs transactions validées. En particulier, quel est l’impact sur les agents qui ont chargés des données dans l’OMS et pour lesquels ces données seront perdue ?
- Si le référentiel OMS ne nécessite pas l’achat de licences (cf la section « Infrastructure Repository Databases » de « Special-Use Licensing » de « Oracle Database Licensing Information – 10g Release 2 (10.2) – Part Number B14199-06« , qu’en est-il de l’utilisation de RAC ou de Data Guard sur ce référentiel ? (Je ne connais pas la réponse et suis intéressé si vous arrivez à y répondre !)
- Pour ce qui est du serveur d’applications et de l’application Enterprise Manager, beaucoup de choses sont possibles :
- Commençons par ce qui ne l’est pas (au moins avec Enterprise Manager 10.2.0.2) ! Vous ne pourrez par changer le nom de la machine sur laquelle vous avez déjà installé Enterprise Manager. Il faudra desinstaller et réinstaller l’application. Pour vous en assurer, recherchez avec les mots clés « How to change OMS hostname post install » sur http://metalink.oracle.com.
- En revanche, il est biensûr possible d’installer le GridControl et de le forcer à ce qu’il utilise un « hostname virtuel » pour ensuite le sécuriser avec un clusterware (y compris celui d’Oracle). Vous pouvez vous reportez à la section « 3.8 Using Virtual Hostnames for Active/Passive High Availability Environments in Enterprise Manager Database Control » du Guide utilisateur « Oracle Enterprise Manager Advanced Configuration – 10g Release 2 (10.2) – Part Number B16242-03« . Vous y apprendrez qu’il suffit d’ajouter l’argument ORACLE_HOSTNAME=[vhost] lorsque vous démarrez « runInstaller »
- Mieux que de gérer une bascule, il est également possible de mettre en place 2 OMS sur le même référentiel OMS. Pour comprendre de quoi il s’agit, reportez-vous à la Figure 3-3 du Guide utilisateur « Oracle Enterprise Manager Advanced Configuration – 10g Release 2 (10.2) – Part Number B16242-03« . Dans ce cas, il n’est pas nécessaire de gérer des bascules. Par contre, reste la question de savoir comment accéder indifféremment les machines 1 ou 2 (ou 3 ou 4…) de l’OMS !
- Pour régler ce dernier point, sachez qu’il est possible d’utiliser un LoadBalancer devant l’OMS et ainsi assurer la continuité des accès au service. A partir de ces méthodes vous arriverez également au moyen d’un reverse-proxy à mettre en place des adresses IP virtuelles (VIP) . Pour en savoir plus à propos de ce type de configurations, reportez-vous aux sections « 3.6.1 Load Balancing Connections Between the Management Agent and the Management Service » et « 3.6.2 Load Balancing Connections Between the Grid Control Console and the Management Service » de « Oracle Enterprise Manager Advanced Configuration – 10g Release 2 (10.2) – Part Number B16242-03« . Vous pouvez également rechercher ce qui suit « How to Configure Grid Control 10.2 behind a server load balancer (SLB) » sur « http://metalink.oracle.com« .
Voilà, avec un peu d’efforts, vous arriverez sans trop de difficulté à fiabiliser votre Enterprise Manager Grid Control. Ne restera plus, et c’est une autre histoire, qu’à gérer les identités et les accès ! ou même déployer les agents sur toutes les cibles. Alors, retournons au travail !
GarK!
