Opennebula что такое
Перейти к содержимому

Opennebula что такое

  • автор:

OpenNebula — платформа для организации управления cloud-инфраструктурой и виртуальными окружениями

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

Код системы полностью открыт под лицензией Apache и доступен всем желающим в полном объеме без ограничений. Готовые установочные пакеты c OpenNebula доступны для Ubuntu 10.04, CentOS 5.5, Debian 5.0.6 и RHEL 5.

Система позволяет создавать Cloud-окружения трех типов:

  • Приватные cloud-системы, доступные только внутри организации, полностью подконтрольные и выполненные на собственных мощностях. В качестве системы виртуализации поддерживается использование Xen, KVM и VMware;
  • Публичные cloud-окружения, работающие в инфраструктуре внешних сервис-провайдеров, таких как Amazon EC2. Для доступа к публичным cloud-окружениям OpenNebula поддерживает такие API, как EC2 Query, OGF OCCI и vCloud;
  • Гибридные cloud-системы, сочетающие элементы публичных и приватных cloud-систем. Например, определенная критически важная часть инфраструктуры можно работать в приватном облаке, а вторичные системы вынесены во внешние облака, или изначально вся система построена как приватная, но при нехватке ресурсов в пиковые моменты к работе привлекаются мощности публичных сервисов.

  • Для менеджера по управлению инфраструктурой:
    • Динамическое изменение размера физической инфраструктуры через добавление или удаление узлов на лету и разбиение кластера на виртуальные разделы, позволяющие выделять только необходимый объем ресурсов для функционирования определенного сервиса;
    • Централизованный интерфейс для управления всеми элементами виртуальной и физической распределенной инфраструктуры;
    • Высокая степень задействования доступных ресурсов, возможность подключения внешних ресурсов, предоставления ресурсов в аренду или организации совместного использования инфраструктуры между несколькими департаментами;
    • Сокращение издержек за счет уменьшения числа физических серверов, уменьшение затрат на администрирование, обслуживание, энергоснабжение и охлаждение (вместо физических серверов предоставляются виртуальные серверы, которые более полно используют доступные физические ресурсы — например, группа мало загруженных серверов теперь может работать на одной физической машине);
    • Возможность быстрого увеличения серверной мощности за счет подключения ресурсов внешних cloud-сервисов в моменты пиковой нагрузки;
  • Для пользователя:
    • Более быстрое получение запрошенного сервиса (виртуальный сервер поднять значительно быстрее, чем купить и установить физический сервер);
    • Поддержка развертывания гетерогенных операционных окружений в рамках единой совместно используемой инфраструктуры;
    • Полный контроль за жизненным циклом виртуальных серверов.

Из новшеств второй версии платформы отмечается:

  • Средства для поддержания репозитория образов виртуальных машин, позволяющего пользователям выбрать нужный образ из каталога, не заботясь о низкоуровневых настройках и конфигурации дисковой подсистемы. Поддерживается разграничение доступа, что позволяет ограничить определенные группы пользователей только заданным списком виртуальных окружений;
  • Поддержка MySQL в качестве базы для хранения параметров OpenNebula (ранее поддерживался только SQLite), что положительно сказывается на возможностях масштабирования пакета;
  • Улучшена поддержка VMWare: с использованием libvirt переписаны интерфейсные драйверы, что позволило задействовать для VMWare все возможности, доступные ранее только при использовании KVM и Xen;
  • Проведена работа по увеличению масштабируемости, что позволило оптимизировать OpenNebula для управления десятками тысяч виртуальных окружений. В частности, переработаны модули планировки и мониторинга;
  • Разделен код управления виртуальными машинами и сбора информации (мониторинг), что увеличило гибкость решения и сократило объем соединений к узлам сети;
  • Поддержка кластерных конфигураций: физические хосты теперь могут быть сгруппированы в логические кластеры, которые могут выступать обработчиками определенных виртуальных машин;
  • Добавлены инструменты для аккаунтинга и генерации отчетов об активности пользователей и серверов;
  • Процесс авторизации и аутентификации реорганизован, вынесен из ядра и теперь работает через подключение дополнений (напирмер, созданы модули для LDAP, Kerberos, авторизации с учетом состояния квот, аутентификация на базе RSA-ключен и т.п.);
  • Возможность управления квотами, через задание определенным пользователям набора ограничений на использование ресурсов;
  • Поддержка привязки дополнительных атрибутов, ассоциированных с заданной виртуальной сетью (параметры шлюза, DNS), которые будут использованы в контексте указанных виртуальных машин;
  • Разработаны биндинги для языка Java с реализацией OpenNebula Cloud API (OCA), включающие поддержку обращения к базовым методам через XML-RPC;
  • Улучшена поддержка API EC2 и OCCI.

Поделиться:

Оставьте свой комментарий!

⁠Часть IV. OpenNebula

Product SiteDocumentation Site

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

Облачная архитектура определяется 3-мя элементами: хранилищем данных, сетью и системой виртуализации.

OpenNebula состоит из следующих компонентов:
Сервер управления (Front-end) — на нём выполняются сервисы OpenNebula;
Серверы с виртуальными машинами;
Хранилище данных — содержит образы виртуальных машин;

Физическая сеть — обеспечивает связь между хранилищем данных, серверами с виртуальными машинами, поддерживает VLAN-ы для виртуальных машин, а также управление сервисами OpenNebula.

Примечание

Компоненты OpenNebula будут установлены в систему, если при установке дистрибутива выбрать профиль Вычислительный узел Opennebula KVM , Вычислительный узел Opennebula LXD или Сервер управления Opennebula (см. главу Установка системы).

Содержание

OpenNebula

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

Архитектура

Облачная архитектура определяется 3-мя элементами: хранилищем данных, сетью и системой виртуализации.

