Особенности планирования СХД для платформы OpenStack
TADетали

Актуальность проблемы

Сегодня затраты на системы хранения данных (СХД) – это существенная часть бюджетов многих крупных российских компаний. Несмотря на медленно снижающуюся стоимость хранения данных, их количество растет быстрыми темпами. Так по прогнозам компании Oracle, к 2020 году ИТ-департаменты будут вынуждены управлять инфраструктурами, имеющими в 50 раз больше данных, в 75 раз больше файлов, но при наличии всего в 1,5 раза больше людей.

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

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

СХД в OpenStack

Хранение данных используется во многих компонентах OpenStack:

• OpenStack Glance – хранение образов VM
• OpenStack Nova – эфемерные диски VM
• OpenStack Cinder – постоянные диски
• OpenStack Swift – хранение объектов
• OpenStack Manila – файловая система совместного доступа

Любая гостевая ОС использует блочное устройство для размещения файловых систем. Выделяются «эфемерное» и постоянное хранение данных.

«Эфемерные» диски существуют до тех пор, пока существует VM (при его удалении, эфемерный диск удаляется). Это, как правило, корневые диски с операционной системой, диски для подкачки (swap). При развертывании только OpenStack Nova, пользователи платформы не имеют доступа к какой-либо форме постоянного хранения по умолчанию. Связанные с VМ «эфемерные» диски, с точки зрения пользователя, исчезают, когда виртуальная машина была удалена. Постоянные блочные устройства не удаляются вместе с виртуальным сервером и могут быть подключены к другому серверу при необходимости. Разумеется, доступны операции для создания и удаления таких устройств, а также управления подключениями. Таблица ниже даёт сравнительный анализ доступных компонентов хранения данных в OpenStack

Возможные сценарии

На диаграмме ниже отображены результаты опроса пользователей OpenStack (октябрь 2015г.): какие низкоуровневые реализации используются ими для хранения постоянных дисков.

OpenStack Nova: Локальная файловая система на гипервизорах

Стандартная и соответствующая идеологии OpenStack архитектура предполагает использование локальной файловой системы на гипервизорах для размещения эфемерных дисков виртуальных серверов (например, в RDO OpenStack это /var/lib/nova/instances). Этот подход обеспечивает локализацию операций ввода/вывода, высокие показатели масштабирования и возможность использования QCOW2 Copy on Write клонов для эффективного использования дискового пространства на файловой системе (в клоне реальное место занимают только изменившиеся от базового образа блоки данных). Также локальная файловая система позволяет эффективно использовать стандартные механизмы кеширования файловых систем. Очевидным недостатком подхода является факт, что при недоступности гипервизора не будет возможности запустить копию виртуальной машины на другом гипервизоре, так как диски находятся локально и недоступны для других хостов.Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft 2.1 т

Поскольку этот вариант не требует покупки/построения выделенной системы хранения данных, то можно сказать, что это один из самых дешевых способов хранить диски VM для OpenStack.

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

OpenStack Nova: Linux LVM

При использовании LVM с OpenStack Nova, эфемерные диски виртуальных серверов создаются локально на гипервизорах. Диск выглядит, как логический том (logical volume) в заранее заданной дисковой группе LVM (volume group). При запуске копии VM, OpenStack создаёт логический том и заливает в него данные из образа. Преимуществом этого решения так же является высокая масштабируемость и локализация операций ввода вывода.

Для данного варианта СХД также применимы описанные выше сценарии.

OpenStack Cinder: Linux LVM

Связка LVM+iSCSI для OpenStack Сinder является референсной. Блочные устройства нарезаются как логические тома LVM, а затем экспортируются по протоколу iSCSI до гипервизора, который пробрасывает блочное устройство в VM. Разумеется, из-за локального размещения данных при недоступности ноды хранения, размещающей диск Cinder, данные будут недоступны. Несмотря на очевидные недостатки, архитекторы ICL Services отмечают, что данный сценарий лучше всего подходит для знакомства с платформой OpenStack и для реализации некритичных сервисов.

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

OpenStack Nova: файловая система совместного доступа

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

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

Распределенное хранилище Ceph

Это один из самых популярных способов построения СХД для платформы OpenStack – более трети всех инсталляций по всему миру.

Ceph хранит данные в виде объектов на локальных дисках серверов, объединяя их в пулы данных. Отказоустойчивость обеспечивается избыточностью хранения. Уровень отказоустойчивости настраивается, и как правило, составляет 3 копии для каждого объекта, которые распределены по разным серверам. Ceph обладает очень высоким уровнем масштабирования, но накладывает высокие требования на пропускную способность сетей передачи данных и имеет некоторые требования к CPU, поскольку алгоритм псевдослучайного распределения данных CRUSH вычисляет расположение объекта при каждом обращении. Не рекомендуется совмещение клиента Ceph (гипервизор) с нодами хранения.

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

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

Интеграция с СХД уровня предприятия

OpenStack Cinder имеет гибкие возможности интеграции с большим числом промышленных СХД: продукты EMC, IBM, HP и т.д. При запросе на создание диска OpenStack выполняет требуемые действия на СХД через API интеграции, что приводит к созданию блочного устройства на стороне СХД. Таким образом, OpenStack выступает своего рода высокоуровневой прослойкой между используемыми низкоуровневыми компонентами и пользователем. Возможно обеспечить интеграцию с большим числом СХД, но в интерфейсе пользователя все операции унифицированы. Всю сложность интеграции OpenStack берет на себя.

Этот подход позволяет использовать всю эффективность и производительность промышленных СХД, а также задействовать FC в качестве транспортной сети. Данный вариант может позволить создавать отказоустойчивые и производительные системы.

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

Amazon S3 совместимое объектное хранилище Swift позволяет хранить объекты пользователей (файлы, резервные копии и тп). Отказоустойчивость, как в Ceph, обеспечивается наличием копий данных, распределенных по файловым системам разных серверов. Стандартная конфигурация предусматривает использование локальных файловых системах нод хранения. Кроме того, Swift может использовать в качестве GlusterFS. Возможна интеграция с OpenStack Glance, что позволяет хранить образы виртуальных серверов в Swift.

Выводы

OpenStack позволяет строить географически распределённую инфраструктуру, а так же задействовать одновременно большое количество СХД. Как пример, одна зона доступности использует Ceph как основное СХД, вторая – EMC, третья – локальную файловую систему. Пользователь в зависимости от потребностей может выбирать зону доступности, что автоматически будет иметь влияние на то, какие СХД будут задействованы для копий VM.

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