вторник, 19 января 2016 г.

JBOD. Путь Золушки

Еще 10 лет назад в корпоративной культуре хранения данных дисковых полок JBOD избегали.  Если их и ставили - то “по бедности“, начиняя внешние коробки какие получится дисками какими придется – чтобы расширить прямое адресное пространство RAID-контроллеров одиночных серверов. 

Сегодня JBOD формируют фундамент программно-определяемого хранения.

Примеры навскидку.

Windows Server 2012 R2. Сценарии производительного/масштабируемого/ценоэффективного хранения  основаны на использовании JBOD.

Hadoop – проект с открытым кодом для организации масштабируемых и распределенных вычислений, а также хранилищ файлов общего назначения с петабайтами данных. Кластеры Hadoop строят на JBOD’ах.

Рекомендуемая архитектура Exchange Server 2013 опирается на JBOD’ы.

NexentaStor – универсальная платформа программно-определяемого хранения файлового (NFS / SMB) и блочного (FC / iSCSI) доступа, с букетом сервисов. Все кластерные конфигурации - на JBOD’ах, с  десятками емких дисков в каждом.

Open-E Jovian DSS – еще один разработчик программно-определяемого хранения на ZFS. Кластеры высокой доступности данных для NFS и iSCSI строятся доступными средствами, поверх массовых JBOD с большим количеством дисков.

RAIDIX —  ПО для высокопроизводительных блочных и файловых систем хранения данных. Показательна история создания  операционной системы для высоконагруженных СХД, о мотиваторах программно-определяемого хранения в задаче, где данных (очень) много и критично быстродействие. Все поверх JBOD

Крупные поставщики решений хранения как  
DataOn Storage плетут все свои сети вокруг JBOD разных фасонов и размеров.

Разработчикам автономных СХД есть от чего плохо спать.





Место JBOD на рынке систем хранения данных

Хранилища данных становятся все более объемными и изощренными по логике обслуживания потоков ввода-вывода. Отсюда популярность программно-определяемых систем (SDS): традиционные RAID-системы не обеспечивают доступности данных, автономные СХД, с их жесткой архитектурой, плохо масштабируются по производительности и емкости, ограничены по возможностям сервисных служб. Благодаря отделению управления SDS от физической реализации серверов 

появился cпрос на JBOD (enclosures) корпоративного уровня -  контейнеры с дисками HDD большой емкости. Их роль - брутто-хранение неструктурированных данных в основании  пирамиды хранения

JBOD подключаются по интерфейсу SAS к управляющим серверам (кластерам). У прямого блочного доступа SAS к данным (как и во всех автономных СХД) минимальные задержки обращения и высокая пропускная способность. Свободу наращивания емкости дают JBOD. Логику управления и встраивание в сеть хранения обеспечивают хост-серверы (типовой архитектуры x86 под управлением выбираемого пользователем ПО хранения). Управляющие серверы могут представляться сети устройствами блочного (FC или iSCSI) или файлового (NAS) доступа - как того требуют приложения и ПО хранения. Разделение средств управления данными и физических хранилищ позволяет эластично масштабировать емкость систем хранения (JBOD), при сохранении предсказуемо низких задержек обращения к данным и высокой скорости потоковых обменов. 

На поле систем большой емкости разработчики традиционных автономных СХД проигрывают в производительности, гибкости, цене реализации.






среда, 13 января 2016 г.

От проприетарных СХД к серверам хранения открытой архитектуры

Один из сильных трендов сегодня - отказ от проприетарных (закрытых) СХД в пользу программно-определяемых систем (SDS) на серверах открытой архитектуры. EMC (30% мирового рынка СХД) инвестирует в SDS-стартапы (пример Scale IO), а другой рукой, через VMware, в VSAN  и EVO: RAIL. 
Причины? Рынок хочет:
  • Свободы физической реализации сообразно задачам пользователя (а не как решил вендор СХД);
  • Простого конфигурирования, масштабирования, модернизации типовыми компонентами (опять же, без привязки к вендору);
  • Управления производительностью и емкостью хранения в широком диапазоне;
  • Сам выбирать специализированное ПО хранения под приложения и типы данных.
Проприетарная СХД - это "черный ящик" с заданными вендором параметрами и ограничениями производительности, емкости, интерфейсов подключения. 

Схематически "черный ящик"  (обычно это двухконтроллерная СХД специфической архитектуры, с фиксированными фронтальными интерфейсами и общим тыловым набором дисков) выглядит так:

Простейшая альтернатива "черному ящику" - конструкция из двух серверов с разделяемым дисковым массивом (кластер хранения). Серверы - типовой архитектуры х86, с подбираемыми под задачу наборами дисков и внешними интерфейсами. Все работает под управлением типового ПО хранения.

Прозрачность и открытая логика построения SDS развязывают руки пользователям. 

ПО хранения обрастает свойствами куда быстрее, чем выпускаются новые поколения "черных ящиков". Разнообразные средства увеличения производительности (SSD, кэширование, tiering, RDMA, широкополосные интерфейсы) - все это доступно в серверах "с полки", если того потребуют приложения. Доступно хоть сегодня, посильно по средствам.

В целом, центростремительные системы SAN на основе закрытых СХД сдают позиции распределенным SDS:
  • Пересматриваются подходы к проектированию систем хранения, с приходом скоростных носителей и протоколов сетевых обменов;
  • Когда модель хранения строится под запросы приложений, гибкость конфигурирования становится ресурсом производительности;
  • Запас мощности современных процессоров позволяет реализовать на уровне операционных систем и их надстроек управление вводом-выводом и хранением данных c огромным набором функциональных возможностей: реализацию и восстановление RAID-массивов, многоуровневое кэширование, тонкую инициализацию, дедупликацию, компрессию, проверки состоятельности данных и т.д.




воскресенье, 10 января 2016 г.

Строим продуктивную среду 4K-видеопроизводства на 16 Гб FC


Для видеопроизводства 4К нужны большие вычислительные ресурсы: рабочих станций редактирования видео, цветокоррекции или оформления, разделяемых систем хранения большой емкости скоростного доступа. Усложняют задачу мультиплатформенноcть MacOS/Windows/Linux и ограничения унаследованного оборудования с разными протоколами подключения.
Новый проект Entry «cтудии 4K» будет интересен тем, кому приходится много хранить (сотни терабайт) и быстро пересылать потоковые данные (на скорости свыше 1 ГБ в секунду). 

Работа с видео Ultra HD требует того и другого.

Предлагаемое решение построено на хранилищах Entry Store с интерфейсом 16 Гб FC под управлением RAIDIX – ПО для высоконагруженных систем хранения медийного контента. Связь с клиентскими машинами и масштабирование обеспечивают коммутатор, хост-адаптеры и мосты 16Гб FC ATTO Technology. Контроллер метаданных Tiger Serve от Tiger Technology управляет совместным доступом групп пользователей к общим материалам в распределенной среде SAN. Сети 1-10 Гб Ethernet обслуживают потребности «второго ряда».

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