CREATION D'UNE ACTIVE DATA GUARD
(UNE PROCEDURE COMPACTE)

I - Introduction
Comme il est indiqué dans le titre de cet article, les tests dont nous vous livrons le compte-rendu, ne sont possibles que sur Oracle Database 11g. Nous avons utilisé la release 11.1.0.6.
Ce sont les nombreuses améliorations apportées par Oracle avec Oracle Database 11g qui ont facilité et simplifié la tâche et permis de rendre la procédure (et en particulier le script rman de création de la standby) aussi compacte.

II - Pré-requis
i) Les bases de données de production (primaire) et standby doivent s'exécuter dans la même release d'Oracle Database 11g, Enterprise Edition
ii) L'option Oracle Active Data Guard doit être installée (Elle est payante et pas présente dans la vue v$option)
iii) La base de données primaire doit être en mode archive log.

III - Configuration de tests

BD primaire BD standby
Serveur bund01 bund02
Base de données prod stdby

IV - Les étapes

Etape 1 : Activer l'option "force logging" sur la base de données primaire
SQL> alter database force logging ;
Database altered.

Etape 2 : S'assurer que la base de données primaire utilise un fichier spfile
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string +DATA/prod/spfileprod.ora

Etape 3 : Créer des standby redo logs sur la base de données primaire avec des numéros de groupes dans la continuité du dernier numéro de groupe des redo logs
SQL> col member for a40
SQL> select GROUP#, MEMBER from v$logfile ;
GROUP# MEMBER
---------- ------------------------------------------------------------
3 +DATA/prod/onlinelog/group_3.266.696684409
3 +DATA/prod/onlinelog/group_3.267.696684415
2 +DATA/prod/onlinelog/group_2.264.696684397
2 +DATA/prod/onlinelog/group_2.265.696684403
1 +DATA/prod/onlinelog/group_1.262.696684385
1 +DATA/prod/onlinelog/group_1.263.696684391

SQL> alter database add standby logfile group 4 ('+DATA/prod/sby_log01_01.rdo','+DATA/sby_log01_02.rdo') size 50M;
Database altered.

SQL> alter database add standby logfile group 5 ('+DATA/prod/sby_log02_01.rdo','+DATA/sby_log02_02.rdo') size 50M;
Database altered.

SQL> alter database add standby logfile group 6 ('+DATA/prod/sby_log03_01.rdo','+DATA/sby_log03_02.rdo') size 50M;
Database altered.

Attention : il est possible de placer les standby redo logs directement dans le répertoire +DATA. Cependant cela entraîne des conflits comme le montrent les messages suivants que nous avons expérimentés :
RMAN-05536: auxiliary logfile name +DATA/sby_log01_01.rdo conflicts with a file used by the target database
RMAN-05536: auxiliary logfile name +DATA/sby_log01_02.rdo conflicts with a file used by the target database
RMAN-05536: auxiliary logfile name +DATA/sby_log02_01.rdo conflicts with a file used by the target database
RMAN-05536: auxiliary logfile name +DATA/sby_log02_02.rdo conflicts with a file used by the target database
RMAN-05536: auxiliary logfile name +DATA/sby_log03_01.rdo conflicts with a file used by the target database
RMAN-05536: auxiliary logfile name +DATA/sby_log03_02.rdo conflicts with a file used by the target database

Etape 4 : Mettre à jour le fichier tnsnames du serveur primaire
Il s'agit d'ajouter les lignes suivantes :
STDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = bund02 )(PORT = 1521))
(CONNECT_DATA =
(SID = stdby)
)
)

Etape 5 : Copier le fichier de mots de passe de la base de données primaire dans le répertoire $ORACLE_HOME/dbs de la standby en lui donnant le nom orapwstdby.
[oracle@bund01 dbs]$ scp -P22 orapwprod oracle@bund02:/u01/app/oracle/product/11.1.0/db_1/dbs/orapwstdby
The authenticity of host 'bund02 (192.168.1.130)' can't be established.
RSA key fingerprint is a3:55:7e:58:c4:66:9d:2f:77:f3:20:2b:c9:75:f5:c7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bund02,192.168.1.130' (RSA) to the list of known hosts.
oracle@bund02's password:
orapwprod
[oracle@bund01 dbs]$

Etape 6 : Mettre à jour les fichiers listener.ora et tnsnames.ora du serveur standby
Il faut leur ajouter les lignes suivantes.
Listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(global_dbname = stdby)
(oracle_home = /u01/app/oracle/product/11.1.0/db_1)
(sid_name = stdby)
)
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/11.1.0/db_1)
(PROGRAM = extproc)
)
)

