Cluster sur SME

[Busy47]

Voila bonjour a tous
J'ai une petit question, je voulais savoir si je pouvais faire une sorte de clustering avec 2 serveur SME relier par un liason VPN, chacun sera un serveur LAMP et auront la meme base de données mais par contre je voulais savoir si la liason vpm coupe par hazard est-ce que les modifications faitent sur la BD SME1 ainsi que les modifs sur la BD SME2 pourront se synchronisé dès que la liaison vpn sera revenu et que les bases pourront être incrémenter sans soucis.
Merci pour vos réponses

[jibe]

Salut,

Je comprends très mal ce que tu veux faire ? Une sorte de haute disponibilité via un VPN ?

Comment vont être gérés les accès à tes deux serveurs ? Comment ferais-tu du load balancing dans une telle configuration ?

En fait, chacun aura un accès séparé, et tu voudrais que la BDD soit synchronisée, c'est ça ? Mais alors, le problème sera que lors de la coupure VPN, tes deux bases vont évoluer indépendemment l'une de l'autre, tu ne pourras plus les synchroniser de manière simple en remplaçant simplement la plus ancienne par la plus à jour !

Je crains que ce que tu imagines ne soit pas raisonnablement possible, ou alors il manque des précisions sur ce que tu imagines faire...

[mad_dog]

La mise en place d'un VPN entre deux serveurs SME est assez simple !
Le plus dur sera de synchoniser 2 base de données MYSQL (vu que tu parle d'appli LAMP), pour cela il faut installer MYSQL5 qui gère bien cela !
Sinon pour l'accès à tes deux serveurs WEB, il faudrait que tu nous indique le fonctionnement précis de se que tu souhaite : il equilibrage de charge ou un failover ?
De plus, il te faut un DNS externe qui gère le round robin !

Donc :
il te faut :
- 2 SME V7
- une mise à jour de MYSQL 4 en MYSQL 5 Cluster
- un paramétrage assez fin de MYSQL 5 Cluster
- 2 services OPENVPN sur chacunes des SME !
- un DNS externe gérant le round-robin !

Pour la conf de MYSQL5, j'essayerai de poster quelques liens !

[jibe]

Salut,

il faut installer MYSQL5 qui gère bien cela !

Décidément, il faudra que je me remette à regarder de plus près MySQL : j'ai toujours considéré que ça n'avait de base de données que le nom, mais il semble que de gros progrès ont eu lieu !

Par contre, je reste assez sceptique sur la réalisation d'un cluster via VPN : c'est quand même moins simple à faire qu'avec une simple liaison ethernet, et le peu de fiabilité de la liaison entre les deux serveurs me laisse sceptique... Crois-tu que les avantages vont arriver à dépasser les nombreux inconvénients ? Que veux-tu faire ? N'y aurait-il pas une meilleure solution ?

[Busy47]

Merci pour vos réponses déja
je vais essayer de mieux m'expliquer
un liason VPN sera crée en bridge je pense ensuite les 2 reseau VPN se verront parfaitement
sur chaque reseau vpn une sme avedc LAMP
chaque utilisateur sur le vpn1 se connectera au serveur sme1 et pour le vpn2 ils se connecteront sur la sme2 et j'aimerais que les 2 sme se synchronise a chaque modifs par exemple. De cette facon si la liason vpn venait a etre perdu les utlisateurs pourrait continuer a travailler sur leur serveurs respectifs et des le retour de la liason vpn tout se resynchronisera automatiquement. Je realise quand meme que c'est un peu complexe a mettre en oeuvre, merci pour votre aide

[Cool34000]

Je ne sais pas comment marche le clustering sous SME, ni même si cela est possible... J'ai quelques expériences sous 2003 serveur...

Pour ta base de données, elle devrait être placée sur un quorum (commun au 2 serveurs du cluster).
Ceci est simplement un espace de stockage commun au 2 serveurs (généralement du SCSI). Mais le prix est cher et le matos nécessaire est conséquant...

Pour les coupures, normalement un cluster en tolérance de panne possède une seule IP, il te suffit de joindre l'IP du cluster et non l'IP du serveur 1 ou 2 !
2 cartes réseaux sont nécessaire pour cela par serveur (1 connectée au LAN, l'autre réliée à l'autre serveur par un cable croisé).

Bon courage !!!

[jibe]

Salut,

Ok, je comprends mieux. En fait, il s'agit simplement de synchroniser deux BDD supposées pouvoir fonctionner indépendamment l'une de l'autre. A partir du moment où elles sont supposées pouvoir fonctionner indépendamment et se resynchroniser, la fiabilité de la liaison n'a qu'une importance relative. Et si j'ai tout bien compris, il ne s'agit pas du tout de clustering, mais d'une simple synchronisation de BDD.

Il reste une chose qui me tracasse, mais pour laquelle tu as peut-être déjà une réponse : lorsqu'une ligne dans une table est modifiée ou supprimée "simultanément" (j'entends : entre deux synchronisations) sur les deux BDD, que se passe-t-il ??? En fait, il faut gérer des accès concurrentiels sans savoir qu'ils le sont ! En effet, si la liaison est tombée lors de ce double accès, ni l'une ni l'autre des BDD ne peut considérer l'accès comme étant concurrentiel... Cela veut dire qu'il est hors de question de gérer les accès concurrentiels par un système de transactions, seulement le versionning est envisageable. Je ne sais pas si MySQL travaille maintenant en versionning ? Et je ne suis même pas sûr que le versionning puisse répondre parfaitement à ce problème... Mais bon, tout cela est peut-être bien géré par ce MySQL cluster dont parle mad-dog ?

