Программно-определяемые СХД: сравниваем 7 решений

В этой статье я кратко расскажу о программно-определяемых хранилищах (Software-Defined Storage, SDS) и о возможностях их применения, которые они дают при построении ИТ-инфраструктуры. В конце статьи вас ждет сравнение семи SDS-решений. Я протестировал их, когда мы с коллегами из «Онланты» прорабатывали варианты развития инфраструктуры облака OnCloud.ru. Надеюсь, что сравнительная таблица сэкономит вам кучу времени и сил при выборе продукта.

Я работаю системным инженером группы облачной интеграции компании «Онланта». Одно из направлений моей деятельности — это исследовательские работы (R&D) по изучению и сравнению новых технологий, которые могли бы помочь нам повысить качество и снизить стоимость облачных услуг OnCloud.ru, предоставляемых «Онлантой». С результатами такого сравнения SDS-решений вы познакомитесь в этой статье.

Тренд к снижению стоимости владения ИТ-инфраструктурой

В крупных организациях системы хранения данных занимают значительную долю стоимости ИТ-инфраструктуры (по оценкам специалистов – до 25%). Эта цифра может существенно вырасти. Причины – рост объема данных и увеличение потребности в емкостях систем хранения данных (СХД), в том числе из-за законов, которые обязывают эти данные хранить. В то же время компании активно стараются экономить ИТ-бюджеты, что вынуждает их находиться в постоянном поиске наиболее выгодных технологических решений, которые бы позволили сократить эти расходы не в ущерб качеству сервиса. Это же относится к хранению и обработке данных.

Требования заказчиков к снижению стоимости владения ИТ-инфраструктурой заставляют поставщиков инвестировать в разработки и предлагать новые технологии. Одна из них — программно-определяемые системы хранения данных (Software-Defined Storage, SDS). Компании начинают задумываться о внедрении SDS, когда процедуры работы с данными становятся неэффективными и их поиск отнимает много времени.

Концепция SDS позволяет получить такие преимущества, как:

Благодаря технологиям SDS можно значительно снизить стоимость СХД и их администрирования. По прогнозам Gartner , к 2020 году 70–80% неструктурированных данных будут храниться на недорогих системах, управляемых с помощью SDS, а уже к 2019 году 70% существующих массивов хранения станут доступны в полностью программной версии.

Когда и зачем нужна SDS

ПО управления СХД должно обеспечивать гибкую организацию хранения данных, а также:

SDS определяют в Storage Networking Industry Association (SNIA, Ассоциация производителей и потребителей систем хранения) как виртуализированную среду хранения данных с интерфейсом управления сервисами, которая должна включать в себя:

Отмечу, что для SDS нужен стандартизированный интерфейс управления – такой, как SNIA Storage Management Initiative Specification (SMI-S). Он является составной частью концепции программно-определяемых дата-центров (SDDC). Эта программная логика облачной инфраструктуры хранения и облачных аппаратных платформ может быть элементом и традиционных ЦОД. Сервисы хранения и обработки данных могут выполняться на серверах, специализированных устройствах хранения (storage appliance) или на обеих этих платформах, устраняя традиционные границы.

Сравниваем SDS-решения

Software-Defined Storage предлагают многие вендоры:

Уточню, что решение RedHat Storage представлено двумя продуктами: RedHat Ceph Storage и RedHat Gluster Storage (RH Storage Server). Здесь они подразумеваются оба, но в приведенном ниже сравнении они не участвовали, так как значительно отличаются от других упомянутых решений.
Ceph — не совсем коробочный продукт. Его использование без штата разработчиков достаточно затруднительно, что сделало его неинтересным для нашей компании. Поэтому этого решения нет в сравнительной таблице.

Условно все SDS-решения можно разделить на три категории:

Некоторые производители предлагают как комплексные решения, так и программную часть (Huawei, Dell EMC). Это позволяет гибко подходить к подбору продуктов и использовать унаследованное «вычислительное» оборудование для решения менее ресурсоемких задач хранения данных. Еще одной заслугой SDS стала возможность применения в некоторых классических СХД виртуализации дисковых массивов.

Решения архитектурно строятся по двум принципам:

В первом случае отказоустойчивость обеспечивается за счет распределенных копий данных, но из-за избыточности коммуникаций между узлами (нодами) снижается скорость записи. Критичным местом является сеть передачи данных, поэтому такие решения обычно реализованы на основе InfiniBand. По такому принципу построены решения VMware vSAN, HPE StoreVirtual VSA, Dell EMC ScaleIO.

В системах без общих элементов данные записываются на один узел, а потом с заданной периодичностью копируются на другие для обеспечения отказоустойчивости. При этом записи не являются транзакционными. Такой подход наиболее дешев. Чаще всего в качестве интерконнекта в нем используется Ethernet. Данная архитектура удобна с точки зрения масштабируемости. Яркий ее представитель — CEPH.

Сейчас многие компании занимаются разработкой как программной SDS (например, Atlantis Computing, Maxta, StarWind, DataCore Software, Sanbolic, Nexenta, CloudByte), так и выпуском комплексных решений (Dell EMC, IBM) или специализированных устройств (Tintri, Nimble, Solidfire).

Из наиболее известных на рынке мы выбрали для сравнения семь решений, которые интереснее всего для задач «Онланты». Это:

В этой таблице мы сравнили их основные характеристики.

Инструмент будущего

Технология SDS начала развиваться еще в начале 2000-х, но пока не смогла заменить классические СХД по целому ряду причин — сейчас мы их обсуждать не будем. Но производители активно занимаются развитием своих продуктов и интерес к технологиям SDS растет. По нашим оценкам, в ближайшее время они станут тем инструментом, который позволит сокращать стоимость ИТ-инфраструктуры при росте потребности в увеличении емкости СХД.

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

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

Но надеюсь, что представленные результаты сравнения помогут вам сориентироваться, сэкономят время и облегчат задачу выбора, какое решение подходит в вашем случае.

Если кто-то из читателей сочтёт возможным поделиться какой-либо дополнительной информацией по обсуждаемому предмету, а возможно, и рассказать о своем выборе, было бы очень интересно.