tnsnames.ora
STDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = bund02.knmc.local )(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stdby)
)
)

PROD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = bund01.knmc.local )(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = prod)
)
)

Etape 7 : Créer le fichier initstdby.ora sur le serveur standby (bund02)
Le fichier doit être stocké dans le répertoire $ORACLE_HOME/dbs et ne contient qu'une seule ligne avec le paramètre db_name. Il faut bien noter que le db_name de la standby est le même que pour la primaire.
db_name=prod

Etape 8 : Sur la standby, créer les répertoires et sous-répertoires devant contenir les fichiers de trace d'audit
Ces créations doivent être faites dans le répertoire $ORACLE_BASE/admin. Les répertoires et sous-répertoires sont : $ORACLE_BASE/admin/stdby, $ORACLE_BASE/admin/stdby/adump

[oracle@bund02 admin]$ mkdir –p stdby/adump

Etape 9 : Sur la primaire, créer le fichier rman de création de la standby.
[oracle@bund01 db_1]$ cat create_stdby.rman
connect target sys/oracleMdp@prod
connect auxiliary sys/ oracleMdp @stdby
run {
allocate channel p1 type disk ;
allocate auxiliary channel s1 type disk ;
duplicate target database for standby from active database
spfile
parameter_value_convert 'prod','stdby'
set db_unique_name='stdby'
set db_file_name_convert='/prod/','/stdby/'
set log_file_name_convert='/prod/','/stdby/'
set control_files='+DATA/stdby/control01.ctl','+DATA/stdby/control02.ctl'
set log_archive_max_processes='5'
set fal_client='stdby'
set fal_server='prod'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(prod,stdby)'
set log_archive_dest_2='service=prod lgwr async valid_for=(online_logfiles, primary_role) db_unique_name=stdby'
set log_archive_dest_state_2='enable'
set log_archive_format='stdby_%t_%s_%r.arc'
;
sql channel p1 "alter system set log_archive_config=' 'dg_config=(prod,stdby' '";
sql channel p1 "alter system set log_archive_dest_2=' 'service=stdby lgwr async valid_for=(online_logfiles, primary_role) db_unique_name=prod' '";
sql channel p1 "alter system set log_archive_max_processes=5";
sql channel p1 "alter system set fal_client=''prod' '" ;
sql channel p1 "alter system set fal_server=''stdby' '";
sql channel p1 "alter system set standby_file_management=AUTO";
sql channel p1 "alter system set log_archive_dest_state_2=enable"
sql channel p1 "alter system archive log current" ;
sql channel s1 "alter database recover managed standby database using current logfile disconnect" ;
}


Etape 10 : Sur le serveur standby, mettre à jour les variables d'environnements et démarrer la standby avec l'option nomount
[oracle@bund02 db_1]$ export ORACLE_SID=stdby
[oracle@bund02 db_1]$ export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
[oracle@bund02 db_1]$ sqlplus / as sysdba
SQL> startup nomount

Etape 11 : Sur le serveur primaire, exécuter le script rman
[oracle@bund01 db_1]$ rman cmdfile=create_stdby.rman log=create_stdby.log

Notes
i) Le script de création effectue les actions suivantes :
- Arrêter la base standby et la re-démarrer avec le fichier spfile nouvellement créé
- Créer un fichier standby controlfile sur le serveur primaire et la copier sur le serveur standby
- Créer une base de données clone sur le serveur standby à l'aide d'Oracle RMAN cloning
- Convertir la base de données clonée en base de données standby physique.

ii) Le processus de creation de la standby physique peut prendre un certain temps, fonction de la taille de la base de données primaire.
iii) le fichier de log se termine par un message d'erreur que l'on peut ignorer
sql statement: alter system archive log current

released channel: p1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql command at 09/06/2009 03:11:04
RMAN-06033: channel s1 not allocated

Recovery Manager complete.

iv) Pour une raison que nous n'avons pas pu déterminer, la standby n'est pas mise en mode "récupération managée".

Etape 12 : Paramétrer Active Data Guard sur le serveur standby
Voir notre précédent post.

Et voilà la simplification que les nombreuses améliorations apportées par Oracle 11g dans Oracle Data Guard ont rendu possible. Mais il y a une autre simplification tout aussi importante. Elle concerne l'utilisation de Dataguard pour le rafraîchissement des environnements de pré-production, de tests et de développement. Cette simplification est portée par une nouvelle fonctionnalité qui porte le nom de snapshot standby. Nous traiterons ce sujet dans notre prochain post.
A bientôt donc …

