DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
Le fichier db2nodes.cfg sert à définir les serveurs de partitions de bases de données qui participent à une instance DB2. Le fichier db2nodes.cfg spécifie également l'adresse IP ou le nom d'hôte d'un commutateur d'interconnexion à haut débit, si vous souhaitez en utiliser un pour les communications du serveur de partitions.
Le format du fichier db2nodes.cfg sur les systèmes Linux et UNIX est le suivant :
numpartitionbd nomhôte portlogique nomréseau nomensembleressourcesnumpartitionbd
, nomhôte, portlogique, nomréseau et nomensembleressources sont définis dans la section suivante.
Le format du fichier db2nodes.cfg sur les systèmes d'exploitation Windows est le suivant :
numpartitionbd nomhôte nomordinateur portlogique nomréseau nomensembleressources
Sur les systèmes d'exploitation Windows, ces entrées de db2nodes.cfg sont ajoutées avec la commande db2ncrt ou START DBM ADD DBPARTITIONNUM. Elles peuvent également être modifiées avec la commande db2nchg. Il est déconseillé d'ajouter ces lignes directement ou de modifier ce fichier.
Pour faire évoluer un système de bases de données partitionné, il faut ajouter une entrée pour chaque serveur de partitions de bases de données dans le fichier db2nodes.cfg. Les valeurs numpartitionbd sélectionnées pour les serveurs de partitions supplémentaires doivent être octroyées par ordre croissant, mais il n'est pas nécessaire qu'elles se suivent. Vous pouvez laisser un intervalle entre deux valeurs numpartitionbd si vous envisagez d'ajouter des serveurs de partitions logiques et que vous voulez regrouper les noeuds logiquement dans ce fichier.
Cette entrée est obligatoire.
Si des noms d'hôte sont fournis dans le fichier db2nodes.cfg, et non des adresses IP, le gestionnaire de bases de données tente dynamiquement de résoudre les noms d'hôte. La résolution peut être locale ou effectuée via la recherche sur des serveurs DNS enregistrés, comme cela est déterminé par les paramètres de système d'exploitation sur la machine.
Depuis DB2 version 9.1, les protocoles TCP/IPv4 et TCP/IPv6 sont tous les deux pris en charge. La méthode de résolution des noms d'hôte a changé.
Alors que la méthode utilisée dans les versions antérieures à la version 9.1 résout la chaîne, comme cela est défini dans le fichier db2nodes.cfg, la méthode de la version 9.1 ou version ultérieure tente de résoudre les noms FQDN (Fully Qualified Domain Name) lorsque des noms abrégés sont définis dans le fichier db2nodes.cfg. La spécification de noms abrégés configurés pour les noms d'hôte qualifiés complets peut générer des retards dans les processus qui résolvent les noms d'hôte.
Pour éviter des retards dans les commandes DB2 qui requièrent la résolution de nom d'hôte, utilisez une des solutions suivantes :
db2 catalog tcpip4 node db2tcp2 remote 192.0.32.67 server db2inst1 with "Look up IPv4 address from 192.0.32.67"
db2 catalog tcpip6 node db2tcp3 1080:0:0:0:8:800:200C:417A server 50000 with "Look up IPv6 address from 1080:0:0:0:8:800:200C:417A"
DB2 réserve une série de ports (par exemple, 60000 - 60003) dans le fichier /etc/services pour les communications interpartition, au moment de l'installation. La zone port_logique dans db2nodes.cfg indique quel port de cette série vous souhaitez attribuer à un serveur de partitions logiques donné.
Si aucune valeur n'est indiquée dans cette zone, la valeur par défaut est 0. Toutefois, si vous ajoutez une entrée dans la zone nom_réseau, vous devez obligatoirement indiquer un numéro dans port_logique.
Si vous utilisez des partitions de bases de données logiques, la valeur port_logique que vous indiquez doit commencer à 0 et continuer par ordre croissant (par exemple, 0,1,2).
Par ailleurs, si vous indiquez une valeur port_logique pour un serveur de partitions de bases de données, vous devez indiquer un port_logique pour chacun des serveurs de ce type dans le fichier db2nodes.cfg.
Cette zone est facultative uniquement" si vous n'utilisez pas de partitions de base de données logiques, ni de commutateur d'interconnexion à haut débit.
Si vous déclarez une entrée dans cette zone, toutes les communications entre les serveurs de partitions de bases de données (à l'exception de celles résultant des commandes db2start, db2stop et db2_all) transitent via le commutateur d'interconnexion.
Ce paramètre n'est nécessaire que si vous utilisez un commutateur d'interconnexion à haut débit pour les communications concernant les partitions de bases de données.
Ce paramètre est uniquement pris en charge sur les systèmes d'exploitation AIX, HP-UX et Solaris.
Sous AIX, ce concept est désigné par "jeux de ressources" et, sous Solaris, il est nommé "projets". Pour plus d'informations sur la gestion des ressources, consultez la documentation de votre système d'exploitation.
Sous HP-UX, le paramètre nom_jeu_ressource est un nom du groupe PRM. Pour plus d'informations, reportez-vous à la documentation "HP-UX Process Resource Manager. User Guide. (B8733-90007)" éditée par HP.
Sur les systèmes d'exploitation Windows, l'affinité de processus pour un noeud logique peut être définie à l'aide de la variable de registre DB2PROCESSORS.
Sous Linux, la colonne nom_jeu_ressource définit un nombre qui correspond à un noeud NUMA (Non-Uniform Memory Access)du système. L'utilitaire système numactl doit être disponible ainsi que le noyau 2.6 avec une prise en charge de la règle NUMA.
Le paramètre nom_réseau doit être indiqué si le paramètre nom_jeu_ressource est précisé.
Utilisez les exemples ci-dessous pour déterminer la configuration appropriée à votre environnement.
0 ServeurA 0 1 ServeurA 1 2 ServeurA 2 3 ServeurA 3
0 ServeurA 0 1 ServeurB 0
4 ServeurA 0 6 ServeurA 1 8 ServeurA 2 9 ServeurB 0
0 ServeurA 0 commutateur1 1 ServeurB 0 commutateur2 2 ServeurB 1 commutateur2
Ces restrictions s'appliquent aux exemples suivants :
Voici un exemple de configuration du jeu de ressources pour les systèmes d'exploitation AIX.
Dans cet exemple, il existe un noeud physique doté de 32 processeurs et huit partitions de base de données logiques (MLN). Cet exemple montre comment attribuer l'affinité de processus à chaque MLN.
DB2/MLN1:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00000,sys/cpu.00001,sys/cpu.00002,sys/cpu.00003
DB2/MLN2:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00004,sys/cpu.00005,sys/cpu.00006,sys/cpu.00007
DB2/MLN3:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00008,sys/cpu.00009,sys/cpu.00010,sys/cpu.00011
DB2/MLN4:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00012,sys/cpu.00013,sys/cpu.00014,sys/cpu.00015
DB2/MLN5:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00016,sys/cpu.00017,sys/cpu.00018,sys/cpu.00019
DB2/MLN6:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00020,sys/cpu.00021,sys/cpu.00022,sys/cpu.00023
DB2/MLN7:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00024,sys/cpu.00025,sys/cpu.00026,sys/cpu.00027
DB2/MLN8:
owner = db2inst1
group = system
perm = rwr-r-
resources = sys/cpu.00028,sys/cpu.00029,sys/cpu.00030,sys/cpu.00031vmo -p -o memory_affinity=1
chuser capabilities=
CAP_BYPASS_RAC_VMM,CAP_PROPAGATE,CAP_NUMA_ATTACH db2inst11 regatta 0 regatta DB2/MLN1 2 regatta 1 regatta DB2/MLN2 3 regatta 2 regatta DB2/MLN3 4 regatta 3 regatta DB2/MLN4 5 regatta 4 regatta DB2/MLN5 6 regatta 5 regatta DB2/MLN6 7 regatta 6 regatta DB2/MLN7 8 regatta 7 regatta DB2/MLN8
Cet exemple illustre l'utilisation des groupes PRM pour les partages d'unité centrale sur une machine équipée de quatre unités centrales et quatre MLN, avec 24% de partage d'unité centrale par MLN, en conservant 4% pour les autres applications. Le nom de l'instance DB2 est db2inst1.
OTHERS:1:4:: db2prm1:50:24:: db2prm2:51:24:: db2prm3:52:24:: db2prm4:53:24::
db2inst1::::OTHERS,db2prm1,db2prm2,db2prm3,db2prm4
prmconfig -i prmconfig -e CPU
1 voyager 0 voyager db2prm1 2 voyager 1 voyager db2prm2 3 voyager 2 voyager db2prm3 4 voyager 3 voyager db2prm4
Vous pouvez configurer PRM (étapes 1 à 3) à l'aide de l'outil graphique xprm.
Sous Linux, la colonne nom_jeu_ressource définit un nombre qui correspond à un noeud NUMA (Non-Uniform Memory Access)du système. La fonction du système numactl doit être disponible en plus du noyau 2.6 avec une prise en charge de la règle NUMA. Pour plus d'informations sur la prise en charge NUMA sous Linux, consultez la page d'aide relative à numact1.
Cet exemple décrit la procédure de configuration d'un poste de travail à quatre noeuds NUMA, avec chaque noeud logique associé à un noeud NUMA.
$ numactl --hardwareVous obtenez des résultats similaires à ce qui suit :
disponibles : 4 noeuds (0-3) noeud 0 taille : 1901 Mo noeud 0 libre : 1457 Mo noeud 1 taille : 1910 Mo noeud 1 libre : 1841 Mo noeud 2 taille : 1910 Mo noeud 2 libre : 1851 Mo noeud 3 taille : 1905 Mo noeud 3 libre : 1796 Mo
0 nom_hôte 0 nom_hôte 0 1 nom_hôte 1 nom_hôte 1 2 nom_hôte 2 nom_hôte 2 3 nom_hôte 3 nom_hôte 3
Voici un exemple de configuration du projet sous Solaris, version 9.
Dans cet exemple, nous sommes en présence d'un noeud physique équipé de huit processeurs : une unité centrale sera utilisée pour le projet par défaut, trois unités centrales seront utilisées par le serveur d'applications et quatre unités centrales seront destinées à DB2. Le nom d'instance est db2inst1.
create system hostname
create pset pset_default (uint pset.min = 1)
create pset db0_pset (uint pset.min = 1; uint pset.max = 1)
create pset db1_pset (uint pset.min = 1; uint pset.max = 1)
create pset db2_pset (uint pset.min = 1; uint pset.max = 1)
create pset db3_pset (uint pset.min = 1; uint pset.max = 1)
create pset appsrv_pset (uint pset.min = 3; uint pset.max = 3)
create pool pool_default (string pool.scheduler="TS";
boolean pool.default = true)
create pool db0_pool (string pool.scheduler="TS")
create pool db1_pool (string pool.scheduler="TS")
create pool db2_pool (string pool.scheduler="TS")
create pool db3_pool (string pool.scheduler="TS")
create pool appsrv_pool (string pool.scheduler="TS")
associate pool pool_default (pset pset_default)
associate pool db0_pool (pset db0_pset)
associate pool db1_pool (pset db1_pset)
associate pool db2_pool (pset db2_pset)
associate pool db3_pool (pset db3_pset)
associate pool appsrv_pool (pset appsrv_pset)system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: appsrv:4000:App Serv project:root::project.pool=appsrv_pool db2proj0:5000:DB2 Node 0 project:db2inst1,root::project.pool=db0_pool db2proj1:5001:DB2 Node 1 project:db2inst1,root::project.pool=db1_pool db2proj2:5002:DB2 Node 2 project:db2inst1,root::project.pool=db2_pool db2proj3:5003:DB2 Node 3 project:db2inst1,root::project.pool=db3_pool
0 hostname 0 hostname db2proj0 1 hostname 1 hostname db2proj1 2 hostname 2 hostname db2proj2 3 hostname 3 hostname db2proj3