version PDF - Flash informatique

26 JANVIER 2010 - N°1
13
26 JANVIER 2010 - N°1
This article gives you a brief explanation of what
MySQL Cluster is, in which cases you can use it and
also includes some useful tips.
Cet article va s’intéresser de manière non exhaus-
tive au clustering MySQL en expliquant ce qu’il peut
apporter, dans quel cas l’utiliser et ce à quoi il faut
être attentif.
Lorsque vous souhaitez que votre application soit disponible 7j/7,
24h/24, la notion de cluster est assez rapidement évoquée comme
étant la réponse adéquate au besoin. Mais qu’est ce qu’un cluster ?
Cela peut être vu comme un regroupement de machines commu-
niquant entre elles qui permet d’augmenter la disponibilité (si une
machine tombe, une autre prend le relais), d’absorber une montée
en charge, faciliter la gestion des ressources. Cependant, l’utilisa-
teur extérieur perçoit cet ensemble comme une seule entité.
Cet article va tenter de traiter de la gestion du clustering par MyS-
QL Cluster 5.1. L’actuelle version GA
& est la 7.0 mais elle n’a pas
été testée par l’auteure.
MySQL Cluster a été conçu pour le marché des télécommunica-
tions qui, pour leurs applications, avait besoin d’une haute dispo-
nibilité, avec des bases de données de taille relativement petites,
qui supporte de nombreuses lectures avec peu d’écritures. On voit
tout de suite que cela s’adresse à des applications particulières !
Ce qu’il permet de faire ?
Haute disponibilité (élimination de SPOF
&, redondance et failo-
ver
&), scalabilité &, haute performance, équilibrage de charge
sont les objectifs mais attention ! l’application doit être pensée
pour le clustering MySQL sinon les objectifs risquent de n’être
partiellement voire pas du tout remplis. Une autre caractéristique
est de pouvoir faire des backups à chaud. Le produit est éprouvé
car il est utilisé en production par des applications grandement
utilisées mais il n’est pas la réponse magique aux problèmes de
performances.
De plus, l’administration d’un cluster MySQL est complètement
différente d’un serveur traditionnel et donc mérite de la forma-
tion et du temps.
Comment cela fonctionne ?
Un cluster MySQL est composé de:
z un ou plusieurs nœuds nommés nœuds API ou SQL pouvant être
considérés par l’application comme étant les points d’entrée
au cluster, ils traitent les requêtes et récupèrent les données;
z des nœuds appelés nœuds de données qui stockent et traitent
les données;
z un ou plusieurs nœuds d’administration permettant de faire
l’administration du cluster.
Il faut au minimum quatre nœuds afin de garantir la haute dis-
ponibilité: un nœud d’administration (qui peut aussi héberger un
nœud API/SQL en backup), un nœud API/SQL (qui peut aussi hé-
berger un nœud d’administration en backup) et deux nœuds de
données.
Configuration minimale d’un cluster MySQL
Afin de garantir le failover, une même donnée se trouve sur au
moins deux nœuds de données différents (selon la configuration
demandée).
Comme un schéma vaut mieux qu’un long discours, en voici un
pour essayer d’expliquer au mieux comment se fait la répartition
des données.
Schématisation du processus de fractionnement d’une table
MySQL Cluster 5.1
Julia.Paolini@epfl.ch
EPFL - Domaine IT, Responsonable MySQL
Analyse

