je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy pour faire du load balancing sur les deux autres serveurs (B et C). B Requete WWW -> A (mod_proxy) -> C
Il existe 2 types d'users. Dans le cas present l'update des pages se ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a une idée ?
PS : Actuellement les stats donnent a peu pres 274000 hits/j et 11164153 KBytes/j, pour une seule machine :)
Panic
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy
pour faire du load balancing sur les deux autres serveurs (B et C).
B
Requete WWW -> A (mod_proxy) ->
C
Il existe 2 types d'users. Dans le cas present l'update des pages se
ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste
ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a
une idée ?
PS : Actuellement les stats donnent a peu pres 274000 hits/j et 11164153
KBytes/j, pour une seule machine :)
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy pour faire du load balancing sur les deux autres serveurs (B et C). B Requete WWW -> A (mod_proxy) -> C
Il existe 2 types d'users. Dans le cas present l'update des pages se ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a une idée ?
PS : Actuellement les stats donnent a peu pres 274000 hits/j et 11164153 KBytes/j, pour une seule machine :)
Panic
patpro
In article <3f7dea2c$0$20951$, Panic wrote:
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy pour faire du load balancing sur les deux autres serveurs (B et C). B Requete WWW -> A (mod_proxy) -> C
Il existe 2 types d'users. Dans le cas present l'update des pages se ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a une idée ?
aucune idée non plus sur les résultats. Mais à ta place je tenterais de mettre quelque chose d'un peu plus transparent pour le proxy qu'un Apache+mod_proxy. J'ai pas d'idée lumineuse là comme ça, mais probablement qu'un round-robin dans ipnat sur la machine A te donnerait à la fois plus de fiabilité et plus de rapidité. Mon expérience m'a montré qu'en certaines occasions le mod_proxy d'apache fait un peu le délicat.
D'un autre coté c'est sur que la config que tu décris te permet de loguer tout sur la machine A et meme de faire ton traitement de stat directement dessus.
patpro
In article <3f7dea2c$0$20951$7a628cd7@news.club-internet.fr>,
Panic <panic@nospam.no> wrote:
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy
pour faire du load balancing sur les deux autres serveurs (B et C).
B
Requete WWW -> A (mod_proxy) ->
C
Il existe 2 types d'users. Dans le cas present l'update des pages se
ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste
ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a
une idée ?
aucune idée non plus sur les résultats. Mais à ta place je tenterais de
mettre quelque chose d'un peu plus transparent pour le proxy qu'un
Apache+mod_proxy. J'ai pas d'idée lumineuse là comme ça, mais
probablement qu'un round-robin dans ipnat sur la machine A te donnerait
à la fois plus de fiabilité et plus de rapidité.
Mon expérience m'a montré qu'en certaines occasions le mod_proxy
d'apache fait un peu le délicat.
D'un autre coté c'est sur que la config que tu décris te permet de
loguer tout sur la machine A et meme de faire ton traitement de stat
directement dessus.
Pour reprendre un peu le sujet, j'immagines la solution suivante
3 serveurs FreeBSD, le premier en front (A) avec apache et le mod_proxy pour faire du load balancing sur les deux autres serveurs (B et C). B Requete WWW -> A (mod_proxy) -> C
Il existe 2 types d'users. Dans le cas present l'update des pages se ferait par FTP, le groupe de A sur A et le B sur B. Je n'ai jamais teste ca et je ne connais pas les resultats de ce genre de truc. Quelqu'un a une idée ?
aucune idée non plus sur les résultats. Mais à ta place je tenterais de mettre quelque chose d'un peu plus transparent pour le proxy qu'un Apache+mod_proxy. J'ai pas d'idée lumineuse là comme ça, mais probablement qu'un round-robin dans ipnat sur la machine A te donnerait à la fois plus de fiabilité et plus de rapidité. Mon expérience m'a montré qu'en certaines occasions le mod_proxy d'apache fait un peu le délicat.
D'un autre coté c'est sur que la config que tu décris te permet de loguer tout sur la machine A et meme de faire ton traitement de stat directement dessus.
patpro
Benjamin Pineau
Le Thu, 2 Oct 2003 14:21:47 +0200, Panic écrivais:
Hello,
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
Qqun a une idée ? :)
* Choix de l'OS
À titre d'apréciation très subjective.
Les 3 BSDs libres supportent parfaitement les fortes charges mais le choix de l'un d'eux n'est pas indifférent.
FreeBSD est très performant et supporte le SMP sur pc. Mais il est largement plus « disparate » (bordélique ? linuxomorphe ?) que les deux autres: ports qui peuvent ne pas compiler, kernel par défault pas très bien senti, ports qui peuvent installer n'importe quoi n'importe où (/usr/local/etc, /var/qmail, ...), évolution un peu figée de la branche 4.* (alors que la branche 5.* est très instable et plus bordélique que jamais), arbre des sources fréquement cassé etc.
OpenBSD et NetBSD sont (à mon gout) à l'inverse très cohérents, simples, propres: en deux mots, « admin friendlys ». En un mot: maintenables.
Cependant OpenBSD est ultra lent (comparez son fs à celui des autres BSD ou aux divers fs linux, c'est incroyable !) et ne supporte pas le SMP (j' imagine que tu envisage d'utiliser une machine multiprocesseurs ?) car avec cet OS, la sécurité prévaut toujours sur les performances (utilisation de propolice par exemple).
NetBSD pour sa part représente un bon compromis. Petit défault à mon gout, il semble encore chercher son modèle de threading, ce qui peut poser des petits problèmes (par exemple avec mysql, sous 1.6.1). Ce problème est parait-il résolu dans -current...
Bref, dans ton cas, j'utiliserai de préférence un snapshot récent de NetBSD (tout en prenant le temps de m'assurer qu'il fonctionne bien) ou bien un FreeBSD 4.*.
* Répartition de la charge
Le plus simple est sans doute de répartir les comptes utilisateurs sur différentes machines, mais celà ne te permettra pas de disposer d'un mécanisme de tolérance aux pannes. La gestion du failover pour le www/ssh/scp/ftp est assez simple. Tu peut faire du mirorring (rsync, fam/imon, coda ...) des données et distribuer les requètes (vrrp, round-robin à partir des dns ou d'un routeur/firewall, proxy, ...). En revanche, si tes utilisateurs utilisent aussi des bases de données bon marché (mysql, postgreesql), les choses se compliquent car il est difficile d'obtenir une réplication bidirectionnelle dans ce cas, et la solution simple (répartion des comptes sur plusieurs machines, sans mécanisme de failover) s'impose (à moins que tu ne préfère scripter de fragiles bricolages ...). Ou, à titre d'alternative, une seule machine très puissante (celà devrait suffir dans ton cas) répliquée sur une seconde machine (éventuellement moins puissante) qui n'est utilisée qu'en cas de panne de la première. Et gestion semi manuelle du retour de la première (resynchronisation des bdd et des fichiers). Celà peut aussi fonctionner en repliquant un groupe de machines sur un groupes de miroirs bien entendu.
Le Thu, 2 Oct 2003 14:21:47 +0200,
Panic <panic@nospam.no> écrivais:
Hello,
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.
Qqun a une idée ? :)
* Choix de l'OS
À titre d'apréciation très subjective.
Les 3 BSDs libres supportent parfaitement les fortes charges mais le choix de
l'un d'eux n'est pas indifférent.
FreeBSD est très performant et supporte le SMP sur pc. Mais il est
largement plus « disparate » (bordélique ? linuxomorphe ?) que les deux autres:
ports qui peuvent ne pas compiler, kernel par défault pas très bien senti,
ports qui peuvent installer n'importe quoi n'importe où (/usr/local/etc,
/var/qmail, ...), évolution un peu figée de la branche 4.* (alors que la
branche 5.* est très instable et plus bordélique que jamais), arbre des
sources fréquement cassé etc.
OpenBSD et NetBSD sont (à mon gout) à l'inverse très cohérents, simples,
propres: en deux mots, « admin friendlys ». En un mot: maintenables.
Cependant OpenBSD est ultra lent (comparez son fs à celui des autres BSD ou
aux divers fs linux, c'est incroyable !) et ne supporte pas le SMP (j'
imagine que tu envisage d'utiliser une machine multiprocesseurs ?) car avec
cet OS, la sécurité prévaut toujours sur les performances (utilisation de
propolice par exemple).
NetBSD pour sa part représente un bon compromis. Petit défault à mon gout, il
semble encore chercher son modèle de threading, ce qui peut poser des petits
problèmes (par exemple avec mysql, sous 1.6.1). Ce problème est parait-il
résolu dans -current...
Bref, dans ton cas, j'utiliserai de préférence un snapshot récent de NetBSD
(tout en prenant le temps de m'assurer qu'il fonctionne bien) ou bien un
FreeBSD 4.*.
* Répartition de la charge
Le plus simple est sans doute de répartir les comptes utilisateurs sur
différentes machines, mais celà ne te permettra pas de disposer d'un
mécanisme de tolérance aux pannes.
La gestion du failover pour le www/ssh/scp/ftp est assez simple.
Tu peut faire du mirorring (rsync, fam/imon, coda ...) des données et
distribuer les requètes (vrrp, round-robin à partir des dns ou d'un
routeur/firewall, proxy, ...).
En revanche, si tes utilisateurs utilisent aussi des bases de données bon
marché (mysql, postgreesql), les choses se compliquent car il est difficile
d'obtenir une réplication bidirectionnelle dans ce cas, et la solution
simple (répartion des comptes sur plusieurs machines, sans mécanisme de
failover) s'impose (à moins que tu ne préfère scripter de fragiles
bricolages ...).
Ou, à titre d'alternative, une seule machine très puissante (celà devrait
suffir dans ton cas) répliquée sur une seconde machine (éventuellement moins
puissante) qui n'est utilisée qu'en cas de panne de la première. Et gestion
semi manuelle du retour de la première (resynchronisation des bdd et des
fichiers). Celà peut aussi fonctionner en repliquant un groupe de machines
sur un groupes de miroirs bien entendu.
Le Thu, 2 Oct 2003 14:21:47 +0200, Panic écrivais:
Hello,
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
Qqun a une idée ? :)
* Choix de l'OS
À titre d'apréciation très subjective.
Les 3 BSDs libres supportent parfaitement les fortes charges mais le choix de l'un d'eux n'est pas indifférent.
FreeBSD est très performant et supporte le SMP sur pc. Mais il est largement plus « disparate » (bordélique ? linuxomorphe ?) que les deux autres: ports qui peuvent ne pas compiler, kernel par défault pas très bien senti, ports qui peuvent installer n'importe quoi n'importe où (/usr/local/etc, /var/qmail, ...), évolution un peu figée de la branche 4.* (alors que la branche 5.* est très instable et plus bordélique que jamais), arbre des sources fréquement cassé etc.
OpenBSD et NetBSD sont (à mon gout) à l'inverse très cohérents, simples, propres: en deux mots, « admin friendlys ». En un mot: maintenables.
Cependant OpenBSD est ultra lent (comparez son fs à celui des autres BSD ou aux divers fs linux, c'est incroyable !) et ne supporte pas le SMP (j' imagine que tu envisage d'utiliser une machine multiprocesseurs ?) car avec cet OS, la sécurité prévaut toujours sur les performances (utilisation de propolice par exemple).
NetBSD pour sa part représente un bon compromis. Petit défault à mon gout, il semble encore chercher son modèle de threading, ce qui peut poser des petits problèmes (par exemple avec mysql, sous 1.6.1). Ce problème est parait-il résolu dans -current...
Bref, dans ton cas, j'utiliserai de préférence un snapshot récent de NetBSD (tout en prenant le temps de m'assurer qu'il fonctionne bien) ou bien un FreeBSD 4.*.
* Répartition de la charge
Le plus simple est sans doute de répartir les comptes utilisateurs sur différentes machines, mais celà ne te permettra pas de disposer d'un mécanisme de tolérance aux pannes. La gestion du failover pour le www/ssh/scp/ftp est assez simple. Tu peut faire du mirorring (rsync, fam/imon, coda ...) des données et distribuer les requètes (vrrp, round-robin à partir des dns ou d'un routeur/firewall, proxy, ...). En revanche, si tes utilisateurs utilisent aussi des bases de données bon marché (mysql, postgreesql), les choses se compliquent car il est difficile d'obtenir une réplication bidirectionnelle dans ce cas, et la solution simple (répartion des comptes sur plusieurs machines, sans mécanisme de failover) s'impose (à moins que tu ne préfère scripter de fragiles bricolages ...). Ou, à titre d'alternative, une seule machine très puissante (celà devrait suffir dans ton cas) répliquée sur une seconde machine (éventuellement moins puissante) qui n'est utilisée qu'en cas de panne de la première. Et gestion semi manuelle du retour de la première (resynchronisation des bdd et des fichiers). Celà peut aussi fonctionner en repliquant un groupe de machines sur un groupes de miroirs bien entendu.
patpro
* Répartition de la charge
En revanche, si tes utilisateurs utilisent aussi des bases de données bon marché (mysql, postgreesql), les choses se compliquent car il est difficile d'obtenir une réplication bidirectionnelle dans ce cas, et la solution simple (répartion des comptes sur plusieurs machines, sans mécanisme de failover) s'impose (à moins que tu ne préfère scripter de fragiles bricolages ...).
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
patpro
* Répartition de la charge
En revanche, si tes utilisateurs utilisent aussi des bases de données bon
marché (mysql, postgreesql), les choses se compliquent car il est difficile
d'obtenir une réplication bidirectionnelle dans ce cas, et la solution
simple (répartion des comptes sur plusieurs machines, sans mécanisme de
failover) s'impose (à moins que tu ne préfère scripter de fragiles
bricolages ...).
pourquoi pas dans ce cas dédier une machine au serveur de base de
données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix
local pour atteindre un MySQL ajoute une latence qui peut alonger le
délais de réponse de 10%, mais avoir une machine dédiée pour ça si les
serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est
une combinaison gagnante.
En revanche, si tes utilisateurs utilisent aussi des bases de données bon marché (mysql, postgreesql), les choses se compliquent car il est difficile d'obtenir une réplication bidirectionnelle dans ce cas, et la solution simple (répartion des comptes sur plusieurs machines, sans mécanisme de failover) s'impose (à moins que tu ne préfère scripter de fragiles bricolages ...).
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
patpro
Panic
patpro wrote:
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau de l'install du serveur web parceque j'ai jamais fait (personellement) d'install multi-serveurs de repartition de charge... :/
patpro wrote:
pourquoi pas dans ce cas dédier une machine au serveur de base de
données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix
local pour atteindre un MySQL ajoute une latence qui peut alonger le
délais de réponse de 10%, mais avoir une machine dédiée pour ça si les
serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est
une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau
de l'install du serveur web parceque j'ai jamais fait (personellement)
d'install multi-serveurs de repartition de charge... :/
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau de l'install du serveur web parceque j'ai jamais fait (personellement) d'install multi-serveurs de repartition de charge... :/
patpro
In article <3f7ef0c7$0$20946$, Panic wrote:
patpro wrote:
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau de l'install du serveur web parceque j'ai jamais fait (personellement) d'install multi-serveurs de repartition de charge... :/
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web. En tout cas le sujet m'interesse, donc n'hésite pas a continuer de poster ici au fur et à mesure que tu avances :)
patpro
In article <3f7ef0c7$0$20946$7a628cd7@news.club-internet.fr>,
Panic <panic@nospam.no> wrote:
patpro wrote:
pourquoi pas dans ce cas dédier une machine au serveur de base de
données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix
local pour atteindre un MySQL ajoute une latence qui peut alonger le
délais de réponse de 10%, mais avoir une machine dédiée pour ça si les
serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est
une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau
de l'install du serveur web parceque j'ai jamais fait (personellement)
d'install multi-serveurs de repartition de charge... :/
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou
un truc du meme accabi en frontal ta seule préoccupation sera la
synchronisation des fichiers servis entre les 2 serveurs web.
En tout cas le sujet m'interesse, donc n'hésite pas a continuer de
poster ici au fur et à mesure que tu avances :)
pourquoi pas dans ce cas dédier une machine au serveur de base de données ? certe, utiliser une connexion TCP/IP plutot qu'un socket unix local pour atteindre un MySQL ajoute une latence qui peut alonger le délais de réponse de 10%, mais avoir une machine dédiée pour ça si les serveurs HTTP sont bien chargés fait gagner nettement plus. Donc c'est une combinaison gagnante.
C'est ce que l'on compte faire, mais je vais avoir un souci au niveau de l'install du serveur web parceque j'ai jamais fait (personellement) d'install multi-serveurs de repartition de charge... :/
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web. En tout cas le sujet m'interesse, donc n'hésite pas a continuer de poster ici au fur et à mesure que tu avances :)
patpro
Arnaud Launay
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si jamais ton serveur de balancing se casse la gueule, c'est fini, tu n'as plus rien du tout.
Arnaud. -- You are as I am with You.
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou
un truc du meme accabi en frontal ta seule préoccupation sera la
synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si
jamais ton serveur de balancing se casse la gueule, c'est fini,
tu n'as plus rien du tout.
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si jamais ton serveur de balancing se casse la gueule, c'est fini, tu n'as plus rien du tout.
Arnaud. -- You are as I am with You.
patpro
In article , Arnaud Launay wrote:
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si jamais ton serveur de balancing se casse la gueule, c'est fini, tu n'as plus rien du tout.
oui c'est clair, mais ça reste dans le shema initialement proposé. Maintenant rien n'interdit effectivement de faire du roundrobin sur le DNS et d'avoir les 2 serveurs web en frontal. Mais a l'origine c'est surtout la répartition de charge qui était souhaitée, plus que la redondance et le failover.
patpro
In article <slrnbntv23.40n.arnaud@cassis.launay.org>,
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou
un truc du meme accabi en frontal ta seule préoccupation sera la
synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si
jamais ton serveur de balancing se casse la gueule, c'est fini,
tu n'as plus rien du tout.
oui c'est clair, mais ça reste dans le shema initialement proposé.
Maintenant rien n'interdit effectivement de faire du roundrobin sur le
DNS et d'avoir les 2 serveurs web en frontal. Mais a l'origine c'est
surtout la répartition de charge qui était souhaitée, plus que la
redondance et le failover.
Le Sat, 04 Oct 2003 18:27:36 +0200, patpro écrivit:
moi non plus mais ca ne me parrait pas insurmontable. Avec un ipnat ou un truc du meme accabi en frontal ta seule préoccupation sera la synchronisation des fichiers servis entre les 2 serveurs web.
À part que tu auras un single point of failure dans ce cas-là. Si jamais ton serveur de balancing se casse la gueule, c'est fini, tu n'as plus rien du tout.
oui c'est clair, mais ça reste dans le shema initialement proposé. Maintenant rien n'interdit effectivement de faire du roundrobin sur le DNS et d'avoir les 2 serveurs web en frontal. Mais a l'origine c'est surtout la répartition de charge qui était souhaitée, plus que la redondance et le failover.
patpro
Arnaud Launay
Le Sat, 04 Oct 2003 19:17:07 +0200, patpro écrivit:
oui c'est clair, mais ça reste dans le shema initialement proposé.
Les mauvais schémas peuvent et doivent être changés.
Maintenant rien n'interdit effectivement de faire du roundrobin sur le DNS et d'avoir les 2 serveurs web en frontal.
Surtout qu'en pratique, le roundrobin, s'il ne garantit pas un étalage parfait de la charge, arrive quand même à faire du 40 à 45% sur l'un et 55 à 65% sur l'autre, ce qui est tout à fait honorable.
Mais a l'origine c'est surtout la répartition de charge qui était souhaitée, plus que la redondance et le failover.
Soit les deux machines reliées au grand ternet via une carte rézo, et c1 et c2 les 2 cables+cartes ethernet reliant les 2 machines avec un heartbeat.
Sur s1 et s2, en plus de faire tourner les serveurs web, on fait également tourner la solution de répartition et redondance (ipf ou je ne sais quoi), de manière à ce que s1 récupère les requêtes arrivant sur s2 si celui-ci est trop chargé, et inversement. Le tout combiné à du RR dns, la charge ne devrait pas être trop importante (on perd évidemment un peu pour le traitement), et en cas de défaillance de s1 et s2, s2 ou s1 prend la main sur l'IP grand-terneteuse de l'autre, à la condition sine qua non qu'il n'y ait pas de cache arp au-dessus, sinon tout est foutu.
Évidemment, le mieux, c'est un loadbalancing matériel avec par exemple deux Foundry ServerIron, mais je crois qu'on explose le budget.
Arnaud.
Le Sat, 04 Oct 2003 19:17:07 +0200, patpro écrivit:
oui c'est clair, mais ça reste dans le shema initialement proposé.
Les mauvais schémas peuvent et doivent être changés.
Maintenant rien n'interdit effectivement de faire du roundrobin
sur le DNS et d'avoir les 2 serveurs web en frontal.
Surtout qu'en pratique, le roundrobin, s'il ne garantit pas un
étalage parfait de la charge, arrive quand même à faire du 40 à
45% sur l'un et 55 à 65% sur l'autre, ce qui est tout à fait
honorable.
Mais a l'origine c'est surtout la répartition de charge qui
était souhaitée, plus que la redondance et le failover.
Soit les deux machines reliées au grand ternet via une carte
rézo, et c1 et c2 les 2 cables+cartes ethernet reliant les
2 machines avec un heartbeat.
Sur s1 et s2, en plus de faire tourner les serveurs web, on fait
également tourner la solution de répartition et redondance (ipf
ou je ne sais quoi), de manière à ce que s1 récupère les requêtes
arrivant sur s2 si celui-ci est trop chargé, et inversement. Le
tout combiné à du RR dns, la charge ne devrait pas être trop
importante (on perd évidemment un peu pour le traitement), et en
cas de défaillance de s1 et s2, s2 ou s1 prend la main sur l'IP
grand-terneteuse de l'autre, à la condition sine qua non qu'il
n'y ait pas de cache arp au-dessus, sinon tout est foutu.
Évidemment, le mieux, c'est un loadbalancing matériel avec par
exemple deux Foundry ServerIron, mais je crois qu'on explose le budget.
Le Sat, 04 Oct 2003 19:17:07 +0200, patpro écrivit:
oui c'est clair, mais ça reste dans le shema initialement proposé.
Les mauvais schémas peuvent et doivent être changés.
Maintenant rien n'interdit effectivement de faire du roundrobin sur le DNS et d'avoir les 2 serveurs web en frontal.
Surtout qu'en pratique, le roundrobin, s'il ne garantit pas un étalage parfait de la charge, arrive quand même à faire du 40 à 45% sur l'un et 55 à 65% sur l'autre, ce qui est tout à fait honorable.
Mais a l'origine c'est surtout la répartition de charge qui était souhaitée, plus que la redondance et le failover.
Soit les deux machines reliées au grand ternet via une carte rézo, et c1 et c2 les 2 cables+cartes ethernet reliant les 2 machines avec un heartbeat.
Sur s1 et s2, en plus de faire tourner les serveurs web, on fait également tourner la solution de répartition et redondance (ipf ou je ne sais quoi), de manière à ce que s1 récupère les requêtes arrivant sur s2 si celui-ci est trop chargé, et inversement. Le tout combiné à du RR dns, la charge ne devrait pas être trop importante (on perd évidemment un peu pour le traitement), et en cas de défaillance de s1 et s2, s2 ou s1 prend la main sur l'IP grand-terneteuse de l'autre, à la condition sine qua non qu'il n'y ait pas de cache arp au-dessus, sinon tout est foutu.
Évidemment, le mieux, c'est un loadbalancing matériel avec par exemple deux Foundry ServerIron, mais je crois qu'on explose le budget.
Arnaud.
patpro
In article , Arnaud Launay wrote:
Mais a l'origine c'est surtout la répartition de charge qui était souhaitée, plus que la redondance et le failover.
Hmmmm, on peut combiner les deux.
ok, merci pour les détails
patpro
In article <slrnbnu0oa.433.arnaud@cassis.launay.org>,
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Mais a l'origine c'est surtout la répartition de charge qui
était souhaitée, plus que la redondance et le failover.
