Масштабирование web-сервиса на арендованных выделенных серверах с администрированием от хостера?

Question

[Сергей Сулаков]

Есть сайт, расположен у одного их хостеров на выделенном сервере с их администрированием. Соответственно, доступа к тонким настройкам не имеем. Подскажите, кто-то сталкивался с масштабированием в таких случаях? То есть арендуем еще один сервер, настраиваем, например Round Robin DNS. Но как в таких случаях быть с хранением сессий? Как с загружаемыми пользователями файлами. Данные сессии и загружаемые пользователями сайты хранятся на одном из серверов(на какой "попал" пользователь), а как получить доступ к ним с остальных? Нормально ли арендовать отдельный сервер для хранения сессий и файлов?

Comments

[sim3x]

Почему не обратитесь к админам хостера?

[Сергей Сулаков]

С ними я тоже общаюсь параллельно. Еще заказал тестовые периоды на два разных выделенных сервера - тестирую возможности

Answer 1

[Night]

Самый простой и дешевый способ переезда на горизонтальное масштабирование:

1. Сессии переезжают в Memcache, который находится на отдельном сервере
2. БД переезжает на отдельный сервер
3. Хранилище файлов, как бы это было не удивительно, тоже переезжает на отдельный сервак
4. Поднимается front нода, которая проксирует все запросы к backend нодам. Обычно это просто Nginx
5. Поднимаете Х нод полностью идентичных между собой с вашим софтом, но без БД, кэша, filestorage'а, используются ранее поднятые ноды для бд, кэша, файлов.
6. Весь трафик идет на front-ноду, которая балансирует трафик между вашим backend-нодами.
7. Все ноды работают с единой базой, с единым кэшом, единым filestorage'ем.
8. Нагрузка распределяется среди всеми нодами равномерно, вы счастливы.

Как результат, вы сможете добавлять сколь угодно backend серверов для разграничения нагрузки.

Обычно проблемы бывают с БД, и тогда приходится балансировать / шардить саму базу. Если проблема в этом, пишите, подскажем :)

Answer 2

[Иван Шумов]

1. О сессиях есть - такая вещь как Sticky Sessions
2. О балансировке - вам необходимы полностью Stateless сервисы. State должен находиться где-то ещё: Cache, Database, ... Но тогда и они должны быть масштабированы. То же и про хранилище. Стоит подумать про SOA архитектуру
3. Cloud Computing. Облака наше все: AWS, Azure... Но тут нужен специалист, который имеет хотябы минимальный опыт ибо этот мир несколько отличается от того к чему вы привыкли