Sergei
фактически шедулер интегрируется с TSDB, которая хранит информацию о характере нагрузки инстансов
sbog
Пробовал, но на небольшом количестве инстансов - не больше 50 машин было
J
Если для внутренних - то проблем нет, кмк
Ну, короче, работал я в одном месте, небольшой хостинг был. И там, конечно, все по модели рашн бизнеса и местных ИПшек. Я хозяин, царь и бог, а вы все говно. А уж клиенты - эт не люди. Кроме тех, конечно, кто по несколько килобаксов в месяц платит.
Ну и там прозрачности ни для своих инженеров ни для клиентов не было никакой. Только отмазки мудацкие по поводу плохого сервиса. Потому так остро и реагирую)
sbog
Да не, это нормально :)
sbog
реагировать нормально, я имею в виду :)
Sergei
насколько мне известно, в кубернетесе дефолтный шедулер вообще не оперирует реальным потреблением, он опируется только на requests/limits и старается забивать bestEffort-инстансы туда, куда они хоть как-то влезают.
при этом общая эффективность кубернетесового шедулера говно.
он начинает умирать очень рано и до сих пор не умеет шардиться. впрочем, шардированный шедулер вообще непростая задача.
sbog
Не, я не говорил "ванильном". Я говорил "чуть ли не в ванильном". Это две большие разницы ))
Sergei
шедулер там конечно же заменяем :)
sbog
Просто там само количество кода меньше, чем в опенстеке. И оперировать контейнерами проще, чем vm-ками
Sergei
(как впрочем и в опенстеке)
я почти уверен что у больших вендоров эти идеи вполне реализованы. впрочем, они напрашиваются, когда начинаешь сравнивать цифры "сколько железа продали" и "сколько железа потреблено"
J
Ток интересное началось, мне сваливать надо)
Sergei
Просто там само количество кода меньше, чем в опенстеке. И оперировать контейнерами проще, чем vm-ками
это тезис тоже, хм, сомнительный.
sbog
(как впрочем и в опенстеке)
я почти уверен что у больших вендоров эти идеи вполне реализованы. впрочем, они напрашиваются, когда начинаешь сравнивать цифры "сколько железа продали" и "сколько железа потреблено"
Видел разных вендоров. В целом - нормально ни у кого, кого видел, не реализовано полностью и нормально.
Sergei
впрочем, я за опенстек не очень умею, но там есть как минимум live-миграция, которая позволяет заметно безболезненнее мувать ворклоады
Sergei
Видел разных вендоров. В целом - нормально ни у кого, кого видел, не реализовано полностью и нормально.
ну я имею в виду не "мирантис", а скорее "рекспейс"
sbog
Да, только она не работает нихера из коробки
Sergei
Да, только она не работает нихера из коробки
на колд-инстансах (которые, собственно, и нужно мувать) вполне работает.
sbog
ну я имею в виду не "мирантис", а скорее "рекспейс"
Если иметь в виду под словом "вендор" тех, кто продает свои решения - то я вообще никого не знаю, у кого бы это работало из коробки. Я имею в виду под словом "вендор" компанию, владеющую инсталляцией из гипервизоров, скажем, на 50000+ CPU
sbog
на колд-инстансах (которые, собственно, и нужно мувать) вполне работает.
Приходите к нам, расскажете коллегам. Нам как раз бы пригодился опыт
Sergei
Приходите к нам, расскажете коллегам. Нам как раз бы пригодился опыт
не думаю, что он вам нужен.
я не умею в опенстек.
и весь мой поинт только в том, что такой умный шедулер возможно написать. и более того, это имеет большой смысл, если клиент(ы) сильно разнородны. экономятся десятки процентов железа.
sbog
Возможно - да. Целесообразно ли экономически с точки зрения бизнеса - ну наверное, да, но обычно есть значительно более острые задачи. Поэтому и не сделано толком ни у кого.
Sergei
Возможно - да. Целесообразно ли экономически с точки зрения бизнеса - ну наверное, да, но обычно есть значительно более острые задачи. Поэтому и не сделано толком ни у кого.
это от скейла зависит так-то.
бывает, что рост утилизации CPU с 92% до 95% - это бизнес-задача на год.
sbog
Это как продавать, да. Просто чаще проще купить еще серверов, чем писать шедулер
citius
как OSA заставить полностью перегенерить контейнер?
контейнер neutron_agents падает на этапе setup-hosts на:
failed: [sd-os-03_neutron_agents_container-77f3254a -> 172.29.8.27] (item={'key': u'lan_address', 'value': {u'bridge': u'br-lan', u'mtu': u'1500', u'netmask': u'255.255.252.0', u'address': u'172.29.26.188', u'interface': u'eth12', u'type': u'veth'}}) => {"changed": false, "cmd": ["cat", "/var/lib/lxc/sd-os-03_neutron_agents_container-77f3254a/eth12.hwaddr"], "delta": "0:00:00.001733", "end": "2017-11-17 15:53:22.755918", "failed": true, "item": {"key": "lan_address", "value": {"address": "172.29.26.188", "bridge": "br-lan", "interface": "eth12", "mtu": "1500", "netmask": "255.255.252.0", "type": "veth"}}, "rc": 1, "start": "2017-11-17 15:53:22.754185", "stderr": "cat: /var/lib/lxc/sd-os-03_neutron_agents_container-77f3254a/eth12.hwaddr: No such file or directory", "stderr_lines": ["cat: /var/lib/lxc/sd-os-03_neutron_agents_container-77f3254a/eth12.hwaddr: No such file or directory"], "stdout": "", "stdout_lines": []}
Остальные сети в него подсасываются нормально, сам контейнер стартует.
И это притом, что из openstack_user_config.yml я уже убрал сетку для интерфейса eth12.
дестроить плейбуком этот конкретный контейнер я пробовал, все равно такая же хрень.
lxc-destroy-ем убивать контейнер тоже пробовал.
такое ощущение что где-то закешены какие-то конфиги (факт-кеш я чистил).
Artem
@im_citius
скорее всего здесь: /etc/openstack_deploy/openstack_inventory.json
Maxim
всем привет
есть адекватный мануал по установке опенстак с дашбордом?
нужно отправить клиенту:(
✠ FLASh ✠
а чем офф дока не адекватный мануал?
Maxim
клиенту непонятно хД
citius
Вот буду очень благода. ) Сам примерно тогда же вылезу. Оч. хочется подебить. )
Andrey
ну, разве что,ммануал по Fuel 9.x. Там и дурачок должен справиться.
а вы фигачите OSA в проде ? с цефом ?
J
а вы фигачите OSA в проде ? с цефом ?
Не, у меня нету опенстека прям в проде. Для академических нужд совсем маленький кластер. Но цеф есть, да)
Andrey
я уж было прям подумал...) по моим прикидкам OSA нужно месяца 4 мучать в лабах прежде чем в прод пускать
J
я уж было прям подумал...) по моим прикидкам OSA нужно месяца 4 мучать в лабах прежде чем в прод пускать
Там аккуратность нужна, разве что.
А так то же самое что из пакетов ставить вручную.
J
Главное ненужную хуйню выключить всю. Типа apply security hardening.
J
В любом случае, рад обсудить был бы. Чем больше народу пробует использовать, тем лучше)
Andrey
да я то за, но что бы серьезно заниматься нужно финансирование) к стати OSA только редхатовские пакеты использует или можно на убунтовые переключиться ?
Andrey
с kolla я точно переключался между RH/Ubuntu
J
да я то за, но что бы серьезно заниматься нужно финансирование) к стати OSA только редхатовские пакеты использует или можно на убунтовые переключиться ?
Не использует пакеты.
Оно прям репозитории клонирует, из них под каждый компонент venv собирает и пипом ставит.
citius
Я чот туплю.
Можешь скинуть список своих бриджей и конфиги сетей из openstack_user_config.yml?)
короче с конкретно этим косяком я справился, перекинув роль на другие физ. сервера.
но с контейнерами все равно творится какая-то ботва, например _repo_ и _memcached_ контейнеры отказываются подниматься на двух из трех хостов, выбранных инфраструктурными.
сетевая конфигурация на всех этих хостах зеркальная.
J
citius
setup-infrastructure не может пакеты на них поставить, потому что в них есть нужные интерфейсы, но на них нет айпишников. соответственно внешка недоступна.
citius
при этом все br-mgmt интерфейсы друг друга пингуют есессно, сама сеть в поряде.
J
Ну чо-то ад какой-то)
Покажи, пожалуйста, все ж секцию с сетями из openstack_user_config. А лучше его полностью вообще)
citius
ща на термбин скину. сек.
citius
бросил ссылку в личку.
J
Спасибо)
Sergei
баньте его сразу
Sergei
@SinTeZoiD
Михаил
Pavel
sbog
Ну нет так нет. Я что знаю - то и говорю. Если у вас есть контрпримеры по большим публичным инсталляциям - приводите, я бы с удовольствием ознакомился со статистикой. А то приходится по саммитам ездить и с малознакомыми людьми бухать для этого. А я не пью в таких количествах.
Pavel
в случае приватных облаков - просто надо честно предупреждать заказчика. В случае публичных - хз, дороже выйдет =)
Pavel
на моем опыте даже x3 по cpu выйдет боком через пару лет
sbog
в случае приватных облаков - просто надо честно предупреждать заказчика. В случае публичных - хз, дороже выйдет =)
Все так и есть. Но в случае публичных - я знаю статистику по некоторым крупным клаудам - и у всех оверпровиженинг есть. Я бы очень рад рассказать про размеры этого оверпровиженинга, но не могу, чесслово.
Pavel
просто надо понимать - чем больше ты накроишь оверпровиженингом, тем больше ты потратишь на эксплуатации, вот и все. А дальше думать
sbog
x3, кстати, не очень много. Если тенанты маленькие, то c x12-x16 начинаются проблемы реально неприятные. А если большие - то, наверное, x4-8 уже потянут за собой некоторые сложности.
sbog
Pavel
у нас х3 и жопа. Благо это делал не я и ответственность не на мне
Pavel
зависит от типа приложений
sbog
Хм. У нас, конечно же, оверпровиженинга нет (лол), но я слышал, что говорили, что можно жить и на чуть большем, чем x3.
sbog
Но зависит от того, что крутят, да.
sbog
А расскажите, коллеги, вот что - кто как у себя в облаках делает докупку нового железа под растущие нужды? Ну, т.е. нагрузка растет и становится понятно, что нужно еще купить стойку-две. Нельзя просто пойти и купить - надо и бюджет согласовать, и подождать, пока привезут, и настроить еще и т.п. - это время. Т.е. нельзя сказать "ааааа, сегодня жопа, завтра нужна стойка", потому что до завтра ее точно не привезут. Кто как делает? Начинают закупки на, скажем, 10%, прикидывая, что за то время, пока эти 10% израсходуются, все сделают? А если облаков больше одного? А если там еще аггрегатов дофига и надо по каждому отдельно следить - как следите?
Михаил
и про "все оверпровижонят"
sbog
Лол. Ну вечно же нельзя оверпровиженить, надо все равно железо-то покупать рано или поздно. Или все покупают, когда петух уже клюет в одно место?
Artem
А расскажите, коллеги, вот что - кто как у себя в облаках делает докупку нового железа под растущие нужды? Ну, т.е. нагрузка растет и становится понятно, что нужно еще купить стойку-две. Нельзя просто пойти и купить - надо и бюджет согласовать, и подождать, пока привезут, и настроить еще и т.п. - это время. Т.е. нельзя сказать "ааааа, сегодня жопа, завтра нужна стойка", потому что до завтра ее точно не привезут. Кто как делает? Начинают закупки на, скажем, 10%, прикидывая, что за то время, пока эти 10% израсходуются, все сделают? А если облаков больше одного? А если там еще аггрегатов дофига и надо по каждому отдельно следить - как следите?
Супер мега гига табличка в екселе с рассчетом всего на свете и корректировкой при каждом баге
sbog
Супер мега гига табличка в екселе с рассчетом всего на свете и корректировкой при каждом баге
Ну чо ты обостряешь? :) Мне правда интересно.
Artem
Ну чо ты обостряешь? :) Мне правда интересно.
Это правда =) Табличка по каждый месяц с примерным ростом клиентов и сколько им в зависимости от этого надо будет ресурсов
Михаил
Лол. Ну вечно же нельзя оверпровиженить, надо все равно железо-то покупать рано или поздно. Или все покупают, когда петух уже клюет в одно место?
это ты считаешь, что нельзя)
пока оом не приходит каждый день - можно)