Les SGBDR en cluster

fadace

Voici un petit comparatif qui vous permettra de voir plus clair dans la jungle des diverses architectures, toutes cachées sous le terme de cluster. ?

- Titre : Les SGBDR en cluster

- Auteur : fadace

- Parution : 10 juin 2009

- Licence : Copyright ® 2009 fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. La problématique et les challenges

- III. Les stratégies

- III-A. Ne rien partager (share nothing)

- III-B. Tout dédoubler (share nothing with replication)

- III-C. Partager les disques (shared disks)

- III-D. Partager disques et mémoire (shared disks with cache fusion)

- IV. Résumé du comparatif

- V. Autres liens

I - Introduction

Avec l'augmentation des volumes des données, la montée en charge des utilisateurs sur les SGBDR la demande de haute disponibilité, et la différence de coût entre hosts et petits systèmes, la mise en réseau d'une base de données devient une demande grandissante du marché.

Quelques éditeurs offrent déjà un certain nombre de solutions, avec plus ou moins de bonheur.

Si les bases de données se ressemblent plus ou moins toutes en ce qui concerne leur interface (norme SQL), des fonctionnalités backoffice telles que la clusterisation diffèrent énormément d'un éditeur à un autre.

Voici donc un petit comparatif qui vous permettra de voir plus clair dans ces nouveaux concepts.

Dans cet article ne sont pas abordées les notions :

- de cluster via système d'exploitation qui consistent à virtualiser 2 machines en une (SQL Server cluster pré 2005, Oracle Fail Safe) ;

- de solutions fail-over / warm-standby gravitant au niveau des réplications diverses.

Le marché s'oriente résolument vers des architectures Blade (fermes de PC) sur Linux (Suse Enterprise ou RedHat Advanced Server), en s'appuyant sur

- leur stabilité ;

- leur faible coût d'investissement ;

- leur reconnaissance de la part de la plupart des éditeurs de SGBDR ;

- un système d'exploitation 64 bits ;

- une gestion de mémoire optimisée même au-delà des 3 Go… ;

- un tuning de disques fin (asynchronous IO).

II - La problématique et les challenges

Avant tout, à quoi sert le clustering ? Cette idée vient du concept de Grid, ou virtualisation des ressources, déjà utilisé dans des projets tels que le Seti.

Un SGBDR est une application gourmande en mémoire, en disques et en CPU. Sur le marché, les gros serveurs (mainframe) sont fortement coûteux, tandis que de petites machines sont relativement peu onéreuses. Il faut donc trouver un moyen de fédérer ces petites machines afin qu'elles réagissent comme une grosse.

Comme vous le verrez rapidement, un des challenges du grid reste entier, quelle que soit la stratégie choisie et quel que soit l'éditeur : celui de la virtualisation des diverses mémoires. À qui le premier ?

III - Les stratégies

III-A - Ne rien partager (share nothing)

C'est la stratégie utilisée par IBM DB2-UDB EEE

DB2-UDB EEE se base sur une technologie share-nothing, ce qui n'en fait techniquement pas une base cluster, mais plutôt une base distribuée.

En environnement EEE (cluster), la conception de l'accès aux données n'est pas totalement transparente pour le développeur : écrite sans suivre des lignes bien précises, des applicatifs peuvent se retrouver à n'utiliser qu'un nœud majeur, au détriment de toute la plateforme.

Cette architecture convient à des applications aisément sécables, mais peut fortement péjorer les performances des requêtes qui ne suivraient pas les clés de répartitions choisies lors des partitionnements.

Pour gérer de manière « plus transparente » les nœuds, il est nécessaire de se baser sur la couche cluster de l'OS pour gérer le contrôle de validité des nœuds (heartbeat).

Lors de la chute d'un nœud, on perd momentanément l'accès à ses données tant qu'un autre nœud ne reprend pas la main sur elles. Pour que cette reprise ait lieu, il faut donc

- travailler avec des disques partagés (!) afin qu'une instance secondaire située sur une autre machine puisse prendre le relais ;

