Pull to refresh
0

Преимущества выделенных серверов над облачными решениями на примере серверной архитектуры Tuffle.com

Reading time 3 min
Views 9.1K
Первую версию Tuffle мы запустили на облачном сервере от Selectel и какое-то время хостились там. Нам казалось, что «облачный сервер» расшифровывается как «плати фактическое потребление ресурсов и забудь о проблемах масштабирования и нехватки производительности». Но проблемы так и давали о себе знать… Так как статья не о Selectel, то мы просто перечислим причины, по которым нам пришлось искать иное решение.

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

2. Ограничения в управлении. Наш выделенный сервер в то же время был сервером виртуальным. Как следствие, все нестандартные операции совершались с использованием системы тикетов, а это жутко неудобно.

3. С ростом посещаемости пропорционально рос и ценник на сервер. Что, казалось бы, совершенно очевидно, только стоимость в определенный момент стала совершенно недемократичной и поставила под сомнение экономичность облачных решений.


А однажды нам написали, что с наших серверов идет DDoS-аттака. Мы все перепроверили, тревога оказалась ложной, но неприятный осадок остался.

В силу всего вышеперечисленного нами было принято решение организовать свое собственное серверное хранилище. Вот тут-то и начинается самое интересное.

По-настоящему выделенные серверы

А решение было такое:

1. Взять на вооружение пару “чистых” отдельных серверов
2. Разработать систему горизонтального масштабирования
3. Распределить между серверами персональные задачи. Иногда несколько задач.

Первым делом бросились искать, где же взять такие сервера, чтобы и канал хороший был, и цена не кусалась. В итоге остановились на Hetzner и купили сразу 8 серверов. И знаете, вышло дешевле, чем тот единственный у Selectel.

Требования к серверам

Для начала мы нарисовали таблицу, в которой расписали, для чего нам нужны сервера, какие они должны иметь характеристики и т.д.



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

Но, оказалось, что у Hetzner нельзя самому сконфигурировать железную начинку. Поэтому все наших 8 серверов были абсолютно одинаковые, а именно EX40. Кстати, стоит отметить, что для неевропейских стран можно смело вычесть из суммы 19 %, это VAT.

Выше мы говорили о масштабируемости. Итак: 3 основных направления по которым важна возможность быстрого масштабирования:

1. Сервера приложения. При высокой нагрузке именно они могут не справляться.
2. Сервера баз данных
3. Сервера контента

Остальное более-менее устойчиво.

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



Пользователь заходит на сайт и обращается к фронт-серверу, который может сам выполнить этот запрос (он в нашем случае и зовется master), или отправить этот запрос своему другу (slave сервер), который ничем не отличается от master. Поэтому, если мы столкнемся с ситуацией, когда не достаточно ресурсов 2-х серверов, нам нужно всего-лишь добавить еще один slave-сервер.

Похожая схема и с базами данных.

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

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

Серверное ПО

Технологический стек у нас не мудреный, работаем по классической схеме, проверенной годами. На входе Nginx — обрабатывает статику, отправляет динамические запросы на Apache. Код написан на PHP, используя Zend Framework. База данных — MySQL. Временное хранилище, а в некоторых случаях и постоянное — MongoDB.

Как же сервер определяет, куда отправить пользователя? Это делает сам Nginx, он балансирует между серверами приложений на основе IP-адресов клиентов. Запрос с одного IP будет попадать всегда на один и тот же сервер. Балансировка запросов осуществляется при помощи haproxy, который необходимо было установить на каждый сервер. Кроме того, haproxy балансирует запросы в режиме round-robin к MySQL.

Разумеется, мы перечислили только основу, еще установлено много ПО, которое занимается конвертацией видео (FFMPEG), фоновыми задачами и т.д.

Данные

Всё-таки мы работаем с тяжеловесным контентом, поэтому очень острой темой является резервное копирование данных. Мы сделали бэкапы инкрементными, но это не всё. Для своей же безопасности храним дынные на “третьих” серверах. О том, как настроены бэкапы в Tuffle, plutov уже писал в своем блоге.

Мониторинг

Серверов много, поэтому следить за ними нам помогает Munin. В нем легко отслеживаются все параметры как отдельно по серверам, так и в целом. Информирует о критических точках.



Вывод

Для нас это позитивный отказ от облачных решений. Примерно за полгода наш сервер ни разу не отключался, а Apache не умирал. Чего и вам желаем.
Tags:
Hubs:
+18
Comments 41
Comments Comments 41

Articles

Information

Website
tuffle.com
Registered
Founded
2012
Employees
2–10 employees
Location
Беларусь