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
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/
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/
Salut Patrick,
Ben le gros intérêt aussi de load-balancer, c'est d'assurer la disponibilité de l'appli... 80 salariés sur le carreau, ça doit couter cher par rapport à l'investissement en matériel: 2 serveurs 1U standard pour l'appli qui peuvent même héberger HAProxy dès le début... Y'a pas de surcout. Après, un HAProxy sur une carte ARM à pas cher et tu atteinds 3K req/s... ca coute pas cher et ça sauve des vies... En plus HAProxy il te dira si ton appli est moisie et il te dira où :) encore un gain de temps, sans un cout supplémentaire: HAProxy est gratuit.
a+
2012/11/27 Patrick Proniewski patpro@patpro.net:
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/
Bonjour,
Le 27/11/2012 07:19, Baptiste a écrit :
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…
d'accord avec les collègues, je rajoute juste une précision concernant la DB : PostGresql est un très bon SGBDR, mais performe surtout pour les grosses requêtes transactionnels, alors que MariaDB sera meilleur pour quantité de petites requêtes. MariaDB est aussi plus facile d'accès pour un DBA et pour les développeurs, donc je pense que pour un site web ce SGBDR est plus adapté.
Mais les 2 sont très bon ;)
Dans tous les cas, la majeure partie du travail devra être faite sur la réécriture partielle ou totale de l'appli, et pour commencer il faudrait jeter un oeil sur le schéma DB et ses index ...
On 27 nov. 2012, at 07:19, Baptiste wrote:
Ben le gros intérêt aussi de load-balancer, c'est d'assurer la disponibilité de l'appli... 80 salariés sur le carreau, ça doit couter cher par rapport à l'investissement en matériel: 2 serveurs 1U standard pour l'appli qui peuvent même héberger HAProxy dès le début...
Je suis d'accord, mais on ignore tout de l'hébergement de l'OP, et je soupçonne que c'est pas tip-top (du mutualisé ?). Avant de jouer à faire du HA entre deux serveurs physiques ou deux VM dans le cloud, il va falloir investir dans un hébergement sérieux (éventuellement du housing plutôt que du hosting).
J'en profite pour faire de la pub, j'ai mon serveur perso hébergé chez Absolight depuis (très) longtemps, j'en suis très content.
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/
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/
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 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/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Il a dit :
20k visiteurs unique jours / 80 salariés.
20k visiteurs, ca fait pas 200.
HAProxy c'est bien aussi pour avoir une page de maintenance, meme si derriere il n'y a qu'un host. Avec le SSL offload des versions récentes, ca marche plutôt bien.
Apres, perso, j'aime assez la solution nginx/upstream hash module, et du varnish pour le contenu statique... Mais c'est une affaire de goûts principalement, je ne sais pas à quel point c'est performant par rapport à d'autres...
Le fait d'avoir un petit host pour le contenu statique est aussi une bonne idée, c'est simple à mettre en place, en tout cas plus simple que du caching.
La virtu, c'est carrément overkill là, je trouves :) Le fait de migrer vers un meilleur dédié peut aider, mais le housing... Je sais pas trop. En cas de défaillance matérielle, l'hébergeur a du spare, une GTI/GTR, est sur place pour remonter rapidement (ou des astreintes la nuit)... bref, tout plein d'avantages par rapport au housing ou tu gardes des pieces dans ton bureau, et ou tu dois faire 20 bornes pour aller au DC en cas de souci... Ca me donne un petit sentiment "bricolage" quoi...
Le mardi 27 novembre 2012 07:07:41 Patrick Proniewski 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/
C'est difficile de conseiller à ce stade « ya ka faire ci ... », mais effectivement la virtualisation est une bonne approche car elle permet de monter en puissance plus facilement qu'avec du matos à chaque fois. Je reste sur le fait que 20K voulait bien dire 20000 visiteurs jours. Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, ...) , à la condition que l'appli PHP le supporte (problème des sessions, ...). Pour la base de données, nous, on recommande aussi Postgresql, en lieu et place de Mysql quand c'est possible.
Maintenant, ne jamais oublier qu'une appli pourrie ne sera jamais compensée par du hardware. Combien de fois j'ai vu des applis où 1 ligne de code (UNE) fout en l'air les performances : requête SQL avec jointures mal faites, boucles PHP à ne plus savoir où on est,...
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de SD76 Envoyé : mardi 27 novembre 2012 00:34 À : French SysAdmin Group Objet : [FRsAG] Conseil sur une architecture serveurs
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
On 27 nov. 2012, at 09:28, Sylvain Donnet wrote:
Je reste sur le fait que 20K voulait bien dire 20000 visiteurs jours
oui, c'est très clair, j'avais juste confondu le k avec un 0, mes yeux sont pas du matin ;)
La virtualisation par contre c'est un peu overkill, à moins de l'utiliser en mode client uniquement (se faire héberger sur un cloud). Parce que monter sa propre infra de virtualisation c'est quand même bien coûteux.
Pour ce qui est de la BDD, je ne suis pas totalement d'accord : - une bonne BDD est une BDD qui est maitrisée en interne. Si tu n'as pas de connaissance en Postgresql (ou de mec capable de monter rapidement en compétence dessus, ou les moyens de faire bosser un DBA compétent externe), ce n'est pas forcément une bonne idée de passer de MySQL à Postgresql. - une appli moisie reste une appli moisie, quelle que soit la BDD. Refondre l'appli ou optimiser l'appli représente toujours les 90 premiers % du gains de perfs.
Les problèmes de perfs de MySQL deviennent franchement problématiques à partir de trafics bien plus importants que 20k visites/j (sur une appli standard), et restent la plupart du temps contournables avec des dévs compétents (après tout, Facebook continue à largement tourner sur du MySQL).
A l'opposé, avec des devs pas à niveau et un bon DBA, Postgresql est plus que recommandé.
Sinon :
Vu ce niveau de trafic, un load-balancer semble être un bon principe, avec 2 serveurs pour le web (voire 2 frontaux + 2 BDD, avec, dans le cas de MySQL, de la réplication), et avoir un/des serveur(s) séparé(s) pour le métier (avec des mécanismes/procédures pour être capable de reprendre le métier sur la plateforme web).
Si le site est assez statique, le meilleur moyen de gagner des perfs est encore de mettre en place un proxy cache (ex: varnish) : les meilleurs perfs sont celles obtenues quand on ne tape pas dans PHP ou dans la base de données.
Suivant la manière dont tu accèdes aux données, un cache applicatif peut aussi être utile (ex: memcached, redis) pour éviter des accès en base.
NB : à ce niveau de trafic, en PHP, ne stocke pas les sessions en BDD, mais dans memcached ou redis.
Si tu cherches un petit hébergeur compétent en mode infogéré, tu peux contacter Typhon.
JFB
Le 27 nov. 2012 à 09:28, Sylvain Donnet a écrit :
C’est difficile de conseiller à ce stade « ya ka faire ci … », mais effectivement la virtualisation est une bonne approche car elle permet de monter en puissance plus facilement qu’avec du matos à chaque fois. Je reste sur le fait que 20K voulait bien dire 20000 visiteurs jours. Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, …) , à la condition que l’appli PHP le supporte (problème des sessions, …). Pour la base de données, nous, on recommande aussi Postgresql, en lieu et place de Mysql quand c’est possible.
Maintenant, ne jamais oublier qu’une appli pourrie ne sera jamais compensée par du hardware. Combien de fois j’ai vu des applis où 1 ligne de code (UNE) fout en l’air les performances : requête SQL avec jointures mal faites, boucles PHP à ne plus savoir où on est,…
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de SD76 Envoyé : mardi 27 novembre 2012 00:34 À : French SysAdmin Group Objet : [FRsAG] Conseil sur une architecture serveurs
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/
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, …) , à la condition que l’appli PHP le supporte (problème des sessions, …).
Y'a des cookies pour ça :) Et HAProxy fait ça très bien, soit en insérant lui même un cookie dans le client, soit en utilisant le cookie applicatif (en le modifiant ou non).
a+
Oui, mais c'est toujours mieux d'avoir un LB et des frontaux stateless, et donc mettre en place un stockage de session centralisé (c'est assez facile de mettre en place un redis/memcached et de configurer PHP pour taper dedans).
JFB
Le 27 nov. 2012 à 11:22, Baptiste a écrit :
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, …) , à la condition que l’appli PHP le supporte (problème des sessions, …).
Y'a des cookies pour ça :) Et HAProxy fait ça très bien, soit en insérant lui même un cookie dans le client, soit en utilisant le cookie applicatif (en le modifiant ou non).
a+ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
pour un client qui avait plsu de 100K (100000 [?]) utilisateur par jour, j'avais comme plateforme deux serveur frontend apache en actif actif avec identification du client pour gérer les sessions, deux haproxy en cluster actif passif assurée par heartbeat, deux backend applicatif en actif actif et un cluster de base de données en actif passif via heartbeat aussi.
tu pouras regarder de ce côté là si tu veux, l'installation et la configuration sont assez simple
Tarik CHICHANE
Le 27 novembre 2012 10:31, JF Bustarret jf@bustarret.com a écrit :
Oui, mais c'est toujours mieux d'avoir un LB et des frontaux stateless, et donc mettre en place un stockage de session centralisé (c'est assez facile de mettre en place un redis/memcached et de configurer PHP pour taper dedans).
JFB
Le 27 nov. 2012 à 11:22, Baptiste a écrit :
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou
autre, …)
, à la condition que l’appli PHP le supporte (problème des sessions, …).
Y'a des cookies pour ça :) Et HAProxy fait ça très bien, soit en insérant lui même un cookie dans le client, soit en utilisant le cookie applicatif (en le modifiant ou non).
a+ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour all,
Quelques remarques perso :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
2/ Quels moyens et quel besoin de disponibilité ? La virtualisation c'est trés bien, mais c'est quand meme rapidement plus cher que des dédiés.
3/ Globalement, as-tu quantifié ton trafic global ? Ok 20K visiteurs, mais combien de hit sur ton frontal ? combien de requetes et de quel type sur ta base ? Combien de requetes différentes aussi ? (là je pense notamment à du memcached si tes requetes sont tout le temps les meme, mais a priori si c'est le cas, il y a de fortes chances que les pages puissent etre aussi mises en cache avant de faire un hit sur tes backends/bdd)
4/ Quel besoin d'I/O disque ? le virtuel est vite moyen la dessus.
5/ Je ne partage pas l'avis de certains, MySQL fait de l'excellent travail, à un niveau de charge assez élevé aujourd'hui (on stock 300 millions d'enregistrement dans certaines de nos tables, ça tiens, le plus dur étant d'aller chercher de la data, et on hit sans gros problèmes 2000 à 2500 req/sec par serveur sans qu'il bronche trop), par contre niveau dispo, la réplication c'est un assez bon moyen, tant que tu n'as pas de problème ...
6/ Tu as profilé les requètes qui sont faites ? parfois un simple index sur une data trés utilisée facilite grandement les choses ...
Pour ton provider actuel (OVH), en dédié ils ont du bon materiel, pour le virtuel, je connais peux leur presta, amazon fait du trés bon travail dessus.
En gros, ta question est beaucoup trop vague pour définir vraiment une solution, il faut que tu quantifie un peu plus ta charge actuelle pour pouvoir faire les bons choix.
S.
2012/11/27 JF Bustarret jf@bustarret.com
Oui, mais c'est toujours mieux d'avoir un LB et des frontaux stateless, et donc mettre en place un stockage de session centralisé (c'est assez facile de mettre en place un redis/memcached et de configurer PHP pour taper dedans).
JFB
Le 27 nov. 2012 à 11:22, Baptiste a écrit :
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou
autre, …)
, à la condition que l’appli PHP le supporte (problème des sessions, …).
Y'a des cookies pour ça :) Et HAProxy fait ça très bien, soit en insérant lui même un cookie dans le client, soit en utilisant le cookie applicatif (en le modifiant ou non).
a+ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables.
Le 27 nov. 2012 à 11:55, Sylvain RAMOUSSE a écrit :
Bonjour all,
Quelques remarques perso :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
2/ Quels moyens et quel besoin de disponibilité ? La virtualisation c'est trés bien, mais c'est quand meme rapidement plus cher que des dédiés.
3/ Globalement, as-tu quantifié ton trafic global ? Ok 20K visiteurs, mais combien de hit sur ton frontal ? combien de requetes et de quel type sur ta base ? Combien de requetes différentes aussi ? (là je pense notamment à du memcached si tes requetes sont tout le temps les meme, mais a priori si c'est le cas, il y a de fortes chances que les pages puissent etre aussi mises en cache avant de faire un hit sur tes backends/bdd)
4/ Quel besoin d'I/O disque ? le virtuel est vite moyen la dessus.
5/ Je ne partage pas l'avis de certains, MySQL fait de l'excellent travail, à un niveau de charge assez élevé aujourd'hui (on stock 300 millions d'enregistrement dans certaines de nos tables, ça tiens, le plus dur étant d'aller chercher de la data, et on hit sans gros problèmes 2000 à 2500 req/sec par serveur sans qu'il bronche trop), par contre niveau dispo, la réplication c'est un assez bon moyen, tant que tu n'as pas de problème ...
6/ Tu as profilé les requètes qui sont faites ? parfois un simple index sur une data trés utilisée facilite grandement les choses ...
Pour ton provider actuel (OVH), en dédié ils ont du bon materiel, pour le virtuel, je connais peux leur presta, amazon fait du trés bon travail dessus.
En gros, ta question est beaucoup trop vague pour définir vraiment une solution, il faut que tu quantifie un peu plus ta charge actuelle pour pouvoir faire les bons choix.
S.
2012/11/27 JF Bustarret jf@bustarret.com Oui, mais c'est toujours mieux d'avoir un LB et des frontaux stateless, et donc mettre en place un stockage de session centralisé (c'est assez facile de mettre en place un redis/memcached et de configurer PHP pour taper dedans).
JFB
Le 27 nov. 2012 à 11:22, Baptiste a écrit :
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, …) , à la condition que l’appli PHP le supporte (problème des sessions, …).
Y'a des cookies pour ça :) Et HAProxy fait ça très bien, soit en insérant lui même un cookie dans le client, soit en utilisant le cookie applicatif (en le modifiant ou non).
a+ _______________________________________________ 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/
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables.
Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH, Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000EUR HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000EUR + 300/an +un bon sysadmin avec les charges et RTT coute 5000EUR/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...) + un swith giga manageable de bonne marque + un bon firewall, un KVM ip +.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par exemple, il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69EUR/mois....chez OVH, Kimsufi, Amazon ou un autre du même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou-cosmonaute-1684.ht... )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit :
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables.
Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était
sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH,
Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
Liste de diffusion du FRsAG http://www.frsag.org/
une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)
- un swith giga manageable de bonne marque
- un bon firewall, un KVM ip
Ton calcul est faux.
Tu ne peux pas comparer ce que tu coute un hébergement à une boîte standard qui achète du matos de grande marque et finance les marges de pas mal d'intermédiaires (hébergeur, constructeur, le prestataire du constructeur qui gère la garantie, le fournisseur de clim, ...), avec ce que coûte l'hébergement à une boite qui a des milliers de m2 de salle machines et plus de 100k serveurs, qui monte lui-même ses serveurs, gère ses stocks de pièces et automatise à mort la plupart de ses process.
L'effet d'échelle est monstrueux.
Ceci étant dit, je suis pas fana d'héberger un gros site avec des contraintes importantes chez OVH, mais, compte tenu du prix, le service rendu par OVH est assez impressionnant.
JFB
je suis d'accord avec toi mais il y a des limites a tout. Le client a sa part de responsabilité, il achète des Mhz et des Giga, ces sociétés leur vendent des Mhz et des Giga... ( en trichant sur les chiffres au passage... , combien de société vendent du dédie pour du virtualisé en réalité ??? )
Le 27/11/2012 13:39, JF Bustarret a écrit :
une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)
- un swith giga manageable de bonne marque
- un bon firewall, un KVM ip
Ton calcul est faux.
Tu ne peux pas comparer ce que tu coute un hébergement à une boîte standard qui achète du matos de grande marque et finance les marges de pas mal d'intermédiaires (hébergeur, constructeur, le prestataire du constructeur qui gère la garantie, le fournisseur de clim, ...), avec ce que coûte l'hébergement à une boite qui a des milliers de m2 de salle machines et plus de 100k serveurs, qui monte lui-même ses serveurs, gère ses stocks de pièces et automatise à mort la plupart de ses process.
L'effet d'échelle est monstrueux.
Ceci étant dit, je suis pas fana d'héberger un gros site avec des contraintes importantes chez OVH, mais, compte tenu du prix, le service rendu par OVH est assez impressionnant.
JFB
Euh, techniquement, un dédié, ca peut être un virtuel. Il est dédié à un client...
Le mardi 27 novembre 2012 13:47:44 Hugues Max a écrit :
je suis d'accord avec toi mais il y a des limites a tout. Le client a sa part de responsabilité, il achète des Mhz et des Giga, ces sociétés leur vendent des Mhz et des Giga... ( en trichant sur les chiffres au passage... , combien de société vendent du dédie pour du virtualisé en réalité ??? )
Le 27/11/2012 13:39, JF Bustarret a écrit :
une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)>>
un swith giga manageable de bonne marque
un bon firewall, un KVM ip
Ton calcul est faux.
Tu ne peux pas comparer ce que tu coute un hébergement à une boîte standard qui achète du matos de grande marque et finance les marges de pas mal d'intermédiaires (hébergeur, constructeur, le prestataire du constructeur qui gère la garantie, le fournisseur de clim, ...), avec ce que coûte l'hébergement à une boite qui a des milliers de m2 de salle machines et plus de 100k serveurs, qui monte lui-même ses serveurs, gère ses stocks de pièces et automatise à mort la plupart de ses process.
L'effet d'échelle est monstrueux.
Ceci étant dit, je suis pas fana d'héberger un gros site avec des contraintes importantes chez OVH, mais, compte tenu du prix, le service rendu par OVH est assez impressionnant.
JFB
Liste de diffusion du FRsAG http://www.frsag.org/
En regle générale, un dédié est un serveur physique dédié, pour du virtuel on parle plus de VPS (Virtual Private Server).
Pour Varnish, tout dépends des usages, mais dans l'ensemble nous en sommes trés content pour nos usages.
2012/11/27 Julien Gormotte julien@gormotte.info
Euh, techniquement, un dédié, ca peut être un virtuel. Il est dédié à un client...
Le mardi 27 novembre 2012 13:47:44 Hugues Max a écrit :
je suis d'accord avec toi mais il y a des limites a tout. Le client a sa part de responsabilité, il achète des Mhz et des Giga, ces sociétés leur vendent des Mhz et des Giga... ( en trichant sur les chiffres au passage... , combien de société vendent du dédie pour du virtualisé en réalité ??? )
Le 27/11/2012 13:39, JF Bustarret a écrit :
une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent
entre
2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais
disons
cher...)>>
un swith giga manageable de bonne marque
un bon firewall, un KVM ip
Ton calcul est faux.
Tu ne peux pas comparer ce que tu coute un hébergement à une boîte standard qui achète du matos de grande marque et finance les marges de pas mal d'intermédiaires (hébergeur, constructeur, le prestataire du constructeur qui gère la garantie, le fournisseur de clim, ...), avec
ce
que coûte l'hébergement à une boite qui a des milliers de m2 de salle machines et plus de 100k serveurs, qui monte lui-même ses serveurs,
gère
ses stocks de pièces et automatise à mort la plupart de ses process.
L'effet d'échelle est monstrueux.
Ceci étant dit, je suis pas fana d'héberger un gros site avec des contraintes importantes chez OVH, mais, compte tenu du prix, le service rendu par OVH est assez impressionnant.
JFB
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 27/11/2012 14:11, Sylvain RAMOUSSE a écrit :
En regle générale, un dédié est un serveur physique dédié, pour du virtuel on parle plus de VPS (Virtual Private Server).
Et comment considérer les clients qui ont leurs propres serveurs et pour qui on a installer une couche de virtualisation (on perd 3% de perf avec Xen ce qui est négligeable) pour pouvoir simplement et à distance faire des snapshots avant modifications, préparer la prochaine version d'os, avoir une image sauvegardée pour un retour plus rapide, ...
Pour le dernier point une bonne sauvegarde marche aussi mais c'est assez pratique en cas de machines avec que des petits fichiers, il est préférable de restaurer une grosse image que des petits fichiers.
Bref les loueurs d'infras il faut effectivement les utiliser sur ce à quoi ils sont bons. Je n'ai jamais vu de grosse infra (physique ou virtualisée), bien sécurisée (vlan, firewall, dmz multiples, ...) chez OVH. Au bout d'un moment soit les clients vont prendre plusieurs PCC pour séparer, soit ils font l'ancienne mode de un dédié ou VPS pour chaque usage à en faire passer en clair les flux non chiffré genre MySQL, ldap, ... Bref pour moi ce sont des accélérateurs de business pour les clients qui ont besoins d'une infra dédiée à moyen et long terme.
Après y a des clients qui n'ont pas besoin de plus et j'en suis aussi bien conscient et je travaille avec pas mal de clients dans ce cas. Certains n'ont même pas envie de failover et sont "presque" prêt à attendre qu'on leur change un disque, une alim, une carte mère. Je dis "presque" car les quelques clients que je n'ai pas réussi à convaincre d'une solution de sauvegarde qui me disent "4H c'est rapide, pas grave si le site ou l'applicatif ne répond pas" risquent de changer de discours quand ils verront que cela prend parfois plusieurs jours ou quand ils auront perdus leurs données car on leur aura réattribué un nouveau serveur sans changer les disques ...
Bonjour
Je m’immisce dans la conversation
Tu ne confonds pas GTR et GTI ??
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Hugues Max Envoyé : mardi 27 novembre 2012 13:11 À : frsag@frsag.org Objet : Re: [FRsAG] Conseil sur une architecture serveurs
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...) + un swith giga manageable de bonne marque + un bon firewall, un KVM ip +.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par exemple, il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69€/mois....chez OVH, Kimsufi, Amazon ou un autre du même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou-cosmonaute-1684.ht... )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit :
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables.
Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH, Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Une GTR 4h, si ca existe, ca doit couter bonbon. Voire le tarif de l'usine de bonbons directement :/
Le mardi 27 novembre 2012 15:34:07 Network Info Haillicourt a écrit :
Bonjour
Je m’immisce dans la conversation Tu ne confonds pas GTR et GTI ??
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Hugues Max Envoyé : mardi 27 novembre 2012 13:11 À : frsag@frsag.org Objet : Re: [FRsAG] Conseil sur une architecture serveurs
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...) + un swith giga manageable de bonne marque + un bon firewall, un KVM ip +.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par exemple, il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69€/mois....chez OVH, Kimsufi, Amazon ou un autre du même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou- cosmonaute-1684.htm )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit : Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables. Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH, Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Je confirme, le GTR 4h ça existe, en HO comme en HNO, et ça coute un bras. Les hébergeurs avec l’agrément "santé" ou "défense" le propose justement. Le 27/11/12 16:30, Julien Gormotte a écrit :
Une GTR 4h, si ca existe, ca doit couter bonbon. Voire le tarif de l'usine de bonbons directement :/
Le mardi 27 novembre 2012 15:34:07 Network Info Haillicourt a écrit :
Bonjour
Je m’immisce dans la conversation
Tu ne confonds pas GTR et GTI ??
De :frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part deHugues Max Envoyé :mardi 27 novembre 2012 13:11 À :frsag@frsag.org Objet :Re: [FRsAG] Conseil sur une architecture serveurs
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)
- un swith giga manageable de bonne marque
- un bon firewall, un KVM ip
+.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par exemple, il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69€/mois....chez OVH, Kimsufi, Amazon ou un autre du même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou-cosmonaute-1684.ht... )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit :
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables. Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était
sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH,
Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Oui, mais au niveau des constructeurs ? Des hébergeurs de données de santé/défense peuvent aussi avoir leur matos de spare (oui, meme des gros serveurs à très cher, chassis complet, en attente dans une baie au cas ou, du matos de remplacement pour toutes les pieces, des switches/firewalls etc... c'est pour ca que ca coute si cher)... Mais je sais pas si un constructeur le propose.
Le mardi 27 novembre 2012 16:37:03 Georges a écrit :
Je confirme, le GTR 4h ça existe, en HO comme en HNO, et ça coute un bras. Les hébergeurs avec l’agrément "santé" ou "défense" le propose justement.
Le 27/11/12 16:30, Julien Gormotte a écrit :
Une GTR 4h, si ca existe, ca doit couter bonbon. Voire le tarif de l'usine de bonbons directement :/
Le mardi 27 novembre 2012 15:34:07 Network Info Haillicourt a écrit :
Bonjour
Je m’immisce dans la conversation
Tu ne confonds pas GTR et GTI ??
De :frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part deHugues Max Envoyé :mardi 27 novembre 2012 13:11 À :frsag@frsag.org Objet :Re: [FRsAG] Conseil sur une architecture serveurs
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000€ HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000€ + 300/an +un bon sysadmin avec les charges et RTT coute 5000€/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)
- un swith giga manageable de bonne marque
- un bon firewall, un KVM ip
+.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par exemple, il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69€/mois....chez OVH, Kimsufi, Amazon ou un autre du même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou-cosmonaute-1684. htm )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit :
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables. Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais c'était
sur les anciens nas, les 2013 devraient être mieux (full ssd, ou hybrid pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout de quelque temps (1 à 3 ans en fonction du nombre de host) on a payé bien plus cher qu'une licence qu'on aurait acheté pour ses propres serveurs. Du coup le calcul en amortissement est plus rentable que la location à notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online, OVH,
Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du faire des restaurations de serveurs y a pas longtemps cela a prit une plombe, du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we, les serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du style vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont vierges... Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
Mes deux sous
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/
Bonjour,
Pour info,un article intéressant sur Varnish et HAProxy, sur le blog de la société Exceliance.
http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname...
Cette même société propose également sur son site, un bouquin sur le load balancing, intéressant aussi.
my 2 cents.
r2r
Oui, mais au niveau des constructeurs ? Des hébergeurs de données de santé/défense peuvent aussi avoir leur matos de spare (oui, meme des gros serveurs à très cher, chassis complet, en attente dans une baie au cas ou, du matos de remplacement pour toutes les pieces, des switches/firewalls etc... c'est pour ca que ca coute si cher)... Mais je sais pas si un constructeur le propose.
Le mardi 27 novembre 2012 16:37:03 Georges a écrit :
Je confirme, le GTR 4h ça existe, en HO comme en HNO, et ça coute un bras. Les hébergeurs avec lâagrément "santé" ou "défense" le propose justement.
Le 27/11/12 16:30, Julien Gormotte a écrit :
Une GTR 4h, si ca existe, ca doit couter bonbon. Voire le tarif de l'usine de bonbons directement :/
Le mardi 27 novembre 2012 15:34:07 Network Info Haillicourt a écrit :
Bonjour
Je mâimmisce dans la conversation
Tu ne confonds pas GTR et GTI ??
De :frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part deHugues Max Envoyé :mardi 27 novembre 2012 13:11 à :frsag@frsag.org Objet :Re: [FRsAG] Conseil sur une architecture serveurs
Bonjour je trouve les informaticiens d'une grande naïveté une Baie dans un datacenter coute entre 800/1000⬠HT mois +un bon serveur HP ou Dell avec les bonnes garanties GTR 4H coutent entre 2500/4000⬠+ 300/an +un bon sysadmin avec les charges et RTT coute 5000â¬/mois +100 Mbps de bande passante garantie coute ( je sais plus , mais disons cher...)
- un swith giga manageable de bonne marque
- un bon firewall, un KVM ip
+.. +... etc.. et encore, GTR 4H , cela veut dire intervention en 4h mais pas réparation ( si le diagnostic du constructeur est erroné par
exemple,
il faut a nouveau attendre les nouvelles pièces.)
et tout cela pour 69â¬/mois....chez OVH, Kimsufi, Amazon ou un autre
du
même acabits
Il faut être Demeuré ou Cosmonaute ( comme disait Pierre Desproges ) pour croire cela ( http://www.france-jeunes.net/lire-il-faut-etre-demeure-ou-cosmonaute-1684. htm )
Ces fournisseurs sont très bien MAIS il faut les utiliser pour ce qu'ils sont, ni plus ni moins.
Le 27/11/2012 12:16, Wallace a écrit :
Le 27/11/2012 12:03, JF Bustarret a écrit :
Pour avoir testé le cloud privé OVH (pcC), les I/O sont pas top (latences très importantes). Je pense qu'en cloud public, c'est pas forcément mieux, les archi devant être assez semblables. Je valide ces deux points avec un retour d'expérience :
- OVH en PCC ça marche, niveau IO c'est pas forcément top mais
c'était
sur les anciens nas, les 2013 devraient être mieux (full ssd, ou
hybrid
pour du cache write). Après personnellement je trouve cela bien trop cher, on paye la licence vmware en mensualisé ce qui fait qu'au bout
de
quelque temps (1 à 3 ans en fonction du nombre de host) on a payé
bien
plus cher qu'une licence qu'on aurait acheté pour ses propres
serveurs.
Du coup le calcul en amortissement est plus rentable que la location
Ã
notre avis.
- Amazon c'est juste une catastrohpe, débit ridicule depuis Online,
OVH,
Level3 ou Cogent seulement 4MB de BP en down comme en up. J'ai du
faire
des restaurations de serveurs y a pas longtemps cela a prit une
plombe,
du coup impossible de tenir une GTR 4H pour un gros volume.
Un client s'est fait planter comme il faut par Amazon, en plein we,
les
serveurs coupés, le lundi on apprend que la carte bleue n'était plus valide mais le client n'a jamais reçu de relance à ce sujet, du
style
vos services vont expirer car votre carte ne passe plus... Changement de carte fait, réactivation des services et mauvaise nouvelle, les snapshots des machines ont disparus et toutes les partitions autre que système (disques supplémentaires) sont
vierges...
Heureusement que les sauvegardes n'étaient pas faite chez Amazon...
Je passe la gestion réseau complètement loufoque on est derrière un
NAT,
la résolution de nom change en interne pour passer sur un adressage
en
10/8 c'est super pratique pour les règles firewall. A chaque
stop/start
changement d'ip sauf à prendre une option payante ...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web
scalable
pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait
pour
une architecture n tiers habituelle en entreprise.
Mes deux sous
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/
Le 27 novembre 2012 12:16, Wallace wallace@morkitu.org a écrit :
Je passe la gestion réseau complètement loufoque on est derrière un NAT,
la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Tu as mal lu la facturation, tu peux avoir une IP flottante, elle ne te coute rien. Enfin, si, elle est facturée si tu ne la rattaches à aucun serveur. Et cette IP là est fixe pour ton serveur.
Et si tu veux faire une archi n tiers, tu montes tes instances dans le VPC amazon, c'est justement fait pour ça. Tu choisis tes plages réseaux et tout. Et c'est pas plus cher (sauf si tu prends un VPN entre ton site et ton VPC).
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
C'est un peu plus vaste que ça, mais bon. Par contre, c'est clair que c'est pas adapté à tous les usages.
Y.
Bonjour,
Merci pour tous ces retours.
Je voulais rappeler que toute le code est en cours de refonte from scratch. C'est justement à l'occasion de la migration que l'on souhaite passer sur un hébergement plus fiable et plus scalable.
20K == 20 000 :D
Le souhait de quitter OVH est principalement leurs manque de sérieux sur des interventions "programmé" (annoncé 5 min avant sur une mailing list) qui plante une grande partie du réseau… ex: Y a un mois sur les switch; l'an dernier sur les routeurs. Ma direction ne comprend pas, on à un serveur vendu "haut de gamme". J'avais augmenté les ressources hardware pour palier le problème de perf le temps que les devs reprennent tout. Le code et l'archi de la DB etait mal conçus. (turn over de dev, pas de doc, forte croissance de l'activitée...)
Bref.
HAproxy est une bonne solution, on à déjà regardé un peu mais comment éviter un SPOF? seul l'hébergeur peut nous proposer du vrrp/carp (ou autre protocole proprio). Comme la dit Tarik il y a bien heartbeat mais j'avais trouvé ca un peut du bidouillage… Mais c'est plus moi que je vais remettre en cause ;)
On a moins regardé varnish on était plus partie sur du nginx pour le cache. Pour le static nous avons prévus de le délocaliser au moins sur sur un nom de domaine different et très facilement déplacable ailleurs.
Nayant pas de ferme de machine, la virtualisation me semble un peu démesuré même site ça nous apporte plus de souplesse sur la scalabilité.
Le choix de postgresql à été fait par notre responsable technique qui maitrisse cette techno. Et pour des modules tel que hstore ou PostGIS.
On est à 15hits/s. Pour les requetes SQL 46 req/s. Ces relevés ne sont pas trop de bon indicateur étant donnée que tout va être refait et donc optimisé. Au pire ca sera des valeurs max.
En tout cas j'y vois un peu plus clair je pense partir sur des machines physique. Après j'hésite un peu sur mettre du LB dés maintenant ou voir comment ca réagit avec un seul frontal…
sd
Le 27 novembre 2012 17:06, Yves Rougy yrougy@gmail.com a écrit :
Le 27 novembre 2012 12:16, Wallace wallace@morkitu.org a écrit :
Je passe la gestion réseau complètement loufoque on est derrière un NAT,
la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...
Tu as mal lu la facturation, tu peux avoir une IP flottante, elle ne te coute rien. Enfin, si, elle est facturée si tu ne la rattaches à aucun serveur. Et cette IP là est fixe pour ton serveur.
Et si tu veux faire une archi n tiers, tu montes tes instances dans le VPC amazon, c'est justement fait pour ça. Tu choisis tes plages réseaux et tout. Et c'est pas plus cher (sauf si tu prends un VPN entre ton site et ton VPC).
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.
C'est un peu plus vaste que ça, mais bon. Par contre, c'est clair que c'est pas adapté à tous les usages.
Y.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 27/11/2012 17:06, Yves Rougy a écrit :
Le 27 novembre 2012 12:16, Wallace <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Je passe la gestion réseau complètement loufoque on est derrière un NAT, la résolution de nom change en interne pour passer sur un adressage en 10/8 c'est super pratique pour les règles firewall. A chaque stop/start changement d'ip sauf à prendre une option payante ...Tu as mal lu la facturation, tu peux avoir une IP flottante, elle ne te coute rien. Enfin, si, elle est facturée si tu ne la rattaches à aucun serveur. Et cette IP là est fixe pour ton serveur.
Et si tu veux faire une archi n tiers, tu montes tes instances dans le VPC amazon, c'est justement fait pour ça. Tu choisis tes plages réseaux et tout. Et c'est pas plus cher (sauf si tu prends un VPN entre ton site et ton VPC).
Bonjour à expliquer à un client qu'il doit prendre plein d'options pour monter une simple architecture ... expliquer aux dev le réseau privé ... En face ils ont du ovh ou nous, ils ont leurs ip attribuées, coût fixe, options compréhensibles par un non technique.
Le gros souci d'Amazon en plus des soucis techniques, c'est qu'il est impossible de prévoir un budget pour une architecture donnée. Certes c'est du facturation à l'usage mais dans les faits les clients aiment savoir à l'avance, peu importe le pic de consommation ou autre. On nous a même demandé de facturer un forfait volontairement plus cher qu'Amazon pour qu'eux disposent d'un budget fixe ... on se serait retrouver à sous louer du EC2...
Bref je reste sur le fait qu'EC2 c'est fait pour les applis web scalable pilotée par du chief ou autre outils de déploiement automatique pour faire du "on demand" sur des points bien précis. Ce n'est pas fait pour une architecture n tiers habituelle en entreprise.C'est un peu plus vaste que ça, mais bon. Par contre, c'est clair que c'est pas adapté à tous les usages.
Vu les capacité IO disque et bande passante oui cela limite clairement les usages :D
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
a+
Le 27 nov. 2012 à 12:28, Baptiste a écrit :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
Et pas que pour du stateless, vu la souplesse de configuration (enfin, dans le cas de varnish, ce n'est plus de la config, c'est de la programmation).
C'est vrai que le load-balancing de varnish a des limitations (parfois surprenantes).
JFB
Le 27/11/2012 13:44, JF Bustarret a écrit :
Le 27 nov. 2012 à 12:28, Baptiste a écrit :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
Et pas que pour du stateless, vu la souplesse de configuration (enfin, dans le cas de varnish, ce n'est plus de la config, c'est de la programmation).
C'est vrai que le load-balancing de varnish a des limitations (parfois surprenantes).
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Et comment traitez vous les flux SSL dans ces deux cas ?
HA Proxy devant varnish !
On peut aussi avoir un setup : HA Proxy -> varnish > HA Proxy > httpd
JFB
Le 27 nov. 2012 à 16:36, Simon Morvan a écrit :
Le 27/11/2012 13:44, JF Bustarret a écrit :
Le 27 nov. 2012 à 12:28, Baptiste a écrit :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
Et pas que pour du stateless, vu la souplesse de configuration (enfin, dans le cas de varnish, ce n'est plus de la config, c'est de la programmation).
C'est vrai que le load-balancing de varnish a des limitations (parfois surprenantes).
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Et comment traitez vous les flux SSL dans ces deux cas ?
Liste de diffusion du FRsAG http://www.frsag.org/
tu peux laisser haproxy traiter le traffic ssl. Tarik CHICHANE
Le 27 novembre 2012 15:36, Simon Morvan garphy@zone84.net a écrit :
Le 27/11/2012 13:44, JF Bustarret a écrit :
Le 27 nov. 2012 à 12:28, Baptiste a écrit :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
Et pas que pour du stateless, vu la souplesse de configuration (enfin,
dans le cas de varnish, ce n'est plus de la config, c'est de la programmation).
C'est vrai que le load-balancing de varnish a des limitations (parfois
surprenantes).
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Et comment traitez vous les flux SSL dans ces deux cas ?
Liste de diffusion du FRsAG http://www.frsag.org/
pour haproxy / varnish, voici quelques réponses: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname...
HAProxy a des fonctionnalités très intéressantes pour être utilisé à la fois devant et derrière un cache (varnish, nginx, ATS, etc...).
Mais on sort du sujet de départ ;)
a+
2012/11/27 tarik chichane tarikchichane2006@gmail.com:
tu peux laisser haproxy traiter le traffic ssl. Tarik CHICHANE
Le 27 novembre 2012 15:36, Simon Morvan garphy@zone84.net a écrit :
Le 27/11/2012 13:44, JF Bustarret a écrit :
Le 27 nov. 2012 à 12:28, Baptiste a écrit :
1/ Les sites sont-ils majoritairement statiques ? si oui, comme dit précédemment => Varnish (BTW, Varnish est un excellent load balancer également) + ressources statiques sur un environnement dédié.
Je marcherai pas dans le troll, trop facile :) Varnish est un reverse proxy cache avec des fonctions basiques de load-balancing. Le fait qu'il soit excellent dans le caching n'en fait pas (malheureusement) un excellent LB. Ceci dit pour du stateless sur X serveurs en HTTP uniquement, ça suffit.
Et pas que pour du stateless, vu la souplesse de configuration (enfin, dans le cas de varnish, ce n'est plus de la config, c'est de la programmation).
C'est vrai que le load-balancing de varnish a des limitations (parfois surprenantes).
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Et comment traitez vous les flux SSL dans ces deux cas ?
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 27/11/2012 16:36, Simon Morvan a écrit :
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Net -> IPVS (en direct-routing) -> NGiNX -> Frontal NGiNX ou Apache ou lighttpd, mais je choisirais NGiNX pour simplifier.
Partage des sessions PHP via sharedance ou Redis.
2012/11/27 Gregory Duchatelet greg-frsag@duchatelet.net:
Le 27/11/2012 16:36, Simon Morvan a écrit :
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Net -> IPVS (en direct-routing) -> NGiNX -> Frontal NGiNX ou Apache ou lighttpd, mais je choisirais NGiNX pour simplifier.
Partage des sessions PHP via sharedance ou Redis.
En parlant de Sharedance, comment vous assurez la redondance de cette brique?
a+
cron qui rsync le tmpfs chaque minute, ça prend environ 1s pour 30k sessions, + heartbeat et ip virtuelle.
Mais depuis qu'il est en prod ~2008 on n'a eu aucun plantage, les seules bascules ont été volontaires (upgrade serveur...)
Greg
Le 27 novembre 2012 17:41, Baptiste bedis9@gmail.com a écrit :
2012/11/27 Gregory Duchatelet greg-frsag@duchatelet.net:
Le 27/11/2012 16:36, Simon Morvan a écrit :
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Net -> IPVS (en direct-routing) -> NGiNX -> Frontal NGiNX ou Apache ou lighttpd, mais je choisirais NGiNX pour simplifier.
Partage des sessions PHP via sharedance ou Redis.
En parlant de Sharedance, comment vous assurez la redondance de cette brique?
a+ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 27/11/2012 17:23, Gregory Duchatelet a écrit :
Le 27/11/2012 16:36, Simon Morvan a écrit :
Et tant qu'on y est, qu'est-ce qui emporte votre préférence chez vous :
Net -> HAProxy -> Varnish -> Frontal ou Net -> Varnish -> HAProxy -> Frontal
Net -> IPVS (en direct-routing) -> NGiNX -> Frontal NGiNX ou Apache ou lighttpd, mais je choisirais NGiNX pour simplifier.
Partage des sessions PHP via sharedance ou Redis.
En utilisant des machines virtuelles on peut faire sauter les ipvs
Net -> Nginx qui fait cache, LB, SSL -> frontal Nginx -> back PHP-FPM Sessions en memcachedb
Les VPS ne sont pas censés tomber, dans le doute on a un RR dns sur les différents reverse proxy avec un TTL à 30 min ce qui permet de changer assez rapidement si pour x raisons la vps ne peut pas être restaurée. Sachant que l'on aurait réattribué l'ip du vps down à une autre vps nginx reverse proxy.
Le 27/11/2012 18:12, JF Bustarret a écrit :
Les VPS ne sont pas censés tomber
Ouais, mais c'est toujours quand les choses qui sont pas censées tomber se mettent à tomber qu'on a des soucis :)
Disons que c'est plus facile à faire repartir, quand je vois des entreprises garantir 100% ou même 99% sur une année ce qui fait de tête entre 3 et 5h de coupure max, c'est juste impossible à tenir. J'en ai fait des entreprises différentes dans l'hébergement et l'infogérance, au final ce n'est que du discours commercial et ils prient pour pas que les clients demandent des pénalités ...
On 27/11/2012 19:39, Wallace wrote:
Disons que c'est plus facile à faire repartir, quand je vois des entreprises garantir 100% ou même 99% sur une année ce qui fait de tête entre 3 et 5h de coupure max, c'est juste impossible à tenir. J'en ai fait des entreprises différentes dans l'hébergement et l'infogérance, au final ce n'est que du discours commercial et ils prient pour pas que les clients demandent des pénalités ...
Comme c'est bien résumé. Les datacenters qui vendaient ça ont cessé. Certains nous bassinent encore avec leurs 5x9 mais personne n'y croit.
Les opérateurs IP présents sur les POPs Parisiens se gaussent des promesses de sécurité et de la surenchère aux portes tournantes, contrôles d'IRIS et autres conneries.
Si vous cherchez de la sécurité la réponse c'est la redondance, un réseau le plus indépendant possible du fournisseur (Gixe s'est très clairement orientés sur de la fibre qu'on annule nous-mêmes en la mutualisant avec d'autres opérateurs) et l'hébergement sur plusieurs datacenters.
Bref raisonnez backups, miroirs et résilience, mais les promesses n'engagent que ceux qui les croient.
Bonne soirée Sylvain
Le 27/11/2012 23:45, Sylvain Vallerot a écrit :
On 27/11/2012 19:39, Wallace wrote:
Disons que c'est plus facile à faire repartir, quand je vois des entreprises garantir 100% ou même 99% sur une année ce qui fait de tête entre 3 et 5h de coupure max, c'est juste impossible à tenir. J'en ai fait des entreprises différentes dans l'hébergement et l'infogérance, au final ce n'est que du discours commercial et ils prient pour pas que les clients demandent des pénalités ...
Pour de la monétique on ne doit pas être si éloigné que ça par rapport à ce type d'engagement... Sinon pour lire ces chiffres il y a des fois deux lectures possibles liées aux indisponibilités planifiées et celles non planifiées.
Cordialement,
Le 28/11/2012 00:07, Jean-Yves LENHOF a écrit :
Pour de la monétique on ne doit pas être si éloigné que ça par rapport à ce type d'engagement... Sinon pour lire ces chiffres il y a des fois deux lectures possibles liées aux indisponibilités planifiées et celles non planifiées.
Le souci c'est qu'on a beau mettre toutes les technologies possibles, toutes les sécurités, redondances sur un même site, on réduit le taux de panne mais on n'est vraiment pas à l'abri d'un gros pépin. Y a qu'à voir le nombre d'incident lié à une erreur humaine, mauvais bouton appuyé, mise en maintenance d'un élément qu'on pensait redondé mais où le mécanisme de bascule n'a pas fonctionné, ...
Même les tiers 4 se font avoir là dessus. Je veux bien croire que les banques et la monétique sont moins touchés, mais pour avoir entre aperçu l'architecture du réseau BNP, ben niveau résilience c'est quand même assez redondé. Ils ont surtout des budgets conséquents car les incidents sont classés par quantité d'argent perdu dans un temps donné. Ils parlent en millions / minute, donc acheter 5 serveurs à mettre dans plusieurs DC pour un applicatif non critique c'est monnaie courante chez eux.
Les non planifiées ne font jamais parti du taux d'indisponibilité. Cela me rappel une coupure électrique programmée chez Level3 Nanterre un we de fête de la musique, cela a duré duré :D
Le 28/11/2012 11:17, Wallace a écrit :
Le 28/11/2012 00:07, Jean-Yves LENHOF a écrit :
Pour de la monétique on ne doit pas être si éloigné que ça par rapport à ce type d'engagement... Sinon pour lire ces chiffres il y a des fois deux lectures possibles liées aux indisponibilités planifiées et celles non planifiées.
Le souci c'est qu'on a beau mettre toutes les technologies possibles, toutes les sécurités, redondances sur un même site, on réduit le taux de panne mais on n'est vraiment pas à l'abri d'un gros pépin. Y a qu'à voir le nombre d'incident lié à une erreur humaine, mauvais bouton appuyé, mise en maintenance d'un élément qu'on pensait redondé mais où le mécanisme de bascule n'a pas fonctionné, ...
Même les tiers 4 se font avoir là dessus. Je veux bien croire que les banques et la monétique sont moins touchés, mais pour avoir entre aperçu l'architecture du réseau BNP, ben niveau résilience c'est quand même assez redondé. Ils ont surtout des budgets conséquents car les incidents sont classés par quantité d'argent perdu dans un temps donné. Ils parlent en millions / minute, donc acheter 5 serveurs à mettre dans plusieurs DC pour un applicatif non critique c'est monnaie courante chez eux.
Et effectivement si tu parles réseau, le 100% redondé est certaines fois "virtuel". Souvent on redonde en utilisant deux opérateurs distincts pour assurer. Sauf que des fois les opérateurs se sous-traitent entre eux des tuyaux... Du coup on pense être super secure et en fait non... et la on est dans le...brin
Cdlt,
On 28/11/2012 13:03, jean-yves@lenhof.eu.org wrote:
Et effectivement si tu parles réseau, le 100% redondé est certaines fois "virtuel". Souvent on redonde en utilisant deux opérateurs distincts pour assurer. Sauf que des fois les opérateurs se sous-traitent entre eux des tuyaux... Du coup on pense être super secure et en fait non... et la on est dans le...brin
Le brin de fibre ? :-) Il y a beaucoup moins d'opérateurs qui détiennent de la fibre que d'opérateurs qui vendent des services (divers) dessus. Donc il faut distinguer en fonction du type de service.
Si vous cherchez une redondance sur un service allumé c'est une bonne idée de le demander à deux opérateurs différents parce que chacun responsable de son réseau actif, va faire user de la résilience de son propre réseau pour continuer à vous fournir le service. Vous serez protégés des pannés de type électrique ou équipement (alim) de livraison qui crame ou qui bug du fait d'avoir un autre prestataire. Mais ça ne vous dispense pas de vous intéresser à la qualité du réseau de transport proposé : le réseau en-dessous, comment est gérée la topologie, en combien de temps ça bascule.
Si vous avec besoin d'une redondance sur un service physique (fibre, lambda) il faut avoir la garantie que des aductions et des chemins indépendants sont utilisés, et c'est pas forcément plus facile avec deux prestataires différents.
-
Baptiste -
David RIBEIRO -
Georges -
Greg -
Gregory Duchatelet
-
Hugues Max -
Jean-Yves LENHOF -
jean-yves＠lenhof.eu.org
-
JF Bustarret -
Julien Gormotte -
Network Info Haillicourt -
Patrick Proniewski -
r2r＠altern.org -
SD76 -
Simon Morvan -
Sylvain Donnet -
Sylvain RAMOUSSE -
Sylvain Vallerot -
tarik chichane -
Wallace -
Yves Rougy