L’un des problèmes récurrents des architectures mutualisés (ou non) utilisant du MySQL est la disponibilité mais aussi la performance de ce dernier. Quelques habitudes existent, chacun avec leurs lots d’avantages et inconvénients. Je vais tenter de vous proposer une mise en oeuvre qui me semble être un bon compromis entre les différents points à prendre en compte : haute disponibilité, performance, type de table MySQL géré, compétences en interne, coût, facilité de déploiement.

MySQL en haute disponibilité

MySQL, beaucoup le critique à tord ou à raison. Le premier à le faire ? Michael Widenius, fondateur de MySQL qui s’affirme avec MariaDB. De manière générale, on notera certaines fonctionnalités (voire performances) en retrait par rapport à d’autres moteurs, que cela soit PostgreSQL, Oracle ou MSSQL. Reste que ces derniers sont cher à mettre en oeuvre et que PostgreSQL nécessite une compétence qui est bien trop rare dans nos contrées. De fait, MySQL reste quelque part une valeur sûre si l’on prend le temps de travailler correctement avec : définir une bonne architecture, le superviser et l’optimiser au fil du temps.

Quand on parle de haute disponibilité, je balaie d’office le fonctionnement basique maître-esclave disponible nativement. En effet, il n’apporte aucune haute disponibilité et le bricolage nécessaire pour inverser les rôles n’est tout bonnement pas industrialisable et encore moins réaliste. Que reste-t-il alors comme solution ?

• MySQL Cluster
  • solution opensource mais un support de la part d’Oracle est conseillé
  • avantage(s) : supporté par l’éditeur (Oracle) ; performance
  • inconvénient(s) : un seul type de moteur de table (NDB)
• Percona XtraDB
  • solution opensource qui dispose d’un support mais où l’on peut se débrouiller ; il s’agit d’une version lourdement mise à jour de MySQL (utilise la librairie Galera)
  • avantage(s) : support de l’éditeur (Percona) ; extension du moteur InnoDB (renommé XtraDB) ; synchro temps réel
  • inconvénients : principalement au niveau des LOCK (mais il y a une solution embarquée pour cela) ; que InnoDB pour le moment ; les statements DDL sont encore problématiques (mais en cours de correction)
• Multi Master Replication
  • solution opensource qui repose sur un abus d’utilisation d’une fonction de mysql (une instance peut être à la fois maître et esclave)
  • avantage(s) : natif à MySQL ; tous les formats de table de MySQL (MyISAM, InnoDB, …)
  • inconvénients : peu stable sur le long terme – lié au fonctionnement en boucle, nécessite du bricolage et l’implémentation d’outils tiers (par ex, MMM)

InnoDB étant plutôt conseillé et apprécié par rapport à MyISAM, j’ai choisi la solution de Perconna. En effet, elle me semble sur le papier très industrialisable avec des inconvénients que l’on peut facilement contourner ou qui vont venir à disparaître.

Percona XtraDB Cluster en pratique

L’environnement utilisé est un environnement de type Prod + PRA. Le principe s’applique facilement dans les autres environnements (Prod + PCA, Prod seule, …). Il faut juste noter un impératif de PXC : il faut minimum trois noeuds.

L’intérêt dans l’architecture est multiple :

• tous les noeuds communiquent ensemble
• on voudra séparer les flux “lecture/écriture” des flux “lecture seule”

Dans ce mode, on va dispatcher des VIP par site :

• PRDVIPRO – lecture seule PRD : 192.168.2.5
• PRDVIPRW – lecture/écriture PRD : 192.168.2.6
• PRAVIPRO – lecture seule PRA : 192.168.12.5
• PRAVIPRW – lecture/écriture PRA : 192.168.12.6

Ainsi, on va isoler les utilisateurs sur les différentes VIP. On pourra définir des super-alias qui pointent sur un site ou l’autre en fonction des besoins et disponibilités. Pour répondre à ces VIP, on supposera les machines suivantes :

• PRDMYSQL01 : 192.168.1.1/24 (management) + 192.168.2.1/24 (métier)
• PRDMYSQL02 : 192.168.1.2/24 (management) + 192.168.2.1/24 (métier)
• PRAMYSQL01 : 192.168.11.1/24 (management) + 192.168.12.1/24 (métier)
• PRAMYSQL02 : 192.168.11.2/24 (management) + 192.168.12.2/24 (métier)

La séparation des droits (RO/RW) ne se fera pas au niveau des rôles des noeuds (côté MySQL) mais au niveau de l’assignation des VIP et définitions des comptes utilisateurs. Il faut donc être attentif de ce côté.

Installation de Percona XtraDB Cluster

On commence par déployer tous les packages nécessaires

gpg --keyserver  hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
gpg -a --export CD2EFD2A | sudo apt-key add -
echo << EOF >> /etc/apt/sources.list
deb http://repo.percona.com/apt squeeze main
deb-src http://repo.percona.com/apt squeeze main
EOF
apt-get update
apt-get install libnet-daemon-perl libplrpc-perl libdbi-perl libaio1 libmysqlclient18 percona-xtradb-cluster-server-5.5 percona-xtradb-cluster-client-5.5 percona-xtradb-cluster-common-5.5 percona-xtrabackup xtrabackup netcat-openbsd rsync

On continue par la configuration du mysql. La configuration est une base pour un serveur avec 8 Go Ram et 4 coeurs. A faire évoluer donc.

echo << EOF > /etc/mysql/my.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
server_id=1
wsrep_node_name=prdmysql01
auto_increment_offset = 4
auto_increment_increment = 4
wsrep_provider=/usr/lib64/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.2.2,192.168.12.1,192.168.12.2
#wsrep_cluster_address=gcomm://
wsrep_slave_threads=16
wsrep_sst_method=xtrabackup
wsrep_cluster_name=pxc
wsrep_sst_auth=root:secret
wsrep_sst_receive_address=192.168.2.1:4444
wsrep_provider_options ="gmcast.listen_addr=tcp://192.168.2.1:4567; ist.recv_addr=192.168.2.1:4568;"
binlog_format=ROW
log_bin=mysql-bin
log_slave_updates
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
innodb_buffer_pool_size=400M
innodb_log_file_size=64M
innodb_data_file_path = ibdata1:10M:autoextend:max:128M
performance_schema
key_buffer = 1M
max_allowed_packet = 4M
table_cache = 64K
query_cache_limit = 64M
sort_buffer_size = 2M
net_buffer_length = 64K
read_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
low_priority_updates = 1
old_passwords = 0
max_connections = 200
max_user_connections = 100
join_buffer_size = 256K
long_query_time = 2
slow-query_log_file = /var/log/mysql/mysql.slow.log
thread_cache_size = 5
query_cache_size = 0
query_cache_type = 1
tmp_table_size = 128M
max_heap_table_size = 128M
concurrent_insert = 2
delay_key_write = all
wait_timeout = 30
interactive_timeout = 30
key_buffer_size = 2G 
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
bind-address = 0.0.0.0
myisam-recover = BACKUP
expire_logs_days = 10
max_binlog_size = 100M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
EOF
chmod 600 /etc/mysql/my.cnf

Les lignes en gras sont à adapter pour chaque serveur :

• un server-id unique à chaque fois
• l’IP métier du serveur abstente du cluster-adress
• le mot de passe root mysql

ATTENTION : ne pas utiliser le même mot de passe root en mysql et sur le système

Une fois le premier serveur mis en place, on arrête le mysql (via service ou init) sur TOUS les serveurs. Ensuite, on duplique le fichier /etc/mysql/debian.cnf et tout le contenu de /var/lib/mysql du premier vers les trois autres.

Une petite subtilité existe sur la version Debian/Ubuntu du package Percona. Au démarrage du premier node d’un cluster (au sens que tout le cluster est arrêté), il faut éditer le fichier my.cnf pour commenter la ligne

wsrep_cluster_address=gcomm://IP,IP,IP

et décommenter la ligne

wsrep_cluster_address=gcomm://

Ensuite, on peut démarrer simplement le service sur la machine puis remodifier le fichier my.cnf. C’est rébarbatif, mais il faut le savoir. Après, on n’aura à le refaire qu’en cas de relance complète depuis zéro du cluster.

Ensuite, on va déployer quelques modifications sur les droits MySQL :

mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.2.%' IDENTIFIED BY 'secret';
mysql> CREATE USER 'perconha'@'localhost' IDENTIFIED BY 'secret';
mysql> FLUSH PRIVILEGES;

Ceci permettra aux différents nodes de communiquer pour la synchro et de disposer d’un user perconha qui n’a accès qu’en consultation aux variables applicatives de MySQL.

Nous n’avons plus qu’à démarrer les différents noeuds MySQL. Sur les versions Debian/Ubuntu, le premier démarrage pourra se faire en erreur. En effet, le script d’init considère que le serveur ne démarre pas car le binaire lui renvoie une erreur. En fait d’erreur, il s’agit juste d’un retour qui signale que le serveur est désynchro. On lui laisse le temps de bien démarrer (on peut consulter syslog pour cela) puis, à volonté, redémarrer le service une dernière fois.

Le cluster est maintenant installé.

VIP & Monitoring

Pour répondre au besoin de la gestion d’une VIP sans outil tiers ou de load balancer, ainsi qu’au monitoring complémentaire de PXC, j’ai mis à disposition des scripts sur mon github.

Le script pour Nagios est relativement simple à utiliser :

usage: ./check_percona -H $HOSTADDRESS$ -p $PORT$ -w $ARG1$ -c $ARG2$ -t $ARG3$ \\(-U $ARG4$ \\(-P $ARG5$\\)\\)
-H hostname or IP
-p service port
-w warning in seconds for replication delay
-c critical in seconds for replication delay
-t timeout for command input
-U user if needed
-P password if needed

Il ne nécessite que la création d’un compte (comme le compte perconha) pour permettre à Nagios de s’y connecter. Attention, il vient en complément du check_mysql disponible de base.

Concernant la VIP, le script va vérifier l’état d’un noeud dans le cluster (mysql disponible, intégré au cluster, synchro avec le cluster) pour assigner les VIP à la machine. Les VIP sont séparés niveau logique entre une pour l’écriture et l’autre pour la lecture. Pour définir le “rôle” d’un noeud, il suffit de créer des fichiers vide “RO” (lecture seule) ou “RW” (lecture/écriture) dans le dossier /etc/perconHa/. une fois placé en cron, le script fera le reste.

Il vérifie bien évidemment qu’une IP n’est pas déjà utilisée avant de l’assigner. Notez qu’il faut éditer le fichier pour y définir les informations relatives à la connexion à MySQL, les VIP ainsi que l’interface métier.

Conclusion

On a donc pu créer rapidement un cluster MySQL autonome, avec une haute disponibilité, une performance certaine mais liée au fine tuning du MySQL (qui se fait tout au long de la vie du cluster) et souple. La base présentée est simple, viable mais reste une base. La partie VIP par exemple serait mieux gérer via un load balancer qui serait plus réactif que la cron. Mais on peut réutiliser le script pour se faire. De la même manière, on pourrait superviser de manière plus fine la consommation en ressource du cluster.

The post Création d’un cluster MySQL haute disponibilité appeared first on D'ici et d'ailleurs.

Original post of Francois Aichelbaum.Votez pour ce billet sur Planet Libre.

Je sais, vous allez me dire que SVN est vieillot et que de toute façon, en bon geek qui se respecte, ça fait longtemps que vous êtes passé sous git.

Mais voilà, si vous n'êtes pas encore complètement convaincu que SVN n'est pas une solution si mauvaise que ça et que vous utilisez ça chez votre client/employeur, j'ai quelques astuces pour vous.

Tout d'abord, les hooks sont présent dans le répertoire hooks de votre repository. De base, votre repository SVN, à sa création, vient avec un template pour toutes les opérations de hooks possible sous SVN. Ça se présente sous la forme suivante :


ls *.tmpl
post-commit.tmpl
post-unlock.tmpl
pre-revprop-change.tmpl
post-lock.tmpl
pre-commit.tmpl
pre-unlock.tmpl
post-revprop-change.tmpl
pre-lock.tmpl
start-commit.tmpl

Comme vous pouvez le constater, toutes les opérations possible et imaginable sont disponible. Personnellement, j'ai eu l'occasion d'en mettre deux en oeuvre :

• pre-revprop-change : lancé avant une modification sur une révision ;
• post-commit : lancé au moment de la fin d'un commit.

