2 Serveurs dédiés: sauvegarde et disponibilité pour site Pro

banane antichar · 28 Février 2010

Bonjour à tous, c'est mon premier poste

Je compte prendre (surement chez ovh) 2 serveurs dédiés(1 pour la bdd postgersql, l'autre pour le site) pour un futur site de E-commerce qui deviendra assez important avec les mois à venir.

Je n'ai pas les même contraintes que les petits sites oscommerce/autoentrepreneur et je serais un pure player, mais je n'ai pas non plus les moyens de la Fnac ni leur problème énorme de monté en charge.

L'idée est d'avoir une disponibilité importante, un système de sauvegarde fiable et automatisé et évidemment un temps de réponse rapide.

Pour la sauvegarde (et réplication de la bdd) pensez vous qu'avec seulement 2 serveurs dédiés à la production, je puisse mettre en place un tel système sans diminuer les performances (par ex de A vers B et inversement) et si non que préconisez vous?

j'ai entendu parler de haproxy pour une solution load balancer pour une disponibilité importante, est il fiable? compliqué à mettre en œuvre?

bruno212 · 28 Février 2010

Bonsoir,

Quelles applications comptes-tu installer ?
Combien de visiteurs par jour as-tu prévu ?

à plus

Julia41 · 28 Février 2010

HAProxy est très fiable, un truc de malade (jamais vu planté même en cas de Ddos massif, c'est toujours les serveurs web derrière qui crashent), gros problème c'est la récupération de l'IP de tes visiteurs (Visiteurs => HAProxy => apache), l'IP qui apparait est l'IP du HAProxy (un proxy donc), mais tu peux quand même récupérer 90% de tes IP avec les header X_Forward_for.

Au niveau de la réplication SQL (slave/master je pense) c'est bien car c'est une sécu supplémentaire, mais le gros problème reste qu'il faut activer les logs bin (je parle de MySQL je ne connais que trop peu postgre) qui demandent pas mal d'écriture disque si tu as beaucoup de requête SQL.
Pour ma part je me sers de cette solution :
backup SQL du serveur SQL vers un serveur SQL hébergé sur le serveur (sous dimensionné) toutes les 2/3h, si le serveur "officiel" plante, alors au niveau de PHP, on passe sur le local (ça dépanne et ça coute pas cher).

En tout cas, la réplication est bien galère à mettre en place (je parle de MySQL) au niveau de tout ce qui est des resync en cas de crash), mais pour HAProxy, ce truc là est une bombe aussi bien par sa stabilité que par sa facilité d'utilisation (rajout de serveur, serveur de backup). Perso je load balance même mes emails avec.

banane antichar · 1 Mars 2010

Merci à vous pour ces réponses rapides.

pour répondre à bruno12:

Windows: je connais bien les windows server, en cas de problème je serai à même de mieux comprendre ce qui se passe, même si une personne sera dédié à la charge.

Apache: inutile de donner de raisons :mrgreen:

Postgresql: pour des raisons de montée en charge, de fiabilité en milieu professionnel et gratuit.

Php

Combien de visiteurs par jour as-tu prévu ?

En vitesse de croisière je dirais en milliers/jours, avec évidemment des pics et creux relatifs au périodes de noël.

@Julia41

Haproxy m'a l'air vraiment très intéressant, par contre ça m'inquiète un peu l'histoire de la récupération des IP, je vais déjà lire 2/3 docs dessus, histoire de ne pas mourir bête.

quand tu dis:

backup SQL du serveur SQL vers un serveur SQL hébergé sur le serveur (sous dimensionné) toutes les 2/3

"Hébergé sur le serveur" duquel parles tu? du serveur dédié au site? si c'est le cas, la bdd de secours ne risque t'elle pas de prendre toute la ressource du serveur puisque les Sgbd sont programmés pour cela?

C'est aussi pour cela que j'ai choisi postgresql, qui, sans être parfait, semble plus au fait niveau réplication. (évidemment je me base plus ce ce que je peut lire que sur mon expérience faible en bdd).

Julia41 · 1 Mars 2010

Si le problème de la bdd de secours qui serait hébergée sur le même serveur que Apache risque de prendre "tout", le principe est de la sous dimensionner mais de permettre que le site "tourne". Si bien sûr tu as les moyens d'investir, tu peux prendre un autre dédié à part (mon idée est en mode radin).

Personnellement plutôt que de stocker mes backups SQL en ".sql" je les stocke dans une base de données tournant. En cas de crash mon backup est prêt à tourner et ça me permet de laisser le site tourner (bien sûr il ramme) mais sans cout supplémentaire.

Je suis d'accord avec toi pour postgre, je ne m'en suis servi que pour tester et voir ce que c'était, mais d'après toutes mes connaissances dans certains cas ça vaut vraiment le coup de changer.

Au final et pour en revenir au total, tu as le choix entre une solution couteuse au niveau des serveurs (pour faire de la réplication) par exemple, ou une solution plus simple (aussi bien d'installation mais au niveau du prix).

Tout dépends de tes besoins et de si oui ou non, ton site peut se permettre de revenir quelques heures en arrière, à savoir aussi qu'il faut identifier d'où les plantages peuvent venir. Si c'est un dédié qui crashent par exemple, à cause des disques, là c'est gênant mais ton backup pourra te permettre de continuer à tourner. Si c'est apache qui plante (site mal codé ou autre), là c'est bien d'avoir des données accessible rapidement et simplement.

banane antichar · 2 Mars 2010

Ok

merci pour les conseils, ça m'aide beaucoup pour la suite.

Julia41 · 3 Mars 2010

N'hésites pas à nous filer des retours sur ce que tu as choisi et là où tu en as chié pour mettre en place

Au final ça reste surtout une question de budget entre "ce dont j'ai besoin" et "ce que je peux me permettre" car avoir des dédiés de backup, si tout tourne comme sur une horloge, demandes des achats en plus qui ne tourneront "jamais"

banane antichar · 6 Mars 2010

D'ici quelques mois, pas de problèmes pour les retours :wink:

Effectivement la question du budget va se poser concernant un 3ème serveur de backup ou non.

Je n'ai pas pris de décision, mais je reviendrai vers vous quand cela sera fait.

Merci.