LINUX.ORG.RU

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

 ,


0

1

Что почитать или у кого перенять опыт, чтобы научиться правильно структурировать и масштабировать инфраструктуру компании? Работаю в веб студии, есть ~20 серверов сконфигурированныx «все в одном» - dns, web-server, mail, db etc (обыкновенный хостинг для клиентов компании). Все проекты достаточно скоро начнут не умещаться на них, накидывать еще серверов, сконфигурированных таким же методом, не хочется, потому что это кажется неверным подходом.

В общем поделитесь, кто может, историей успеха. Кроме как в сети, спрашивать о таких вещах мне не у кого.

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

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

invokercd ★★★★
()
Ответ на: комментарий от invokercd

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

Alternating_Current
() автор топика
Ответ на: комментарий от invokercd

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

Alternating_Current
() автор топика
Ответ на: комментарий от Alternating_Current

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

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

dvrts ★★★
()

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

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

dvrts ★★★
()

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

все в одном

winlook38 ★★
()
Ответ на: комментарий от Alternating_Current

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

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

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

invokercd ★★★★
()
Ответ на: комментарий от dvrts

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

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

Alternating_Current
() автор топика
Ответ на: комментарий от Alternating_Current

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

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

dvrts ★★★
()
Последнее исправление: dvrts (всего исправлений: 1)
Ответ на: комментарий от Alternating_Current

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

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

dvrts ★★★
()
Ответ на: комментарий от invokercd

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

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

Alternating_Current
() автор топика
Ответ на: комментарий от AndreyKl

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

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

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

dvrts ★★★
()
Последнее исправление: dvrts (всего исправлений: 1)

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

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

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

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

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

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

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

puppy

Кого?

dvrts ★★★
()
Ответ на: комментарий от dvrts

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

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

puppet?

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

dvrts ★★★
()
Ответ на: комментарий от Alternating_Current

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

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

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

dvrts ★★★
()
Ответ на: комментарий от dvrts

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

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

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

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

dvrts ★★★
()
Ответ на: комментарий от dvrts

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

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

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

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

dvrts ★★★
()
Ответ на: комментарий от AndreyKl

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

dvrts ★★★
()
Ответ на: комментарий от dvrts

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

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

Alternating_Current
() автор топика
Ответ на: комментарий от Alternating_Current

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

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

но отзыв по 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, благо он уже достаточно стабилен и по сути уже является хорошим заделом на будущее для дальнейшего возможного роста инфраструктуры вширь и ввысь.

dvrts ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.