- mettre son instance secondaire sur la même machine (!) que la primaire pour ne pas utiliser de disques partagés.

Relevons que pour pallier certaines de ces faiblesses, IBM offre une solution - Parallel Sysplex - orientée… disques partagés…

III-B - Tout dédoubler (share nothing with replication)

C'est la stratégie utilisée par MySQL, développée par Ericsson : chaque nœud comprend la totalité de l'information du système. Il semblerait que le pgCluster de PostgreSQL se base sur les mêmes principes.

La synchronisation des données se fait via un mécanisme de réplication interne, et en mode synchrone. Tout se réplique sur tout, ce qui laisse présager quelques soucis avec un nombre de nœuds important…

Ce choix étrange est fortement prétéritant pour les performances, mais c'est le prix de la sécurité pour une technologie essentiellement orientée fail-over.

Répliquer l'information autant de fois qu'il y a de nœuds est de plus fortement coûteux en terme de disques (pour n Go de données et m nœuds, il faut avoir n*m Go de disque )et en terme de CPU (toutes les transactions OLTP se jouent sur tous les nœuds).

Il va sans dire que cette solution marche à merveille lors d'une quelconque perte d'instance, tout étant répliqué partout.

III-C - Partager les disques (shared disks)

C'est la stratégie utilisée par Sybase ASE : une base est visible et utilisable par toutes les instances, mais seule une instance gère toutes les modifications.

En cas de crash d'une instance, c'est une autre instance qui transforme sa base Proxy (remote) en base locale.

III-D - Partager disques et mémoire (shared disks with cache fusion)

C'est la stratégie utilisée par Oracle RAC : chaque nœud peut accéder à la totalité de l'information du système

Oracle offre enfin un environnement cluster digne de ce nom. Il s'appuie sur une technologie RAC de disques partagés, ce qui fait que chaque instance Oracle voit et utilise les mêmes données.

L'intérêt de cette technologie est sa transparence quasi totale : aucune spécificité n'est à gérer dans le code et le passage « Oracle simple instance » à « Oracle RAC » ne nécessite aucun changement au niveau du développement. Il faudra par contre, au niveau DBA, passer par une recréation de base + full export/import.

C'est un sous-système Oracle qui gère intelligemment la notion de verrous et de synchronisation de blocs mémoire, permettant ainsi l'utilisation simultanée d'une donnée par plusieurs instances.

Lors de la chute d'un nœud, on ne perd pas d'accès aux données et on continue à travailler en mode dégradé (avec un TAF bien réglé, cela s'entend).

IV - Résumé du comparatif

Stratégie

Tout dédoubler

Ne rien partager

Partager les disques

Partager disques et mémoire

Éditeur

Disponibilité jusqu'au dernier nœud

OUI

NON

OUI

OUI

Transparence au design

OUI

NON

OUI

OUI

Indépendance des instances

OUI

NON

NON

OUI

Volumétrie non duplifiée

NON

OUI

OUI

OUI

Écriture d'un bloc de données via plusieurs nœuds

OUI

NON

NON

OUI

Performance / montée en charge

NON

OUI

NON

OUI

Interréplication nécessaire

OUI

NON/OUI

NON

NON

Synchronisation disques/mémoire

Réplication

Distribution

Base proxy

Fusion mémoire

Intégration à un existant

Plug-In

Reload / split

Plug-In

Plug-In

Tuning fin nécessaire sur partitionnement

NON

OUI

NON

NON

Convient pour grand nombre de nœuds

NON

OUI

OUI

OUI

Unicité nécessaire dans chaque table

NON

OUI

NON

NON

Open source

OUI

NON

NON

NON

Microsoft ne propose toujours pas de version en vrai cluster au niveau de la base: sa technologie s'appuie sur le cluster Windows et permet une quasi haute disponibilité en remontant plus ou moins rapidement une instance dont le nœud serait tombé sur un nœud sain. Cela reste de l'actif/passif… bien éloigné de ce que proposent ses concurrents.

V - Autres liens

- SGBDR : le comparatif

- Clustering MySQL

- IBM DB2-UDB EEE

- Oracle RAC