Abstract: О новом тренде — software defined strorge и главной родовой травме блочных устройств — обещании бесконечной надёжности.

Лирика

На горизонте новый buzzword: Software defined $thing. Мы уже имеем состоявшийся и сформировавшийся круг всего, относящегося к software defined networks (SDN), пришла очередь и storage (SDS). Видимо, дальше у нас будет software defined computing или ещё что-то подобное, потом резко всполошатся и подтянутся HP/VMWare и предложат (private) «software defined enterprise», который будет означать всё тоже, что было, но ещё моднее и актуальнее.

Впрочем, рассказ не про баззворды. За каждым таким странным названием (grid, elastic, cloud) стоит дальнейшее развитие технологий — построение дальнейших слоёв взаимодействия компонент (эм… взаимодействия участников взаимодействия, иначе не скажешь), основным мотивом которых является уход от гранулированности компьютерной системы, так, чтобы вся терминология, вся предметная область ушла от «межпроцессного взаимодействия» и стала автономной. В более-менее приличном виде мы это (в виде уже свершившегося факта) мы видим в волшебном мире javascript работе www, когда нас никаким образом не волнуют сервера, на которых крутятся задачи — всё общение происходит на уровне между браузером (с учётом его интимных подробностей DOM, JS и т.д.) и абстракцией, под названием URI, которой не важно — один это сервер или сотни разных.

Это взаимодействие выглядит очень соблазнительным, так что его распространяют на все остальные области, по мере возможности.

Перед рассказом про SDS, посмотрим на уже состоявшееся: SDN (software defined network).

В последнее время набирает популярность идея SDN (Software-defined Networking). На фоне данной концепции, а может и под её влиянием, развивается идея и SDS – Software Defined Storage. Данное направление выглядит перспективным и начинает активно развиваться, к примеру, выход в бета версии VSAN.

Здравствуйте, уважаемые читатели!

Современные облака, используемые для целей хостинга, высоко поднимают планку требований к инфраструктуре хранения данных. Чтобы клиент получил качественную услугу, системе хранения данных должен быть присущ целый ряд свойств:

• высокая надежность хранения
• высокая доступность данных, то есть минимальное время простоя при авариях
• высокая скорость доступа и минимальные задержки
• низкая удельная стоимость хранения
• различные прикладные возможности: клонирование, снимки состояния и т.д.

Ни RAID-массивы, ни «железные» СХД не способны решить все перечисленные задачи одновременно. Именно поэтому все большее распространение в индустрии хостинга приобретает Software-defined storage. Одним из ярких представителей SDS является распределенное хранилище под названием Ceph.

Мы решили рассказать об этом замечательном продукте, который используется в CERN, 2GIS, Mail.ru и в нашем облачном хостинге.

Проект любой сложности, как ни крути, сталкивается с задачей хранения данных. Таким хранилищем могут быть разные системы: Block storage, File storage, Object storage и Key-value storage. В любом вменяемом проекте перед покупкой того или иного storage-решения проводятся тесты для проверки определённых параметров в определённых условиях. Вспомнив, сколько хороших, сделанных правильно растущими руками проектов прокололись на том, что забыли про масштабируемость, мы решили разобраться:

• Какие характеристики Block storage и File storage нужно учитывать, если хотите, чтобы при росте проекта система хранения выросла вслед за ним
• Почему отказоустойчивость на software уровне надежнее и дешевле, чем на hardware уровне
• Как правильно проводить тестирование, чтобы сравнивать «яблоки с яблоками»
• Как получить на порядок больше/меньше IOPS, поменяв всего один параметр

В процессе тестирования мы применяли RAID–системы и распределенную систему хранения данных Parallels Cloud Storage (PStorage). PStorage входит в продукт Parallels Cloud Server.

Мы часто писали про кластеры в коробке и Windows Storage Spaces и самый частый вопрос — как выбрать правильную конфигурацию дисков?

Традиционный вопрос обычно выглядит так:

— Хочу 100500 IOPS!

или:

— Хочу 20 терабайт.

Потом выясняется, что IOPS на самом деле нужно не так много и можно обойтись несколькими SSD, а с 20 терабайт (4 диска по нынешним временам) хотят снять весьма прилично, и в реальности это получится многоуровневое хранилище.

Как подойти к этому правильно и спланировать заранее?

Нужно последовательно ответить на несколько ключевых вопросов, например:

• Приоритет защиты целостности данных (например при сбое диска).
• Требуется производительность, но не ценой защиты.
• Умеренные требование к ёмкости.
• Размер бюджета для построения смешанного решения.
• Удобство управления и мониторинга.

Современные сети и дата-центры бодро шагают к полной и тотальной программно-определяемой схеме, когда фактически неважно, какое железо вы напихаете внутрь, всё будет на софте. У сотовых операторов это началось с того, что им не хотелось ставить по 20 антенн на дом (у них узлы переконфигурируются, меняют частоты и параметры просто обновлением конфига), а в дата-центрах сначала с виртуализации серверов, которая теперь мастхэв, а потом продолжилось и виртуализацией хранилищ.

Но вернёмся в Россию 2015 года. Ниже я покажу, как «из подручных средств» (x86 машин и любых «хранилок») сэкономить денег, повысить надёжность и решить ещё ряд типовых для сисадминов среднего и крупного бизнеса задач.


На этой схеме видны обе архитектуры, о которых пойдет речь. SDS — два красных контроллера в центре с любым бекэндом, от внутренних дисков до FC полок и облаков. И виртуальный SAN, на схеме Hyper-converged storage.

Самое главное:

• Вам плевать, что за железо стоит: диски, SSD, зоопарк производителей, старые и новые модели… — всё это отдаётся оркестирующему софту, и он приводит это к той виртуальной архитектуре, которая вам нужна в итоге. Грубо говоря, объединяет в один том или позволяет нарезать как вам удобно.
• Вам плевать, какие интерфейсы у этих систем. SDS построится сверху.
• Вам плевать, какие функции ваши хранилки могли, а какие не могли (опять же, теперь они могут то, что надо: решает софт сверху).

Заодно рассмотрим пару типовых задач с конкретным железом и ценами.

Всем доброго времени суток, уважаемые читатели!

Давненько я не писал на Хабре – и времени не было, и мыслей тоже было не густо… Но мысли – это динамический поток, если есть что «на вход» — то появится и «выход». И вот, наблюдая за тенденциями в IT, посмотрев вокруг, назрели мысли: все мы, инфраструктурщики, медленно и верно катимся в Software Defined Computing, т.е. парадигма проприетарного железа сменяется программными решениями поверх стандартных компонентов. У нас появляются SDN (Software Defined Networking), SDS (Software Defined Storage), ну а SDC – это по сути абстракция на базе гипервизора или контейнеризации…

Сегодня я хотел бы затронуть решения в области SDS – и уже за пределы решений Microsoft, мне хотелось посмотреть на сторонние партнерские решения и посмотреть есть ли там жизнь вообще… Сразу обращу Ваше внимание, что я буду вести повествование о Windows-мире, по старой привычке и большей области компетенции, нежели red-eye story… (смайл)
Первое, что мне пришло в голову – это StarWind. Программные решения StarWind я хорошо помню еще со времен Windows Server 2003 (- царство ему бинарное), тогда это был простой и эффективный способ сделать недорогое блочное хранилище из простого сервера с жесткими дисками, а не мутить-покупать дорогую СХД… Все течет, все меняется – в одну реку не войти дважды. Такой функционал со временем появился и в самом Windows Server, да и сейчас эра облаков на дворе, а облако всегда натягивается и растягивается поверх инфраструктуры – и я вспомнил про StarWind, думаю: «дайка я посмотрю, может у них есть что интересное?..» И я не прогадал, решение интересное действительно есть и имя ему StarWind Virtual SAN.

Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.

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

Это было чертовски долго, но всё прошло спокойно.

ONTAP Select это логическое развитие линейки Data ONTAP-v, т.е. Software Defined Storage. Софт ONTAP (Операционную систему или прошивку по-народному, если хотите) можно использовать на специализированной аппаратной плтформе FAS или в виде виртуальной машины: в публичных облаках или на комодити оборудовании.
Два последних варината называют ONTAP for Cloud и ONTAP Select соответственно.

Как и предшественник ONTAP Select, этот продукт, который живёт в виде виртуальной машины и полностью опирается на традиционный RAID контроллер, установленный в вашем сервере. Поддерживаются NAS (CIFS, NFS) и IP SAN (iSCSI) протоколы и отсутствует поддержка FCP. В документах NetApp можно встретить внутренее название ONTAP Select — sDOT, это одно и тоже.

Из ожидаемых новшеств:

• Поддержка High Avalability
• Поддержка кластеризации до 4 нод
• Максимальный полезный объем 400 ТБ (по 100ТБ на ноду в 4х нодовом кластере)

На ряду с High Availability и кластеризацией по-прежнему поддерживаются однонодовые конфигурации.

Следуя современным тенденциям в индустрии хранения и обработки данных, я добрался до SDS — программно-определяемых хранилищ, а именно — продукта компании HPE под названием HPE StoreVirtual VSA, о чем и поведаю Вам в данной статье.

