Informations supplémentaires sur HADB

Cette section présente d'autres informations importantes sur l'implémentation du système HADB dans Application Server 8.2.

• Améliorations relatives à HADB

• Prise en charge du système de fichiers HADB

• Mise à niveau de la base de données de disponibilité anticipée

• Restrictions SQL connues

• Équilibrage de charge de haute disponibilité

Améliorations relatives à HADB

• Une nouvelle commande de gestion, hadbm setadminpassword, a été ajoutée afin de permettre la modification du mot de passe utilisé pour l'administration de la base de données. La commande comporte des options indiquant l'agent de gestion à utiliser ainsi que les ancien et nouveau mots de passe. Pour plus d'informations, reportez-vous à la page de manuel hadbm setadminpassword.

• La commande de gestion hadbm listpackages a été modifiée. Avant, la commande ne prenait en charge aucun opérande et répertoriait tous les packages dans le domaine de gestion approprié. À présent, la commande dispose d'un opérande de nom de package optionnel et répertorie uniquement les packages dotés de ce nom. Si l'opérande n'est pas indiqué, tous les packages sont répertoriés. Pour plus d'informations, reportez-vous à la page de manuel hadbm listpackages.

• La commande de gestion hadbm createdomain a été modifiée. L'opérande hostlist est étendu de manière à préciser également le numéro de port de l'agent de gestion. Ainsi, le domaine peut être entièrement spécifié en utilisant uniquement l'opérande hostlist. L'ancien comportement est toujours pris en charge dans le cadre de la compatibilité ascendante. Pour plus d'informations, reportez-vous à la page de manuel relative à la commande hadbm createdomain.

• Certains des messages d'erreur du système de gestion ont été modifiés. Ces modifications ont été apportées pour améliorer la compréhension, la cohérence et la précision de ces messages. Les modifications effectuées ne sont pas répertoriées dans ces notes de version.

• Les procédures d'installation et de désinstallation ont été légèrement modifiées. Normalement, le lien symbolique /opt/SUNWhadb/4 devrait être préservé lors de l'installation ou de la désinstallation de HADB, mais ce n'est pas toujours le cas :

