2 serveurs, load balancing ou bi-processeur pour un site ?
14 réponses
Fred
Bonjour à tous,
J'ai un site en ASP + MySQL hébergé sur un serveur win 2000 server (PIV
2,8GHz, 1Go RAM).
Le cpu du serveur est régulièrement à une charge moyenne de 50 à 65%
(répatri essentiellement entre IIS (45%), MySQL (45%) et Winroute
firewall (10%)).
On a optimisé au mieux nos requetes, et on se pose la question de migrer
d'ici quelques temps vers un autre serveur plus puissant, le trafic du
site ne cessant de croitre.
Quel est le meilleur choix en terme de performance, de fiabilité et de
coût entre les idées suivantes :
- avoir 2 serveurs, un pour la base de données (mySQL) et l'autre pour IIS
- avoir 2 serveurs en load balancing (il me semble qu'il faut avoir win
2000 advanced server ou windows 2003)
- avoir un seul serveur bi-processeur (genre bi-xeon).
On Mon, 29 Aug 2005 23:30:41 +0200, Calimero wrote:
Sinon un simple round robin DNS à 0.00Euro suffirait.
Hum. On est certain que le round robin resolve les problèmes de sessions?
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux partager l'accès au dit répertoire entre tous les noeuds de ton cluster. Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un autre serveur, la session peut continuer.
Le client établit une première connexion sur le LB, celui-ci enregistre l'info dans une mémoire cache et forwarde vers un des noeuds/serveurs. Les connexions suivantes seront alors dirigées par le LB vers le même serveur après vérification dans la table de correspondance. Il est aussi possible de faire ces redirections pour tout un subnet au lieu d'une seule IP, dans le cas où ce sont des proxies côté client qui se connectent. Dans cette configuration, les serveurs web ne sont pas directement visibles par l'utilisateur. Le serveur de fichier n'est pas indispensable, aussi.
Enfin bon, à confirmer par "quelqu'un qui sait", n'ayant pas encore eu l'occasion de vraiment jouer avec tout ca.
-- @+ Calimero
R12y wrote:
On Mon, 29 Aug 2005 23:30:41 +0200, Calimero wrote:
Sinon un simple round robin DNS à 0.00Euro suffirait.
Hum. On est certain que le round robin resolve les problèmes de sessions?
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux
partager l'accès au dit répertoire entre tous les noeuds de ton cluster.
Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un
autre serveur, la session peut continuer.
Le client établit une première connexion sur le LB, celui-ci enregistre
l'info dans une mémoire cache et forwarde vers un des noeuds/serveurs.
Les connexions suivantes seront alors dirigées par le LB vers le même
serveur après vérification dans la table de correspondance. Il est aussi
possible de faire ces redirections pour tout un subnet au lieu d'une
seule IP, dans le cas où ce sont des proxies côté client qui se connectent.
Dans cette configuration, les serveurs web ne sont pas directement
visibles par l'utilisateur.
Le serveur de fichier n'est pas indispensable, aussi.
Enfin bon, à confirmer par "quelqu'un qui sait", n'ayant pas encore eu
l'occasion de vraiment jouer avec tout ca.
On Mon, 29 Aug 2005 23:30:41 +0200, Calimero wrote:
Sinon un simple round robin DNS à 0.00Euro suffirait.
Hum. On est certain que le round robin resolve les problèmes de sessions?
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux partager l'accès au dit répertoire entre tous les noeuds de ton cluster. Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un autre serveur, la session peut continuer.
Le client établit une première connexion sur le LB, celui-ci enregistre l'info dans une mémoire cache et forwarde vers un des noeuds/serveurs. Les connexions suivantes seront alors dirigées par le LB vers le même serveur après vérification dans la table de correspondance. Il est aussi possible de faire ces redirections pour tout un subnet au lieu d'une seule IP, dans le cas où ce sont des proxies côté client qui se connectent. Dans cette configuration, les serveurs web ne sont pas directement visibles par l'utilisateur. Le serveur de fichier n'est pas indispensable, aussi.
Enfin bon, à confirmer par "quelqu'un qui sait", n'ayant pas encore eu l'occasion de vraiment jouer avec tout ca.
-- @+ Calimero
Patrick Mevzek
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux partager l'accès au dit répertoire entre tous les noeuds de ton cluster. Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un autre serveur, la session peut continuer.
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
C'est là qu'un load balancer qui garde un état des connexions s'impose.
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant) - un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps) - la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes - une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux
partager l'accès au dit répertoire entre tous les noeuds de ton cluster.
Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un
autre serveur, la session peut continuer.
Et si on ne veut pas partager un répertoire, on met les sessions dans une
base de données, ou un cache comme memcached (mais sans garantie de
persistence).
C'est là qu'un load balancer qui garde un état des connexions s'impose.
Le problème c'est que les sessions ne sont pas nécessairement gérées
par des cookies, et que dans tous les cas de figure il faut que le
répartiteur de charge implémente HTTP pour décoder les bouts importants.
Donc SPOF potentiel, risque de problèmes (style débordement de buffer),
et bien sûr impact en performances.
Le problème du DNS RR c'est que ca ne prend pas en compte:
- des serveurs de puissance différentes (statistiquement chacun
récupère autant)
- un basculement vers un serveur qui marche quand l'actuel lâche
(vu que le client conserve l'IP pendant un certain temps)
- la prise en compte des défaillances des serveurs, avant de leur envoyer
des requêtes
- une répartition entre les serveurs basée sur l'URL par exemple,
pour spécialiser certains serveurs à certaines tâches.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
En PHP, où les sessions peuvent être basées sur des fichiers, tu peux partager l'accès au dit répertoire entre tous les noeuds de ton cluster. Tu peux alors faire du RR. Du coup, même si l'utilisateur bascule sur un autre serveur, la session peut continuer.
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
C'est là qu'un load balancer qui garde un état des connexions s'impose.
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant) - un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps) - la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes - une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Calimero
Patrick Mevzek wrote:
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu éternelle, c'est pas forcément dramatique.
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le problème des proxies), à mon sens le problème disparaît.
x.x.x.x initie une connexion vers le LB, celui-ci redirige vers le noeud numéro 1. x.x.x.x initie une nouvelle connexion vers le LB, celui-ci, grâce à sa hash table de correspondance rebalance vers le même noeud numéro 1.
Du coup, t'es relativement indépendant du protocole utilisé.
Il me semble que linux-HA (heartbeat) travaille comme ca.
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées tombent et les clients doivent relancer leur session (après le basculement automatique vers un autre noeud).
Effectivement, le load balancer devient un point critique alors, c'est vrai. Je suppose qu'on peut clusteriser le load balancer, ou au moins avoir un hotspare... (mon + fake ?)
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant)
Augmenter la pondération des serveurs les plus puissants (multiples enregistrements) ?
- un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme toujours...
- la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR des familles...
- une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur pour les images ? Ca ne demande que peu de "technologie", effectivement
Disons que le RR a globalement l'avantage du coût et une relative simplicité, par rapport aux solutions utilisant un LB intermédiaire.
-- @+ Calimero, qui aimerait vraiment tester la chose, au lieu de juste pouvoir lire des docs ;-)
Patrick Mevzek wrote:
Et si on ne veut pas partager un répertoire, on met les sessions dans une
base de données, ou un cache comme memcached (mais sans garantie de
persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu
éternelle, c'est pas forcément dramatique.
Le problème c'est que les sessions ne sont pas nécessairement gérées
par des cookies, et que dans tous les cas de figure il faut que le
répartiteur de charge implémente HTTP pour décoder les bouts importants.
Donc SPOF potentiel, risque de problèmes (style débordement de buffer),
et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le
problème des proxies), à mon sens le problème disparaît.
x.x.x.x initie une connexion vers le LB, celui-ci redirige vers le noeud
numéro 1.
x.x.x.x initie une nouvelle connexion vers le LB, celui-ci, grâce à sa
hash table de correspondance rebalance vers le même noeud numéro 1.
Du coup, t'es relativement indépendant du protocole utilisé.
Il me semble que linux-HA (heartbeat) travaille comme ca.
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées
tombent et les clients doivent relancer leur session (après le
basculement automatique vers un autre noeud).
Effectivement, le load balancer devient un point critique alors, c'est
vrai. Je suppose qu'on peut clusteriser le load balancer, ou au moins
avoir un hotspare... (mon + fake ?)
Le problème du DNS RR c'est que ca ne prend pas en compte:
- des serveurs de puissance différentes (statistiquement chacun
récupère autant)
Augmenter la pondération des serveurs les plus puissants (multiples
enregistrements) ?
- un basculement vers un serveur qui marche quand l'actuel lâche
(vu que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme toujours...
- la prise en compte des défaillances des serveurs, avant de leur envoyer
des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR
des familles...
- une répartition entre les serveurs basée sur l'URL par exemple,
pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur
pour les images ?
Ca ne demande que peu de "technologie", effectivement
Disons que le RR a globalement l'avantage du coût et une relative
simplicité, par rapport aux solutions utilisant un LB intermédiaire.
--
@+
Calimero, qui aimerait vraiment tester la chose, au lieu de juste
pouvoir lire des docs ;-)
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu éternelle, c'est pas forcément dramatique.
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le problème des proxies), à mon sens le problème disparaît.
x.x.x.x initie une connexion vers le LB, celui-ci redirige vers le noeud numéro 1. x.x.x.x initie une nouvelle connexion vers le LB, celui-ci, grâce à sa hash table de correspondance rebalance vers le même noeud numéro 1.
Du coup, t'es relativement indépendant du protocole utilisé.
Il me semble que linux-HA (heartbeat) travaille comme ca.
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées tombent et les clients doivent relancer leur session (après le basculement automatique vers un autre noeud).
Effectivement, le load balancer devient un point critique alors, c'est vrai. Je suppose qu'on peut clusteriser le load balancer, ou au moins avoir un hotspare... (mon + fake ?)
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant)
Augmenter la pondération des serveurs les plus puissants (multiples enregistrements) ?
- un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme toujours...
- la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR des familles...
- une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur pour les images ? Ca ne demande que peu de "technologie", effectivement
Disons que le RR a globalement l'avantage du coût et une relative simplicité, par rapport aux solutions utilisant un LB intermédiaire.
-- @+ Calimero, qui aimerait vraiment tester la chose, au lieu de juste pouvoir lire des docs ;-)
Patrick Mevzek
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu éternelle, c'est pas forcément dramatique.
Quand elles sont utilisées pour l'authentification... c'est dommage de les perdre, non ?
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le problème des proxies), à mon sens le problème disparaît.
Parce que les données de session sont au niveau IP ? (je parle du numéro de session, soit dans l'URL soit dans un cookie).
Se baser sur l'IP du client c'est tout sauf statistiquement satisfaisant (les 256^4 adresses IP n'ont pas le même usage) d'une part. D'autre part plusieurs client peuvent avoir la même IP (passage par un proxy), une IP peut changer en cours de session (IP dynamique, proxy anonymisant ou non, etc...), bref partir de l'idée 1 client = 1 ip, c'est une erreur classique, et cela revient vous hanter plus tard... quand c'est trop tard (pour corriger tous les programmes qui font cette hypothèse foireuse)
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées tombent et les clients doivent relancer leur session (après le basculement automatique vers un autre noeud).
Ce qui fait beaucoup de travail pour gérer un événement somme toute ordinaire.
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant)
Augmenter la pondération des serveurs les plus puissants (multiples enregistrements) ?
Je doute que cela fonctionne.
- un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme toujours...
Sauf que compromis il ne peut y avoir là. Pour que ca marche il faut un TTL de 0, ce qui est tout sauf très satisfaisant question trafic.
- la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR des familles...
C'est mélanger les tâches. Le DNS c'est la traduction IP vers nom et réciproquement, point final. Le reste se passe à d'autres couches.
- une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur pour les images ?
Par exemple. Ou les clients payants des clients gratuits. Ou le forum du site, et le reste. Etc... etc...
Disons que le RR a globalement l'avantage du coût et une relative simplicité, par rapport aux solutions utilisant un LB intermédiaire.
Personnellement, je suis partisan des reverse proxy. Et si on va se protéger de leur chute, plusieurs en DNS RR, par exemple.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Et si on ne veut pas partager un répertoire, on met les sessions dans une
base de données, ou un cache comme memcached (mais sans garantie de
persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu
éternelle, c'est pas forcément dramatique.
Quand elles sont utilisées pour l'authentification... c'est dommage de
les perdre, non ?
Le problème c'est que les sessions ne sont pas nécessairement
gérées par des cookies, et que dans tous les cas de figure il faut
que le répartiteur de charge implémente HTTP pour décoder les bouts
importants. Donc SPOF potentiel, risque de problèmes (style
débordement de buffer), et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le
problème des proxies), à mon sens le problème disparaît.
Parce que les données de session sont au niveau IP ?
(je parle du numéro de session, soit dans l'URL soit dans un cookie).
Se baser sur l'IP du client c'est tout sauf statistiquement satisfaisant
(les 256^4 adresses IP n'ont pas le même usage) d'une part. D'autre part
plusieurs client peuvent avoir la même IP (passage par un proxy), une IP
peut changer en cours de session (IP dynamique, proxy anonymisant ou non,
etc...), bref partir de l'idée 1 client = 1 ip, c'est une erreur
classique, et cela revient vous hanter plus tard... quand c'est trop tard
(pour corriger tous les programmes qui font cette hypothèse foireuse)
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées
tombent et les clients doivent relancer leur session (après le
basculement automatique vers un autre noeud).
Ce qui fait beaucoup de travail pour gérer un événement somme toute
ordinaire.
Le problème du DNS RR c'est que ca ne prend pas en compte: - des
serveurs de puissance différentes (statistiquement chacun récupère
autant)
Augmenter la pondération des serveurs les plus puissants (multiples
enregistrements) ?
Je doute que cela fonctionne.
- un basculement vers un serveur qui marche quand l'actuel lâche (vu
que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme
toujours...
Sauf que compromis il ne peut y avoir là. Pour que ca marche il faut un
TTL de 0, ce qui est tout sauf très satisfaisant question trafic.
- la prise en compte des défaillances des serveurs, avant de leur
envoyer des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR
des familles...
C'est mélanger les tâches. Le DNS c'est la traduction IP vers nom et
réciproquement, point final. Le reste se passe à d'autres couches.
- une répartition entre les serveurs basée sur l'URL par exemple,
pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur
pour les images ?
Par exemple. Ou les clients payants des clients gratuits. Ou le forum du
site, et le reste. Etc... etc...
Disons que le RR a globalement l'avantage du coût et une relative
simplicité, par rapport aux solutions utilisant un LB intermédiaire.
Personnellement, je suis partisan des reverse proxy. Et si on va se
protéger de leur chute, plusieurs en DNS RR, par exemple.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Et si on ne veut pas partager un répertoire, on met les sessions dans une base de données, ou un cache comme memcached (mais sans garantie de persistence).
Disons que les sessions HTTP ayant de toute façon une nature assez peu éternelle, c'est pas forcément dramatique.
Quand elles sont utilisées pour l'authentification... c'est dommage de les perdre, non ?
Le problème c'est que les sessions ne sont pas nécessairement gérées par des cookies, et que dans tous les cas de figure il faut que le répartiteur de charge implémente HTTP pour décoder les bouts importants. Donc SPOF potentiel, risque de problèmes (style débordement de buffer), et bien sûr impact en performances.
Mhhhh si on travaille au niveau IP (ou subnet, pour gérer en partie le problème des proxies), à mon sens le problème disparaît.
Parce que les données de session sont au niveau IP ? (je parle du numéro de session, soit dans l'URL soit dans un cookie).
Se baser sur l'IP du client c'est tout sauf statistiquement satisfaisant (les 256^4 adresses IP n'ont pas le même usage) d'une part. D'autre part plusieurs client peuvent avoir la même IP (passage par un proxy), une IP peut changer en cours de session (IP dynamique, proxy anonymisant ou non, etc...), bref partir de l'idée 1 client = 1 ip, c'est une erreur classique, et cela revient vous hanter plus tard... quand c'est trop tard (pour corriger tous les programmes qui font cette hypothèse foireuse)
Je t'accorde qu'en cas de perte d'un noeud, les sessions associées tombent et les clients doivent relancer leur session (après le basculement automatique vers un autre noeud).
Ce qui fait beaucoup de travail pour gérer un événement somme toute ordinaire.
Le problème du DNS RR c'est que ca ne prend pas en compte: - des serveurs de puissance différentes (statistiquement chacun récupère autant)
Augmenter la pondération des serveurs les plus puissants (multiples enregistrements) ?
Je doute que cela fonctionne.
- un basculement vers un serveur qui marche quand l'actuel lâche (vu que le client conserve l'IP pendant un certain temps)
Effectivement, faut bien régler le TTL... un compromis comme toujours...
Sauf que compromis il ne peut y avoir là. Pour que ca marche il faut un TTL de 0, ce qui est tout sauf très satisfaisant question trafic.
- la prise en compte des défaillances des serveurs, avant de leur envoyer des requêtes
On pourrait imaginer un DNS intelligent, mais on s'éloigne du simple RR des familles...
C'est mélanger les tâches. Le DNS c'est la traduction IP vers nom et réciproquement, point final. Le reste se passe à d'autres couches.
- une répartition entre les serveurs basée sur l'URL par exemple, pour spécialiser certains serveurs à certaines tâches.
Séparer le contenu statique du contenu dynamique par ex ? Un serveur pour les images ?
Par exemple. Ou les clients payants des clients gratuits. Ou le forum du site, et le reste. Etc... etc...
Disons que le RR a globalement l'avantage du coût et une relative simplicité, par rapport aux solutions utilisant un LB intermédiaire.
Personnellement, je suis partisan des reverse proxy. Et si on va se protéger de leur chute, plusieurs en DNS RR, par exemple.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
