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.