Choix de l’architecture matérielle

Une plateforme de base de données est constituée d’un ou plusieurs serveurs, d’un système d’exploitation, d’un SGBD et d’un support de stockage des données.

Le choix d’une architecture matérielle destinée à supporter une base de données volumi-neuse est guidé principalement par le souci d’atteindre le meilleur rapport prix/performances, l’extensibilité et la disponibilité des données [77]. Actuellement, les architectures parallèles sont disponibles sous plusieurs formats tels que les Multi-Processeurs Symétriques (SMP), les Clus-ters, les Machines Massivement Parallèles(MMP). Ces architectures sont classifiées selon les critères suivants: partage de la mémoire (shared-memory), partage des disques (shared disks), sans aucun partage (shared nothing) et partage partiel des ressources (shared-something). En conséquence, les architectures parallèles sont classifiées selon différentes catégories :

shared-2.1. Les étapes de la phase de déploiement d’un EDP

memory, shared-disk, shared-nothing et shared-something. Dans ce qui suit, nous décrivons d’abord les trois architectures conventionnelles et leurs architectures hybrides qui tentent de combiner les avantages de chaque architecture puis les architectures alternatives telles qu’elles sont présentées dans la littérature [119, 135].

2.1.1.1 Architectures conventionnelles

Il y a trois architectures conventionnelles et des architectures hybrides qui tentent de com-biner les avantages de chacune d’elles [58, 135]. La figure 2.2 illustre les trois architectures conventionnelles, avec leur architecture hybride.

Figure 2.2 – Architetcures matérielles usuelles

2.1.1.1.1 Architectures à mémoire partagée (shared-memory). Les processeurs et les disques ont accès à une mémoire commune, typiquement par un bus ou un réseau d’intercon-nexion. L’intérêt de l’utilisation de cette architecture est l’efficience de la communication entre les processeurs ; les données sont accessibles par n’importe quels processeurs. Chaque proces-seur peut envoyer rapidement un message aux autres en écrivant en mémoire au lieu d’utiliser les canaux de communication. L’inconvénient majeur de cette architecture est le fait qu’elle n’est pas scalable (32 à 64 nœuds). Cela est dû au fait que le bus (le réseau d’interconnexion) devient un goulot d’étranglement. L’ajout de nouveaux processeurs implique l’accroissement du temps d’attente pour accéder à la mémoire principale partagée. Généralement, l’architec-ture à mémoire partagée a une large mémoire cache au niveau de chaque processeur de sorte que le référencement de la mémoire partagée est évité autant que possible. En outre, les caches doivent être cohérents, c’est-à-dire que si un processeur effectue une écriture dans un empla-cement mémoire, les données de cet emplaempla-cement mémoire doivent être soit mises à jour ou

supprimées de n’importe quel autre processeur où les données sont mises en cache.

2.1.1.1.2 Architectures à disques partagés (shared disks). Chaque processeur dé-tient sa propre mémoire centrale et le disque est partagé entre tous les processeurs. L’architec-ture à disques partagés est similaire à l’architecL’architec-ture à mémoire dans le sens qu’une mémoire secondaire est partagée. Elle souffre de congestion dans le réseau d’interconnexion quand plu-sieurs processeurs essayent d’accéder au disque en même temps. En effet, le traitement de l’ensemble des sous-requêtes nécessite la récupération des données du disque partagé pour les stocker dans sa mémoire locale. Ainsi, la différence principale entre l’architecture à mémoire partagée et celle à disque partagé est la hiérarchie de la mémoire qui est partagée.

Dans le contexte des nouvelles architectures logicielles, les architectures à disques parta-gés et à mémoire partagée sont considérés comme des machines multiprocesseurs symétriques (Symmetric Multi Processor, SMP).

