Как стать автором
Обновить

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

Время на прочтение3 мин
Количество просмотров9.1K
Всего голосов 42: ↑30 и ↓12+18
Комментарии41

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

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

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

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

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

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

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

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

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

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

Тот же размер БД — довольно больная тема. Ума не приложу, как можно в стандартной поставке иметь _выключенный_ 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.
Сложно то не сложно, но пока прощелкаешь через десятки менюшек заббикса для создания каждой метрики/алерта/графика — руки отвалятся, если ты не заядлый старкрафтер.
Плюс к этому, к его дубовому интерфейсу нужно долго привыкать, и пока не привыкнешь, все вышесказанное только усугубляется. К примеру, уже несколько лет с ним работаю, но постоянно то «Add», то «Save» забываю нажать, т.к. в некоторых местах это нужно сделать дважды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А это идея!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий