1 enregistrement A pour chaque sous-domaine (10000+); des problèmes potentiels? Une autre solution?

Question

La plupart des solutions que j'ai lues ici pour prendre en charge les sous-domaines par utilisateur au niveau DNS consistent à faire pointer le tout sur une adresse IP à l'aide de * .domain.com.

C’est une solution simple et facile, mais que se passe-t-il si je veux diriger les 1000 premiers utilisateurs enregistrés vers serverA et les 1000 prochains utilisateurs enregistrés vers serverB? C’est la solution que nous privilégions pour réduire nos coûts en logiciels et en matériel pour la mise en cluster.

texte alt http://learn.iis.net/file.axd?i = 1101 (schéma cité sur le site MS IIS)

La solution la plus logique semble avoir 1 x enregistrement A par sous-domaine dans les fichiers de données de zone. BIND ne semble pas avoir de limite de taille sur les fichiers de données de zone, mais uniquement sur la mémoire disponible.

Cependant, mon équipe s’inquiète de la latence de la préparation et de la préparation de la nouvelle sous-analyse, car la création d’un nouveau sous-domaine consiste à insérer un nouvel enregistrement A & record; redémarrage du serveur DNS.

Les performances du redémarrage du serveur DNS devraient-elles nous préoccuper?

Merci d'avance.

UPDATE:

On dirait que la plupart d'entre vous me suggèrent d'utiliser une configuration de proxy inverse à la place:

texte alternatif http://learn.iis.net/file.axd?i = 1102

(ARR est la solution de proxy inverse d'IIS7)

Cependant, voici les inconvénients que je peux voir:

1. point unique d'échec
2. ne peut pas configurer de manière stratégique les serveurs dans différents emplacements en fonction de la géolocalisation IP.

Answer 1

Le proxy frontal avec une entrée DNS générique est vraiment la solution. C’est ainsi que fonctionnent les grands sites comme LiveJournal.

Notez qu'il ne s'agit pas simplement d'un équilibreur de charge de couche TCP: de nombreuses solutions examinent également la partie hôte de l'URL pour déterminer le serveur dorsal sur lequel transférer la requête. Vous pouvez facilement le faire en utilisant Apache sur un serveur de faible spécification avec la configuration appropriée .

Le proxy veille à ce que la session de chaque utilisateur aille toujours vers le bon serveur principal et que la plupart des méthodes de traitement de session continuent de fonctionner.

De plus, le proxy ne doit pas nécessairement être un point de défaillance unique. Il est tout à fait possible et assez facile d’exécuter deux mandataires frontaux ou plus dans une configuration redondante (pour éviter les pannes) ou même de les faire partager la charge (pour éviter les contraintes).

J'appuie également la proposition de John Sheehan selon laquelle l'application devrait simplement regarder la partie gauche de l'URL pour déterminer le contenu de l'utilisateur à afficher.

Si vous utilisez Apache pour le back-end, consultez ce message aussi pour des informations sur la façon de le configurer.

Answer 2

Utilisez l'entrée DNS générique, puis utilisez l'équilibrage de la charge pour répartir la charge entre les serveurs, quel que soit leur client.

Pendant que vous y êtes, ignorez l'étape de réécriture de l'URL et demandez à votre application de déterminer le compte sur lequel elle repose en fonction de l'URL telle qu'elle a été entrée (vous pouvez tout aussi facilement déterminer quel X se trouve dans X.domain.com ou dans le domaine. com? utilisateur = X).

EDIT: En fonction de vos informations supplémentaires, vous souhaiterez peut-être créer un "courtier". qui stocke quels clients doivent accéder à quels serveurs. Faites en sorte que le public soit directement affecté aux ressources associées au client stockées chez le courtier. Votre front-end peut être équilibré, puis vous pouvez extraire des serveurs de fichiers / bases de données en fonction de leur identité.

Answer 3

Si vous utilisez tinydns, vous n'avez pas besoin de redémarrer le serveur de noms si vous modifiez sa base de données et cela ne devrait pas être un goulot d'étranglement car il est généralement très rapide. Je ne sais pas si cela fonctionne bien avec plus de 10000 entrées cependant (cela me surprendrait sinon).

http://cr.yp.to/djbdns.html