В прошлой статье я рассказал об основных понятиях SAN на примере небольших инсталляций. Сегодня копнем глубже и разберемся с построением сетей хранения для крупной организации. Разумеется, одна короткая статья никак не заменит объемные труды Brocade и HP, но хотя бы поможет сориентироваться и выбрать правильный курс при проектировании.

Представляю вашему вниманию первую часть серии публикаций о технологиях хранения VMware vSphere. В данной статье будут рассмотрены старые проверенные фичи, доступные еще в 4 и 5 версиях продукта.

Представляю вашему вниманию вторую часть серии публикаций о технологиях хранения VMware vSphere. В ней будут рассмотрены новые возможности, которые стали доступны в 6 версии продукта. Из-за большого объема 2я часть будет разбита на 2 статьи: часть 2.1 с описанием технологий SPBM и VAIO (данная статья), часть 2.2 с описанием VVOL (следующая статья).

Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.

Описание технологии VVOL

Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.

Site Recovery Manager (SRM)

VMware Site Recovery Manager (SRM) это решение для обеспечения непрерывности бизнеса и аварийного восстановления, предназначенное для планирования, тестирования и восстановления ВМ (виртуальных машин) с защищаемого (основного) сайта на (резервный) сайт восстановления.

SRM предлагает 3 подхода к защите (репликации) ВМ:

Введение

Передо мной была поставлена задача — развернуть кластер VMware Virtual SAN 6.2 для тестирования производительности, анализа возможностей, особенностей и принципов работы гиперконвергентной программной СХД от VMware.

Кроме того, созданный тестовый стенд должен стать платформой для разработки и апробирования методики тестирования распределенных СХД, в т.ч. для гиперконвергентных инфрастуктур (HCI).

Результатов тестирования и описания его методики в данной статье не будет, вероятно этому будет посвящена отдельная публикация.

Данная статья будет полезна специалистам, которые впервые сталкиваются с развертыванием кластера VMware Virtual SAN 6.2. Я постарался указать подводные камни, на которые можно напороться при поднятии кластера, что позволит значительно сократить время и нервы на их обход.

В данной статье я постарался раскрыть назначение VMware Virtual SAN, принципы её работы, требования, возможности и ограничения данной системы, основные рекомендации по её проектированию.

Концепция Virtual SAN

VMware Virtual SAN (далее vSAN) представляет собой распределенную программную СХД (SDS) для организации гипер-конвергентной инфраструктуры (HCI) на базе vSphere. vSAN встроен в гипервизор ESXi и не требует развертывание дополнительных сервисов и служебных ВМ. vSAN позволяет объединить локальные носители хостов в единый пул хранения, обеспечивающий заданный уровень отказоустойчивости и предоставляющий свое пространство для всех хостов и ВМ кластера. Таким образом, мы получаем централизованное хранилище, необходимое для раскрытия всех возможностей виртуализации (технологии vSphere), без необходимости внедрения и сопровождения выделенной (традиционной) СХД.

Клиентам, внедряющим твердотельные накопители текущего поколения, такие как Intel DC NVMe серии P3700, приходится справляться со сложной проблемой: поскольку пропускная способность гораздо выше, чем у дисковых накопителей, а задержки гораздо ниже, большая часть общего времени транзакций теперь приходится на работу программного обеспечения хранилища. Другими словами, производительность и эффективность всей системы хранения данных все сильнее зависят от производительности и эффективности используемого программного набора. При этом носители данных постоянно совершенствуются, в ближайшие годы их мощность превзойдет возможности программных архитектур, используемых в системах хранения данных.



Для помощи ОЕМ-производителям и поставщикам программного обеспечения в интеграции такого оборудования корпорация Intel создала набор драйверов и разработала полную архитектуру хранилища под названием Storage Performance Development Kit (SPDK). Цель SPDK — подчеркнуть высокую эффективность и производительность, достигаемые совокупностью технологий Intel в области сетей, вычислений и хранения данных. С помощью SPDK удалось продемонстрировать, что можно достичь великолепных показателей в миллионы операций ввода-вывода в секунду, используя несколько процессорных ядер и несколько накопителей NVMe без какого-либо дополнительного оборудования для разгрузки. Intel предоставляет полный исходный код эталонной архитектуры для Linux на условиях более широкой и либеральной лицензии BSD, он распространяется в сообществе через GitHub. По адресу spdk.io находятся блог, список рассылки и дополнительная документация.

В предыдущей статье мы рассказали о трендах на рынке аппаратных средств, о трансформации Lenovo и привели примеры реализованных проектов. Предлагаем вашему вниманию вторую часть рассказа об анонсе новых систем и решений Lenovo для дата-центров, где мы подробнее расскажем о платформе Intel Purley, продуктах ThinkSystem и ThinkAgile.

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

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

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