Технологии NetApp: управление данными без ограничений

Роман Ройфман: Наши продукты для облаков – это как собственный автомобиль, каршеринг и такси

NetApp анонсировала выпуск своего сервиса Cloud Volumes для Google Cloud Platform. Ранее компания презентовала аналогичные продукты для двух других облачных мега-провайдеров – Microsoft Azure и Amazon WebServices. О том, как сделать взаимовыгодным симбиоз поставщика решений для управления данными и облачного провайдера – «гиперскейлера» в интервью CNews рассказал технический директор NetApp в России, СНГ и Восточной Европе Роман Ройфман. Подробнее обо всех новинках можно будет узнать на конференции NetApp Directions, которая пройдет в Москве 17 июля 2018 г.

CNews: NetApp официально объявила о выпуске сервиса NetApp Cloud Volumes для облачной платформы Google. Почему выбрали именно Google? Ведь есть еще такие серьезные игроки как Microsoft Azure и Amazon Web Services.

Роман Ройфман: Действительно мы недавно объявили о запуске технологии Cloud Volumes для Google-платформ, но это не первый наш проект для больших облачных провайдеров («гиперскейлеров»). Ранее мы сделали проект с Azure, потом с Amazon, и вот сейчас добавилась платформа для Google. Сейчас мы работаем со всеми четырьмя крупнейшими гиперскейлерами, включая китайскую Alibaba. И это обстоятельство отличает нас от остальных игроков на рынке систем управления данными.

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

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

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

CNews: А почему вы не хотите собственное облако? Вы считаете, это невыгодно?

Роман Ройфман: Как показало время, решение не строить собственное облако было правильным. Многие из тех, кто пытался это сделать сами, уже ушли с этого рынка. Воевать с Amazon очень сложно, это под силу только гигантам. Только посмотрите, какие бюджеты и какие ресурсы тратит Microsoft на развитие Azure. Фактически, все, что зарабатывает Microsoft на продаже лицензий, корпорация направляет на развитие Azure, потому что это будущее. Только вкладывая огромные средства в инфраструктуру своего облака можно пытаться конкурировать с Amazon.

Здравый смысл говорит, что даже если мы привлечем все свои ресурсы, то не сможем конкурировать с Amazon напрямую. Но это еще не повод сдаваться. Можно найти другой путь. Есть ли у гиперскейлеров прямой интерес покупать системы хранения сторонних производителей? В целом – нет, они многое умеют делать сами. Поэтому нашей задачей было найти варианты, чтобы сделать наши решения интересными как для тех, кто ушел в облака, так и для самих гиперскейлеров, и, конечно, для нас. Мы выстраиваем отношения, напоминающие протокооперацию — форму факультативного симбиоза, при которой выгоду от сотрудничества получают все стороны.

К этому мы шли достаточно долго. Мы уже много лет предоставляем решение под названием NetApp Private Storage. В этом варианте заказчик совмещает услуги гиперскейлера с собственными системами хранения, стоящими «рядом с облаком». Есть определённая выгода от того, чтобы размещать вычислительные ресурсы в облаке, но данные хранить на собственной системе. И для этого есть несколько причин. Во-первых, безопасность. Вы точно знаете, где находятся ваши данные. Во-вторых, мобильность данных – вы можете использовать вычислительные ресурсы в двух разных облаках одновременно, но они будут иметь доступ к одним и тем же данным на вашей СХД NetApp Private Storage. В противном случае, если и данные, и вычисления разбросаны по разным облакам, придется решать задачу синхронизации данных между облаками, организовать управление данных в разных гиперскейлерах, и оплачивать трафик для синхронизации данных между облаками. В-третьих, можно сделать отказоустойчивые сервисы, когда один узел кластера MS SQL работает в одном облаке, а второй – в другом, но все данные лежат на СХД NetApp Private Storage, которая принадлежат вам, и переключение сервиса между облаками ними занимает секунды.

roifmansmall.jpg
Роман Ройфман: Мы рассматриваем крупнейших облачных провайдеров не как угрозу, а как возможность совместной работы. И предлагаем интересные сервисы работающие внутри инфраструктуры гиперскейлеров.


Параллельно мы начали развивать еще один продукт для тех заказчиков, которые целиком уходят в облака – NetApp Cloud Volume ONTAP ранее известный под именем ONTAP Cloud. В этом случае весь функционал запускается внутри облаков провайдера, того же Amazon или Azure. В результате заказчик получает cloud native систему, но при этом весь функционал, который был доступен в инженерных системах NetApp, работает и в облаке. Используется весь багаж компании, 25 лет наработок, опыт интеграции с приложениями. То есть, приложение заказчика мигрирует в облачную среду, но при этом оказывается в знакомой комфортной ситуации. Оно понимает, как работать с системой хранения, как из нее получить максимум функционала.