Une machine SMP typique est constituée de plusieurs CPUs allant de 2 à 16 CPUs. Donc, un nombre élevé des processeurs n’est pas tolérable à cause des problèmes de passage à l’échelle. Chaque processeur maintient son propre cache et une mémoire principale partagée entre tous les processeurs. La taille de la mémoire principale et du cache diffère d’une machine à l’autre. Plusieurs disques peuvent être attachés à une machine SMP et tous les CPU auront un accès similaire. Le système d’exploitation alloue normalement les tâches selon un ordonnanceur. Un processeur est inactif, une tâche dans sa file d’attente est immédiatement attribuée. De cette façon, l’équilibrage est relativement facile à réaliser.

2.1.1.1.3 Architectures sans partage (shared-nothing) attribut à chaque nœud sa propre mémoire et son propre disque. Les processeurs communiquent entre eux via un réseau de communication à haut débit. Par ailleurs, les réseaux d’interconnexion des systèmes sans partage sont généralement conçus pour être évolutifs, de sorte que leur capacité de transmission augmente avec le nombre des nœuds qui sont ajoutés. En conséquence, l’architecture sans partage est plus scalable et peut aisément supporter un large nombre de processus. Teradata,

Grace et le prototype de recherche Gamma sont de type shared nothing. Le problème de

compétition pour accéder aux données partagées ne se pose pas pour cette architecture mais le problème d’équilibrage de charge est difficile à atteindre même pour les requêtes simples car les données sont stockées localement au niveau de chaque disque. Le problème de la mauvaise distribution est l’un des challenges dans le traitement parallèle des requêtes sur une machine de ce type.

Dans le contexte des nouvelles architectures logicielles, la machine sans partage est classifiée comme machine massivement parallèle(Massively Parallel Processing, MPP). Cette architec-ture est caractérisée par le haut débit de son réseau d’interconnexion.

2.1.1.1.4 Architectures hybrides. Il s’agit d’une combinaison des architectures sans par-tage et à mémoires partagées. Elle combine les avanpar-tages de chacune et compense leurs incon-vénients respectifs. Elle réalise à la fois l’équilibre de charge des architectures à mémoires partagées et l’extensibilité des architectures sans partage. Cette architecture est nommée

Sha-2.1. Les étapes de la phase de déploiement d’un EDP red Something. Elle augmente la flexibilité de la configuration (nombre des nœuds et taille

des nœuds) et diminue le coût de communication réseau car le nombre de nœuds est réduit. Le parallélisme intra-requête peut être isolé à un seul multiprocesseur shared-memory car il est beaucoup plus facile de paralléliser une requête dans une architecture à mémoire partagée que dans une architecture sans partage. En outre, le degré de parallélisme sur un seul nœud à mémoire partagée peut être suffisant pour la plupart des applications. Autrement dit, le parallélisme intra-requête est obtenu à travers l’exécution parallèle sur les nœuds.

Il en existe plusieurs variantes de cette architecture mais fondamentalement chaque nœud est une machine à mémoire partagée connectée au réseau d’interconnexion de l’architecture sans partage.

2.1.1.2 Architectures distribuées

Aujourd’hui, nous assistons à une émergence dans le développement des ordinateurs et des réseaux à haut débit. Cela a donné naissance à de nouvelles architectures matérielles distribuées qui peuvent être utilisées comme des plateformes logicielles pour le déploiement des systèmes parallèles

2.1.1.2.1 Les architectures grappes de machines (cluster). Un cluster est un en-semble de nœuds interconnectés pour partager des ressources pour un seul système. Les res-sources partagées peuvent être un matériel comme un disque ou un logiciel comme un sys-tème de gestion de données. Les nœuds d’un cluster sont des composantes simples comme un micro-ordinateur (PC) ou des machines plus puissantes comme les SMP. L’utilisation des composantes off-the-shelf est essentielle pour obtenir le meilleur rapport prix/performance tout en exploitant le progrès continu des composantes matérielles. Dans sa forme la moins chère, l’interconnexion entres les nœuds peut être un simple réseau. Cependant, il existe actuellement un standard pour l’interconnexion des nœuds d’un cluster nommé Myrinet and Infiniband qui produit des réseaux à haut débit (Gigabits/sec) avec une faible latence pour le transfert des messages. Contrairement aux systèmes distribués, un cluster est regroupé géographiquement (sur le même site) et il est généralement homogène. L’architecture d’un cluster peut être soit sans partage soit à disque partagé.

