l'organisation de la BDD

Summary:

et ce n'est pas une mafia

l'organisation de la BDD

Jerome_H 11 Jan 2009 16:10

1er post de 2009 :)

Voici ce que je propose concernant la structure de nos serveurs services de BDD. On en avait discuté avec Cédric dans la semaine, ce post est là pour formaliser.
Etant donné que la réplication MySQL est un poil difficile à organisée avec 3 instances, j'ai pensé à n'en utiliser que 2. Rien d'extraordinaire pour le moment, mais là où c'est intéressant, c'est de définir une instance principale, l'instance maître, et une instance secondaire, l'instance esclave, et de mettre en place une réplication de maître vers esclave.
On aura donc ainsi une sauvegarde temps réel de la BDD.

Une autre astuce, c'est de mettre dans le code du site Web, les 2 instances. Si l'instance maître ne répond pas, il tente sur l'instance esclave automatiquement. Invisible pour l'utilisateur, si la réplication fonctionne parfaitement.

Il ne restera plus qu'à remettre en place le maître à partir des données de l'esclave (à la main, on en inversant la réplication).

Dommage que mon hdd du portable est plein, j'aurais bien testé la réplication entre 2 VM…

Re: l'organisation de la BDD

Cedric_B 11 Jan 2009 22:41

Bonne année ! ;-)

ça va être une bonne semaine projet. Je le sens.
Je pense que pour la soutenance de lundi (je crois) aucun système ne sera installé. ça n'a pas l'air de bouger. À moins qu'ils nous préviennent en milieu de semaine …

Re: l'organisation de la BDD

Jerome_H 12 Jan 2009 12:44

Mouais, c'est vrai que personne ne s'affole…

A première vue, on a pas mal de créneau libre cette semaine (mercredi toute la journée, jeudi matin, …). On pourrait installer un minimum de truc sur machine virtuelle, pour au moins faire tourner quelque chose. Il faudrait qu'on est des consignes précises de ce qu'il faut.

Re: l'organisation de la BDD

Cedric_B 12 Jan 2009 15:40

C'est clair, cette semaine le temps ne manque pas. Mais il ne faut pas attendre de consignes des profs. Faut qu'on se lance.
Ce que je vais faire ce soir (et commencer dès maintenant même ;-). En réfléchissant à divers trucs et certainement en éditant le Wiki.

On ne sait même pas sil faut un rapport ou quelque chose. Au pire je fais une petit rapport avec la wiki en LaTeX. ça va vite.
On a même une petite analyse des risques, ça va les impressionner.

On pourra aussi leur donner un accès au Wiki que l'on contrôle. Donc avec une adresse mail à nous. Il existe un service qui donne des adresses poubelles durant un temps donné. Je ne me souviens plus du nom, je vais chercher. Au pire, ben hotmail, ah ah :-)
En voyant le boulot et notre réflexion sur le wiki, Francine sera toute fière !

Re: l'organisation de la BDD

Cedric_B 12 Jan 2009 17:00

Voilà, il y a par exemple ce service :
http://www.jetable.org/fr/

Faut aussi qu'on pense à la serrure sécurisé … ça saoule.

Re: l'organisation de la BDD

Cedric_B 12 Jan 2009 17:17

Ah oui, on est fixé sur les technologies qu'on va utiliser ?
lighttpd ?
green-sql ? …

Re: l'organisation de la BDD

stephm 12 Jan 2009 17:47

Re :)

Quelques p'tites merdes ce week-end on fait que j'ai pu que installer FreeBSD vendredi soir et pas pu installer une debian en machine virtuelle comme j'ai dit à Cédric non plus…

Sinon faudra voir aussi si on utilise des machines virtuelles, ou bien si on installe physiquement sur les machines. C'est risqué d'installer sur VMWare, surtout au niveau de la RAM et ressources CPU… Après le problème si on installe sur les machines physiques, c'est le redéploiement d'un serveur, ca prendra un peu de temps…

A priori on aura