14 26 JANVIER 2010 - N°1 14
26 JANVIER 2010 - N°1
26 JANVIER 2010 - N°1 26 JANVIER 2010 - N°1
Les rectangles NDBD représentent les nœuds de données.
La table est d’abord divisée en plusieurs partitions (P1, P2, P3, P4).
Dans l’exemple, le cluster est configuré pour qu’une donnée existe
à deux endroits différents (nombre de réplicas=2), on appelle
fragment primaire la partition qui est utilisée par les requêtes et
le fragment secondaire la partition qui est utilisée pour le backup.
De cette manière, tant qu’un nœud dans chaque node group est
vivant, le cluster continue de fonctionner car l’entièreté des don-
nées sont disponibles.
Par contre si tous les nœuds d’un node group tombent, le cluster
s’arrête de fonctionner.
Le mécanisme de réplication synchrone est utilisé de manière
à garantir la consistance des données entre les différents frag-
ments: lorsque l’on souhaite modifier une donnée, l’ordre est en-
voyé au serveur MySQL qui détermine quel est le nœud qui stocke
le fragment primaire correspondant à cette donnée et la modifie.
Il est ensuite envoyé aux autres nœuds du même node group afin
que le(s) fragment(s) secondaire(s) soi(en)t modifié(s). Attention
toutefois, plus la donnée est volumineuse et est dupliquée, plus
cela demande du temps pour l’écrire et la modifier !
Ce à quoi il faut faire attention
Sans rentrer dans les détails qui ne vous dirons (peut-être) rien,
voici quelques informations (toujours non exhaustives bien sûr) à
prendre en compte:
z Voici le matériel recommandé par MySQL pour les serveurs
utilisés comme nœuds de stockage dans le cluster:
w Système: Linux (Red Hat, SuSe), Solaris, AIX, HP-UX, Mac
OSX.
w CPU: 2 processeurs: Intel Xeon, Intel Itanium, AMD Opte-
ron, Sun SPARC, IBM PowerPC.
w Mémoire: 16 GB RAM.
w Disque: 4 disques 36GB SCSI (contrôleur RAID 1).
w Réseau: Ethernet gigabit.
z Il faut au minimum quatre nœuds (donc quatre machines)
avec une mémoire conséquente car les données et les index
sont maintenus en mémoire.
z Pour des raisons de performances, les quatre nœuds devraient
être dédiés au clustering.
z S’il y a beaucoup plus d’écritures que de lectures, les perfor-
mances risquent de chuter.
z Attention au nombre de jointure dans une même requête, plus
il y en a plus les performances vont diminuer.
z Administration différente d’un serveur MySQL classique et
plus complexe.
z Pour l’instant que sur Linux.
z Certains ordres SQL qui fonctionnent avec un MySQL clas-
sique produisent une erreur (création de tables temporaires,
limitations sur les index …).
Deux petits tableaux comparatifs, MyISAM et InnoDB étant des
moteurs de stockage de MySQL et NDB étant le (seul) moteur de
MySQL Cluster.
MyISAM versus NDB
Caractéristique MyISAM NDB
Supporte les transactions multi ins-
tructions et les rollback
&Non Oui
Supporte les index fulltext Oui Non
Peut utiliser les recherches hash Non Oui
Supporte l’Unicode à partir de la
version 4.1 5.0
Peut compresser le stockage en lec-
ture seule Oui Non
Supporte les clés étrangères Non Non
Supporte les transactions Non Oui
Verrou au niveau Table Enregistre-
ment
Utilise beaucoup de RAM et a beau-
coup de trafic réseau Non Oui
InnoDB versus NDB
Caractéristique InnoDB NDB
Supporte les contraintes des clés
étrangères Oui Non
Supporte les transactions Oui Oui
Verrou au niveau Enregistre-
ment
Enregistre-
ment
Supporte l’Unicode à partir de la
version 4.1.2 5.0
Utilise beaucoup de RAM et a beau-
coup de trafic réseau Non Oui
Au bout du compte
MySQL Cluster apporte tout ce qui a trait à la notion de disponi-
bilité (99,999%) et de performance mais la scalabilité est réduite
dans le sens où l’on peut rajouter à chaud uniquement des nœuds
d’administration et API/SQL. Il faut faire attention à la notion
d’équilibrage de charge car dans le cas de MySQL Cluster elle se
fait grâce à la répartition des données sur plusieurs nœuds (donc
chaque nœud s’occupe du traitement de ses données) mais pas
parce que la donnée existe à plusieurs endroits. En effet, seul le
fragment primaire est utilisé pour la lecture et l’écriture.
La version 7.0 de MySQL Cluster semble apporter sont lot de
nouveautés intéressantes, comme par exemple l’amélioration de
la scalabilité en donnant la possibilité d’ajouter/supprimer des
nœuds de données à chaud. Elle permet aussi de tirer avantage
du multithreading, ce qui n’était pas possible avant. Cela permet-
trait, selon MySQL, d’améliorer grandement les temps de réponse.
MySQL s’est aussi intéressé à la plate-forme Windows car la ver-
sion 7.0 peut dorénavant être installée sur du 2003 Server, XP ou
Vista mais pour le moment uniquement pour du développement.
Certaines limitations ont aussi été repoussées comme par exemple
le nombre de nœuds qu’un cluster pouvait gérer.
MySQL Cluster 5.1