Les clusters sans partage ont été largement utilisés car ils fournissent le meilleur rapport qualité/prix et peuvent atteindre des milliers de nœuds (evolutifs).

Les clusters à disques partagés existent sous deux formats.

– un N AS est une plateforme qui partage le disque sur un réseau en utilisant un protocole de distribution des fichiers systèmes comme Network File System. Le N AS est bien adapté pour les applications à faible débit telles que la sauvegarde et l’archivage de données à partir de disques durs des P C. Cependant, il est relativement lent et il ne convient pas pour la gestion des bases de données car il devient rapidement un goulot d’étranglement avec de nombreux nœuds,

– un SAN produit des fonctionnalités similaires mais avec des interfaces à niveau inférieur. Il utilise un protocole basé sur des blocs, ce qui facilite la gestion de la cohérence du cache. SAN fournit un haut débit de données et peut évoluer jusqu’à un grand nombre de nœuds.

Figure 2.3 – Exemple d’un cluster d’ordinateurs

Sa seule limitation à l’égard de shared-nothing est son coût d’acquisition élevé.

Les architectures clusters ont beaucoup d’avantages. D’une part, elles combinent la flexi-bilité et la performance des architectures à mémoires partagées au niveau de chaque nœud. D’autre part, elles assurent l’extensibilité et la disponibilité de l’architecture à disques parta-gés ou sans partage. En outre, l’utilisation des nœuds off-the-shelf à mémoire partagée avec une interconnexion standard de clusters fournit une alternative rentable pour approprier une plateforme à haute performance comme N U M A ou M P P .

2.1.1.2.2 Grille de calcul. Elle découle de la combinaison de ressources informatiques à partir de multiples domaines administratifs appliqués à une tâche commune, généralement à un problème scientifique, qui nécessite le traitement d’une grande quantité de données. Cette architecture permet le partage, la sélection et l’agrégation de ressources autonomes réparties géographiquement de manière dynamique durant l’exécution des requêtes en fonction de leur disponibilité, capacité de stockage, puissance de calcul, coût et qualité de service [75]. Ce sont rien d’autre que des clusters à grande échelle, que la figure 2.4 illustre un exemple d’infrastruc-ture grille de calcul.

2.1. Les étapes de la phase de déploiement d’un EDP 2.1.1.2.3 Cloud de calcul. Le Cloud est particulièrement avantageux pour les petites et moyennes entreprises qui souhaitent externaliser complètement leurs infrastructures de centres de données, ou les grandes entreprises qui souhaitent obtenir une haute capacité de calcul et de stockage sans engager de coût élevé de construction de centres de calcul importants en interne. Le Cloud est une extension de ce paradigme où les capacités des applications sont exposées comme des services sophistiqués qui peuvent être accessibles sur un réseau facturés selon la consommation.

Un nuage (Cloud) est un système parallèle composé d’un ensemble d’ordinateurs intercon-nectés, dynamiquement provisionnés et présentés comme une ou plusieurs ressources informa-tiques unifiées basées sur le service. Fondamentalement, un nuage peut être : un nuage public qui désigne une structure souple et ouverte dédié à la vente de services dont les informations peuvent être consultées à partir d’Internet. Un Cloud privé est un réseau propriétaire ou un centre de calcul qui fournit des services hébergés à un nombre limité de personnes. Les infor-mations et les applications qui s’exécutent sur le Cloud privé peuvent être consultées à partir de l’intranet de l’entreprise en utilisant une connexion VPN entre le centre de calcul interne et l’infrastructure du sous-traitant. La figure 2.5 illustre un exemple de l’infrastructure Cloud de calcul.

Figure 2.5 – Exemple de l’infrastructure cloud de calcul