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

Question

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

Это простое и простое решение, но что если я захочу указать первую 1000 зарегистрированных пользователей на сервер A, а следующие 1000 зарегистрированных пользователей на сервер B? Это предпочтительное решение для нас, чтобы снизить затраты на программное и аппаратное обеспечение для кластеризации.

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

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

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

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

Заранее спасибо.

UPDATE:

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

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

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

Тем не менее, вот МОДУЛИ, которые я вижу:

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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