Плюс мы сейчас делаем принципиально новый шаг – предлагаем NetApp Cloud Volumes Services. В чем главное отличие от предыдущего варианта? Вы сразу получаете «дисковое пространство как сервис» с функциональностью, привычной для ONTAP. Вы получаете настоящую, я бы сказал промышленную, реализацию файловых протоколов для ваших облачных сервисов с возможность создания копий и snapshot. При этом это сервис доступный из стандартных интерфейсов и API Azure, Amazon или Google. Это не отдельная железка стоящая «рядом с облаком». Это такой же сервис, как и другие «родные» сервисы Azure или AWS. И вы можете потреблять их точно также, как и сервисы Azure или AWS, и вам не требуется для этого никаких знаний администратора СХД. Повторюсь, что это все реализовано как родные сервисы гиперскейлера, соответственно, реализация Cloud Volumes в случае работы через Azure, Amazon или Google немного отличается.

CNews: Чем отличается реализация на четырех разных платформах – Azure, Amazon, Google, Aliиaba?

Роман Ройфман: Есть небольшие различия. Хотя во всех случаях используются только all-flash массивы и общий framework для управления ресурсами, но каждое решение уникально, потому что оно интегрировано с родными API конкретного гиперскейлера.

Самая главная работа – это интеграция с инфраструктурой облачного провайдера, потому выделение дискового пространства, создание моментальных снимков, клонов томов , создание репликации – все выполняется не стандартными командами ONTAP, а на уровне родных API гиперскейлера. Именно гиперскейлер выполняет выделение пространства, отвечает за биллинг и выставление счетов.

CNews: Продукты Cloud Volumes ONTAP и Cloud Volumes будут существовать одновременно?

Роман Ройфман: Да, названия продуктов почти не отличимые, но их потребители все же немного разные.

В случае Cloud Volumes ONTAP потребители – это те, кому нужна программно-определяемая система хранения в облаке. Ключевое слово здесь система хранения, хоть и облачная, точнее программно-определяемая СХД построенная из ресурсов облака. Потребители готовы общаться с ней как с системой хранения и ждут такой же функциональности, как и от физических СХД. При использовании Cloud Volumes ONTAP, a пользователь должен конфигурировать и управлять ONTAP и всеми облачными ресурсами выделенными для его работы. Cloud Volumes ONTAP идеально подходит для администраторов систем хранения и администраторов инфраструктуры, которые хотя полностью контролировать все детали их систем хранения даже если они ушли в облако.

NetApp Cloud Volumes – это cloud-native сервис файлового доступа, также базирующийся на проверенной технологии ONTAP, и предоставляющий дополнительные сервисы управления данными (Snapshots, Clones, Sync). Этот сервис позволяет совместить десятилетия опыта NetApp в создании файловых сервисов уровня предприятия, простоту и гибкость крупнейших облаков (AWS, Azure, Google) и, например, HDInsight, EMR. NetApp Cloud Volumes позволяет получить в облаке качественную реализацию NFSv3, NFSv4 (скоро) и SMB протоколов. В случае с Cloud Volumes Servicesзаказчик просто хочет получать «nativecloud» сервис для хранения данных (включая поддержку API). Он не хочет думать об управлении СХД, думать о конфигурировании и мониторинге, о планировании и сайзинге, об апгрейдах и прочем. Он просто хочет сервис. При этом вы получаете одни и те же возможности управления данными доступные во всех крупнейших облачных поставщиков Amazon Web Services, Azure и Google Cloud Platform. Так что даже если вы переносите в облако ваши унаследованные приложения, то сможете использовать преимущества быстрого выделения ресурсов, ведь создание и выделение 100ТБ выполняется всего за 8 секунд. В этом подходе вы оплачиваете только используемые ресурсы и переходите от капитальных к операционным затратам.

Важен еще один вопрос, с которого мы начинали, – зачем потребителям нужен Cloud Volumes и что это дает гиперскейлерам? Почему нельзя просто использовать родной сервис облачного провайдера? Ведь у них тоже есть сервис, который дает файловый доступ внутри облака.

В случае Elastic File Services (EFS) в облаке Amazon вы получаете ограниченную поддержку NFSv4.1, но у вас нет SMB или NFSv3, нет резервных копий, snapshot и клонов, нет Kerberos и нет ACL. У вас есть ограничения по числу файловых систем на один аккаунт и есть известные проблемы с производительностью. Есть огромное число заказчиков для которых несмотря на все вышесказанное EFS является приемлемым, но есть и заказчики более искушенные и требовательные.

Далее в случае Azure File Storage у вас невысокая производительность для SMB3 service, и нет поддержки NFS. Есть Snapshot, как технологический preview, но это все еще далеко от возможностей ONTAP.

