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

А если у тебя не сервис, а хостинг и ты виртуалки эти продаешь? Или, скажем, у тебя универ или чот подобное и ты студентам вируталки отдаешь? Уж хотя бы переподнятие виртуалок на другом хосте стоило бы еализовать)

под все выше перечисленное я нге буду использовать openstack =)

все просто, упал/умер/ребутнулся хост - то все вм, на котором в нем крутились - перезжают на другие

все просто, упал/умер/ребутнулся хост - то все вм, на котором в нем крутились - перезжают на другие

все просто, упал/умер/ребутнулся хост - то все вм, на котором в нем крутились - перезжают на другие

Это нихуя не просто, ребутнулся и умер это 2 разные ситуации. Я бы не хотел чтобы на хосте который сам ребутнулся в дальнейшем чтото поднялос (Виртуалка) до проверки админа

Ну а я буду. Собственно, и проектировался опенстек как альтернатива aws и другим публичным хостингам. А потом очень неудачно началась волна девопс моды. И сразу начались гнилые базры что только лохи относятся к виртуалкам как к питомцам, что все должно быть скотом и надо проектировать свой сервис нормально и все вот это дерьмо.

ну так и отмечу - запускаться ему или ждать админа

не так просто ответить на вопрос, куда должны автоматом переехать инстансы :)

не так просто ответить на вопрос, куда должны автоматом переехать инстансы :)

Планировщик решит сам. Там теперь для этого широкие возможности.

Вот я ктому что каждый кейс надо прописать и тогда придет понимание что в вашем видении является HA. Это и не просто.

ну хорошо, а как той сценарий, упал хост, пока чинят, в это время я хочу вм запустить, я должен сначала эвакуировать в определенный хост и тд, нельзя просто жмякнул и он нашел куда запускаться?

Не надо. Это менеджерская болезнь. Надо прописать и проживать, обсудить, да как бы чего не вышло. Вот и висят патчи 2015 года на расссмотрении. А нужно то одну конкретную функцию: Возможность переподнимать виртуальные машины на свой страх и риск на другом сервере, если их родной гипервизор помер. Хотя бы в очень грубом виде.

Не надо. Это менеджерская болезнь. Надо прописать и проживать, обсудить, да как бы чего не вышло. Вот и висят патчи 2015 года на расссмотрении. А нужно то одну конкретную функцию: Возможность переподнимать виртуальные машины на свой страх и риск на другом сервере, если их родной гипервизор помер. Хотя бы в очень грубом виде.

и что надо сделать? я жмяку старт и он нифига не встанет, если не эвакуирую на другой хост

Мы научились это быстро делать)

ну можно написать педаль и уволиться :)

Я имел ввиду что мы научились быстро разрабатывать регламенты т.к. у нас это делают ИТ-шники а не менеджеры

Я имел ввиду что мы научились быстро разрабатывать регламенты т.к. у нас это делают ИТ-шники а не менеджеры

ну а ночью или в 8 утра че делать, если критичный говносервис валяется

Это серьезный вопрос?) Если у вас клиент на 1к евро то у вас сидит ночная смена, если у вас клиент на 5евро и без СЛА - то спать дальше

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

Имею ввиду, самостоятельно и не дожидаясь никого)

вы про heat template ?

А если совсем серьезно у нас есть услуга "простых" впс на локальном хранилище, за 5 лет наебнулась ровно одна нода, разбудили админа, он за 2 часа доехал, переткнул все диски в другую (бэкап) ноду и поехал спать дальше

Можно на "ты". Не, я про то что можно следить за состоянием агентов и одновременно за виртуалками, хоть с помощью systemd юнита. И если чо не так - дергать скипт который запустит или плавную живую миграцию или эвакуацию.

у нас ровно так же :) Но я "делаю инфраструктурное облако" которое должно автоматизировать решение подобных сбоев

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

ну понятно, что с БД так лучше не поступать, но например с той же jira - почему бы и нет. Для конечного пользователя профит должен быть очевидным: 30-90 минут на починку железа или пару мин на миграцию инстанса

Jira умеет "кластеризацию"

Или вы её продаете отдельными инстанцами?

Ну в смысле за деньги) Она и так денег стоит, или вы её скачали с рутракера?)

1. Берешь пачку серверов 2. Накатываешь кубернетесы 3. В кубернетесах крутишь опенстековские сервисы 4. Виртуалки тоже в отдельном контейнере 5. Сервер сдох 6. Кубернетес сам все починил 7. Пьешь ром, куришь сигару, готовишь доклад на очередной модный дивапс митап 8. УХ! ПРОФИТИЩЕ

1. Берешь пачку серверов 2. Накатываешь кубернетесы 3. В кубернетесах крутишь опенстековские сервисы 4. Виртуалки тоже в отдельном контейнере 5. Сервер сдох 6. Кубернетес сам все починил 7. Пьешь ром, куришь сигару, готовишь доклад на очередной модный дивапс митап 8. УХ! ПРОФИТИЩЕ

да нафиг стек, если просто поставить openshift или кубернетес

"3. В кубернетесах крутишь опенстековские сервисы" - это прям грядет. Мирантис уже вовсю так делает

изыди!

ляпнул я тут про ceph, вот он и появился

он всегда так, на цеф приходит. Как-то даже в кубиковский чатик пришел 🙂

1. Берёшь кубинскую сигару 2. Накатываешь ром 3. И на хую крутишь всякую виртуализацию

1. Берёшь кубинскую сигару 2. Накатываешь ром 3. И на хую крутишь всякую виртуализацию

1. Берёшь кубинскую сигару 2. Накатываешь ром 3. И на хую крутишь всякую виртуализацию

Жаль, что комьюнити в этом плане не очень поворотливое

Жаль, что комьюнити в этом плане не очень поворотливое

Как это? Поворотливое. Есть и nova-lxd и супермодные kata containers. Ща в этом направлении движение и пошло.