1 A-запись для каждого поддомена (10000+);есть какие-нибудь потенциальные проблемы?Есть какое-нибудь другое решение?

Question

Большинство решений, которые я прочитал здесь для поддержки субдомена для каждого пользователя на уровне DNS, заключаются в том, чтобы указывать все на один IP-адрес, используя * .domain.com .

Это простое решение, но что, если я хочу указать первым 1000 зарегистрированным пользователям на ServerA, а следующим 1000 зарегистрированным пользователям - на ServerB?Для нас это предпочтительное решение для снижения затрат на программное и аппаратное обеспечение для кластеризации.

альтернативный текст http://learn.iis.net/file.axd?i=1101 (диаграмма взята с сайта MS IIS)

Наиболее логичным решением кажется наличие 1 x A-записи на поддомен в файлах данных зоны.У BIND, похоже, нет никаких ограничений по размеру файлов данных зоны, они ограничены только доступной памятью.

Однако моя команда обеспокоена задержкой запуска и готовности нового поддомена, поскольку создание нового поддомена состоит из вставки новой A-записи и перезапуска DNS-сервера.

Стоит ли нам беспокоиться о производительности перезапуска DNS-сервера?

Заранее благодарю вас.

Обновить:

Похоже, большинство из вас предлагают мне вместо этого использовать обратную настройку прокси:

альтернативный текст http://learn.iis.net/file.axd?i=1102

(ARR - это решение для обратного прокси-сервера IIS7)

Однако вот МИНУСЫ, которые я вижу:

1. единственная точка отказа
2. невозможно стратегически настроить серверы в разных местах на основе геолокации IP.

Answer 1

Внешний прокси-сервер с подстановочной записью DNS действительно подходит для этого.Именно так работают такие крупные сайты, как LiveJournal.

Обратите внимание, что это не просто балансировщик нагрузки уровня TCP - существует множество решений, которые будут проверять часть URL-адреса хоста, чтобы выяснить, на какой внутренний сервер также переслать запрос.Вы можете легко сделать это с помощью Apache, работающего на низкопрофильном сервере с подходящая конфигурация.

Прокси-сервер гарантирует, что сеанс каждого пользователя всегда переходит на нужный внутренний сервер, и большинство любых методов обработки сеанса будут просто продолжать работать.

Кроме того, прокси-сервер не обязательно должен быть единственной точкой отказа.Вполне возможно и довольно легко запустить два или более интерфейсных прокси-сервера в избыточной конфигурации (чтобы избежать сбоя) или даже разделить с ними нагрузку (чтобы избежать стресса).

Я бы также поддержал предложение Джона Шиэна о том, чтобы приложение просто смотрело на левую часть URL-адреса, чтобы определить, контент какого пользователя отображать.

Если вы используете Apache для серверной части, смотрите этот пост также для получения информации о том, как это настроить.

Answer 2

Используйте подстановочную запись DNS, затем используйте балансировку нагрузки для распределения нагрузки между серверами, независимо от того, каким клиентом они являются.

Пока вы этим занимаетесь, пропустите этап перезаписи URL-адреса и попросите ваше приложение определить, к какой учетной записи оно относится, на основе введенного URL-адреса (вы можете так же легко определить, что такое X в X.domain.com как в домене.com?user=X).

Редактировать:Основываясь на вашей дополнительной информации, вы можете захотеть разработать "брокера", который хранит, какие клиенты должны получать доступ к каким серверам.Сделайте это общедоступным, а затем извлекайте данные из ресурсов, связанных с клиентом, хранящихся у брокера.Ваш интерфейс может быть сбалансирован по нагрузке, тогда вы сможете получать данные с файловых серверов / баз данных в зависимости от того, кем они являются.

Answer 3

Если вы используете tinydns, вам не нужно перезапускать сервер имен, если вы изменяете его базу данных, и это не должно быть узким местом, потому что обычно оно работает очень быстро.Я не знаю, хорошо ли он работает с более чем 10000 записями (меня бы удивило, если бы это было не так).

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