DB2 EEE pour UNIX - Mise en route

Configuration

La Figure 1 montre un exemple de configuration matérielle de DB2 EEE.

Figure 1. Configuration matérielle de DB2 Enterprise - Extended Edition


Figure présentant la configuration matérielle de DB2 Enterprise - Extended Edition

DB2 EEE peut fonctionner sur un groupe de processeurs individuels interconnectés par une mémoire partagée (multiprocesseurs symétriques (SMP)), un inverseur logique de communication à haut débit (par exemple, HPS), ou un réseau local. Le nombre de serveurs de partitions de bases de données dans une configuration varie d'une plateforme à une autre. Le nombre de ces serveurs communiquant sur un réseau local doit être limité à 16.

En pratique, le nombre maximum de serveurs de partitions de bases de données dans une configuration varie en fonction des plateformes et des outils de gestion disponibles sur chacune d'elles. Pour plus d'informations sur la configuration, reportez-vous au manuel Administration Guide.

Par exemple, dans un environnement de systèmes POWERParallel évolutifs pour RISC IBM System/6000 (RS/6000 SP) fonctionnant sous AIX, le nombre de serveurs de partitions de bases de données n'est limité que par la taille maximale d'un système SP RISC/6000 AIX.

Dans un environnement HP-UX, le nombre de serveurs de partitions de bases de données est limité par la taille des ordinateurs et leur quantité au sein du groupe. Par exemple, 24 serveurs de partitions de bases de données peuvent s'exécuter dans un groupe de 4 serveurs de type Enterprise K580 dotés chacun de 6 unités centrales.

Dans un environnement PTX, le nombre de serveurs de partitions de bases de données est limité par le nombre d'ensembles de quatre processeurs installés dans une machine. Cependant, nous vous recommandons de n'exécuter qu'un serveur de partitions par ensemble de processeurs NUMA-Q. Par exemple, cinq noeuds logiques multiples co-existent sur un système à cinq ensembles de quatre processeurs, chaque noeud disposant de quatre processeurs.

Dans un environnement Solaris**, le nombre de serveurs de partitions de bases de données est limité par la taille des ordinateurs et leur quantité au sein du groupe. Quarante serveurs de partitions de bases de données pourraient être exécutés sur un système regroupant quatre Ultra Enterprise 6000 dotés chacun de dix processeurs.

Vous devez prendre connaissance des informations présentées dans les sections suivantes avant de vous lancer dans la configuration de votre système de bases de données partitionnées. Ces informations décrivent les éléments suivants :

Ordinateurs et mémoire

DB2 Enterprise - Extended Edition met en oeuvre une architecture sans partage ; par conséquent, chaque serveur de partition de base de données est l'équivalent d'un système de base de données monopartition. Ainsi, la capacité de stockage du système de bases de données partitionnées est égale à celle fournie par un système de bases de données monopartitions, multipliée par le nombre de serveurs de partitions de bases de données. Vous pouvez stocker des tables d'une taille allant jusqu'à 512 Go (giga-octets) par partition de base de données. Par exemple, dans une base de données de 128 partitions, la taille maximale d'une table est d'environ 64 To (téra-octets).

Groupes de noeuds et partitionnement de données

Vous pouvez définir des sous-ensembles nommés d'une ou de plusieurs partitions d'une base de données. Chaque sous-ensemble défini est appelé groupe de noeuds. Un sous-ensemble contenant plusieurs partitions de base de données est appelé groupe de noeuds multipartition. Les groupes multipartitions ne peuvent être définis que dans des partitions appartenant à la même base de données.

Lorsqu'une base de données est créée, trois groupes de noeuds par défaut sont créés : IBMDEFAULTGROUP, IBMCATGROUP et IBMTEMPGROUP.

Si vous le souhaitez, vous pouvez créer des espaces table dans les groupes de noeuds par défaut IBMDEFAULTGROUP et IBMCATGROUP, puis créer des tables au sein de ces espaces table.

Le groupe de noeuds IBMDEFAULTGROUP contient toutes les partitions pour la base de données. Lorsque vous créez une base de données, une partition de base de données est créée sur chaque serveur de partitions de base de données (noeud) défini dans le fichier de configuration des noeuds (db2nodes.cfg).

Le groupe de noeuds IBMCATGROUP associé à la base de données est créé sur le serveur de partitions de base de données sur lequel vous avez entré la commande create database. Ce groupe de noeuds contient uniquement la partition de base de données locale du serveur de partitions de base de données sur lequel la commande a été entrée. Ce serveur de partitions de base de données est appelé noeud du catalogue de la base de données car le groupe de noeuds IBMCATGROUP contient les tables du catalogue de la base de données.

Vous ne pouvez pas exploiter directement le troisième groupe de noeuds par défaut, IBMTEMPGROUP. A l'instar du groupe IBMDEFAULTGROUP, il contient toutes les partitions d'une base de données. Tous les espaces table temporaires y sont stockés.

La Figure 2, est un exemple de base de données comportant trois groupes de noeuds. Le groupe de noeuds 1 est un groupe de noeuds multipartition constitué de quatre partitions de base de données, le groupe de noeuds 2 est de type monopartition et le groupe de noeuds 3 est un groupe de noeuds multipartition.

Figure 2. Groupes de noeuds dans une base de données

Diagramme présentant les groupes de noeuds dans une base de données

Lorsque vous souhaitez créer des espaces table pour une base de données, vous devez commencer par créer le groupe de noeuds dans lequel seront stockés ces espaces table. Ensuite, vous pouvez créer un espace table dans le groupe de noeuds, puis créer les tables dans l'espace table.

Vous pouvez supprimer des partitions de base de données d'un groupe de noeuds, ou, si de nouveaux noeuds ont été définis dans le fichier db2nodes.cfg, vous pouvez les ajouter à un groupe de noeuds dans une base de données. Pour plus d'informations sur l'ajout et la suppression de noeuds dans des groupes de noeuds, reportez-vous au manuel Administration Guide.

Au fur et à mesure que la taille de votre base de données augmente, vous pouvez ajouter des serveurs de partitions de bases de données au système de bases de données afin d'améliorer les performances. Cette opération entraîne ce que l'on appelle un changement d'échelle du système de bases de données. Lorsque vous ajoutez un serveur de partitions de bases de données, une partition de base de données est créée pour chaque base de données qui existe déjà dans le système de bases de données. Vous ajoutez alors la nouvelle partition de base de données à un groupe de noeuds existant qui appartient à cette base de données, puis vous répartissez à nouveau les données dans ce groupe de noeuds pour utiliser la nouvelle partition. Pour plus de détails, reportez-vous au manuel Administration Guide.

Une clé de partitionnement est associée à chaque table définie dans un groupe de noeuds multipartition. Une clé de partitionnement est un ensemble de colonnes ordonnées dont les valeurs sont utilisées conjointement à une mappe de partitionnement pour déterminer dans quelle partition de base de données réside une ligne d'une table donnée. La mappe de partitionnement est une matrice de 4 096 numéros de partitions de base de données.

Des colonnes de tout type de données (à l'exception de LONG VARCHAR, LONG VARGRAPHIC, BLOB ou CLOB) peuvent être utilisées en tant que clé de partitionnement. Une table définie dans un groupe de noeuds monopartition n'est pas forcément dotée d'une clé de partitionnement. Les tables ne comportant que des colonnes à zones étendues ne peuvent être définies que dans des groupes de noeuds monopartitions, et aucune clé de partitionnement ne peut leur être associée. Pour plus d'informations sur la création de tables, reportez-vous au manuel SQL Reference.

Les groupes de noeuds et les clés de partitionnement permettent de :

Pour plus d'informations sur la création de groupes de noeuds, reportez-vous au manuel SQL Reference. Pour plus d'informations sur l'utilisation de groupes de noeuds, reportez-vous au manuel Administration Guide.

Noeuds logiques multiples

Généralement, vous configurez DB2 Enterprise - Extended Edition de manière à ce qu'un serveur de partitions de base de données soit affecté à chaque ordinateur. Cependant, dans certains cas, il s'avère plus avantageux que plusieurs serveurs de partitions de bases de données soient affectés à chaque ordinateur. Si ces serveurs de partitions de bases de données (noeuds) font partie de la même instance, il s'agit alors d'une configuration à noeuds logiques multiples (MLN).

Les configurations à noeuds logiques multiples (MLN) s'avèrent utiles lorsque le système exécute des requêtes sur un ordinateur doté d'une architecture de multiprocesseurs symétriques (SMP). De plus, des noeuds logiques multiples permettent de tirer parti des configurations matérielles SMP. En outre, la taille des partitions de base de données étant inférieure, vous pouvez obtenir de meilleurs performances lors d'opérations telles que la sauvegarde et la restauration de partitions de base de données et d'espaces table, et la création d'index. En général, nous recommandons d'utiliser un noeud logique multiple par ensemble de quatre processeurs. En fonction du système d'exploitation utilisé avec DB2 EEE, cela peut varier pour des raisons de performances.

Pour plus d'informations sur la configuration des noeuds logiques, reportez-vous au manuel Administration Guide.

Instances

Une instance dispose de ses propres bases de données et de son propre répertoire d'instance. Le répertoire d'instance contient le fichier de configuration du gestionnaire de bases de données, les répertoires du système de bases de données, les répertoires des noeuds et le fichier de configuration des noeuds. Pour plus de détails sur les instances d'un système de bases de données partitionnées, reportez-vous au manuel Administration Guide.

Dans DB2 Enterprise - Extended Edition, une instance est constituée de tous les serveurs de partitions de bases de données (noeuds) définis pour faire partie d'un système de bases de données partitionnées spécifique. Les serveurs de partitions de bases de données sont définis dans le fichier db2nodes.cfg en tant que noeuds.

Les droits permettant d'accéder à chacune des instances se trouvant sur un même ordinateur sont différents. Cela est illustré par la Figure 3, qui présente deux instances distinctes. L'instance 1 contient six serveurs de partitions de bases de données et l'instance 2 en contient huit. (Il existe plusieurs serveurs de partitions de bases de données lorsque plusieurs lignes relient un serveur de partitions de bases de données et le répertoire d'instance.) Les deux instances se chevauchent, mais cela est dû à l'affectation de deux serveurs de partitions de bases de données à chacun des trois ordinateurs se trouvant au centre de la figure.

Le fichier db2nodes.cfg de l'instance 1 n'indiquera pas les serveurs de partitions de bases de données appartenant à l'instance 2, et inversement.

Figure 3. Deux instances

Diagramme décrivant deux instances

Plusieurs instances peuvent se trouver sur le même ordinateur, chacune d'entre elles étant configurée de manière différente :

Chaque instance appartient à un utilisateur appelé propriétaire de l'instance. Pour plus de détails sur la création d'instances, reportez-vous au manuel Administration Guide.

Le propriétaire de l'instance dispose des droits SYSADM pour toutes les bases de données appartenant à l'instance. Puisqu'il contrôle presque totalement l'instance, cet ID utilisateur peut :

Le propriétaire de l'instance ne peut pas supprimer une instance (il faut pour cela disposer des droits root.)

Une relation bi-univoque existe entre l'instance et son propriétaire, en ce sens qu'un utilisateur ne peut pas être propriétaire de plusieurs instances. (Cependant, un propriétaire d'instance peut disposer de droits d'accès à d'autres instances, y compris jusqu'aux droits SYSADM). De plus, chaque instance doit disposer d'un répertoire personnel distinct.

Gestionnaire FCM

Le gestionnaire FCM (Fast Communications Manager) offre un support de communication pour DB2 Enterprise - Extended Edition. Chaque serveur de partitions de base de données dispose d'un démon FCM assurant la communication avec les autres serveurs de partitions de bases de données en vue de la gestion des demandes des agents et de la transmission des mémoires tampon de messages. Le support consiste en :

Le démon FCM est démarré lorsque vous démarrez l'instance. Il lit alors le fichier de configuration des noeuds (INSTHOME/sqllib/db2nodes.cfg, où INSTHOME représente le répertoire personnel du propriétaire de l'instance) et définit une adresse identifiée à utiliser dans les communications.

Si la communication entre les serveurs de partitions de bases de données échoue ou si elle est rétablie, le démon FCM met à jour les informations (que vous pouvez visualiser à l'aide du moniteur du gestionnaire de bases de données) et lance l'opération appropriée (telle que l'annulation d'une transaction affectée).

note

Vous pouvez spécifier le nombre de mémoires tampon de messages FCM à l'aide du paramètre de configuration du gestionnaire de bases de données fcm_num_buffers. Pour une description de ce paramètre et des autres paramètres FCM, reportez-vous au manuel Administration Guide.

Haute disponibilité (High Availability)

Vous pouvez configurer votre système de bases de données partitionnées de sorte que le serveur de bases de données puisse s'exécuter sur une autre machine si une machine est défaillante.

Sous AIX, la fonction de secours est mise en oeuvre par HACMP (High Availability Cluster Multi-Processing). Cette fonction permet le transfert automatique de la charge d'un processeur sur un autre en cas de défaillance matérielle ou logicielle. HACMP offre une meilleure disponibilité via un cluster de processeurs qui partagent les ressources telles que les disques et les accès réseau.

Sur les systèmes Solaris, la fonction de secours est assurée par Sun Cluster 2.2. Celui-ci peut détecter les défaillances et redémarrer les ressources dans un environnement de clusters. Il constitue également le support de reprise pour les disques physiques et les adresses IP.

Actuellement, le support de reprise DB2 pour les systèmes d'exploitation HP-UX ou PTX est un processus manuel qui implique le redémarrage manuel du noeud logique défaillant sur un noeud ayant accès au disque de celui-ci.

Pour plus d'informations, reportez-vous au manuel Administration Guide.


[ Début de page | Page précédente | Page suivante | Table des matières | Index ]