Всем привет. Данная статья написана для тех, кто до сих пор мечется между выбором платформ виртуализации и после прочтения статьи из серии «Поставили proxmox и вообще все отлично, 6 лет аптайм не единого разрыва». Но после установки того или иного коробочного решения, возникает вопрос, а как бы тут подправить и тут, чтобы мониторинг был более понятный и вот тут, чтобы контролировать бэкапы…. А потом приходит время и вы понимаете, что хочется чего то более функционального, ну или хочется чтобы внутри вашей системы стало все понятно, а не этот черный ящик или хочется использовать что то больше, чем гипервизор и куча виртуальных машин. В данной статье будет немного размышлений и практика на основе платформы Opennebula — выбрал т.к. не требовательна к ресурсам и архитектура не такая сложная.

И так, как видим многие облачные провайдеры работают на kvm и делают внешнюю обвязку для управления машинами. Ясно что крупные хостеры пишут свои обвязки для облачной инфраструктуры, тот же YANDEX например. Кто то использует openstack и делает обвязку на этой основе — SELECTEL, MAIL.RU. Но если у вас есть свое железо и небольшой штат специалистов, то обычно выбирают что-то из готового — VMWARE, HYPER-V, есть бесплатные лицензии и платные, но сейчас не про это. Поговорим про энтузиастов — это те, кто не боится предложить и попробовать новое, несмотря на то, что в компании явно дали понять «Кто это потом будет после тебя обслуживать», «А мы это что ли в прод потом выкатим? Страшно.» Но ведь можно для начала применять данные решения в условиях тестового стенда и если всем понравится, то можно поднять вопрос о дальнейшем развитии и использовании в более серьезных средах.

Также вот ссылка на доклад www.youtube.com/watch?v=47Mht_uoX3A от активного участника развития данной платформы.

Возможно в данной статье что-то будет лишнее и уже понятно опытному специалисту, а в некоторых случаях не буду описывать все т. к. подобные команды и описание есть в сети. Тут только мой опыт работы с данной платформой. Надеюсь, активные участники дополнят в комментариях, что можно сделать лучше и какие я допустил ошибки. Все действия были в условиях домашнего стенда состоящие из 3х ПК с разными характеристиками. Также я специально не стал указывать как работает данный софт и как устанавливать. Нет, только опыт администрирования и проблемы с которыми столкнулся. Возможно кому то это пригодится в выборе.

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

1. Повторяемость установки

Есть куча инструкций по установке opennebula, тут не должно возникнуть проблем. От версии к версии появляются новые фичи, которые не всегда смогут заработать при переходе от версии к версии.

2. Мониторинг

Будем мониторить саму ноду, kvm и opennebula. Благо уже есть готовое. Про мониторинг linux хостов есть масса вариантов, тот же заббикс или node exporter — кому что больше нравится — на данный момент определяю так, что мониторинг системных метрик (температура там где она может измеряться, консистентность дискового массива), через zabbix, а то что касается приложений через экспортер в прометей. По мониторингу kvm например можно взять проект github.com/zhangjianweibj/prometheus-libvirt-exporter.git и поставить запуск через systemd, вполне хорошо работает и показывает метрики kvm, также есть готовый dashboard grafana.com/grafana/dashboards/12538.

Например, вот мой файл:

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

И так у нас 1 экспортер, надо второй для мониторинга самой opennebula, использовал такой github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Можно добавить в обычный node_exporter для мониторинга системы следующее.

В файле по node_exporter меняем старт таким образом:

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

Создаем директорию mkdir -p /var/lib/opennebula_exporter

bash скрипт представленный выше сначала проверяем работу через консоль, если показывает то что надо (если выдает ошибку то ставим xmlstarlet), копируем его в /usr/local/bin/opennebula_exporter.sh

Добавляем в крон задание на каждую минуту:

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

Метрики стали появляться, можно забирать их прометеем и строить графики и делать алерты. В графане можно нарисовать например такой простой дашборд.



(видно что тут я сделал overcommit cpu, ram)

Для тех кто любит и использует заббикс, есть github.com/OpenNebula/addon-zabbix

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

К логированию, пока особо не приступал. Как самый простой вариант, это добавить td-agent на парсинг директории /var/lib/one с регулярными выражениями. Например, файлик sunstone.log подходит под regexp nginx и другие файлики, которые показывают историю обращений с платформой — какой в этом плюс? Ну например мы можем явно отслеживать количество «Error, error» и быстрее отследить, где и на каком уровне есть неисправность.

3. Резервные копии

Есть также платные допиленные проекты — например sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Тут мы должны понимать, что просто бэкапить образ машины, в данном случае совсем не то, ведь наши виртуальные машины должны работать с полной интеграцией (тот же контекст файлик, в котором описываются настройки сети, имя vm и кастомные настройки для ваших приложений). Поэтому тут определяемся что и как будем бэкапить. В некоторых случаях лучше делать копии того, что находится в самой vm. И возможно надо бэкапить только один диск от данной машины.

Например мы определились, что все машины запускаются с persistent images следовательно почитав docs.opennebula.io/5.12/operation/vm_management/img_guide.html

значит сначала с нашей vm можем выгрузить образ:

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Смотрим, под каким именем он сохранился

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
   
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

Также в просторах сети нашел интересный доклад и есть еще такой открытый проект, но тут только под qcow2 хранилище.

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

4. Удобство использования

