OpenStack

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:54, 2 декабря 2017.
OpenStack
Openstack logo.png
Постоянный выпуск: Mitaka[1][2] / 7 April 2016 года; 6 years ago (2016-04-07)
Написана на: Python
Операционная система: Cross-platform
Тип ПО: Cloud computing
Лицензия: Apache License 2.0
Веб-сайт openstack.org

OpenStack – Open source проект по разработке платформы, позволяющей строить частные и публичные «облака» (cloud computing). Цель проекта - предоставление простых и удобных широкомасштабных и многофункциональных решений для любого типа «облака». Технология включает в себя серию взаимосвязанных проектов, обеспечивающих разработку многочисленных составляющих инфраструктурного решения для «облака»[3].

OpenStack был создан для того, чтобы обеспечить массовый запуск сотен, тысяч и даже десятков тысяч однотипных (как правило) виртуальных серверов для хостинга приложений с собственными средствами обеспечения отказоустойчивости. Сама платформа не предлагает высокой доступности отдельно взятого виртуального сервера.

Содержание

Создание

Проект OpenStack возник по инициативе двух производителей и объединил их продукты – объектное хранилище Rackspace и систему управления гипервизорами NASA. «OpenStack призван помочь организациям предоставлять облачные вычислительные ресурсы, запущенные на стандартном оборудовании», – заявляют вендоры. В данном материале мы попробуем разобраться, так ли это на самом деле.

OpenStack сегодня

Первый релиз OpenStack вышел в октябре 2010 г. Так компания Rackspace стала одним из ближайших конкурентов другого облачного провайдера IaaSAmazon Web Services (AWS), который в то время сильно терял свои позиции. По сути, OpenStack – копия AWS: многие сервисы и процессы в этих платформах одинаковы и даже совместимы между собой.

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

  • средство управления гипервизорами (Nova)
  • объектное хранилище (Swift)
  • хранилище образов виртуальных машин (Glance)
  • веб-интерфейс управления (Horizon)
  • каталог пользователей и сервисов (Keychain)
  • средство управления сетевой инфраструктурой (Neutron)
  • блочное хранилище (Cinder)
  • оркестратор облачных приложений (Heat)
  • инструмент учета потраченных ресурсов (Ceilometer)
  • средство предоставления БД как услуги.

В ближайшем будущем планируется реализовать такие возможности, как предоставление физического оборудования по запросу, а также развертывание кластеров Hadoop[4].

Что такое OpenStack?

OpenStack – комплекс программного обеспечения, реализующий функции облачной платформы. Он позволяет управлять пулами различных ресурсов по типу IaaS.

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

  • балансировщики нагрузки (Load Balancer as a Service),
  • средства защиты периметра (Firewall as a Service, Security Groups),
  • объектное хранение данных, совместимое с Amazon S3.

Доступ к ресурсам, предоставляемый платформой, возможен «по клику» через портал самообслуживания. Пользователи платформы могут самостоятельно создавать виртуальные сети, маршрутизаторы, дисковые устройства всего в несколько кликов, а платформа OpenStack будет самостоятельно внедрять эти изменения на низком уровне, обеспечивая интеграцию с различным сетевым оборудованием и системами хранения данных. После настройки сетей пользователям доступна возможность создавать виртуальные серверы из заранее заданных образов виртуальных серверов. Большая часть пользовательских операций интуитивно понятна и не требует специфических знаний используемых низкоуровневых технологий.

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

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

OpenStack не является гипервизором, но он поддерживает несколько гипервизоров через слой абстракции. В том числе популярные гипервизоры (коммерческие и с открытым исходным кодом). Среди них: KVM, Xen, QEMU, Microsoft Hyper-V, доступна с VMware vSphere (ESXi в чистом виде не поддерживается)[5].

В чем преимущества OpenStack?

OpenStack сокращает время на развертывание и вывод на рынок тех или иных приложений.

Вокруг OpenStack образовалась огромная экосистема, в которой принимают участие большое количество разработчиков из более чем 500 крупнейших компаний-лидеров ИТ-индустрии мира. Существует большое количество вендор-специфичных модулей для OpenStack, решающих те или иные задачи. Продукт активно развивается, что вызывает большой интерес у многих компаний, среди которых: at&t, Ubuntu, Hewlett Packard Enterprise, IBM, Intel, Rackspace, RedHat, SUSE.

Концепции облака OpenStack

Облачные платформы, такие как OpenStack, предназначены для использования с другим классом приложений, таких как Apache Cassandra, MongoDB и Hadoop, которые спроектированные для горизонтального масштабирования (scale-out), и являются устойчивыми к падению виртуальных машин. Ресурсы могут быть расширены за счет добавления новых экземпляров приложений на однотипных виртуальных серверах с последующей балансировкой нагрузки. Эти распределенные приложения самостоятельно обеспечивают собственную отказоустойчивость на уровне приложения, независимо от базовой инфраструктуры и передовых функций гипервизоров.

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

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

В чем разница подходов облака и традиционной инфраструктуры?

Если сравнить запущенные экземпляры виртуальных серверов с животными, то традиционные платформы обеспечивают принцип работы «домашний питомец», а OpenStack – подход «стадо» (иногда встречается термин «свиноферма»).

Каждый домашний питомец уникален: у него есть имя, свои повадки и характер. Кот Вася у соседа и ваша Мурка – это две совершенно разные кошки. Если ваш кот болеет – вы ведете его к ветеринару, вы его лечите, заботитесь о его состоянии, вы его кормите и ухаживаете за ним.

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

Сравнение подходов к виртуальной инфраструктуре:

  1. Подход "Домашнее животное":
    • Уникальны (имена вроде rocky, mainserver, adcontroller);
    • Наличие процедур патчинга;
    • Требуются средства высокой доступности от инфраструктурной платформы;
    • При выходе из строя - восстановление.
  2. Подход "Стадо":
    • Идентичны друг другу (имена вроде host111);
    • Наложение патчей на темплейт - переразворачивание из темплейта;
    • Высокая доступность приложения обеспечена средствами приложения и несколькими экземплярами приложения в облаке;
    • При выходе из строя - удаление, создание нового[6].

Основные компоненты OpenStack

  • Nova — контроллер вычислительных ресурсов;
  • Glance — библиотека образов виртуальных машин, обычно с бэкендом в Swift;
  • Swift — облачное файловое хранилище;
  • Cinder — служба работы с блочными устройствами хранения данных (выведена из Nova в отдельный проект);
  • Keystone — сервис идентификации;
  • Neutron (в первых выпусках — Quantum) — сервис «подключение к сети как услуга» между интерфейсами устройств (vNIC), которые управляются другими сервисами OpenStack.
  • Horizon — графический интерфейс администрирования.
  • Heat - оркестратор
  • Ceilometer - средства сбора, нормализации и трансформации данных, предоставляемых сервисами OpenStack. Собираемые данные используются для реализации различных сценариев реагирования на события.
  • Trove - База данных
  • Sahara - Elastic Map Reduce
  • Ironic - средства управления и провижининга физическими серверами (Bare Metal Provisioning)
  • Zaqar - Multiple Tenant Cloud Messaging
  • Manila - Shared File System Service
  • Designate - DNS как сервис (DNSaaS - DNS as a Service)
  • Barbican - API безопасности
  • Searchlight - передовая и масштабируемая индексация и поиск по многопользовательских облачных ресурсах.

OpenStack Compute (Nova) - отвечает за создание, запуск, перезапуск, остановку виртуальных машин, и т.д. компонент для контроля вычислительных ресурсов. Модуль может работать с различными технологиями виртуализации (гипервизорами), такими, как KVM, VMware, Xen, а также с Hyper-V и системами виртуализации на уровне операционной системы, такими, как LXC. Также модуль может управлять конфигурациями bare metal и high-performance computing.

Nova

Что такое Nova

Nova - это проект OpenStack, который обеспечивает способ предоставления вычислительных облаков (например, виртуальных серверов). Nova поддерживает создание виртуальных машин, [baremetal (на "голом" железе)] серверов и имеет ограниченную поддержку системных контейнеров. Nova работает как набор демонов поверх существующих серверов Linux для предоставления этой услуги. Для выполнения основных функций необходимо предустановить такие OpenStack сервисы:

  • Keystone - обеспечивает идентификацию и аутентификацию для всех служб OpenStack.
  • Glance - обеспечивает репозиторий образов. Все экземпляры вычислений запускаются с Glance образов.
  • Neutron - обеспечивает предоставление виртуальных или физических сетей, которые вычисляют экземпляры, подключаемые при загрузке.

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

Для конечного пользователя

Конечный пользователь будет использовать Nova для создания и управления серверами с помощью либо инструментов, либо API напрямую.

Инструменты для использования Nova
  • Horizon - официальный веб-сайт проекта OpenStack
  • OpenStack клиент - официальный CLI для проектов OpenStack. Его необходимо использовать как свой CLI, он включает в себя не только команды Nova, но и команды для большинства проектов в OpenStack.
  • Клиент Nova - для некоторых продвинутых или административных команд Nova. Рекомендуется все же использовать OpenStack CLI.
Запись в API

Все конечные пользователи (и некоторые административные) функции Nova отображаются с помощью REST API, который может использоваться для создания более сложной логики или автоматизации. Это можно использовать напрямую или через различные SDK. Следующие ресурсы помогут вам начать с непосредственного использования API:

  • Compute API Guide - руководство по разработке API. Помогает сформулировать концепции API, чтобы облегчить использование ссылок API.
  • Compute API Reference - сборник всех функций для API-интерфейса вычислений, включая все методы и параметры запроса / ответа и их значение.
  • Compute API Microversion History - реализация различных версий.
  • Placement API Reference - справочник к Compute API Reference
  • Placement API Microversion History - справочник к Compute API Microversion History.
  • Block Device Mapping - это параметры привязки блока, используемые для подключения определенных блочных устройств к вычислениям.

Nova может быть настроена на предоставление уведомлений через RPC.

  • Versioned Notifications - это список существующих версий с уведомлениями и образцами.

Официальные репозитории проекта:

Neutron

Что такое Neutron

Neutron - это проект OpenStack, обеспечивающий «сетевое подключение как услугу» между устройствами интерфейса (например, vNIC), управляемыми другими службами OpenStack (например, Nova). Он реализует API-интерфейс Neutron.

  • Предоставляет облачным арендаторам API для создания богатых сетевых топологий и настраивания передовых сетевых политик в облаке.
    • Пример: создание многоуровневой топологии веб-приложений
  • Включает инновационные плагины (открытый и закрытый источник), которые предоставляют расширенные возможности сети
    • Пример: использование туннелирования L2-in-L3 во избежание ограничений VLAN, предоставление сквозных гарантий QoS, использование протоколов мониторинга, таких как NetFlow.
  • Дает каждому создавать расширенные сетевые службы (открытый и закрытый источник), которые подключаются к сетям арендаторов Openstack.
    • Примеры: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS (не реализованы), data-center-interconnect-aaS.
  • Поддержка GUI Horizon для:
    • Нейтронных L2 и L3 сетей и создание / удаление подсети
    • Загрузки виртуальных машин в определенных Neutron сетях.
  • API Extensibility Framework, включая расширения для:
    • «сети провайдеров», которая отображает сети Neutron L2 для конкретной VLAN в физическом центре обработки данных

Neutron был представлен в качестве основной части OpenStack с выпуском Folsom. До релиза Folsom сетевые функции были жестко привязаны к модулю Nova OpenStack, что потребовало от разработчиков одновременного разрабатывания как вычислительных, так и сетевых функций OpenStack. С Neutron сетевое взаимодействие стало более модульным, что положительно сказывается как на качестве, так и на времени разработки. Ядро Neutron API включает поддержку сетевого взаимодействия 2 уровня и IP-адресов (IPAM), а также расширение для маршрутизатора 3 уровня, которое обеспечивает маршрутизацию между сетями второго уровня и шлюзами во внешние сети. Neutron включает в себя растущий список плагинов, которые обеспечивают возможность взаимодействия с различными коммерческими и сетевыми технологиями с открытым исходным кодом, включая маршрутизаторы, коммутаторы, виртуальные коммутаторы и программные сетевые контроллеры (SDN).

Официальные репозитории проекта:

Swift

Что такое Swift

Проект OpenStack Object Store, известный как Swift, предлагает облачное программное обеспечение для хранения данных, позволяющее хранить и извлекать множество данных с помощью простого API. Он построен для масштабирования и оптимизирован для обеспечения долговечности, доступности и параллелизма во всем наборе данных. Swift идеально подходит для хранения неструктурированных данных, которые могут расти без ограничений.

Официальные репозитории проекта:

Glance

Что такое Glance

Услуга просмотра образов включает обнаружение, регистрацию и извлечение образов виртуальной машины. В Glance есть RESTful API, который позволяет запрашивать метаданные образов VM, а также извлекать фактический образ. Образы VM, доступные через Glance, могут храниться в разных местах от простых файловых систем до систем хранения объектов, таких как OpenStack Swift. На первый взгляд образы хранятся в виде шаблона, который используется для запуска новых экземпляров. Glance был разработан как автономная служба для тех, кому нужно организовать большие наборы образов виртуальных дисков. Glance предоставляет комплексное решение для управления образами облачных дисков. Он также может выполнять моментальные снимки из исполняемого экземпляра для резервного копирования виртуальных машин и их состояний.

Архитектура Glance

