Глава 10. Интеграция Ceph с OpenStack

OpenStack является платформой с открытым исходным кодом, для оснащения частных или общедоступных облачных решений со множеством арендаторов для построения гибкого и масштабируемого решения IaaS (Infrastructure as a Service, Инфраструктуры как службы). Будучи программным обеспечением с открытым исходным кодом, OpenStack предлагает богатый комплекс возможностей без привязки к определённому производителю или затратного лицензирования. OpenStack управляется некоммерческим Фондом OpenStack и поддерживается известными компаниями, включающими Red Hat, Mirantis, Dell, Cisco, IBM и Rackspace. Также имеются мириады персональных участников.

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

Nova является самым сердцем OpenStack: она создаёт и управляет экземплярами виртуальных машин, обычно применяющих QEMU/ KVM, однако прочие гостевые технологии виртуализации также доступны через систему libvirt, включая Xen, Hyper-V, VMware и даже голое железо. Nova классифицирует экземпляры по системам гипервизора в соответствии с потребностями, доступностью, а также политиками и выравнивает для подключения ресурсов сетевой среды и системы хранения.

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

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

Swift является системой хранения объектов OpenStack. Он включает в себя и основу хранения с избыточностью учётных записей, посредничеста (proxy), контроллера, а также узлов хранения объектов, а также API доступа, аналогичным S3 Amazon. Можно построить некое объектное хранилище с помощью Swift, однако если вам при этом также требуется и службы хранения блоков, и файловой системы, вам придётся предоставить и раздельно управлять дополнительными решениями. Служба Шлюза RADOS Ceph (RGW) предоставляет совместимый со Swift API тем, кому он требуется и при этом также сопровождает блочные и файловые службы из единой основы хранения.

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

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

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

В рамках OpenStack Ceph применяет Keystone предоставляя соответствие между пользователями шлюза RADOS и арендаторами и ролями OpenStack. Keystone также применяется для регистрации самого RGW и URL прочих конечных точек служб.

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

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

OpenStack является многогранным и развивающимся, поэтому даже полная настройка OpenStack для Ceph является трудной в рамках данной книги.

На верхнем уровне мы создаём пулы Cinder, Glance и RGW, затем устанавливаем пакеты Ceph, полномочия и настраиваем гипервизоры Nova OpenStack а также контроллеры Cinder и Glance. Для полноты подробностей ознакомьтесь с приводимыми далее ссылками, на если кратко:

# ceph-deploy install <name of OpenStack node>
# ceph-deploy admin <name of OpenStack node>
		

Также вам потребуется управлять основным файлом настроек в /etc/ceph на каждом узле OpenStack с тем, чтобы ваш кластер мог взаимодействовать и был доступен. Каждая служба OpenStack также нуждается в настройке для применения ваших кластеров Ceph. Например:

glance-api.conf:
[glance_store]
 stores = rbd
 default_store = rbd
 rbd_store_pool = images
 rbd_store_user = glance-user
 rbd_store_ceph_conf = /etc/ceph/ceph.conf
 rbd_store_chunk_size = 8

cinder.conf:
[DEFAULT]
 enabled_backends = ceph

 [ceph]
 volume_driver = cinder.volume.drivers.rbd.RBDDriver
 volume_backend_name = ceph
 rbd_pool = cinder-pool
 rbd_ceph_conf = /etc/ceph/ceph.conf
 rbd_flatten_volume_from_snapshot = false
 rbd_max_clone_depth = 3
 rbd_store_chunk_size = 4
 rados_connect_timeout = -1
 glance_api_version = 2
 rbd_user = rbd-user
 rbd_secret-uuid=xxxx-xxxxxx
 backup_driver = cinder.backup.drivers.ceph
 backup_ceph_conf = /etc/ceph/ceph.conf
 backup_ceph_user = cinder-backup
 backup_ceph_chunk_size = 134217728
 backup_ceph_pool = backups
 backup_ceph_stripe_unit = 0
 backup_ceph_stripe_count = 0
 restore_discard_excess_bytes = true
 
