Хранилища находятся во многих частях стека OpenStack и различные типы могут привести к путанице даже у искушенных инженеров, работающих с облаками. В данном разделе рассматриваются параметры устройств постоянного хранения, которые вы можете настраивать в своем облаке. Важно понимать разницу между эфемерным хранилищем и постоянным хранилищем.
При развертывании только вычислительных служб OpenStack (nova), ваши пользователи не имеют доступа к какой- либо постоянной системе хранения по умолчанию. Диски, связанные с виртуальными машинами "эфемерные", что означает (с точки зрения пользователя), что они эффективно исчезают после завершения работы виртуальной машины.
Постоянное хранилище означает, что данный хранимый ресурс останется после завершения любого другого ресурса и всегда является доступным, вне зависимости от состояния выполняемого экземпляра.
На сегодняшний день облака OpenStack в явном виде поддерживают два вида постоянных хранилищ: объектные хранилища и блочные хранилища.
При помощи хранилища объектов пользователи получают доступ к двоичным объектам через REST API. Вы можете быть знакомы с Amazon S3, который является широко известным примером системы хранения объектов. В OpenStack хранилище объектов реализуется в рамках проекта OpenStack Object Storage (swift) Если у ваших пользователей существует необходимость архивирования или управления большими наборами данных, значит вы хотите предоставить им хранилище объектов. Помимо этого, OpenStack может хранить образы ваших виртуальных машин (ВМ) внутри системы хранения объектов, как альтернатива хранению образов в файловой системе.
Хранилище объектов OpenStack предоставляет решение хранения с высокой масштабируемостью и высокой доступностью ослабляя некоторые ограничения традиционных файловых систем. При проектировании и приобретении такого кластера важно понять некоторые основные концепции о его работе. По существу, этот тип хранения построен на идее, что любое оборудование хранение подвержено сбоям, причем в какой-то момент это происходит на любом уровне. Редко происходящие отказы, которые ставят подножку другим системам хранения, например, проблемы выхода из строя RAID контроллеров или целых серверов великолепно обрабатываются хранилищем объектов OpenStack.
Хорошая документация, описывающая архитектуру хранилища объектов может быть найдена в документации разработчика— прочтите ее для начала. { Прим. пер.: у нас на сайте присутствует в свободном доступе перевод книги коллектива авторов "Реализация облачного хранилища с OpenStack Swift" (Проектирование, реализация и успешное управление вашим собственным кластером облачного хранилища с использованием популярного программного обеспечения OpenStack Swift. Кападиа Амар, Варма Средхар, Раджана Крис.), 978-1782168058} После того, как вы поймете архитектуру, вам необходимо будет разобраться с тем, что делают серверы прокси и как работают зоны. Однако некоторые важные моменты упускаются при первом беглом ознакомлении.
При проектировании кластера необходимо учитывать надежность и доступность. Осознайте, что их основным источником являются распределение размещение ваших данных, а не надежность оборудования.Рассмотрим значение по умолчанию для реплик, которое равно трем. Это означает, что прежде чем объект будет помечен как записанный, по крайней мере две копии существуют — в случае отказа на запись одного сервера, третья копия может присутствовать или еще не существовать при начальном возврате операции записи. Изменение данного значения повышает надежность хранения данных, но уменьшает имеющийся у вас объем хранилища. Далее, ознакомьтесь с размещением серверов. Проанализируйте их распространение по всем своим центрам обработки данных, и зонам отказоустойчивости энергоснабжения. Является ли зоной стойка, сервер или диск?
Сетевые модели хранилищ объектов могут показаться необычными на первый взгляд. Рассмотрим эти основные транспортные потоки:
-
Между объектами, контейнерами, и серверами учетных записей
-
Между этими серверами и серверами прокси
-
Между серверами прокси и вашими пользователями
Хранилища объектов очень "разговорчивые" по сравнению с остальными серверами, размещающими данные, даже небольшой кластер производит обем, измеряемый мегабайтами в секунду, причем он преимущественно такой: “У вас есть оъект?”/“Да, у меня есть объект!” Разумеется, если ответ на приведенный вопрос отрицательный или вышло время ожидания ответа, начинается репликация объекта.
Рассмотрим ситуацию, при которой отказывает сервер целиком и 24ТБайт данных необходимо переслать "немедленно" для сохранения трех экземпляров — это может предоставить значительную загруженность сети.
Другой факт, о котором часто забывают, это то, что когда загружается новый файл, сервер прокси должен записывать столько потоков, сколько установлено реплик — умножая сетевой обмен. Для кластера с тремя репликами, 10 Gbps означет 30 Gbps выход. В комбинации с предыдущими запросами высокой пропускной способности для репликаций это приводит к рекомендации, чтобы ваша частная сеть должна обеспечивать гораздо более высокую пропускную способность чем существуют потребности у вашей общедоступной сети. О! к тому же хранилища объектов OpenStack взаимодействуют внутри незашифрованным без авторизации протоколом rsync для целей производительности— вы действительно хотите, чтобы частная сеть была приватной.
Оставшийся пункт полосы пропускания это общедоступная часть.
Службы swift-proxy не сохраняет состояние, что означает,
что вы легко можете добавить дополнительные методы балансировки HTTP для
совместного использования полосы пропускания между ними.
БОльшее число серверов прокси означает бОльшую полосу пропускания, если ваше хранилище поспевает за ними.
Блочные хранилища (иногда называемые хранилищами томов) предоставляют для пользователя блочные устройства. Пользователи взаимодействуют с блочными хранилищами путем присоединения томов к своим работающим экземплярам виртуальных машин.
Эти тома являются постоянными: они могут быть отделены от одного экземпляра и повторно подключены к другому, причем данные остаются не поврежденными. Блочные хранилища реализуются в OpenStack проектом блочных хранилищ OpenStack (Cinder), который поддерживает множество серверов хранения в форме драйверов устройств. Выбранный вами сервер хранения должен поддерживаться устройством блочного хранилища.
Большинство устройств блочного хранилища позволяют экземпляру осуществлять прямой доступ к аппаратным средствам устройства блочной системы хранения. Это помогает увеличить общую производительность чтения/записи системы ввода/вывода.
В редакции 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.
Таблица 6.1, “Хранилища OpenStack” объясняет различные хранилища OpenStack concepts provided by OpenStack.
| Эфемерное хранилище | Блочное хранилище | Хранилище объектов | |
|---|---|---|---|
Используется для… |
Работы операционной системы и рабочей области |
Добавляет дополнительные устройства постоянного хранения виртуальным машинам (ВМ) |
Хранит данные, включающие образы ВМ |
Доступ через… |
Файловую систему |
блочные устройства которые могут разбиваться на разделы, подвергаться форматированию и монтироваться (такие как /dev/vdc) |
REST API |
Доступны из… |
В пределах ВМ |
В пределах ВМ |
Где угодно |
Управляется… |
OpenStack Compute (nova) |
OpenStack Block Storage (cinder) |
OpenStack Object Storage (swift) |
Существует до… |
Останова ВМ |
Удаляется пользователем |
Удаляется пользователем |
Размеры устанавливаются… |
Установками администратором настроек размеров, известных как предпочтения (flavor) |
Описываются пользователем в начальном запросе |
Размером доступного физического хранилища |
Пример типичного применения… |
10 ГБ первый диск, 30 ГБ второй диск |
1 ТБ диск |
10-ки ТБ-ов наборов хранимых данных |
Пользователи будут указывать различные потребности для своих случаев использования. Некоторым, возможно, потребуется быстрый доступ ко многим объектам, которые не очень часто изменяются, или вы захотите установить на файл значение времени жизни(TTL). Другим может потребоваться доступ только к хранилищу, смонтированному в пределах самой файловой системы, однако требующего мгновенной репликации при запуске нового экземпляра. Для других систем, эфемерное хранилище — хранилище, которое высвобождается, когда прекращается выполнение подключенной к нему виртуальной машщины — является предпочтительным вариантом. Когда вы выбираете сервер храненияs, , задайте себе следующие вопросы от имени пользователей:
-
Требуются ли моим пользователям блочные хранилища?
-
Требуются ли моим пользователям хранилища объектов?
-
Требуются ли мне поддержка миграции в режиме реального времени?
-
Должны ли мои устройства постоянного хранения содержаться в моих вычислительных узлах, или я должен использовать внешнюю СХД?
-
На какое количество пластин устройств хранения я могу рассчитывать? Даст ли лучший результат ввода/вывода большее количество шпинделей, несмотря на сетевой доступ?
-
Какой результат является моей целью в выборе наилучшего соотношения стоимость- производительность?
-
Как я должен управлять эксплуатацией систем хранения?
-
Насколько резервируемой и распределенной является система хранения? Что произойдет в случае отказа узла хранения? В какой степени это может смягчить сценарии угрозы потери моих данных?
Для развертывания вашей системы хранения с использованием серийных аппаратных средств, вы можете использовать ряд пакетов с открытым исходным кодом, что демонстрируется в следующей : Таблице 6.2, “Поддержка постоянных хранилищ на основе файлов”.
| Объекты | Блоки | Файловый уровень[a] | |||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Swift |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
LVM |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||
Ceph |
|
|
экспериментально |
||||||||||||||||||||||||||||||||||||||||||||||
Gluster |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||
NFS |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
ZFS |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||
Sheepdog |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
[a] Данный список решений хранения совместно используемых данных на файловом уровне с открытым исходным кодом не является исчерпывающим; существуют и другие решения с открытым исходным кодом (MooseFS). Возможно, ваша организация уже развернула решение хранения совместно используемых данных файлового уровня, которое можно использовать. | |||||||||||||||||||||||||||||||||||||||||||||||||
Кроме того, вы должны решить: хотите ли вы поддерживать в своем облаке хранилище объектов. Двумя общими случаями использования для поддержки хранилищ объектов в компьютерном облаке являются:
-
Обеспечение пользователей механизмом устройств постоянного хранения
-
Для масштабируемых, надежных систем хранения для образов виртуальных машин
В данном разделе приводится общий анализ отличий между различными технологиями серийных серверов хранения. В зависимости от потребностей ваших пользователей облака, вы можете реализовать одну или несколько из этих технологий в различных комбинациях:
- Хранилище объектов OpenStack (swift)
-
Официальное хранилище объектов OpenStack. Это зрелая технология, которая использовалась в течение ряда лет в практической деятельности Rackspace как технология, лежащая в основе Rackspace Cloud Files. Поскольку технология обладает высокой масштабируемостью, она хорошо подходит для управления петабайтами хранимых данных. Преимуществами хранилищ объектов OpenStack являются лучшая интеграция с OpenStack (интегрируется с OpenStack Identity, работает с интерфейсом инструментальной панели OpenStack), а также лучшая поддержка многократного развертывания центров обработки данных за счет поддержки асинхронных эпизодических непротиворечивых репликаций.
Поэтому, если вы в конечном итоге планируете раccредоточить свой кластер хранения в нескольких центрах обработки данных и если вам нужно унифицировать учетные данные пользователей, как для вычислений, так и для объектов хранения, или, если вы хотите управлять своими хранимыми объектами через инструментальную панель OpenStack, вы должны рассмотреть хранилище объектов OpenStack. Более подробную информацию о хранилище объектов OpenStack можно найти в разделе Хранилище объектов (исправлено переводчиком).
- 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 For OpenStack (GFO). GFO использует настраиваемую версию Swift, которая, в свою очередь, использует Gluster в качестве сервера хранения.
Основное преимущество использования GFO над обычным swift, проявляется, когда вы также хотите поддерживать распределенную файловую систему, либо для поддержки миграции совместно используемого хранилища в реальном времени или предоставить ее в качестве отдельной услуги для ваших конечных пользователей. Если вы хотите управлять хранилищами объектов и файлов в пределах одной системы, вы должны рассмотреть использование GFO.
- LVM
-
Cистема управления логическим томами (Logical Volume Manager) на основе Linux, которая обеспечивает уровень абстракции поверх физических дисков, чтобы представлять логические тома операционной системе. Сервер LVM (Logical Volume Manager) реализует блочные хранилища как LVM логических разделов.
На каждом хосте, где размещается блочное хранилище, администратор должен сначала создать группу томов, выделенную для томов блочного хранилища. Блоки создаются из логических томов LVM.
![[Замечание]](../common/images/admon/note.png)
Замечание LVM не обеспечивает никакой репликации. Как правило, администраторы настраивают RAID на узлах, использующих LVM как блочное хранилище, для защиты от сбоев отдельных жестких дисков. Однако, RAID не защищает от отказа всего хоста.
- ZFS
-
Драйвер iSCSI Solaris для блочного хранилища OpenStack реализует блоки как примитивы ZFS. ZFS является файловой системой, которая также имеет функциональность диспетчера томов. Это отличает ее от системы Linux, в которой существует разделение диспетчера томов (LVM) и файловых систем (таких как, ext3, ext4, XFS, btrfs). ZFS имеет ряд преимуществ по сравнению с ext4, в том числе улучшенную проверку целостности данных.
Сервера ZFS для блочных хранилищ OpenStack поддерживают только основанные на Solaris системы, такие как Illumos. Хотя и существует портация ZFS для Linux, она не содержится ни в каких стандартных дистрибутивах, а также не была протестирована с блочным хранилищем OpenStack. Как и LVM, ZFS не обеспечивает репликацию по хостам самостоятельно; вам требуется добавить решение по репликации поверх ZFS если ваше облако нуждается в возможности обработки отказов узлов хранения.
Мы не рекомендуем ZFS, если у вас нет опыта работы с ее развертыванием, поскольку сервера ZFS для блочных хранилищ требуют операционную систему на основе Solaris, а мы предполагаем, что ваш опыт, прежде всего, базируется на системах Linux.
- {Прим. пер.: GPFS
-
коммерческая файловая система, поддерживаемая OpenStack начиная с редакции Havana (17 октября 2013). Данная файловая система предоставляет поддержку всех типов хранилищ при наличии собственных систем обеспечения надежности, отказоустойчивости, масштабируемости хранимых объемов и пропускной способности, при совместимости с большим спектром серийно выпускаемого оборудования различных производителей и гарантированном сопровождении и поддержке производителем самой GPFS (IBM) При наличии требований уровня критических приложений или доступности бюджетных средств, рекомендуем обратить внимание на данный продукт. }
Мы надеемся, что теперь у вас есть некие соображения анализа и вопросы, которые вы зададите своим будущим пользователям облака об их вариантах использования хранилищ. Как вы можете увидеть, ваши решения по хранилищам будут также влиять на проект вашей сети в отношении требований производительности и безопасности. ПРодолжите изучение с нами для принятия более обоснованных решений по проекту вашего облака OpenStack.