Glance имеет архитектуру клиент-сервер и предоставляет Rest API, через который выполняется запрос на сервер. Запрос от клиента принимается через Rest API и ожидает аутентификации Keystone. Glance-контроллер домена управляет всеми внутренними операциями, которые разделены на слои, каждый уровень реализует свои собственные задачи. Glance store - это уровень связи между Glance и внешними хранилищами данных или локальной файловой системой и обеспечивает единый интерфейс для доступа. В системе используется база данных SQL Central, доступная для всех компонентов системы. Архитектура Glance состоит из нескольких компонентов:

  • Клиент - любое приложение, использующее сервер Glance.
  • REST API - предоставляет функции Glance через REST.
  • Уровень абстракции базы данных (DAL - Database Abstraction Layer) - интерфейс прикладного программирования, который объединяет связь между Glance и базами данных.
  • Glance Domain Controller - промежуточное программное обеспечение, которое реализует основные функции Glance: авторизация, уведомления, политики, подключения к базе данных.
  • Glance Store - организует взаимодействие между Glance и различными хранилищами данных.
  • Уровень реестра (Registry Layer) - дополнительный уровень, организующий безопасную связь между доменом и DAL с помощью отдельной службы.
Архитектура Glance

Форматы Glance

Когда мы загружаем образ, чтобы заглянуть, нам нужно указать форматы образов виртуальной машины. Glance поддерживает широкий спектр форматов, таких как форматы дисков и форматы контейнеров. Виртуальный диск аналогичен загрузочному драйверу физического сервера, только сжатому в файл. Различные виртуализации поддерживают разные форматы дисков.

Дисковые форматы

Форматы дисков образа виртуальной машины - это формат образа диска. Ниже приведены форматы дисков, поддерживаемые OpenStack.

  1. Raw - формат необработанного неструктурированного диска.
  2. VHD- наиболее распространенный формат, поддерживаемый большинством технологий виртуализации OpenStack, кроме KVM.
  3. VMDK - формат, распространенный VMware.
  4. QCOW2 - QEMU формат образов, собственный формат для KVM и QEMU, поддерживает расширенные настройки.
  5. VDI - формат изображений виртуального диска, созданный Oracle VM VirtualBox.
  6. ISO - формат архива для оптических дисков.
  7. AMI,ARI, AKI - Amazon машины, Ramdisk, и ядро образа.
Форматы контейнеров

Как видно, OpenStack также поддерживает концепцию разных форматов контейнера, которая описывает форматы файлов и содержит дополнительные метаданные о виртуальной машине. Ниже приведены форматы контейнеров, которые поддерживаются в OpenStack.

  1. bare - показывает, что для образа нет контейнера или метаданных.
  2. ovf - формат контейнера OVF.
  3. aki - в Glance хранится образ ядра Amazon.
  4. ari - в Glance хранится образ ramdisk Amazon.
  5. ami - в Glance хранится образ machine Amazon.
  6. ova - в Glance хранится образ архива OVA.
  7. docker - в Glance хранится Docker архив файловой системы контейнера.

Официальные репозитории проекта:

Keystone

Что такое Keystone

Keystone - это служба идентификации, используемая OpenStack для аутентификации (authN) и авторизации высокого уровня (authZ). В настоящее время он поддерживает авторизацию на основе токенов и авторизацию пользовательского сервиса. В последнее время он был модифицирован, появилась возможность установки расширения для поддержки проксирования внешних служб и механизмов AuthN / AuthZ, таких как oAuth, SAML и openID в будущих версиях.

Компоненты Keystone

  1. Пользователь (User) - представляет собой цифровой идентификатор человека, системы или службы, которые используют облачные сервисы OpenStack. Keystone гарантирует, что входящие запросы поступают от действительного пользователя, которому могут быть назначены токены доступа к ресурсам. Пользователи назначаются конкретному арендатору с конкретной ролью.
  2. Арендатор (Tenant) - это группа, используемая для выделения ресурсов и / или пользователей. Группы могут быть сопоставлены с клиентами, проектами или организациями.
  3. Роль (Role) - включает в себя набор назначенных прав и привилегий пользователя для выполнения определенного набора операций. Пользовательский токен, выданный Keystone, включает список ролей этого пользователя. Затем службы определяют, как интерпретировать эти роли.
  4. Учетные данные (Credentials) - это данные, известные только конкретному пользователю, который подтверждает свою личность. К примеру включает имя пользователя и пароль, имя пользователя и ключ API, или токен аутентификации.
  5. Аутентификация (Authentication) - это акт подтверждения личности пользователя путем проверки набора предоставленных пользователем учетных данных. Эти учетные данные изначально являются именем пользователя и паролем или именем пользователя и ключом API. В ответ на учетные данные служба идентификации отправляет токен аутентификации, который пользователь должен предоставить для последующих запросов.
  6. Токен (Token) - это произвольный бит текста, используемый для доступа к ресурсам. Каждый токен имеет область, описывающую доступные ресурсы. Маркер может быть отозван в любое время и действителен в течение конечного времени. В общем, токен - это часть данных, предоставленных пользователю Keystone при предоставлении правильной комбинации имени пользователя и пароля. Как было сказано выше, то, что тесно связано с токеном, это дата его истечения (обычно это часы или даже минуты). Пользовательский клиент может кэшировать токен и вводить его в запрос API OpenStack. Конечные точки API OpenStack берут токен из пользовательских запросов и проверяют его на основе аутентификации Keystone, тем самым подтверждая легитимность вызова.
  7. Сервис (Service) - служба OpenStack, такая как Compute (Nova), Object Storage (Swift) или Image Service (Glance), предоставляет один или несколько конечных точек, через которые пользователи могут обращаться к ресурсам и выполнять операции.
  8. Конечная точка (Endpoint) - это доступный по сети адрес, обычно описываемый URL-адресом, с которого осуществляется доступ к услугам.
Keystone v2 - UUID

UUID - уникальный идентификатор объекта - пользователь в нашем случае. В более ранних версиях Keystone он использовался в качестве основы для токена. Наиболее важные вещи происходят здесь при проверке шага UUID, когда каждое приложение после каждого запроса клиента, проверяется действительность токена онлайн, эта операция генерирует огромный сетевой трафик, особенно, если есть сотни пользователей. Фактически, Keystone был, пожалуй, самым загруженным сервисом OpenStack до появления Keystone v3.

Keystone v3 - PKI

С появлением третьей версии Keystone сервис был перенесен на проверенную временем платформу PKI (ее принцип 1:1, как в Windows PKI). Сервер со службой OpenStack Identity изменился, чтобы работать в качестве центра сертификации (CA), а токены получили цифровые подписи.

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

Во время проверки подписи извлекается информация о ролях пользователя. На основе этой информации приложение обрабатывает или отклоняет запрос клиента. Если подпись подделана или истек срок действия (дата истечения срока действия также возвращается во время проверки), клиенту будет отказано. Кроме того, каждый второй токен в запросах пользователей проверяется в сводном списке CA для достоверности. Если сервер Keystone или администратор удаляют токен пользователя, он будет автоматически включен в список отзыва и отклонен любой программой в OpenStack. Активный сеанс клиента также не поможет - он будет удален.

У Keystone есть только одна особенность, которая должна быть принята во внимание. Служба не шифрует переданные данные, поэтому не забудьте использовать SSL для передачи личных данных.

Официальные репозитории проекта:

Cinder

Что такое Cinder

Cinder - это служба хранения блоков для OpenStack. Он предназначен для представления ресурсов хранения конечным пользователям, которые могут быть использованы проектом OpenStack Compute (Nova). Это делается с использованием либо эталонной реализации (LVM), либо драйверов плагинов для другого хранилища. Краткое описание Cinder заключается в том, что он виртуализирует управление устройствами хранения блоков и предоставляет конечным пользователям API самообслуживания запрашивать и потреблять эти ресурсы, не требуя каких-либо знаний о том, где их хранилище фактически развернуто или на каком типе устройства.

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

Физические носители данных, будь то диски или твердотельные диски, могут быть расположены внутри или напрямую подключены к узлам сервера Cinder, или они могут быть расположены во внешних системах хранения от сторонних поставщиков. Сторонние поставщики хранилищ используют архитектуру плагина Cinder для выполнения необходимых интеграционных работ. Внутренний путь от внешних систем хранения до вычислительных узлов, где расположены гипервизоры, может быть iSCSI, Сетевая файловая система (NFS) или Fibre Channel. Многие поставщики хранилищ теперь обеспечивают поддержку блок девайсов. К ним относятся EMC, Hitachi Data Systems, HP, IBM и NetApp. Существует также значительная поддержка Cinder от стартапов, включая SolidFire, Nexenta, Pure Storage и Zadara Storage.

Реализации OpenStack обычно строятся вокруг масштабируемых конфигураций серверов, поэтому Fibre Channel не лучший выбор протокола. Это, вероятно, будет дорогостоящим и сложным для реализации из-за аппаратных затрат и проблем масштабирования Fibre Channel на большом количестве узлов хранения.

Поддержка NFS была представлена ​​с выпуском OpenStack от Grizzly, хотя она была экспериментально представлена ​​с Folsom. Тома виртуальной машины под хранилищем NFS рассматриваются как отдельные файлы, аналогично реализации хранилища NFS на VMware или VHD на Hyper-V.

Компоненты Cinder

  1. Том (Volume) - по требованию выдает хранилище виртуальных машин. Служба томов управляет взаимодействием с блочными устройствами хранения. Когда запросы поступают из планировщика, служба томов создает, изменяет и удаляет тома по мере необходимости.
  2. Api - отвечает и обрабатывает запросы и помещает их в очередь сообщений. Когда принимается входящий запрос, служба API проверяет требования идентификации, и выполняется перевод запроса в сообщение, обозначающее необходимые операции хранения блоков. Затем сообщение отправляется обработчику сообщений для обработки другими службами хранения блоков.
  3. Резервное копирование (backup) - обеспечивает возможность резервного копирования тома блока хранения во внешний репозиторий хранилища.
  4. Планировщик (scheduler) - назначает задачи очереди и определяет сервер томов обеспечения. Служба планировщика считывает запросы из очереди сообщений и определяет, на каком узле хранения блоков должен быть выполнен запрос. Затем планировщик связывается с сервисом томов на выбранном хосте для обработки запроса.
  5. База данных (Database) - предоставляет информацию о состоянии.
  6. RabbitMQ server - предоставляет очередь сообщений AMQP. RabbitMQ (также используемый другими службами) обрабатывает управление транзакциями OpenStack, включая организацию очередей, распределение, безопасность, управление, кластеризацию. Сообщения становятся особенно важными, когда развертывание OpenStack масштабируется и его службы работают на нескольких машинах.

Представление

Во многих развертываниях OpenStack все службы Cinder, за исключением службы томов, находятся на узлах контроллера. В этих развертываниях товарные серверы используются в качестве выделенных узлов тома Cinder, при этом на них работают службы томов Cinder, как показано ниже. В этой конфигурации узел томов Cinder функционирует как недорогой, без излишеств массив хранения данных, который служит для простых блоков для облачных экземпляров, используя Logical Volume Manager (LVM), входящий во все дистрибутивы Linux, для управления локально подключенным хранилищем.

Cinder устройство

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

  1. Проблема расширения - при развертывании товарного решения Cinder, скорее всего, это более дешевый вариант, когда требования к мощности низки,но он становится менее экономичным в случаях использования больших мощностей. Например, типичным узлом узла Cinder в развертывании OpenStack может быть сервер Dell R720 с 8 внутренними дисками. Использование 600-Гбайт дисков SAS на 600 ГБ даст ~ 2,3 ТБ с RAID 10 и ~ 5,4 ТБ с RAID 5 и менее, очевидно, с SSD. Если пользователи, нуждались в 12 ТБ хранилища Cinder и нуждались в том, чтобы они были на дисках SAS на 600 ГБ в конфигурации RAID 10; использование только серверов означало бы внедрение решения с 5 узлами томов Cinder.
  2. Отсутствие избыточности - eще одним ограничением в товарном решении Cinder является отсутствие избыточности. Хотя оба узла могут управляться одними и теми же облачными контроллерами, узлы тома фактически являются независимыми «массивами хранения», которые не обмениваются данными друг с другом. Фактически это означает, что если узел узла Cinder терпит неудачу, все тома, экспортированные этим узлом, а также данные на нем, становятся недоступными.

Официальные репозитории проекта:

Внедрение OpenStack

Благоприятными условиями использования платформы OpenStack, с точки зрения ICL Services являются:

  • хостинг серверов и приложений с коротким сроком жизни (часы, дни, недели);
  • облачный тип нагрузки используемых приложений;
  • хостинг некритичных виртуальных серверов и приложений;
  • частое развертывание однотипных серверов.

Все эти условия вытекают из специфики использования OpenStack и прежде всего отсутствия поддержки высокой доступности отдельно взятого виртуального сервера.

Установка OpenStack на Debian

Управляющий узел

Настройка сетевого интерфейса

  1. Настроем интерфейс тривиальным образом: зададим IP адрес для нода (зависит от вашей настройки сети, оригинальная статья предлагает адреса NAT по типу 10.0.0.11), маску сети 255.255.255.0 ( 255.255/24), а так же стандартный шлюз (10.0.0.1)
  2. Для автоматической настройки необходимо настроить файл конфигурации сети:

Замените INTERFACE_NAME с вашим актуальным названием, обычно eth1 или ens224.

  • Отредактируйте /etc/network/interfaces примерно так, как показано ниже:
# The provider network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
  1. Перезагрузите систему для сохранения настроек (также можно перезапустить систему сети)
# /etc/init.d/networking restart

Настройка имен доступа

  1. Назовем наш главный узел controller.
  2. Отредактируйте /etc/hosts подобным образом(адреса заданы для наглядности, их необходимо поменять на свои):
