ГЛАВА 5

Решения систем хранения

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

Концепции хранилища OpenStack

Если вы разворачиваете только OpenStack Compute Service (nova), вашим пользователям по умолчанию не будут доступны никакие устройства постоянного хранения. Диски связанные с ВМ являются "эфемерными" (ephemeral, временными), что означает (с точки зрения пользователя), что они эффективно исчезают по завершению сеанса. Вы должны определить,какой тип устройств постоянного хранения вы хотите предоставить своим пользователям.

На сегодняшний день OpenStack в явном виде поддерживает два вида устройств непрерывного хранения: хранилища объектов (object storage) и блочные хранилища (block storage)

Хранилища объектов

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

Блочные хранилища

Блочные хранилища (иногда называемые хранилищами томов) выставляют для пользователя блочные устройства. Пользователи взаимодействуют с блочными хранилищами путем присоединения томов к своим работающим экземплярам.

Эти тома являются постоянными: они могут быть отделены от одного экземпляра и повторно подключены к другому, причем данные остаются не поврежденными. Блочные хранилища реализуются в OpenStack проектом OpenStack Block Storage (Cinder), который поддерживает множество серверов хранения в форме устройств (drivers). Выбранный вами сервер хранения должен поддерживаться устройством блочного хранилища.

Большинство устройств блочного хранилища позволяют экземпляру осуществлять прямой доступ к аппаратным средствам устройства блочной СХД. Это позволяет увеличить общее чтение/запись системы ввода/вывода.

В редакции Folsom начала осуществляться поддержка использования файлов в качестве томов. Изначально она стартовала как драйвер ссылок для поддержки NFS в Cinder. Начиная с редакции Grizzly, поддержка была расширена до полномасштабного драйвера NFS, а также дополнена драйвером GlusterFS.
Прим. пер.: Havana (17 октября 2013) и Icehouse (17 апреля 2014) существенно расширили список поддерживаемых файловых систем и СХД. Например, начиная с Havana осуществляется поддержка GPFS NSD. Полный действующий список поддерживаемых файловых систем и систем хранения данных доступен по адресу https://wiki.openstack.org/wiki/CinderSupportMatrix

Работа этих драйверов слегка отличается от обычных драйверов "блочных" систем хранения. В файловых системах NFS и GlusterFS создается некий файл, который затем отображается в виде тома в экземпляре. Такое отображение/ трансляция аналогично использованию OpenStack-ом в QEMU виртуальных машин на основе файлов, хранящихся в /var/lib/nova/instances

Хранилища файлового уровня

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

Облака OpenStack не предоставляют конечным пользователям хранилища файлового уровня. Тем не менее, когда вы проектируете свое облако, важно предусмотреть возможность хранения на файловом уровне для хранения экземпляров в /var/lib/nova/instances при проектировании облака, так как вы должны иметь совместно используемую файловую систему, если вы хотите использовать миграцию в режиме онлайн.

Выбор сервера хранения

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

• Требуются ли моим пользователям блочные хранилища?
• Требуются ли моим пользователям хранилища объектов?
• Требуются ли мне миграция в режиме реального времени?
• Должны ли мои устройства постоянного хранения содержаться в моих вычислительных узлах, или я должен использовать внешнюю СХД?
• На какое количество пластин устройств хранения я могу рассчитывать? Даст ли лучший результат ввода/вывода большее количество шпинделей, несмотря на сетевой доступ?
• Какой результат является моей целью в выборе наилучшего соотношения стоимость- производительность?
• Как я должен управлять эксплуатацией систем хранения?
• Насколько резервируемой и распределенной является система хранения? Что произойдет в случае отказа узла хранения? В какой степени это может смягчить сценарии угрозы потери моих данных?

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

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

Помимо существующих технологий с открытым исходным кодом, существует ряд фирменных решений, которые официально поддерживаются OpenStack Block Storage. Они предлагаются в следующем списке поставщиков:

• IBM (Storwize family/SVC, XIV)
• NetApp
• Nexenta
• SolidFire

