DEDIBOX-NEWS.COM

JalaL · 2006-08-13 01:09:08

Bonjour a tous,

J'envisage de prendre une nouvelle box pour la dedier a une grosse base de données (moteur de recherche) et je voudrais savoir quelques details.

Comment securiser le transfert de données entre le serveur web et le serveur mysql qui seront separés physiquement ?

J'ai pu comprendre qu'il faut utiliser des tunels ssh, des vpn... mais je n'ai rien trouvé de concret, pour un initié comme moi ca serait sympas d'expliquer comment faire, je cite : "un simple tunel ssh"

La fonction mysql_connect() de php permet etablir une connexion mysql securisée (openssl) pour securiser les données et que l'on peut aussi compresser les données pour gagner du temps... est ce que cela suffit pour securiser les données (sans parler du serveur lui meme)

J'ai été chez OVH en mutualisé et le serveur mysql etait independant du serveur web, et tout allait bien... normalement il n'y aura pas de probleme coté rapidité des transferts, la seule chose qui m'inquite c'est la securité des données (login/passwd surtout)

Toute aide est la bienvenue

Calimero · 2006-08-13 01:23:46

Si tu optes pour le SSL, tu dois pouvoir te contenter d'une recompilation de MySQL (sous Debian en tout cas, le mysql packagé n'est pas "SSL-ready"). Faudra évidemment utiliser une connexion SSL côté client. Tu peux aussi imposer les connexions SSL pour certains comptes (typiquement les comptes qui accèderont de l'extérieur). En ajoutant quelques règles iptables, ca doit être honnête comme setup.

Une autre solution est de travailler un peu plus bas, en montant un VPN. Je te conseille de matter openvpn, qui est complètement en user space et qui est très facile à mettre en place. La howto est d'ailleurs assez exhaustive. Dans ce cas là, il suffit de faire sauter le "bind-address = 127.0.0.1" dans la conf mysql, pour qu'il puisse se binder à l'interface VPN. Adapter tes règles iptables en conséquence et banzaï.

A mon sens le tunnel SSH est une option pour du dev ou de la maintenance ponctuelle, mais pour une utilisation "24x7", je pense qu'il vaut mieux monter un VPN qui fera le restart en cas de perte de connexion (openvpn est impressionnant sur ce point), etc...

Guillaume · 2006-08-13 08:30:57

Idem, j'opetrai pour le VPN si je devais utiliser 2 box.

JalaL · 2006-08-14 00:30:41

Je sais pas si je comprend bien le principe du VPN, il y a private network dedans, ce qui veut dire que j'aurai deux adresse IP privées (du genre 192.168.0.x par exemple) sur les deux box... je pourrais donc acceder aux serveur mysql dedié (la 2eme box) grace a une adresse ip privée et une clé de cryptage privée identique sur les deux box...

Je suppose qu'il faudra que j'installe le serveur vpn sur la 2eme box, celle que je souhaite acceder a distance ou bien peu importe qui est serveur et qui est client ?

Calimero · 2006-08-14 00:50:12

En fait, tu vas faire un réseau virtuel en utilisant un réseau "physique". Tu fais de l'encapsulation. Selon le type de VPN tu vas pouvoir travailler au layer 2: utiliser des protocoles non-IP (IPX/SPX...) entre les deux machines, faire passer les broadcasts... ou travailler au layer 3, en IP. Dans la majorité des cas (et celui qui nous intéresse ici), travailler au niveau IP est plus efficace et plus simple à mettre en place.

Bref, techniquement, tu vas avoir une machine qui va faire serveur et l'autre client. Le client se connecte au serveur, s'authentifie (avec openvpn c'est via des certificats que tu auras générés au préalable), négocie les params du VPN et finalement monte l'interface sur la virtuelle.

Sur le client, tu auras alors une interface virtuelle (ici openvpn en mode routing/layer3):

Code:

node02:~# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.42.0.41  P-t-P:10.42.0.42  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1428 (1.3 KiB)  TX bytes:1428 (1.3 KiB)

ainsi que la route nécessaire pour que les paquets à destination du serveur, via VPN, passent bien dans le tunnel.

Le serveur aura aussi une interface virtuelle avec les routes kivonbien.

Ensuite, tu peux alors te connecter au mysql d'en face:
$ mysql -u toto -h 10.42.0.1 -p ...

Peu importe qui est client ou serveur, tu décides qui fait quoi et basta.

JalaL · 2006-08-14 17:01:41

Merci pour les infos, là je vois un peu plus clair ce que c'est... je vais tester tout ca.

Puisqu'on parle toujours de separation mysql/apache, surtout pour augmenter les performances mysql... je pensais qu'une replication maitre/esclave entre les deux box pourrait augmenter les performances de l'ensemble (pour ne pas dire cluster)... Il y aurait beaucoup moins d'ecriture dans la base de données que de lecture. Dans ce cas toutes les ecritures dans la BdD seront a la charge du maitre (et seront repliquées par l'esclave) et tout ou une grande partie des lectures seront deleguées à l'esclave.

Dans ce cas le serveur apache sera aussi mysql maitre, et l'esclave mysql sera sur la 2eme box.

Vous en pensez quoi ? est ce qu'il y a interet a faire de la replication avec une telle configuration ? si ce n'est que pour avoir un serveur de secours sans aucun gain de performance par rapport à un seul serveur apache/mysql !

Guillaume · 2006-08-14 17:30:42

Je te conseillerai déjà de mettre en place ta solution sur un serveur unique avant de te lancer dans du clustering.

Après, si ton site génère bcp de requêtes et de visites tu pourrais mettre 2 dédibox apache+mysql slave en frontal et avoir ton mysql maitre par derrière (sur le même principe que celui dont tu parle, les esclaves répliquent les données du maitre). Mais là je part dans des délires qui sont sans doute injustifiés pour le moment (Mais qui sait? ).

En faisant comme tu l'indique, tu mettrais ton crawler sur le mysql maitre?

Dernière modification par Guillaume (2006-08-14 17:31:33)

JalaL · 2006-08-14 18:26:05

Je suis en train d'etudier une solution clustering economique, deja si j'arrive a mettre mysql sur un serveur independant c'est deja une augmentation de performances en soi... je ne vais pas prendre une 2eme box dès demain...

Le crawler doit fonctionner chez moi, j'ai toujour mon vieux serveur que j'utilise pour le developpement.

Je vais faire une liaison maitre esclave entre mon serveur à la maison et la 1ere box, la 1ere box doit repliquer ma base de données à la maison qui sera alimentée par le crawler. C'est plus pratique, au lieu de faire un dump mysql de quelques Go, l'uploader, et l'importer dans la 1ere box avec une interruption de service pendant l'importation du dump. Ca me fera gagner des heures. Sinon j'utiliserai le maitre directement.

J'ai lu plein de tutoriaux sur le sujet : "prenez deux serveur apache en frontal, un serveur mysql maitre, et deux serveurs mysql esclaves, melangez le tout et mettez au four chauffé à 180° pendant 15 minutes" comme si s'etait une recette de cuisine... il doit certainement y avoir des solutions plus economiques, efficaces et extensibles en meme temps.

Calimero · 2006-08-14 19:32:17

Avant de se lancer dans de gros plans d'optimisation, faut voir le comportement de ton application. Si effectivement c'est mysql le point faible (genre tu fais un max de choses dans tes requêtes SQL), on peut imaginer un setup du genre:

dedibox 1: serveur web + mysql master (utilisé pour les écritures et une partie de la lecture)
dedibox 1: mysql slave (que de la lecture)

Dans ton code, pour les actions en lecture tu tires un des deux serveurs au hasard (avec une pondération + forte pour le slave). Pour les écritures, tout sur le master.

Si tu veux garder ton crawler à la maison, on peut imaginer ca:
maison : crawler + mysql master
dedibox 1 : apache + mysql slave
dedibox 2 : apache + mysql slave
+ round robin DNS à TTL pas trop haut (pour lourder un des deux serveurs s'il meurt)

L'avantage, c'est que chaque dedibox est indépendante et ton application n'a pas à faire la distinction entre les actions en lecture/écriture.
==> chaque apache travaille sur son mysql à lui sans ce soucier de l'autre.

Est-ce que tu maintiens des sessions PHP (genre pour stocker des paramètres en langues, ...) ?

JalaL · 2006-08-14 19:51:12

C'est exactement je ce pensais a l'instant. Pour l'ecriture j'utilise le maitre, et je tire un nombre au hasard entre 0 et 100, si le nombre est < 10 je lis sur le maitre, sinon je lis sur l'esclave. Comme ca seulement 10% des lectures se passeront sur le maitre.

La deuxieme solution est une tres bonne idée, dans tous les cas si le crawler + maitre est hors ligne (ce qui est souvent le cas) les deux esclaves seront a jour et pourront lire les données sur place, je peux eventuellement transformer l'un d'eux en maitre pour enregistrer toutes les insert/update... mais elle sera tres dure a implementer

Pour le moment je reste sur la 1ere solution, et si jamais je devrais passer à la 2eme solution je prendrai une 3eme box plutot que mon home server

JalaL · 2006-08-15 17:00:58

Je pense qu'il y a une solution meilleure. Faire une replication croisée sur les deux box et du round robin dns pour basculer entre les deux. Les sessions sont stockées dans la BdD et dans un cookie, donc je n'aurai pas de souci avec les sessions. Seul probleme c'est les logs apache (stats) qui seront separés sur les deux box, dans ce cas il faudra prevoir un stockage commun pour les logs apache dans l'une des deux box ou (mieux) un script qui fusionne les deux logs avant le calcul des stats => toujours besoin d'un tunel vpn pour l'authentification...

Il y a aussi le probleme des auto_increment simultanés sur les deux box qui peut etre resolu tres facilement
>> http://www.onlamp.com/pub/a/onlamp/2006 … ation.html

A part ça, ca va etre difficile d'avoir une defaillance

Calimero · 2006-08-15 18:57:58

Les sessions en BDD, c'est pas forcément top en terme de perf (disons que tu vas utiliser ton mysql pour du travail "idiot"). Tu peux lorgner du côté des daemons du type memcached ou mcache pour partager des infos arbitraires (au hasard, des infos de session).

JalaL · 2006-08-15 21:06:44

Calimero a écrit:
Les sessions en BDD, c'est pas forcément top en terme de perf...

...c'est pas forcement l'ideal mais ca permet de resoudre un probleme surtout si on ne sais pas qu'il existe d'autres solutions a part monter la partition/repertoire /tmp de l'autre serveur.

La seule application qui utilise des sessions sur mon serveur c'est un forum phpbb, il a son propre systeme de sessions dans sa propre BdD. Le jour où j'aurai besoin d'utiliser des sessions sur mes propres applications je tenterai autre chose.

Calimero · 2006-08-15 21:44:13

OK, je croyais que tu parlais de sessions PHP.

DEDIBOX-NEWS.COM

#1 2006-08-13 01:09:08

Pas vraiment cluster mais simple separation apache/mysql

#2 2006-08-13 01:23:46

Re: Pas vraiment cluster mais simple separation apache/mysql

#3 2006-08-13 08:30:57

Re: Pas vraiment cluster mais simple separation apache/mysql

#4 2006-08-14 00:30:41

Re: Pas vraiment cluster mais simple separation apache/mysql

#5 2006-08-14 00:50:12

Re: Pas vraiment cluster mais simple separation apache/mysql

Code:

#6 2006-08-14 17:01:41

Re: Pas vraiment cluster mais simple separation apache/mysql

#7 2006-08-14 17:30:42

Re: Pas vraiment cluster mais simple separation apache/mysql

#8 2006-08-14 18:26:05

Re: Pas vraiment cluster mais simple separation apache/mysql

#9 2006-08-14 19:32:17

Re: Pas vraiment cluster mais simple separation apache/mysql

#10 2006-08-14 19:51:12

Re: Pas vraiment cluster mais simple separation apache/mysql

#11 2006-08-15 17:00:58

Re: Pas vraiment cluster mais simple separation apache/mysql

#12 2006-08-15 18:57:58

Re: Pas vraiment cluster mais simple separation apache/mysql

#13 2006-08-15 21:06:44

Re: Pas vraiment cluster mais simple separation apache/mysql

Calimero a écrit:

#14 2006-08-15 21:44:13

Re: Pas vraiment cluster mais simple separation apache/mysql

Pied de page des forums