Горизонтальное масштабирование: маршрутизация пользовательских поддоменов между серверами

Question

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

В настоящее время каждый поддомен каждого пользователя попадает в тот же виртуальный хост, где один фронт-контроллер PHP отображает соответствующий контент на основе имени хоста. Единственная подстановочная DNS-запись для * .mydomain.com указывает на текущий сервер.

Каков наилучший вариант для маршрутизации различных поддоменов пользователей на разные серверы?

Мои мысли:

• новый домен верхнего уровня для каждого сервера. user.s1.mydomain.com, user.s2.mydomain.com и т. д. (информация о неэлементах и ​​утечках)
• Запуск моего собственного DNS-сервера для маршрутизации пользователей между серверами (дополнительная точка отказа, незнакомая технология)
• A центральный фронт-контроллер/балансировщик, который обратный-проксирует каждый запрос на соответствующий сервер (дополнительная точка отказа, потенциально ограниченные соединения)

Answer 1

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

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

upstream upstream_regular_backend { 
    fair; 
    server 10.0.0.1:80; 
    server 10.0.0.2:80; 
} 

server { 
    listen 0.0.0.0:80; 
    server_name example.com; 
    proxy_set_header Host $host; 
    proxy_set_header X-Real-IP $remote_addr; 
    location/{ 
     proxy_pass http://upstream_regular_backend; 
    } 
} 

Для обслуживания статического контента и передачи обратно все остальное, что-то вроде:

server { 
    listen 0.0.0.0:80; 
    server_name example.com; 
    proxy_set_header Host $host; 
    proxy_set_header X-Real-IP $remote_addr; 
    index index.php; 
    root /some/dir/: 
    location ~ \.php { 
     proxy_pass http://upstream_regular_backend; 
    } 
} 

Естественно, если вы не используете PHP, настройки конфигурации соответственно.

По определению вверху, «справедливое»; будут основываться на балансировке баланса на основе времени отклика. Для мотивов кэширования вы можете использовать «ip_hash;» вместо этого, поскольку он будет обрабатывать запросы от клиента всегда на одном сервере.

Наша установка немного дальше по дороге. У нас есть nginx load-balancers, проксирующий кэш лака, который, в свою очередь, проксирует серверы динамического контента.

Если вы беспокоитесь о том, что nginx является одноточечным отказом, настройте вторичный сервер, готовый принять IP-адрес интерфейса в случае его отказа.