# главный узел
10.0.0.11       controller

# вычислительный узел
10.0.0.31       compute1

# узел блоков
10.0.0.41       block1

# узел объектов 1
10.0.0.51       object1

# узел объектов 2
10.0.0.52       object2

Вычислительный узел

Настройка сетевого интерфейса
  • Настроить интерфейс сети на ноде (примерным образом): IP адрес: 10.0.0.31 Маска: 255.255.255.0 (255.255/24) Шлюз: 10.0.0.1
  • Также как и в управляющем ноде зададим для простоты адреса: Необходимо заменить INTERFACE_NAME на актуальной для вашей системы интерфейс,eth or ens224
    • Изменить необходимо в /etc/network/interfaces
# The provider network interface
auto INTERFACE_NAME
iface  INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
  • Перезапустить службу сети, или полностью нод.
Настройка имен доступа

Абсолютно аналогично настройки управляющего узла.

Нод хранения блоков (опционально)

Все настройки аналогично предыдущем:

Настройка сетевого интерфейса
  • Настроить интерфейс сети на ноде (примерным образом): IP адрес: 10.0.0.31 Маска: 255.255.255.0 (255.255/24) Шлюз: 10.0.0.1
  • Также как и в управляющем ноде зададим для простоты адреса: Необходимо заменить INTERFACE_NAME на актуальной для вашей системы интерфейс,eth or ens224
  • Изменить необходимо в /etc/network/interfaces
# The provider network interface
auto INTERFACE_NAME
iface  INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
  • Перезапустить службу сети, или полностью нод.
Настройка имен доступа
  • Отредактируйте /etc/hosts подобным образом(адреса заданы для наглядности, их необходимо поменять на свои):
# главный узел
10.0.0.11       controller

# вычислительный узел
10.0.0.31       compute1

# узел блоков
10.0.0.41       block1

# узел объектов 1
10.0.0.51       object1

# узел объектов 2
10.0.0.52       object2

Проверка соединения

Рекомендую проверить соединения на доступность, к примеру:

  • Может ли controller выходить в интернет, также необходимо проверить на всех нодах аналогично:
# ping -c 4 ru.bmstu.wiki

PING ru.bmstu.wiki (195.19.44.140) 56(84) bytes of data.
64 bytes from h140.net44.bmstu.ru (195.19.44.140): icmp_seq=1 ttl=48 time=46.1 ms
64 bytes from h140.net44.bmstu.ru (195.19.44.140): icmp_seq=2 ttl=48 time=45.7 ms
64 bytes from h140.net44.bmstu.ru (195.19.44.140): icmp_seq=4 ttl=48 time=56.8 ms

-— ru.bmstu.wiki ping statistics —-
4 packets transmitted, 3 received, 25% packet loss, time 3021ms
rtt min/avg/max/mdev = 45.747/49.568/56.849/5.156 ms
 
  • Из контроллера в другие ноды:
# ping -c 4 compute1

PING compute1 (10.0.0.31) 56(84) bytes of data.
64 bytes from compute1 (10.0.0.31): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=4 ttl=64 time=0.202 ms

--- compute1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
 
  • Из нодов к главному:
# ping -c 4 controller

PING controller (10.0.0.11) 56(84) bytes of data.
64 bytes from controller (10.0.0.11): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from controller (10.0.0.11): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from controller (10.0.0.11): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from controller (10.0.0.11): icmp_seq=4 ttl=64 time=0.202 ms

--- controller ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms

Сетевой протокол времени

Необходимо установить Chrony, реализацию NTP, для правильной синхронизации служб между узлами. Рекомендуется настроить управляющий таким образом, чтобы он сам синхронизировался с более точным сервером и пересылал на другие.

Управляющий узел
  • Установка необходимых пакетов:
# apt install chrony
  • Отредактируйте /etc/chrony/chrony.conf добавьте в него:
server NTP_SERVER iburst

Замените NTP_SERVER на имя хоста или IP-адрес подходящего более точного NTP-сервера. Конфигурация поддерживает несколько ключей сервера.

  • Для подключения остальных узлов к chrony управляющего узла в файл /etc/chrony/chrony.conf необходимо добавить:
allow 10.0.0.0/24
  • Перезагрузите NTP сервис:
# service chrony restart
Остальные Ноды
  • Установка необходимых пакетов:
# apt install chrony
  • Отредактируйте /etc/chrone/chrony.conf добавьте в него:
server controller iburst
  • Закомментировать pool 2.debian.pool.ntp.org offline iburst
  • Перезагрузите NTP сервис:
# service chrony restart
Проверка работоспособности

Прежде, чем идти дальше необходимо проверить, все ли нормально работает, для этого необходимо провести обычную операцию провери:

  • Запустить команду на управляющем ноде:
# chronyc sources

  210 Number of sources = 2
  MS Name/IP address         Stratum Poll Reach LastRx Last sample
  ===============================================================================
  ^- 192.0.2.11                    2   7    12   137  -2814us[-3000us] +/-   43ms
  ^* 192.0.2.12                    2   6   177    46    +17us[  -23us] +/-   68ms

В столбце Name/IP address должен быть указано имя хоста, которое прописывали в начале, а также дополнительные сервера синхронизации. Содиржимое в столбце S должна быть * для серверва, на который в настоящее время синхронизируется служба NTP.

  • Запустить ту же операцию на всех других нодах:
# chronyc sources

  210 Number of sources = 1
  MS Name/IP address         Stratum Poll Reach LastRx Last sample
  ===============================================================================
  ^* controller                    3    9   377   421    +15us[  -87us] +/-   15ms

Содиржомое в столбце Name/IP address должен быть controller.

Пакеты OpenStack

Подключение OpenStack репозиториев
# apt install software-properties-common
# add-apt-repository cloud-archive:newton
  • Апгрейд пакетов на хосте:
# apt update && apt dist-upgrade
  • Установка OpenStack клиента:
# apt install python-openstackclient

SQL database

Большинство служб OpenStack используют базу данных SQL для хранения информации. Базы данных обычно используется (устанавливается) на управляющем узле. В этом рукаводстве используется MariaDB или MySQL в зависимости от дистрибутива. Службы OpenStack также поддерживают дургие базы данных SQL, включая PostgreSQL.

Установка и настройка компонентов
  • Установка компонентов:
# apt install mariadb-server python-pymysql
  • Создайте и отредактируйте /etc/mysql/mariadb.conf.d/99-openstack.cnf:
    • Создайте раздел [mysqld] и установиет ключ привязки-адреса на IP-адрес контроллера, чтобы разрешить доступ другим узлам через сеть. Установите допольнительные параметры, и набор символов UTF-8:
[mysqld]
bind-address = 10.0.0.11

default-storage-engine = innodb
innodb_file_per_table
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8

Конец установки:

  • Перезапустите службу базы данных:
# service mysql restart
  • Для обеспечения безопасности базы данных запустите встроенный скрипт mysql_secure_installation. Обычно для этого используют тот же пароль, что и для root.
# mysql_secure_installation

Служба сообщений

OpenStack использует очередь сообщений для координации операций и информации о статусе между службами. Служба очереди сообщений обычно выполняется на узле контроллера. OpenStack поддерживает несколько служб очереди сообщений, включая RabbitMQ, Qpid и ZeroMQ. Однако в большинстве дистрибутивов, пакет OpenStack поддерживает конкретную службу очереди сообщений. Это руководство реализует службу очереди сообщений RabbitMQ, потому что большинство дистрибутивов поддерживают ее.

Очередь сообщений выполняется на узле контроллера.

Установка и настройка компонентов
  • Установка компонентов:
# apt install rabbitmq-server
  • Добавим openstack пользователя:
# rabbitmqctl add_user openstack RABBIT_PASS

Creating user "openstack" ...

Заменить RABBIT_PASS на свой пароль.

  • Назначить для пользователя openstack полный доступ на запись и чтение:
# rabbitmqctl set_permissions openstack ".*" ".*" ".*"

Setting permissions for user "openstack" in vhost "/" ...

Служба Memcached

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

Установка и настройка компонентов
  • Установка компонентов:
# apt install memcached python-memcache
  • Отредактируйте /etc/memcached.conf и настройте службу для использования IP-адреса управления узла контроллера. Это означает, что доступ через другие узлы осуществляется через сеть управления:
-l 10.0.0.11

Конец установки: Перезапусите службу:

# service memcached restart

Обзор службы доступа (OpenStack Identity)

Служба OpenStack Identity обеспечивает единую точку интеграции для управления аутентификацией, авторизацией и каталогом сервисов.

Служба Identity обычно является первой службой, с которой пользователь взаимодействует. После аутентификации конечный пользователь может использовать свою личность для доступа к другим службам OpenStack. Аналогично, другие службы OpenStack используют службу Identity для обеспечения того, чтобы сохранялась политика безопасности. Служба Identity также может интегрироваться с некоторыми внешними системами управления пользователями (такими как LDAP). Пользователи и службы могут находить другие службы, используя каталог услуг, которым управляет служба Identity. Как следует из названия, каталог сервисов представляет собой набор доступных сервисов в развертывании OpenStack. Каждая служба может иметь один или несколько конечных точек, и каждая конечная точка может быть одного из трех типов: admin, internal или public. В производственной среде разные типы конечных точек могут находиться в отдельных сетях, подверженных различным типам пользователей по соображениям безопасности. Например, общедоступная сеть API может быть видна из Интернета, чтобы клиенты могли управлять облаками. Сеть API-администратора может быть ограничена операторами внутри организации, которая управляет облачной инфраструктурой. Внутренняя сеть API может быть ограничена хостами, которые содержат службы OpenStack. Кроме того, OpenStack поддерживает несколько областей для масштабируемости. Для простоты в этом руководстве используется сеть управления для всех типов конечных точек и региона RegionOne по умолчанию. Вместе регионы, службы и endpoints, созданные в службе идентификации, включают в себя каталог услуг для развертывания. Каждой службе OpenStack в развертывании нужна служебная запись с соответствующими endpoints, хранящимися в службе Identity. Все это можно сделать после установки и настройки службы Identity. Служба содержит такие компоненты как:

  • Сервер - Централизованный сервер предоставляет службы аутентификации и авторизации с использованием интерфейса RESTful.
  • Драйвера - Драйверы или back-end службы интегрированы в централизованный сервер. Они используются для доступа к идентификационной информации в репозиториях, внешних по отношению к OpenStack, и могут уже существовать в инфраструктуре, где развертывается OpenStack (например, базы данных SQL или LDAP-серверы).
  • Модули - Модули промежуточного программного обеспечения запускаются в адресном пространстве компонента OpenStack, который использует службу Identity. Эти модули перехватывают запросы служб, извлекают учетные данные пользователя и отправляют их на централизованный сервер для авторизации. Интеграция между промежуточными модулями и компонентами OpenStack использует интерфейс шлюза веб-сервера Python.
Установка и настройка

В этом разделе описывается, как установить и настроить службу OpenStack Identity с кодовым именем keystone на узле контроллера. Для целей масштабирования эта конфигурация развертывает токены Fernet и HTTP-сервер Apache для обработки запросов.

Предустановка

Прежде чем настраивать службу OpenStack Identity, вы должны создать базу данных и токен администрирования.

  • Создадим базу данных:
    • Воспользуйтесь доступом к базе данных, как пользователь root:
$ mysql -u root -p
    • Создайте базу данных keystone:
mysql> CREATE DATABASE keystone;
    • Предоставьте надлежащий доступ к базе данных keystone:
mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
  IDENTIFIED BY 'KEYSTONE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
  IDENTIFIED BY 'KEYSTONE_DBPASS';

Заменив KEYSTONE_DBPASS на свой пароль.

  • Выйти из системы.
Установка и настройка компонентов
  • Запустить и следовать коммандам устанавливающихся компонентов:
# apt install keystone
  • Отредактируйте /etc/keystone/keystone.conf в соответствии с представленном ниже образом:
    • В [database] секции, настроить доступ к базе данных:
[database]
...
connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone

Заменить KEYSTONE_DBPASS на соответствующий пароль базы данных.

    • В [token] секции, установить fernet:
[token]
...
provider = fernet
  • Заполните базу данных службы удостоверений:
# su -s /bin/sh -c "keystone-manage db_sync" keystone
  • Объявите ключ Fernet репозитория:
# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
# keystone-manage credential_setup --keystone-user keystone --keystone-group keystone
  • Загрузите сервис Identity:
# keystone-manage bootstrap --bootstrap-password ADMIN_PASS \
  --bootstrap-admin-url http://controller:35357/v3/ \
  --bootstrap-internal-url http://controller:35357/v3/ \
  --bootstrap-public-url http://controller:5000/v3/ \
  --bootstrap-region-id RegionOne

Замените ADMIN_PASS с соответствующим паролем администратора.

Настройка Apache HTTP сервера
  • Отредактируйте /etc/apache2/apache2.conf и сконфигуруйте ServerName:
ServerName controller

Завершение установки:

  • Перезагрузите Apache сервис и удалите стандартный SQLite:
# service apache2 restart
# rm -f /var/lib/keystone/keystone.db
  • Настройка учетной записи администратора:
$ export  OS_USERNAME=admin
$ export  OS_PASSWORD=ADMIN_PASS
$ export  OS_PROJECT_NAME=admin
$ export  OS_USER_DOMAIN_NAME=Default
$ export  OS_PROJECT_DOMAIN_NAME=Default
$ export  OS_AUTH_URL=http://controller:35357/v3
$ export  OS_IDENTITY_API_VERSION=3

Заменить ADMIN_PASS endpoints на соответствующий пароль, используемый в keystone-manage bootstrap endpoints.

Создание доменов, проектов, пользователей и ролей

Служба Identity предоставляет услуги аутентификации для каждой службы OpenStack. Служба аутентификации использует комбинацию доменов, проектов, пользователей и ролей.

  • В этом руководстве используется сервис-проект, содержащий уникальный пользователь для каждой службы, добавляемой в вашу среду. Создайте проект службы:
$ openstack project create --domain default \
  --description "Service Project" service

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Service Project                  |
| domain_id   | default                          |
| enabled     | True                             |
| id          | 24ac7f19cd944f4cba1d77469b2a73ed |
| is_domain   | False                            |
| name        | service                          |
| parent_id   | default                          |
+-------------+----------------------------------+
  • Регулярные (неадминистративные) задачи должны использовать непривилегированный проект и пользователя. В качестве примера это руководство создает demo проект и пользователя.
  • Создание demo проекта:
$ openstack project create --domain default \
  --description "Demo Project" demo

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Demo Project                     |
| domain_id   | default                          |
| enabled     | True                             |
| id          | 231ad6e7ebba47d6a1e57e1cc07ae446 |
| is_domain   | False                            |
| name        | demo                             |
| parent_id   | default                          |
+-------------+----------------------------------+
    • Создание demo пользователя:
$ openstack user create --domain default \
  --password-prompt demo

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | aeda23aa78f44e859900e22c24817832 |
| name                | demo                             |
| password_expires_at | None                             |
+---------------------+----------------------------------+
    • Добавим роль пользователя в demo проект:
$ openstack user create --domain default \
  --password-prompt demo

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | aeda23aa78f44e859900e22c24817832 |
| name                | demo                             |
| password_expires_at | None                             |
+---------------------+----------------------------------+
Создание доменов, проектов, пользователей и ролей

Проверьте работу службы идентификации перед установкой других служб.

  • Из соображений безопасности отключите механизм токена аутентификации: отредактируйте /etc/keystone/keystone-paste.ini и уберите admin_token_auth из [pipeline:public_api], [pipeline:admin_api] и [pipeline:api_v3] секций.
  • Отмените временную переменную среды OS_AUTH_URL и OS_PASSWORD:
$ unset OS_AUTH_URL OS_PASSWORD
  • Как пользователь admin, запросите токен аутентификации:
$ openstack --os-auth-url http://controller:35357/v3 \
  --os-project-domain-name Default --os-user-domain-name Default \
  --os-project-name admin --os-username admin token issue

Password:
+------------+-----------------------------------------------------------------+
| Field      | Value                                                           |
+------------+-----------------------------------------------------------------+
| expires    | 2016-02-12T20:14:07.056119Z                                     |
| id         | gAAAAABWvi7_B8kKQD9wdXac8MoZiQldmjEO643d-e_j-XXq9AmIegIbA7UHGPv |
|            | atnN21qtOMjCFWX7BReJEQnVOAj3nclRQgAYRsfSU_MrsuWb4EDtnjU7HEpoBb4 |
|            | o6ozsA_NmFWEpLeKy0uNn_WeKbAhYygrsmQGA49dclHVnz-OMVLiyM9ws       |
| project_id | 343d245e850143a096806dfaefa9afdc                                |
| user_id    | ac3377633149401296f6c0d92d79dc16                                |
+------------+-----------------------------------------------------------------+
  • Как demo пользователь, попросите токен аутентификации:
$ openstack --os-auth-url http://controller:5000/v3 \
  --os-project-domain-name Default --os-user-domain-name Default \
  --os-project-name demo --os-username demo token issue

Password:
+------------+-----------------------------------------------------------------+
| Field      | Value                                                           |
+------------+-----------------------------------------------------------------+
| expires    | 2016-02-12T20:15:39.014479Z                                     |
| id         | gAAAAABWvi9bsh7vkiby5BpCCnc-JkbGhm9wH3fabS_cY7uabOubesi-Me6IGWW |
|            | yQqNegDDZ5jw7grI26vvgy1J5nCVwZ_zFRqPiz_qhbq29mgbQLglbkq6FQvzBRQ |
|            | JcOzq3uwhzNxszJWmzGC7rJE_H0A_a3UFhqv8M4zMRYSbS2YF0MyFmp_U       |
| project_id | ed0b60bf607743088218b0a533d5943f                                |
| user_id    | 58126687cbcc4888bfa9ab73a2256f27                                |
+------------+-----------------------------------------------------------------+

Создание сценариев клиентской среды OpenStack

В предыдущем разделе использовалась комбинация переменных среды и параметров команд для взаимодействия с службой Identity через клиент openstack. Чтобы повысить эффективность клиентских операций, OpenStack поддерживает простые сценарии клиентской среды, также известные как файлы OpenRC. Эти сценарии обычно содержат общие параметры для всех клиентов, но также поддерживают уникальные параметры.

Создание скрипта

Создадим сценарий для admin и demo проекты и пользователей.

  • Отредактируйте admin-openrc файл и добавьте соответствующий контекст:
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

Замените ADMIN_PASS на соотвествующий пароль admin, который был задан на этапе Identity.

  • Отредактируйте demo-openrc файл и добавьте соответствующий контекст:
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=demo
export OS_USERNAME=demo
export OS_PASSWORD=DEMO_PASS
export OS_AUTH_URL=http://controller:5000/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

Замените DEMO_PASS на пароль соответствующий паролю demo, заданному на этапе Identity.

Использование скриптов

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

  • Загрузите файл admin-openrc, для запуска скрипта:
$ . admin-openrc
  • Запросить токен аутентификации:
$ openstack token issue

+------------+-----------------------------------------------------------------+
| Field      | Value                                                           |
+------------+-----------------------------------------------------------------+
| expires    | 2016-02-12T20:44:35.659723Z                                     |
| id         | gAAAAABWvjYj-Zjfg8WXFaQnUd1DMYTBVrKw4h3fIagi5NoEmh21U72SrRv2trl |
|            | JWFYhLi2_uPR31Igf6A8mH2Rw9kv_bxNo1jbLNPLGzW_u5FC7InFqx0yYtTwa1e |
|            | eq2b0f6-18KZyQhs7F3teAta143kJEWuNEYET-y7u29y0be1_64KYkM7E       |
| project_id | 343d245e850143a096806dfaefa9afdc                                |
| user_id    | ac3377633149401296f6c0d92d79dc16                                |
+------------+-----------------------------------------------------------------+

Установка сервиса образов

Служба Image (glance) позволяет пользователям искать, регистрировать и извлекать образы виртуальной машины. Он предлагает REST API, который позволяет запрашивать метаданные образа виртуальной машины и получать фактический образ. Вы можете хранить образы виртуальной машины, доступные через службу образов в различных местах, от простых файловых систем до систем хранения объектов, таких как OpenStack Object Storage. Служба OpenStack Image занимает центральное место в инфраструктуре как услуга (IaaS), как показано в концептуальной архитектуре. Он принимает запросы API для образов дисков или серверов, а также определения метаданных от конечных пользователей или компонентов OpenStack Compute. Он также поддерживает хранение образов дисков или серверов на разных типах репозиториев, включая хранилище объектов OpenStack. Для поддержки кэширования в службе OpenStack Image выполняется ряд периодических процессов. Услуги репликации обеспечивают согласованность и доступность через кластер. Другие периодические процессы включают аудиторов, обновителей и жнецов. Служба OpenStack Image включает следующие компоненты:

  • glance-api - Принимает образы API изображений для обнаружения, извлечения и хранения образов.
  • glance-registry - Сохраняет, обрабатывает и извлекает метаданные образов. Метаданные включают такие элементы, как размер и тип.
  • База данных - Сохраняет метаданные образов, и вы можете выбрать свою базу данных в зависимости от ваших предпочтений. Большинство развертываний используют MySQL или SQLite.
  • Репозиторий для файлов образов - Поддерживаются различные типы репозиториев, включая обычные файловые системы (или любую файловую систему, установленную на узле контроллера gl-api), хранилище объектов, блокирующие устройства RADOS, хранилище данных VMware и HTTP. Обратите внимание, что некоторые репозитории будут поддерживать только чтение.
  • Служба определения метаданных - Общий API для поставщиков, администраторов, служб и пользователей для определения собственных метаданных. Эти метаданные могут использоваться для различных типов ресурсов, таких как образы, артефакты, тома, вкусы и агрегаты. Определение включает в себя ключ, описание, ограничения и свойства ресурса нового свойства, с которыми он может быть связан.

Установка и настройка

В этом разделе описывается, как установить и настроить службу образов, под кодовым именем glance, на узле контроллера. Для простоты эта конфигурация хранит образы в локальной файловой системе.

Предустановка

Перед установкой и настройкой службы Image необходимо создать базу данных, учетные данные службы и endpoints API.

  • Чтобы создать базу данных, выполните следующие действия:
    • Используйте клиент доступа к базе данных для подключения к серверу базы данных в качестве пользователя root:
$ mysql -u root -p
    • Создайте базу данных glance:
mysql> CREATE DATABASE glance;
    • Предоставьте надлежащий доступ к базе данных glance:
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \
  IDENTIFIED BY 'GLANCE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' \
  IDENTIFIED BY 'GLANCE_DBPASS';

Замените GLANCE_DBPASS подходящим паролем.

    • Выйдите из клиента доступа к базе данных.
  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Чтобы создать учетные данные службы, выполните следующие действия:
    • Создайте пользователя glance:
$ openstack user create --domain default --password-prompt glance

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 3f4e777c4062483ab8d9edd7dff829df |
| name                | glance                           |
| password_expires_at | None                             |
+---------------------+----------------------------------+
    • Добавьте роль admin пользователю glance и service проекту:
$ openstack role add --project service --user glance admin
    • Создайте объект службы glance:
$ openstack service create --name glance \
  --description "OpenStack Image" image

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Image                  |
| enabled     | True                             |
| id          | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| name        | glance                           |
| type        | image                            |
+-------------+----------------------------------+
  • Создайте конечные точки API сервиса Image Image:
$ openstack endpoint create --region RegionOne \
  image public http://controller:9292

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 340be3625e9b4239a6415d034e98aace |
| interface    | public                           |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance                           |
| service_type | image                            |
| url          | http://controller:9292           |
+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \
  image internal http://controller:9292

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | a6e4b153c2ae4c919eccfdbb7dceb5d2 |
| interface    | internal                         |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance                           |
| service_type | image                            |
| url          | http://controller:9292           |
+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \
  image admin http://controller:9292

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 0c37ed58103f4300a84ff125a539032d |
| interface    | admin                            |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | 8c2c7f1b9b5049ea9e63757b5533e6d2 |
| service_name | glance                           |
| service_type | image                            |
| url          | http://controller:9292           |
+--------------+----------------------------------+
Установка и настройка компонентов
  • Установите компоненты:
# apt install glance
  1. Отредактируйте файл /etc/glance/glance-api.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://glance:GLANCE_DBPASS@controller/glance

Замените GLANCE_DBPASS на пароль, который вы выбрали для базы данных службы образов.

    • В разделах [keystone_authtoken] и [paste_deploy] настройте доступ к службе удостоверения:
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = glance
password = GLANCE_PASS

[paste_deploy]
...
flavor = keystone

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

    • В разделе [glance_store] настройте локальное хранилище файловой системы и местоположение файлов изображений:
[glance_store]
...
stores = file,http
default_store = file
filesystem_store_datadir = /var/lib/glance/images/
  • Отредактируйте файл /etc/glance/glance-registry.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://glance:GLANCE_DBPASS@controller/glance

Замените GLANCE_DBPASS на пароль, который вы выбрали для базы данных службы Image.

    • В разделах [keystone_authtoken] и [paste_deploy] настройте доступ к службе удостоверения:
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = glance
password = GLANCE_PASS

[paste_deploy]
...
flavor = keystone

Замените GLANCE_DBPASS на пароль, который вы выбрали для базы данных службы Image.

  • Заполните базу данных службы Image:
# su -s /bin/sh -c "glance-manage db_sync" glance

Завершение установки

  • Перезапустите службу:
# service glance-registry restart
# service glance-api restart

Проверка работоспособности

  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Загрузите исходный образ:
$ wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
  • Загрузите образ в сервис Image, используя формат диска QCOW2, формат голого контейнера и общедоступную видимость, чтобы все проекты могли получить к нему доступ:
$ openstack image create "cirros" \
  --file cirros-0.3.4-x86_64-disk.img \
  --disk-format qcow2 --container-format bare \
  --public

+------------------+------------------------------------------------------+
| Field            | Value                                                |
+------------------+------------------------------------------------------+
| checksum         | 133eae9fb1c98f45894a4e60d8736619                     |
| container_format | bare                                                 |
| created_at       | 2015-03-26T16:52:10Z                                 |
| disk_format      | qcow2                                                |
| file             | /v2/images/cc5c6982-4910-471e-b864-1098015901b5/file |
| id               | cc5c6982-4910-471e-b864-1098015901b5                 |
| min_disk         | 0                                                    |
| min_ram          | 0                                                    |
| name             | cirros                                               |
| owner            | ae7a98326b9c455588edd2656d723b9d                     |
| protected        | False                                                |
| schema           | /v2/schemas/image                                    |
| size             | 13200896                                             |
| status           | active                                               |
| tags             |                                                      |
| updated_at       | 2015-03-26T16:52:10Z                                 |
| virtual_size     | None                                                 |
| visibility       | public                                               |
+------------------+------------------------------------------------------+
  • Подтвердите загрузку образа и подтвердите атрибуты:
$ openstack image list

+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 38047887-61a7-41ea-9b49-27987d5e8bb9 | cirros | active |
+--------------------------------------+--------+--------+

Установка вычислительного узла(Compute service)

Используйте OpenStack Compute для управления облачными вычислительными системами. OpenStack Compute является важной частью системы Infrastructure-as-a-Service (IaaS). Основные модули реализованы в Python.

OpenStack Compute взаимодействует с OpenStack Identity для аутентификации; Служба OpenStack Image для образов дисков и серверов; и панель инструментов OpenStack для пользовательского и административного интерфейса. Доступ к образам ограничен проектами и пользователями; квоты ограничены для каждого проекта (например, количество экземпляров). OpenStack Compute может масштабироваться горизонтально на стандартном оборудовании и загружать образы для запуска экземпляров. OpenStack Compute состоит из следующих областей и их компонентов:

  • nova-api service - Принимает и отвечает на вызовы API для конечных пользователей. Служба поддерживает API OpenStack Compute, API Amazon EC2 и специальный API-интерфейс администратора для привилегированных пользователей для выполнения административных действий. Он применяет некоторые политики и инициирует большинство операций оркестровки, таких как запуск экземпляра.
  • nova-api-metadata service - Принимает запросы метаданных из экземпляров. Служба nova-api-metadata обычно используется, когда вы запускаете многопользовательский режим с установками nova-network.
  • nova-compute service - Рабочий демон, который создает и завершает экземпляры виртуальной машины через API гипервизора. Например:
    • XenAPI for XenServer/XCP
    • libvirt for KVM or QEMU
    • VMwareAPI for VMware

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

  • nova-scheduler service - Принимает запрос экземпляра виртуальной машины из очереди и определяет, на каком хосте компьютера-компилятора он выполняется.
  • nova-conductor module - Способствует взаимодействию между сервисом nova-compute и базой данных. Это устраняет прямой доступ к базе данных облака, созданной службой nova-compute. Модуль nova-conductor масштабируется горизонтально. Однако не развертывайте его на узлах, где запущена служба nova-compute.
  • nova-cert module - Демон сервера, обслуживающий службу Nova Cert для сертификатов X509. Используется для создания сертификатов для euca-bundle-image. Только для API EC2.
  • nova-network worker daemon - Подобно сервису nova-compute, принимает сетевые задачи из очереди и манипулирует сетью. Выполняет такие задачи, как настройка интерфейсов моста или изменение правил IPtables.
  • nova-consoleauth daemon - Авторизует токены для пользователей, которые предоставляют консольные прокси. Эта служба должна запускаться для работы консольных прокси. Вы можете запускать прокси любого типа против одной службы nova-consoleauth в конфигурации кластера.
  • nova-novncproxy daemon - Предоставляет прокси для доступа к запущенным экземплярам через соединение VNC. Поддерживает браузеры newnc.
  • nova-spicehtml5proxy daemon - Предоставляет прокси для доступа к запущенным экземплярам через соединение SPICE. Поддерживает браузер HTML5 с поддержкой браузера.
  • nova-xvpvncproxy daemon - Предоставляет прокси для доступа к запущенным экземплярам через соединение VNC. Поддержка Java-клиента, специфичного для OpenStack.
  • nova-cert daemon - x509 сертификатов.
  • nova client - Позволяет пользователям отправлять команды в качестве администратора, арендатора или конечного пользователя.
  • Очередь - Центральный концентратор для передачи сообщений между демонами. Обычно реализуемый с помощью RabbitMQ также может быть реализован с другой очередью сообщений AMQP, например ZeroMQ.
  • SQL database - Сохраняет большинство состояний времени сборки и времени выполнения для облачной инфраструктуры, в том числе:
    • Доступные типы экземпляров
    • Используемые экземпляры
    • Доступные сети
    • Проекты

Теоретически OpenStack Compute может поддерживать любую базу данных, поддерживаемую SQL-Alchemy. Общие базы данных SQLite3 для тестирования и разработки, MySQL, MariaDB и PostgreSQL.

Установка и найтрока управляющего узла

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

Предустановка

Перед установкой и настройкой службы Compute необходимо создать базы данных, учетные данные служб и endpoints API.

  • Чтобы создать базы данных, выполните следующие действия:
    • Используйте клиент доступа к базе данных для подключения к серверу базы данных в качестве пользователя root:
$ mysql -u root -p
    • Создайте базы данных nova_api и nova:
mysql> CREATE DATABASE nova_api;
mysql> CREATE DATABASE nova;
    • Предоставить надлежащий доступ к базам данных:
mysql> GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost' \
  IDENTIFIED BY 'NOVA_DBPASS';
mysql> GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' \
  IDENTIFIED BY 'NOVA_DBPASS';
mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' \
  IDENTIFIED BY 'NOVA_DBPASS';
mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' \
  IDENTIFIED BY 'NOVA_DBPASS';

Замените NOVA_DBPASS на подходящий пароль.

    • Выйдите из клиента доступа к базе данных.
  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Чтобы создать учетные данные службы, выполните следующие действия:
    • Создайте пользователя nova:
$ openstack user create --domain default \
  --password-prompt nova

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 8a7dbf5279404537b1c7b86c033620fe |
| name                | nova                             |
| password_expires_at | None                             |
+---------------------+----------------------------------+
  • Добавьте роль admin в пользователя nova:
$ openstack role add --project service --user nova admin
  • Создайте объект службы nova:
$ openstack service create --name nova \
  --description "OpenStack Compute" compute

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Compute                |
| enabled     | True                             |
| id          | 060d59eac51b4594815603d75a00aba2 |
| name        | nova                             |
| type        | compute                          |
+-------------+----------------------------------+
  • Создайте endpoints API службы Compute:
$ openstack endpoint create --region RegionOne \
  compute public http://controller:8774/v2.1/%\(tenant_id\)s

+--------------+-------------------------------------------+
| Field        | Value                                     |
+--------------+-------------------------------------------+
| enabled      | True                                      |
| id           | 3c1caa473bfe4390a11e7177894bcc7b          |
| interface    | public                                    |
| region       | RegionOne                                 |
| region_id    | RegionOne                                 |
| service_id   | 060d59eac51b4594815603d75a00aba2          |
| service_name | nova                                      |
| service_type | compute                                   |
| url          | http://controller:8774/v2.1/%(tenant_id)s |
+--------------+-------------------------------------------+

$ openstack endpoint create --region RegionOne \
  compute internal http://controller:8774/v2.1/%\(tenant_id\)s

+--------------+-------------------------------------------+
| Field        | Value                                     |
+--------------+-------------------------------------------+
| enabled      | True                                      |
| id           | e3c918de680746a586eac1f2d9bc10ab          |
| interface    | internal                                  |
| region       | RegionOne                                 |
| region_id    | RegionOne                                 |
| service_id   | 060d59eac51b4594815603d75a00aba2          |
| service_name | nova                                      |
| service_type | compute                                   |
| url          | http://controller:8774/v2.1/%(tenant_id)s |
+--------------+-------------------------------------------+

$ openstack endpoint create --region RegionOne \
  compute admin http://controller:8774/v2.1/%\(tenant_id\)s

+--------------+-------------------------------------------+
| Field        | Value                                     |
+--------------+-------------------------------------------+
| enabled      | True                                      |
| id           | 38f7af91666a47cfb97b4dc790b94424          |
| interface    | admin                                     |
| region       | RegionOne                                 |
| region_id    | RegionOne                                 |
| service_id   | 060d59eac51b4594815603d75a00aba2          |
| service_name | nova                                      |
| service_type | compute                                   |
| url          | http://controller:8774/v2.1/%(tenant_id)s |
+--------------+-------------------------------------------+
Установка и настройка компонентов
  • Установка компонентов:
# apt install nova-api nova-conductor nova-consoleauth \
  nova-novncproxy nova-scheduler
  • Отредактируйте файл /etc/nova/nova.conf и выполните следующие действия:
    • В разделах [api_database] и [database] настройте доступ к базе данных:
[api_database]
...
connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova_api

[database]
...
connection = mysql+pymysql://nova:NOVA_DBPASS@controller/nova

Замените NOVA_DBPASS на пароль, который вы выбрали для баз данных Compute.

    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

  • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе удостоверения:
