Комментарии 32
Спасибо, интересная статья!
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E56151BF
Не используйте short gpg key id и другим не советуйте. Дешевые коллизии на них получили ещё в 2011 году. Сейчас коллизия получается за 4 секунды https://evil32.com/.
Спасибо за статью!
Скажите пожалуйста, используете ли Mesos+Marathon в продакшене?
Скажите пожалуйста, используете ли Mesos+Marathon в продакшене?
Да, используем. Но в основном для stateless-сервисов. Базы как и раньше живут на отдельных виртуалках.
А были ли какие нибудь проблемы? Что происходит в случае падения слейва? Маратон поднимает их на других слейвах?
Смотрели в сторону kubernetes?
Имел неприятный опыт от попытки использования Маратона. В azure есть шаблон Mesos+Marathon, которые поднимает машинки и устаналивает. Попытался поднимать контейнеры в Маратоне, ничего не происходило к сожалению.
Смотрели в сторону kubernetes?
Имел неприятный опыт от попытки использования Маратона. В azure есть шаблон Mesos+Marathon, которые поднимает машинки и устаналивает. Попытался поднимать контейнеры в Маратоне, ничего не происходило к сожалению.
>> А были ли какие нибудь проблемы?
Ну проблемы всегда есть, очень зависит от конечного сервиса, который хотите загнать в контейнер. Плюс, кластер, который сейчас есть у нас проде — не моя затея и я не все знаю.
>> Что происходит в случае падения слейва? Маратон поднимает их на других слейвах?
Да, все так. И даже падение одного из мастеров не приводит к даунтайму.
>> Смотрели в сторону kubernetes?
Особо нет. Знаю только что мультимастер в kubernetes появился совсем недавно.
Попробуйте все повторить по этой статье — уверен, у вас получится :)
Ну проблемы всегда есть, очень зависит от конечного сервиса, который хотите загнать в контейнер. Плюс, кластер, который сейчас есть у нас проде — не моя затея и я не все знаю.
>> Что происходит в случае падения слейва? Маратон поднимает их на других слейвах?
Да, все так. И даже падение одного из мастеров не приводит к даунтайму.
>> Смотрели в сторону kubernetes?
Особо нет. Знаю только что мультимастер в kubernetes появился совсем недавно.
Попробуйте все повторить по этой статье — уверен, у вас получится :)
а на dcos не пробовали переезжать?
Интересный продукт, если знаете пара вопросов:
1) Что происходит с запущенными процессами при внезапной смерти slave ноды? Процессы перезапустятся на других нодах?
2) Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?
1) Что происходит с запущенными процессами при внезапной смерти slave ноды? Процессы перезапустятся на других нодах?
2) Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?
>> Что происходит с запущенными процессами при внезапной смерти slave ноды? Процессы перезапустятся на других нодах?
Да, на других рабочих слейвах. Но при условии, что на нем есть необходимые мощности. Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
>> Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
Каждому процессу выделяется определенное к-во памяти, и цпу. В случае, если хард ввесь роздан, новые контейнеры (задачи в Марафоне) не будут создаваться (будут висеть в состоянии Waiting) и начнут создаваться только при добавлении дополнительного слейва. Кластер, который будет выбран для каждого следующего контейнера выбирается достаточно случайным образом. Конечно же, если вы хотите высокой доступности — то следует иметь как минимум 2 ноды (на вторую будут переезжать контейнеры первого слейва, в случае ее поломки. Но не нужно забывать, что на втором должны быть мощностя для сервисов с первого слейва). Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
>> 3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
В моем понимании, да, есть. Если падает лидер среди мастеров и потом он же появляется — то возврата назад только по этой причине не будет. Со слейвами все аналогично. Слейв падает — контейнеры расходятся по слейвам, что живы и при появлении старого слейва они уже возвращаться не будут. На появившемся слейве будут пускаться новые задачи Марафона.
>> 4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
Насколько я знаю, нет. Да и они не особо нужны, потому что Докер как раз чудесно ложится в парадигму микросервисов и Месоса. Ну т.е. если слейв упадет, то с OpenVZ/LXC миграция данных никак и не произойдет. Т.е. как раз при пересоздании Докер-контейнера мы ничего не потеряем, т.к. наш сервис stateless.
В случае, если вы хотите запускать базы — то есть варианты с отдельным стореджом (Flocker), который будет подключаться к новому контейнеру, в случае падения старого. Ну а образы, которыми управляет Флокер, будут лежать на какой-то кластерной ФС типа Ceph.
>> 5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?
Как я говорил, есть Флокер, который может при пересоздании контейнера привязывать новому старые данные, что лежат на какой-то кластерной ФС. Но подробностей с репликациями я вам не подскажу. Но думаю с реляционными базами, которые следят за позициями при репликациях, может быть не легко. Я в общем, не все знаю.
Да, на других рабочих слейвах. Но при условии, что на нем есть необходимые мощности. Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
>> Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
Каждому процессу выделяется определенное к-во памяти, и цпу. В случае, если хард ввесь роздан, новые контейнеры (задачи в Марафоне) не будут создаваться (будут висеть в состоянии Waiting) и начнут создаваться только при добавлении дополнительного слейва. Кластер, который будет выбран для каждого следующего контейнера выбирается достаточно случайным образом. Конечно же, если вы хотите высокой доступности — то следует иметь как минимум 2 ноды (на вторую будут переезжать контейнеры первого слейва, в случае ее поломки. Но не нужно забывать, что на втором должны быть мощностя для сервисов с первого слейва). Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
>> 3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
В моем понимании, да, есть. Если падает лидер среди мастеров и потом он же появляется — то возврата назад только по этой причине не будет. Со слейвами все аналогично. Слейв падает — контейнеры расходятся по слейвам, что живы и при появлении старого слейва они уже возвращаться не будут. На появившемся слейве будут пускаться новые задачи Марафона.
>> 4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
Насколько я знаю, нет. Да и они не особо нужны, потому что Докер как раз чудесно ложится в парадигму микросервисов и Месоса. Ну т.е. если слейв упадет, то с OpenVZ/LXC миграция данных никак и не произойдет. Т.е. как раз при пересоздании Докер-контейнера мы ничего не потеряем, т.к. наш сервис stateless.
В случае, если вы хотите запускать базы — то есть варианты с отдельным стореджом (Flocker), который будет подключаться к новому контейнеру, в случае падения старого. Ну а образы, которыми управляет Флокер, будут лежать на какой-то кластерной ФС типа Ceph.
>> 5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?
Как я говорил, есть Флокер, который может при пересоздании контейнера привязывать новому старые данные, что лежат на какой-то кластерной ФС. Но подробностей с репликациями я вам не подскажу. Но думаю с реляционными базами, которые следят за позициями при репликациях, может быть не легко. Я в общем, не все знаю.
Спасибо за развернутый ответ, пара неясностей осталась.
>>Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
Вопрос не как они расходятся при запуске, с этим обычно нет проблем ни у одной кластерной системы, но представим ситуацию мы запустили много процессов, они успешно разошлись по нодам, но в какой-то момент часть из них успешно завершилась и возникает ситуация, что одна нода загружена в полку, а остальные простаивают, вот для такой ситуации живая миграция очень необходима.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
>> Докер как раз чудесно ложится в парадигму микросервисов и Месоса
Не всегда, иногда микросервис требует более полного воссоздания окружения, когда в один контейнер мы запихиваем несколько процессов вместе с их взаимосвязью, плюс имеем изменяемую ФС (не все сервисы умеют писать все свои изменения в БД) на время работы контейнера, так как нам нужно чтоб он сохранял свое состояние после перезапуска, бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
>>Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
Вопрос не как они расходятся при запуске, с этим обычно нет проблем ни у одной кластерной системы, но представим ситуацию мы запустили много процессов, они успешно разошлись по нодам, но в какой-то момент часть из них успешно завершилась и возникает ситуация, что одна нода загружена в полку, а остальные простаивают, вот для такой ситуации живая миграция очень необходима.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
>> Докер как раз чудесно ложится в парадигму микросервисов и Месоса
Не всегда, иногда микросервис требует более полного воссоздания окружения, когда в один контейнер мы запихиваем несколько процессов вместе с их взаимосвязью, плюс имеем изменяемую ФС (не все сервисы умеют писать все свои изменения в БД) на время работы контейнера, так как нам нужно чтоб он сохранял свое состояние после перезапуска, бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
>>> но представим ситуацию мы запустили много процессов, они успешно разошлись по нодам, но в какой-то момент часть из них успешно завершилась и возникает ситуация, что одна нода загружена в полку, а остальные простаивают, вот для такой ситуации живая миграция очень необходима.
одна нода не загружена так чтобы это мешало работе других контейнеров (задач) на этой же ноде. В Месосе нет овершаринга ресурсов, т.е. роздается только то количество мощностей, которое есть. То что прям вы спрашиваете — не факт, что возможно и я не совсем понимаю зачем это нужно. Если вы захотите убрать работающий слейв — то при наличии мощностей на других слейвах — они туда и мигрируют.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
Как я это все понимаю, нет, нельзя. Но я могу что-то не знать. По-дефолту это так.
>>> Не всегда, иногда микросервис требует более полного воссоздания окружения
Значит ваш докерфайл должен описывать вот это все и сетапаться со всем необходимым. Все дополнительные данные должны копироваться в новый контейнер или же монтироваться и перетаскиваться каким-то флокером, в случае падения контейнера.
>>> бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
Опишите конкретный кейс.
одна нода не загружена так чтобы это мешало работе других контейнеров (задач) на этой же ноде. В Месосе нет овершаринга ресурсов, т.е. роздается только то количество мощностей, которое есть. То что прям вы спрашиваете — не факт, что возможно и я не совсем понимаю зачем это нужно. Если вы захотите убрать работающий слейв — то при наличии мощностей на других слейвах — они туда и мигрируют.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
Как я это все понимаю, нет, нельзя. Но я могу что-то не знать. По-дефолту это так.
>>> Не всегда, иногда микросервис требует более полного воссоздания окружения
Значит ваш докерфайл должен описывать вот это все и сетапаться со всем необходимым. Все дополнительные данные должны копироваться в новый контейнер или же монтироваться и перетаскиваться каким-то флокером, в случае падения контейнера.
>>> бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
Опишите конкретный кейс.
>>>Как я это все понимаю, нет, нельзя. Но я могу что-то не знать. По-дефолту это так.
разумеется что нельзя, логично же — почти всем нодам нельзя стартовать с меньшими ресурсами, потому если указано что ноде надо 8гб, то ей надо 8 гб и стартовать ее с 6 нельзя.
если эпизодически нужны ресурсы это называется autoscale — https://github.com/mesosphere/marathon-autoscale
в общем если коротко — выделяя ресурсов на ноду в марафоне больше, чем ему надо, в расчете на эпизодическую нагрузку, вы явно что-то не так делаете в плане архитектуры приложения. лучше 2 ноды по 4 гб чем 1 на 8. а еще лучше 3 по 2
разумеется что нельзя, логично же — почти всем нодам нельзя стартовать с меньшими ресурсами, потому если указано что ноде надо 8гб, то ей надо 8 гб и стартовать ее с 6 нельзя.
если эпизодически нужны ресурсы это называется autoscale — https://github.com/mesosphere/marathon-autoscale
в общем если коротко — выделяя ресурсов на ноду в марафоне больше, чем ему надо, в расчете на эпизодическую нагрузку, вы явно что-то не так делаете в плане архитектуры приложения. лучше 2 ноды по 4 гб чем 1 на 8. а еще лучше 3 по 2
Из живого примера что пришло на ум. Биллинг ISP:
1) Демона самой биллинг системы
2) Mysql база данных
3) Redis база данных
4) Nginx+HHVM
5) Radius сервер
6) Около 10 демонов шлюзов для взаимодействия с платежными терминалами типа киви.
7) ERP интегрированная с ядром биллинга, в ней же тикетсистема с собственной базой, десятком демонов (связь с телефонией, 1С и т.п.) при этом обновления для ERP части выходят примерно раз в неделю.
Коротче штук 30 процессов которые логично держать в рамках единого контейнера и бэкапить целиком, а не по частям, для воссоздания образа всей системы на определенный момент времени в случаи краха. В докер в теории можно все это засунуть, сторадж под mysql, сторадж под редис, стораджу для логов работы скриптов и радиуса, остальное каждый процесс в свой контейнер, но поддерживать это все и восстановить на определенный момент времени — это будет ад.
По поводу эпизодической нагрузки, есть контейнеры выполняющие например суточный, месячный годовой рассчеты бухгалтерии, соответственно суточный грузит систему около 40 минут в сутки, остальное время почти не нагружает, месячный около 7 часов в месяц и так далее, то-есть ресурсы нужны эпизодически, но сразу много, разделить на несколько процессов это не выйдет, так как единый процесс производит рассчеты и генерацию отчетов. Для того же OVZ это не проблема, он может динамически управлять ресурсами в процентном соотношении от доступных, что намного удобней и логичней чем статическая привязка к определенным параметрам, коротче задачи не девопс, по этому докер — как сову на глобус местами натягивать, можно, но усложняет обслуживание вместо упрощения.
1) Демона самой биллинг системы
2) Mysql база данных
3) Redis база данных
4) Nginx+HHVM
5) Radius сервер
6) Около 10 демонов шлюзов для взаимодействия с платежными терминалами типа киви.
7) ERP интегрированная с ядром биллинга, в ней же тикетсистема с собственной базой, десятком демонов (связь с телефонией, 1С и т.п.) при этом обновления для ERP части выходят примерно раз в неделю.
Коротче штук 30 процессов которые логично держать в рамках единого контейнера и бэкапить целиком, а не по частям, для воссоздания образа всей системы на определенный момент времени в случаи краха. В докер в теории можно все это засунуть, сторадж под mysql, сторадж под редис, стораджу для логов работы скриптов и радиуса, остальное каждый процесс в свой контейнер, но поддерживать это все и восстановить на определенный момент времени — это будет ад.
По поводу эпизодической нагрузки, есть контейнеры выполняющие например суточный, месячный годовой рассчеты бухгалтерии, соответственно суточный грузит систему около 40 минут в сутки, остальное время почти не нагружает, месячный около 7 часов в месяц и так далее, то-есть ресурсы нужны эпизодически, но сразу много, разделить на несколько процессов это не выйдет, так как единый процесс производит рассчеты и генерацию отчетов. Для того же OVZ это не проблема, он может динамически управлять ресурсами в процентном соотношении от доступных, что намного удобней и логичней чем статическая привязка к определенным параметрам, коротче задачи не девопс, по этому докер — как сову на глобус местами натягивать, можно, но усложняет обслуживание вместо упрощения.
да ну, зачем сюда мезос+марафон? мезос с марафоном крут когда на него деплоят микросервисы, вот тут он себя показывает. пихать в него такую систему поиметь головную боль на ровном месте, имхо.
у нас на нем живет куча микросервисов на Java 8+ Vert.х, у которых в качестве кеша hazelcast, бд Cassandra, а вертксовый эвентбас подружен с Confluent(он же допиленный Kafka) и вся эта хрень логгируется в graylog2, тобишь ориентировано все на кластеризацию
у нас на нем живет куча микросервисов на Java 8+ Vert.х, у которых в качестве кеша hazelcast, бд Cassandra, а вертксовый эвентбас подружен с Confluent(он же допиленный Kafka) и вся эта хрень логгируется в graylog2, тобишь ориентировано все на кластеризацию
Потому что это все и еще куча различных систем ща живет в кластере на OpenVZ с ядром 2.6 который и прекрасно работает, в смысле выпадение любой из нод не сказывается на жизни системы, в качестве ФС — Ceph. Но есть такая неприятность, что новые версии ОС не поддерживаются в OpenVZ прошлого поколения, а вот с OpenVZ 7 есть ряд косяков, они перешли на prlctl вместо vzctl, который кусок кода virtuozzo и большая часть необходимого функционала теперь не доступна, хотите функционал — купите virtuozzo (ценообразование там либо под откаты либо просто не вменяемо дорого), иначе в системе нет даже банальных бэкапов. Вот и стоим перед проблемой, на что нам мигрировать пол сотни контейнеров в OVZ, если считать в докерах, то будет пару тысяч процессов, причем не очешуеть обслуживать все это и поддерживать. Для девопса — выбор докера очевиден, а вот для продакшина предпочтительней полноценные контейнеры с ОС внутри и сохранением состояния, пока что в поиске.
Без разделения всего на отдельные части нет никакого смысла юзать Mesos или Kubernetes. Тут как раз суть в том, что каждый контейнер имеет только необходимый минимум: отдельно нджинкс, отдельно база, отдельно ПХП. Все комуникации в основном происходят по сетевому стеку. Если же вы хотите жить по-старому — то почему не что-то типа Proxmox-a?
Ну т.е. я не говорю о том, что Месос необходим всем, это вовсе не так. Я говорю о том, что это немного другой способ организации инфраструктуры программ.
Ну т.е. я не говорю о том, что Месос необходим всем, это вовсе не так. Я говорю о том, что это немного другой способ организации инфраструктуры программ.
то почему не что-то типа Proxmox-a
С радостью бы, но ProxMox 3 уже не поддерживается и имеет тот же OVZ c ядром 2.6, казалось бы выбор Proxmox 4, который перешел на LXC, но тут загвозтка в стабильности, которой просто нет, мы пару недель гоняли его на тестовом кластере — это просто ужасно, без преувеличений, на данный момент он не готов для продакшина, может и допилят через пару лет, но пока вот так https://habrahabr.ru/post/278877/ итого пока выбор выглядит очень не радостно: Proxmox 4 — не стабилен, OVZ 7 — не достаточно базовых возможностей, урезано много основного, чтоб подстегнуть к покупке Virtuozzo 7, который распространяется по подписке с платой за каждый контейнер и сам по себе дорогой, тестовый кластер на всего 3 ноды и 20 контейнеров нам посчитали в 540$ в месяц, причем на данный момент это только зарелизившийся продукт без комьюнити. Да еще есть LXD — на данный момент не умеет живую миграцию, но вроди как обещают скоро допилить, может что упустил, но вся контейниризация уходит в сторону докера, вот и испытываю муки выбора, просматривая все более-менее похожее с попыткой хотя-бы мысленно адаптировать под мои задачи.
ну тут из того что я знаю ближе всего coreos, полноценная ос и работать можно с серверами как с контейнерами
Вероятно тогда вам стоит ждать стабилизации кода-фич LXC. Или же переходить на Proxmox + KVM
KVM дает лишний оверхед, в плане виртуалок вариантов море, у нас есть кластер на сфере и вся виртуализация там, тут именно контейнеры нужны, вот и ждем стабилизации, попутно подбирая другие варианты, может что подойдет.
Ну имхо конечно, LXC я в проде не использовал, но OpenVZ как раз был самой доделанной контейнеризацией. Посидите тогда еще намного на старом OpenVZ, и ждите стабилизации.
Так и делаем, OVZ по стабильности очень хорошо допиленный продукт, пока использование новых ОС стоит не очень остро — будем сидеть на нем, там где требуются новые версии ОС, пока будем виртуалить на сфере и ждать когда один из вариантов контейнеризации ОС на современных ядрах будет более-менее стабилен. OVZ 7 тоже в принципе не плох, в плане скорости работы очень понравился, но вот насильное впихивание в него кусков от коммерческого продукта не пошло на пользу проекту, т.к. теперь это не самостоятельный продукт, а демо-версия virtuozzo, которая не годится для продакшина. На докер и производные пытались перейти несколько раз уже, но никак идеология один процесс — один контейнер не ложится на нашу структуру.
А что конкретно не так в OVZ 7? Что испортили?
Бэкапы есть только в платной версии — это самое критичное, остальное скорее придирки, управление кластером есть только в платной версии и то в стадии разработки, система миграции из старого в новый OVZ можно считать не работает, она есть но я в качестве теста пытался перенести с 10 контейнеров, 9 не переехали корректно и требовали ручной допилки, живая миграция только для платного их же стораджа. Вообще сравнение есть тут https://openvz.org/Comparison
Ну и КВМ не такой уж и оверхед дает. И плюс контейнеры не дают такого же уровня безопасности. Но контейнеры значительно удобней админить, это да.
Если мы раздаем контейнеры всему миру, аля VDS, то нас это парит, если мы используем только внутри своей инфраструктуры где безопасность обеспечивается на уровне самого гипервизора плюс отдельная защита периметра, то нет особой разницы КВМ или ОВЗ, главное удобство админства, тут контейнерам нет равных. Виртуалки тоже используем, но тут есть где развернуться, в принципе возможности сферы покрывают все необходимые задачи и в КВМ просто нет нужды, хотя на других проектах использовал и КВМ с виртио дровами вполне неплохая производительность.
мы реляционные субд(постгрес) менеджим в рамках persistent volume'ов(http://mesos.apache.org/documentation/latest/persistent-volume/), пока полет нормальный. а под этими volume'мами просто гластер. в конфиге контейнера в марафоне указать что конкретно этот контейнер работает с этим разделом и все.
не то чтобы фанат реляционных субд в докере, но в такой связке пока проблем не было
не то чтобы фанат реляционных субд в докере, но в такой связке пока проблем не было
Интересный вариант, надо попробовать на стенде погонять по стабильности, а то ценовая политика Virtuozzo 7 меня крайне огорчает, так что с OpenVZ придется куда-то уходить, вот ищу вариант куда с наименьшим геморроем в плане миграции.
есть жеж coreos(https://coreos.com), интересная штука. инстанс рестартует ~ 10 секунд, работает нормально, fleet(https://coreos.com/fleet/docs/latest/launching-containers-fleet.html) вообще изумительная вещь, если научиться готовить. мы юзаем coreos, поверх dc/os с марафоном, сервис дискавери через vip(https://docs.mesosphere.com/1.7/usage/service-discovery/virtual-ip-addresses/) — работает супер, есть идея заморочиться с rkt и flannel и заменить dc/os вообще, но подкупает коробочность, допиливать по минимуму приходится.
стабильность зависит от кол-ва инстансов, оно же мажется. будет нормально ресурсов для подхвата — оно впринципе неубиваемо
стабильность зависит от кол-ва инстансов, оно же мажется. будет нормально ресурсов для подхвата — оно впринципе неубиваемо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mesos. Container Cluster Management System