Bonjour, L'organisation pour lequel je travaille (établissement public) a développé une soixantaine de sites en technos PHP/MySql ou PHP/Oracle. Elles sont actuellement hébergées chez plusieurs hébergeurs sur une dizaine de machines. Chaque application dispose de son propre Virtual Host (www.appli.domain.fr). Nous souhaitons réintégrer l'ensemble des applications chez un hébergeur unique et revoir un peu l'archi technique. Nous avons environ 50000 visiteurs uniques/500000 pages vues par jour pour l'ensemble des applications. J'ai des notions en hébergement d'appli web mais je ne suis pas expert. On souhaite s'appuyer sur les compétences d'un hébergeur. Je souhaite décrire l'architecture cible attendue (qui serait redondée sur la prod). En m'inspirant de (1) et (2), j'imagine une architecture cible de ce type : * 1 filer (SAN) contenant l'ensemble des applications avec une décomposition par Virtual Host du type : /var/www/ ├── domain.fr │ ├── sous-domaine1 │ │ └── public_html │ ├── sous-domaine2 │ │ └── public_html │ ├── sous-domaine3 │ │ └── public_html │ └── sous-domaine3 │ └── public_html ├── domain2.fr └── domain3.fr * différents Frontaux Web avec des montages NFS sur le SAN * différents serveurs de base de données Un frontab web pouvant héberger N application. Chaque virtual host disposerait de son propre PHP (via php-fpm). Mon interrogation porte sur l'utilisation d'un SAN mutualisé à l'ensemble des frontaux web. Avez-vous déjà rencontré ce type d'archi chez certains hébergeurs ? Est-ce que c'est fiable ? Quid des performances ? Est-ce que le SAN pourrait également héberger les fichiers temporaires de l'application (fichier de logs Apache, fichiers générés par les applis - logs applicatifs, cache Smarty, ... - ) ? Si ce type d'architecture n'est pas conseillée, que préconiseriez-vous ? Un serveur dédié hébergeant quelques applications ? Merci pour vos retours, Bonne fin de semaine, François (1) http://publications.jbfavre.org/web/apache-vhosts-automatiques-avec-SSL-auth... (2) http://publications.jbfavre.org/web/php-fpm-apps-server-nginx.fr
bonjour je manage deja qlq systèmes de ce type pour de grosses boites pour ma part je met toujours 2 Firewall en redondance et partage de charge en frontal et derrière toute une série de serveurs Les firewall ont les ip publiques , ils font la répartition du trafic vers les serveurs, en round robin ou autre solution et ils détectent si un serveur est down pour ne plus envoyer du trafic vers ce serveur. ( en VRRP type openbsd ) Pour ce qui est du san, nas ou autre tout dépend de la perf. attendue - 500 000 pages/jour static c'est rien , mais 500 000 pages mal codées php3 , passées php4, puis en php5 a l'arach , c'est énorme Donc avant de savoir si il faut du san, du fiber channel , ou Mhz il faut faire un état de lieu précis et chiffré des tes applications php/mysql. Il y a plein d'outils pour cela sur le net, l'idée étant d'évaluer le nombre I/O nécessaire ( entrée/sortie ) et le débit - a partir de là , il faut choisir le matériel qui permet d'atteindre tes objectifs vl'a bye Hugues. Le 13/05/2011 14:47, François a écrit :
Bonjour,
L'organisation pour lequel je travaille (établissement public) a développé une soixantaine de sites en technos PHP/MySql ou PHP/Oracle. Elles sont actuellement hébergées chez plusieurs hébergeurs sur une dizaine de machines. Chaque application dispose de son propre Virtual Host (www.appli.domain.fr). Nous souhaitons réintégrer l'ensemble des applications chez un hébergeur unique et revoir un peu l'archi technique. Nous avons environ 50000 visiteurs uniques/500000 pages vues par jour pour l'ensemble des applications.
J'ai des notions en hébergement d'appli web mais je ne suis pas expert. On souhaite s'appuyer sur les compétences d'un hébergeur.
Je souhaite décrire l'architecture cible attendue (qui serait redondée sur la prod).
En m'inspirant de (1) et (2), j'imagine une architecture cible de ce type : * 1 filer (SAN) contenant l'ensemble des applications avec une décomposition par Virtual Host du type : /var/www/ ├── domain.fr │ ├── sous-domaine1 │ │ └── public_html │ ├── sous-domaine2 │ │ └── public_html │ ├── sous-domaine3 │ │ └── public_html │ └── sous-domaine3 │ └── public_html ├── domain2.fr └── domain3.fr * différents Frontaux Web avec des montages NFS sur le SAN * différents serveurs de base de données
Un frontab web pouvant héberger N application. Chaque virtual host disposerait de son propre PHP (via php-fpm).
Mon interrogation porte sur l'utilisation d'un SAN mutualisé à l'ensemble des frontaux web. Avez-vous déjà rencontré ce type d'archi chez certains hébergeurs ? Est-ce que c'est fiable ? Quid des performances ? Est-ce que le SAN pourrait également héberger les fichiers temporaires de l'application (fichier de logs Apache, fichiers générés par les applis - logs applicatifs, cache Smarty, ... - ) ? Si ce type d'architecture n'est pas conseillée, que préconiseriez-vous ? Un serveur dédié hébergeant quelques applications ?
Merci pour vos retours,
Bonne fin de semaine, François
(1) http://publications.jbfavre.org/web/apache-vhosts-automatiques-avec-SSL-auth... (2) http://publications.jbfavre.org/web/php-fpm-apps-server-nginx.fr _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 13 mai 2011 15:16, hugues Max <huguesmax@gmail.com> a écrit :
bonjour je manage deja qlq systèmes de ce type pour de grosses boites
pour ma part je met toujours 2 Firewall en redondance et partage de charge en frontal et derrière toute une série de serveurs Les firewall ont les ip publiques , ils font la répartition du trafic vers les serveurs, en round robin ou autre solution et ils détectent si un serveur est down pour ne plus envoyer du trafic vers ce serveur. ( en VRRP type openbsd )
C'est le firewall qui s'occupe de la répartition des charges. Je ne savais pas que les firewall pouvaient jouer ce rôle. Pour l'équilibrage de charge, on utilise en général un équipement dédié.
Pour ce qui est du san, nas ou autre tout dépend de la perf. attendue - 500 000 pages/jour static c'est rien , mais 500 000 pages mal codées php3 , passées php4, puis en php5 a l'arach , c'est énorme
C'est du PHP5 (Zend Framework, Joomla, dotclear) ou PHP4 (codés à l'arrache). Si on met un APC ou cache d'opcode, est-ce que cela peut soulager le SAN étant donné que le code de l'appli sera chargé en mémoire ? N.B : j'ai dû mal à cerner dans quelles conditions, on prend un SAN ou un NAS ;-)
Donc avant de savoir si il faut du san, du fiber channel , ou Mhz il faut faire un état de lieu précis et chiffré des tes applications php/mysql. Il y a plein d'outils pour cela sur le net, l'idée étant d'évaluer le nombre I/O nécessaire ( entrée/sortie ) et le débit - a partir de là , il faut choisir le matériel qui permet d'atteindre tes objectifs
Tu pourrais m'aiguiller sur les outils permettant d'évaluer ça ? Merci pour ta réponse, bonne journée, François
Hello, Le 13 mai 2011 à 15:24, frantishrek a écrit :
Le 13 mai 2011 15:16, hugues Max <huguesmax@gmail.com> a écrit :
bonjour je manage deja qlq systèmes de ce type pour de grosses boites
pour ma part je met toujours 2 Firewall en redondance et partage de charge en frontal et derrière toute une série de serveurs Les firewall ont les ip publiques , ils font la répartition du trafic vers les serveurs, en round robin ou autre solution et ils détectent si un serveur est down pour ne plus envoyer du trafic vers ce serveur. ( en VRRP type openbsd )
C'est le firewall qui s'occupe de la répartition des charges. Je ne savais pas que les firewall pouvaient jouer ce rôle. Pour l'équilibrage de charge, on utilise en général un équipement dédié.
En général j'aime bien avoir 2 couches : - firewall - load balancer Car un truc qui fait les 2... = possibilités d'emmerdes... surtout si c'est du propriétaire. L'exception : OpenBSD + Relayd + CARP + PF.
Pour ce qui est du san, nas ou autre tout dépend de la perf. attendue - 500 000 pages/jour static c'est rien , mais 500 000 pages mal codées php3 , passées php4, puis en php5 a l'arach , c'est énorme
C'est du PHP5 (Zend Framework, Joomla, dotclear) ou PHP4 (codés à l'arrache). Si on met un APC ou cache d'opcode, est-ce que cela peut soulager le SAN étant donné que le code de l'appli sera chargé en mémoire ?
N.B : j'ai dû mal à cerner dans quelles conditions, on prend un SAN ou un NAS ;-)
Pour le SAN tu es en général en direct attached (FCaL, FCoE, iSCSI, ...) donc a part si tu as un filesystem qui peux être partagé comme VMFS de VMWare ESX, tu vas te trouver avec des pb de consistance de FS. Surtout dans le cas du web, un NAS me semble plus "intelligent" :)
Donc avant de savoir si il faut du san, du fiber channel , ou Mhz il faut faire un état de lieu précis et chiffré des tes applications php/mysql. Il y a plein d'outils pour cela sur le net, l'idée étant d'évaluer le nombre I/O nécessaire ( entrée/sortie ) et le débit - a partir de là , il faut choisir le matériel qui permet d'atteindre tes objectifs
Tu pourrais m'aiguiller sur les outils permettant d'évaluer ça ?
Merci pour ta réponse, bonne journée, François _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour comme l'a dit Xavier, je fais du Openbsd+carp+pf c'est super efficace, et j'ai des firewall qui tournent depuis plusieurs années sans pb si tu utilises apache comme serveur web regardes http://httpd.apache.org/docs/2.0/programs/ab.html avec un parallèle des outils comme iostat http://www.drzz.net/articles.php?id=80 l'idée étant de te faire un abaque par application et d'avoir une moyenne appli1 = x pages = X ressources/page Puis de faire la somme de tout cela, puis de multiplié par X si tu prévois une augmentation - cela va te donner un débit nécessaire et un nombre entrée/sortie puis il faut faire un appel d'offre avec ces infos pour l'hebergement ou pour le Hardware ( les commerciaux de chez Computa Center savent très bien faire cela ) X sites X espace disk X debit internet X I/O par NAS ou SAN ou ce que tu veux X en GTR ( garantie de temps de rétablissement ) vl'a bye Hugues Le 13/05/2011 15:24, frantishrek a écrit :
Le 13 mai 2011 15:16, hugues Max<huguesmax@gmail.com> a écrit :
bonjour je manage deja qlq systèmes de ce type pour de grosses boites
pour ma part je met toujours 2 Firewall en redondance et partage de charge en frontal et derrière toute une série de serveurs Les firewall ont les ip publiques , ils font la répartition du trafic vers les serveurs, en round robin ou autre solution et ils détectent si un serveur est down pour ne plus envoyer du trafic vers ce serveur. ( en VRRP type openbsd ) C'est le firewall qui s'occupe de la répartition des charges. Je ne savais pas que les firewall pouvaient jouer ce rôle. Pour l'équilibrage de charge, on utilise en général un équipement dédié.
Pour ce qui est du san, nas ou autre tout dépend de la perf. attendue - 500 000 pages/jour static c'est rien , mais 500 000 pages mal codées php3 , passées php4, puis en php5 a l'arach , c'est énorme C'est du PHP5 (Zend Framework, Joomla, dotclear) ou PHP4 (codés à l'arrache). Si on met un APC ou cache d'opcode, est-ce que cela peut soulager le SAN étant donné que le code de l'appli sera chargé en mémoire ?
N.B : j'ai dû mal à cerner dans quelles conditions, on prend un SAN ou un NAS ;-)
Donc avant de savoir si il faut du san, du fiber channel , ou Mhz il faut faire un état de lieu précis et chiffré des tes applications php/mysql. Il y a plein d'outils pour cela sur le net, l'idée étant d'évaluer le nombre I/O nécessaire ( entrée/sortie ) et le débit - a partir de là , il faut choisir le matériel qui permet d'atteindre tes objectifs Tu pourrais m'aiguiller sur les outils permettant d'évaluer ça ?
Merci pour ta réponse, bonne journée, François _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :) c'est : - trop cher - peu scalable - pas distribué Aujourd'hui en 2011, il y a plein de bonnes choses pour faire une belle archi web bien propre... hdfs, voldemort, reddis, varnish, etc... Ton problème, c'est que c'est déjà developpé, et qu'ils ont pris un modèle très peu distribuable (sql/oracle). Tu n'as pas de coupure protocolaire sur ton archi ? genre reverse proxy (haproxy par exemple), etc ? ça me semble dangereux ... 2011/5/13 François <frantishrek@gmail.com>:
Bonjour,
L'organisation pour lequel je travaille (établissement public) a développé une soixantaine de sites en technos PHP/MySql ou PHP/Oracle. Elles sont actuellement hébergées chez plusieurs hébergeurs sur une dizaine de machines. Chaque application dispose de son propre Virtual Host (www.appli.domain.fr). Nous souhaitons réintégrer l'ensemble des applications chez un hébergeur unique et revoir un peu l'archi technique. Nous avons environ 50000 visiteurs uniques/500000 pages vues par jour pour l'ensemble des applications.
J'ai des notions en hébergement d'appli web mais je ne suis pas expert. On souhaite s'appuyer sur les compétences d'un hébergeur.
Je souhaite décrire l'architecture cible attendue (qui serait redondée sur la prod).
En m'inspirant de (1) et (2), j'imagine une architecture cible de ce type : * 1 filer (SAN) contenant l'ensemble des applications avec une décomposition par Virtual Host du type : /var/www/ ├── domain.fr │ ├── sous-domaine1 │ │ └── public_html │ ├── sous-domaine2 │ │ └── public_html │ ├── sous-domaine3 │ │ └── public_html │ └── sous-domaine3 │ └── public_html ├── domain2.fr └── domain3.fr * différents Frontaux Web avec des montages NFS sur le SAN * différents serveurs de base de données
Un frontab web pouvant héberger N application. Chaque virtual host disposerait de son propre PHP (via php-fpm).
Mon interrogation porte sur l'utilisation d'un SAN mutualisé à l'ensemble des frontaux web. Avez-vous déjà rencontré ce type d'archi chez certains hébergeurs ? Est-ce que c'est fiable ? Quid des performances ? Est-ce que le SAN pourrait également héberger les fichiers temporaires de l'application (fichier de logs Apache, fichiers générés par les applis - logs applicatifs, cache Smarty, ... - ) ? Si ce type d'architecture n'est pas conseillée, que préconiseriez-vous ? Un serveur dédié hébergeant quelques applications ?
Merci pour vos retours,
Bonne fin de semaine, François
(1) http://publications.jbfavre.org/web/apache-vhosts-automatiques-avec-SSL-auth... (2) http://publications.jbfavre.org/web/php-fpm-apps-server-nginx.fr _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Le 13 mai 2011 16:13, Steven Le Roux <steven@le-roux.info> a écrit :
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :)
c'est :
- trop cher - peu scalable - pas distribué
A priori, au vu des réponses, cela semble l'orientation globale. Si je résume, vous ne conseillez donc pas de disposer d'un espace disque partagé à l'ensemble des applications. Vous préconisez de stocker les applications sur chaque frontal ?
Aujourd'hui en 2011, il y a plein de bonnes choses pour faire une belle archi web bien propre... hdfs, voldemort, reddis, varnish, etc...
Je ne connais pas très bien ces technos. Ok pour conserver les sessions avec des bases clé-valeur (voldemort, redis ou memcached) mais quant est-il des données partagées dans le cas de plusieurs frontaux webs ? C'est le rôle que peut jouer hdfs ?
Ton problème, c'est que c'est déjà developpé, et qu'ils ont pris un modèle très peu distribuable (sql/oracle).
(sourire)
Tu n'as pas de coupure protocolaire sur ton archi ? genre reverse proxy (haproxy par exemple), etc ? ça me semble dangereux ...
Je ne connais pas bien haproxy. Je ne suis pas sûre de bien comprendre. L'objectif est de disposer d'une infra redondée avec un équipement dédié. Merci pour la réponse. Grâce à ton message, j'ai appris plein de nouveaux mots (redis, voldemort, hdfs) ;-)
Bonjour, Le 13/05/2011 17:01, frantishrek a écrit :
Le 13 mai 2011 16:13, Steven Le Roux <steven@le-roux.info> a écrit :
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :)
c'est :
- trop cher - peu scalable - pas distribué A priori, au vu des réponses, cela semble l'orientation globale. Si je résume, vous ne conseillez donc pas de disposer d'un espace disque partagé à l'ensemble des applications. Vous préconisez de stocker les applications sur chaque frontal ? Cela dépend de ton niveau d'I/O, de la quantité de RAM de tes frontaux (pour le cache) et de plein de choses. Par exemple, stocker en NFS du contenu comme des images pour que ces dernières soient délivrables par plusieurs frontaux en même temps, cela a du sens. :)
Tu peux aussi imaginer de tout stocker sur un filer et d'avoir des frontaux en diskless boot pxe... Il y a plein de solutions, il faut juste que tu trouves celle qui te convient. :) Je te mettrais juste en garde sur une chose, il faut éviter de faire trop d'écritures en NFS. Car si tu es tout sur le NFS y compris l'OS, si le filer rame, tu as tout qui rame... On peut aussi avoir des systèmes mixte, OS et conf sur le disque du frontal, data sur NFS... Bon courage. :)
C'est une archi assez courante que tu recherche. Basiquement, dans l'ordre, du plus proche du browser au plus éloigné : Couche 1 : Load balancing : Avec 500K vue/jour, un Pentium 4 avec IPVSadm saurait faire l'affaire Couche 2 : Les frontaux web : Des machines identiques, fut-ce t'elle Diskless ou non, avec l'apache/php/whatever the techno classique. Couche 3-3bis : - SQL Dédié + - NFS Dédié. Pour ce qui est des contraintes : - Les serveurs web doivent pouvoir partager les sessions. A voir avec l'appli web (genre stocker les sessions en db sur le SQL, dans un memcached caché sur le SQL, ou via un daemon sharedanced... etc). - Pour ce qui est de la haute disponibilité : -- Elle est aquise de fait sur la couche des frontaux web : Si un frontal web tombe, il doit sortir du cluster et le LVS doit l'oublier. Les performances sont amoindries, pas la disponibilité. -- Pour le Load balancer, un jumeaux et un coup de heartbeat avec une IP Failover suffit. -- Pour le SQL, de la replication master/slave ou master/master et un coup de heartbeat avec une IP Failover suffit. -- Pour le NFS, de la réplication (Y'a un millions de techno la...ca va de drbd a la réplication de pauvre a coup de Rsync permanent), et du heartbeat, encore. Avec ca on obtient du HA a tout les niveau, et une architecture relativement scalable au niveau des web. La scalabilité du Filer NFS et du SQL est une autre problématique apres... La partie firewalling est plus que presque inutile a ce niveau la : - Les loadbalancer doivent agir comme des routeurs et redistribuer la charge, pas de distinction de protocole ou quoi. Pas de raison de mettre un firewall a moins d'avoir des contraintes tres precises. - Les seuls a avoir une ou des IP publique la dedans sont les load balancer. Ces memes IP publiquent se retrouveront sur la loopback des Frontaux web, pour la répartirion de charge. - Tout le reste peut communiquer sur des ip privées, dans des VLAN privés. - Si au milieu de ca on respecte les bases de sécurité d'avoir des services maintenus a jours, patchés, et rien d'ouvert qui n'ai pas un besoin express de l'etre, le firewall devant tout ca est a mon sens inutile. - Au pire du pire, trois bout d'iptables et/ou de PF font l'affaire. Quant aux variantes, on peut load balancer avec du varnish par exemple au lieu du LVS (Couche 7 au lieu de couche3), ce qui permettra d'éliminer facilement 95% des acces NFS, mais nécessite des configuration fine en fonctions des spécifités des codes applicatif derriere. C'est pas la meme vision des choses. Dans le genre variantes aussi, on peut imaginer du HA assuré par des techno de virtualisation, on peut imaginer une "foret" de SQL ou sont réparties les bases, voit les tables, etc. Le 13 mai 2011 à 17:01, frantishrek a écrit :
Le 13 mai 2011 16:13, Steven Le Roux <steven@le-roux.info> a écrit :
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :)
c'est :
- trop cher - peu scalable - pas distribué
A priori, au vu des réponses, cela semble l'orientation globale. Si je résume, vous ne conseillez donc pas de disposer d'un espace disque partagé à l'ensemble des applications. Vous préconisez de stocker les applications sur chaque frontal ?
Aujourd'hui en 2011, il y a plein de bonnes choses pour faire une belle archi web bien propre... hdfs, voldemort, reddis, varnish, etc...
Je ne connais pas très bien ces technos. Ok pour conserver les sessions avec des bases clé-valeur (voldemort, redis ou memcached) mais quant est-il des données partagées dans le cas de plusieurs frontaux webs ? C'est le rôle que peut jouer hdfs ?
Ton problème, c'est que c'est déjà developpé, et qu'ils ont pris un modèle très peu distribuable (sql/oracle).
(sourire)
Tu n'as pas de coupure protocolaire sur ton archi ? genre reverse proxy (haproxy par exemple), etc ? ça me semble dangereux ...
Je ne connais pas bien haproxy. Je ne suis pas sûre de bien comprendre. L'objectif est de disposer d'une infra redondée avec un équipement dédié.
Merci pour la réponse. Grâce à ton message, j'ai appris plein de nouveaux mots (redis, voldemort, hdfs) ;-) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
--- Colin Brigato colin@brigato.fr
2011/5/13 frantishrek <frantishrek@gmail.com>:
Le 13 mai 2011 16:13, Steven Le Roux <steven@le-roux.info> a écrit :
J'aurais tendance à dire, pour le web : pas de SAN ! ! ! :)
c'est :
- trop cher - peu scalable - pas distribué
A priori, au vu des réponses, cela semble l'orientation globale. Si je résume, vous ne conseillez donc pas de disposer d'un espace disque partagé à l'ensemble des applications. Vous préconisez de stocker les applications sur chaque frontal ?
Ah non, mais je pense qu'on se s'entend pas sur la notion de frontal. Pour moi le frontal est un reverse proxy, dans grande intelligence, (à part la gestion de l'affinité de session), et derriere il y a les backend (serveur d'appli).
Aujourd'hui en 2011, il y a plein de bonnes choses pour faire une belle archi web bien propre... hdfs, voldemort, reddis, varnish, etc...
Je ne connais pas très bien ces technos. Ok pour conserver les sessions avec des bases clé-valeur (voldemort, redis ou memcached) mais quant est-il des données partagées dans le cas de plusieurs frontaux webs ? C'est le rôle que peut jouer hdfs ?
Oui hdfs peut jouer ce rôle. Mais il est d'autant plus utile si les appli savent faire du map/reduce, où qu'elles aient besoin de stocker dans un format clé/valeur/valeur selon le modèle de bigtable (hbase).
Ton problème, c'est que c'est déjà developpé, et qu'ils ont pris un modèle très peu distribuable (sql/oracle).
(sourire)
Tu n'as pas de coupure protocolaire sur ton archi ? genre reverse proxy (haproxy par exemple), etc ? ça me semble dangereux ...
Je ne connais pas bien haproxy. Je ne suis pas sûre de bien comprendre. L'objectif est de disposer d'une infra redondée avec un équipement dédié.
oui ça n’empêche pas. c'est juste qu'il vaut mieux séparer les couches, et mettre le produit qui fait le mieux une chose pour faite cette chose, plutôt qu'un truc à tout faire. (C'est mon avis).
Merci pour la réponse. Grâce à ton message, j'ai appris plein de nouveaux mots (redis, voldemort, hdfs) ;-)
tant mieux :)
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Bonjour,
L'organisation pour lequel je travaille (établissement public) a développé une soixantaine de sites en technos PHP/MySql ou PHP/Oracle. Elles sont actuellement hébergées chez plusieurs hébergeurs sur une dizaine de machines. Chaque application dispose de son propre Virtual Host (www.appli.domain.fr). Nous souhaitons réintégrer l'ensemble des applications chez un hébergeur unique et revoir un peu l'archi technique. Nous avons environ 50000 visiteurs uniques/500000 pages vues par jour pour l'ensemble des applications.
J'ai des notions en hébergement d'appli web mais je ne suis pas expert. On souhaite s'appuyer sur les compétences d'un hébergeur.
Je souhaite décrire l'architecture cible attendue (qui serait redondée sur la prod).
En m'inspirant de (1) et (2), j'imagine une architecture cible de ce type : * 1 filer (SAN) contenant l'ensemble des applications avec une décomposition par Virtual Host du type : /var/www/ âââ domain.fr â  âââ sous-domaine1 â â âââ public_html â  âââ sous-domaine2 â â âââ public_html â  âââ sous-domaine3 â  â  âââ public_html â  âââ sous-domaine3 â  âââ public_html âââ domain2.fr âââ domain3.fr * différents Frontaux Web avec des montages NFS sur le SAN * différents serveurs de base de données
Un frontab web pouvant héberger N application. Chaque virtual host disposerait de son propre PHP (via php-fpm).
Mon interrogation porte sur l'utilisation d'un SAN mutualisé à l'ensemble des frontaux web. Avez-vous déjà rencontré ce type d'archi chez certains hébergeurs ? Est-ce que c'est fiable ? Quid des performances ? Est-ce que le SAN pourrait également héberger les fichiers temporaires de l'application (fichier de logs Apache, fichiers générés par les applis - logs applicatifs, cache Smarty, ... - ) ? Si ce type d'architecture n'est pas conseillée, que préconiseriez-vous ? Un serveur dédié hébergeant quelques applications ?
Déjà dans ton cas il faut partir sur du NAS et pas du SAN. Ensuite tu sembles être dans une architecture 3 tiers classique Les questions à se poser sont : - système haute-disponibilité ou partage de charge + haute dispo ou rien - comment faire la répartition de charge et/ou la redondance au différents étages (étage web, appli, bd, stockage) - la question qui n'est jamais posée : si on veut de la répartition de charge est-ce que l'applicatif le supporte (synchronisation des sessions & co) Enfin l'audience des sites ne paraît pas phénoménale donc suivant la qualité du code de l'appli la partie dimensionnement de chaque étage ne devrait pas être un problème. ++ David
Merci pour vos retours,
Bonne fin de semaine, François
(1) http://publications.jbfavre.org/web/apache-vhosts-automatiques-avec-SSL-auth... (2) http://publications.jbfavre.org/web/php-fpm-apps-server-nginx.fr _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (8)
-
Colin Brigato -
David Amiel -
David B. -
frantishrek -
François
-
hugues Max -
Steven Le Roux -
Xavier Beaudouin