Используя Cloud Volumes, вы получаете полный набор функциональности систем ONTAP в сочетании с высокой производительностью, надежностью и традиционной возможностью интеграции с приложениями.

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

CNews: Что-то вроде тюнинга автомобиля?

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

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

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

Когда же он переходит в Cloud Volumes ONTAP, в облаке живет приблизительно та же программно-определяемая СХД. Конечно многие задачи, связанные, например, с выделением ресурсов, управлением железа и прочее, берет на себя гиперскейлер и автоматизиция. Но на нас, как на потребителе, остается мониторинг производительности, а только после этого мы можем заняться собственно полезными вещями – создавать тома, выделять их для приложений...

В случае с Cloud Volumes Services, все операции, кроме выделения томов, их монтирования, делает за пользователя кто-то другой, обычно – поставщик сервиса.

CNews: Как сориентироваться заказчику, какой вариант Cloud Volumes Services, Cloud Volumes ONTAP или собственное СХД ему выбрать?

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

CNews: Каких причин?

Роман Ройфман: В некоторых случаях – это цена, в других – вопросы безопасности и контроля данных. Для многих компаний утечка данных означает катастрофу, поэтому такие заказчики предпочитают хранить информацию у себя. Но попробовав облако, от него уже сложно отказаться, так рождается гибридная история, когда данные остались в собственных ЦОД, а вычислительные мощности по мере необходимости арендуются у одного или нескольких гиперскейлеров.

Но нам кажется, что большинство потребителей Cloud Volumes – это пользователи новых приложений. Не те, кто переносят в облако уже существующие, а те, кто пишут cloudnative приложения, которые разрабатываются специально с таким расчетом, что будут работать в том или ином облаке. Они готовы потреблять ресурсы именно как сервис, для них это естественно.

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

CNews: В вашем решении StorageGRID используется технология объектного хранения данных. За счет чего в ней достигается высокая скорость обработки данных?

Роман Ройфман: StorageGRID – отличная система объектного хранения. В одном или нескольких ЦОДах вы можете создать свое облако хранения объектов, которое будут говорить на том же самом языке протокола S3, что и сервис хранения объектов у Amazon. Причем наша реализация максимально совместима с решение Amazon S3.

Давайте посмотрим один возможный сценарий – вы записываете в локальную объектную СХД на своем ЦОДе фотографию в виде объекта. Сразу же после этого сработает триггер о том, что появился новый объект с определенным префиксом. Он за собой потянет вызов Lambda-функции для копирования изображение в AWS S3 и запуск распознавания образов например, Amazon Rekognition. Rekognition определит, кто это у вас на фотографии – мужчина это или женщина, какие эмоции испытывает, каков его или ее возраст. Полученный результат возвращается в локальный ЦОД, где записывается в метаданные хранимого локально объекта.

Также вы можете интегрировать возможности поиска с метаданным объекта например, с помощью ELK стека. То есть, если вы в собственное хранилище записали объект, то для его обработки можете использовать почти всё богатство сервисов, обычно доступное внутри Amazon или Azure, но продолжать хранить объекты локально.

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

CNews: За счет каких механизмов облачные интеллектуальные сервисы снижают стоимость владения?

Роман Ройфман: Сложный вопрос, напрямую любое облачное решение будет дороже. Облако становится дешевле только в долгосрочной перспективе или если вы рассматриваете совокупную стоимость владения, когда не надо строить свой ЦОД, нести расходы по его эксплуатации, и т.д.

CNews: Следующая тема – технология NVMe. Чем она так хороша, почему многие начинают ее использовать?

Роман Ройфман: C NVMe интересная история. Мы жили очень долго с использованием SCSI-протокола, более 30 лет с середины восьмидесятых. Большинство новых протоколов базировались на нем. И вот сейчас настало время NVMe – это новый протокол, Он принципиально отличается от предшественников, он больше не базируется на SCSI. И если старый SCSI создавался изначально для медленных устройств, то NVMe сразу создавался для быстрых носителей.

Такая, кажется, банальная вещь, как протокол, очень важна. Это как язык, на котором мы общаемся с устройствами. А как мы знаем из гипотезы лингвистической относительности или гипотезы Сепира-Уорфа, язык определяет сознание и возможности, которыми мы можем пользоваться. Например, когда мы начали использовать технологию Fiber-Channel, NetApp смогла построить решение метрокластер, которое почти десятилетие было уникальным в индустрии. Это решение стало возможным в первую очередь благодаря протоколу.

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

CNews: Чем отличается «простой» NVMe от NVMe over fabric?

Роман Ройфман:

Как я сказал выше NVMe – это способ подключения носителей. Грубо говоря, интерфейс для SSD. Многие производители пытаются сказать, что это инновация, но мы так не думаем. Это в принципе не сложный шаг. Мы сами являемся одним из лидеров в поставках NVMe носителей в составе систем хранения и поставили десятки петабайт таких носителей за последний год. И если раньше мы использовали их в основном для кеширования внутри наших систем, то сейчас мы используем их и для хранения данных.

NVMe over fabric – это уже история быстрого подключения СХД к серверам. NVMe over fabric очень заметно снижает задержку для работы с приложением. Недавно Demartek провел тестирование влияния протокола на производительность СХД. Для чистоты эксперимента тестирование проводилось на один и том же оборудовании. В качестве СХД была взята наша предыдущая флагманская линейка NetApp AFF A700, одни и те же 32Гбит коммутаторы Brocade, а для генерации нагрузки использовались четыре сервера под управлением SUSE Linux Enterprise Server (SLES).

Для оценки влияния протокола один из контролеров подключали по fiber-channel, а второй по протоколу NVMe over FC. В результате производительность значительно выросла – наблюдалось увеличения числа IOPS на 50% и снижение задержки на 30%. Разумеется, для разных систем результаты могут разниться. Получается, что ничего не перестраивая, только изменяя способы подключения, поменяв протокол, на том же оборудовании можно получить прирост производительности до 50%.

Скорости растут драматически – если ранее нас устраивала работа CХД c задержкой порядка 1 миллисекунды, то с переходом на NVMe over fabric мы можем говорить о сотнях микросекунд. Мы горды, что были первой системой хранения уровня предприятия где была реализована поддержка протокола NVMe over fabric были наши системы NetApp EF570, которые позволили приложениям после перехода на новый протокол работать с задержкой менее 150 микросекунд.

На наш взгляд, просто поддержка носителей NVMe или поддержка протокола NVMe over fabric – это не достаточно. Это только отдельные шаги. Важно иметь end-to-end NVMe СХД, в которой новая технология используется, как для подключения серверов, так и для подключения носителей. И мы здесь тоже оказались первыми и представили первую end-to-end NVMe СХД NetApp AFFA800. Более того, эта модель еще стала первая системой хранения уровня предприятия с поддержкой 100Гбит Ethernet.

А в дальнейшем NVMe безусловно повлияет на архитектуру систем хранения в целом. Мы поменяли на СХД протоколы для back-end и front-end на NVMe. Что дальше?

Первая вещь, которую нужно будет учесть, что NVMe позволяет использовать не только SSD на стороне сервера. Там появляются другие носители – Persistent memory, SCM-устройства. Они станут кэширующим или быстрым слоем для оперативного хранения данных, которые будут ускорять классические ALL Flash СХД, в том числе и подключенные по NVMe over fabric. Мы опять возвращаемся к концепции многоуровневого хранения, но на новом витке развития технологий.

CNews: То есть, мы выбираем место хранения, чтобы работа СХД съедала как можно меньше времени и как можно меньше ресурсов?

Роман Ройфман: Да. Даже сверхбыстрая NVMe-система, о которой мы сейчас говорим как о новинке, в архитектуре следующего поколения будет медленным слоем. Самые востребованные, самые горячие данные будут оставаться на сервере, рядом с процессором сервера. А менее горячие данные будут уходить на внешнее хранение. А уже от туда совсем «остывшие», «холодные» и «замороженные» данные в виде объектов будут уходить в облачную структуру. Почти все элементы этого паззла уже здесь – NVMe, NVMe over Fabric, FabricPool, объектное хранение StorageGRID WebScale.

Метафорически можно сказать, что уже сейчас наша СХД разговаривает на «клингонском» (NVMe) и на облачном «языке Высоких Эльфов» (AWSS3). И мы опять возвращаемся к аналогиям когнитивной лингвистики, и тому как используемые языки влияют на реальность, и как протоколы влияют на архитектуру CХД.

CNews: Под занавес немного футурологии. Куда будут дальше развиваться СХД?

Роман Ройфман: Думаю в том направлении, о котором я только что рассказал. Управление данными не будет больше ограничено какой-то коробкой. Будет управление данными внутри системы хранения, оно будет расширятся и захватит ресурсы сервера. Так что вы уже не сможете четко провести грань между тем, где у вас работает управление данными. Далее мы задействуем ресурсы внутри облака. Это как конструктор LEGO, кирпичики собираются в красивую картину, в которой мы видим свое достойное место.

Новости

Все новости

Интервью

Фёдор Прохоров:

Сбер дает доступ к своему облачному суперкомпьютеру и искусственному интеллекту

Облака из тренда превратились в норму жизни, но это не значит, что новым облачным провайдерам больше нечем удивить публику. О том, как Сбер делится своими наработками с другими компаниями и даже государством.
Развернуть