[Busy47]

Enfet si une ligne est rajouter sur une table avec par exemple n°7 toutes les deux il faudrait qu'a la synchronisation un des n°7 passe en 8 et l'autre reste en 7 mais je pense que sa se situe plus au niveau du code php. Je pense egalement que c'est ne pas un cluster de mysql.

[jibe]

Salut,

Tu as le problème que tu cites, mais aussi une foule d'autres. Par exemple la modification simultanée d'une ligne depuis deux postes et un tas d'autres cas d'accès concurrentiels. Il y a effectivement une part assurée par le programme, mais aussi une part assurée par le SGBD (enfin, normalement. Je n'ai jamais travaillé avec MySQL justement parce que cela était très mal géré... Tout au moins dans les versions que je connaissais). Pour faire fonctionner deux SGBD en tolérence de panne, il faut arriver à faire en sorte qu'elles gèrent communément ce que normalement elles gèrent individuellement...

Tu me fais un peu peur, parce que ce que tu veux faire est quelque chose de très pointu et que tu sembles méconnaitre et/ou minimiser les problèmes qui t'attendent. Lis ceci qui t'aidera à bien tout cerner

Pour ma part, je pense qu'il est plus facile de fiabiliser la liaison distante et de n'avoir qu'un seul serveur de BDD. A ma connaissance, c'est d'ailleurs ce qui se fait généralement. Mais à toi de voir en fonction de tes besoins réels...

[mad_dog]

Voici un article très interressant sur la réplication MYSQL 5

http://greg.rubyfr.net/pub/?page_id=26

[jibe]

Salut,

Intéressant en effet. Bien que ça reste assez dans l'esprit MySQL, c'est à dire simple pour ne pas dire simpliste... Bon, j'ai peut-être parcouru un peu vite aussi

Mais c'est bien ce que je disais : pas d'accès concurrentiels, pire même : pas de mise à jour simple du master à partir du slave. Pour moi, le système à tolérance de panne reste du bricolage plus qu'autre chose... Et encore, là aussi pas d'accès simultané sur les deux bases : on met à jour le master, et lorsqu'il tombe en panne, on utilise le slave.

AMHA, ce n'est pas ce qui convient à Busy47 (mais je répète : j'ai peut-être lu un peu vite et avec un a-priori défavorable pour MySQL que je considère excellente pour faire une galerie photos, mais pas des applications nécessitant un "vrai" SGBD relationnel).

Pour faire ce que tu veux, Busy47, il faudrait déjà partir avec un vrai SGBD. Et je ne suis pas certain que faire de la tolérance de panne via Internet soit une bonne chose... Perso, comme je te le disais, je préfère sécuriser la liaison et n'avoir qu'un serveur (ou un cluster en tolérance de panne ou load balancing, mais un "vrai" cluster avec une seule IP pour les deux serveurs)... Je pense que la solution est ainsi plus fiable et pas forcément plus onéreuse (Firebird est en GPL et se monte assez facilement sur SME 6, probablement aussi sur SME 7)...