nova.conf:
 [libvirt]
 images_type = rbd
 images_rbd_pool = cinder-pool
 images_rbd_ceph_conf = /etc/ceph/ceph.conf
 rbd_user = rbd-user
 rbd_secret_uuid = 457ec676-34da-4bec-938c-9291138d545c337
 disk_cachemodes="network=writeback"
 hw_disk_discard = unmap # enable discard support
 live_migration_flag= "VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_PERSIST_DEST,VIR_MIGRATE_TUNNELLED"
 	   

Большинство оснащений OpenStack имеют свои собственные механизмы для наполнения пакетов и управления ими, а также их настройки с применением Ansible, Puppet, Chef или прочих инструментов. Имеются шансы, что ваша реализация уже имеет возможность управления этим для вас.

После настройки пользователи и службы способны определять конечные точки служб путём запросов к базе данных Keystone, а сама службе Nova через libvirt имеет возможность создавать и применять тома RBD Ceph.

Облака OpenStack обычно настраиваются для пердставления виртуальных дисков экземплярам гостевой операционной системы через libvirt посредством драйверов virtio, которые обходят ограничения нагрузки и производительности эмуляции обычных устройств IDE/ATA. В кластера Linux эти тома часто представляются как /dev/vda, /dev/vdb и так далее в случае если применяется более ранний драйвер virtio-blk и как /dev/sda, /dev/sdb и далее при настройке более новым драйвером virtio-scsi. В любом случае можно также ссылаться на устройства применяя UUID, как это было представлено в предыдущем примере.

Гостевые операционные системы могут таким образом устанавливать и применять тома на основе Ceph как если бы они были обычными физическими дисками, как для устройств загрузки, так и для вспомогательных устройств. Сама гостевая операционная система через утилиту cloud-init будет обычно изменять свой размер при самой первой загрузке чтобы соответствовать предоставляемому размеру.

Вот некий пример создания тома в 500 ГБ и его подключения к некому имеющемуся экземпляру Nova в качестве дополнительного устройства:

$ cinder create --display_name MyVolume 500
$ cinder list
+---------------------+---------+------------+----+-----------+
|          ID         | Status  |Display Name|Size|Volume Type|
+---------------------+---------+------------+----+-----------+
|19a9f901-ba9d-45e1-8622-a5466673ae76 |available|MyVolume 500| |
+---------------------+---------+------------+----+-----------+
$ nova list
+----------------------------+------+--------+----------------------+
|         ID                 | Name | Status |     Networks         |
+----------------------------+------+--------+----------------------+
| 842331c-ncc-n0-b100di-abcd |eprise| ACTIVE | private=192.168.1.2  |
+----------------------------+------+--------+----------------------+
$ nova volume-attach 842331c-ncc-n0-b100di-abcd \
            19a9f901-ba9d-45e1-8622-a5466673ae76 auto
		

Затем в этом экземпляре мы можем просматривать этот том, создавать в нём разделы, форматировать и монтировать его.

instance$ ls /dev/vd*
/dev/vda /dev/vda1 /dev/vdb
instance$ lsblk
 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
 vda 253:0 0 10G 0 disk
 └─vda1 253:1 0 10G 0 part /
 vdb 253:16 0 500G 0 disk

instance$ fdisk /dev/vdb
instance$ mkfs.xfs /dev/vdb1
instance$ mkdir /mountpoint
instance$ mount /dev/vdb1 /mountpoint
		

OpenStack эволюционирует и является многосторонним; нам затруднительно предоставить здесь подробные шаги для оснащения некоторого виртуального кластера OpenStack неким способом, который будет работать и соответствовать целям, которыми вы обогащаетесь в данной главе. Однако имеются два популярных пакета чтобы помочь вам развернуть некий кластер виртуализации на скорую руку, с которым вы можете поэксперементировать и даже интегрировать его со своим виртуальным кластером Ceph из Главы 5, Развёртывание виртуального кластера песочницы.

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