Данная статья подготовлена Артемом Демариным, экспертом Отдела систем хранения данных компании «Инфосистемы Джет»
Сегодня многие отдают предпочтение услугам VoD (Video on Demand), вместо того, чтобы идти в кино. Либо вместо посещения кафе заказывают еду на дом. Потребление ресурсов в виде услуг является уже чем-то обыденным и само собой разумеющимся.
Постепенно этот подход стал применяться и к ИТ-инфраструктуре/ИТ-сервисам. Создание ресурсов по запросу стало возможным благодаря активному использованию систем серверной виртуализации, которые позволили абстрагироваться от фиксированных конфигураций. На первичном этапе это дало возможность рассматривать ИТ-инфраструктуру и ИТ-сервисы как услуги, но всё еще не обеспечивало нужной гибкости и динамичности для удовлетворения пользовательских запросов. Для решения данной задачи была разработана концепция программно-определяемого ЦОД (Software Defined Datacenter, SDDC), которая предусматривает абстрагирование от аппаратной части абсолютно всех компонентов ЦОД.
Подход этот возник не вчера, однако его воплощение в жизнь затрудняют несколько факторов. Самый главный – инфраструктура хранения данных. В отличие от приложений, серверов и сети, ресурсы хранения, а вместе с ними данные продуктивных систем, зачастую оказываются привязанными к уникальному оборудованию различных производителей.
Исторически каждый вендор создавал свой продукт на базе доступных ему аппаратных платформ и ОС или разрабатывал абсолютно новый комплекс со своими программными интерфейсами (API) и уникальным набором функций. В итоге среди платформ и продуктов царит такое разнообразие, что даже массивы одного производителя могут быть несовместимы между собой (нет возможности для полного или частичного взаимодействия, например, для репликации).
Значительное повышение вычислительной мощности x86 серверов, и активное использование облачных технологий стали почвой для развития программно-ориентированных СХД (Software-Defined Storage, SDS). За функции хранения и управления данными в этих решениях отвечает ПО на базе стандартных компонентов вычислительных сред (серверов, дисковых полок расширения, коммутаторов, контроллеров и т.д.). Главная их особенность – отсутствие специализированных аппаратных средств, обеспечивающих реализацию отдельных функций. На сегодня можно выделить несколько классов программно-ориентированных СХД:
Данная классификация весьма условна – часто продукты реализуют функции, относящиеся к нескольким классам.
Концепция SDDC подразумевает упрощение ИТ-инфраструктуры за счет применения более однородных вычислительных компонентов и назначения им ролей на уровне ПО. При этом допускается как выделение компонентов под роль, так и совмещение нескольких ролей на одном наборе оборудования.
Рис. 1. Верхнеуровневое сравнение традиционной и программно-ориентированной архитектур хранения
В последние 7–10 лет производители классических массивов начали добавлять SDS-решения в свои портфели. В большинстве своем они повторяют классические СХД: обеспечивают доступ к данным по стандартным протоколам (FC, iSCSI, IB, FCoE, CIFS, NFS) и схожий функционал (динамическое управление ресурсами, репликация, мгновенные снимки, клоны и т.д.).
Очевидно, что SDS-системы, повторяющие архитектуру классических массивов, имеют те же технические ограничения: фиксированное число контроллеров (нод), интерфейсных портов взаимодействия и накопителей (жестких дисков, SSD). Однако переход к концепции программного определения сделал возможным применение технологий, которые раньше были доступны только в сложных Hi-End (например, виртуализация внешних дисковых ресурсов). За счет включения продуктов SDS в стек решений базового и среднего уровня вендоры существенно нарастили функционал в этих сегментах.
Самыми популярными на сегодня являются SDS-решения с объектным принципом хранения данных. Их основные потребители – крупные и средние провайдеры услуг облачного хранения: Dropbox, Apple, Amazon, Google и др. В случае частных облаков объектный подход гарантирует унификацию вычислительных компонентов и динамическое расширение инфраструктуры за счет добавления универсальных новых нод (серверов), которые могут обеспечивать сервис хранения одновременно с другими ролями.
Объектный принцип предусматривает хранение множества копий частей массива данных – так называемых объектов (классические же решения отвечают за гарантированное хранение всего массива данных – в рамках одного ресурса). Сохранность данных обеспечивается при доступности хотя бы одного экземпляра из множества. Применение объектного хранения сделало возможным резервирование данных в зависимости от места расположения компонентов SDS. Например, можно дублировать объекты на ресурсах разных узлов (серверов – участников SDS), размещенных в разных стойках ЦОД. В этом случае допустима потеря части компонентов при условии сохранения одной или более копий каждого из объектов.
Объектный принцип дает куда большую масштабируемость и гибкость в управлении ресурсами. Первое обеспечивается применением множества равноправных нод. В результате эта характеристика меньше зависит от ограничений аппаратных компонентов, чего не скажешь о классических массивах. Гибкость управления ресурсами достигается за счет применения динамических алгоритмов распределения и хранения объектов: можно оперативно изменять принципы хранения в зависимости от бизнес-требований.
Основной недостаток объектных хранилищ – необходимость иметь N-кратный объем ресурсов (где N – число хранимых копий объектов и, соответственно, уровень защиты данных) и осуществлять доступ к данным по объектным протоколам (S3, Rest API). Впрочем, затраты на избыточный объем возмещаются за счет использования компонентов массового производства (серверов, жестких дисков, коммутационного оборудования), которые существенно дешевле специализированных аппаратных решений, выпускаемых малыми партиями. Проблема с протоколами доступа к данным стоит острее: большая часть бизнес-приложений и прикладного ПО на текущий момент не имеют поддержки объектных протоколов. При этом доработка либо замена используемого ПО за приемлемое время и вменяемые деньги очень часто невозможна. В связи с этим основные SDS-продукты на данный момент имеют отдельный компонент (роль) для предоставления ресурсов по классическим протоколам (iSCSI, NFS, CIFS).
В большинстве случаев применение объектных или основанных на них СХД в отличие от классических или подобных им массивов требуют более детальной проработки и оценки возможностей решения. Это связано с совершенно другим подходом к организации инфраструктуры, резервированию данных (РК) и комплекса в целом (Disaster Recovery, DR). Ошибки, допущенные в этом месте, могут дорого обойтись. Одно из возможных последствий – отсутствие постоянной производительности. В зависимости от используемых алгоритмов распределения и кеширования данных может наступить ситуация, когда будет производиться обращение не к локальным ресурсам, а к другим узлам (членам группы хранения единого набора данных) по внутренней сети – Ethernet, InfiniBand, WAN. На рис. 2 показан пример подобного колебания производительности.
Рис. 2. График возможной многонодовой производительности SDS-решения
Красная линия отражает время отклика при выполнении операций ввода/вывода. Пиковые значения приходятся на выполнение операций на удаленном узле. Увеличение времени отклика напрямую влияет на производительность операций (чем это время больше, там меньше операций можно выполнить за определённый период). Из примера видно, что задержка на выполнение удаленных операций не постоянна и может стать причиной значительного снижения общей производительности. Чем продолжительнее выполнение операций на удаленном узле, тем больше будет влияние на суммарную производительность.
Чтобы минимизировать влияние этой особенности многоузловых SDS на продуктивные среды, нужно провести предварительную глубокую проработку конфигурации и оценку принципиальной возможности ее применения.
Основные области и решения, в которых началось активное применение технологий SDS:
Программно-определяемые системы хранения – наиболее гибкие и динамично развивающиеся технологии в группе решений по хранению данных. Применяемые в них алгоритмы позволяют уменьшить используемые компоненты и суммарную стоимость решений. В качестве примера – задача по построению среды хранения. Компания имеет 3 дата-центра в пределах одного города, соединенные IP-каналами достаточной пропускной способности. Требования к ресурсам хранения следующие:
Решить эту задачу с помощью классических дисковых массивов в полной мере не получится. На сегодня существуют системы, которые обеспечивают одновременный доступ (на чтение/запись) только с 2 технологических площадок (например, HDS G1000 GAD) либо из всех ЦОДов к единому хранилищу, расположенному в одном из дата-центров и резервируемому в других. Условное решение – организация ресурсов хранения с делением на сегменты по площадкам и резервированием этих сегментов между ЦОДами. Пример данной реализации представлен на рис. 3.
Рис. 3. Обобщенная схема решения с применением классических массивов
Реализация такого подхода требует не менее 200 ТБ суммарной полезной емкости для организации хранения и резервирования и ограничивает локальный полный (чтение/запись) доступ объемом локального сегмента. Доступ на запись в удаленные сегменты должен будет осуществляться через каналы связи между площадками. Таким образом, требуется обеспечить работу прикладного ПО с 3 независимыми сегментами данных.
Теперь рассмотрим вариант использования SDS-систем с объектным доступом. В этом случае возможно построение единого хранилища данных с расположением компонентов (узлов) на 3 площадках. Динамические алгоритмы хранения дают возможность обеспечить хранение не менее 1 копии на каждой площадке, что гарантирует сохранность данных при потере до 2 из 3 ЦОДов. Данный подход, как и в случае с классическим массивом, требует хранения 3-кратного объема, но применение недорогих компонентов снижает TCO аппаратной части.
Иногда нет возможности разместить в каждом ЦОДе полный объем требуемого оборудования (из-за отсутствия места, недостатка ресурсов электропитания, охлаждения и т.д.). Выход – SDS-решения с уникальными (более сложными) алгоритмами распределения данных, например Quantum Lattus: хранение данных тут производится совместно с хранением сервисной информации для их восстановления. Схожее решение – RAID 5 или 6 с применением данных четности для восстановления массива. Главное отличие Quantum Lattus от классического RAID – возможность регулирования уровня сервисной информации. За счет этого можно задавать необходимый уровень сохранности данных при выходе из строя определенного количества компонентов. Например, можно задать потерю всех компонентов одной из технологических площадок, в данном случае требуемый объем хранения для обеспечения 100 ТБ полезной емкости составляет ~164 ТБ.
Рис. 4. Обобщенная схема решения с применением SDS
Решение позволяет минимизировать емкость для обеспечения хранения данных, но в то же время накладывает более жесткие требования к доступности, пропускной способности каналов связи между площадками и набору ПО СРК и архивирования данных (необходимо наличие возможности работы с объектными системами хранения).
Развитие и использование программно-ориентированных СХД следует рассматривать как наиболее перспективное направление в индустрии хранения. Реальное применение SDS сегодня ограничено рядом факторов, но наращивание их функционала и постепенное увеличение стабильности и прогнозируемости работы компонентов позволит со временем рассматривать SDS в качестве основных систем хранения для большинства областей.
Основное ограничение в использовании объектных SDS – неготовность ПО. В большинстве случаев в крупных программных продуктах запаздывает реализация новых функций, а зачастую она невозможна архитектурно.
Остается надеяться, что столкновения «в лоб» новых программных и классических продуктов не будет. Наилучшим вариантом может стать плавная смена решений, либо модель, при которой оба вида займут свои ниши и не будут сильно конкурировать. Мы же можем занять место в кругу защитников той или иной технологии либо наблюдать со стороны, применяя для своих задач всё лучшее от них обеих.
Мы будем рады вашим конструктивным комментариям.
Сегодня многие отдают предпочтение услугам VoD (Video on Demand), вместо того, чтобы идти в кино. Либо вместо посещения кафе заказывают еду на дом. Потребление ресурсов в виде услуг является уже чем-то обыденным и само собой разумеющимся.
Постепенно этот подход стал применяться и к ИТ-инфраструктуре/ИТ-сервисам. Создание ресурсов по запросу стало возможным благодаря активному использованию систем серверной виртуализации, которые позволили абстрагироваться от фиксированных конфигураций. На первичном этапе это дало возможность рассматривать ИТ-инфраструктуру и ИТ-сервисы как услуги, но всё еще не обеспечивало нужной гибкости и динамичности для удовлетворения пользовательских запросов. Для решения данной задачи была разработана концепция программно-определяемого ЦОД (Software Defined Datacenter, SDDC), которая предусматривает абстрагирование от аппаратной части абсолютно всех компонентов ЦОД.
Подход этот возник не вчера, однако его воплощение в жизнь затрудняют несколько факторов. Самый главный – инфраструктура хранения данных. В отличие от приложений, серверов и сети, ресурсы хранения, а вместе с ними данные продуктивных систем, зачастую оказываются привязанными к уникальному оборудованию различных производителей.
Исторически каждый вендор создавал свой продукт на базе доступных ему аппаратных платформ и ОС или разрабатывал абсолютно новый комплекс со своими программными интерфейсами (API) и уникальным набором функций. В итоге среди платформ и продуктов царит такое разнообразие, что даже массивы одного производителя могут быть несовместимы между собой (нет возможности для полного или частичного взаимодействия, например, для репликации).
Значительное повышение вычислительной мощности x86 серверов, и активное использование облачных технологий стали почвой для развития программно-ориентированных СХД (Software-Defined Storage, SDS). За функции хранения и управления данными в этих решениях отвечает ПО на базе стандартных компонентов вычислительных сред (серверов, дисковых полок расширения, коммутаторов, контроллеров и т.д.). Главная их особенность – отсутствие специализированных аппаратных средств, обеспечивающих реализацию отдельных функций. На сегодня можно выделить несколько классов программно-ориентированных СХД:
- программно-аппаратные решения, повторяющие архитектуру классических массивов (EMC XtremIO, IBM FlashSystems и т.д.);
- независимое ПО для построения решений на базе x86 серверов (EMC ScaleIO, pNFS, RAIDIX, EuroNAS, Open-E и т.д.);
- объектные хранилища данных (Gluster, OpenStack Swift, Ceph, EMC Atmos, HDS HCP, Quantum Lattus, EMC ViPR и т.д.);
- Hadoop-совместимые хранилища (Apache Hadoop HDFS-совместимые решения);
- системы виртуализации дисковых ресурсов (EMC ViPR, IBM SVC, Huawei VIS и т.д.).
Данная классификация весьма условна – часто продукты реализуют функции, относящиеся к нескольким классам.
Концепция SDDC подразумевает упрощение ИТ-инфраструктуры за счет применения более однородных вычислительных компонентов и назначения им ролей на уровне ПО. При этом допускается как выделение компонентов под роль, так и совмещение нескольких ролей на одном наборе оборудования.
Рис. 1. Верхнеуровневое сравнение традиционной и программно-ориентированной архитектур хранения
Объектное хранение
В последние 7–10 лет производители классических массивов начали добавлять SDS-решения в свои портфели. В большинстве своем они повторяют классические СХД: обеспечивают доступ к данным по стандартным протоколам (FC, iSCSI, IB, FCoE, CIFS, NFS) и схожий функционал (динамическое управление ресурсами, репликация, мгновенные снимки, клоны и т.д.).
Очевидно, что SDS-системы, повторяющие архитектуру классических массивов, имеют те же технические ограничения: фиксированное число контроллеров (нод), интерфейсных портов взаимодействия и накопителей (жестких дисков, SSD). Однако переход к концепции программного определения сделал возможным применение технологий, которые раньше были доступны только в сложных Hi-End (например, виртуализация внешних дисковых ресурсов). За счет включения продуктов SDS в стек решений базового и среднего уровня вендоры существенно нарастили функционал в этих сегментах.
Самыми популярными на сегодня являются SDS-решения с объектным принципом хранения данных. Их основные потребители – крупные и средние провайдеры услуг облачного хранения: Dropbox, Apple, Amazon, Google и др. В случае частных облаков объектный подход гарантирует унификацию вычислительных компонентов и динамическое расширение инфраструктуры за счет добавления универсальных новых нод (серверов), которые могут обеспечивать сервис хранения одновременно с другими ролями.
Объектный принцип предусматривает хранение множества копий частей массива данных – так называемых объектов (классические же решения отвечают за гарантированное хранение всего массива данных – в рамках одного ресурса). Сохранность данных обеспечивается при доступности хотя бы одного экземпляра из множества. Применение объектного хранения сделало возможным резервирование данных в зависимости от места расположения компонентов SDS. Например, можно дублировать объекты на ресурсах разных узлов (серверов – участников SDS), размещенных в разных стойках ЦОД. В этом случае допустима потеря части компонентов при условии сохранения одной или более копий каждого из объектов.
Объектный принцип дает куда большую масштабируемость и гибкость в управлении ресурсами. Первое обеспечивается применением множества равноправных нод. В результате эта характеристика меньше зависит от ограничений аппаратных компонентов, чего не скажешь о классических массивах. Гибкость управления ресурсами достигается за счет применения динамических алгоритмов распределения и хранения объектов: можно оперативно изменять принципы хранения в зависимости от бизнес-требований.
Основной недостаток объектных хранилищ – необходимость иметь N-кратный объем ресурсов (где N – число хранимых копий объектов и, соответственно, уровень защиты данных) и осуществлять доступ к данным по объектным протоколам (S3, Rest API). Впрочем, затраты на избыточный объем возмещаются за счет использования компонентов массового производства (серверов, жестких дисков, коммутационного оборудования), которые существенно дешевле специализированных аппаратных решений, выпускаемых малыми партиями. Проблема с протоколами доступа к данным стоит острее: большая часть бизнес-приложений и прикладного ПО на текущий момент не имеют поддержки объектных протоколов. При этом доработка либо замена используемого ПО за приемлемое время и вменяемые деньги очень часто невозможна. В связи с этим основные SDS-продукты на данный момент имеют отдельный компонент (роль) для предоставления ресурсов по классическим протоколам (iSCSI, NFS, CIFS).
В большинстве случаев применение объектных или основанных на них СХД в отличие от классических или подобных им массивов требуют более детальной проработки и оценки возможностей решения. Это связано с совершенно другим подходом к организации инфраструктуры, резервированию данных (РК) и комплекса в целом (Disaster Recovery, DR). Ошибки, допущенные в этом месте, могут дорого обойтись. Одно из возможных последствий – отсутствие постоянной производительности. В зависимости от используемых алгоритмов распределения и кеширования данных может наступить ситуация, когда будет производиться обращение не к локальным ресурсам, а к другим узлам (членам группы хранения единого набора данных) по внутренней сети – Ethernet, InfiniBand, WAN. На рис. 2 показан пример подобного колебания производительности.
Рис. 2. График возможной многонодовой производительности SDS-решения
Красная линия отражает время отклика при выполнении операций ввода/вывода. Пиковые значения приходятся на выполнение операций на удаленном узле. Увеличение времени отклика напрямую влияет на производительность операций (чем это время больше, там меньше операций можно выполнить за определённый период). Из примера видно, что задержка на выполнение удаленных операций не постоянна и может стать причиной значительного снижения общей производительности. Чем продолжительнее выполнение операций на удаленном узле, тем больше будет влияние на суммарную производительность.
Чтобы минимизировать влияние этой особенности многоузловых SDS на продуктивные среды, нужно провести предварительную глубокую проработку конфигурации и оценку принципиальной возможности ее применения.
Основные области и решения, в которых началось активное применение технологий SDS:
- тестовые среды и среды разработки;
- хранение резервных и архивных данных;
- системы публичного/корпоративного облачного хранения (Dropbox и др.);
- публичный/корпоративный web-хостинг данных;
- общецелевые файловые хранилища (общие файловые ресурсы);
- системы машинной обработки неструктурированных данных (социальные сети, статистическая обработка данных и др.);
- хранилища виртуальных машин;
- BLOB-хранилища вторичных данных информационных систем.
Программно-определяемые системы хранения – наиболее гибкие и динамично развивающиеся технологии в группе решений по хранению данных. Применяемые в них алгоритмы позволяют уменьшить используемые компоненты и суммарную стоимость решений. В качестве примера – задача по построению среды хранения. Компания имеет 3 дата-центра в пределах одного города, соединенные IP-каналами достаточной пропускной способности. Требования к ресурсам хранения следующие:
- общий объем данных – 100 ТБ;
- одновременный доступ на чтение/запись из 3 ЦОДов;
- отказоустойчивость до уровня потери одного из ЦОДов.
Решить эту задачу с помощью классических дисковых массивов в полной мере не получится. На сегодня существуют системы, которые обеспечивают одновременный доступ (на чтение/запись) только с 2 технологических площадок (например, HDS G1000 GAD) либо из всех ЦОДов к единому хранилищу, расположенному в одном из дата-центров и резервируемому в других. Условное решение – организация ресурсов хранения с делением на сегменты по площадкам и резервированием этих сегментов между ЦОДами. Пример данной реализации представлен на рис. 3.
Рис. 3. Обобщенная схема решения с применением классических массивов
Реализация такого подхода требует не менее 200 ТБ суммарной полезной емкости для организации хранения и резервирования и ограничивает локальный полный (чтение/запись) доступ объемом локального сегмента. Доступ на запись в удаленные сегменты должен будет осуществляться через каналы связи между площадками. Таким образом, требуется обеспечить работу прикладного ПО с 3 независимыми сегментами данных.
Теперь рассмотрим вариант использования SDS-систем с объектным доступом. В этом случае возможно построение единого хранилища данных с расположением компонентов (узлов) на 3 площадках. Динамические алгоритмы хранения дают возможность обеспечить хранение не менее 1 копии на каждой площадке, что гарантирует сохранность данных при потере до 2 из 3 ЦОДов. Данный подход, как и в случае с классическим массивом, требует хранения 3-кратного объема, но применение недорогих компонентов снижает TCO аппаратной части.
Иногда нет возможности разместить в каждом ЦОДе полный объем требуемого оборудования (из-за отсутствия места, недостатка ресурсов электропитания, охлаждения и т.д.). Выход – SDS-решения с уникальными (более сложными) алгоритмами распределения данных, например Quantum Lattus: хранение данных тут производится совместно с хранением сервисной информации для их восстановления. Схожее решение – RAID 5 или 6 с применением данных четности для восстановления массива. Главное отличие Quantum Lattus от классического RAID – возможность регулирования уровня сервисной информации. За счет этого можно задавать необходимый уровень сохранности данных при выходе из строя определенного количества компонентов. Например, можно задать потерю всех компонентов одной из технологических площадок, в данном случае требуемый объем хранения для обеспечения 100 ТБ полезной емкости составляет ~164 ТБ.
Рис. 4. Обобщенная схема решения с применением SDS
Решение позволяет минимизировать емкость для обеспечения хранения данных, но в то же время накладывает более жесткие требования к доступности, пропускной способности каналов связи между площадками и набору ПО СРК и архивирования данных (необходимо наличие возможности работы с объектными системами хранения).
Развитие и использование программно-ориентированных СХД следует рассматривать как наиболее перспективное направление в индустрии хранения. Реальное применение SDS сегодня ограничено рядом факторов, но наращивание их функционала и постепенное увеличение стабильности и прогнозируемости работы компонентов позволит со временем рассматривать SDS в качестве основных систем хранения для большинства областей.
Основное ограничение в использовании объектных SDS – неготовность ПО. В большинстве случаев в крупных программных продуктах запаздывает реализация новых функций, а зачастую она невозможна архитектурно.
Остается надеяться, что столкновения «в лоб» новых программных и классических продуктов не будет. Наилучшим вариантом может стать плавная смена решений, либо модель, при которой оба вида займут свои ниши и не будут сильно конкурировать. Мы же можем занять место в кругу защитников той или иной технологии либо наблюдать со стороны, применяя для своих задач всё лучшее от них обеих.
Мы будем рады вашим конструктивным комментариям.