В данном пункте опишу те проблемы с которыми столкнулся я. Например, по образам, как мы знаем есть persistent — при монтировании этого образа к vm, все данные записываются в этот образ. А если non-persistent, то копируется образ на хранилище и данные пишутся в то что скопировалось от исходного образа — так работают заготовки шаблонов. Неоднократно сам себе делал проблемы тем, что забыл указать persistent и 200 гб образ копировался, проблема в том, что наверняка данную процедуру отменить нельзя, надо идти на ноду и прибивать текущий процесс «cp».

Один из важных минусов — это нельзя отменить действия просто используя gui. Вернее ты их отменишь и увидишь, что ничего не происходит и снова запустишь, отменишь и по факту уже будет 2 процесса cp, которые копируют образ.

И тут приходит пониманием, почему opennebula каждый новый инстанс нумерует новым id, например в том же proxmox создал vm с id 101, удалил ее, потом вновь создаешь и id 101. В opennebula такого не будет, каждый новый инстанс будет создаваться с новым id и в этом есть своя логика — например, очистка старых данных или не успешных инсталляций.

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

5. Максимальная простота

Конечно тут чем дальше идешь, тем меньше становится тех, кто будет понимать тебя.

В условиях моего стенда — 3 ноды с nfs хранилищем — все работает в порядке. Но если проводить эксперименты на отключение энергии, то например при запуска snapshot и отключении питания ноды, у нас сохраняются настройки в БД, что есть snapshot, а по факту его нет (ну мы же все понимаем, что исходно записал в sql базу о данном действии, но сама операция прошла не успешно). Плюс в том, что при создании снимка формируется отдельный файлик и есть «родитель», следовательно в случае проблем и даже если через gui не работает, мы можем забрать qcow2 файлик и восстановится отдельно docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

По сетям, к сожалению не все так просто. Ну по крайне мере проще чем в openstack, я использовал только vlan (802.1Q) — вполне работает, но если вы из template network сделайте изменения в настройках, то данные настройки не применяться на уже работающих машинах т. е. надо удалить и добавить сетевую карту, тогда новые настройки применяться.

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

6. Дополнительные плагины и установки

Ведь как мы понимаем облачная платформа может управлять не только kvm, но и vmware esxi. К сожалению пула с Vcenter у меня не оказалось, если кто пробовал напишите.

В поддержке других облачных провайдеров заявлено docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Также пробовал прикрутить Vmware Cloud от селектел, но ничего не получилось — в общем забил т. к. Много факторов, а писать в тех.поддержку хостинг провайдера нет смысла.

Также, сейчас в новой версии есть firecracker — это запуск microvm, типа kvm обвязка над докер, что дает еще больше универсальности, безопасности и повышения производительности т. к. Не надо тратить ресурсы на эмуляцию оборудования. Я вижу только преимущество по отношению к докеру в том, что не занимает дополнительное количество процессов и нет занимаемых сокетов при использовании данной эмуляции т.е. вполне себе можно использовать как балансировщик нагрузки (но про это наверное стоит написать отдельную статью, пока не провел все тесты в полной мере).

7. Положительный опыт использования и дебаг ошибок

Хотел поделится своими наблюдениями по поводу работы, часть описал выше, хочется написать побольше. Действительно, вероятно не я один, кто сначала думает, что эта не та система и вообще тут все костыльно — как с этим вообще работают? Но потом приходит понимание и что все вполне логично. Конечно всем не угодить и некоторые моменты требуют доработок.

Например, простая операция копирования образа диска с одного datastore на другой. В моем случае есть 2 ноды с nfs, отправляю образ — копирование идет через frontend opennebula, хотя все мы привыкли к тому, что данные должны копироваться напрямую между хостами — в той же vmware, hyper-v мы привыкли именно к этому, но тут по другому. Тут другой подход и другая идеология, и в 5.12 версии убрали кнопку «migrate to datastore» — переносится только сама машина, но не хранилище т.к. подразумевается централизованное хранилище.

Далее популярная ошибка с разными причинами «Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5» Ниже будет топ, что надо посмотреть.

• Права на образ для пользователя oneadmin;
• Права для пользователя oneadminдля запуска libvirtd;
• А правильно ли смонтирован datastore? Иди и проверь путь на самой ноде, возможно что то отвалилось;
• Неправильно сконфигурированная сеть, вернее на frontend стоит в настройках сети, что в качестве основного интерфейса для vlan стоит br0, а на ноде прописано — bridge0 — надо чтобы было одинаково.

system datastore хранит метаданные для вашей vm, если вы запускаете vm с persistent image, то vm необходимо иметь доступ к изначально созданной конфигурации на том хранилище, где вы создавали vm — это очень важно. Поэтому при переносе vm на другой datastore надо все перепроверить.

8. Документация, сообщество. Дальнейшее развитие

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

Тут в целом, все довольно хорошо документировано и даже по официальному источнику не составит проблем установить и найти ответы на вопросы.

Сообщество, активное. Публикует много готовых решений, которые вы можете использовать в своих установках.

На данный момент с 5.12 изменились некоторые политики в компании forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 будет интересно узнать, как будет развиваться проект. В начале я специально указал некоторых поставщиков, которые используют свои решения и то что предлагает индустрия. Четкого ответа что использовать вам, конечно же нет. Но для небольших организаций поддержка своего маленького частного облака может обойтись не так дорого, как это кажется. Главное, точно знать, что это вам нужно.

Как итог, вне зависимости от того, что вы выбрали в качестве облачной системы не стоит останавливаться на одном продукте. Если у вас есть время, стоит присмотреться к другим более открытым решениям.

Есть хороший чатик t.me/opennebula активно помогают и не отправляют искать решение проблемы в гугл. Присоединяйтесь.