Je fais ici appel à l'expérience de mes chers amis hébergeurs. Je
recherche un logiciel serveur DNS répondant à mes critères de sélection.
Comme c'est pour un volume légèrement supérieur à quelques dizaines ou
centaines de requêtes par seconde, que des dizaines de milliers de zones
sont hébergées, et que le but est de faire quelque chose de réellement
pro, les contraintes sont toutes autres que le particulier et sa
connexion ADSL
Donc voici :
- Continuité de service à 100% pour chaque serveur (sauf incident
hardware ou réseau) ; càd qu'un reload ne fait pas de microcoupure...
- Performance : peut répondre à n'importe quelle requête en moins de 10ms
- Chargement initial relativement rapide (mettons moins de 20 sec)
Avec bien sur :
- Simplicité relative
- Respect des RFC
J'ai passé un peu en revue tout ce qui se fait sur le marché OpenSource:
- BIND éliminé : chargement trop long, microcoupures en cas de reload,
coupures de près de 1 sec sur un rndc reconfig d'un gros named.conf,
pertes de paquets sous la forte charge...
- L'ensemble des serveurs à base de requêtes temps réel sur base SQL :
éliminés car trop lents (PowerDNS, MyDNS, MaraDNS)
- NSD éliminé pour problème de continuité de service : un reload
necessite "recompiler" l'ensemble des fichie
- DJB/TinyDNS éliminé pour non-respect des RFC, problèmes de tenue en
charge, complexité à générer de bonnes conf
J'avais des espoirs sur l'utilisation de PowerDNS avec le "bindbackend",
mais je me retrouve avec des problèmes de conception qui entrainent des
problèmes de continuité de service : s'il n'aime pas le contenu d'une
nouvelle version d'une zone il ne garde pas l'ancienne, il arrête de
répondre
(documenté sur l'url
http://downloads.powerdns.com/documentation/html/bindbackend.html#AEN5101
et si je fais les transferts moi-même sur des fichiers ça a le même
comportement ...)
et bien plus grave, j'ai réussi à lui faire faire des "exited on signal
6" avec un fichier named.conf de quelques milliers de zones totalement
bateau à base de
zone "truc.com" { file "path/truc.com"; };
en plus quand il ne segfault pas, il arrête de répondre le temps de
faire le "rediscover", ce qui ne le rend pas tellement meilleur que BIND...
Bref, je suis un peu au bout de mes options ; jusqu'ici je me rabats sur
MyDNS qui s'il est parfois un peu lent (50 à 100ms pour des requetes pas
en cache) a le mérite de marcher 100% du temps, de répondre en 5ms aux
requêtes en cache, et de se montrer fiable/simple à gérer couplé à des
scripts d'axfr et autre réplication mysql.
Pour plus tard, je pense à la solution "ANS" de chez Nominum, très
impressionnante, que j'ai pu tester il y a quelques mois... Encore très
chère (des licences à plus de 10KE/serveur), c'est la seule qui
répondrait à mes trois critères.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique ROUSSEAU
Le sam, 10 mar 2007 at 22:28 GMT, Patrick Viet a écrit :
Bonjour, ou bonsoir,
Je fais ici appel à l'expérience de mes chers amis hébergeurs. Je recherche un logiciel serveur DNS répondant à mes critères de sélection.
Comme c'est pour un volume légèrement supérieur à quelques dizaines ou centaines de requêtes par seconde, que des dizaines de milliers de zones sont hébergées, et que le but est de faire quelque chose de réellement pro, les contraintes sont toutes autres que le particulier et sa connexion ADSL
Donc voici : - Continuité de service à 100% pour chaque serveur (sauf incident hardware ou réseau) ; càd qu'un reload ne fait pas de microcoupure... - Performance : peut répondre à n'importe quelle requête en moins de 10ms - Chargement initial relativement rapide (mettons moins de 20 sec)
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
Le sam, 10 mar 2007 at 22:28 GMT, Patrick Viet <pviet@delta6.net.nospam> a écrit :
Bonjour, ou bonsoir,
Je fais ici appel à l'expérience de mes chers amis hébergeurs. Je
recherche un logiciel serveur DNS répondant à mes critères de sélection.
Comme c'est pour un volume légèrement supérieur à quelques dizaines ou
centaines de requêtes par seconde, que des dizaines de milliers de zones
sont hébergées, et que le but est de faire quelque chose de réellement
pro, les contraintes sont toutes autres que le particulier et sa
connexion ADSL
Donc voici :
- Continuité de service à 100% pour chaque serveur (sauf incident
hardware ou réseau) ; càd qu'un reload ne fait pas de microcoupure...
- Performance : peut répondre à n'importe quelle requête en moins de 10ms
- Chargement initial relativement rapide (mettons moins de 20 sec)
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les
requetes vers X serveurs derrière (X = 2 suffirait probablement).
Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les
problèmes de reload. De même, si l'un d'entre eux commence à répondre
trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau
"ocrrectement".
Le sam, 10 mar 2007 at 22:28 GMT, Patrick Viet a écrit :
Bonjour, ou bonsoir,
Je fais ici appel à l'expérience de mes chers amis hébergeurs. Je recherche un logiciel serveur DNS répondant à mes critères de sélection.
Comme c'est pour un volume légèrement supérieur à quelques dizaines ou centaines de requêtes par seconde, que des dizaines de milliers de zones sont hébergées, et que le but est de faire quelque chose de réellement pro, les contraintes sont toutes autres que le particulier et sa connexion ADSL
Donc voici : - Continuité de service à 100% pour chaque serveur (sauf incident hardware ou réseau) ; càd qu'un reload ne fait pas de microcoupure... - Performance : peut répondre à n'importe quelle requête en moins de 10ms - Chargement initial relativement rapide (mettons moins de 20 sec)
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
Patrick Viet
Dominique ROUSSEAU wrote:
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins aussi fiable dans la réalité que sur le papier. D'expérience, ce type d'usine à gaz qui ferait un swap en reconfigurant le load balancer toutes les dix minutes provoquerait davantage de pannes liées à la redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Sans oublier son coût complètement délirant pour déployer sur trois sites distincts : - matos supplémentaire - espace en baie/courant supplémentaire - travail supplémentaire
A ce rythme là j'ai amorti mes trois licences ANS dès la première année, la complexité en plus...
Merci pour ta remarque toutefois ; j'invite les autres gens à donner leur avis sur la question.
-- Patrick Viet
Dominique ROUSSEAU wrote:
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les
requetes vers X serveurs derrière (X = 2 suffirait probablement).
Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les
problèmes de reload. De même, si l'un d'entre eux commence à répondre
trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau
"ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins
aussi fiable dans la réalité que sur le papier. D'expérience, ce type
d'usine à gaz qui ferait un swap en reconfigurant le load balancer
toutes les dix minutes provoquerait davantage de pannes liées à la
redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Sans oublier son coût complètement délirant pour déployer sur trois
sites distincts :
- matos supplémentaire
- espace en baie/courant supplémentaire
- travail supplémentaire
A ce rythme là j'ai amorti mes trois licences ANS dès la première année,
la complexité en plus...
Merci pour ta remarque toutefois ; j'invite les autres gens à donner
leur avis sur la question.
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins aussi fiable dans la réalité que sur le papier. D'expérience, ce type d'usine à gaz qui ferait un swap en reconfigurant le load balancer toutes les dix minutes provoquerait davantage de pannes liées à la redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Sans oublier son coût complètement délirant pour déployer sur trois sites distincts : - matos supplémentaire - espace en baie/courant supplémentaire - travail supplémentaire
A ce rythme là j'ai amorti mes trois licences ANS dès la première année, la complexité en plus...
Merci pour ta remarque toutefois ; j'invite les autres gens à donner leur avis sur la question.
-- Patrick Viet
Barbapapa
- L'ensemble des serveurs à base de requêtes temps réel sur base SQL : éliminés car trop lents (PowerDNS, MyDNS, MaraDNS)
J'ai fait à peu près la même analyse, avec à peu près les mêmes exigences lorsque nous avons décidé de nous séparer de BIND il y a 4 ans. Certes les choses ont un peu évoluées entre temps au niveau des différents produits, mais dans le fond pas tant que ça.
Nous avions finalement opté pour MyDNS, et je ne l'ai jamais regretté, car le produit est très stable, et très performant, vraiment très simple à utiliser, et très facilement extensible (ajouter un id client dans la base est simplissime, il suffit d'ajouter la colonne dans la table mysql).
Quand je dis très performant, le temps de réponse est largement sous les 10ms (la moyenne est entre 1 et 2 pour une requete initiale, et le systeme de cache permet ensuite à mydns de répondre en 0.02ms sur les requetes identiques suivantes), à condition que la base des enregistrements MySQL tienne en RAM, et que mydns et mysql soient ensemble sur un même serveur connecté par une socket fichier (notre base contient aujourd'hui autour de 15000 zones et 120000 enregistrements).
Notre configuration est réalisée avec 3 serveurs, un serveur mysql maitre sur lequel les zones sont modifiées et deux réplicats en lecture seule. Les réplicats et le serveur maitre ne sont évidemment pas physiquement au même endroit. Il n'y a jamais de rechargement de mydns sauf en cas de mise à jour logicielle : sur mydns ça n'arrive à peu près jamais, mais mysql reste un peu une plaie pour ça, on utilise donc un 3ème réplicat qui prend le relais le temps de la mise à jour de chacun des 2 autres (on aurait pu utiliser le maitre pour le faire, si on avait manqué d'espace ou de ressources hardware). Hors période de mise à jour ce 3ème réplicat est prêt à prendre le relais a tout instant si un probleme hardware ou réseau survenait sur l'un des 2 autres.
pour info à l'instant sur l'un des réplicats : up 52w1d16h59m8s (31597148s) 6721016433 questions (212/s)
ps: Pour plus de détails, mon email est valide.
- L'ensemble des serveurs à base de requêtes temps réel sur base SQL :
éliminés car trop lents (PowerDNS, MyDNS, MaraDNS)
J'ai fait à peu près la même analyse, avec à peu près les mêmes
exigences lorsque nous avons décidé de nous séparer de BIND il y a 4
ans. Certes les choses ont un peu évoluées entre temps au niveau des
différents produits, mais dans le fond pas tant que ça.
Nous avions finalement opté pour MyDNS, et je ne l'ai jamais regretté,
car le produit est très stable, et très performant, vraiment très simple
à utiliser, et très facilement extensible (ajouter un id client dans la
base est simplissime, il suffit d'ajouter la colonne dans la table mysql).
Quand je dis très performant, le temps de réponse est largement sous les
10ms (la moyenne est entre 1 et 2 pour une requete initiale, et le
systeme de cache permet ensuite à mydns de répondre en 0.02ms sur les
requetes identiques suivantes), à condition que la base des
enregistrements MySQL tienne en RAM, et que mydns et mysql soient
ensemble sur un même serveur connecté par une socket fichier (notre base
contient aujourd'hui autour de 15000 zones et 120000 enregistrements).
Notre configuration est réalisée avec 3 serveurs, un serveur mysql
maitre sur lequel les zones sont modifiées et deux réplicats en lecture
seule. Les réplicats et le serveur maitre ne sont évidemment pas
physiquement au même endroit.
Il n'y a jamais de rechargement de mydns sauf en cas de mise à jour
logicielle : sur mydns ça n'arrive à peu près jamais, mais mysql reste
un peu une plaie pour ça, on utilise donc un 3ème réplicat qui prend le
relais le temps de la mise à jour de chacun des 2 autres (on aurait pu
utiliser le maitre pour le faire, si on avait manqué d'espace ou de
ressources hardware). Hors période de mise à jour ce 3ème réplicat est
prêt à prendre le relais a tout instant si un probleme hardware ou
réseau survenait sur l'un des 2 autres.
pour info à l'instant sur l'un des réplicats :
up 52w1d16h59m8s (31597148s) 6721016433 questions (212/s)
- L'ensemble des serveurs à base de requêtes temps réel sur base SQL : éliminés car trop lents (PowerDNS, MyDNS, MaraDNS)
J'ai fait à peu près la même analyse, avec à peu près les mêmes exigences lorsque nous avons décidé de nous séparer de BIND il y a 4 ans. Certes les choses ont un peu évoluées entre temps au niveau des différents produits, mais dans le fond pas tant que ça.
Nous avions finalement opté pour MyDNS, et je ne l'ai jamais regretté, car le produit est très stable, et très performant, vraiment très simple à utiliser, et très facilement extensible (ajouter un id client dans la base est simplissime, il suffit d'ajouter la colonne dans la table mysql).
Quand je dis très performant, le temps de réponse est largement sous les 10ms (la moyenne est entre 1 et 2 pour une requete initiale, et le systeme de cache permet ensuite à mydns de répondre en 0.02ms sur les requetes identiques suivantes), à condition que la base des enregistrements MySQL tienne en RAM, et que mydns et mysql soient ensemble sur un même serveur connecté par une socket fichier (notre base contient aujourd'hui autour de 15000 zones et 120000 enregistrements).
Notre configuration est réalisée avec 3 serveurs, un serveur mysql maitre sur lequel les zones sont modifiées et deux réplicats en lecture seule. Les réplicats et le serveur maitre ne sont évidemment pas physiquement au même endroit. Il n'y a jamais de rechargement de mydns sauf en cas de mise à jour logicielle : sur mydns ça n'arrive à peu près jamais, mais mysql reste un peu une plaie pour ça, on utilise donc un 3ème réplicat qui prend le relais le temps de la mise à jour de chacun des 2 autres (on aurait pu utiliser le maitre pour le faire, si on avait manqué d'espace ou de ressources hardware). Hors période de mise à jour ce 3ème réplicat est prêt à prendre le relais a tout instant si un probleme hardware ou réseau survenait sur l'un des 2 autres.
pour info à l'instant sur l'un des réplicats : up 52w1d16h59m8s (31597148s) 6721016433 questions (212/s)
ps: Pour plus de détails, mon email est valide.
Spyou
Dominique ROUSSEAU wrote:
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins aussi fiable dans la réalité que sur le papier. D'expérience, ce type d'usine à gaz qui ferait un swap en reconfigurant le load balancer toutes les dix minutes provoquerait davantage de pannes liées à la redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Pas besoin de reconfigurer le loadballancer toutes les dix minutes. Suffit de lui faire envoyer les requettes aux deux serveurs (ou deux serveurs sur un pool de X, le cas echeant) en lui disant de prendre en compte la réponse la plus rapide.
Propre et fault-tolerant, quoi que la remarque de Christophe est tres juste :)
Mais ca peut valloir pour un gros resolver.
Sans oublier son coût complètement délirant pour déployer sur trois sites distincts : - matos supplémentaire - espace en baie/courant supplémentaire - travail supplémentaire
Ca fait 1U, 2 au max, un bon load ballancer .. faut pas pousser qd meme.
Dominique ROUSSEAU wrote:
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les
requetes vers X serveurs derrière (X = 2 suffirait probablement).
Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les
problèmes de reload. De même, si l'un d'entre eux commence à répondre
trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau
"ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins
aussi fiable dans la réalité que sur le papier. D'expérience, ce type
d'usine à gaz qui ferait un swap en reconfigurant le load balancer
toutes les dix minutes provoquerait davantage de pannes liées à la
redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Pas besoin de reconfigurer le loadballancer toutes les dix minutes.
Suffit de lui faire envoyer les requettes aux deux serveurs (ou deux
serveurs sur un pool de X, le cas echeant) en lui disant de prendre en
compte la réponse la plus rapide.
Propre et fault-tolerant, quoi que la remarque de Christophe est tres
juste :)
Mais ca peut valloir pour un gros resolver.
Sans oublier son coût complètement délirant pour déployer sur trois
sites distincts :
- matos supplémentaire
- espace en baie/courant supplémentaire
- travail supplémentaire
Ca fait 1U, 2 au max, un bon load ballancer .. faut pas pousser qd meme.
Et pourquoi pas mettre en frontal un load-balancer qui orienterait les requetes vers X serveurs derrière (X = 2 suffirait probablement). Ainsi, il suffit de sortir un serveur à redémarrer du pool, masquant les problèmes de reload. De même, si l'un d'entre eux commence à répondre trop lentement, il est sorti du pool, jusqu'à ce qu'il réponde à nouveau "ocrrectement".
J'y avais pensé aussi.
Mais c'est trop complexe pour de la vraie prod qui doit être au moins aussi fiable dans la réalité que sur le papier. D'expérience, ce type d'usine à gaz qui ferait un swap en reconfigurant le load balancer toutes les dix minutes provoquerait davantage de pannes liées à la redondance plutot qu'aux défaillances qu'elle est sensée couvrir.
Pas besoin de reconfigurer le loadballancer toutes les dix minutes. Suffit de lui faire envoyer les requettes aux deux serveurs (ou deux serveurs sur un pool de X, le cas echeant) en lui disant de prendre en compte la réponse la plus rapide.
Propre et fault-tolerant, quoi que la remarque de Christophe est tres juste :)
Mais ca peut valloir pour un gros resolver.
Sans oublier son coût complètement délirant pour déployer sur trois sites distincts : - matos supplémentaire - espace en baie/courant supplémentaire - travail supplémentaire
Ca fait 1U, 2 au max, un bon load ballancer .. faut pas pousser qd meme.