FreeBSD : machine de tête, avec seulement du nginx dessus pour la répartition de charge des serveurs webs. P'tete s'en servir pour la centralisation des logs (ya un utilitaire chflags qui permet d'ajouter un mode sappnd aka system-append only).

Debian :
3 serveurs lighttpd : A voir ce qu'on fait au niveau du filtrage (ça ignore toutes les requêtes sauf celles provenant du serveur de tête; ou alors il tourne que sous localhost et on fait transiter le tout par un tunnel ssh, ce qui est discret mais un peu plus couteux en ressources je pense)
2 serveurs green-sql : Permet de filtrer les requêtes SQL contenant du code malicieux. La mise en place des serveurs green-sql dépend fortement de l'orientation de l'architecture MySQL mise en place, donc faut voir.
2 serveurs mysql : Le problème de la réplication MySQL c'est que ya un maître et un esclave (normal). On peut exécuter que des ordres SELECT sur l'esclave, et tout les ordres existants sur le maître. La réplication est effectuée grâce à un binlog, que l'esclave doit surement loader tous les x temps. Donc en gros, tous les ordres sont effectués sur le maître. L'esclave prends que le relai si le maître tombe. Ou bien on peut dire que on balance tous les SELECT sur l'esclave, et le reste sur le maître. Et faut voir comment gérer vite fait le cas ou le maître ou l'esclave tombe.

Donc maintenant, les scénarios catastrophes :

La machine de tête tombe : Ca c'est le scénario le plus galère. Soit on remonte la machine from scratch, install à la main, on balance un p'tit script sh install.sh qui nous reconf toute la machine et c'est parti. Ou alors une fois que la machine est clean (virtuelle ou bien physique ?), on backup les partitions hardware avec dd, ou bien on fait des backups des machines virtuelles vmware. Ou alors une des debian prend le relai le temps de remonter le serveur de tête. J'pense que c'est le moins, genre celle qui aura aucun serveur MySQL d'installé. Après faut voir en combien de temps on peut gérer le basculement.

Le MySQL maître tombe : Faut voir comment gérer ça, et le tester en grandeur nature. Ya surement déjà des scripts pré-faits qui gèrent le truc, dunno, à se renseigner.

Le MySQL esclave tombe : Si l'esclave tombe, c'est pas grave, ca générera surement des warnings sur le maître comme quoi les binlogs ont pas pu être mis à jour sur l'esclave.

Re: l'organisation de la BDD

Cedric_B 12 Jan 2009 19:37

Moi je préfère des vrais machines que des virtuelles. En plus après faut aussi surveiller le système hôte.
ça prendra un peu plus de temps à re-déployer, mais :

• on n'arrivera pas à faire planter nos systèmes ;
• si une tombe quand même une autre peut prendre le relais.

Pour lighttpd
Oui, donc si on prend bien cette architecture on pourra faire communiquer les Debian uniquement avec la BSD.
On peut également utiliser la boucle localhost. Je pense que ça devrait aller.

Pour greensql
Pareil, faut qu'on valide cette architecture. Sinon, j'air regardé sur le site, ça n'est pas compliqué à installer et configurer.

Pour la catastrophe
On sauvegardera nos systèmes via dd. Ou on peut les mettre sur une partition différentes, c'est plus dangereux mais ça va plus vite.

On file quand un accès aux profs ? Histoire qu'ils peuvent nous dire que notre architecture correspond à leur attentes…

Re: l'organisation de la BDD

Jerome_H 12 Jan 2009 20:14

En y réfléchissant, je pense que l'installation se fera après la sountenance/rapport, quand tout aura été validé.

Dans l'état actuelle des choses, j'opterai aussi pour des machines réelles. On a pas assez de RAM pour virtualiser des serveurs de prod.

Pour l'architecture avec machine de tête, il faut vraiment la faire valider, parce que je ne me rappelle pas avoir entendu que l'on aurait 4 machines :/
Et dans le cas où cette machine tombe, on passe en indisponibilité, il faudrait donc fixer un temps de reprise.
Je ne vois pas trop comment une Debian pourrait prendre le relais. En l'activant à la main, à distance, par cette fameuse serrure sécurisée ? En gros, elle ne doit faire que de la répartition finalement cette machine.

Lighttpd n'as pas l'air trop hard à configurer. On n'a qu'un seul site, entièrement en https, donc pas besoin de VirtualHost.

J'y pense, on a encore toute les règles de firewall à définir :(

Last edited on 12 Jan 2009 20:14 by Jerome_H Show more

Re: l'organisation de la BDD

Cedric_B 12 Jan 2009 22:51

En y réfléchissant, je pense que l'installation se fera après la sountenance/rapport, quand tout aura été validé.

Je l'espère bien.

Pour l'architecture avec machine de tête, il faut vraiment la faire valider

C'est clair. Faudrait en parler aux profs. Leur montrer le Wiki ou qu'on prenne une initiative.

J'y pense, on a encore toute les règles de firewall à définir :(

J'y est pensé. Comme pour Snort. Pour Snort ce n'est pas difficile.
Mais j'ai pas beaucoup avancé toujours à cause du réseau.
C'est pour ça qu'une étape importante maintenant c'est qu'on fixe notre réseau, avec les adresses …
On verra demain en crypto ;-)

Tenez, je viens enfin de Tester Ulteo. C'est le fondateur de Mandriva (Mandrake plutôt) qui en est à l'origine.
C'est cool, y a toutes les applications nécessaires et à jour. Même OpenOffice 3 ! Et le bureau est assez réactif.
Ce qui est bien aussi, c'est qu'on peut supprimer son compte (ça devient rare cette option !).