7 апреля 2014 в 13:42

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

Первую версию 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 не умирал. Чего и вам желаем.
Автор: @Tuffle_Team
Tuffle
рейтинг 23,24
Компания прекратила активность на сайте

Комментарии (41)

  • +1
    А не проще было вместо аренды физических серверов арендовать инстансы в амазоне? Намного удобнее масштабироваться.
    Или боялись мифических выключений сервера?
    • +2
      Если честно, то просто хотелось иметь что-то более независимое, чем все эти облачные предложения. Во-вторых, можно же создать своё облако, которое будет дешевле и делать его будет интересно (на хабре даже есть статья сравнения стоимости 2-х решений). С этим решением мы уже не так жестко связаны с самим размещением серверов.

      Но, конечно, сначала было бы проще на Амазоне. Но с настроенной системой масштабирование — уже не проблема.
    • +2
      Я Вам скажу по своему опыту — Амазон совсем не дешевле Хецнера. Наш проект когда-то тоже хостился у компании Scalaxy, но после того как она умерла пришлось самим конструировать своё облако. Набрали железных серверов у Хецнера, поверх поставили Xen, и получили довольно неплохое решение. По деньгам в итоге получилось чуть дороже, зато мы смогли продублировать многие функции приложения и сейчас имеем такую конфигурацию, которая в облаках за эти деньги нам даже и не снилась.
      • +1
        А я и не говорил ничего про деньги. Я сказал про масштабирование.

        Развернуть дополнительные инстансы из шаблона в разы быстрее, чем добавлять физических серверов и настраивать их.
        • 0
          Ведь суть в разработке горизонтального масштабирования в том, чтобы при добавлении нового элемента, нужно было просто сделать клон одного звена. Слово «настраивать» в вашем комментарии значит что-то сложное, хотя между тем это всего лишь сделать клон машины, что делается за пару часов.
  • +4
    Любопытно! К сожалению, мой опыт с хетцнером был достаточно негативным. Особенно в плане замены серверов, в случае железных неполадок. Хотя саппорт частенько шел на встречу. Бывало, что в течении месяца на 12 серверах заменяются все диски.

    Со своей колокольни я бы вам порекомендовал отказаться от munin, в какой-то момент времени, у меня на мои 10 серверов в мониторинге, воркер рисовалка графиков стал отъедать 1 ядро (да он однопоточный) достаточно приличного сервака, а опрос серверов занимал до 8ми минут (при этом крон, по умолчанию, раз в 5 минут запускает опрос серверов). Я перешел на связку sensu+graphite и мне было счастье.
    • 0
      Огромное спасибо за совет. До этого не было опыта работы с мониторящим ПО, поэтому особо не заморачивались насчет выбора.
      • +1
        Обратите внимание, у яндекса в видеороликах было неплохое описание возможностей Graphite и как они его используют.

        tech.yandex.ru/events/yac/2013/talks/1122/
      • +1
        Мы раньше тоже сидели на munin. Сейчас используем Zabbix — очень довольны
        • +1
          Вот вы в заббикс начните кастомные метрики заводить в большом количестве, а так же попробуйте делать наложенные графики по нескольким метриками :) Я так же промолчу про объемы базы. А так же про удобство работы с дашбордами.

          Я уже дважды с заббиксом такое прошел.
        • +1
          Zabbix удобен тем, что умеет все функции мониторинга и много готовых шаблонов из коробки.
          Для простых задач — самое то. А если что по-сложнее надо, или более-менее отсутствующее в шаблонах — дуб дубом.
          • +1
            Он заточен под мониторинг сетевого оборудования и стандартных метрик, типа проца и LA.
            (риторическое) А вот попробуй в нем сделать, ну скажем график с метриками собранными с access.log, показателями кеша, LA, памяти и io? Чтобы сопоставить данные.
            • +1
              Можно, но это пытка.
              • +1
                В лучшем случае — это пытка и потерянное время! :)
                • 0
                  Не холивара ради, а лишь из простого интереса — где же там пытка? Содержимое логов выдирается стандартными log, подсчет через count(«log[...,like

                  Несколько calculated item'ов с подобранными коэффициентами накладываются на одном графике.

                  Чем сложно-то?
                  • 0
                    Согласен, не ради холивара.

                    Сугубо мои доводы:

                    1. освоение заббикса — 1 неделя, я иак и не понял, как быстро такое сделать. Размер базы за неделю сбора данных с 70% моих датчиков превысил 2 Гб. Дать программерам в руки инструмент для создания кастомной визуализации метрик, и к тому же быстрой — не возможно.
                    2. sensu+graphite — решение того же вопроса 2 дня (освоени так же с нуля). Размер баз grahite и до 500 метров не дошел. за счет развитых графитовских дашбордов у программеров есть интерфейс делать любые кастомные визуализации.
                    • 0
                      Крепкие доводы, могу согласиться с каждым. С наскока заббикс обычно не дается.

                      Тот же размер БД — довольно больная тема. Ума не приложу, как можно в стандартной поставке иметь _выключенный_ housekeeper :( Т.е. удаление старых данных банально не происходит, если не включить его специально в дебрях меню.

                      BTW, метрики с лог-файлов собираются в два приема. Для примера возьмем подсчет 50x-ошибок в nginx:
                      1) создаем Item с ключом
                      log["/var/log/nginx/access.log","\" 50",UTF-8,100]
                      2) создаем набор Calculated Item'ов с формулами на каждую из 50х ошибок
                      count("log[\"/var/log/nginx/access.log\",\"\\" 50\",UTF-8,100]",60," 500 ","like")

                      Рисуем графики по вкусу. Можно накладывать CPU, RAM, I/O.
                  • 0
                    Сложно то не сложно, но пока прощелкаешь через десятки менюшек заббикса для создания каждой метрики/алерта/графика — руки отвалятся, если ты не заядлый старкрафтер.
                    Плюс к этому, к его дубовому интерфейсу нужно долго привыкать, и пока не привыкнешь, все вышесказанное только усугубляется. К примеру, уже несколько лет с ним работаю, но постоянно то «Add», то «Save» забываю нажать, т.к. в некоторых местах это нужно сделать дважды.

                    Если таких метрик нужно немного, или если добавлять их понемногу, постепенно, то это в общем нормально, а если предполагается много и пробовать их комбинировать по-всякому, лучше сразу искать ему в этом замену.
                    • 0
                      Во-первых — это надо знать и понимать (заббикс)
                      Во-вторых — не дело админов нагружать постоянно программерскими запросами на графики
                    • +1
                      Для рутинных задач и автоматизации используйте API Zabbix'a. Для питона есть отличный клиент.
                    • 0
                      Там же можно клонировать проверки, переносить их массово между шаблонов и так же массово менять им однотипные параметры.
                      • 0
                        Учитывая так же, что написано выше.

                        Имеем 10 серверов, с каждого около 100-120 метрик, 30% этих метрик идут по принципу трапа, часто 5-15 в секунду.

                        Нужно:
                        — около 30 готовых графиков в рилтайме.
                        — неизвестное количество графиков «по требованию» (в моем случае было около 150), т.е. возможность делать графики «на лету», в т.ч. и комбинированные.
                        — набор стандартных графиков с обновлением по таймауту (от 30 сек до 5 мин)
                        — возможность добавления новых метрик без перезагрузки сервисов/клиентов.

                      • 0
                        Вот именно эти операции в нем и «тяжелые» в плане интерфейса.
                        • 0
                          Через пару тройку месяцев сбора данных, они будут не только тяжелыми в и-се, но и тяжелыми с БД. Проверено.
                          Собстенно каждый хорошо на своем месте, но тупизна и хреновое развитие систем обычных мониторинга порадили такие решения как sensu, graphite.
  • –1
    забудь о проблемах масштабирования и нехватки производительности
    дальше, в целом, можно не читать.

    master-slave репликация
    haproxy балансирует запросы в режиме round-robin к MySQL
    WAT

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

    впечатление, что маркетолог писал техническую статью.
    поставил минус с чистой совестью. нечем тут хвалиться, да и делиться таким опытом с другими — тоже.
    • 0
      Спасибо за отзыв, но вы не угадали, статью писал не маркетолог. Скорее всего, вы хотели увидеть больше подробностей, которые не очень связаны с общей темой об архитектуре.
  • 0
    То есть сервера взятые в аренду не известно где намного более «независимое решение», чем инстансы в амазоне? Риски одинаковы
    • 0
      1. Hetzner — это не неизвестно где
      2. Решение, которые сделано на Amazon, будет тяжело перенести на другое окружение. Наши серверы можно перенести куда угодно.
      • +3
        Это каким образом? Чем виртуалка на амазоне отличается от физического сервера в хецнере?
        • +1
          Сетевой инфраструктурой отличается. Амазон можно сказать впаривает свой баллансер на входе, свои сети и т.д.
          Такого один в один мало кто предлагает.
          Выделенный сервер — очень простое, понятное и популярное предложение, можно уехать куда угодно.

          Ну и ценник Амазона не совсем низкий. Я бы сказал совсем не низкий, выделенные сервера можно найти дешевле.
          • +1
            Ну вы еще скажите что у них в офисе чай не вкусный.

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

            И кстати, если выделенный сервер в хецнере умрет в пятницу вечером, а админы раздолбаи без мониторинга — то все выходные система работает в режиме недостатка ресурсов/недостатка резервных мощностей. Если умирает хост на амазоне — виртуалка перезапускается на другом хосте через пару минут.

            И хватит уже про деньги, пожалуйста, никто не говорит что амазон это супер дешево. Я лишь говорю, то что масштабироваться в условиях амазона намного проще, инфраструктура там надежней, а трава зеленее — то же справедливо и для Azure, и для прочих крупных игроков рынка public cloud.
            • 0
              Ну вы ещё скажите, что у них в офисе чай пили! А может вы с суппортом общались?

              100 серверов и полгода достаточно, чтобы был закреплён персональный менеджер, была персональная скидка и суппорт запомнил, что тут не идиоты сидят и если сказано что-то не работает, то оно не работает. И в воскресенье починят
              Я не про Хецнер, я про другие хостинги.

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

              • 0
                Ок, мне не трудно, я еще раз повторю.

                1. Я не говорю ничего про цену.
                2. Виртуалка на амазоне ничем не отличается от выделенного сервера в хецнере с точки зрения переноса куда-либо, при этом в амазоне проще масштабироваться — вот главный тезис, с которого начался этот тред, а Вы мне зачем-то про персональных менеджеров в других хостингах и про то что кто-то где-то говорит.

                Про неудобства амазона расскажите, например, дропбоксу.
  • +1
    1. У вам заключен договор с Хетцнером? мне просто интересно
    2. А решение, которое собрано в Хетцнере вы уже переносили? Если даже не пробовали, то и говорить тут не о чем.
    • 0
      Мне кажется, тут могут быть различные нюансы. Например, если сервера в Хетцнере виртуализованы, то перенести снэпшоты виртуалок не самая большая проблема. Даже инфраструктуру выделенных серверов можно организовать таким образом, чтобы они были относительно быстро переносимы и восстанавлеваемы.
  • 0
    Буквально в этом месяце ушли из Selectel к другому провайдеру.
    Причем в Selectel использовали арендованный «полноценный» сервер.

    Причина — периодические DDoS атаки на соседей по дата-центру, что приводит к недоступности наших серверов на 2-4 часа.
    Два раза терпели, потом всё, забрали.

    Сейчас стоит наш физический сервер в более «мелком» дата-центре и проблемы как рукой сняло.
    • 0
      Очень похожая ситуация была. А еще часто из-за каких-то профилактик канал был настолько узкий, что выдерживал ну хорошо если десяток пользователей.
  • 0
    ТС, а что за нестандартные операции над серверами имеете ввиду?
    • 0
      Так как это не совсем выделенный сервер, то и возможности ограничены. Оперативная память, как и CPU в каких-то пределах, которые не всегда удовлетворяли нас. Из-за каких-то глобальных настроек Selectel'а часто не работал какой-то функционал Linux, были большие проблемы с iptables, что мешало нормально работать SMTP.
  • +1
    Следующий шаг — собрать кластер из нескольких low-end десктопов у себя дома и рассказать о том, что получилось еще более бюджетно и почти так же круто, как у ведущих облачных провайдеров.

    А потом, когда пойдут первые дизастеры, придумывать отмазки «блок питания у сервера сгорел… подождите сутки пока заменим… подождали? оказывается еще и винт сгорел вместе с БП… ценные данные были? ничем не поможем, мы же бесплатный сервис, мы не даем гарантий».

    • 0
      А это идея!

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

Самое читаемое Разработка