Webcontrat - Database : Différence entre versions
(→Mots de passe sudo) |
(→Problèmes connus) |
||
| (Une révision intermédiaire par le même utilisateur non affichée) | |||
| Ligne 91 : | Ligne 91 : | ||
/etc/init.d/mysql stop | /etc/init.d/mysql stop | ||
| − | rm /var/lib/mysql | + | rm /var/lib/mysql/galera.cache |
| − | rm /var/lib/mysql | + | rm /var/lib/mysql/grastate.dat |
/etc/init.d/mysql start | /etc/init.d/mysql start | ||
| Ligne 214 : | Ligne 214 : | ||
On a une base de mots de passe dans /var/local/sudopass/passwd.db | On a une base de mots de passe dans /var/local/sudopass/passwd.db | ||
| + | |||
| + | Le module pam ne permet pas encore de hashs forts, il fau generer le mot de passe de cette façon : | ||
| + | |||
| + | mkpasswd -m des | ||
| + | |||
| + | puis il faut ajouter dans le fichier avec cette commande : | ||
| + | |||
| + | |||
| + | { echo user; echo hash; } | db5.3_load -T -t hash /var/local/sudopass/passwd.db | ||
Version actuelle datée du 1 février 2022 à 14:48
Sommaire
Database Webcontrat[modifier]
La base de donnée utilisée est 10.5 + Galera Cluster
GaleraCluster permet de répliquer les 3 noeud en temps réel et permet aussi une configuration multimaster.
Pour accéder au cluster depuis la PROD, la REC et la FORM on tape sur le HAPROXY + keepalived (10.30.1.10) qui est constitué de 2 machine (10.30.1.11 et .12)
Les flux sont répartis par Round Robin vers les 2 nœuds principaux 10.30.1.101 et 10.30.1.102. Le nœud 3 sert de réserve, de serveur de backup et d’intégration pour l'eai. Cela permet de moins impacter la prod en cas de soucis, voir de déconnecter l’hôte en cas de grosse MAJ.
Phpmyadmin : https://dev.webcontrat.cnrs.fr/phpmyadmin/
Repartiteur de charge[modifier]
Un répartiteur de charge permet d’aiguiller le trafic vers les nœuds du cluster.
ip keepalived : 10.30.0.20
En mode nominal, via HA-Proxy1 :
En cas de problème sur HA-Proxy1 on bascule automatiquement vers le 2 (keepalived) :
Supervision[modifier]
Une machine de supervision permet d'avoir une vue d'ensemble sur le cluster
Login : voir Julien ou Alexis pour création d'un compte
cliquer sur "Galera-Prod"
Cela donne accès a l'ensemble du cluster
Pour avoir une vue plus fine sur chaque brique du cluster, cliquer sur Nodes
Cela permet de :
- voir la charge sur chaque nœud
- voir l'état des HaProxy, le primaire étant par défaut le 10.30.1.21
L'onglet Query monitor permet d'avoir une vue sur les requêtes, ou en tuer une en cas de boucle
L'onglet Performances donne une vue admin DB. Voir menu Health et Transaction log plus particulièrement
L'onglet Backup donne la main sur les sauvegardes gérées par clusterControl
Manage permet de configurer les serveurs depuis l'interface Web en modifiant / poussant les confs vers les briques du cluster
Alarms Permet de voir certaines alertes mais peu de détails (licence payante)
Redémarrage[modifier]
En cas de plantage complet du cluster, celui ci ne redémarre pas seul. Il faut de booter manuellement :
- ARRETER LE HAPROXY !
- ARRETER LE CLUSTERCONTROL
- Se connecter sur le nœud 1 (10.30.1.101)
- Démarrer avec la commande /etc/init.d/mysql start --wsrep-new-cluster
- Attendre le démarrage
- Se connecter sur les autres nœuds et redémarrer mysql normalement (/etc/init.d/mysql start)
- Vérifier les logs dans les 3 serveurs, une fois complètement synchronisés, redémarrer HaProxy
Il peut arriver que lors de la coupure les nœuds ne soient pas synchros. Dans ce cas il faut démarrer le cluster avec le ne oud le plus a jour. Pour cela il faut regarder les logs au démarrage, le cluster ne montera pas. Dans ce cas, arrêter tous les nœuds (/etc/init.d/mysql stop) et refaire la manip suivante en démarrant le nœuds 2 en premier. Si cela ne démarre pas non plus, refaire la manip avec le nœud 3 en 1er.
Logs[modifier]
sur chaque serveur, suivre les logs dans /var/log/mysql.log -> accès a toutes les données de réplication entre les noeuds + les erreurs
Problèmes connus[modifier]
En cas extrême si un nœud ne veux pas redémarrer et APRÈS avoir vérifier la cohésion des données, effacer les fichiers de cache pour forcer une synchro totale (SST)
/etc/init.d/mysql stop rm /var/lib/mysql/galera.cache rm /var/lib/mysql/grastate.dat /etc/init.d/mysql start
Restauration TiNa[modifier]
Attention, TiNa ne remplace automatiquement la base a restaurer. Il faut lancer la restauration et attendre la fin de la procedure.
Un fichier de dump mysql est envoyé dans /tmp.
Attention, le fichier ne crée pas la base, il faut la creer manuellement avant.
mysql -u user -p mysql> create database mydb; mysql> use mydb; mysql> source /tmp/mydb.sql;
Config SSL[modifier]
sur un des noeuds :
mkdir -p /etc/mysql/ssl cd /etc/mysql/ssl
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca-cert.pem
Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Herault Locality Name (eg, city) []:Montpellier Organization Name (eg, company) [Internet Widgits Pty Ltd]:CNRS Organizational Unit Name (eg, section) []:Webcontrat Common Name (e.g. server FQDN or YOUR name) []:Mariadb.localdomain Email Address []:dr13.ssi@cnrs.fr
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-key.pem -out server-req.pem idem sauf : Common Name (e.g. server FQDN or YOUR name) []:Mariadb
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem
openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem -out client-req.pem idem serveur
openssl rsa -in client-key.pem -out client-key.pem
openssl x509 -req -in client-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem
openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem server-cert.pem: OK client-cert.pem: OK
Copier le répertoire ssl sur chaque serveur
Changer les droits :
chown -R mysql:mysql /etc/mysql/ssl
Modifier le fichier my.cnf :
# MySQL Server [mysqld] ssl-ca=/etc/mysql/ssl/ca-cert.pem ssl-cert=/etc/mysql/ssl/server-cert.pem ssl-key=/etc/mysql/ssl/server-key.pem # MySQL Client [client] ssl-ca=/etc/mysql/ssl/ca-cert.pem ssl-cert=/etc/mysql/ssl/client-cert.pem ssl-key=/etc/mysql/ssl/client-key.pem
Redemarrer chaque nœud l'un après l'autre.
Cryptage IST : dans my.cnf :
wsrep_provider_options="gcache.size=128M; gmcast.segment=0; socket.ssl_key=/etc/mysql/ssl/server-key.pem; socket.ssl_cert=/etc/mysql/ssl/server-cert.pem; socket.ssl_ca=/etc/mysql/ssl/ca-cert.pem"
Il faut faire un bootstrap complet du serveur !
Cryptage SST :
MariaDB [(none)]> CREATE USER 'sstssl'@'localhost' IDENTIFIED BY 'oiwybolNes8crond9Blov'; Query OK, 0 rows affected (0.03 sec) MariaDB [(none)]> GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstssl'@'localhost' REQUIRE ssl; Query OK, 0 rows affected (0.02 sec) MariaDB [(none)]> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec)
dans my.cnf :
wsrep_sst_auth="sstssl:oiwybolNes8crond9Blov"
Mots de passe sudo[modifier]
Pour ne pas que clustercontrol se connecte en root et pour avoir 2 mots de passes differents, modificationdes serveurs sous son control :
# cat /etc/pam.d/sudo #%PAM-1.0 auth [success=1 default=ignore] pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd auth requisite pam_deny.so auth required pam_permit.so #@include common-auth @include common-account @include common-session-noninteractive
On a une base de mots de passe dans /var/local/sudopass/passwd.db
Le module pam ne permet pas encore de hashs forts, il fau generer le mot de passe de cette façon :
mkpasswd -m des
puis il faut ajouter dans le fichier avec cette commande :
{ echo user; echo hash; } | db5.3_load -T -t hash /var/local/sudopass/passwd.db
