Содержание


Знакомство с OpenStack

Storage-компоненты Swift и Cinder

Comments

Серия контента:

Этот контент является частью # из серии # статей: Знакомство с OpenStack

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Знакомство с OpenStack

Следите за выходом новых статей этой серии.

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

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

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

  • OpenStack Swift — это пример объектного хранилища, которое по своей концепции подобно решению Amazon Simple Storage Service.
  • В отличие от него, OpenStack Cinder — это блочное хранилище, подобное решению Amazon Elastic Block Store.

Блочное хранилище OpenStack Block Storage (Cinder)

Cinder — это кодовое имя проекта OpenStack Block Storage; данный компонент предоставляет персистентное блочное хранилище для гостевых виртуальных машин. Блочное хранилище часто требуется для поддержки расширяемых файловых систем, для достижения максимальной производительности и для интеграции с корпоративными сервисами хранения, а также для приложений, которым требуется хранилище блочного уровня без файловой структуры.

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

Объектное хранилище OpenStack Object Storage (Swift)

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

В основе объектного хранилища лежат две основные концепции — объекты и контейнеры.

Объект — это основная сущность хранения. Он содержит контент и все возможные дополнительные метаданные, ассоциированные с файлами, хранящимися в системе OpenStack Object Storage. Данные хранятся в несжатом и в незашифрованном виде и состоят из имени объекта, его контейнера и, возможно, метаданных, представленных в форме пар "ключ/значение". Объекты распределены между несколькими дисками в масштабе всего центра обработки данных, чем Swift гарантирует репликацию данных и целостность данных. Распределенная организация позволяет применять недорогие массовые аппаратные средства, а также улучшает такие характеристики, как масштабируемость, избыточность и долговечность.

Контейнер подобен папке Windows® в том смысле, что он является отсеком хранилища для размещения набора файлов. Контейнеры не могут быть вложены друг в друга, однако у арендатора имеется возможность создать неограниченное количество контейнеров. Объекты должны храниться в контейнере, поэтому для того, чтобы использовать хранилище объектов Object Storage, необходимо не менее одного контейнера.

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

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

Архитектура Swift состоит из трех компонентов — серверы, процессы и кольца.

Серверы

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

  • Прокси-сервер
  • Серверы объектов
  • Серверы контейнеров
  • Серверы учетных записей

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

Сервер объектов — это простой сервер, способный загружать, изменять и извлекать объекты (обычно это файлы), хранящиеся на устройствах, которыми он управляет. Объекты хранятся в локальной файловой системе с использованием расширенных атрибутов, которые могут содержать дополнительные метаданные. Маршрут объекта базируется на хеш-функции имени объекта и на метке времени.

Сервер контейнеров по существу является каталогом объектов. Он осуществляет привязку объектов к определенному контейнеру и по запросу предоставляет списки контейнеров. В целях резервирования эти списки реплицируются в масштабе всего кластера.

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

Процессы

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

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

Чтобы свести к минимуму объем сетевого трафика, необходимого для этого сравнения, сервисы создают хеш для каждой подсекции раздела и сравнивают эти списки. При репликации контейнеров и учетных записей также используются хеши, но они дополняются общими наивысшими отметками (high-water mark). Реальные обновления осуществляются по принципу проталкивания, в общем случае – посредством использования rsync для копирования объектов, контейнеров и учетных записей.

Кроме того, репликатор выполняет сборку мусора, обеспечивая принудительное согласованное удаление сопутствующих данных в случае удаления каких-либо объектов, контейнеров или учетных записей. После удаления какого-либо объекта и т. д. система помечает его последнюю версию "надгробным камнем" (tombstone), что является сигналом репликатору о необходимости удаления соответствующего элемента на всех реплицированных узлах.

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

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

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

Кольца

Пользователи и другие проекты OpenStack обращаются к хранимым сущностям по их логическим именам, однако в конечном итоге все запросы (как по чтению, так и по записи) должны отображаться на конкретное физическое местоположение. Для этого прокси-сервер и обеспечивающие процессы, включая сервисы репликации, должны уметь отображать логические имена на физические местоположения. Это отображение носит название кольцо (ring). Учетные записи, контейнеры и объекты сопоставляются с отдельными кольцами. Кольцо описывает это отображение в терминах устройств, разделов, реплик и зон.

