« Rev
@openstack_ru   111
Fwd »


Sergey
И S2d обязательно с маланокс картами и свичами
Sergey
Бань
Sergey
)
J
cells?
J
Деление новы на домены. Каждая ячейка - считай независимый набор nova сервисов и гипервизоров. Эт надо, мне кажется, только для очень больших инфраструктур. Ток у CERN про это читал.
J
Ну и плюс в каждой ячейке своя база и свой кролик.
J
Для этого и задумывалось, собсно.
Михаил
вот оно чё
J
Вот та презенташка. Старая, но дает представление о том как ими пользоваться) https://www.openstack.org/assets/presentation-media/Deep-Dive-into-the-CERN-Cloud-Infrastructure.pdf
Alexander
а еще было бы отлично если бы кто-то по русски объяснил что такое cells и placement и какого хера часть флагов про cells уже deprecated
Placement - шаг в сторону децентрализации размещения виртуалок и депрекейта скедулера
J
Чот мне слово депрекейт резануло глаза. А зачем отказываться от планировщика?
J
И что сейчас не так с размещением виртуалок?
Михаил
плюсую
J
Ну, то есть, я онимаю зачем нужен placement-api сервис, но не понимаю чем плох планировщик. Тем что там единица планирования - хост и учет ресурсов завязан в основном на хосты?
Николай
Жучков админ комьюнити лол)
Николай
Алексей когда там саммит в Москве ?
Alexander
Nova еще со времен PTG в Атланте хотят отказаться от скедулера, это будет являться радикальным решением проблемы живой миграции без участия фильтров, например (проекты Congress и Watcher давно просят учитывать фильтры Nova Scheduler при live migrate, но команда нова отказываться из-за юз кейса: админ запросил живую миграцию -> миграция провалилась из-за сработавшего фильтра). Это объяснение позиции команды нова со времен Pike-релиза, будем читать, что на Queens запланировали
Sergey
там и опенстек есть)
Alexander
Спасибо) Я чего-то пока не соображу как работать должно без фильтров. Есть идеи?
думаю, здесь добавится эвристика и выбор хоста станет чуть менее надежным, но куда более быстрым. доводилось встречаться с руководителем лаборатории одного из мексиканских вузов, они пилят модель облачной платформы, где стремятся свести централизации к минимуму. при выборе хоста они руководствуются приниципом "кто первый сообщил – тому отдаем". думаю, в рамках OS можно сделать оповещение по AMQP, на которое узлы будут реагировать и, если кто-то из них соответствует, будут отправлять ответку с соглашением разместить
Alexander
чья ответка первая приедет – тот победил
Alexander
правда, в таком случае убирается механизм весов
Ilya
OVH
Овх готов нам дать инфраструктуру нахаляву?
Sergey
Буржуй на халяву?
Sergey
на халяву я вам могу одну виртуалочку сделать)
Ilya
Буржуй на халяву?
Так то я много провайдеров на опенстеке знаю
Ilya
на халяву я вам могу одну виртуалочку сделать)
А виртуалочки нам будет мало :-) а вот сколько нам надо я никак определиться не могу
Sergey
а скока надо?
Ilya
а скока надо?
Читай выше :-)
Sergey
не ты не ломайся как девочка
Sergey
решайся
Ilya
решайся
Вот решим - скажу :-)
Sergey
вот реши и скажи
J
Чо-то какая-то мутная система предлагается. Сейчас допилили вроде до более-менее нормального вида когда отслеживаются разные классы ресурсов и известно где чего и сколько. Как понимаю, для nova в целом проблема в том что щас все планирование делается централизованно. Кстати, правду сказать, фильтры эти все та еще дрянь, наебался с ними вдоволь хотя попенстеком вот только-только заниматсья начал можно сказтаь.
sbog
Деление новы на домены. Каждая ячейка - считай независимый набор nova сервисов и гипервизоров. Эт надо, мне кажется, только для очень больших инфраструктур. Ток у CERN про это читал.
Все из Large Deployments Group используют nova cells, если я не ошибаюсь. Из коробки оно не работает, нужно патчить, патчи пока еще не въехали в апстрим.
J
Подумал что збс было бы сделать как в цефе. Подобие CRUSH прикрутить. И схема такая: Клиент от nova-placement получает карту ресурсов и сам считает куда виртуалку класть. Норм же было бы?
J
Как понимаю, чо-то такое и хотят?
Alexander
Как понимаю, чо-то такое и хотят?
я знаю лишь вектор их мысли, что именно они сделают – я не ебу:(
sbog
Примерно так. Это часть решения проблемы живой миграции (которая вообще не должна существовать в контексте OpenStack)
sbog
Миграция
Alexander
Примерно так. Это часть решения проблемы живой миграции (которая вообще не должна существовать в контексте OpenStack)
а на уровне чего она должна быть? гипервизора? так гипервизор не обладает контекстом опенстека
sbog
Суть в том, что есть клиенты, они набиваются в HV и при оверкоммите важные кастомеры начинают просасывать. Отключить оверкоммит это овердорого. Остается их мувать. Но т.к. нет миграции и не предвидится и вообще она не нужна, вместо этого этих клиентов проще плейсить изначатьно в пустые клетки.
J
Миграция
Почему нет? Если тебе гипервизор надо выключить и память поменять, например, почему не эвакуировать все на другой хост?
J
Я работал в таком хуевом месте где к клиентам как к скоту относились, да. Хостинг такой небольшой был)
sbog
а на уровне чего она должна быть? гипервизора? так гипервизор не обладает контекстом опенстека
Смотри выше. У тебя есть опенстек, в нем все ноют про миграцию. А она вообще не кейс деплойментов опенстека.
J
У клиента сервис. Он чо, прерваться должен?
sbog
У клиента сервис. Он чо, прерваться должен?
Он должен быть stateless и планироваться изначально с учетом таких проблем.
sbog
Весь опенстек на это и рассчитан
J
Я работаю в таком. 100k+ VM-ок. Хотите поговорить про скот?
Конечно хочу. Тем более стрёмно если о клиентах не заботитесь.
sbog
Конечно хочу. Тем более стрёмно если о клиентах не заботитесь.
Как забота о клиенте связана с особенностями инфры?
J
Опенстек расчитан на то чтобы быть Iaas. Но его можно использовать и как простую систему для VDS хостинга, а все IaaS потроха себе оставить. И вот клиент взял виртуалку. У него там фотки котиков, голой жены и отпуска в Исландии. И впн сервер с сайтом-визиткой впридачу. Что, из-за того что "так не должно быть" оставлять его на какое-то время без сервиса?
Sergey
»>голой жены где можно посмотреть?
sbog
Хотите отказоустойчивости - вам специально k8s придумали. Хотите огромные пачки вмок на пять минут - вот вам опенстек
J
Если вы купили велосипед и пытаетесь на нем переплыть озеро - у вас, теоретически может получиться. Именно этим и занимается весь мелкий хостинг, который ставит опенстек. Привыкли VDS отдавать и туда же лезут.
Ладно, ясно-понятно. Эт была лекция о том что опенстек не для мелких хостингов и что те кто его ставят продают свой сервис серьезным пацанам. Ынтепрайз и все дела)
sbog
Все так и есть.
Alexander
Как сраться за миграцию закончим, расскажешь немного?)
а что рассказывать? Ed Leafe является доверенным лицом от нескольких проектов, которые используют Nova для менеджмента облака. Он появлялся на всех PTG, где слушал проблемы менеджент-проектов и пытался их донести до Nova (он там кор). Политику Nova в отношении разных юз кейсов (касательно миграции и скедулера) поменять сложно, т.к. на мета-уровне проект модерирует только PTL и еще несколько человек, остальные коры отвечают только за определенные части Nova. Отсюда какую либо спецификацию, которая затрагивает несколько частей, очень тяжело протащить
Radik
что это вообще такое?
На лекциях os admin разбирал этот вопрос
Artem
Все так и есть.
Ирония: Ага а интерпрайз привык к castle, о чем вы лечите :(
sbog
Ну в вашем мире может и привык. А в моем мире каждый энтерпрайз ставит себе то, что хочет. Я знаю много крупных клиентов на опенстеке и совсем не знаю небольших.
sbog
Другое дело что никто из энтерпрайза не использует опенстек для прода практически.
sbog
Все почти для дев нужд
Alexander
Чот какая-то грусть(
их можно понять, Nova слишком большой проект для модерирования всего и вся
Radik
Чот какая-то грусть(
Вроде были и примеры. Потому что списывал с выступления разработчиков, чтобы разобраться во всей этой хренотени
Alexander
вот есть у вас идея классная про развитие Nova
« Rev
@openstack_ru   111
Fwd »