Назад | Перейти на главную страницу

DNS с подстановочными знаками, размещенный DNS или DNS-сервер

Я создаю сайт, на котором пользователи могут создать свой собственный сайт. Пользователь вводит имя сайта (скажем, site1), и сайт создается с поддоменом site1.example.com. В настоящее время я настроил DNS с подстановочными знаками для одного сервера, на котором был создан сайт. Это нормально работает, но недостаточно масштабируемо для использования в будущем.

Я хотел бы иметь возможность контролировать, на каком сервере создается сайт. Например, site1 создается на server1, а site2 создается на server2. Я искал несколько решений.

  1. Настроить собственный DNS-сервер и создать поддомен до создания сайта.
  2. Использование какого-то размещенного DNS-сервера с API для создания домена.
  3. Используйте IIS каким-либо образом, чтобы я мог перенаправить свой DNS с подстановочными знаками на поддомен, размещенный на сервере.

Я предпочитаю решение IIS, но не нашел ни одного примера по его настройке, или если это вообще возможно.

Возможно, есть какие-то открытые или платные решения.

Есть много способов решить эту проблему, но лучшее решение зависит от ваших ограничений, среды, типов сайтов и т. Д. Например:

  • Разве один сервер не может обрабатывать все сайты из-за размера контента на каждом сайте или из-за создаваемой нагрузки / трафика?
  • Хранится ли контент в виде файлов или в базе данных?
  • На сайтах запущено приложение, требующее общего состояния? Общее состояние хранится в памяти или на другом сервере или кластере серверов?
  • Требуется ли для каждого сайта собственное развертывание приложения или приложение поддерживает мультитенантность (в основном, может ли оно посмотреть, какое имя хоста было запрошено, и использовать его в качестве своего сайта - именно так большинство CMS / e, размещенных на нескольких клиентах) -коммерческие приложения работают)
  • Может ли один сайт вырасти настолько, что с ним не сможет справиться один сервер?

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

"Типичный" способ настроить это - иметь несколько уровней:

  • Уровень базы данных (очень мощная пара аварийного переключения, ведущая / ведомая системы или кластер, в зависимости от вашей платформы БД)
  • Уровень состояния сеанса (может храниться на уровне БД, отдельной БД, сервере состояния сеанса IIS, memcached или чем-то подобном)
  • Уровень приложения (ваш сервер приложений - IIS)
  • Уровень балансировки нагрузки (выделенное оборудование, nginx, HAproxy и т. Д.)

Здесь есть несколько ключевых моментов:

  • Любой сервер приложений может обработать запрос для любого «сайта» (потому что это одно и то же приложение, и все они подключаются к одной базе данных)
  • Состояние вашего сеанса должно быть общим и доступным для всех серверов приложений.
  • Уровень вашей базы данных должен выдерживать нагрузку одновременного доступа со всех серверов приложений. Большинство людей используют кеширование в разных точках, чтобы эта работа работала.
  • Если вы стремитесь к высокой доступности, вам необходимо иметь емкость N + 1: например, если для вашей пиковой нагрузки требуется 10 серверов приложений, у вас должно быть как минимум 11.
  • Часто на большом сайте люди выгружают свой статический контент (изображения, CSS и т. Д.) На другой сервер или даже в CDN, например Akami или Amazon CloudFront.

Настройка довольно гибкая. Вы можете добавить МНОГО серверов приложений. Вы можете самостоятельно изменить настройку любого тира. У вас нет единой точки отказа (например, вы можете терпеть потерю одного или двух серверов, чтобы никто этого не заметил).

Даже если ваше приложение не поддерживает мультитенантность, у вас есть несколько вариантов:

  • Разверните каждый сайт на каждом сервере (примечание: для этого требуется, чтобы у вас был способ также синхронизировать все файлы для установки / обновлений, и чтобы вы не хранили какой-либо контент локально)
  • Разверните каждый сайт на каждом сервере, но храните контент на централизованном (и избыточном) NAS или SAN
  • Разверните сайты выборочно, а затем используйте балансировщик нагрузки для направления трафика на соответствующий сервер на основе имени хоста.

Взгляни на Настройка StackExchange, что на самом деле довольно близко к тому, что я только что описал:

Ваша проблема заключается в программном создании записей DNS?

В таком случае вы можете использовать NicTool. Он имеет обширный API для управления вашим DNS и может работать со многими серверами имен.

Отказ от ответственности: я использую NicTool на работе, и я установил автоматизацию, которая сэкономила нам значительные средства.

Для этого есть несколько решений. А как насчет статического определения места назначения сервера на основе домена? Например, после создания site12, если хеш site12 четный, то он переходит на server1, иначе он переходит на server2.