ACTIVE DATA GUARD
VERIFICATION ET PARAMETRAGE DE L'ACTIVE DATA GUARD SOUS ORACLE DATABASE 11G

Jusqu'à la version 10.2 d'Oracle, les bases de données standby physiques ne pouvaient fonctionner que dans deux modes exclusifs :
- Ouverture en lecture seule pour permettre que les utilisateurs puissent exécuter des requêtes d'intérrogation et ainsi décharger en partie la base de données de production.
- Ouverture en récupération managée pour permettre l'application des données de redo que la standby reçoit de la base de données de production.
L'inconvénient majeur de ce fonctionnement en deux modes exclusifs l'un de l'autre est que lorsque la standby physique est en lecture seule, les fichiers de log sont accumulés pour n'être appliqués qu'une fois que la standby est remise dans le mode "récupération managée".
C'est, entre autres, pour cette raison qu'Oracle a introduit l'Active Dataguard en 11g. Cette nouvelle fonctionnalité permet aux utilisateurs d'avoir un accès en lecture seule aux bases de données standby physiques pendant que le transport des logs et leur application continuent sur ces mêmes bases de données.
"Active Data Guard" est mentionnée comme une nouvelle option payante dans les brochures du produit Oracle Database 11g.
Et on pourrait s'attendre à la retrouver dans la vue v$option lorsque cette option est activée. Or il n'en est rien. Il se pose dès lors la question de savoir comment vérifier la présence de cette option et comment la paramétrer/activer.
C'est l'objet du présent article.

Vérification d'Active Data Guard
La vérification de la présence de l'option "Active Data Guard" se fait sur la standby database à l'aide de la requête ci-dessous.
SQL> SELECT 'Active Data Guard is Enabled' ADG
2 FROM v$MANAGED_STANDBY A, V$DATABASE B
3 WHERE A.PROCESS LIKE 'MRP%' AND B.OPEN_MODE='READ ONLY';

ADG
----------------------------
Active Data Guard is Enabled

Si cette requite affiche comme réponse "Active Data Guard Enabled" (comme c'est le cas ci-dessus) alors on peut en conclure qu'Active Data Guard est "activée.
Si par contre la réponse est "no rows selected" comme ci-dessous, alors l'option n'est pas activée et il faudra la paramétrer.
SQL> SELECT 'Active Data Guard is Enabled' ADG
2 FROM v$MANAGED_STANDBY A, V$DATABASE B
3 WHERE A.PROCESS LIKE 'MRP%' AND B.OPEN_MODE='READ ONLY';

no rows selected


Paramétrage d'Active Data guard
Plusieurs étapes sont nécessaires pour paramétrer Active Data Guard.

1°) Vérifier si la standby est en récupération managée
SQL> select process, status from v$managed_standby ;
PROCESS STATUS
--------- ------------
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
MRP0 APPLYING_LOG
6 rows selected.

2°) Si c'est le cas comme dans l'exemple ci-dessus (la présence du processus MRP0 l'atteste), arrêter la récupération managée et vérifier l'effectivité de l'arrêt.
SQL> alter database recover managed standby database cancel ;
Database altered.
SQL> select process, status from v$managed_standby ;
PROCESS STATUS
--------- ------------
ARCH CONNECTED
ARCH CONNECTED
ARCH CLOSING
ARCH CONNECTED
ARCH CONNECTED
RFS IDLE
RFS IDLE
RFS IDLE
8 rows selected.

3°) Ouvrir la standby avec la commande alter et l'option open
SQL> alter database open
Note : Une solution alternative consiste à arrêter la standby et à la re-démarrer comme une bd classique
SQL> shutdown
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 857903104 bytes
Fixed Size 1303272 bytes
Variable Size 486542616 bytes
Database Buffers 364904448 bytes
Redo Buffers 5152768 bytes
Database mounted.
Database opened.

4°) Re-démarrer la récupération managée avec l'option "using current logfile".
SQL> alter database recover managed standby database using current logfile disconnect ;
Database altered.

5°) vérifier que la récupération managée a démarré et que l'Active Dataguard est "activée"
SQL> select process, status from v$managed_standby ;
PROCESS STATUS
--------- ------------
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
MRP0 APPLYING_LOG
6 rows selected.

SQL> SELECT 'Active Data Guard is Enabled' ADG
2 FROM v$MANAGED_STANDBY A, V$DATABASE B
3 WHERE A.PROCESS LIKE 'MRP%' AND B.OPEN_MODE='READ ONLY';

ADG
----------------------------
Active Data Guard is Enabled

Voilà comment gérer la nouvelle fonctionnalité "Active Data Guard" dans Oracle Database 11g.
Nous verrons dans notre prochain post, une procédure compacte (simplifiée) de mise en place d'une configuration "Active Data Guard".
A bientôt donc !

DATAGUARD ET RAFRAICHISSEMENT DES ENVIRONNEMENTS
(3E PARTIE)

Cet article a été rédigé en collaboration avec M. Akli IMARAZENE, Consultant et DBA.

V - Les étapes de la deuxième phase
Il s'agit de réintégrer la base de pré-production et de tests dans son rôle de standby database.

Etape 1 : Re-démarrer la database activée avec les options mount et force et procéder à son flashback jusqu'au restore point
SQL> startup mount force
SQL> archive log list ;
SQL> flashback database to restore point bf_app_test ;

Etape 2 : Convertir la database activée en physical standby database et la re-démarrer avec les options mount et force
SQL> alter database convert to physical standby ;
SQL> startup mount force

Etape 3 : Lancer la récupération managée sur la standby
SQL> alter database recover managed standby database disconnect ;

Etape 4 : Activer le transport des logs archivés depuis la primary vers la standby et noter le numéro de séquence courante sur la primary
Sur la primary
SQL> alter database set log_archive_dest_state_2=enable scope=both ;
SQL> select database_role, open_mode from v$database ;
SQL> alter system switch logfile ;
SQL> archive log list ;

Etape 5 : Vérifier que les logs archivés sont bien appliqués sur la standby
SQL> select database_role, open_mode from v$database ;
SQL> archive log list ;

Etape 6 : Vérifier l'application des logs archivés en temps réel dans le fichier d'alertes de la standby database
$ tail –f /u01/app/oracle/product/10.2.0/db_1/dbs/alertstbyprod.log

Dans l'un de nos prochains posts, nous verrons comment Oracle a permis de simplifier davantage cette même procédure dans Oracle Database 11g avec la nouvelle fonctionnalité snapshot standby.

Webographie
Oracle Data Guard Concepts and Administration 10g Release 2 (10.2) – Chapter 12.6 : Using a Physical Standby Database for Read/Write Testing and Reporting

Fin ./.

DATAGUARD ET RAFRAICHISSEMENT DES ENVIRONNEMENTS
(2E PARTIE)

Cet article a été rédigé en collaboration avec M. Akli IMARAZENE, Consultant et DBA.

IV - Les étapes de la première phase

Etape 1 : S'assurer que la primary et la standby databases sont synchronisées
i) Sur la primary
$ export ORACLE_SID=iprod
$ export ORACLE_BASE=/u01/app/oracle
$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
$ sqlplus / as sysdba
SQL> archive log list
SQL> select database_role, open_mode from v$database ;

ii) Sur la standby
$ export ORACLE_SID=stbyprod
$ export ORACLE_BASE=/u01/app/oracle
$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
$ sqlplus / as sysdba
SQL> archive log list
SQL> select database_role, open_mode from v$database ;

Les lignes "Current log sequence" des commandes "archive log list" doivent afficher le même numéro de séquence sur les deux bases de données.

Etape 2 : S'assurer que la standby database applique bien les redo logs
i) Sur la primary
SQL> alter system switch logfile ;
SQL> archive log list

ii) Sur la standby
SQL> archive log list

Les lignes "Current log sequence" des commandes "archive log list" doivent afficher le même numéro de séquence sur les deux bases de données.

Etape 3 : Activer la flashback database sur la standby database
Sur la standby
SQL> alter system set db_recovery_file_dest_size=5G scope=both ;
SQL> alter system set db_recovery_file_dest='/u01/app/oracle/flashback' scope=both ;
SQL> show parameter db_recovery
SQL> shutdown immediate ;
SQL> startup mount ;
SQL> alter database flashback on

Etape 4 : Arrêter l'application des redos sur la standby database et y créer un restore point
SQL> alter database recover managed standby database cancel ;
SQL> create restore point bf_app_test guarantee flashback database ;

Etape 5 : Archiver le log courant sur la primary database afin d'avoir les archived logs jusqu'au SCN du restore point et différer le transport des redo logs vers la standby database
SQL> alter system archive log current ;
SQL> archive log list ;
SQL> show parameter log_archive_dest_state_2
SQL> alter system set log_archive_dest_state_2=DEFER ;
SQL> show parameter log_archive_dest_state_2