Вы можете найти матрицу функциональных возможностей, предоставляемых всеми поддерживаемыми драйверами блочных хранилищ, на OpenStack вики ( https://wiki.openstack.org/wiki/CinderSupportMatrix).

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

• Чтобы снабдить пользователей механизмом устройств постоянного хранения
• Для масштабируемых, надежных систем хранения для образов виртуальных машин

Технологии серийно выпускаемых серверов хранения

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

• OpenStack Object Storage (Swift). Официальное хранилище объектов OpenStack. Это зрелая технология, которая использовалась в течение ряда лет в практической деятельности Rackspace как технология, лежащая в основе Rackspace Cloud Files. Поскольку технология обладает высокой масштабируемостью, она хорошо подходит для управления петабайтами хранимых данных. Преимуществами хранилищ объектов OpenStack являются лучшая интеграция с OpenStack (интегрируется с OpenStack Identity, работает с интерфейсом инструментальной панели OpenStack), а также лучшая поддержка многократного развертывания центров обработки данных за счет поддержки асинхронных эпизодических непротиворечивых репликаций.
  Поэтому, если вы в конечном итоге планируете раccредоточить свой кластер хранения в нескольких центрах обработки данных и если вам нужно унифицировать учетные данные пользователей, как для вычислений, так и для объектов хранения, или, если вы хотите управлять своими хранимыми объектами через инструментальную панель OpenStack, вы должны рассмотреть OpenStack Object Storage. Более подробную информацию о OpenStack Object Storage можно найти в следующем разделе.
• Ceph. Масштабируемое решение для хранения, которое реплицирует данные между серийными узлами хранения. Ceph первоначально был разработан одним из основателей DreamHost и в настоящее время используется в данном продукте.
  Ceph был разработан, чтобы представить конечному пользователю различные типы интерфейсов хранилищ данных: он поддерживает хранение объектов, блочные хранилища и интерфейсы файловой системы, хотя интерфейс файловой системы пока не считается готовым продуктом. Для хранения объектов Ceph поддерживает тот же API, что и Swift, может использоваться в качестве сервера хранения для блочных хранилищ Cinder, а также сервера хранения для образов glance. Ceph поддерживает "Слабую инициализацию" ("Thin Provisioning"), реализованную копированием при записи.
  Он может быть полезным при загрузке с тома, поскольку новый том может быть подготовлен очень быстро. Ceph также поддерживает аутентификацию на основе keystone (начиная с версии 0.56), поэтому он может быть бесшовным обменником в реализации OpenStack Swift по умолчанию. Преимущество Ceph в том, что он предоставляет администратору более тонкое управление стратегией распределения данных и репликации, позволяет консолидировать ваши хранилище объектов и блочное хранилище, допускает очень быструю инициализацию загрузки с томов при использовании слабой инициализации, и поддерживает интерфейс распределенной файловой системы, хотя этот интерфейс пока не рекомендуется пока не рекомендуется для использования в промышленном развертывании в рамках проекта Ceph. {Прим. пер.: в текущих версиях файловая система Ceph является штатным компонентом, см. например, http://ceph.com/docs/master/cephfs/, что явно отменяет данную рекомендацию!}
  Если вы хотите управлять хранилищем объектов и блочным хранилищем в рамках одной системы, или если вы хотите поддержать быструю загрузку-с-тома, вы должны рассмотреть вариант использования Ceph.
• Gluster. Распределенная, совместно используемая файловая система. По состоянию на момент выхода версии Gluster 3.3, вы можете использовать Gluster для консолидации хранилища объектов и хранилища файлов в единое решение хранения файлов и объектов, которое называется Gluster UFO. Gluster UFO использует настраиваемую версию Swift, которая, в свою очередь, использует Gluster в качестве сервера хранения. Основное преимущество использования Gluster UFO над обычным Swift, проявляется, когда вы также хотите поддерживать распределенную файловую систему, либо поддерживать миграцию совместно используемого хранилища в реальном времени или предоставить ее в качестве отдельной услуги для ваших конечных пользователей. Если вы хотите управлять хранилищами объектов и файлов в пределах одной системы, вы должны рассмотреть использование Gluster UFO.
• LVM. Система управления логическим томами (Logical Volume Manager) на основе Linux, которая обеспечивает уровень абстракции поверх физических дисков, чтобы представлять логические тома операционной системе. Сервер LVM (Logical Volume Manager) реализует блочные хранилища как LVM логических разделов. На каждом хосте, где размещается блочное хранилище, администратор должен сначала создать группу томов, выделенную для томов блочного хранилища. Блоки создаются из логических томов LVM.
  LVM не обеспечивает никакой репликации. Как правило, администраторы настраивают RAID на узлах, использующих LVM как блочное хранилище, для защиты от сбоев отдельных жестких дисков. Однако, RAID не защищает от отказа всего хоста.
  Драйвер iSCSI Solaris для OpenStack Block Storage реализует блоки как примитивы ZFS. ZFS является файловой системой, которая также имеет функциональность диспетчера томов. Это отличает ее от системы Linux, в которой существет разделение диспетчера томов (LVM) и файловых систем (таких как, ext3, ext4, XFS, btrfs). ZFS имеет ряд преимуществ по сравнению с ext4, в том числе улучшенную проверку целостности данных.
• Sheepdog. Недавний проект, который призван обеспечить блочные хранилища для экземпляров на основе KVM при поддержке репликации между хостами. Мы не рекомендуем Sheepdog для производства облака, поскольку ее авторы в NTT Labs рассматривают Sheepdog в качестве экспериментальной технологии.
• Прим. пер.: GPFS - коммерческая файловая система, поддерживаемая OpenStack начиная с редакции Havana (17 октября 2013). Данная файловая система предоставляет поддержку всех типов хранилищ при наличии собственных систем обеспечения надежности, отказоустойчивости, масштабируемости хранимых объемов и пропускной способности, при совместимости с большим спектром серийно выпускаемого оборудования различных производителей и гарантированном сопровождении и поддержке производителем самой GPFS (IBM) При наличии требований уровня критических приложений или доступности бюджетных средств, рекомендуем обратить внимание на данный продукт.

Замечания по OpenStack Object Storage

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

Хороший документ, описывающий архитектуру объектного хранилища находится в документации разработчика ( http://docs.openstack.org/developer/swift/overview_architecture.html) - для начала ознакомьтесь с ним. После того, как вы представили себе архитектуру, вы должны понять, что делает прокси-сервер и как работают зоны. Тем не менее, обозначим некоторые существующие важные моменты, которые часто упускаются при первом ознакомлении.

При проектировании кластера, необходимо учитывать долговечность и доступность. Поймите, что их основным источником является распределение и расположение ваших данных, а не надежность оборудования. Рассмотрим значение по умолчанию количества копий, равное 3. Это означает, что, перед тем, как объект будет помечен успешно записанным, существуют. По крайней мере, две копии - в случае отказа при записи на одном сервере, третий экземпляр может существовать или пока еще нет, в то время как начально возвращена операция записи. Изменение этого числа увеличивает надежность ваших данных, но уменьшает объем имеющейся у вас памяти. Далее обратим внимание на размещение серверов. Рассмотрим их распределение по всей сети и зонам отказа электропитания вашего центра обработки данных. Является зона стойкой, сервером или диском?

На первый взгляд сетевые структуры хранилища объектов могут показаться непривычными. Рассмотрим эти основные потоки трафика.

• Среди объектов, контейнеров и серверов учетных записей
• Между этими серверами и прокси
• Между прокси и вашими пользователями

Хранилище объектов очень 'болтливое' среди всех серверов, хранящих данные - даже небольшой кластер делает трафик, измеряемый мегабайтами в секунду, причем он преимущественно состоит из "У вас есть объект" / "Да у меня есть объект!". Конечно, если ответ на вышеупомянутой вопрос отрицательный или истекает время ожидания, начинается репликация объекта.

Рассмотрим ситуацию, когда отказывает весь сервер, и 24ТБ данных должно быть передано "немедленно", чтобы остаться в трех экземплярах - это может составить значительную нагрузку для сети.

Другой часто забываемый факт заключается в том, что когда загружаем новый файл, прокси-сервер должен записать столько потоков, сколько существует реплик - порождая кратное умножение сетевого трафика. Для кластера c 3-мя репликами, 10Гбит в секунду означает порождение 30Гбит в секунду. Объединяя это с предыдущими высокими запросами пропускной способности репликаций порождает в результате рекомендацию необходимости для вашей локальной сети значительно более высокой пропускной способности, того требует сеть общего полбзования. Oh и OpenStack Object Storage взаимодействуют внутри с использованием не зашифрованного, без аутентификации протокола rsync для получения производительности - вам действительно нужна собственная сеть, чтобы быть приватной.

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

Дополнительные прокси означают более высокую пропускную способность, если это позволяет хранилище.

Глава 4	Оглавление	Глава 6
Перевод: Copyright © 2014  . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru