27 февраля состоялся экспертный круглый стол на тему «Перспективы программно-определяемых СХД (Software Defined Storage)», организованный журналом Connect при поддержке компании IBM. В его работе приняли участие CIO компаний из различных сфер бизнеса, которые поделились собственным опытом, мнениями и сомнениями по поводу использования технологии SDS.
В круглом столе приняли участие:
Дмитрий АПАШКИН, «РН-Информ»
Юрий БЫКОВ, КЭС-Холдинг
Николай ВОРОНЦОВ, «Росэлектроника»
Михаил ИЗОПЕСКОВ, ВГТРК
Алексей КАРТЫШЕВ, «Дочки-Сыночки»
Игорь КАТКОВ, IBM
Сергей КВАШУК, «Райффайзенбанк»
Антон МАКАРОВ, Аэропорт Шереметьево
Кирилл МИЛЕЙШЕВ, «Нордеа Банк»
Андрей НАРСКИХ, IT Energy
Равиль САФИУЛЛИН, IBM
Марк ТЕПТЕРЕВ, «Оверсан»
Евгений ЦЫПИН, IBM
Дмитрий ЧЕРНЦОВ, «Газпром информ»
Модератор Круглого стола Руслан СМЕЛЯНСКИЙ, эксперт в области программно-определяемых сред, член-корреспондент РАН, профессор, директор по науке и образованию Центра прикладных исследований компьютерных сетей.
Концепция Software Defined
Во вступительном слове Руслан Смелянский сделал обзор концепции Software Defined и предпосылок ее появления. Традиционные СХД создавались еще в 1990-е гг. Ориентированы они были на существовавшие тогда приложения, о совместимости одних СХД с другими тогда никто не задумывался. К настоящему времени практически все крупные компании обременены парком унаследованных СХД, состоящим из разрозненных «островов» хранения. Унаследованные системы хранения дороги в обслуживании и сложны в эксплуатации, их трудно масштабировать, они не готовы к работе с облачными платформами, мобильными приложениями, большими данными. Эти проблемы привели к пересмотру идеологии построения систем хранения данных и появлению концепции Software Defined Storage – программно-определяемых систем хранения данных.
Тенденция перехода к программному определению характерна для всей области компьютерных сетей (в том числе и сетей хранения данных). В развитии архитектуры компьютерных сетей сегодня есть две доминанты: переход к централизованному программному управлению сетью в целом (Software Defined Network) и виртуализация сетевых сервисов (Network Function Virtualization).
В традиционной сети архитектура каждого устройства подразумевает наличие как слоя передачи данных (Forwarding Plane или Data Plane), так и слоя управления (Control Plane). Каждое устройство наделено собственным «интеллектом», что делает его более сложным и дорогим, при этом интеллектуальные функции в разных устройствах дублируются. Устройства сети работают практически независимо друг от друга, что увеличивает время сходимости сети после любых изменений.
В сети SDN за устройствами остается только задача передачи данных, а весь интеллект управления (Control Plane) выносится в единый логический центр – контроллер SDN. Через интерфейсы, обращенные к сетевым устройствам, контроллер видит все изменения в сети и быстро на них реагирует, сокращая время сходимости. При этом сами устройства в сети становятся проще и дешевле. Через интерфейсы, обращенные к приложениям, контроллер узнает о требованиях каждого приложения к параметрам сети и уровню сервиса. Концепция SDN предполагает наличие открытых API для сетевых приложений. За счет этого любой разработчик или оператор может создавать приложения для управления сетью. Это относится к любым сетям, будь то операторские, корпоративные или сети хранения данных. В последние пару лет в мире начал формироваться новый рыночный сегмент – ПО для управления компьютерными сетями.
В традиционной сети сетевые сервисы (Firewall, NAT, DPI, акселерация, балансировка и пр.) реализуются с помощью программно-аппаратных решений (middlebox или appliance), большинство из которых располагаются на границе сети. Технология виртуализации сетевых сервисов (NFV) предполагает логическое отделение функционала таких решений от аппаратной составляющей: соответствующий функционал в виде виртуальных машин может быть расположен на стандартных серверах. Возможности современных серверов стандартной архитектуры и новые технологии, в частности Intel DPDK, позволяют делать такое решение достаточно мощным и производительным. Вместо традиционных middlebox можно использовать на границе сети микро-ЦОД на базе стандартных серверов с развернутыми на них виртуальными машинами – это позволит быстро запускать и без труда масштабировать сетевые сервисы.
Те же принципы – абстрагирование сервисов хранения от аппаратного обеспечения – реализуются в программно-конфигурируемых системах хранения (SDS). Контроллер, развернутый поверх традиционных систем хранения, позволяет динамически перераспределять данные между устройствами хранения с учетом требований приложения и возможностей подключенных устройств (по емкости, быстродействию и пр.). Такое решение обеспечивает возможность легко создавать виртуальные пулы хранилищ, совместимые со сторонними облачными сервисами, – путем использования управляющих приложений (собственных или приобретенных), которые обеспечат уровень доступности и сервисы хранения/репликации/восстановления в соответствии с заданным SLA. При этом весь пул хранения будет выглядеть для пользователя как единое виртуальное хранилище. Для повышения надежности программно-конфигурируемого решения (исключения единой точки отказа) Control Plane можно сделать физически распределенным.
Предприятию с унаследованным парком разнородных СХД модель SDS позволит, как минимум, более рационально использовать имеющийся ресурс. Существенно и то, что сокращаются трудозатраты администратора. Функции настройки, которые в традиционных системах выполнялись вручную, берет на себя оркестратор – многофункциональное управляющее ПО.
Варианты реализации
Идеальная SDS должна обеспечивать полную независимость функционала от аппаратного обеспечения – как на уровне управления, так и на уровне хранения – и при этом обеспечивать не меньшие надежность, функциональность и производительность, чем современные hi-end-массивы. Существующие на рынке SDS-решения приближаются к идеалу в большей или меньшей степени.
Как объяснил Игорь Катков (IBM), есть два подхода к решению вопроса: со стороны программного обеспечения и со стороны аппаратных средств. Чисто программные продукты обеспечивают полную независимость от аппаратных средств на обоих уровнях (управления и хранения), они могут использовать простейшие стандартные серверы и простейшие дисковые полки. По мере совершенствования и все большей стандартизации серверных технологий у пользователей чисто программных решений становится меньше вопросов по поводу их функциональности и совместимости. Но вопросы надежности остаются. У крупнейших заказчиков, которым требуется высокая надежность систем хранения, полностью программно-реализованные SDS встречаются редко. Причина, возможно, в том, что эта технология пока не считается достаточно зрелой.
Производители традиционных СХД подходят к концепции SDS либо путем развития продуктов для виртуализации систем хранения (программно-аппаратных устройств, которые ставятся поверх имеющихся систем), либо путем развития технологий федерации (storage federation), когда системы хранения (точнее, их контроллеры) напрямую общаются друг с другом, обеспечивая возможность прозрачного перемещения томов данных между различными массивами. Эти подходы обеспечивают независимость SDS от устройств хранения, т. е. решают вопрос независимости от аппаратного обеспечения процентов на 90. Но на уровне управляющего слоя независимость от аппаратных технологий обеспечивается лишь частично.
Пример такого решения – IBM SVC (новое название продукта – IBM Spectrum Virtualize). Он позволяет подключать любые носители (Flash, SAS, SATA) разных поколений и пользоваться функционалом класса Hi-End. Но он не может быть развернут на произвольно выбранном сервере, конфигурация сервера задается производителем. С одной стороны, это позволяет более качественно реализовать некоторые сервисы (например, онлайн-компрессию данных за счет наличия специального аппаратного ускорителя), с другой – вендор может нести ответственность за надежность своего решения. Поэтому есть примеры использования SVC для критически важных приложений – ERP, Core Banking, биллинга и т. п.
Продолжая тему, Равиль Сафиуллин (IBM) пояснил, что IBM SVC – продукт для блочного хранения. Для файлового хранения у IBM есть параллельная файловая система GPFS и основанный на ней чисто программный продукт Elastic Storage (современное название – IBM Spectrum Scale). SDS-продукты IBM способны закрыть практически все возможные потребности заказчиков в области систем хранения данных. В скором времени на рынок выйдет платформа, обеспечивающая совместную работу корпоративных хранилищ и публичного облака.
Практический опыт
В «Райффайзенбанке» SDS-системы разных вендоров используются уже четыре года наряду с классическими hi-end- и midrange-массивами. Как сообщил Сергей Квашук, в качестве SDS в банке применяются несколько решений: чисто программные, программно-аппаратные, в том числе IBM SVC. Преимущество чисто программных решений – свобода выбора аппаратной составляющей. Но, как показала практика, программно-аппаратные решения более предсказуемы, стабильны и надежны. При этом любые SDS-решения несовершенны. По мнению спикера, пока нет решения, которое полностью бы обеспечивало весь набор нужного функционала. Наиболее универсальным (позволяющим использовать любые среды хранения) и функциональным (реализующим возможность пользоваться всеми функциями классических СХД) является решение IBM SVC.
В SDS-решениях вызывают опасения потенциальные пределы производительности контроллера, который при достижении определенного порога может начать генерировать задержку. Это повод задуматься о том, стоит ли консолидировать абсолютно все хранилища под одним контроллером, а также принять во внимание матрицу совместимости продуктов разных поставщиков.
Тем не менее концепция SDS (или хотя бы первый шаг в этом направлении – виртуализация СХД) способна принести ощутимую выгоду за счет объединения в пул унаследованных систем хранения. В том же «Райффайзенбанке» есть центр тестирования и разработки, где сосредоточено примерно 20 СХД разных классов и поколений. Все они подключены к виртуализатору и, с точки зрения пользователя, выглядят как единая система хранения на 0,5 Пбайт. Постепенно устаревающие СХД выводятся из эксплуатации и заменяются другими, и это происходит незаметно для пользователей и приложений.
Для представителей таких секторов, как банковский или нефтегазодобывающий, ключевыми характеристиками СХД являются надежность и производительность, потому к программным реализациям они относятся осторожно, считая их недостаточно предсказуемыми. Иная позиция у сервис-провайдера – о ней рассказал Марк Тептерев («Оверсан»). У провайдера услуг публичного облака основное требование к ИТ-инфраструктуре – высокая отдача от инвестиционных вложений. Чем дешевле обходится инфраструктура, тем ниже тарифы и тем более конкурентоспособен провайдер на рынке.
С 2009 г. «Оверсан» несколько раз переходил от SDS к традиционным СХД и обратно. В первый же год работы выяснилось, что классические системы сложно использовать для публичного облака. На тот момент на рынке еще не было хорошо проработанных вендорских SDS-решений, и провайдер начал создавать собственное с использованием простых массивов JBOD и интерконнекта Infiniband. Но разработка и поддержка самодельного решения обходились слишком дорого. На некоторое время провайдер вернулся к классическим вендорским СХД. Однако теперь «Оверсан» опять переходит к решению SDS – чисто программному и на этот раз покупному. Дальнейшее развитие облачных систем хранения предполагает полный отказ от вендорских решений в пользу стандартных серверов и полок JBOD. Функционал и надежность решения провайдера устраивают. Что касается рисков сбоя, то они существуют и в классических системах. К тому же для сервис-провайдера вопросы стоимости решения имеют ключевое значение.
«За» и «против»
Как полагает Дмитрий Чернцов («Газпром информ»), подход SDS применим скорее для целей разработки и тестирования, но не для продуктивных систем. Несомненно, программно-определяемое решение упрощает управление парком оборудования. Но для «Газпрома» и других крупных компаний на первом месте надежность, производительность и доступность систем. Не очевидно, что SDS сможет их гарантировать, есть сомнения по поводу потенциального «бутылочного горлышка», которое может создать контроллер.
Аналогичные опасения высказал Дмитрий Апашкин («РН-Информ»). Между тем в компании сейчас используется множество единиц оборудования различных производителей, и расположены они в разных офисах. Отсутствует гибкость управления и постоянно не хватает дискового пространства. Поэтому SDS-решение рассматривается. Но лишь для инфраструктурных приложений, нетребовательных к производительности дисковых подсистем.
Алексей Картышев («Дочки-Сыночки») признался, что в ритейлерской сети есть определенные проблемы с инфраструктурой – при внедрении любой информационной системы приходится наращивать ресурсы вычислений и хранения и не только нести финансовые затраты, но и во многом переделывать существующую инфраструктуру. Возможно, со временем технология SDS решит эти проблемы, но пока это не очевидно.
Если одни компании сознательно придерживаются консервативного подхода к развитию ИТ-инфраструктуры, то у других просто нет выбора. Например, в «Росэлектронике», компании государственной и входящей в оборонно-промышленный комплекс, выбор системы будет определяться нормативными актами.
Специалисты IBM со своей стороны уверены в надежности SDS. Время, когда программно-определяемые системы хранения существовали скорее на уровне концепции, миновало, сегодня это реальные продукты, готовые для использования в корпоративной инфраструктуре, и тому есть целый ряд примеров. Важно то, что SDS позволяет предприятиям справляться с насущными проблемами – управлением парком разнородного оборудования и работой с большими объемами данных. Для больших данных, к использованию которых вплотную подошли уже многие компании, SDS предлагает гораздо более интересные решения, нежели традиционные системы хранения.
Среди участников мероприятия были представители компаний, осуществивших виртуализацию инфраструктуры хранения и считающих переход к SDS следующим шагом в корпоративной стратегии. Так, Андрей Нарских сообщил, что компания IT Energy уже больше года использует IBM SVC для виртуализации и тиеринга. Система хранения обслуживает SAP ERP, и никаких нареканий не было. Однако, по мнению спикера, пока не хватает возможностей автоматизированной оркестрации ресурсов в соответствии с требованиями приложений, в частности тиеринга с учетом производительности и надежности конкретных дисковых подсистем в пуле.
В «Нордеа Банке» также используется IBM SVC. По словам Кирилла Милейшева, тема SDS интересна банку с учетом перспектив развития бизнеса и использования технологий больших данных.
Юрий Быков («КЭС-Холдинг») сообщил, что в холдинг входит множество энергетических компаний, расположенных в разных регионах, у всех есть свои СХД. Для централизованного управления ими (тиеринга, переноса данных между массивами и пр.) применяется SDS-решение другого вендора, оно позволяет делать все это с единой консоли. Но переведены на SDS только инфраструктурные сервисы. Для ответственных приложений компания предпочитает использовать уже отработанные технологии и готова поступиться преимуществами, которые обещают новые решения.
По мнению Михаила Изопескова (ВГТРК), SDS – тренд и компаниям надо готовиться к этой технологии. Для ВГТРК актуальна задача виртуализации и оркестрации имеющегося парка СХД, консолидации сервисов и их централизованного предоставления дочерним структурам. Компания собирается протестировать одно из программных SDS-решений. Использовать его предполагается для инфраструктурных сервисов. В сфере хранения медиа-архивов и производства ТВ-контента специалист не видит применения для SDS – просто нет проблем с существующими технологиями.
Препятствия к внедрению
Один из возникших вопросов касался экономики решения. Как продемонстрировать бизнесу выгоду от внедрения SDS?
Эксперты IBM могут это сделать. Они анализируют существующий парк СХД, стоимость их поддержки, планы по выведению из эксплуатации, оценивают темпы роста объемов данных и будущие потребности компании в пространстве хранения и сервисах. Существующие и планируемые затраты за три-пять лет сравниваются с расчетными затратами при внедрении нового решения. В случае, например, SVC экономический эффект достигается за счет того, что можно уменьшить долю hi-end-оборудования в пользу midrange, продлить сроки эксплуатации ряда старых систем и сделать доступными на них современные сервисы и т. д. Все это выражается в цифрах, которые можно предъявить бизнесу.
Некоторых смущает сложность внедрения нового решения поверх существующих систем с продуктивной нагрузкой. Ответом на это является построение плана постепенной миграции. Соответствующие методики и компетенции заказчикам доступны.
Продолжают сохраняться сомнения в надежности программно-определяемых систем со стороны пользователей: многие считают новую технологию недостаточно зрелой. Поэтому, например, «Оверсан» предлагает клиентам на выбор классическое или SDS-решение. Пока классическому решению клиенты доверяют больше. Но растет доля клиентов, для которых важна не инфраструктура в основе сервиса, а гарантии провайдера. А такие гарантии провайдер давать готов. По опыту Марка Тептерева, абсолютное большинство проблем с классическими СХД связаны с недостаточной квалификацией специалистов. SDS – унифицированные системы, с которыми проще работать, поэтому их надежность может оказаться даже выше.
В ходе обсуждения всплыла еще одна несколько неожиданная тема: потребители не полностью используют возможности, которые предоставляют вендорские продукты. Бывает, что ИТ-специалисты заказчика (даже сертифицированные вендором) не знают каких-то важных вещей об особенностях функционирования поставленного решения. Кто в этом виноват: вендор, который недоучил, или сам заказчик, который экономит на повышении квалификации сотрудников? В отношении многих вендоров подобное обвинение было бы несправедливым, тем не менее обратить внимание на проблему стоит обеим сторонам.
Итог
Разброс мнений участников обсуждения перспектив применения SDS охватил весь возможный спектр: от «категорически не готов» до «уже используем». Однако того, что SDS – тенденция, которая со временем станет доминирующей (как минимум, в программно-аппаратной реализации), никто не отрицал. Вопрос в сроках.
В контексте сказанного уместным кажется замечание Евгения Цыпина (IBM) о том, что наличие SDS является показателем зрелости ИТ-инфраструктуры заказчика. При достижении определенного уровня развития инфраструктуры внедрение SDS становится неизбежным.
