Pu*** le matin j'ai pas les yeux en face des trous :D Tu as raison, c'est bien 20k (20000) et pas 200 !
Cela dit, l'essence de mon discours reste valable, mais le HA/LB prend beaucoup
plus de sens.
Mea culpa, la prochaine fois j'attendrai d'avoir avalé mon thé et mis mes
lunettes avant de répondre.
On 27 nov. 2012, at 09:18, David RIBEIRO wrote:
> 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
