Ci-dessous, les différences entre deux révisions de la page.
wiki:cluster:sql [2017/07/01 21:30] insolentbacon |
wiki:cluster:sql [2020/06/27 18:16] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Cluster NDB (MySQL) ====== | ||
- | |||
- | ==== Introduction ==== | ||
- | |||
- | Actuellement nous avons le SQL (avec MySQL en backend) sur | ||
- | spirit. Il est stocké directement sur le disque en local. | ||
- | Des sauvegardes sont faites régulièrement sur les NAS, ils sont | ||
- | dump dans un fichier " | ||
- | |||
- | L' | ||
- | qui nous permetterait d' | ||
- | 1/ De la redondance | ||
- | 2/ De la "haute disponibilité" | ||
- | |||
- | |||
- | === 1/ La redondance === | ||
- | |||
- | |||
- | Un NDB cluster est consisté de *Data Nodes*, noeuds qui | ||
- | permettent de stocker les tables et databases MySQL. | ||
- | |||
- | L' | ||
- | le cluster pour qu'il y ait autant de copies de la BDD que de | ||
- | noeuds de prod. On aurait donc une sauvegarde de notre BDD sur | ||
- | chaque noeud. | ||
- | |||
- | Ça ne remplacera bien évidemment pas les backups réguliers mais | ||
- | ça permettera de ne pas perdre toute une journée d' | ||
- | cas de défaillance du disque de spirit (pas de raid). | ||
- | |||
- | === 2/ _La haute disponibilité_ === | ||
- | |||
- | Le cluster a aussi des *SQL Nodes*. C'est en quelque sorte des | ||
- | " | ||
- | comportent comme des serveurs MySQL qui vont aller interroger | ||
- | les *Data Nodes*. | ||
- | |||
- | Le SQL est critique à MiNET... sans lui pas de radius, donc pas | ||
- | de DHCP donc pas d' | ||
- | On peut configurer un système d'IP flottante pour qu'on ait en | ||
- | permanance l' | ||
- | des noeuds sont shutdown.) | ||
- | |||
- | |||
- | === 3/ Que foutre sur ce cluster ? === | ||
- | |||
- | Il faut savoir que chaque noeud de NDB consomme à peu près | ||
- | autant de RAM que la taille de la BDD qu'il traîte (si on fait 1 | ||
- | réplication par noeud). | ||
- | |||
- | Je pense qu'il n'est donc pas jusdicieux de mettre toutes les | ||
- | tables qu'on a actuellement sur le SQL. | ||
- | |||
- | Genre ostickets, base de donnée qui fait 0.5GiB, redondé en HA, | ||
- | je suis pas sûr que ça soit judicieux. Pareil pour | ||
- | etherpad/ | ||
- | gars). | ||
- | |||
- | Je propose donc de juste mettre la BDD adh5-prod qui fait | ||
- | ~200MiB sur tous les noeuds. | ||
- | En allouant 512MiB de mémoire pour chaque VM *Data Node* sur | ||
- | chaque noeud de prod' on est large. | ||
- | |||
- | Sachant qu'on a à peu près 150MiB de logs dedans qu'on pourrait | ||
- | élaguer un peu, je suis sûr qu'on peut stocker juste 100MiB | ||
- | d'ADH5 sur le cluster. | ||
- | |||
- | ==== La partie technique ==== | ||
- | |||
- | Le cluster est constitué de trois types de machines. | ||
- | Des noeuds de " | ||
- | Les noeuds SQL sont sur des VMs pour pouvoir un meilleur contrôle sur le réseau (notamment pouvoir faire des IP flottantes/ | ||
- | |||
- | |||
- | Pour gérer le cluster on peut utiliser ndb_mgm qui fait partie du package // | ||
- | |||
- | root@ndbmgmt1: | ||
- | -- NDB Cluster -- Management Client -- | ||
- | ndb_mgm> show | ||
- | Connected to Management Server at: localhost: | ||
- | Cluster Configuration | ||
- | --------------------- | ||
- | [ndbd(NDB)] 4 node(s) | ||
- | id=1 @192.168.102.38 | ||
- | id=2 @192.168.102.44 | ||
- | | ||
- | [...] | ||
- | | ||
- | | ||
- | Il ne faut pas oublier d' | ||
- | |||
- | === Le management === | ||
- | |||
- | **Attention, | ||
- | |||
- | Pour lancer les processus de management il suffit de faire | ||
- | ndb_mgmd --initial -f / | ||
- | | ||
- | Vous l' | ||
- | |||
- | === Le stockage === | ||
- | Sur ndbdata1, | ||
- | ndbd | ||
- | |||
- | Les noeuds utilisent 0.75GiB de RAM pour stocker les relations. Ne vous alarmez pas si vous voyez qu'ils utilisent 100% de la RAM du container, c'est normal. (Et même, si vous voulez vous amuser, vous pouvez augmenter la RAM du container et vous rendre compte qu'il utilisera quand même 100% de la RAM) | ||
- | |||
- | === Les noeuds d' | ||
- | Sur les noeuds d' | ||
- | |||
- | Leur disponibilité est cruciale. C'est pour ça qu'il y a un système d'IP virtuelle, mis en place grâce à keepalived qui s' | ||
- | |||
- | Pour permettre à MySQL de listen sur l'IP 192.168.102.52 même sur les machines qui n'ont pas cette ip, il faut juste faire: | ||
- | |||
- | echo 1 > / | ||
- | |||
- | ou ajouter dans / | ||
- | |||
- | net.ipv4.ip_nonlocal_bind = 1 | ||
- | |||
- | |||
- | |||
- | |||
- | |||