Развитие IT-инфраструктуры

веб-студия и хостинг это как бы разные вещи (на нормальном уровне).

Если просто нужно размещать клиентов я бы выбрал облако по вкусу

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

По сути, хочу, чтобы все было как у «больших дядек». Чтобы если вдруг повалит куча клиентов, все можно было легко расширить.

Чтобы если вдруг повалит куча клиентов, все можно было легко расширить.

Тебе неспроста порекомендовали облако - со своим железом такой гибкости достичь невозможно (или не будет хватать железа, или накупить с избытком, и половина будет простаивать).

~20 серверов сконфигурированныx «все в одном» - dns, web-server, mail, db etc

Физические или виртуализированные? Если там нет виртуализации, то это просто смешно.

По моему ответ заложен в самом вопросе. Где-то вот тут: «20 серверов сконфигурированныx «все в одном»».

все в одном

Это невозможно, большие дяди обладают большими средствами. Это их бизнес - много клиентов, хороший сапорт и хорошие спецы (в идеале).

Вообще все зависит от необходимого масштабирования, можно тупо взять proxmox и давать каждому клиенту по контейнеру и одному ip адресу. Разворачивается тачка из шаблона (который можно запилить под свои нужды). Мне трудно что-то советовать без понимания количества приложений и железа.

Кстати держать все на одном сервере - это очень плохая идея, особенно dns и sql

Физические, поэтому я и спрашиваю, как такая связка реализована у нормальных людей. Все сущности просто на разных хостах или в виртуалках или кластера какие строят? Вот пример для конкретики, почтовый сервер на кучу доменов и есть только обычные сервера (без СХД). Лучше поместить все на несколько виртуалок или на физ. хостов или на часть из них поставить FreeNAS, чтобы имитировать СХД?

То есть я не очень компетентен в вопросе, но если подсказать направление, то разберусь.

У нормальных людей все сервисы разнесены по разным хостам, в идеале виртуальным и распределенным. То есть на железе стоит гипервизор, выше крутятся виртуалки (полноценные или контейнеры, в зависимости от задачи) с различными сервисами.

Само собой, если уж все делать с умом, то делается избыточность.

Лучше поместить все на несколько виртуалок или на физ. хостов или на часть из них поставить FreeNAS, чтобы имитировать СХД?

Если есть возможность сделать коннект между физическими хостами с сетью порядка 10 гигабит, стоит вынести отдельно сервера для хранения данных (упор на кучу девяток в плане доступности данных), и сервера, занимающиеся вычислениями (упор на CPU/RAM). Естественно, как я указал выше - все сервисы должны крутиться в виртуалках.

Кстати держать все на одном сервере - это очень плохая идея, особенно dns и sql

Цель - переделать все это в ту структуру, которую все мне в теме описывают, уже понял направление, куда копать. Буду пробовать.

со своим железом такой гибкости достичь невозможно

а своё облако? по моему вполне решение.

Свое облако - это опять-таки свое железо. Что означает что при неправильном планировании нагрузки у нас есть два варианта:

а) при недостаточном «количестве» своего железа при резком повышении количества клиентов у нас нет достаточно ресурсов чтоб им отдать; б) у нас достаточно своего железа - накупили с головой. Абсолютно реальна ситуация когда клиентов намного меньше чем предполагаемая утилизация железа - означает что оно простаивает и мы потратили больше денег чем должны были.

С публичными же облаками такой вопрос исключен - в три клика мы расширяем инфраструктуру при увеличении нагрузки, в три клика уменьшаем при ее понижении (то есть не платим за то, что не используем). Если этот процесс автоматизировать, то вообще сказка.

я на твоём месте разбил бы сначала:

dns, sql, web, mail - по крайней мере четыре типа вырисовывается. Каких то серверов у тебя будет всего ничего, 1 днс (если приватный, два или один свой + один секондари платный, если публичный), mail, тоже один. а каких-то будет кучка: ориентировочно это db и web. напиши скрипт для разворачивания их с помощью каких нибудь puppy или вроде того.

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

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

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

Виртуализацией нужно заморачиваться с самого начала, чтоб потом не мудохаться виртуализированием уже работающих сервисов. Не использовать виртуализацию в 2015-м году - моветон и признак некомпетентности специалиста.

puppy

Кого?

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

puppet?

РЕД. да, виноват, puppet. уже забыл как называется.

Если физическую железку полностью надо отдать под какой-то сервис, то тоже виртуализировать?

А какое отношение имеет уровень зарплаты к использованию публичных облаков?

puppet?

Да, но я бы не рекомендовал его без сильной на то надобности. Лучше/проще - chef, а особенно ansible.

Если физическую железку полностью надо отдать под какой-то сервис, то тоже виртуализировать?

Приведи пример такого сервиса.

Вообще отказываясь от виртуализации ты лишаешь себя гибкости и удобства работы с такими сервисами. Такое можно делать только если ты ГАРАНТИРОВАННО знаешь что сервис не будет расширяться, мигрировать, модернизироваться и т.д. То есть как раз задеплоил, так и будет вечно стоять.

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

Последние несколько лет я работаю исключительно с облачными сервисами. Зарплата моя меньше $3k. Что не так?

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

И повторно обращаю внимание на то, что со своим железом мы теряем в гибкости и масштабируемости, пример я приводил выше.

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

Понял, спасибо.

Мне лень таким заниматься)

Я могу сказать одно - с физической инфраструктурой за последнее время я работал лишь на одном проекте, когда мы сами строили публичное облако на Openstack. Все остальное - это Amazon, иногда DO.

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

я соглашусь что с правильно настроеной виртуализацией лушче чем без. но тут ведь вопросы, как у них там это всё организовано, да может у человека сроки жмут или ещё что. в целом конечно если грамотно подходить то с нею лучше чем без неё. но ведь у человека явно опыта маловато, он просто не сможет из неё извлечь выгоду (читай правильно настроить под свои нужды). Я всё таки советовал бы настроить на железе просто разбив по «профилям»: мейл, днс, веб, sql. ну и какую то систему управления зоопарком, тут я не силён, ansible значит ansible. Это будет рабочее решение. А потом идти разбираться с виртуализацией или собственным облаком на опенстек например.

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

если сроки не жмут, я бы однозначно глядел на опенстек. я работал лично с kvm и могу сказать что руками виртуалками рулить не сахар, настройки всего этого без тулзы вроде puppet (или чего там ещё) сжирают всё время. Поэтому только автоматизация. причём не самописная лучше чем самописная. гораздо.

но отзыв по openstack надо попросить у тех кто работал с этим, вот хотя бы dvrts

но отзыв по openstack надо попросить у тех кто работал с этим

Я работал с ним, и хочу сказать что один человек не сможет одновременно держать все подпорки и костыли чтоб его полноценно юзать. Это отличное, но пока еще сырое решение, да и не предназначено оно для этого. Это отличная ЗАГОТОВКА для построения чего-то своего, но не ready-to-use решение. Мы строили крупное публичное облако на большом количестве железа, где заказчик особо денег и ресурсов не жалел, и цель этого всего была другая - это должно было быть публичное облако для юзеров (по типу того же amazon, rackspace, DO). То есть совершенно разные масштабы по сравнению с целями ТС.

У openstack есть немало плюсов, но эти плюсы в свою очередь дают большой оверхед по сравнению с решениями на голом KVM. То есть нужно четко понимать для чего и зачем он нужен.

К тому же относительно недавно dyasny сформулировал свою точку зрения насчет юзкейсов для инспользования и неиспользования openstack - если вкратце, то критичные к падениям и динамические сервисы должны располагаться вне openstack (на гипервизоре), некритичные, но важные (которые могут падать и система должна быстро поднимать клон упавшей VM с сервисом) - на openstack. Гугли pets&cattle.

Если ТС будет админить сам все самостоятельно, и я правильно понял масштабы задачи, то стоит обратить внимание на два продукта - Proxmox и oVirt. Причем второе - enterprise-ready, по сути апстрим для коммерческой RHEV, где будет куча всяких плюшей.

Proxmox - порог вхождения ниже, есть плюшки типа одновременного руления как полностью виртуализированых машин (KVM), так и контейнеров (OpenVZ), но мне сама концепция не очень нравится. Во первых, сильно костыльное свое ядро, на деле ядро с шестого CentOS с OpenVZ, прикрученное к дебиановскому юзерспейсу, второе - явный упор на коммерческое использование продукта. Есть бесплатные репозитории, но якобы софт в них нестабилен.

Так что я бы порекомендовал присмотреться к oVirt, благо он уже достаточно стабилен и по сути уже является хорошим заделом на будущее для дальнейшего возможного роста инфраструктуры вширь и ввысь.

спс за отзыв.