Etape 6 : Activer la physical standby database (la transformer en base de données classique), mettre son mode de protection en "maximize performance" et l'ouvrir
SQL> alter database activate standby database ;
SQL> startup mount force ;
SQL> alter database set standby database to maximize performance ;
SQL> alter database open ;

A partir de maintenant, les équipes de tests et de développement peuvent disposer de la base de données pour leurs tests de la journée.

A suivre …

DATAGUARD ET RAFRAICHISSEMENT DES ENVIRONNEMENTS
(1ERE PARTIE)

Cet article a été rédigé en collaboration avec M. Akli IMARAZENE, Consultant et DBA.

I - Introduction
Une configuration Dataguard a deux fonctions principales :
- Assurer la protection des données de l'entreprise ;
- Concourir à la haute disponibilité de la base de données de production par la capacité de la base de secours (standby) à participer à une permutation de rôles avec la base de production (primary) lors de maintenances planifiées ou suite à une panne de la base de données de production.
Il y une troisième fonction beaucoup moins connue que l'on peut faire jouer à une configuration Dataguard : celle de servir au rafraîchissement des bases de données de pré-production, de tests et/ou de développement.
Il y a quelques jours, un ami et collègue m'expliquait toutes les difficultés qu'il a eues à faire accepter par ses collègues DBAs et sa hiérarchie la mise en œuvre d'une configuration Dataguard pour assurer le rafraîchissement d'une base de données de tests malgré l'argument incontestable que constitue l'extraordinaire gain en temps que cela allait procurer au quotidien.
La réaction des collègues et de la hiérarchie de mon collègue est d'autant plus surprenante que la maîtrise de la mise en œuvre d'une configuration Dataguard n'est pas une tâche insurmontable et que de toutes les manières la mise en œuvre sera précédée de tests approfondis devant déboucher sur une procédure écrite qui servira de base à un transfert de compétences à tous les DBAs de l'équipe.
Dans cet article, nous nous fixons comme objectif de décrire dans ses grandes lignes une procédure de rafraîchissement d'une base de données de tests à l'aide d'une configuration Dataguard.
Nous supposons que le lecteur maîtrise la mise en place d'une configuration Dataguard car ceci ne sera pas traité dans le présent article.
Nous commencerons par présenter la configuration Dataguard qui servira de base à nos propos ; ensuite nous décrirons les différentes étapes à franchir pour aboutir au résultat escompté.