OpenNebula состоит из следующих компонентов:

  • Сервер управления (Front-end) — на нём выполняются сервисы OpenNebula.
  • Серверы с виртуальными машинами.
  • Хранилище данных — содержит образы виртуальных машин.
  • Физическая сеть — обеспечивает связь между хранилищем данных, серверами с виртуальными машинами, поддерживает VLAN-ы для виртуальных машин, а также управление сервисами OpenNebula.

Планирование ресурсов

Минимальные требования к серверу управления
Ресурс Минимальное значение
Оперативная память 2ГБ
CPU 1 CPU (2 ядра)
Диск 100ГБ
Сеть 2 интерфейса

Максимальное количество серверов, управляемых одним front-end-ом, зависит от инфраструктуры, особенно от производительности хранилища. Обычно рекомендуется не управлять более чем 500-ми серверами из одной точки, хотя существуют примеры с более чем 1000 серверами.

Сервера виртуализации
  • CPU: в обычных условиях каждое ядро, предоставляемое виртуальной машине (ВМ), должно быть реальным ядром физического процессора, например, для обслуживания 40 ВМ с 2-мя процессорами в каждой, облако должно иметь 80 физических ядер. Они могут быть распределены по разным серверам: 10 серверов с 8-ю ядрами или 5 серверов с 16-ю ядрами на каждом. В случае перераспределения недостаточных ресурсов используются атрибуты CPU и VCPU: CPU означает физические ядра, выделенные для ВМ, а VCPU — виртуальные ядра для гостевой ОС.
  • Память: по умолчанию, OpenNebula не предоставляет памяти для гостевых систем больше, чем есть на самом деле. Желательно рассчитывать объём памяти с запасом в 10% на гипервизор. Например, для 45 ВМ с 2ГБ памяти на каждой, необходимо 90ГБ физической памяти. Важно количество физических серверов: каждый сервер должен иметь 10% запас для работы гипервизора, так, 10 серверов с 10ГБ памяти на каждом могут предоставить по 9ГБ для виртуальных машин и смогут обслужить 45 машин из этого примера (10% от 10ГБ = 1ГБ на гипервизор).
Хранилище данных

OpenNebula работает с двумя видами данных в хранилище: образцами виртуальных машин и образами (дисками) самих ВМ. Планирование хранилища — очень важная задача, т.к. от него зависит производительность облака. Например, при использовании Ceph для среднего по размеру облака, необходимо взять как минимум 3 сервера в следующей конфигурации: 5×1ТБ дисков, 16ГБ памяти, 2 CPU с 4-мя ядрами на каждом и 2 сетевые карты (минимум).

Сеть

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

Установка

Сервер управления

Установить сервер управления OpenNebula можно следующей командой:

# apt-get install opennebula-server opennebula-common gem-opennebula-cli opennebula-flow opennebula-sunstone opennebula-gate gem-http-cookie 

После успешной установки необходимо обновить зависимости пакетов, выполнив команду:

# apt-get update && apt-get dist-upgrade 

Установка кластера высокой доступности для снижения простоев основных сервисов OpenNebula

Установка MySQL (MariaDB) для хранения конфигурации (на сервере управления):

# apt-get install mariadb # systemctl enable --now mariadb.service # mysql_secure_installation # mysql -u root 
mysql> GRANT ALL PRIVILEGES ON opennebula.* TO 'oneadmin' IDENTIFIED BY ''; mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED; 

Перед запуском сервера OpenNebula в первый раз необходимо настроить параметры доступа к базе данных в конфигурационном файле /etc/one/oned.conf :

DB = [ backend = "mysql", server = "localhost", port = 0, user = "oneadmin", passwd = "", db_name = "opennebula" ]

Периодические задания для чистки БД.

Проверка работы сервера управления

Для проверки работоспособности сервера управления необходимо выполнить следующую команду (от имени пользователя oneadmin):

oneadmin$ oneuser show USER 0 INFORMATION ID : 0 NAME : oneadmin GROUP : oneadmin PASSWORD : 67aedfae4124dd409035f32ea2f25fgeae6 AUTH_DRIVER : core ENABLED : Yes USER TEMPLATE TOKEN_PASSWORD="ec21d27e247fedhasabcb08b8e0a4ca3c" RESOURCE USAGE & QUOTAS
Проксирование запросов к серверу Sunstone

Для соединения с веб-интерфейсом сервера управления желательно использовать протокол SSL, для чего необходимо установить дополнительный прокси, а сервер управления настроить на прослушивание только локального адреса 127.0.0.1:9869. Пример настройки HTTP сервера Nginx:

# apt-get install nginx 

В файле конфигурации виртуального сервера /etc/nginx/sites-enabled/sampleserver.org :

#### OpenNebula Sunstone upstream upstream sunstone < server 127.0.0.1:9869; >#### sampleserver.org HTTP virtual host server < listen 80; server_name sampleserver.org; ### Permanent redirect to HTTPS (optional) return 301 https://$server_name:8443; >#### sampleserver.org HTTPS virtual host server < listen 8443; server_name sampleserver.org; ### SSL Parameters ssl on; ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; ### Proxy requests to upstream location / < proxy_pass http://sunstone; >>

Изменения в файле конфигурации /etc/one/sunstone-server.conf :

:host: 127.0.0.1 :port: 9869
Сервер виртуализации

Установка серверов виртуализации (для системы виртуализации KVM):

# apt-get install opennebula-node-kvm # systemctl enable --now libvirtd 

Ключи для доступа по SSH

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 у меня не оказалось, если кто пробовал напишите.

Также пробовал прикрутить 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 — надо чтобы было одинаково.

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

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

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

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

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

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

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

  • IT-инфраструктура
  • *nix
  • Виртуализация
  • Облачные вычисления

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *