Rechercher dans la communauté

Objectif : L'objet principal de ce tutoriel est la réplication d'une base de données entre deux nas Synology d'un réseau local. Cette réplication peut avoir diverses utilisations, dans ce tutoriel je l'ai appliquée à la redondance d’un site Wordpress. Préambule : Il existe de nombreux tutoriels sur le web concernant la réplication d'une base de données SQL ou MariaDB et celui-ci en est largement inspiré. En le mettant en place sur mes deux nas Synology je me suis heurté à plusieurs problèmes. Il m'a fallu combiner les informations de plusieurs sites avant d'obtenir le résultat voulu. Depuis plusieurs mois que cette réplication est fonctionnelle, j'ai pu évaluer sa résilience et je dois dire que je suis surpris du résultat. Que ce soit l'arrêt d'un des deux nas ou la modification ou la mise à jour d'un des sites la synchronisation des deux bases reste effective. J’ai même récemment écrasé la base de données en important, à l’aide de phpMyAdmin, une ancienne sauvegarde sur l’un des nas et celle-ci a été immédiatement répliquée sur le deuxième nas. Pour l’application à la mise en place d’une redondance d’un site Wordpress présent sur les deux Nas d’un même réseau, en plus de la réplication de la base de données Wordpress, il faut synchroniser bilatéralement le contenu du répertoire wp-content. EDIT du 9/1/2022 : Pour l'accès au site en redondance totale, il faut faire, sur les deux nas, un virtual host avec le même nom wordpress.ndd. (Avec dsm7, faire un portail de serveur du paquet wordpress). N'étant pas un professionnel de l'informatique, mon vocabulaire peut s'avérer inadapté et la méthode employée peut sans doute être simplifiée. N'hésitez pas en m'en faire part, je modifierai en conséquence. Prérequis : Deux nas présents sur le même réseau local. Sur l’un des nas (nas1), MariaDB10, phpMyAdmin et Wordpress ont été installés et un site Wordpress est fonctionnel et accessible de l’extérieur. EDIT du 9/1/2022 : avoir une sauvegarde du site (répertoire wordpress) y compris de la base de données wordpress. Personnellement j'utilise le plugin gratuit "Updraft plus". Sur le nas2 Webstation et les différentes versions de PHP et Apache sont installées. Putty et WinSCP installés sur un PC de réseau avec accès au deux nas en mode vrai root (voir tuto https://www.nas-forum.com/forum/topic/57289-tuto-acc%C3%A8s-ssh-et-root-via-dsm-6/). Pour que le nas2 puisse prendre le relais du nas1 en cas de défaillance de ce dernier, il faudra utiliser l'IPV6 et mettre en place le tuto suivant : Application du protocole IPV6. Accès redondant à votre réseau local Sans cela une intervention manuelle sera nécessaire afin de modifier la redirection des ports du routeur vers le nas2. Préparation du nas 2: Installer MariaDB10, phpMyAdmin et Wordpress sur le nas 2 Sur le bureau, cliquer sur MariaDB10, cocher la case « activer la connexion TCP/IP » et sélectionner le port 3306. Faire de même sur le Nas 1. Les pare-feux des deux nas doivent être réglés pour n’autoriser l’accès à ce port que depuis le réseau local. phpMyAdmin : après installation, si la base de données phpMyAdmin n’apparaît pas, vous devez avoir une notification dans la partie basse, il suffit de suivre les instructions pour créer la base. Pour la suite, il faut autoriser la connexion de phpMyAdmin entre nas. Pour cela utiliser WinSCP en root et éditer le fichier /volume1/web/phpMyAdmin/config.inc.php Nota : Pour dsm7 remplacer web par web_packages Et ajouter la ligne suivante après la ligne 35 : $cfg['AllowArbitraryServer'] = true; Profitez-en pour renseigner la clé $cfg['blowfish_secret'] =' ' en insérant 32 caractères entre les apostrophes si ce n’est pas déjà fait. Faire cette opération sur les deux nas. Synchronisation du dossier wp-content Dans mon cas j'ai synchronisé le répertoire volume1/web_packages/wordpress/wp-content du nas1 sous dsm7 avec le répertoire volume1/web/wordpress/wp-content du nas2 sous dsm6. Pour cela j'ai utilisé Cloud Sync(dsm7) avec WebDAV(dsm6). Si les deux Nas ont la même version du dsm, il y a plusieurs façons de faire une synchronisation bilatérale des dossiers wp-content. EDIT du 9/1/2022 : J'ai validé ce tuto avec deux nas sous DSM7. Pour la synchronisation du dossier web_packages/wordpress/wp-content j'ai utilisé "Synology Drive ShareSync". A la création de la synchronisation, bien paramétrer une synchronisation unidirectionnelle du nas1 vers le nas2, avec effacement des fichiers du nas2 non présents sur le nas1. Un fois la synchronisation terminée (coche verte : cela peut prendre du temps) rendre la synchronisation bidirectionnelle. Nous voilà prêts pour la réplication des BdD. Réplication des bases de données wordpress Master-Slave Pour cette réplication on trouve de nombreux tutoriels sur internet. Je me suis largement inspiré de celui-ci : http://www.responsive-mind.fr/replication-mysql-master-master/ Sur les deux nas accéder en root à phpMyAdmin. Dans l’accueil, onglet réplication vous devez avoir ceci : EDIT du 12/12/2023 dans une nouvelle version de PhpMyAdmin on a : Réplication de l'original et Réplication des répliques Nous allons donc commencer par faire une réplication nas1 (maître) vers nas2 (esclave). Sur le nas 1 cliquer dans réplication maître sur « configurer » Dans le menu déroulant sélectionner « Ignorer toutes les bases de données, répliquer : » et dessous sélectionner wordpress. Copier les 4 lignes à ajouter à la fin du fichier my.cnf…..sauf que ce fichier n’existe pas encore ! On crée donc un fichier texte que l’on renommera my.cnf une fois édité avec les 4 lignes sans oublier d’ajouter : [mysqld] en tête de fichier. Pour les étourdis (comme moi) : Lorsque l’on renomme le fichier ne pas oublier de prendre également l’extension txt, pour cela bien démasquer les extensions. Avec WinSCP en root placer ce fichier dans /var/packages/MariaDB10/etc/ où l’on trouvera : my_port.cnf et synology.cnf . Les trois fichiers doivent avoir les mêmes droits 0644 et appartenir au même propriétaire : root. A ce moment-là redémarrer MariaDB10 pour prise en compte : Dans putty en root sur le nas, lancer la commande : /usr/syno/bin/synopkg restart MariaDB10 On revient sur phpMyAdmin du nas 1, sélectionner la BdD wordpress (la structure apparait dans la fenêtre de droite) puis l’onglet SQL. Entrer la commande suivante : GRANT REPLICATION SLAVE ON *.* TO 'synchro'@'192.168.1.15' IDENTIFIED BY 'motdepasse'; synchro : utilisateur de replication vous êtes libre du nom. 192.168.1.15 : à adapter c’est l’IP locales du nas 2 Motdepasse : au choix (je vous avouerais que j’ai gardé le même pour tous les mots de passe de ce tuto) N’oubliez pas les apostrophes. Nous allons maintenant vider les caches des privilèges et des tables, tout en les verrouillant en lecture seule, à l’aide des commandes suivantes (re-cliquer sur SQL pour entrer la commande): FLUSH PRIVILEGES; FLUSH TABLES WITH READ LOCK; Laisser cette instance de phpMyAdmin ouverte et ouvrir une seconde instance La BdD wordpress étant sélectionnée sur cette nouvelle instance, aller dans l’onglet exportation et cliquer sur exécuter pour télécharger la BdD. Refermer cette instance. Revenir sur l’instance précédente De retour sur l’onglet SQL taper : SHOW MASTER STATUS; Nous obtenons ceci : On note la position (ici 185432) et le nom du fichier ( ici mysql-bin.000003) Sur phpMyAdmin du nas 2 créer une BdD wordpress (nouvelle base de données donner-lui le même nom wordpress puis créer). Sélectionner wordpress à gauche puis l’onglet Importer. Choisir le fichier qui vient d’être téléchargé wordpress.sql puis cliquer sur exécuter en bas. L’importation est assez longue. Wordpress étant toujours sélectionné, entrer les instructions suivantes dans l’onglet SQL : STOP slave; CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='synchro', MASTER_PASSWORD='motdepasse', MASTER_LOG_POS=185432, MASTER_LOG_FILE='mysql-bin.000003'; START slave; On revient sur phpMyAdmin du nas1, wordpress toujours sélectionné, déverrouiller les tables : UNLOCK TABLES; Il ne reste plus qu’à redémarrer MariaDB10 sur les deux nas ( /usr/syno/bin/synopkg restart MariaDB10 dans putty) puis à vérifier le résultat dans l’onglet réplication. Sur le nas 1(accueil, onglet réplication, afficher l’état du maître) : Sur le nas 2 (accueil, onglet réplication, afficher l’état du slave) : Remarquez la première ligne : « waiting for master to send event » ainsi que Yes en face de « Slave_IO_Running » et « Slave_SQL_Running » . Master_Log_File et Master_Position sont identiques au valeurs master du nas1. Si vous avez une erreur vous pouvez tenter de réparer à l’aide de l’instruction sous ce tableau : gestion des erreurs/ignorer l’erreur courante. Parfois ça marche 😉 sinon il faudra recommencer à FLUSH PRIVILEGES; FLUSH TABLES WITH READ LOCK; car vous avez probablement manqué quelque chose. Si vous avez n'avez pas d'erreur, la réplication du nas 1 vers le nas 2 est maintenant effective. Mais pour une parfaite redondance des sites il faut maintenant faire la même chose dans l’autre sens. Réplication Master-Master Nous allons commencer par créer le fichier my.cnf dans le nas2 de la même façon que pour le nas1. Puis on redémarre MariaDB10. Dans phpMyAdmin du nas 2, wordpress étant sélectionné entrer les instructions suivantes dans l’onglet SQL : GRANT REPLICATION SLAVE ON *.* TO 'synchro'@'192.168.1.10' IDENTIFIED BY 'motdepasse'; SHOW MASTER STATUS; Puis reporter les info file et position sur phpMyAdmin du nas 1: STOP slave; CHANGE MASTER TO MASTER_HOST='192.168.1.15', MASTER_USER='synchro', MASTER_PASSWORD='motdepasse', MASTER_LOG_POS=123456, MASTER_LOG_FILE='mysql-bin.789123'; START slave; Redémarrer le service MariaDB10 sur les deux nas et vérifier les informations obtenues dans phpMyAdmin onglet "réplication"/état du serveur slave de chaque nas : « waiting for master to send event » ainsi que Yes en face de « Slave_IO_Running » et « Slave_SQL_Running »: EDIT du 9/1/2022 : Idem, si vous avez une erreur vous pouvez tenter de réparer à l’aide de l’instruction sous ce tableau : gestion des erreurs/ignorer l’erreur courante. Voilà. Si tout à bien fonctionné toute modification sur l'un des sites sera reproduite sur le second. Si vous notez des erreurs ou des maladresses ou si vous réalisez d'autre applications de la réplication de bases de données n'hésitez pas à poster ici.

Ce tuto est l'objet d'une collaboration avec @dd5992 N'oubliez pas de le remercier si cela vous à plu 😉 Prérequis : · avoir 2 synos sur le réseau local · une box compatible IPV6 · Avoir son propre nom de domaine et être ns et soa de sa zone (voir Tuto de Fenrir DNS serveur). · Savoir utiliser le reverse proxy : (voir Tuto de Kawamashi ) · Avoir implémenté le tuto de Fenrir sur la sécurisation des accès. Notation : On notera « ndd » le nom de domaine principal utilisé (par exemple machin.fr) Idée directrice : But à atteindre : accéder en interne et en externe aux applications des synos ainsi qu’aux périphériques du réseau local avec une adresse xxx.ndd, même en cas de panne ou de déconnexion d’internet de l’un des deux synos (fonctionnement dégradé), tout ceci en n’utilisant que le port 443 (https), le port 80 pouvant être utilisé pour rediriger son traffic sur le port 443 ou pour un autre usage (par exemple être disponible pour le renouvellement du certificat Let’s Encrypt – en limitant l’accès dans le pare-feu). Bien entendu, en cas de fonctionnement dégradé il ne sera pas possible d’accéder, depuis l’extérieur, aux applications du syno déconnecté d’internet 😊. Lors d’une connexion à partir d’une adresse de type « xxx.ndd » un reverse-proxy est utilisé pour accéder à une application de l’un des synos ou à l’un des périphériques (imprimante, routeur, caméra, …). L’idée est d’implémenter un reverse-proxy dans chacun des deux synos, chacun étant accessible de l’extérieur avec la même adresse et donnant accès aux mêmes applications et périphériques du réseau local. La difficulté principale est de conserver la connexion depuis l’extérieur avec le réseau local lorsque le syno1 qui héberge la zone locale est déconnecté d’internet. Pour cela nous allons utiliser la recopie de la zone publique sur le DNS secondaire et transmettre par cette zone l’adresse IPV6 du syno2 comme ns publique IPV6. L’autre difficulté est d’utiliser les reverse-proxies sur 2 synos différents avec la contrainte de n’utiliser que le port 443, car en IPV4, il n’est possible de rediriger ce port que sur l’un d’eux. L’IPV6 nous permettra de résoudre cette difficulté tout en conservant le même niveau de sécurité. Réalisation : Fonctions IPV6 utilisées Règle générale : En IPV6, toutes les machines du réseau local qui sont compatibles avec ce protocole (routeurs, synos, PC, caméras, …) peuvent être accessibles depuis Internet grâce à leur adresse IPV6 publique, la seule condition est que IPV6 soit activé sur la box et sur chacune des machines à contacter. Pour notre tuto : Pour pouvoir contacter Syno2 en IPV6, il suffira d’activer l’IPV6 sur Syno2 et la box (si ce n’est déjà fait). On pourra garder la configuration du reste du réseau local tel qu’il était précédemment, c’est-à-dire en IPV4. En IPV6, la box se comporte comme un simple routeur (même en mode bridge) sans PAT (Port Address Translation), donc le flux IPV6 entrant sera directement routé vers l’équipement qui a la bonne adresse IPV6, sans configuration particulière. Les deux comportements IPV6 et IPV4 vont coexister, et en IPV4, le PAT utilisera les redirections de port de la box pour envoyer le flux IPV4 vers Syno1 sur le port d’entrée du reverse-proxy. Il faut donc enregistrer dans les DNS du domaine l’adresse IPV6 de Syno2 (par un enregistrement AAAA) et installer un reverse-proxy sur ce syno. L’ouverture du réseau local à IPV6 donnant accès de l’extérieur à tout équipement local, il conviendra de filtrer les accès. C’est ce qui sera abordé dans la section Sécurité,ci-après. Nom de domaine et DNS Point de départ : les prérequis ci-dessus. Syno1 : Dans la zone publique on ajoute (ou modifie) deux enregistrements AAAA : ndd AAAA IPV6syno2 adresse publique ns.ndd AAAA IPV6syno2 adresse publique Syno2 : Pour que le domaine ne soit pas bancal et qu’il réponde correctement au test https://zonemaster.net on crée une zone publique. Avec les enregistrements suivants : ndd NS ns.ndd ndd NS ns1.dnssecondaire ndd NS ns2.dnssecondaire (éventuellement) ndd AAAA IPV6syno2 adresse publique ns.ndd AAAA IPV6syno2 adresse publique Dans notre cas nous avions un enregistrement *.ndd CNAME ns.ndd et un certificat wildcard qui nous évite de nombreux enregistrements CNAME et la création du certificat correspondant. Il ne reste plus qu’a renseigner pour cette zone la règle de transfert de zone avec l’adresse IPV6 du DNS secondaire (IPV4 peut marcher aussi) et renseigner la notification des zones esclaves puis vérifier le zone master. Par rapport au résultat du test https://zonemaster.net/ avant réalisation de ce tuto, Il ne doit y avoir qu’un seul warning supplémentaire sans importance concernant les numéros de série des SOA qui sont différents (on peut d’ailleurs facilement corriger ceci). Edit : pour simplifier les mises à jour des zones, il est possible que les zones locales et publiques du syno1 soient transférées dans le syno2 par des zones slaves. Utilisation des reverse-proxies On complètera le reverse proxy du syno1 avec les applications du syno2 en employant des noms différents de celles du syno1 et une redirection vers : http://IP-locale-syno2:port de l’appli. Pour éviter de futures ambiguïtés on remplacera, dans les redirections des applications syno1, localhost par l’adresse locale du syno1. On fait, sur le syno2, un reverse proxy, avec les mêmes enregistrements. Cas particuliers : 1/ Les virtual hosts du syno1 ne sont pas affectés. Il n’a pas été fait de test sur d’éventuels virtual hosts du syno2. 2 / PhotoStation La commande suivante dans le .htaccess (en plus de l’éventuelle redirection du http en https si l’on utilise le port 80) : RewriteCond %{HTTP_HOST} ^photo.ndd$ RewriteRule ^$ https://photo.nddr/photo [L,R=301] peut être utilisée, dans les deux synos, en plus du reverse proxy. Il faut dans ce cas remplacer photo.ndd par photo2.ndd (par exemple) pour le syno2 3/ SurveillanceStation Le reverse proxy réalisé de manière identique aux autres applications n’est pas suffisant pour visualiser les flux vidéo des caméras (bug connu), Il faudra utiliser l’application client. Il est possible d’utiliser le même nom pour les applications des deux synos , dans ce cas, si l’on paramètre SurveillanceStation de manière identique, on obtient une redondance sur la vue obtenue. Seuls les enregistrements réalisés seront différents d’un syno à l’autre. Avec les synos1 et 2 (ou uniquement syno1) opérationnels, on se connecte à l’aide de l’application client à SurveillanceStation du syno1. Si le syno1 est down l’image se gèle et en rafraichissant l’application client, elle se connecte sur SurveillanceStation du Syno2. Sécurité : Pare-feu IPV6 Comme on l’a vu précédemment, l’ouverture du réseau local à IPV6 impose de protéger les équipements locaux contre les accès indésirables provenant de l’extérieur. Dans l’exemple de ce tuto, il s’agit de tous les accès sur toutes les machines locales, à l’exception des ports 443 (et éventuellement 80) de Syno2. Donc pour Syno2 il faudra activer le pare-feu en n’autorisant pour le traffic IPV6 entrant que les ports 443 et/ou 80 et en restreignant plus si besoin. On peut ajouter d’autres filtres, par exemple restreindre en plus l’accès en provenance de certaines zones géographiques. Pour interdire l’accès IPV6 vers les autres machines, plusieurs possibilités : · Ne pas activer IPV6 sur une machine permet d’interdire tout accès IPV6 à cette machine. C’est possible sur les synos (Panneau de configuration/Réseau/Interface réseau/LAN/Modifier/IPV6/Configuration d’IPV6:Desactivé), les machines (PC ou serveurs) sous Windows (voir ici) et sur certains autres équipements. · Utiliser un pare feu local à chaque machine (solution idéale sur syno - ici, existe sur Windows). A utiliser pour syno1. · La troisième solution est plus radicale, mais nécessite un équipement spécifique : Installer un pare-feu en entrée du réseau local (par exemple dans un routeur en aval de la box en mode bridge) (voir la configuration ici), en ne laissant passer que les accès vers le port 443 (et 80 si besoin) de Syno2 (on peut là aussi ajouter d’autres filtres, par exemple restreindre l’accès pour certaines zones géographiques). Note : Lors de nos tests, nous avons également essayé d’utiliser le nouveau pare-feu IPV6 de notre box (une freebox révolution). Ce pare-feu (comme la plupart des pare-feux IPV6 des box n’est pas configurable et en l’activant, nous avons perdu l’accès à Syno2 de l’extérieur. Donc pour appliquer ce tuto, il faut désactiver le pare-feu IPV6 de la box. Résultats En cas de panne du syno1 : périphériques, DSM et applications du syno2 resterons accessibles du réseau local et de l’extérieur tant que l’enregistrement IPV6 du syno2 en tant que serveur de nom restera propagé. A priori tant qu’un changement n’aura pas été transmis dans le DNS secondaire par la zone publique du DNS syno1. Si les syno1 et 2 sont opérationnels tous les périphériques, DSM et applications sont accessibles (sauf DSM et applications syno2 si celui-ci est en panne, bien sûr) Restrictions · En cas de panne de la box, plus aucun accès · La redondance n'est disponible que pour les clients externes qui ont une connectivité IPV6 (fonctionnement non redondant en IPV4) Schémas illustrant le fonctionnement