[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = nova
password = NOVA_PASS

Замените NOVA_PASS на пароль, который вы выбрали для пользователя nova в службе удостоверения.

  • В разделе [DEFAULT] настройте параметр my_ip для использования IP-адреса интерфейса управления узла контроллера:
[DEFAULT]
...
my_ip = 10.0.0.11
  • В разделе [DEFAULT] включите поддержку службы Networking:
[DEFAULT]
...
use_neutron = True
firewall_driver = nova.virt.firewall.NoopFirewallDriver
  • В разделе [vnc] настройте прокси-сервер VNC для использования IP-адреса интерфейса управления узла контроллера:
[vnc]
...
vncserver_listen = $my_ip
vncserver_proxyclient_address = $my_ip
  • В разделе [glance] настройте расположение API-интерфейса Image:
[glance]
...
api_servers = http://controller:9292
  • В разделе [oslo_concurrency] настройте путь блокировки:
[oslo_concurrency]
...
lock_path = /var/lib/nova/tmp
  • Из-за ошибки в упаковке удалите параметр log-dir из раздела [DEFAULT].
  • Заполните базы данных Compute:
# su -s /bin/sh -c "nova-manage api_db sync" nova
# su -s /bin/sh -c "nova-manage db sync" nova

Конец установки:

  • Перезапустите службы вычислений:
# service nova-api restart
# service nova-consoleauth restart
# service nova-scheduler restart
# service nova-conductor restart
# service nova-novncproxy restart

Установка и найтрока вычислительного узла

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

Установка и настройка компонетов
  • Установка компонентов:
# apt install nova-compute
  • Отредактируйте файл /etc/nova/nova.conf и выполните следующие действия:
    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

    • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе удостоверения:
[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = nova
password = NOVA_PASS

Замените NOVA_PASS на пароль, который вы выбрали для пользователя nova в службе Identity.

  • В разделе [DEFAULT] настройте параметр my_ip:
[DEFAULT]
...
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
Замените MANAGEMENT_INTERFACE_IP_ADDRESS на IP-адрес интерфейса сети управления на вашем вычислительном узле, как правило, 10.0.0.31 для первого узла в примерной архитектуре.
  • В разделе [DEFAULT] включите поддержку службы Networking:
[DEFAULT]
...
use_neutron = True
firewall_driver = nova.virt.firewall.NoopFirewallDriver
  • В разделе [vnc] включите и настройте удаленный доступ к консоли:
[vnc]
...
enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = $my_ip
novncproxy_base_url = http://controller:6080/vnc_auto.html

Серверный компонент прослушивает все IP-адреса, а прокси-компонент только прослушивает IP-адрес интерфейса управления вычислительного узла. Основной URL-адрес указывает местоположение, в котором вы можете использовать веб-браузер для доступа к удаленным консолям экземпляров на этом вычислительном узле.

  • В разделе [glance] настройте расположение API-интерфейса Image:
[glance]
...
api_servers = http://controller:9292
  • В разделе [oslo_concurrency] настройте путь блокировки:
[oslo_concurrency]
...
lock_path = /var/lib/nova/tmp
  • Из-за ошибки в упаковке удалите параметр log-dir из раздела [DEFAULT].

Конец установки:

  • Определите, поддерживает ли ваш вычислительный узел аппаратное ускорение для виртуальных машин:
$ egrep -c '(vmx|svm)' /proc/cpuinfo

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

Если эта команда возвращает значение нуля, ваш вычислительный узел не поддерживает аппаратное ускорение, и вы должны настроить libvirt для использования QEMU вместо KVM.

  • Отредактируйте раздел [libvirt] в файле /etc/nova/nova-compute.conf следующим образом:
[libvirt]
...
virt_type = qemu
  • Перезапустить службу Compute:
# service nova-compute restart

Проверка работоспособности

  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Список компонентов сервиса для проверки успешного запуска и регистрации каждого процесса:
$ openstack compute service list

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary             | Host       | Zone     | Status  | State | Updated At                 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
|  1 | nova-consoleauth   | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  2 | nova-scheduler     | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  3 | nova-conductor     | controller | internal | enabled | up    | 2016-02-09T23:11:16.000000 |
|  4 | nova-compute       | compute1   | nova     | enabled | up    | 2016-02-09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+

Сервис сетевого обслуживания(Networking service)

В этой главе объясняется, как установить и настроить службу сети (neutron) с помощью сети провайдеров или сети самообслуживания. OpenStack Networking (neutron) позволяет создавать и прикреплять интерфейсные устройства, управляемые другими службами OpenStack, к сетям. Плагины могут быть реализованы для размещения различного сетевого оборудования и программного обеспечения, обеспечивая гибкость архитектуры и развертывания OpenStack. Он включает следующие компоненты:

  • neutron-server - Принимает и направляет запросы API к соответствующему подключаемому модулю OpenStack Networking для действий.
  • OpenStack Networking plug-ins and agents - Подключение и отсоединение портов, создайте сети или подсети и укажите IP-адресацию. Эти плагины и агенты различаются в зависимости от поставщика и технологий, используемых в конкретном облаке. OpenStack Networking поставляется с плагинами и агентами для виртуальных и физических коммутаторов Cisco, продуктов NEC OpenFlow, Open vSwitch, моста Linux и продукта VMware NSX.

Общими агентами являются L3 (уровень 3), DHCP (динамическая IP-адреса хоста) и агент plug-in.

  • Очередь сообщений - Используется большинством установок OpenStack Networking для маршрутизации информации между neutron-server и различными агентами. Также выступает в качестве базы данных для хранения состояния сети для определенных подключаемых модулей.

OpenStack Networking в основном взаимодействует с OpenStack Compute для обеспечения сетей и подключения для своих экземпляров.

OpenStack Networking (neutron) управляет всеми сетевыми аспектами инфраструктуры виртуальной сети (VNI) и аспектами уровня доступа инфраструктуры физической сети (PNI) в среде OpenStack. OpenStack Networking позволяет проектам создавать передовые топологии виртуальной сети, которые могут включать такие сервисы, как брандмауэр, балансировщик нагрузки и виртуальная частная сеть (VPN). Сеть - сети, подсети и маршрутизаторы - как абстракции объектов. Каждая абстракция имеет функциональные возможности, имитирующие ее физический аналог: сети содержат подсети, а маршрутизаторы маршрутизируют трафик между различными подсетями и сетями. Любая заданная сетевая настройка имеет как минимум одну внешнюю сеть. В отличие от других сетей, внешняя сеть - это не просто фактически определенная сеть. Вместо этого она представляет собой образ на фрагмент физической, внешней сети, доступной вне установки OpenStack. IP-адреса во внешней сети могут быть физически доступны во внешней сети. В дополнение к внешним сетям любая сетевая сеть имеет одну или несколько внутренних сетей. Эти программно определенные сети напрямую подключаются к виртуальным машинам. Только виртуальные машины в любой заданной внутренней сети или на подсетях, подключенных через интерфейсы к аналогичному маршрутизатору, могут напрямую обращаться к виртуальным машинам, подключенным к этой сети. Для внешней сети для доступа к виртуальным машинам и наоборот, необходимы маршрутизаторы между сетями. Каждый маршрутизатор имеет один шлюз, который подключен к внешней сети и один или несколько интерфейсов, подключенных к внутренним сетям. Как и физический маршрутизатор, подсети могут обращаться к машинам в других подсетях, которые подключены к одному маршрутизатору, а машины могут обращаться к внешней сети через шлюз маршрутизатора. Кроме того, вы можете распределять IP-адреса во внешних сетях по портам во внутренней сети. Всякий раз, когда что-то подключается к подсети, это соединение называется портом. Вы можете связать внешние IP-адреса с портами с виртуальными машинами. Таким образом, объекты внешней сети могут обращаться к виртуальным машинам. Сеть также поддерживает группы безопасности. Группы безопасности позволяют администраторам определять правила брандмауэра в группах. VM может принадлежать одной или нескольким группам безопасности, а Networking применяет правила в этих группах безопасности для блокировки или разблокирования портов, диапазонов, портов или типов трафика для этой виртуальной машины. Каждый плагин, который использует Networking, имеет свои собственные концепции. Хотя это не так важно для работы в среде VNI и OpenStack, понимание этих концепций может помочь вам настроить Networking. Во всех сетевых установках используется основной плагин и плагин группы безопасности (или только плагин группы безопасности No-Op). Кроме того, доступны плагины Firewall-as-a-Service (FWaaS) и Load-Balancer-as-a-Service (LBaaS).

Установка и настройка управляющего узла

Предустановка

Перед настройкой службы OpenStack Networking (neutron) необходимо создать базу данных, учетные данные службы и endpoints API.

  • Чтобы создать базу данных, выполните следующие действия:
    • Используйте клиент доступа к базе данных для подключения к серверу базы данных в качестве пользователя root:
$ mysql -u root -p
    • Создайте базу данных neutron:
mysql> CREATE DATABASE neutron;
    • Предоставьте надлежащий доступ к базе данных neutron, заменив NEUTRON_DBPASS на подходящий пароль:
mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \
  IDENTIFIED BY 'NEUTRON_DBPASS';
mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' \
  IDENTIFIED BY 'NEUTRON_DBPASS';
    • Выйдите из клиента доступа базы данных.
  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Чтобы создать учетные данные службы, выполните следующие действия:
    • Создайте пользователя neutron:
$ openstack user create --domain default --password-prompt neutron

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 319f34694728440eb8ffcb27b6dd8b8a |
| name                | neutron                          |
| password_expires_at | None                             |
+---------------------+----------------------------------+
  • Добавьте роль admin к пользователю neutron:
$ openstack role add --project service --user neutron admin
  • Создайте объект обслуживания neutron:
$ openstack service create --name neutron \
  --description "OpenStack Networking" network

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Networking             |
| enabled     | True                             |
| id          | f71529314dab4a4d8eca427e701d209e |
| name        | neutron                          |
| type        | network                          |
+-------------+----------------------------------+
  • Создайте конечные точки API службы сети:
$ openstack endpoint create --region RegionOne \
  network public http://controller:9696

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 85d80a6d02fc4b7683f611d7fc1493a3 |
| interface    | public                           |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f71529314dab4a4d8eca427e701d209e |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://controller:9696           |
+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \
  network internal http://controller:9696

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 09753b537ac74422a68d2d791cf3714f |
| interface    | internal                         |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f71529314dab4a4d8eca427e701d209e |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://controller:9696           |
+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \
  network admin http://controller:9696

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 1ee14289c9374dffb5db92a5c112fc4e |
| interface    | admin                            |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f71529314dab4a4d8eca427e701d209e |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://controller:9696           |
+--------------+----------------------------------+
Настройка сетевых параметров

Вы можете развернуть службу сети, используя одну из двух архитектур, представленных опциями 1 и 2.

Вариант 1 развертывает простейшую возможную архитектуру, которая поддерживает привязку экземпляров к сетям провайдера (внешних). Нет самообслуживания (частные) сети, маршрутизаторы или плавающие IP-адреса. Только администратор или другой привилегированный пользователь может управлять сетями провайдеров.

Вариант 2 дополняет вариант 1 со службами уровня 3, которые поддерживают привязку экземпляров к сетям самообслуживания. Демонстрационный или другой непривилегированный пользователь может управлять сетями самообслуживания, включая маршрутизаторы, которые обеспечивают связь между сетями самообслуживания и провайдера. Кроме того, плавающие IP-адреса обеспечивают подключение к экземплярам с использованием сетей самообслуживания из внешних сетей, таких как Интернет. Сети самообслуживания обычно используют оверлейные сети. Наложение сетевых протоколов, таких как VXLAN, включает в себя дополнительные заголовки, которые увеличивают накладные расходы и уменьшают пространство, доступное для данных полезной нагрузки или пользователя. Без знания инфраструктуры виртуальной сети экземпляры пытаются отправить пакеты с использованием максимального блока передачи Ethernet по умолчанию (MTU) 1500 байт. Служба Networking автоматически предоставляет правильное значение MTU экземплярам через DHCP. Однако некоторые облачные изображения не используют DHCP или игнорируют параметр DHCP MTU и требуют конфигурации с использованием метаданных или сценария.

Настройка агента метаданных
  • Отредактируйте файл /etc/neutron/metadata_agent.ini и выполните следующие действия:
    • В разделе [DEFAULT] настройте хост метаданных и общий SECRET:
[DEFAULT]
...
nova_metadata_ip = controller
metadata_proxy_shared_secret = METADATA_SECRET

Замените METADATA_SECRET на подходящий SECRET для прокси-сервера метаданных.

Настройка службы Compute для использования службы Networking
  • Отредактируйте файл /etc/nova/nova.conf и выполните следующие действия:
    • В разделе [neutron] настройте параметры доступа, включите прокси-сервер метаданных и настройте SECRET:
[neutron]
...
url = http://controller:9696
auth_url = http://controller:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS
service_metadata_proxy = True
metadata_proxy_shared_secret = METADATA_SECRET

Замените NEUTRON_PASS на пароль, который вы выбрали для пользователя neutron в службе идентификации. Замените METADATA_SECRET на SECRET, который вы выбрали для прокси-сервера метаданных. Конец установки:

  • Заполните базу данных:
# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
  • Перезапустите службу Compute API:
# service nova-api restart
  • Перезапустите сетевые службы.

Для обеих сетевых опций:

# service neutron-server restart
# service neutron-linuxbridge-agent restart
# service neutron-dhcp-agent restart
# service neutron-metadata-agent restart

Для сетевой опции 2 также перезапустите службу уровня 3:

# service neutron-l3-agent restart

Вариант сети 1: сети провайдеров

Установите и настройте сетевые компоненты на узле контроллера.

Установка компонентов
# apt install neutron-server neutron-plugin-ml2 \
  neutron-linuxbridge-agent neutron-dhcp-agent \
  neutron-metadata-agent
Настройка компонентов сервера

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

  • Отредактируйте файл /etc/neutron/neutron.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://neutron:NEUTRON_DBPASS@controller/neutron

Замените NEUTRON_DBPASS на пароль, который вы выбрали для базы данных.

  • В разделе [DEFAULT] включите модуль Modular Layer 2 (ML2) и отключите дополнительные плагины:
[DEFAULT]
...
core_plugin = ml2
service_plugins =
  • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

  • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе удостоверения:
[DEFAULT]
...
auth_strategy = keystone 

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = neutron
password = NEUTRON_PASS

Замените NEUTRON_PASS на пароль, который вы выбрали для пользователя нейтрона в службе идентификации.

  • В разделах [DEFAULT] и [nova] настройте Networking для уведомления об изменениях топологии сети:
[DEFAULT]
...
notify_nova_on_port_status_changes = True
notify_nova_on_port_data_changes = True 

[nova]
...
auth_url = http://controller:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = nova
password = NOVA_PASS

Замените NOVA_PASS на пароль, который вы выбрали для пользователя nova в службе удостоверения.

Настройка Modular Layer 2 (ML2)

Плагин ML2 использует механизм моста Linux для создания виртуальной сетевой инфраструктуры уровня 2 (мост и коммутация) для экземпляров.

  • Отредактируйте файл /etc/neutron/plugins/ml2/ml2_conf.ini и выполните следующие действия:
    • В секции [ml2] включить flat и VLAN-сети:
[ml2]
...
type_drivers = flat,vlan
    • В разделе [ml2] отключите сети самообслуживания:
[ml2]
...
tenant_network_types =
    • В разделе [ml2] включите механизм моста Linux:
[ml2]
...
mechanism_drivers = linuxbridge
    • В разделе [ml2] включите драйвер расширения безопасности порта:
[ml2]
...
extension_drivers = port_security
    • В разделе [ml2_type_flat] настройте виртуальную сеть провайдера как flat сеть:
[ml2_type_flat]
...
flat_networks = provider
    • В разделе [securitygroup] включите ipset для повышения эффективности правил группы безопасности:
[securitygroup]
...
enable_ipset = True
Настройка агента моста Linux

Агент моста Linux создает инфраструктуру виртуальных сетей уровня 2 (мост и коммутацию) для экземпляров и обрабатывает группы безопасности.

  • Отредактируйте файл /etc/neutron/plugins/ml2/linuxbridge_agent.ini и выполните следующие действия:
    • В разделе [linux_bridge] сопоставьте виртуальную сеть провайдера с физическим сетевым интерфейсом провайдера:
[linux_bridge]
physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME

Замените PROVIDER_INTERFACE_NAME именем физического сетевого интерфейса.

    • В разделе [vxlan] отключите наложенные сети VXLAN:
[vxlan]
enable_vxlan = False
    • В разделе [securitygroup] включите группы безопасности и настройте драйвер брандмауэра iptables для Linux:
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
Настройка агента DHCP

Агент DHCP предоставляет услуги DHCP для виртуальных сетей.

  • Отредактируйте файл /etc/neutron/dhcp_agent.ini и выполните следующие действия:
    • В разделе [DEFAULT] настройте драйвер интерфейса моста Linux, драйвер DHCP Dnsmasq и включите изолированные метаданные, чтобы экземпляры в сетях провайдеров могли получать доступ к метаданным по сети:
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True

Вариант сети 2: Сети самообслуживания

Установите и настройте сетевые компоненты на узле контроллера.

Установка компонентов
# apt install neutron-server neutron-plugin-ml2 \
  neutron-linuxbridge-agent neutron-l3-agent neutron-dhcp-agent \
  neutron-metadata-agent
Настройка компонентов сервера
  • Отредактируйте файл /etc/neutron/neutron.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://neutron:NEUTRON_DBPASS@controller/neutron

Замените NEUTRON_DBPASS на пароль, который вы выбрали для базы данных.

    • В разделе [DEFAULT] включите плагин Modular Layer 2 (ML2), маршрутизатор и перекрывающиеся IP-адреса:
[DEFAULT]
...
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

    • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе Identity:
[DEFAULT]
...
auth_strategy = keystone 

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = neutron
password = NEUTRON_PASS

Замените NEUTRON_PASS на пароль, который вы выбрали для пользователя нейтрона в службе идентификации.

    • В разделах [DEFAULT] и [nova] настройте Networking для уведомления об изменениях топологии сети:
[DEFAULT]
...
notify_nova_on_port_status_changes = True
notify_nova_on_port_data_changes = True 

[nova]
...
auth_url = http://controller:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = nova
password = NOVA_PASS

Замените NOVA_PASS на пароль, который вы выбрали для пользователя nova в службе удостоверения.

Настройка Modular Layer 2 (ML2)

Плагин ML2 использует механизм моста Linux для создания виртуальной сетевой инфраструктуры уровня 2 (мост и коммутация) для экземпляров.

  • Отредактируйте файл /etc/neutron/plugins/ml2/ml2_conf.ini и выполните следующие действия:
    • В секции [ml2] включить flat, VLAN и VXLAN-сети:
[ml2]
...
type_drivers = flat,vlan,vxlan
    • В разделе [ml2] включите сети самообслуживания VXLAN:
[ml2]
...
tenant_network_types = vxlan
    • В разделе [ml2] включите механизмы объединения Linux и слоя-2:
[ml2]
...
mechanism_drivers = linuxbridge,l2population
    • В разделе [ml2] включите драйвер расширения безопасности порта:
[ml2]
...
extension_drivers = port_security
    • В разделе [ml2_type_flat] настройте виртуальную сеть провайдера как flat сеть:
[ml2_type_flat]
...
flat_networks = provider
    • В разделе [ml2_type_vxlan] настройте диапазон идентификаторов сети VXLAN для сетей самообслуживания:
[ml2_type_vxlan]
...
vni_ranges = 1:1000
    • В разделе [securitygroup] включите ipset для повышения эффективности правил группы безопасности:
[securitygroup]
...
enable_ipset = True
Настройка агента моста Linux

Агент моста Linux создает инфраструктуру виртуальных сетей уровня 2 (мост и коммутацию) для экземпляров и обрабатывает группы безопасности.

  • Отредактируйте файл /etc/neutron/plugins/ml2/linuxbridge_agent.ini и выполните следующие действия:
    • В разделе [linux_bridge] сопоставьте виртуальную сеть провайдера с физическим сетевым интерфейсом провайдера:
[linux_bridge]
physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME

Замените PROVIDER_INTERFACE_NAME именем физического сетевого интерфейсa.

    • В разделе [vxlan] включите оверлейные сети VXLAN, настройте IP-адрес физического сетевого интерфейса, который обрабатывает сети наложения, и включите layer-2 population:
[vxlan]
enable_vxlan = True
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
l2_population = True

Замените OVERLAY_INTERFACE_IP_ADDRESS на IP-адрес базового физического сетевого интерфейса, который обрабатывает оверлейные сети. В примерной архитектуре используется интерфейс управления туннельным трафиком для других узлов. Поэтому замените OVERLAY_INTERFACE_IP_ADDRESS на IP-адрес управления узла контроллера.

    • В разделе [securitygroup] включите группы безопасности и настройте драйвер брандмауэра iptables для Linux:
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
Настройка агента layer-3

Агент Layer-3 (L3) предоставляет услуги маршрутизации и NAT для виртуальных сетей самообслуживания.

  • Отредактируйте файл /etc/neutron/l3_agent.ini и выполните следующие действия:
    • В разделе [DEFAULT] настройте драйвер интерфейса моста Linux и внешний сетевой мост:
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
Настройка агента DHCP

Агент DHCP предоставляет услуги DHCP для виртуальных сетей.

  • Отредактируйте файл /etc/neutron/dhcp_agent.ini и выполните следующие действия:
    • В разделе [DEFAULT] настройте драйвер интерфейса моста Linux, драйвер DHCP Dnsmasq и включите изолированные метаданные, чтобы экземпляры в сетях провайдеров могли получать доступ к метаданным по сети:
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True

Установка и настройка вычислительного узла

Узел вычисления обрабатывает соединения и группы безопасности для экземпляров.

Установка компонентов
# apt install neutron-linuxbridge-agent
Настройка общих компонентов

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

  • Отредактируйте файл /etc/neutron/neutron.conf и выполните следующие действия:
    • В разделе [database] закомментируйте любые параметры подключения, поскольку узлы вычислений не имеют прямого доступа к базе данных.
    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

  • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе Identity:
[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = neutron
password = NEUTRON_PASS

Замените NEUTRON_PASS на пароль, который вы выбрали для пользователя neutron в службе Identity.

Конфигурация сетевых настроек

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

Настройка службы Compute для использования службы Networking
  • Отредактируйте файл /etc/nova/nova.conf и выполните следующие действия:
    • В разделе [neutron] настройте параметры доступа:
[neutron]
...
url = http://controller:9696
auth_url = http://controller:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS

Замените NEUTRON_PASS на пароль, который вы выбрали для пользователя neutron в службе Identity. Конец установки:

  • Перезапустить службу вычислений:
# service nova-compute restart
  • Перезапустите агент моста Linux:
# service neutron-linuxbridge-agent restart

Вариант сети 1: сети провайдеров

Настройте компоненты сети на вычислительном узле.

Настройка агента моста Linux

Агент моста Linux создает инфраструктуру виртуальных сетей уровня 2 (мост и коммутацию) для экземпляров и обрабатывает группы безопасности.

  • Отредактируйте файл /etc/neutron/plugins/ml2/linuxbridge_agent.ini и выполните следующие действия:
    • В разделе [linux_bridge] сопоставьте виртуальную сеть провайдера с физическим сетевым интерфейсом провайдера:
[linux_bridge]
physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME

Замените PROVIDER_INTERFACE_NAME именем физического сетевого интерфейса.

    • В разделе [vxlan] отключите наложенные сети VXLAN:
[vxlan]
enable_vxlan = False
    • В разделе [securitygroup] включите группы безопасности и настройте драйвер брандмауэра iptables для Linux:
[securitygroup]
...
enable_security_group = True

firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

Вариант сети 2: Сети самообслуживания

Настройте компоненты сети на вычислительном узле.

Настройка агента моста Linux

Агент моста Linux создает инфраструктуру виртуальных сетей уровня 2 (мост и коммутацию) для экземпляров и обрабатывает группы безопасности.

  • Отредактируйте файл /etc/neutron/plugins/ml2/linuxbridge_agent.ini и выполните следующие действия:
    • В разделе [linux_bridge] сопоставьте виртуальную сеть провайдера с физическим сетевым интерфейсом провайдера:
[linux_bridge]
physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME

Замените PROVIDER_INTERFACE_NAME именем физического сетевого интерфейса.

    • В разделе [vxlan] включите оверлейные сети VXLAN, настройте IP-адрес физического сетевого интерфейса, который обрабатывает сети наложения, и включите populate слоя-2:
[vxlan]
enable_vxlan = True
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
l2_population = True

Замените OVERLAY_INTERFACE_IP_ADDRESS на IP-адрес базового физического сетевого интерфейса, который обрабатывает оверлейные сети. В примерной архитектуре используется интерфейс управления туннельным трафиком для других узлов. Поэтому замените OVERLAY_INTERFACE_IP_ADDRESS на IP-адрес управления вычислительного узла.

    • В разделе [securitygroup] включите группы безопасности и настройте драйвер брандмауэра iptables для Linux:
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

Проверка работоспособности

  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Список загруженных расширений для проверки успешного запуска процесса neutron-server процесса:
$ neutron ext-list

+---------------------------+-----------------------------------------------+
| alias                     | name                                          |
+---------------------------+-----------------------------------------------+
| default-subnetpools       | Default Subnetpools                           |
| network-ip-availability   | Network IP Availability                       |
| network_availability_zone | Network Availability Zone                     |
| auto-allocated-topology   | Auto Allocated Topology Services              |
| ext-gw-mode               | Neutron L3 Configurable external gateway mode |
| binding                   | Port Binding                                  |
| agent                     | agent                                         |
| subnet_allocation         | Subnet Allocation                             |
| l3_agent_scheduler        | L3 Agent Scheduler                            |
| tag                       | Tag support                                   |
| external-net              | Neutron external network                      |
| net-mtu                   | Network MTU                                   |
| availability_zone         | Availability Zone                             |
| quotas                    | Quota management support                      |
| l3-ha                     | HA Router extension                           |
| flavors                   | Neutron Service Flavors                       |
| provider                  | Provider Network                              |
| multi-provider            | Multi Provider Network                        |
| address-scope             | Address scope                                 |
| extraroute                | Neutron Extra Route                           |
| timestamp_core            | Time Stamp Fields addition for core resources |
| router                    | Neutron L3 Router                             |
| extra_dhcp_opt            | Neutron Extra DHCP opts                       |
| dns-integration           | DNS Integration                               |
| security-group            | security-group                                |
| dhcp_agent_scheduler      | DHCP Agent Scheduler                          |
| router_availability_zone  | Router Availability Zone                      |
| rbac-policies             | RBAC Policies                                 |
| standard-attr-description | standard-attr-description                     |
| port-security             | Port Security                                 |
| allowed-address-pairs     | Allowed Address Pairs                         |
| dvr                       | Distributed Virtual Router                    |
+---------------------------+-----------------------------------------------+
Вариант сети 1: сети провайдеров
  • Список агентов для проверки успешного запуска neutron:
$ openstack network agent list

+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host       | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+
| 0400c2f6-4d3b-44bc-89fa-99093432f3bf | Metadata agent     | controller | None              | True  | UP    | neutron-metadata-agent    |
| 83cf853d-a2f2-450a-99d7-e9c6fc08f4c3 | DHCP agent         | controller | nova              | True  | UP    | neutron-dhcp-agent        |
| ec302e51-6101-43cf-9f19-88a78613cbee | Linux bridge agent | compute    | None              | True  | UP    | neutron-linuxbridge-agent |
| fcb9bc6e-22b1-43bc-9054-272dd517d025 | Linux bridge agent | controller | None              | True  | UP    | neutron-linuxbridge-agent |
+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+

На выходе должны указываться три агента на узле контроллера и один агент на каждом вычислительном узле.

Вариант сети 2: Сети самообслуживания
  • Список агентов для проверки успешного запуска neutron агентов:
$ openstack network agent list

+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host       | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+
| f49a4b81-afd6-4b3d-b923-66c8f0517099 | Metadata agent     | controller | None              | True  | UP    | neutron-metadata-agent    |
| 27eee952-a748-467b-bf71-941e89846a92 | Linux bridge agent | controller | None              | True  | UP    | neutron-linuxbridge-agent |
| 08905043-5010-4b87-bba5-aedb1956e27a | Linux bridge agent | compute1   | None              | True  | UP    | neutron-linuxbridge-agent |
| 830344ff-dc36-4956-84f4-067af667a0dc | L3 agent           | controller | nova              | True  | UP    | neutron-l3-agent          |
| dd3644c9-1a3a-435a-9282-eb306b4b0391 | DHCP agent         | controller | nova              | True  | UP    | neutron-dhcp-agent        |
+--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+

На выходе должны указываться четыре агента на узле контроллера и один агент на каждом вычислительном узле.

Панель управления(Dashboard)

Панель инструментов (horizon) - это веб-интерфейс, который позволяет администраторам и пользователям облачных сайтов управлять различными ресурсами и сервисами OpenStack. В этом примере развертывание использует веб-сервер Apache.

Установка и настройка

В этом разделе описывается, как установить и настроить панель управления на узле контроллера. Единственной основной услугой, необходимой для установки, является служба Identity. Вы можете использовать панель управления в сочетании с другими службами, такими как Image, Compute и Networking. Вы также можете использовать панель управления в средах с автономными службами, такими как Block Storage.

Установка и настройка компонентов
  • Установка компонентов:
# apt install openstack-dashboard
  • Отредактируйте файл /etc/openstack-dashboard/local_settings.py и выполните следующие действия:
    • Настройте панель управления для использования служб OpenStack на узле контроллера:
OPENSTACK_HOST = "controller" 
    • Разрешить всем хостам доступ к панели мониторинга:
ALLOWED_HOSTS = ['*', ]
    • Настройте службу хранения memcached сессии:
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

CACHES = {
    'default': {
         'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
         'LOCATION': 'controller:11211',
    }
}
  • Включить Identity API версии 3:
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % OPENSTACK_HOST
  • Включить поддержку доменов:
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
  • Настройка версий API:
OPENSTACK_API_VERSIONS = {
    "identity": 3,
    "image": 2,
    "volume": 2,
}
  • Настройте default в качестве домена по умолчанию для пользователей, созданных с помощью панели управления:
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = "default"
  • Настройте user как роль по умолчанию для пользователей, созданных с помощью панели управления:
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "user"
  • Если вы выбрали сетевой вариант 1, отключите поддержку сетевых служб уровня 3:
OPENSTACK_NEUTRON_NETWORK = {
    ...
    'enable_router': False,
    'enable_quotas': False,
    'enable_ipv6': False,
    'enable_distributed_router': False,
    'enable_ha_router': False,
    'enable_lb': False,
    'enable_firewall': False,
    'enable_vpn': False,
    'enable_fip_topology_check': False,
}
  • При необходимости настройте часовой пояс:
TIME_ZONE = "TIME_ZONE"

Замените TIME_ZONE соответствующим идентификатором часового пояса. Для получения дополнительной информации см. Список часовых поясов. Конец установки:

  • Перезагрузите конфигурацию веб-сервера:
# service apache2 reload
Проверка работоспособности

Проверьте работу панели управления. Войдите в панель управления с помощью веб-браузера по адресу http://controller/horizon. Аутентификация с использованием admin или demo-пользователей и учетных данных домена default. Ваша среда OpenStack теперь включает панель управления. Вы можете запустить экземпляр или добавить дополнительные службы в свою среду.

После установки и настройки панели мониторинга вы можете выполнить следующие задачи:

  • Предоставьте пользователям общедоступный IP-адрес, имя пользователя и пароль, чтобы они могли получить доступ к панели мониторинга через веб-браузер. В случае возникновения проблем с подключением SSL-сертификата укажите IP-адрес сервера на имя домена и дайте пользователям доступ.
  • Настройте свою панель инструментов.
  • Настройте хранилище сеансов.
  • Чтобы использовать клиент VNC с информационной панелью, браузер должен поддерживать HTML5 Canvas и HTML5 WebSockets.

Служба хранения блоков(Block Storage)

Служба хранения блоков (cinder) предоставляет устройства хранения блоков в гостевых экземплярах. Метод, в котором хранилище предоставляется и используется, определяется драйвером Block Storage или драйверами в случае конфигурации с несколькими backend. Существует множество доступных драйверов: NAS / SAN, NFS, iSCSI, Ceph и другие. API Block Storage и службы планировщика обычно выполняются на узлах контроллера. В зависимости от используемых драйверов служба тома может работать на узлах контроллера, вычислительных узлах или автономных узлах хранения. Служба хранения блоков OpenStack (cinder) добавляет постоянное хранилище на виртуальную машину. Block Storage обеспечивает инфраструктуру для управления томами и взаимодействует с OpenStack Compute для предоставления томов для экземпляров. Услуга также позволяет управлять объемными снимками и типами томов. Служба хранения блоков состоит из следующих компонентов:

  • cinder-api - Принимает запросы API и направляет их cinder-volume для обработки.
  • cinder-volume - Взаимодействует непосредственно с службой Block Storage и такими процессами, как cinder-scheduler. Он также взаимодействует с этими процессами через очередь сообщений. Служба cinder-volume отвечает на запросы чтения и записи, отправленные в службу хранения блоков, чтобы поддерживать состояние. Он может взаимодействовать с различными поставщиками хранилища через архитектуру драйвера.
  • cinder-scheduler daemon - Выбор оптимального узла поставщика хранилища для создания тома. Аналогичный компонент для nova-scheduler.
  • cinder-backup daemon - Служба резервного копирования cinder обеспечивает резервное копирование томов любого типа резервного хранилища. Подобно сервису службы cinder-volume, он может взаимодействовать с различными хранилищами через архитектуру драйвера.
  • Messaging queue - Маршрутизирует информацию между процессами Block Storage.

Установка и настройка управляющего узла

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

Предустановка

Перед установкой и настройкой службы Block Storage необходимо создать базу данных, учетные данные службы и endpoints API.

  • Чтобы создать базу данных, выполните следующие действия:
    • Используйте клиент доступа к базе данных для подключения к серверу базы данных в качестве пользователя root:
$ mysql -u root -p
    • Создайте базу данных cinder:
mysql> CREATE DATABASE cinder;
    • Предоставьте надлежащий доступ к базе данных cinder:
mysql> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' \
 IDENTIFIED BY 'CINDER_DBPASS';
 mysql> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%' \
 IDENTIFIED BY 'CINDER_DBPASS';

Замените CINDER_DBPASS на подходящий пароль.

    • Выйдите из клиента доступа к базе данных.
  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Чтобы создать учетные данные службы, выполните следующие действия:
    • Создайте пользователя cinder:
$ openstack user create --domain default --password-prompt cinder

User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 0dbcdd0968dd4c948eacf9eb60d82b46 |
| name                | cinder                           |
| password_expires_at | None                             |
+---------------------+----------------------------------+
    • Добавьте роль admin для пользователя cinder:
$ openstack role add --project service --user cinder admin
    • Создайте объекты службы cinder и cinderv2:
$ openstack service create --name cinder \
  --description "OpenStack Block Storage" volume

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Block Storage          |
| enabled     | True                             |
| id          | ab3bbbef780845a1a283490d281e7fda |
| name        | cinder                           |
| type        | volume                           |
+-------------+----------------------------------+
$ openstack service create --name cinderv2 \
  --description "OpenStack Block Storage" volumev2

+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Block Storage          |
| enabled     | True                             |
| id          | eb9fd245bdbc414695952e93f29fe3ac |
| name        | cinderv2                         |
| type        | volumev2                         |
+-------------+----------------------------------+
  • Создайте конечные точки API службы Block Storage:
$ openstack endpoint create --region RegionOne \
  volume public http://controller:8776/v1/%\(tenant_id\)s

  +--------------+-----------------------------------------+
  | Field        | Value                                   |
  +--------------+-----------------------------------------+
  | enabled      | True                                    |
  | id           | 03fa2c90153546c295bf30ca86b1344b        |
  | interface    | public                                  |
  | region       | RegionOne                               |
  | region_id    | RegionOne                               |
  | service_id   | ab3bbbef780845a1a283490d281e7fda        |
  | service_name | cinder                                  |
  | service_type | volume                                  |
  | url          | http://controller:8776/v1/%(tenant_id)s |
  +--------------+-----------------------------------------+

$ openstack endpoint create --region RegionOne \
  volume internal http://controller:8776/v1/%\(tenant_id\)s

  +--------------+-----------------------------------------+
  | Field        | Value                                   |
  +--------------+-----------------------------------------+
  | enabled      | True                                    |
  | id           | 94f684395d1b41068c70e4ecb11364b2        |
  | interface    | internal                                |
  | region       | RegionOne                               |
  | region_id    | RegionOne                               |
  | service_id   | ab3bbbef780845a1a283490d281e7fda        |
  | service_name | cinder                                  |
  | service_type | volume                                  |
  | url          | http://controller:8776/v1/%(tenant_id)s |
  +--------------+-----------------------------------------+

$ openstack endpoint create --region RegionOne \
  volume admin http://controller:8776/v1/%\(tenant_id\)s

  +--------------+-----------------------------------------+
  | Field        | Value                                   |
  +--------------+-----------------------------------------+
  | enabled      | True                                    |
  | id           | 4511c28a0f9840c78bacb25f10f62c98        |
  | interface    | admin                                   |
  | region       | RegionOne                               |
  | region_id    | RegionOne                               |
  | service_id   | ab3bbbef780845a1a283490d281e7fda        |
  | service_name | cinder                                  |
  | service_type | volume                                  |
  | url          | http://controller:8776/v1/%(tenant_id)s |
  +--------------+-----------------------------------------+
$ openstack endpoint create --region RegionOne \
  volumev2 public http://controller:8776/v2/%\(tenant_id\)s

+--------------+-----------------------------------------+
| Field        | Value                                   |
+--------------+-----------------------------------------+
| enabled      | True                                    |
| id           | 513e73819e14460fb904163f41ef3759        |
| interface    | public                                  |
| region       | RegionOne                               |
| region_id    | RegionOne                               |
| service_id   | eb9fd245bdbc414695952e93f29fe3ac        |
| service_name | cinderv2                                |
| service_type | volumev2                                |
| url          | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+

$ openstack endpoint create --region RegionOne \
  volumev2 internal http://controller:8776/v2/%\(tenant_id\)s

+--------------+-----------------------------------------+
| Field        | Value                                   |
+--------------+-----------------------------------------+
| enabled      | True                                    |
| id           | 6436a8a23d014cfdb69c586eff146a32        |
| interface    | internal                                |
| region       | RegionOne                               |
| region_id    | RegionOne                               |
| service_id   | eb9fd245bdbc414695952e93f29fe3ac        |
| service_name | cinderv2                                |
| service_type | volumev2                                |
| url          | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+

$ openstack endpoint create --region RegionOne \
  volumev2 admin http://controller:8776/v2/%\(tenant_id\)s

+--------------+-----------------------------------------+
| Field        | Value                                   |
+--------------+-----------------------------------------+
| enabled      | True                                    |
| id           | e652cf84dd334f359ae9b045a2c91d96        |
| interface    | admin                                   |
| region       | RegionOne                               |
| region_id    | RegionOne                               |
| service_id   | eb9fd245bdbc414695952e93f29fe3ac        |
| service_name | cinderv2                                |
| service_type | volumev2                                |
| url          | http://controller:8776/v2/%(tenant_id)s |
+--------------+-----------------------------------------+
Установка и настройка компонентов
  • Установите пакеты:
# apt install cinder-api cinder-scheduler
  • Отредактируйте файл /etc/cinder/cinder.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder

Замените CINDER_DBPASS на пароль, который вы выбрали для базы данных Block Storage.

    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

    • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе Identity:
[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = cinder
password = CINDER_PASS

Замените CINDER_PASS на пароль, который вы выбрали для пользователя cinder в службе Identity.

    • В разделе [DEFAULT] настройте параметр my_ip для использования IP-адреса интерфейса управления узла контроллера:
[DEFAULT]
...
my_ip = 10.0.0.11
    • В разделе [oslo_concurrency] настройте путь блокировки:
[oslo_concurrency]
...
lock_path = /var/lib/cinder/tmp
  • Заполните базу данных Block Storage:
# su -s /bin/sh -c "cinder-manage db sync" cinder
Настройка вычислительного узла для Block Storage
  • Отредактируйте файл /etc/nova/nova.conf и добавьте к нему следующее:
[cinder]
os_region_name = RegionOne

Конец установки:

  • Перезапустите службу Compute API:
# service nova-api restart
  • Перезапустите службы Block Storage:
# service cinder-scheduler restart
# service cinder-api restart

Установка и настройка управляющего узла

В этом разделе описывается, как устанавливать и настраивать узлы хранения для службы Block Storage. Для простоты эта конфигурация ссылается на один узел хранения с пустым устройством хранения локального блока. В инструкциях используется /dev/sdb, но вы можете подставить другое значение для вашего конкретного узла.

Служба предоставляет логические тома на этом устройстве с использованием драйвера LVM и предоставляет их экземплярам через транспорт iSCSI. Вы можете следовать этим инструкциям с небольшими изменениями в горизонтальном масштабе вашей среды с дополнительными узлами хранения.

Предустановка

Перед установкой и настройкой службы Block Storage на узле хранения необходимо подготовить устройство хранения.

  • Установите допольнительные пакеты:
# apt install lvm2
  • Создайте физический том LVM /dev/sdb:
# pvcreate /dev/sdb

Physical volume "/dev/sdb" successfully created
  • Создайте cinder-volumes группы LVM:
# vgcreate cinder-volumes /dev/sdb

Volume group "cinder-volumes" successfully created

Служба Block Storage создает логические тома в этой группе томов.

  • Только экземпляры могут обращаться к томам блока хранения. Однако основная операционная система управляет устройствами, связанными с томами. По умолчанию инструмент сканирования томов LVM сканирует каталог /dev для устройств хранения блоков, содержащих тома. Если проекты используют LVM на своих томах, инструмент сканирования обнаруживает эти тома и пытается кэшировать их, что может вызвать множество проблем как с базовой операционной системой, так и с объемами проектов. Вы должны перенастроить LVM для сканирования только тех устройств, которые содержат группу томов объёма. Отредактируйте файл /etc/lvm/lvm.conf и выполните следующие действия:
  • В разделе devices добавьте фильтр, который принимает устройство /dev/sdb и отклонит все остальные устройства:
devices {
...
filter = [ "a/sdb/", "r/.*/"]

Каждый элемент в массиве фильтров начинается с a для accept(подтверждения) или r для reject (отклонения) и включает регулярное выражение для имени устройства. Массив должен заканчиваться на r/.*/, чтобы отклонить все остальные устройства. Вы можете использовать команду vgs -vvvv для тестирования фильтров.

Установка и настройка компонентов
  • Установите пакеты:
# apt install cinder-volume
  • Отредактируйте файл /etc/cinder/cinder.conf и выполните следующие действия:
    • В разделе [database] настройте доступ к базе данных:
[database]
...
connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder

Замените CINDER_DBPASS на пароль, который вы выбрали для базы данных Block Storage.

    • В разделе [DEFAULT] настройте доступ к очереди сообщений RabbitMQ:
[DEFAULT]
...
transport_url = rabbit://openstack:RABBIT_PASS@controller

Замените RABBIT_PASS паролем, который вы выбрали для учетной записи openstack в RabbitMQ.

    • В разделах [DEFAULT] и [keystone_authtoken] настройте доступ к службе Identity:
[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = cinder
password = CINDER_PASS

Замените CINDER_PASS на пароль, который вы выбрали для пользователя cinder в службе Identity.

  • В разделе [DEFAULT] настройте параметр my_ip:
[DEFAULT]
...
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS

Замените MANAGEMENT_INTERFACE_IP_ADDRESS на IP-адрес сетевого интерфейса управления на вашем узле хранения, как правило, 10.0.0.41 для первого узла в примере архитектуры.

    • В разделе [lvm] настройте конец LVM с драйвером LVM, группой cinder-volumes , протоколом iSCSI и соответствующей службой iSCSI:
    • В разделе [DEFAULT] включите задний конец LVM:
[DEFAULT]
...
enabled_backends = lvm
    • В разделе [DEFAULT] настройте расположение API-интерфейса Image:
[DEFAULT]
...
glance_api_servers = http://controller:9292
    • В разделе [oslo_concurrency] настройте путь блокировки:
[oslo_concurrency]
...
lock_path = /var/lib/cinder/tmp

Конец установки:

  • Перезапустите службу Volume Storage, включая ее зависимости:
# service tgt restart
# service cinder-volume restart

Проверка работоспособности

  • Введите учетные данные admin, чтобы получить доступ к командам CLI только для администратора:
$ . admin-openrc
  • Перечислите сервисные компоненты для проверки успешного запуска каждого процесса:
$ openstack volume service list

+------------------+------------+------+---------+-------+----------------------------+
| Binary           | Host       | Zone | Status  | State | Updated_at                 |
+------------------+------------+------+---------+-------+----------------------------+
| cinder-scheduler | controller | nova | enabled | up    | 2016-09-30T02:27:41.000000 |
| cinder-volume    | block@lvm  | nova | enabled | up    | 2016-09-30T02:27:46.000000 |
+------------------+------------+------+---------+-------+----------------------------+

Видео установка на Debian

Примечания