Sergey
Limitations
This is a proof of concept that is not meant to be used in production
We cannot forecast how many servers should be migrated. This is the reason why we only plan a single virtual machine migration at a time. So it’s better to use this algorithm with CONTINUOUS audits.
It assume that live migrations are possible
Sergey
мугога
Sergey
прошло 6 лет. как было дендрофекальным решением так и осталось
J
Ок, даталайн мы услышали)
Sergey
при чем здесь датан?
Sergey
кстате, а максимальный размер кластера каков в стэкэ?
Alexander
мугога
Некоторые стратегии действительно PoC, другие могут быть использованы в небольшом проде
Sergey
ну это в частности drs
J
Зависит от того как проектируешь все. Делишь ли на ячейки, что используешь для базы и для мессадж брокера. Сотни и тысячи серверов у народа работают вроде ок.
Sergey
то что везде работает лет 6 уже как без проблем
Sergey
Sergey
тысяча. виртуалки. ну ооооок
Sergey
сотни и тысячи это порядки. даже не разы
Alexander
Проекту DRS в стеке третий год исполнится в конце года
Sergey
Проекту DRS в стеке третий год исполнится в конце года
мда. хотелось поржать но хочется плакать
Sergey
я вспоминаю 2013 год и shared nothing live migration
J
тысяча. виртуалки. ну ооооок
К чему это все высокмерие то?)
Если тебе правда интересно, спрашивай. А если чсв почесать, то конструктивная беседа не оч клеится в таких случаях.
Sergey
Sergey
кластеры бд, кластеры виртуализации, кластеры очередей это немного разные сущности
Sergey
мне интересн разумный и физический предел
Sergey
у кровавых тырпраыйзов 64 ноды
Sergey
но их можно слепить в логический кластер
Sergey
много по 64
Sergey
это касаемо виртуализации
Sergey
с бд там у всех по разному
J
много по 64
Ну и тут примерно то ж самое. В общем то, естественный подход - группировать сначала на одном уровне, а потом группы более низкого уровня снова группировать.
Sergey
тут возникают грустные моменты например в виде кворума
J
тут возникают грустные моменты например в виде кворума
А кворум нужен не везде ж, а для маленького количества инфраструктурных сервисов. Для базы данных нужен.
Для бошек хранилища нужен, а больше и не знаю даже где.
Sergey
гхм
Sergey
а кластер вм например?
Sergey
ну смари
Sergey
у тебя 100 нод, 50 упало
Sergey
кластер жив или нет?
J
Жив, если среди упавших 50 штук не находится весь контрол плейн.
Sergey
гы
Sergey
пролет товарищ майор
Sergey
в кластере формула живости x>=n/2+1
Sergey
где x количество выживших, n общее колво нод
J
Но это ж формализм.
Если api сервисы продолжают работать и обрабатывать запросы клиентов, если виртуалки с упавших серверов переезжаютна живые, если при всем при этом продолжается управление ресурсами, значит жив. Почему нет то?)
Sergey
иначе шплитбрейн вам обеспечен
Sergey
у тебя кластер
Sergey
если это одинокостоящие ноды то там да, все равно
Sergey
в кластере есть кворум. нет кворума нет кластера
Sergey
все просто
Sergey
Жив, если среди упавших 50 штук не находится весь контрол плейн.
и кстате, у кластера нет контролплейна
Sergey
это вам не oswitch или nsx
J
Но дело то в том что кластер в классическом смысле не нужен. ВСе демоны рулящие ресурсами - это wsgi питоновские приложения, они stateless, что называется.
Единственное для чего важно общее состояние и кворум - это база. А раз для всего остального не нужно общее состояние о котором договариваются, не нужен и кластер в классическом смысле и не нужен кворум.
Sergey
вмки
Sergey
у тебя вмки живут на 100 хостах
Sergey
хотя судя по ситуации с ha в попенстэке там днищище ололо
J
у тебя вмки живут на 100 хостах
На 100.
Но если осталось 50 хостов и их ресурсы позволяют крутить виртуалки и свои и с упавших 50, то в чем проблема? Да, ситуация опасная, но, тем не менее, работать и в таком виде будет.
Sergey
кворума нет
Sergey
если вдруг поднимутся оставшиеся 50 у тебя будет боль
Sergey
ниже пояса
J
Почему? Если поднимутся оставшиеся 50, виртуалки можно начать плавно перемещать обратно.
Не буду пиздеть, сами они это не сделают) Как сами и не поднимутся при падении их родных хостов.
Это есть в сервисе masakari, но он пока хреновато документирован и с ним не очень просто.
Fox
Добрый день коллеги! подскажите а через horizont я могу изменить размер диска без потери данных, диск находится на ceph
Александр
чо?!
Anonymous
resize человек для volume хочет, видимо.
Anonymous
или для image в glance с бэкендом в ceph.
Anonymous
непонятно...
Александр
Вот и вопрос "чо?!" 🙂
J
Добрый день коллеги! подскажите а через horizont я могу изменить размер диска без потери данных, диск находится на ceph
Ладн, смотри, если диск - это cinder диск, то можно без проблем особых.
J
Добрый день коллеги! подскажите а через horizont я могу изменить размер диска без потери данных, диск находится на ceph
отключаешь от инстанса диск (detach), затем деалешь extend и снова подключаешь.
Если же это корневой диск созданный nova или эфемерный диск, то тут надо будет сделать вот как:
Сделать снапшот диска, преобразовав его в образ
Сделать ребилд инстанса выбрав нужный flavor и указав в качестве источника твой свежесозданный образ.
Вроде ничо не напутал и глупостей не написал)
Fox
пардон за ламерский вопрос
Anonymous
"Если же это корневой диск созданный nova или эфемерный диск, то тут надо будет бить по лицу"
Anonymous
желательно, ногами.
Fox
ну диск в ceph ну и логично что это блочное устроство
Fox
и явно в cinder
Anonymous
ну cinder делает lv внутри lvm, поэтому детач и попытка увеличить.
J
что значит диск созданый nova )
Ну смотри, при создании виртаулки диск может создаваться либо сразу через cinder либо средствами nova (тогда этот диск жестко привязан к виртуалке и живет только пока она существует. Его размер нельзя менять и много чо еще нельзя с ним делать). Но такой диск удобен чисто чтоб держать н анем систему, например.
Anonymous
а тьфу.
Anonymous
о. уже вечер
J
и явно в cinder
Ну тогда detach и потом через volumes тыкаешь стрелочку напротив диска и там есть пункт extend volume. Уменьшить нельзя, только увеличить. Но это и логично.
Fox
т.е. останавливаю виртуалку, деатач и увеличиваю