Ah bah oui, c'est ce que j'étais en train de dire

Le mardi 27 novembre 2012 09:18:31 David RIBEIRO a écrit :

Il parle de 20K soit 20000 visites non ?

Le 27 novembre 2012 07:07, Patrick Proniewski <patpro@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.backup@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/