Ces hooks vont servir à changer/régler le comportement de votre repository à l'aide de script. Pour les mettre en place, rien de plus simple :

• Faîtes un script dans le langage qui vous amuse (même si j'aurais tendance à privilégier un script shell Unix tout simple) ;
• Copier/lier ce script dans le répertoire du hooks en respectant le nom de l'opération à laquelle vous voulez le lier.

Exemple de hooks SVN : pre-revprop-change

Prenons le cas du pre-revprop-change. Ce script est lancé pour vérifier que l'opération de modification d'une révision de votre repository est bien autorisé. Je sais, vous aller me dire que ce type de demande vous parez étrange. Mais comme chacun sait, le client est roi et à coeur vaillant, rien d'impossible !

Dans le cas présent, nous allons justement restreindre cette opération à la modification du message de log de votre révision. Nous allons également interdire que cette modification puisse se faire par un autre utilisateur que celui à l'origine de la modification.

Sans plus attendre, voici donc le fameux script en charge de cette modification :

#!/bin/bash
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ] && \\
   [ `svnlook author -r "$REV" "$REPOS"` = "$USER" ]; then
  exit 0
fi

echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1

Couplage avec Jenkins à l'aide d'un événement de post-commit

Original post of Yannig.Votez pour ce billet sur Planet Libre.

• On apprenait il y a quelques jours qu'une nouvelle saveur était officiellement rentrée dans les rangs, avec Kubuntu et les autres : GNOME Ubuntu.

• On apprenait aussi que Ubuntu prenait Wayland pour un boulet et prévoyait de basculer sous Mir, son propre jouet.

• On apprend aussi que l'équipe de développement de GNOME va peser de tout son poids sur le développement de Wayland. C'est encore en l'état de proposition, mais il n'y a pas de doute : entre Wayland et Mir, Wayland vaincra.

• Et je ne parle pas de la gueulante des mainteneurs de Kubuntu

Donc, si on comprend bien. Canonical accueille GNOME les bras ouverts, du moins en saveur. Ce n'est pas rien. C'est une reconnaissance officielle qui consacre l'importance d'une version GNOME de Ubuntu, sans Unity.

Après, GNOME décide clairement de mettre Wayland dans les starting-blocks pour mars 2014. Ils vont faire passer le support de Wayland au premier plan tout en gardant une compatibilité avec X11 via xwayland.

Là dedans, Canonical va tout faire pour passer à Mir en lieu et place de Wayland. Mir et Unity seront donc la combinaison ultime pour pleinement profiter de Ubuntu Canonical et... mais comment va faire GNOME Ubuntu ?

Même si l'équipe de GNOME affirme qu'il va rester compatible avec X11, quid de la pérennité du plan à trois GNOME/X11/Ubuntu ?

Canonical, dans sa logique, ne devrait plus trop s'attarder sur X11. Ils n'y auront plus intérêt et sans doute pas les moyens. Va-t-on voir apparaitre des saveurs d'Ubuntu non plus basées sur des environnements graphiques mais sur les serveurs graphiques ? Ça me paraitrait un peu dingue.

Bref, je comprends pas comment ça va bien pouvoir se passer. Ça sent vraiment l'implosion des communautés non alignées sur les nouvelles directives de Canonical.

Original post of dada.Votez pour ce billet sur Planet Libre.

Contexte

Lorsque l'on manipule des serveurs sous GNU/Linux, on utilise de manière quasiment exclusive nos si chères et si pratiques/efficaces/magiques commandes en utilisant très souvent le Secure Shell aussi appelé : SSH !

J'ai un serveur qui héberge ce blog entre autre et un NAS chez moi afin d'y entreposer ces indispensables sauvegardes ! Quoi de mieux que de passer par un script pour effectuer les différentes opérations ! Voilà que notre script peut très rapidement avoir besoin de copier un certains nombre de fichiers vers ce NAS via la commande scp par exemple. Tout ceci est parfait mais comment ne pas devoir entrer son mot de passe ou le stocker en clair à l'aide d'une quelconque bidouille ou commande bizarres ? Utiliser un système d'authentification proposé par ce formidable outil !

Prérequis

Tout d'abord vérifions coté serveur que nous disposons bien des paquets nécéssaires et l'autorisation d'authentification par clé RSA :