II - Présentation de la configuration Dataguard
Notre configuration comprend une base de données de production dite primary database et une base de données de tests (la base de données qui a besoin d'être rafraîchie tous les matins) qui va jouer le rôle de base de données secours, dite standby database.
Primary Database
db_name : prod
instance_name : iprod
db_unique_name : uprod

Standby Database
db_name : prod
instance_name : stbyprod
db_unique_name : usprod

III - Principe d'utilisation d'une configuration Dataguard pour le rafraîchissement
Durant toutes les nuits, la standby database joue son rôle de base secours. Il reçoit les archive logs générés sur la primary database et les applique au fil de l'eau.
Tous les matins, le DBA en charge de la gestion de cette configuration exécute les actions suivantes :
- Activer la fonctionnalité flashback database sur la standby database ;
- Arrêter l'application des données de redo sur la standby database ;
- Créer un restore point sur la standby database ;
- Archiver le redo log courant sur la primary database ;
- Différer le transport des redo logs vers la standby database ;
- Transformer la standby database en base de données classique pouvant être utilisée pour des tests avec des opérations de lecture/écriture et enfin l'ouvre et la met à la disposition des équipes de tests.

Tous les soirs, le même DBA lance le rafraîchissement de la base de tests après avoir procédé à un flashback pour annuler toutes les mises à jour faites par les équipes de tests et après l'avoir réintégré dans son rôle de standby database. Les actions menées sont, dans l'ordre :
- Procéder au flashback de la base de données de tests jusqu'au restore point ;
- Convertir la base de données de tests en physical standby database et le mettre en mode récupération manager;
- Activer le transport des logs archivées vers la standby database où ils seront appliqués

A suivre …

Installation d'une machine virtuelle à l'aide d'Oracle VM Manager
(A partir de l'image iso du dvd OEL disponible via http)

Dans ce bref post, nous nous contentons de livrer la trame (les grandes lignes et les remarques) de l'installation d'une machine virtuelle à l'aide d'Oracle VM Manager à partir de l'image iso du DVD d'Oracle Enterprise Linux rendu disponible via un partage http.

I - Installation et démarrage du serveur apache
# yum install httpd
# service httpd start

II - Création d'un point de montage dans l'arborescence du daemon httpd et montage de l'image iso sur Oracle VM Server
# cd /var/www/html
# mkdir oelr5u3
# mount –o ro,loop /OVS/tmp/Enterprise-R5-U3-Server-i386-dvd.iso oelr5u3
# ls –l oelr5u3

III - Arrêt du firewall sur Oracle VM Server et vérification de l'accessibilité de l'image iso depuis le navigateur d'une autre machine du réseau LAN
# service iptables stop
# service iptables status
Vérification à partir d'un navigateur d'un poste local du LAN http://192.168.10.100/oelr5u3

IV - Création de la machine virtuelle à l'aide d'Oracle VM Manager

Pour une description synthétique de la création d'une nouvelle machine virtuelle à partir du support d'installation, nous invitons le lecteur à consulter le chapitre 6 "managing Virtual machines", sous-chapitre "Creating a new virtual machine from installation media" (Oracle VM Manager user's guide Release 2.1) à l'adresse http://download.oracle.com/docs/cd/E11081_01/doc/doc.21/e10901/vm.htm.

V - Remarques

i) Pendant la phase d'installation des binaires, Le clavier azerty (français) était très mal pris en charge par la console vnc. Il fallait une très grande gymnastique et une bonne dose de devinette pour trouver les bonnes touches. Les caractères 2 et 3 étaient tout simplement introuvables.

ii) Lors de l'installation, le système sera re-démarré plusieurs fois et à chaque fois, la console vnc se ferme automatiquement ; il faut la rouvrir.

iii) Une fois l'installation terminée le clavier français était mieux pris en charge. Par contre la connexion par putty prend beaucoup de temps (plusieurs minutes).
Mais la souris est toujours mal pris en charge par la console vnc.

iv) La création d'une machine virtuelle à l'aide d'Oracle VM Manager ne semble pas faire bon ménage avec la présence d'un deuxième repository monté et rendu disponible via ocfs2. Oracle VM Manager constatant que le deuxième repository dispose de plus d'espace, tente d'y stocker les fichiers de la nouvelle machine en cours de création. Mais pour une raison que nous n'avons pas réussi à déterminer, le serveur physique hébergeant Oracle VM Server redémarre automatique. Ceci constitue à notre avis un bug reproductible puisqu'il s'est produit plusieurs fois lors de nos tests.

En guise de conclusion provisoire sur Oracle VM

Nous arrivons aux termes de notre première série d'articles consacrés à la mise en œuvre de la technologie Oracle VM qui est au cœur du concept de déploiement rapide d'applications d'infrastructures. Les enjeux sont énormes : outre la consolidation des serveurs, le gain de temps dans le déploiement des bases de données peut être important. Nous reviendrons certainement sur le sujet dès qu'il y aura des nouveautés importantes.
Dans nos prochains post, nous traiterons de l'utilisation d'une configuration Dataguard pour le rafraîchissement des bases de données de pré-production, de tests et de développement.
A très bientôt donc.

Installation d'une machine virtuelle à l'aide de l'utilitaire virt-install
(A partir de l'image iso du dvd OEL)

Nous continuons notre exploration de la technologie Oracle VM. Dans le présent article, nous verrons comment installer une machine virtuelle motorisée par Oracle Enterprise Linux 5 Update 3.
Nous utilisons pour ce faire, le fichier image du dvd d'Oracle Enterprise Linux et l'outil virt-install. Ensuite nous ferons prendre en charge la machine nouvellement créée par Oracle VM Manager.

Etape 1 : télécharger OEL 5 Update 3 dans son format dvd et le mettre à disposition sur Oracle VM Server
i) Téléchargement du fichier image

Il faut se rendre sur le site d'Oracle e-delivery (http://edelivery.oracle.com/EPD/GetUserInfo/get_form?caller=LinuxWelcome). Le fichier image iso du dvd d'OEL5.3 recherché est compressé dans un fichier archive.
L'archive a les caractéristiques suivantes :
- Nom : V15414-01zip
- Libellé : Enterprise Linux Release 5 Update 3 for x86 (32 Bit) - DVD
- Taille : 2.7 Go
Après l'avoir téléchargé, déplaçons l'archive dans un répertoire dédié créé pour les besoins de notre test et dézippons-la.
# mkdir /OVS/tmp
# mv /root/V15414-01zip /OVS/tmp/
# cd /OVS/tmp
# unzip V15414-01zip
Il en résulte le fichier image proprement dit (Enterprise-R5-U3-Server-i386-dvd.iso). Pour économiser de la place disque, nous pouvons supprimer l'archive
# rm –f V15414-01zip

ii) Montage du fichier image sur un point de montage dédié (/tmp/oel5u3)

Créons ensuite un point de montage pour le fichier image et montons
# mount -o rw,loop /OVS/tmp/Enterprise-R5-U3-Server-i386-dvd.iso /tmp/oel5u3/

Etape 2 : Configurer le serveur NFS sur Oracle VM Server

La configuration que nous présentons ci-dessous est assez simple (juste ce qu'il faut). Le lecteur souhaiter approfondir la configuration d'un serveur NFS en prenant en compte en compte la problématique sécurité pourra consulter l'article détaillé publié par Gregory R. Kriehn à l'adresse http://optics.csufresno.edu/~kriehn/fedora/fedora_files/f7/howto/nfs.html.

i) Mettre à jour le fichier /etc/exports en y insérant le répertoire à partager et les adresses IP des machines autorisées à y accéder.

# cat /etc/exports
/tmp/oel5u3 192.168.10.100(rw,no_root_squash) 192.168.10.110(rw,no_root_squash) 192.168.10.10(rw,no_root_squash)

ii) Metrre à jour le fichier /etc/hosts.allow en y insérant les adresses IP des machines autorisées à bénéficier des services NFS en face des différents processus daemons participant aux services NFS

# cat /etc/hosts.allow
lockd:192.168.10.100,192.168.10.110,192.168.10.10
mountd:192.168.10.100,192.168.10.110,192.168.10.10
rpcbind:192.168.10.100,192.168.10.110,192.168.10.10
rquotad:192.168.10.100,192.168.10.110,192.168.10.10
statd:192.168.10.100,192.168.10.110,192.168.10.10

iii) Arrêter le firewall et re-démarrer les services portmap, nfslock et nfs afin de faire prendre en compte les modifications effectuées

[root@ovs01 ~]# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]

[root@ovs01 ~]# service nfslock restart
Stopping NFS locking: [ OK ]
Stopping NFS statd: [ OK ]
Starting NFS statd: [ OK ]

[root@ovs01 ~]# service portmap restart
Stopping portmap: [ OK ]
Starting portmap: [ OK ]

[root@ovs01 ~]# service nfs restart
Shutting down NFS mountd: [ OK ]
Shutting down NFS daemon: [ OK ]
Shutting down NFS quotas: [ OK ]
Shutting down NFS services: [ OK ]
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]

iv) Vérifier que le répertoire /tmp/oel5u3 est bien mis à disposition par le serveur NFS (une seule des deux commandes aurait suffi)
[root@ovs01 ~]# exportfs
/tmp/oel5u3 192.168.10.100
/tmp/oel5u3 192.168.10.110
/tmp/oel5u3 192.168.10.10

[root@ovs01 ~]# showmount -e
Export list for ovs01.knmc.local:
/tmp/oel5u3 192.168.10.110,192.168.10.10,192.168.10.100


Etape 3 : Exécuter l'utilitaire virt-install

Compte tenu du nombre de paramètres, nous avons préféré saisir la commande correspondante dans un fichier (create_vm.sh) que nous avons rendu exécutable.
[root@ovs01 ~]# cat create_vm.sh

virt-install \
--name vm01 \
--ram=1024 \
--file=/OVS/running_pool/vm01/system.img \
--file-size=10 \
--location=nfs:192.168.10.100:/tmp/oel5u3 \
--keymap=fr

Récapitulons les paramètres
Nom de la machine virtuelle à créer : vm01
Taille de la mémoire physique : 1024 Mo
Nom du fichier disque à allouer à la machine : =/OVS/running_pool/vm01/system.img
Taille du fichier disque à allouer : 10 Go
Emplacement où les binaires d'Oracle Enterprise Linux 5.3 sont mis à disposition : répertoire /tmp/oel5u3 du serveur NFS ayant comme adresse IP 192.168.10.100
Clavier utilisé : clavier de type français (azerty).

[root@ovs01 tmp]# ./create_vm.sh
Would you like to enable graphics support? (yes or no) yes

Starting install...
libvir: Xen Daemon error : GET operation failed:

VNC Viewer Free Edition 4.1.2 for X - built Jan 21 2009 14:35:26
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Wed Aug 26 05:28:29 2009
CConn: connected to host localhost port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
TXImage: Using default colormap and visual, TrueColor, depth 16.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

Wed Aug 26 05:29:17 2009
CConn: Throughput 14285 kbit/s - changing to hextile encoding
CConn: Throughput 14285 kbit/s - changing to full colour
CConn: Using pixel format depth 16 (16bpp) little-endian rgb565
CConn: Using hextile encoding

Wed Aug 26 05:33:47 2009
CConn: Throughput 20000 kbit/s - changing to raw encoding
CConn: Using raw encoding

Précisions importantes relatives à l'exécution de virt-install
i) Lors de l'exécution de l'utilitaire virt-install le message d'erreur suivant est affiché. Mais on peut l'ignorer :
libvir: Xen Daemon error : GET operation failed:

ii) Le re-démarrage suivant de la machine virtuelle nouvellement créée peut afficher les messages suivants que l'on peut également ignorer :
libvir: xen Daemon error: internal error domain information incomplete, missing kernel
Entity: line25: parser error : Opening and ending tag mismatch: os line 5 and domain

Entity: line26: parser error : Premature end of data in tag domain line 1

iii) L'exécution de virt-install inclut la phase d'installation d'Oracle Enterprise Linux qui ne comporte aucune difficulté particulière. Pour faire simple, nous avons choisi d'utiliser le serveur DHCP pour faire affecter une adresse IP à la nouvelle machine. Nous avons constaté qu'il en résultait que la nouvelle machine avait comme hostname new-host-20. Le curseur sur la nouvelle machine n'était pas très précis. En réalité, il y avait deux curseurs dans les fenêtres vnc.
Pour changer le hostname de la machine, on peut utiliser l'un des deux méthodes suivantes :
- Modifier les fichiers /etc/sysconfig/network et /etc/hosts et re-démarrer la machine (# service network restart)
- Modifier le fichier /etc/hosts et rediriger la commande echo "" dans le fichier /proc/sys/kernel/hostname ; par exemple
# echo "vm01" > /proc/sys/kernel/hostname

iv) Contrairement au fichier disque (system.img) qui est stocké dans le répertoire /OVS/running_pool/vm01, le fichier de configuration de la nouvelle machine virtuelle créée à l'aide de virt-install est localisé dans le répertoire /etc/xen et a pour nom vm01 (le même nom que la machine).
v) Il peut s'avérer nécessaire de re-démarrer la nouvelle machine une ou deux fois avant que le clavier français ne devienne vraiment opérationnel.
vi) Oracle VM Manager ne prend pas en charge par défaut la nouvelle machine. Une procédure complémentaire est nécessaire pour cela. C'est l'objet de l'étape suivante.

Etape 4 : Eteindre la nouvelle machine et l'importer dans Oracle VM Manager
i) Arrêter la nouvelle machine après avoir noté son domain-id
[root@ovs01 vm01]# xm list

Name ID Mem VCPUs State Time(s)
Domain-0 0 585 4 r----- 624.1
OVM_EL5U3_X86_OVM_MANAGER_PVM 1 2048 2 -b---- 355.4
vm01 2 1024 1 -b---- 415.0

[root@ovs01 vm01]# xm shutdown –w 2
Domain 2 terminated
All domains terminated
[root@ovs01 vm01]#

ii) Copier le fichier de configuration de la machine dans le répertoire /OVS/running_pool/vm01 en renommant la copie en vm.cfg.

# cp –p /etc/xen/vm01 /OVS/running_pool/vm01/vm.cfg

iii) Importer la nouvelle machine dans Oracle VM Manager en utilisant le menu Resources et le sous-menu "Virtual Machine Images"

iv) Approuver/valider la machine virtuelle ainsi importée.

Conclusion

Nous venons de vous montrer comment utiliser l'utilitaire virt-install pour créer une machine virtuelle sur un serveur Oracle VM Server à partir du fichier image dvd des binaires d'Oracle Enterprise Linux 5.3. Nous regrettons que cet utilitaire gère autrement le fichier de configuration de la machine virtuelle créée. Cependant il n'y a pas de difficulté particulière à l'importer dans Oracle VM Manager.
Dans notre prochain post, nous verrons comment créer une machine virtuelle toujours à partir d'un fichier image d'Oracle Enterprise Linux mais directement à l'aide d'Oracle VM Manager, ce qui nous éviterait d'avoir à l'importer ensuite dans Oracle VM Manager.