В этом контексте термин раздел (partition) относится к логическим подмножествам контента, хранящегося в кольце. Рекомендуется выделять по 100 разделов для каждого участвующего устройства. Эти разделы распределяются равномерно между всеми устройствами, приписанными к компоненту OpenStack Object Storage. Если в кластере используются диски разных размеров, также можно назначать весовые коэффициенты для выравнивания распределения разделов между устройствами.

По умолчанию каждый раздел реплицируется три раза. Можно использовать большее количество реплик (replica) для оптимизации доступности, однако очевидно, что при этом также увеличится потребление ресурсов хранения. Кольцо также указывает, какие устройства следует использовать при передаче управления в сценариях сбоя и как перераспределять разделы при добавлении устройств в кластер или при удалении их из кластера.

Последний элемент отображения с помощью кольца – это зона (zone), которая используется для включения/отключения т. н. "близости данных" (data affinity). Зона может задавать устройство хранения данных, физический сервер или местоположение (стойка, проход или центр обработки данных). Зона — это логическая концепция, которую пользователи могут применять в соответствии со своими потребностями, однако обычно она отражает такие физические элементы, как местоположение, источник питания и сетевое соединение.

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

Архитектура Cinder значительно проще, чем архитектура Swift, поскольку Cinder не осуществляет автоматическое распределение объектов и их репликацию. Архитектура Cinder показана на рис. 1.

Рисунок 1. Архитектура Cinder
Image showing the Cinder architecture
Image showing the Cinder architecture

SКак и в случае других проектов OpenStack, доступ к функциям Cinder можно получить через API-интерфейс при посредстве информационной панели и командной строки. К хранилищу объектов можно обращаться через интерфейс RESTful HTTP API с аутентификацией на компоненте OpenStack Keystone с помощью Python-класса с именем Auth Manager.

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

Диспетчер томов управляет динамически присоединяемыми устройствами блочного хранения данных, которые называются томами. Они могут использоваться в качестве устройств начальной загрузки виртуальных экземпляров или присоединяться в качестве вторичного хранилища. Кроме того, Cinder позволяет делать моментальные снимки, которые представляют собой копии томов, доступные только в режиме чтения. Эти снимки можно использовать для создания новых томов с поддержкой чтения-записи.

Обычно тома присоединяются к Compute-узлам посредством технологии iSCSI. Кроме того, блочному хранилищу требуется какая-либо внутренняя система, которая по умолчанию осуществляет управление логическими томами в локальной группе томов, однако с помощью драйверов может распространить свое влияние на внешние массивы хранения или аппаратно-программные комплексы (appliance).

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

Инструкции по установке конкретной системы существенно зависят от дистрибутивов и от релиза OpenStack. Как правило, эти инструкции предоставляются в составе дистрибутива. Однако вне зависимости от дистрибутива/релиза вам придется выполнять одни и те же основные задачи, которые рассматриваются в этом разделе.

Системные требования

Платформа OpenStack ориентирована на 64-разрядную x86-архитектуру; другими словами, она рассчитана на применение массовых аппаратных средств, поэтому минимальные системные требования весьма скромны. Весь пакет проектов OpenStack способен исполняться на одной системе с оперативной памятью объемом 8 ГБ. Однако в случае больших рабочих нагрузок имеет смысл использовать в качестве хранилища выделенные системы. Поскольку описываемая платформа ориентирована на массовое оборудование, нет никакой необходимости в применении такой функциональности, как RAID-диски, тем не менее рекомендуется использовать как минимум четырехъядерные процессоры, 8–12 ГБ оперативной памяти и гигабитный сетевой адаптер. Очевидно, что размеры жесткого диска или SSD-накопителя зависят от объема данных, подлежащих хранению, и от желаемого уровня избыточности.

Установка

Инструкции по установке зависят от дистрибутива, в частности, от выбранной вами утилиты управления пакетами. Во многих случаях при установке необходимо объявить репозитарий. Так, например, в случае утилиты Zypper необходимо объявлять libzypp с параметром zypper ar:

# zypper ar -f http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/SLE_11_SP3/Cloud:OpenStack:Grizzly.repo

Затем нужно установить требуемые пакеты Swift и/или Cinder. Утилита управления пакетами автоматически установит все нужные зависимости. Окончательный вид процедуры установки зависит от требуемой конфигурации и от конкретного релиза OpenStack, используемого при установке. Необходимо ознакомиться с соответствующими инструкциями, изложенными в Руководстве по установке. В качестве иллюстрации я приведу основные команды для следующих ОС: Debian (напр., Ubuntu), Red Hat (Red Hat Enterprise Linux®, CentOS, Fedora) и openSUSEE:

  • Debian: Установите базовые пакеты Swift на всех хостах:
    sudo apt-get install python-swift
    sudo apt-get install swift
    и соответствующие серверные пакеты на хостах, на которых будут исполняться эти серверы:
    sudo apt-get install swift-auth
    sudo apt-get install swift-proxy
    sudo apt-get install swift-account
    sudo apt-get install swift-container
    sudo apt-get install swift-object

    В состав Cinder входят пакеты API, планировщика и диспетчера томов:

    sudo apt-get install cinder-api
    sudo apt-get install cinder-scheduler
    sudo apt-get install cinder-volume
  • Red Hat: Выполните следующие команды:
    sudo yum install openstack-swift
    sudo yum install openstack-swift-proxy
    sudo yum install openstack-swift-account
    sudo yum install openstack-swift-container
    sudo yum install openstack-swift-object
    sudo yum install openstack-swift-doc
    sudo yum install openstack-cinder
    sudo yum install openstack-cinder-doc
  • openSUSE: Выполните следующие команды:
    sudo zypper install  openstack-swift
    sudo zypper install  openstack-swift-auth 
    sudo zypper install  openstack-swift-account 
    sudo zypper install  openstack-swift-container 
    sudo zypper install  openstack-swift-object 
    sudo zypper install  openstack-swift-proxy
    sudo zypper install openstack-cinder-api
    sudo zypper install openstack-cinder-scheduler
    sudo zypper install openstack-cinder-volume

Конфигурирование

Конфигурирование установки OpenStack Object Storage сводится к настройке конфигурационных файлов для каждого из следующих четырех пакетов:

  • account-server.conf
  • container-server.conf
  • object-server.conf
  • proxy-server.conf

Конфигурационные файлы устанавливаются в каталог /etc/swift/. Набор опций по умолчанию хорошо подходит для стандартной установки, однако при наличии каких-либо особых требований вам придется отредактировать эту конфигурацию.

Сценарии использования

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

Начнем с компонента Cinder.

  1. Войдите в панель OpenStack Dashboard в качестве пользователя с ролью Member. В навигационной панели под заголовком Manage Computer нажмите Volumes > Create Volume.
    Рисунок 2. Создание тома
    Image showing how to create a volume
    Image showing how to create a volume
  2. Том должен появиться в списке для вашего проекта.
    Рисунок 3. Тома вашего проекта
    Image showing the volumes for your project
    Image showing the volumes for your project
  3. Отредактируйте подключения, чтобы связать этот том с одним из ваших Compute-экземпляров.
    Рисунок 4. Управление подключением томов
    Image showing how to edit attachments
    Image showing how to edit attachments

OpenStack создает уникальное допустимое iSCSI-имя и представляет его Compute-узлу, у которого теперь имеется активный сеанс iSCSI. Этот экземпляр может использовать том Cinder точно так же, как если бы это было локальное хранилище (обычно как диск /dev/sdX).

Чтобы можно было использовать Swift с вашим проектом, необходимо сначала создать контейнер.

  1. Войдите в панель OpenStack Dashboard в качестве пользователя с ролью Member. В навигационной панели под заголовком Object Store нажмите Containers > Создание контейнера.
    Рисунок 5. Create a container
    Image showing how to create a container
    Image showing how to create a container

    Это простая операция, которая не предусматривает предоставление каких-либо данных. Необходимо ввести лишь имя контейнера.

  2. Теперь, когда у вас есть контейнер, в большинстве случаев приложение будет наполнять его объектами и извлекать их по мере необходимости с помощью программного интерфейса.
    Рисунок 6. Заполненный контейнер
    Image showing the populated container
    Image showing the populated container
  3. Объекты также можно загрузить с помощью информационной панели. Под заголовком Object Store нажмите Containers > Upload Object и введите имя файла с сохраненным контентом.
    Рисунок 7. Загрузка объекта
    Image showing how to upload an object
    Image showing how to upload an object

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

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Open source
ArticleID=999788
ArticleTitle=Знакомство с OpenStack: Storage-компоненты Swift и Cinder
publish-date=03062015