• Il n'est plus possible de saisir des mots de passe sur la ligne de commande sous la forme d'options de commande. Cette modification concerne toutes les commandes hadbm prenant en charge la saisie de mots de passe comme options de ligne de commande. Dans les commandes hadbm, il était jusqu'alors possible d'entrer un mot de passe via :

  1. un fichier de mot de passe ;

  2. une option de ligne de commande ;

  3. une entrée interactive.

  La deuxième méthode (l'option de ligne de commande), considérée comme dangereuse en termes de sécurité, n'est plus autorisée. Un message d'avertissement apparaît si un mot de passe est saisi de cette manière. Il est recommandé d'utiliser la première ou la troisième méthode. L'utilisation d'un mot de passe sur la ligne de commande deviendra impossible dans la prochaine version. Notez que cette modification s'applique à toutes les commandes hadbm prenant en charge l'option de mot de passe.

• Le système HADB a été mis à niveau de manière à prendre en charge JGroups version 2.2. Son code source est distribué avec HADB. Pour prendre en charge les mises à niveau à partir d'une version antérieure de HADB, les deux versions JGroups 2.1 et 2.2 sont fournies avec HADB. Pour JGroups 2.1, seul le code octet est fourni.

Prise en charge du système de fichiers HADB

Plusieurs considérations importantes doivent être prises en compte si vous souhaitez configurer HADB de manière à utiliser l'un des systèmes de fichiers suivants :

• ext2 et ext3 : HADB prend en charge les systèmes de fichiers ext2 et ext3 sous Red Hat Application Server 3.0. Sous Red Hat Application Server 2.1, seul le système ext2 est pris en charge.

• Veritas : lorsque le système de fichiers Veritas est utilisé sur la plate-forme Solaris, le message “WRN: Direct disk I/O mapping failed“ est consigné dans les fichiers de l'historique. Ce message indique que le système HADB ne parvient pas à activer la fonction d'E/S directe pour les unités de données et de journaux. La fonction d'E/S directe permet de réduire le traitement nécessaire à l'écriture des pages de disque et, par voie de conséquence, d'améliorer les performances du processeur. En outre, elle réduit le temps système consacré à la gestion des pages de données corrompues dans le système d'exploitation.

  Pour utiliser la fonction d'E/S directe avec le système de fichiers Veritas, procédez de l'une des manières suivantes:

  • Créez des unités de données et de journaux sur un système de fichiers monté avec l'option mincache=direct. Cette option s'applique à l'ensemble des fichiers créés sur le système de fichiers. Reportez-vous à la commande mount_vxfs(1M) pour obtenir plus de détails.

  • Utilisez la fonction Quick I/O de Veritas pour effectuer une E/S brute sur les fichiers du système de fichiers. Reportez-vous au Guide d'administration de VERITAS File System 4.0 pour Solaris pour obtenir plus de détails.

    Notez que ces configurations ont été testées avec Application Server 8.2.

    Reportez-vous au Guide d'administration de la haute disponibilité d'Application Server Enterprise Edition pour obtenir des informations sur l'installation et la configuration de HADB avec le logiciel Application Server.

Mise à niveau de la base de données de disponibilité anticipée

• Migration de données et tâches antérieures à la mise à niveau

• Procédure de mise à niveau

• Test de la mise à niveau

• Informations spéciales relatives au déploiement et à la mise à niveau

Migration de données et tâches antérieures à la mise à niveau

Avant de commencer

Les utilisateurs doivent conserver les fichiers de l'historique HADB, les fichiers de configuration de l'agent de gestion, les fichiers journaux et le référentiel, ainsi que toutes les unités de données en dehors du chemin d'installation. Si cela n'a pas déjà été fait, il est nécessaire d'y remédier avant de procéder à la mise à niveau. Pour déplacer le référentiel de gestion et les fichiers de configuration :

1. Arrêtez tous les anciens agents de gestion et maintenez les nœuds HADB en cours d'exécution.

2. Sur chaque hôte, déplacez le référentiel vers le nouvel emplacement.

3. Sur chaque hôte, copiez le répertoire dbconfig au nouvel emplacement.

4. Sur chaque hôte, mettez à jour le fichier mgt.cfg et définissez le chemin approprié pour dbconfig et le référentiel.

5. Lancez les agents de gestion via le fichier mgt.cfg mis à jour.

Procédure de mise à niveau

Pour effectuer la mise à niveau de HADB version 4.4.x vers 4.4.3, suivez la procédure ci-dessous :

1. Si nécessaire, effectuez les tâches antérieures à la mise à niveau mentionnées ci-dessus.

2. Installez HADB version 4.4.3 sur tous les hôtes HADB (sous un autre chemin que celui utilisé pour la version 4.4.x, par exemple sous /opt/SUNWhadb/4.4.3).

3. Installez HADB 4.4.3 sur les hôtes client de hadbm, s'ils diffèrent des hôtes HADB.

4. Arrêtez tous les agents de gestion exécutés sur tous les hôtes HADB.

5. Démarrez les processus d'agent de gestion à l'aide de la nouvelle version du logiciel, mais en utilisant les anciens fichiers de configuration. Pour les étapes suivantes, utilisez la commande hadbm disponible à partir du répertoire bin de la nouvelle version.

6. Enregistrez le package dans le domaine de gestion (étant donné que le nom de package par défaut devient V4.4, vous devrez probablement fournir un autre nom pour éviter des conflits avec des packages existants dotés du même nom) :

   hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.3 V4.4.3

7. Exécutez la commande hadbm listpackages, puis vérifiez que le nouveau package est enregistré dans le domaine.

8. Redémarrez la base de données avec la nouvelle version hadbm 4.4.3. S'il est nécessaire de déplacer les unités et les fichiers de l'historique, exécutez la mise à niveau en ligne tout en définissant de nouveaux chemins pour ces unités et fichiers de l'historique, en une seule opération :

   hadbm set packagename=V4.4.3,devicepath=new_devpath, historypath=new_histpath

   Si les unités et les fichiers de l'historique sont déjà situés en dehors du répertoire d'installation, exécutez la commande ci-dessous, de manière à effectuer uniquement un redémarrage progressif des nœuds :

   hadbm set packagename=V4.4.3 database name

9. Vérifiez que la base de données est en cours d'exécution (à l'aide de la commande hadbm status) et qu'elle fonctionne normalement, en servant les transactions du client.