# yum install openssh-server openssh-client openssh

$ grep RSA /etc/sshd_config RSAAuthentication yes

Que notre serveur SSH est lancé et se lance au démarrage du serveur ( ;) ):

# /etc/init.d/sshd status ou # service sshd status

# chkconfig sshd on

S'il n'est pas démarré, un simple # service sshd start doit suffire !

Fonctionnement

Un schéma vaut mieux qu'une explication :

Source : http://geekfault.org - license Creative Commons

Génération d'une clé RSA ou DSA

Une fois ce qu'il faut d'activé et de configuré côté serveur, nous nous rendons sur le client. C'est sur cette machine que nous ne voulons plus rentrer ce mot de passe si long et compliqué :)

Rendez vous dans votre home de l'utilisateur qui voudra se connecter au serveur SSH sans donner de mot de passe mais en utilisant ce système d'authentification.

$ cd

$ ssh-keygen -t rsa

Generating public/private dsa key pair. Enter file in which to save the key (/home/monuser/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/monuser/.ssh/id_rsa. Your public key has been saved in /home/monuser/.ssh/id_rsa.pub. The key fingerprint is: 8f:80:d8:c5:3d:9s:0b:10:66:42:9c:84:45:a1:d0:14 monuser@monserveur

Nos clés se trouvent en théorie dans /home/monuser/.ssh/ avec comme nom id_rsa et id_rsa.pub.

Retenez bien la passphrase renseignée car elle nous servira encore ! Elle sert de base à l’algorithme de génération de la clé privée, donc plus elle est compliquée en combinant des chiffres/lettres/ponctuations majuscules/minuscules, mieux c'est !

Sécurisation de la clé privée

Nous allons mettre la clé privée en lecture seule pour le propriétaire de la clé et aucun droit pour les autres utilisateurs :

$ chmod 400 ~/.ssh/id_rsa

Modifier la passphrase

$ chmod u+w ~/.ssh/id_rsa
$ ssh-keygen -p -f ~/.ssh/id_rsa
$ chmod u-w ~/.ssh/id_rsa

Exporter la clé publique

Comme vu ci-dessus, 2 clés ont été générées ; une privée que l'on ne communique pas et une publique que l'on va transférer sur le serveur SSH :

$ cat .ssh/id_dsa.pub | ssh monuser@monserveur \\ "cat - >>~/.ssh/authorized_keys"

Votre mot de passe est demandée, normal, vous effectuez l'opération et ensuite on teste en listant le contenu du répertoire home de monuser :

$ ssh monuser@monserveur ls

Là il nous demande la passphrase et affiche le résultat de la commande ls ! Plus de mot de passe ! ... mais une passphrase ... :(

Automatiser le stockage de la clé privée (passphrase)

Démarrer l'agent

Pour cela nous allons utiliser un agent SSH, c'est lui qui va s'occuper de stocker en mémoire la clé privée :

Pour cela nous allons le démarrer et le rattacher au shell courant :

$ ssh-agent /bin/bash

Ajouter une clé

Nous fournissons notre clé privée à l'agent via un simple :

$ ssh-add

Qui nous demande une dernière fois la passphrase et le tour est joué !

Vérifions :

$ ssh monuser@monserveur ls

Nous obtenons le résultat de la commande ls sans avoir rentré quoique ce soit !

Supprimer une clé

$ ssh-add -d ~/.ssh/id_rsa

Original post of Slobberbone.Votez pour ce billet sur Planet Libre.

Après la conversion d’un blog WordPress, vous pouvez maintenant convertir votre site SPIP en un site PluXml.

Pour le moment, seuls les articles sont récupérés, mais à terme, bien évidemment catégories, commentaires et médias seront de la fête.

C’est assez expérimental pour l’instant mais en local, avec un export fait par un SPIP 2.1.10, ça fonctionne.

Si vous voulez tester, il faut télécharger la version de dev sur github.

Si vous trouvez un bug, c’est également sur github que ça se passe.

Et bien évidemment, le projet sera à suivre sur le site prévu à cet effet.

(à propos, le projet a basculé sous licence WTFPL)

Original post of Nicolas Lœuillet.Votez pour ce billet sur Planet Libre.