Il parle de 20K soit 20000 visites non ?
Le 27 novembre 2012 07:07, Patrick Proniewski <pat...@patpro.net> a écrit :
> Bonjour,
>
> Je ne vois pas trop ce qu'il aurait à gagner avec un load balancer. Avec
> 200 visiteurs uniques par jour la puissance de calcul d'un smartphone
> suffi. Même en doublant le nombre de visiteurs tous les mois (la "forte
> croissance" dont il est question) il doit pouvoir tourner avec un serveur
> d'entrée de gamme encore pendant 6 mois (ce qui donnerait 12800 visiteurs
> jour, et reste carrément raisonnable).
> Je crois que le problème est ailleurs. Si l'appli est si moisie que ça, il
> faut la réécrire. Ça sert à rien de balancer la sauce sur le hardware, et
> de monter des usines à gaz pour tirer sur les perfs si l'appli jette les
> ressources par la fenêtre.
> En tout cas, on ne nous dit pas tout. Si peu de visites, et déjà des
> besoins d'améliorer la disponibilité, c'est pas normal.
>
> Ton conseil reste judicieux pour préparer l'avenir. Avoir un domaine genre
> static.maboite.fr pour héberger toutes les ressources statiques est une
> démarche saine et permet en cas de coup dur de mettre rapidement en place
> de la répartition de charge.
>
> La virtualisation, c'est quand on a trop de ressources matérielles par
> rapport à ses besoins, alors on se permet d'en gâcher un peu en ajoutant
> quelques couches entre ses appli et son hardware, et ça n'apporte de la
> sécurité/redondance que quand tu commences à avoir du du matos sérieux (une
> ferme de serveurs avec un stockage redondant, et le soft qui va bien pour
> gérer le HA, la migration des VM à chaud d'un serveur à l'autre, la reprise
> automatique quand un serveur claque, etc.)
>
> Tu auras la même chose sans avoir à le gérer si tu te fais héberger dans
> un cloud, pour une toute petite fraction du coût de l'investissement, donc
> il ne faut pas jeter la solution du cloud aussi vite :)
> Même en partant sur du cloud, cela ne règle pas la question de la
> scalabilité : il faut que l'appli soit correctement écrite pour pouvoir
> croitre.
>
> Ensuite, je ne connais pas la qualité de l'hébergement souscrit chez O*V,
> mais si c'est du mutualisé d'entrée de gamme, le simple fait de migrer sur
> du dédié (hors ovh) peut changer la face du monde.
>
>
> On 27 nov. 2012, at 06:39, Baptiste wrote:
>
> > Salut,
> >
> > Ah ben je crois qu'il te faut un bon Load-balancer, efficace et pas
> > cher: HAProxy :)
> > Tu pourras gérer tes 2 serveurs en fail-over l'un de l'autre ou en
> > répartition pure et simple, tu pourras faire du content switching
> > ("routage" basé sur le Host header ou l'URL ou autre).
> > En plus, ça fourni pleins d'informations sur les temps de réponses des
> > applications, et donc en cas de lenteurs, tu pourras pointer soit
> > l'archi soit les dévs :)
> >
> > Je ne saurais trop te conseiller de diviser ton trafic en 2 dès
> > maintenant: 1 nom de domaine pour les objets statiques et 1 nom de
> > domaine pour l'application dynamique, même si tout est hébergé sur un
> > même serveur pour le moment.
> > Avec HAProxy, ça te permettra de gérer différent health check, mais
> > aussi différents niveau de régulation de trafic, persistance, etc....
> >
> > voili voilou,
> >
> > a+
> >
> >
> > 2012/11/27 SD76 <sd76.bac...@gmail.com>:
> >> Bonjour,
> >>
> >> Étant sysadmin junior, je me permet de vous sollicitez afin de faire
> les bon
> >> choix.
> >>
> >> Contexte:
> >>
> >> PME immobilière nationale en fort développement. Actuellement site
> vitrine
> >> et outils métiers
> >> ne font qu'un même techno (Apache/php/mysql) et serveur unique...
> >> On a pas mal de souci de perf (code non optimisé et pareil coté BDD).
> >>
> >> 20k visiteurs unique jours / 80 salariés.
> >> Les volumétries sont raisonnable.
> >>
> >> Objectif:
> >>
> >> Tout est en cours de refonte (Nginx/PHP/PostGresql), nous souhaitons
> isoler
> >> le site et l'application métier sans trop arriver à choisir. Améliorer
> la
> >> disponibilité, faciliter la mise en prod…
> >>
> >> Exemple d'archi:
> >>
> >> Site et sa base de donnée sur un premier serveur avec un failover
> >> idem pour la partie métier
> >>
> >> Site et appli métier sur un même serveur et chaque base de donnée sur
> leur
> >> serveur…
> >>
> >> Les combinaisons sont nombreuse…
> >>
> >> Virtualisation ou non? Les techno nous importe peu tant qu'elles on fait
> >> leurs preuve.
> >> Étant donné la croissance de l’activité, nous recherchons aussi la
> >> scalabilité.
> >> L'idée étant de garder au maximum la main sur les machines, le "cloud"
> ne
> >> nous
> >> botte pas vraiment.
> >> Et pour avoir déjà donné, je ne veux pas de solution à base de
> bidouillage
> >> :)
> >>
> >> Si vous avez des retours d’expériences sur des besoins similaire ou des
> >> remarques à apporter
> >> j'en serait ravi.
> >>
> >> NB: O*H nous hébergent actuellement, je souhaiterai déménager. Si vous
> avec
> >> de bon contact,
> >> je suis preneur.
> >>
> >> Merci.
> >> sd
> >>
> >> _______________________________________________
> >> Liste de diffusion du FRsAG
> >> http://www.frsag.org/
> >>
> > _______________________________________________
> > Liste de diffusion du FRsAG
> > http://www.frsag.org/
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
