Opennebula. Короткие записки



    Всем привет. Данная статья написана для тех, кто до сих пор мечется между выбором платформ виртуализации и после прочтения статьи из серии «Поставили 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 активно помогают и не отправляют искать решение проблемы в гугл. Присоединяйтесь.

    Комментарии 14

      0
      Задам тот же вопрос, что и несколько лет назад:
      OpenNebula+Ceph+Zabbix минимальными средствами командной строки поднять и сопровождать возможно? В смысле, чтобы всё через гуй?
        0
        В моем случае, не использовал ceph (у меня работает на nfs шаре и часть локальные датасторы), в основном пропагандируют linstor. Изначально у меня была только одна нода, при первоначальной настройке и использованию, конечно часто ходишь в консоль, но как настроишь, исправишь ошибки — все будет работать и в основном используешь только gui.
        Конечно, если ты будешь обслуживать данный кластер, в консоль будешь заходить время от времени — это неизбежно :).
          0

          А что вы подрузамеваете под "сопровождать"? Можно использовать, не заглядывая в консоль, но не нужно. Приходится иногда допиливать по мелочи. Обновления — из консоли. Но поднимается там всё по доке из коммандной строки за условные три минуты.

            0
            Так в буквальном. Вот есть у меня заботливо сконфигурированный рабочий кластер, могу я его передать в обслуживание человеку, не знающему никсы от слова «совсем»? Причём передать так, чтобы он мне как-нибудь не позвонил среди ночи в самый неподходящий момент.
            И про поднимается тот же вопрос, чтобы при поддержке с телефона «далее-далее-далее».
              0

              Таких систем не существует в природе. Потому что оно всё работает ровно до тех пор, пока не сломается. Пока оно не сломается — её вообще "сопровождать" не нужно. А если сломается — ни одну систему неопытный сопровождающий поднять не сможет.


              Конкретно OpenNebula можно администрировать (добавлять\удалять хранилища, импортировать образы, создавать пользователей, виртуальные дата центры и так далее) из веб-интерфейса. Но это бомба замедленного действия — как и в случае с любой другой сложной системой, что с Виндой, что с vmware esxi. При этом сами хосты, на которых работает ONE администрировать нужно обычным образом — как Linux. Опять же, если сломается что-то.

          0
          Enterprise ready решение для виртуализации за 0 рублей — Nutanix Community Edition + HYCU. Получаем гиперконвергентный кластер и средство резервного копирования.
            +2
            portal.nutanix.com/page/documents/details?targetId=Nutanix-Community-Edition-Getting-Started:com-sysreqs-ce-r.html
            Ограничения до 4х узлов. Минимальные требования RAM на ноду 16 гб, 12 из которых будет выделено под cvm. Надо разрешить отправку статистики, иначе кластер будет заблокирован для управления, в том числе надо обязательно обновлять иначе блокировка.
            Если это не так, напишите коротко — будет интересно.
              0
              Всё так и есть, и ограничение на 4 хоста (лимита по производительности хостов нет), и необходимость подключения к внешним серверам, и необходимость своевременного обновления, как Nutanix, так и HYCU, но зато это полностью бесплатное решение, с минимальным порогом вхождения для установки и администрирования. Настроить кластер и резервное копирование можно ни разу не зайдя в консоль. Для тех, кто находится на стадии выбора платформы виртуализации, не стоит вот так сразу отметать Nutanix.
                +1

                Нифига себе минимальный порог вхождения:


                • Установка производится раскатыванием образа сразу на диск (работа с флешки на проде это ужас тихий).
                • После запуска нужной зайти в консоль под юзером.
                • Требования к железу: минимум один ssd да ещё и over 5gb/s производительность.
                • Сетевые адаптеры настраиваются из консоли cvm (я про lacp и прочие).
                • Создание виртуалки я бы только профи доверил: процесс неинтуитивный и требует знания nutanix bible.

                Не знаю, как по мне они собрали антипаттерны по порогу входа. Взять тот же проксмокс:


                • Классический мастер установки с диска с минимумом настроек.
                • Дальше в консоль можно вообще не входить: ceph и другие datastore, сети, пользователи и кластер настраиваются из gui.
                • Пакетная база подходит от дебиана, а значит можно ставить дрова на рейд-контроллеры и прочую специфику.
                • Мониторинг в influxdb даже внутрь виртуалки прекрасно работает.
                • kvm и lxc — там где больше чем приложение, то виртуалки, а где нужна нативная производительность, используются контейнеры.
                • Никаких анальных зондов и блокировки при несвоевременном обновлении или lockdown со стороны чебурнета.
                • Вместе с ceph и openvswitch 2gb ОЗУ без виртуалок (OpenStack от 18gb, OpenNebula от 16gb, oVirt как и VMWare от 4gb, но лучше больше, Hyper-V заточен под Win со всеми вытекающими и нет web-морды) — ресурсы не расходуются впустую.

                Как по мне, то построить инфраструктуру на Proxmox быстрее и легче. Недостатки есть как и у всех, но порог входа и рациональное использование ресурсов пока что лучшие для небольших (относительно) инсталляций. Обслуживать практически не нужно.

              +2

              Хорошая попытка, Нутаникс))

              0

              Использую в продакшене opennebula HA + ceph + IB + VxLANs ровно три года: начиная с 5.0. У системы есть свои минусы, но в целом жить можно, чуть подпиливая напильником. До недавнего времени для меня главным недостатком было отсутствие биллинга, даже коммерческого. Всё остальное терпимо.


              Но, к сожалению, только до недавнего времени: до того, как они поменяли лицензионную политику. Начиная с июня 2020 года, с выходом 5.12, в OpenNebula Community Edition обновления возможны только в рамках текущих минорных изменений версии. Т.е., например, с 5.10 на 5.12 обновиться бесплатно уже нельзя, если продукт используется в коммерческих целях. Точнее, обновиться-то можно (пакеты есть), но вот onedb в Community Edition больше не поддерживает upgrade между мажорными версиями.


              Для меня это убивает все преимущества. Так что рассматриваю, куда мигрировать. И очень недоволен этим фактом, конечно. Пока смотрю на CloudStack.

                +1
                куда мигрировать
                oVirt?
                  0

                  oVirt не поддерживает ceph напрямую, а "не напрямую" либо коряво плюс появляется SPoF (если через cinder), либо коряво и менее быстро (если через cephfs).


                  Ну, и у меня об oVirt больше представление как об enterprise-решении для корпораций, а не для public cloud — хотя тут я могу ошибаться. У OpenNebula есть, например, такая абстракция, как VDC, Virtual Data Center. Отдельный VDC выделяется клиенту, внутри VDC клиент может делать всё, что хочет, они изолированы друг от друга.

                    0
                    Тем не менее через cinder отлично работает.

                    Ну, и у меня об oVirt больше представление как об enterprise-решении для корпораций, а не для public cloud

                    а, ну это да. Если пилишь для других cloud — он наверное не будет так удобен.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое