Notes de version des services de données Sun Cluster 3.1 10/03

Problèmes liés à la documentation

Cette rubrique détaille les erreurs connues et les omissions de la documentation, de l'aide en ligne et des pages de manuel, et indique la marche à suivre pour y remédier.

Sun Cluster 3.1 Data Service for Oracle Parallel Server/Real Application Clusters Guide

Cette rubrique traite des erreurs et omissions contenues dans le document Sun Cluster 3.1 Data Service for Oracle Parallel Server/Real Application Clusters Guide.

Configuration minimale requise pour l'utilisation du système de fichiers de cluster

La rubrique “Requirements for Using the Cluster File System” indique à tort qu'il est possible de stocker des fichiers de données sur le système de fichiers de cluster. Il ne faut pas stocker de fichiers de données sur le système de fichiers de cluster. Ignorez donc toute référence aux fichiers de données dans cette rubrique.

Création de fichiers et répertoires spécifiques aux noeuds destinés à être utilisés avec le logiciel Oracle Parallel Server/Real Application Clusters sur le système de fichiers de cluster

Après l'installation du logiciel Oracle sur le système de fichiers de cluster, tous les fichiers du répertoire spécifiés par la variable d'environnement ORACLE_HOME sont accessibles à tous les noeuds du cluster.

Certaines installations peuvent requérir la maintenance d'informations spécifiques aux noeuds par des fichiers ou répertoires Oracle. Cette exigence peut être satisfaite par la création d'un lien symbolique dont la cible est un fichier ou répertoire d'un système de fichiers local du noeud. Ce type de système de fichiers n'existe pas dans le système de fichiers de cluster.

La création d'un lien symbolique implique donc l'allocation d'une zone sur un système de fichiers local. Avant de pouvoir créer des liens symboliques vers les fichiers de cette zone, les applications Oracle doivent d'abord pouvoir accéder aux fichiers. Les liens symboliques résidant sur le système de fichiers du cluster, les références aux liens sont les mêmes depuis tous les noeuds. Ainsi, tous les noeuds doivent avoir le même espace de nom pour la zone du système de fichiers local.

Procédure de création d'un répertoire spécifique à un noeud destiné à être utilisé avec le logiciel Oracle Parallel Server/Real Application Clusters sur le système de fichiers de cluster

Cette procédure doit être exécutée pour tous les répertoires devant maintenir des informations spécifiques aux noeuds. Les répertoires suivants doivent généralement maintenir ces informations :

$ORACLE_HOME /network/agent ;
$ORACLE_HOME /network/log ;
$ORACLE_HOME /network/trace ;
$ORACLE_HOME /srvm/log ;
$ORACLE_HOME /apache.

Pour de plus amples informations sur les autres répertoires susceptibles de devoir maintenir des informations spécifiques aux noeuds, reportez-vous à votre documentation Oracle.

Créez sur chaque noeud du cluster le répertoire local devant maintenir des informations spécifiques aux noeuds.
# mkdir -p rép_local
-p

Indique que tous les répertoires parents non existants sont créés d'abord.

rép_local

Spécifie le nom de chemin d'accès complet du répertoire que vous créez.

Sur chaque noeud du cluster, faites une copie locale du répertoire global devant maintenir des informations spécifiques aux noeuds.
# cp -pr rép_global parent_rép_local
-p

Indique que le propriétaire, le groupe, les modes d'autorisations d'accès, la date de modification, la date d'accès et les listes de contrôle d'accès sont préservés.

-r

Indique que le répertoire et tous ses fichiers, avec les éventuels sous-répertoires et leurs fichiers sont copiés.

rép_global

Spécifie le chemin d'accès complet du répertoire global que vous copiez. Ce répertoire réside sur le système de fichiers du cluster dans le répertoire défini par la variable d'environnement ORACLE_HOME.

parent_rép_local

Spécifie le répertoire du noeud local destiné à contenir la copie locale. Il s'agit du répertoire parent de celui que vous avez créé à l'Étape 1.

Remplacez le répertoire global copié à l'Étape 2 par un lien symbolique vers la copie locale du répertoire global.
1. Supprimez le répertoire global copié à l'Étape 2 à partir de n'importe quel noeud du cluster.
  # rm -r rép_global
  -r
  
  Indique que le répertoire et tous ses fichiers, avec les éventuels sous-répertoires et leurs fichiers sont supprimés.
  
  rép_global
  
  Spécifie le nom de fichier et le chemin d'accès complet du répertoire global que vous supprimez. Il s'agit du répertoire global copié à l'Étape 2.
2. Créez un lien symbolique depuis la copie locale du répertoire vers le répertoire global supprimé à l'Étape a à partir de n'importe quel noeud du cluster.
  # ln -s rép_local rép_global
  -s
  
  Indique qu'il s'agit d'un lien symbolique.
  
  rép_local
  
  Indique que le répertoire local créé à l'Étape 1 est la source du lien.
  
  rép_global
  
  Indique que le répertoire global supprimé à l'Étape a est la cible du lien.

Exemple 1–1 Création de répertoires spécifiques aux noeuds

Cet exemple montre les différentes étapes de création de répertoires spécifiques aux noeuds sur un cluster à deux noeuds. Ce cluster est configuré de la manière suivante :

La variable d'environnement ORACLE_HOME spécifie le répertoire /global/oracle.
Le système de fichiers local de chaque noeud est situé dans le répertoire /local.

Effectuez les opérations indiquées ci-dessous sur chaque noeud.

Pour créer les répertoires requis sur le système de fichiers local, exécutez les commandes suivantes :

# mkdir -p /local/oracle/network/agent

# mkdir -p /local/oracle/network/log

# mkdir -p /local/oracle/network/trace

# mkdir -p /local/oracle/srvm/log

# mkdir -p /local/oracle/apache

Pour faire des copies locales des répertoires globaux devant maintenir des informations spécifiques aux noeuds, exécutez les commandes suivantes :

# cp -pr $ORACLE_HOME/network/agent /local/oracle/network/.

# cp -pr $ORACLE_HOME/network/log /local/oracle/network/.

# cp -pr $ORACLE_HOME/network/trace /local/oracle/network/.

# cp -pr $ORACLE_HOME/srvm/log /local/oracle/srvm/.

# cp -pr $ORACLE_HOME/apache /local/oracle/.

Effectuez les opérations indiquées ci-dessous sur un noeud uniquement.

Pour supprimer les répertoires globaux, exécutez les commandes suivantes :

# rm -r $ORACLE_HOME/network/agent

# rm -r $ORACLE_HOME/network/log

# rm -r $ORACLE_HOME/network/trace

# rm -r $ORACLE_HOME/srvm/log

# rm -r $ORACLE_HOME/apache

Pour créer des liens symboliques depuis les répertoires locaux vers leurs répertoires globaux correspondants, exécutez les commandes suivantes :

# ln -s /local/oracle/network/agent $ORACLE_HOME/network/agent

# ln -s /local/oracle/network/log $ORACLE_HOME/network/log

# ln -s /local/oracle/network/trace $ORACLE_HOME/network/trace

# ln -s /local/oracle/srvm/log $ORACLE_HOME/srvm/log

# ln -s /local/oracle/apache $ORACLE_HOME/apache

Procédure de création d'un fichier spécifique à un noeud destiné à être utilisé avec le logiciel Oracle Parallel Server/Real Application Clusters sur le système fichiers de cluster

Cette procédure doit être exécutée pour tous les fichiers devant maintenir des informations spécifiques aux noeuds. Les fichiers suivants doivent généralement maintenir ces informations :

$ORACLE_HOME /network/admin/snmp_ro.ora ;
$ORACLE_HOME /network/admin/snmp_rw.ora.

Pour de plus amples informations sur les autres fichiers susceptibles de devoir maintenir des informations spécifiques aux noeuds, reportez-vous à votre documentation Oracle.

Sur chaque noeud du cluster, créez le répertoire local du fichier devant maintenir des informations spécifiques aux noeuds.
# mkdir -p rép_local
-p

Indique que tous les répertoires parents non existants sont créés d'abord.

rép_local

Spécifie le nom de chemin d'accès complet du répertoire que vous créez.

Sur chaque noeud du cluster, faites une copie locale du fichier global devant maintenir des informations spécifiques aux noeuds.
# cp -p fichier_global rép_local
-p

Indique que le propriétaire, le groupe, les modes d'autorisations d'accès, la date de modification, la date d'accès et les listes de contrôle d'accès sont préservés.

fichier_global

Spécifie le nom de fichier et le chemin d'accès complet du fichier global que vous copiez. Ce fichier a été installé dans le système de fichiers du cluster dans le répertoire défini par la variable d'environnement ORACLE_HOME.

rép_local

Spécifie le répertoire destiné à contenir la copie locale du fichier. Il s'agit du répertoire créé à l'Étape 1.

Remplacez le fichier global copié à l'Étape 2 par un lien symbolique vers la copie locale du fichier.
1. Supprimez le fichier global copié à l'Étape 2 à partir de n'importe quel noeud du cluster.
  # rm fichier_global
  fichier_global
  
  Spécifie le nom de fichier et le chemin d'accès complet du fichier global que vous supprimez. Il s'agit du fichier global copié à l'Étape 2.
2. Créez un lien symbolique depuis la copie locale du fichier vers le répertoire où le fichier global a été supprimé à l'Étape a à partir de n'importe quel noeud du cluster.
  # ln -s fichier_local rép_global
  -s
  
  Indique qu'il s'agit d'un lien symbolique.
  
  fichier_local
  
  Indique que le fichier copié à l'Étape 2 est la source du lien.
  
  rép_global
  
  Indique que le répertoire à partir duquel la version globale du fichier a été supprimée à l'Étape a est la cible du lien.

Exemple 1–2 Création de fichiers spécifiques aux noeuds

Cet exemple montre les différentes étapes de création de fichiers spécifiques aux noeuds sur un cluster à deux noeuds. Ce cluster est configuré de la manière suivante :

La variable d'environnement ORACLE_HOME spécifie le répertoire /global/oracle.
Le système de fichiers local de chaque noeud est situé dans le répertoire /local.

Effectuez les opérations indiquées ci-dessous sur chaque noeud.

Pour créer le répertoire local des fichiers devant maintenir des informations spécifiques aux noeuds, exécutez la commande suivante :
# mkdir -p /local/oracle/network/admin

Pour faire une copie locale des fichiers globaux devant maintenir des informations spécifiques aux noeuds, exécutez les commandes suivantes :

# cp -p $ORACLE_HOME/network/admin/snmp_ro.ora \
  /local/oracle/network/admin/.

# cp -p $ORACLE_HOME/network/admin/snmp_rw.ora \
  /local/oracle/network/admin/.

Effectuez les opérations indiquées ci-dessous sur un noeud uniquement.

Pour supprimer les fichiers globaux, exécutez les commandes suivantes :

# rm $ORACLE_HOME/network/admin/snmp_ro.ora

# rm $ORACLE_HOME/network/admin/snmp_rw.ora

Pour créer des liens symboliques depuis les copies locales des fichiers vers leurs fichiers globaux correspondants, exécutez les commandes suivantes :

# ln -s /local/oracle/network/admin/snmp_ro.ora \
 $ORACLE_HOME/network/admin/snmp_rw.ora

# ln -s /local/oracle/network/admin/snmp_rw.ora \
  $ORACLE_HOME/network/admin/snmp_rw.ora

Sun Cluster 3.1 Data Service for Oracle E-Business Suite Guide

Cette rubrique traite des erreurs et omissions du document Sun Cluster 3.1 Data Service for Oracle E-Business Suite Guide.

Procédure d'enregistrement et de configuration de Sun Cluster HA pour Oracle E-Business Suite en tant que service de basculement

L'étape 13 de la procédure “How to Register and Configure Sun Cluster HA for Oracle E-Business Suite as a Failover Service” est erronée. Le texte correct est le suivant :

13. Create a resource for the Oracle E-Business Suite Concurrent Manager Server.

# grep PROD.CON_COMNTOP /var/tmp/config.txt
PROD.CON_COMNTOP=/global/mnt10/d01/oracle/prodcomn <- CON_COMNTOP
#
# grep PROD.DBS_ORA806= /var/tmp/config.txt
PROD.DBS_ORA806=/global/mnt10/d01/oracle/prodora/8.0.6 <- ORACLE_HOME

L'exemple suivant cette étape est également incorrect. Corrigez-le comme suit :

RS=ebs-cmg-res
RG=ebs-rg
HAS_RS=ebs-has-res
LSR_RS=ebs-cmglsr-res
CON_HOST=lhost1
CON_COMNTOP=/global/mnt10/d01/oracle/prodcomn
CON_APPSUSER=ebs
APP_SID=PROD
APPS_PASSWD=apps
ORACLE_HOME=/global/mnt10/d01/oracle/prodora/8.0.6
CON_LIMIT=70
MODE=32/Y

Service de données Sun Cluster 3.1 10/03 pour Sun ONE Directory Server et Sun ONE Web Server

Cette rubrique présente les erreurs et omissions relevées dans les documents Sun Cluster 3.1 Data Service for Sun ONE Directory Server Guide et Guide des services de données Sun Cluster 3.1 pour Sun ONE Web Server.

Modification de nom pour iPlanet Web Server et iPlanet Directory Server

Les noms d'iPlanet Web Server et iPlanet Directory Server ont été modifiés ; ils s'appellent désormais Sun ONE Web Server et Sun ONE Directory Server. Les noms des services de données sont maintenant Sun Cluster HA pour Sun ONE Web Server et Sun Cluster HA pour Sun ONE Directory Server.

Les noms d'applications sur le Sun Cluster Agents CD-ROM sont peut-être toujours iPlanet Web Server et iPlanet Directory Server.

Service de données Sun Cluster 3.1 10/03 pour SAP liveCache

Cette rubrique présente les erreurs et omissions relevées dans le document Sun Cluster 3.1 Data Service for SAP liveCache.

La rubrique « Registering and Configuring Sun Cluster HA for SAP liveCache » devrait indiquer que SAP xserver ne peut être configuré que comme ressource évolutive. La configuration de SAP xserver comme ressource de basculement empêche la ressource SAP liveCache de basculer. Ignorez toute référence à la configuration de la ressource SAP xserver comme ressource de basculement dans le document Sun Cluster 3.1 Data Service for SAP liveCache.

La rubrique « Registering and Configuring Sun Cluster HA for SAP liveCache » devrait également contenir une étape supplémentaire. Après l'étape 10, « Enable the scalable resource group that now includes the SAP xserver resource », vous devez enregistrer la ressource liveCache en entrant le texte suivant :

# scrgadm -a -j ressource_livecache -g groupe_ressources_livecache \
-t SUNW.sap_livecache -x livecache_name=nom_LC \
-y resource_dependencies=ressource_stockage_livecache

Après avoir enregistré la ressource liveCache, passez à l'étape suivante, « Set up a resource group dependency between SAP xserver and liveCache ».

Service de données Sun Cluster 3.1 10/03 pour le serveur WebLogic

Cette rubrique présente les erreurs et omissions relevées dans le document Sun Cluster 3.1 Data Service for WebLogic Server .

Le tableau « Protection of BEA WebLogic Server Component » devrait indiquer que la base de données du serveur BEA WebLogic est protégée par toutes celles prises en charge par le serveur BEA WebLogic et par Sun Cluster. Il devrait également indiquer que les serveurs HTTP sont protégés par tous ceux pris en charge par le serveur BEA WebLogic et par Sun Cluster.

Service de données Sun Cluster 3.1 10/03 pour Apache

Cette rubrique présente les erreurs et omissions relevées dans le document Sun Cluster 3.1 Data Service for Apache Guide.

La rubrique « Planning the Installation and Configuration » ne devrait pas comporter de remarque sur l'utilisation de serveurs proxy évolutifs servant une ressource Web évolutive. L'utilisation de serveurs proxy évolutifs n'est pas prise en charge.

Si vous utilisez la propriété d'extension Liste_Uri_détecteur pour le service de données Sun Cluster HA pour Apache, la valeur requise pour la propriété version_type est 4. Vous pouvez mettre à niveau le type de ressource vers version_type 4.

Service de données Sun Cluster 3.1 10/03 pour Sun ONE Web Server

Si vous utilisez la propriété d'extension Liste_Uri_détecteur pour le service de données Sun Cluster HA pour Sun ONE Web Server, la valeur requise pour la propriété version_type est 4. Vous pouvez mettre à niveau le type de ressource vers version_type 4.

Pages de manuel

SUNW.wls(5)

La rubrique « See Also » de cette page de manuel comporte une erreur. Il convient de se reporter non pas au document Sun Cluster 3.1 Data Services Installation and Configuration Guide, mais au document Sun Cluster 3.1 Data Service for WebLogic Server Guide.