Pull to refresh

Comments 15

Любопытно, сколько % процессорной мощности продуктивных хостов виртуализации отъедается такими вот, подобными этому, питоновыми костылями опенстэка?
Тут если уж наезжать на съедаемые ресурсы — наезжать надо не на реализацию каких-то компонентов на питоне, а в целом на ряд архитектурных решений — типа того, что в общем-то не очень здравая мысль запускать с периодом в 2 секунды портянку из трех бинарников.
1-3%. На удивление, меньше, чем, например, оверхед от виртуальной памяти у операционной системы. 2 секунды для компьютера — это очень много. А с учётом, что это константный оверхед, не зависящий от нагрузки, им можно пренебречь.
Справедливости ради — это решение не специфично для OpenStack, а подходит и для кучи других подобных же штуковин, стоящих в кроне или в каком-то частотном опроснике, например, из мониторинга. Я помню, что года 2-3 назад подкручивал подобное для:

  • OpenVZ'шных скриптов, вызываемых vzeventd
  • sar'овского /usr/lib64/sa/sa1
  • почти всех проверок мониторинга для железа (всяких вызовов einarc, smartctl, ipmitool и т.п.)

Хотя, конечно, у меня объемы несравнимо меньшие.
А что не так с vzeventd скриптами и почему они должны спамить? Есть ли багрепорт на bugzilla.openvz.org?
А как вам вариант скомпилировать python'овский root-wrapper и таки поставить на него suid?
Какую проблему это решит?
Но сам root-wraper написан на Питоне (как и всё в Openstack), а на интерпретируемые файлы ставить suid нельзя. В качестве простого и разумного решения root-wraper вызывается как sudo root-wraper.
Изменение схемы дистрибьюции (добавление «компиляции» питона) должно решать что-то большее, чем пара строчек в логе. Я это к тому, что такие изменения очень инвазивные, и должны быть нацелены на что-то глобальное. sudo /usr/bin/root-wraper вполне разумный подход.
Пожалуй вы таки правы :)

//Кстати, забавно, мои глаза прямо таки избегали папочки /etc/sudoers.d, спасибо что упомянули о ней в статье (пойду разгребу свой один слегка разросшийся конфиг).
Вообще в этом весь OpenStack — набор костылей и абсолютно разрозненных технологий. Все адекватные инженеры и архитекторы стремятся к гетерогенности (1 вендор, 1 протокол, 1 тип железа, 1 кодовая база на все), а тут тотальная гетерогенщина и костыли для костылей, на которых костыли работают.

Точнее ой, не работают :) Ну или приведите пример реально работающего крупного провайдера на OpenStack.
Вся идея опенстека — vendor-agnostic. Это очень интересная идея и она напоминает отношения операционной системы и железа. Фичи железа либо ложатся на железо, либо игнорируется, либо, если фича ну очень вкусная, под неё создаётся отдельный класс устройств. Но ОС не подстраивается под мелкие фичи каждой железки.

Насчёт крупных инсталляций — большинство гигантов либо из pre-openstack, либо не занимаются iaas.

Среди второго эшелона OpenStack практически единственное multi tenant решение, которое можно поднять за разумное время и резумное количество ресурсов программистов.
Сплошной энтерпрайз. Публичность там приделана с боку.

Разница между энтерпрайзом и публичностью в том, что в энтерпрайзе стейкхолдеры операторов инфраструктуры и пользователей одни, а в публичном — разные. Причём пользователи могут быть разных стейкхолдеров, в том числе враждебных (злой хаккир Вася арендовал виртуалочку и щипает соседей).

Openstack же кровь от крови multi-tennant, причём в самом агрессивном виде multitennant, что там даже возникают обратные проблемы — как бы нам «двух теннатов подружить».

Если мы говорим про публичные (ака провайдерские) проекты, то openstack'у просто нет альтернатив. Для приватных их много, и будет большим преувеличением сказать, что в приватных облаках openstack наиболее удобен.
Пример крупного провайдера на OpenStack — internap, плюс недавно купленный этим-же internap-ом iWeb
Sign up to leave a comment.