10. Si tout fonctionne correctement, vous pourrez supprimer l'ancienne installation ultérieurement. Avant d'annuler l'enregistrement de l'ancien package, supprimez toutes les références à l'ancien package dans le référentiel ma. À défaut, la commande hadbm unregisterpackage échouera, en indiquant le message “package en cours d'utilisation.”Une opération de reconfiguration fictive, par exemple hadbm set connectiontrace=same as previous value, supprimera toutes les références à l'ancien package. Maintenant, annulez l'enregistrement de l'ancien package :

    hadbm unregisterpackage [--hosts=host-list] old pacakge name

11. Supprimez l'ancienne installation du système de fichiers.

Test de la mise à niveau

Sous Solaris, testez la mise à niveau en vérifiant qu'elle a été correctement effectuée :

1. Vérifiez que les processus en cours d'exécution utilisent les nouveaux binaires. À tous les nœuds HADB, vérifiez les éléments ci-dessous :

   new path/bin/ma -v new path/bin/hadbm -v

2. Vérifiez si la base de données est en cours d'exécution. La commande ci-dessous doit indiquer que tous les nœuds HADB présentent un statut “en cours”.

   new path/bin/hadbm status -n

3. Vérifiez que les pointeurs des produits utilisant HADB ont été modifiés de manière à renvoyer vers le nouveau chemin HADB.

4. Vous pouvez exécuter les tests de mise à niveau des produits utilisant HADB pour vérifier le bon fonctionnement de la mise à niveau de HADB.

   Après une mise à niveau en ligne, si la nouvelle version ne fonctionne pas correctement, revenez à l'ancienne version de HADB. Toutefois, si le référentiel de l'agent de gestion a été modifié, vous pouvez rétablir la base de données HADB à un niveau inférieur, mais le nouvel agent de gestion doit rester en cours d'exécution.

Informations spéciales relatives au déploiement et à la mise à niveau

Cette section présente des informations supplémentaires sur le déploiement et la mise à niveau de HADB.

• Déploiement

• Mise à niveau en ligne de 4.4.1 vers 4.4.2

Déploiement

• Stockez l'unité, le journal et les fichiers de l'historique sur des disques locaux uniquement. N'utilisez pas de fichiers système montés à distance.

• Si plusieurs nœuds sont placés sur un hôte, il est recommandé de placer les périphériques appartenant à chaque nœud sur des disques différents. À défaut, les éventuels conflits de disque réduiront les performances. Les signes de ce problème sont indiqués dans les fichiers de l'historique par des messages comme BEWARE - last flush/fputs took too long. Lorsqu'un seul nœud comporte plusieurs fichiers de périphérique de données, il est recommandé d'utiliser des disques séparés.

• Utilisez des disques locaux (de préférence des disques distincts de celui utilisé pour les périphériques de données) pour installer les binaires HADB sur les hôtes HADB. Des retards NFS ou un conflit de disque peuvent entraîner le redémarrage du nœud avec l'avertissement : “Processus bloqué pour nnn, durée de blocage max. de nnn” dans les fichiers de l'historique.

• Ne placez pas les périphériques HADB, les fichiers de l'historique, les répertoires et les fichiers de configuration de l'agent de gestion sous le chemin d'accès au package HADB. À défaut, vous rencontrerez des problèmes lors de mises à niveau vers des versions plus récentes et lors de la suppression de l'ancien chemin du package.

• La version de HADB est officiellement prise en charge pour un maximum de 28 nœuds (24 actifs et 4 disponibles).

• Nous vous recommandons d'utiliser la même version pour le pilote JDBC et le serveur HADB.

• Le protocole IPv6 n'est pas pris en charge, seul IPv4 l'est.

• La longueur des lignes de commande est limitée à 2048 octets sous Windows.

• Le réseau doit être configuré pour une multidiffusion UDP.

• En raison d'un swapping excessif observé dans RedHat Enterprise Linux 3.0, updates 1 à 3, nous ne le recommandons pas comme plate-forme de déploiement. Le problème est résolu dans la version RedHat Enterprise Linux 3.0 update 4.

• Possibilité d'exécution du superviseur de nœud NSUP avec la priorité au temps réel :

  Les processus du superviseur de nœud (NSUP), clu_nsup_srv, garantissent la haute disponibilité de la base de données HADB par le biais de messages de “pulsation” échangés en temps voulu. Les délais sont affectés lorsqu'un NSUP est hébergé au même emplacement que d'autres processus, générant ainsi des insuffisances de ressource. Il en résulte des partitions de réseau erronées et des redémarrages de nœud (précédés de l'avertissement “Processus bloqué pendant n secondes” dans les fichiers de l'historique) entraînant des abandons de transactions et autres exceptions.

  Pour résoudre ce problème, le superviseur de nœud clu_nsup_srv (trouvé sous installpath/lib/server) doit comporter le bit suid et le fichier doit appartenir à l'utilisateur root. Pour ce faire, procédez manuellement à l'aide des commandes :

  # chown root clu_nsup_srv # chmod u+s clu_nsup_srv

  Le processus clu_nsup_srv est alors exécuté en tant qu'utilisateur root lors de son démarrage, ce qui lui permet d'obtenir automatiquement la priorité en temps réel après le démarrage. Pour éviter toute incidence sur la sécurité lors de l'utilisation de setuid, la priorité en temps réel est définie au tout début du processus et ce dernier reprend l'ID utilisateur réel une fois la priorité modifiée. D'autres processus HADB réduisent leur priorité au niveau de partage du temps.

  Si le superviseur NSUP n'a pas pu définir la priorité de temps réel, il émet un avertissement, “Impossible de définir la priorité de temps réel” (unix: errno will be set to EPERM), consigné dans le fichier ma.log et se poursuit sans la priorité de temps réel.

  Dans certains cas, il est impossible de définir des priorités de temps réel, notamment :

  • lors d'une installation dans des zones non globales de Solaris 10 ;

  • lors de la révocation des privilèges PRIV_PROC_LOCK_MEMORY (autoriser un processus à verrouiller des pages dans la mémoire physique) et/ou PRIV_PROC_PRIOCNTL sous Solaris 10 ;

  • lorsque les utilisateurs désactivent l'autorisation setuid ;

  • lorsque les utilisateurs installent le logiciel en tant que fichiers .tar (option d'installation non root pour App.server).

  Le processus clu_nsup_srv n'utilise pas beaucoup de ressources processeur, son empreinte est petite et son exécution avec une priorité de temps réel n'a aucune incidence sur les performances.

• Configuration du multiacheminement sur réseau IP (IPMP) pour HADB pour Solaris (testé sur Solaris 9 uniquement) :

  Sun recommande de configurer le multiacheminement sur réseau IP sur les systèmes Solaris hébergeant des bases de données HADB, afin de garantir une disponibilité maximale du réseau. La procédure est expliquée en détail dans le Guide d'administration du multiacheminement sur réseau IP. Si vous décidez d'utiliser le multiacheminement avec HADB, reportez-vous à la section relative à l'administration du multiacheminement sur réseau du Guide d'administration du multiacheminement sur réseau IP afin de procéder à la configuration du multiacheminement, étape requise pour ensuite adapter cette configuration à HADB comme décrit ci-dessous. Le Guide d'administration du multiacheminement sur réseau IP fait partie de la documentation concernant l'administrateur système de Solaris 9. Vous pouvez la télécharger à partir de l'adresse http://docs.sun.com.

  • Définition du délai de détection des défaillances de l'interface réseau

    Afin que HADB puisse correctement prendre en charge les défaillances relatives au multiacheminement, le délai de détection des défaillances de l'interface réseau ne doit pas dépasser les 1000 millisecondes comme indiqué dans le paramètre FAILURE_DETECTION_TIME sous /etc/default/mpathd. Modifiez le fichier et remplacez la valeur de ce paramètre par 1000si la valeur initiale est supérieure :

    FAILURE_DETECTION_TIME=1000

    Pour que la modification soit prise en compte, exécutez la commande ci-dessous :

    pkill -HUP in.mpathd

  • Adresses IP à utiliser avec HADB

    Comme décrit dans le Guide d'administration du multiacheminement sur réseau IP Solaris, le multiacheminement implique le rassemblement d'interfaces réseau physiques en groupes d'interfaces multivoies. Chacune des interfaces physiques d'un groupe est associée à deux adresses IP : une adresse d'interface physique et une adresse test. Seule l'adresse d'interface physique peut être utilisée pour la transmission des données. L'adresse de test, quant à elle, est destinée uniquement à un usage interne à Solaris. Lors de l'exécution de la commande hadbm create --hosts, chaque hôte doit être spécifié avec une seule des adresses d'interface physique du groupe de multiacheminement.

  • Exemple

    Supposons que les Hôte 1 et Hôte 2 disposent chacun de deux interfaces réseau physiques. Sur chaque hôte, ces deux interfaces sont configurées en tant que groupe de multiacheminement. L'exécution de la commande ifconfig -a génère le résultat suivant :

    Hôte 1

    bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255

    Hôte 2

    bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255

    Dans ce cas, les interfaces réseau physiques sur les deux hôtes sont celles répertoriées en tant que bge0 et bge1. Celles référencées par bge0:1 et bge1:1 sont des interfaces de test de multiacheminement (elles sont signalées comme étant désapprouvées dans ifconfig). Pour plus de détails, reportez-vous au Guide d'administration du multiacheminement sur réseau IP.

    Pour configurer HADB dans cet environnement, sélectionnez une adresse d'interface physique au niveau de chaque hôte. Dans cet exemple, nous choisissons 129.159.115.10 sur l'hôte 1 et 129.159.115.20 sur l'hôte 2. Pour créer une base de données avec un nœud par hôte, utilisez l'argument suivant pour hadbm create :

    --host 129.159.115.10,129.159.115.20

    Pour créer une base de données avec deux nœuds de base de données sur chaque hôte, utilisez l'argument :

    --host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20

    Dans les deux cas, la variable ma.server.mainternal.interfaces doit être paramétrée sur 129.159.115.0/24 sur les deux hôtes.

Mise à niveau en ligne de 4.4.1 vers 4.4.2

Il est impossible d'effectuer une mise à niveau de 4.2 ou 4.3 vers 4.4 en ligne. En revanche, la version 4.4 prend en charge les mises à niveau en ligne vers les versions ultérieures. Pour effectuer une mise à niveau de 4.4.1 vers 4.4.2, suivez la procédure ci-dessous :

1. Installez 4.4.2 sur tous les hôtes HADB (sous un autre chemin que celui utilisé pour 4.4.1, par exemple sous /opt/SUNWhadb/4.4.2-6).

2. Installez la nouvelle version sur les hôtes hadbm client.

3. Arrêtez tous les agents de gestion exécutés sur les hôtes HADB.

4. Démarrez les processus d'agent de gestion à l'aide de la nouvelle version du logiciel, mais en utilisant les anciens fichiers de configuration. Pour les étapes suivantes, utilisez la commande hadbm disponible à partir du répertoire bin de la nouvelle version.

5. Enregistrez le package dans le domaine de gestion (étant donné que le nom de package par défaut devient V4.4, vous devrez probablement fournir un autre nom pour éviter des conflits avec des packages existants dotés du même nom) :

   hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2

6. Redémarrez la base de données avec la nouvelle version (la commande suivante lance un redémarrage progressif des nœuds) :

   hadbm set packagename=V4.4.2 nom_base_de_données

7. Vérifiez que la base de données est en cours d'exécution (à l'aide de la commande hadbm status) et qu'elle fonctionne normalement, en servant les transactions du client.

8. Si tout fonctionne correctement, vous pourrez supprimer l'ancienne installation ultérieurement.

   Avant d'annuler l'enregistrement de l'ancien package, supprimez toutes les références à l'ancien package dans le référentiel ma. À défaut, la commande hadbm unregisterpackage échouera et affichera le message “package en cours d'utilisation”.Une opération de reconfiguration fictive, par exemple hadbm set connectiontrace=< same_as_previous_value>, supprimera toutes les références à l'ancien package. Maintenant, annulez l'enregistrement de l'ancien package :

   hadbm unregisterpackage [--hosts=<liste_hôtes>] <nom_ancien_package>

   Supprimez l'ancienne installation du système de fichiers, en suivant les instructions d'installation de HADB à l'adresse .

Restrictions SQL connues

• Il est impossible de créer un index secondaire UNIQUE sur une table.

• L'expression (DISTINCT column) n'est pas autorisée dans une expression d'agrégation , à moins qu'elle ne soit la seule expression sélectionnée.

• Toutes les tables doivent être créées avec une clé primaire (les tables sans clé primaire ne sont pas prises en charge).

• FULL OUTER JOIN n'est pas pris en charge.

• Les sous-requêtes IN qui sont des sous-requêtes de table ne sont pas prises en charge ; par exemple :

  SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2')

• Les contraintes autres que NOT NULL et PRIMARY KEY ne sont pas prises en charge.

• Il est possible d'affecter un nouveau propriétaire à la ressource. Dans ce cas, cependant, les privilèges octroyés au propriétaire actuel ne sont pas accordés au nouveau propriétaire.

• Deux sous-requêtes NOT EXISTS imbriquées où chaque sous-requête n'est pas (directement) corrélée au niveau externe des requêtes ne sont pas prises en charge.

• Les privilèges de colonne ne sont pas pris en charge.

• Les constructeurs de valeur de ligne sont autorisés uniquement dans une clause VALUES.

• Les sous-requêtes ne sont pas acceptées comme expressions de valeur dans les constructeurs de valeur de ligne.

• Les types de données ci-dessous ne peuvent pas être utilisés lors de la création de clés primaires :

  • REAL

  • FLOAT

  • DOUBLE PRECISION

  • DECIMAL

  • NUMERIC

Équilibrage de charge de haute disponibilité

Application Server inclut l'équilibrage de charge pour les clients HTTP, IIOP et JMS, la prise en charge du basculement de la session HTTP, la prise en charge du basculement et du clustering EJB, les services d'horloge EJB haute disponibilité, la récupération des transactions distribuées, la prise en charge des mises à niveau d'applications progressives, ainsi qu'une base de données haute disponibilité pour le stockage de l'état transitoire des applications J2EE.

La disponibilité assure le basculement des instances d'Application Server mises en cluster. Lorsqu'une panne est détectée, la session que supervisait le serveur non disponible est réaffectée à une autre instance d'Application Server. Les informations relatives à la session sont stockées dans la base de données HADB. Le système HADB prend en charge la persistance des sessions HTTP, des beans de session avec état et des références liées à la connexion unique.