26 JANVIER 2010 - N°1 26 JANVIER 2010 - N°1
26 JANVIER 2010 - N°1
1515
26 JANVIER 2010 - N°1
Dans tous les cas, il n’est pas pensable de prendre une application
existante telle quelle et de la clusteriser. Il faut vraiment prendre
le temps de repenser l’application afin de l’adapter au produit !
Pour toute question concernant MySQL, vous pouvez contac-
ter l’équipe d’administrateurs MySQL via mail: mysql-admin@
groupes.epfl.ch.
Le succès du service Doodle (www.doodle.com) ne se dément
pas. Il permet très facilement de gérer une prise de rendez-vous
ou de réaliser un petit sondage. L’outil est tellement agréable et
rapide à utiliser que désormais beaucoup de rendez-vous à l’EPFL
se concrétisent au moyen de ce service. Son business plan est
identique à celui de Google, un service gratuit qui se rémunère
à l’aide de publicité plus ou moins discrète. Cette démarche peut
évidemment poser problème à ceux qui considèrent assez juste-
ment qu’il n’y a pas de raison d’être envahi par de la publicité sur
son lieu de travail. C’est pourquoi nous avons décidé d’acquérir
une licence d’utilisation spécialement pour l’EPFL qui donne les
avantages suivants:
z suppression de la publicité
z trafic Web sécurisé par HTTPS
z utilisation du bandeau EPFL.
Ainsi, la suppression de la publicité et l’utilisation du bandeau
EPFL permettent encore de renforcer le sérieux de l’outil. De plus,
sa confidentialité est améliorée à l’aide d’un canal de communi-
cation crypté (HTTPS) entre le poste de travail et les serveurs Web
de Doodle.
Doodle@epfl
Pierre.Mellier@epfl.ch
EPFL – Domaine IT – Responsable du KIS
À votre service
L’accès au service Doodle pour l’EPFL se fait au moyen de l’URL
epfl.doodle.com, le service continuant à être hébergé chez
Doodle. Seules les personnes, identifiées à l’aide d’une adresse
email de l’EPFL (prenom.nom@epfl.ch), peuvent gérer des prises
de rendez-vous et des sondages. Pour vous connecter à ce service,
vous avez donc besoin de configurer un compte doodle avec votre
adresse email de l’EPFL. Bien sûr, les personnes qui répondent à la
prise de rendez-vous ou au sondage peuvent provenir quant à eux
du monde entier… n
MySQL Cluster 5.1
Pour la formation, vous pouvez joindre l’équipe responsable de la
formation par mail (cours.dit@epfl.ch), le matin par téléphone
(021 69 322 44) ou par fax [phone]).
Sur mysql.epfl.ch vous trouverez un récapitulatif de toutes les
informations concernant MySQL à l’EPFL. n
GLOSSAIRE &
Failover: commutation automatique vers
un système redondant ou en attente,
lors d’une panne.
GA (Generally Available): stable pour être en
production.
Jointure: combinaison des enregistre-
ments de deux tables disposant de va-
leurs correspondantes dans une colonne
donnée de chaque table (souvent ayant
le même nom dans les deux).
Rollback: annulation d’une transaction.
Scalabilité: possibilité de pouvoir étendre
un système facilement.
SPOF (single point of failure): élément d’un
système qui, dans le cas où il tombe en
panne, empêche le système entier de
fonctionner.