Главная » Хабрахабр » SolidFire — СХД для тех, who **cking hate storage

SolidFire — СХД для тех, who **cking hate storage

Появляется всё больше решений, которые уходят от традиционного подхода унифицированных хранилищ. Это специализированные хранилища, которые заточены под задачи определённого направления бизнеса. Ранее я уже рассказывал о системе Infinidat InfiniBox F2230. Сегодня в центре моего обзора SolidFire.

«Who f*cking hate storage» @ Дэйв Хитс, основатель компании NetApp
В конце 2015 года компания NetApp объявила о покупке стартапа SolidFire, который был основан в 2010 году. Интерес к этим системам вызван их иным подходом к управлению хранилищами данных и предсказуемой производительностью.

Также это позволило спустя полтора года выпустить на рынок и новый продукт — NetApp HCI (Hyper Converged Infrastructure), который в качестве подсистемы хранения использует SolidFire. Решения SolidFire дополнили линейку продуктов NetApp, которые включали в себя All Flash FAS (AFF), EF и E серии.

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

Дейв Райт, CEO of SolidFire, 2012

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

Сегодняшнего участника нашего обзора SolidFire также можно отнести к этому классу устройств. Не так давно я уже рассказывал о системе Infinidat InfiniBox F2230, которая прекрасно подходит для задач сервис- провайдеров. В попытке решить эту задачу и родился SolidFire. Основатель SolidFire Дейв Райт со своей командой — выходцы из RackSpace, где они занимались разработкой эффективной системы хранения, которая обеспечивала бы линейную производительность в среде со множеством пользователей, при этом была простой, легко масштабируемой и обладающей гибкими возможностями автоматизации.

На сегодняшний день линейка SolidFire состоит из четырех моделей с разным соотношением IOPS/TB.

Для хранения данных используются 10 (MLC) SSD, а в качестве NVRAM — Radian RMS-200. Правда, уже есть планы по переходу к модулям NVDIMM.

Здесь интерес представляет то, как SolidFire получает и хранит данные. Все мы знаем про ограниченный ресурс SSD накопителей, поэтому логично, что для их наибольшей сохранности компрессия и дедупликация должны происходить на лету, до записи на SSD. Когда SolidFire получает данные от хоста, он разбивает их на блоки 4КБ, после чего этот блок сжимается и сохраняет в NVRAM. Затем происходит синхронная репликация этого блока в NVRAM на «соседнюю» ноду кластера. После этого SolidFire получает хэш данного сжатого блока и ищет этот хеш- значение в своем индексе сохраненных данных в рамках всего кластера. Если блок с таким хэшем уже существует, SolidFire обновляет только свои метаданные со ссылкой на данный блок, если же блок содержит уникальные данные, он записывается на SSD, и также для него записываются метаданные. Этот механизм хранения данных и метаданных очень похож на механизм работы объектного хранилища.

Наш тестовый кластер из четырех нод

Стоит отметить одну очень важную вещь — кластер SolidFire способен работать с нодами как с разной «плотностью IOPs/TB», так и объединять в рамках одного кластера ноды разных поколений. Уже появились слухи, что в скором времени произойдёт обновление этой линейки. имеется поддержка как Scale Out, так и Scale Back. Во-первых, это делает использование данной системы более предсказуемой в плане поддержки оборудования, а также облегчает процесс перехода со старых нод на новые, когда вы просто добавляете новые и удаляете старые из кластера в режиме реального времени (дожидаясь только перестроения кластера) без простоев, т.к.

SolidFire может поставляться в виде трех решений:

  • SolidFire в качестве самостоятельного продукта, на базе серверов Dell/EMC,
  • как часть FlexPod SF на серверах Cisco,
  • как часть NetApp HCI на его платформе.

Как вы могли заметить из таблицы характеристики, ноды поддерживают только подключение по iSCSI, а для соединения по FC есть отдельный тип нод — Fabric Interconnect, который в свою очередь содержит четыре порта для данных по FC и четыре порта iSCSI для подключения к нодам, а также 64GB собственной системной памяти/кэша на чтение.

В таблице характеристик указана и производительность каждой из нод. Это один из тех случаев, когда вы знаете производительность свой системы хранения данных ещё на этапе покупки. Данная производительность является гарантированной (при профиле нагрузки 4Kb, 80/20) на каждую ноду.

Конечно, вы можете выжать из каждой ноды и большую производительность при определённых условиях, но это не то, для чего данное решение разрабатывалось. Соответственно, покупая кластер из X нод или расширяя существующее решение, вы понимаете, какой объём и какую производительность вы получите в конечном итоге. Наибольшую производительность на SolidFire можно получить при большом количестве томов и сессий. Если вы хотите получить миллионы IOPS в 2U на единственном томе, вам лучше обратить своё внимание на другие продукты, к примеру на AFF.

Главная страница интерфейса

Фактически у нас есть два пула ресурсов: объём и IOPS’ы. Управление хранилищем довольно просто. Это опять-таки делает расширение системы крайне простым занятием. Выделяя один из типов ресурсов и зная их конечное количество, мы чётко понимаем другие возможности нашей системы. Рассматриваем SF4805 или SF19210 с «менее плотным» соотношением IOPS/TB. Нужна дополнительная производительность? Смотрим в сторону SF9605 и SF38410, которые предоставляют меньше IOPS на Gb. Нужен объём?

Такие вещи, как дедупликация и компрессия, работают по умолчанию. С точки зрения администратора СХД, система смотрится довольно скучно.

Именно эта простота, на мой взгляд, и раскрывается за цитатой Дэйва Хитса из заголовка статьи. Репликация и снепшоты также имеются, причём репликация может быть организована для всей линейки продуктов NetApp (кроме E-серии). Но об интеграции мы ещё поговорим. Учитывая, что данная система предполагает интеграцию с различными системами динамического выделения ресурсов, без участия администратора и без дополнительных трудозатрат, в скором времени вы вообще забудете, как выглядит интерфейс SolidFire.

Не то, чтобы мы не верили вендору, но привыкли всё пробовать самостоятельно. Мы в «Онланте» провели нагрузочное тестирование, дабы удостовериться в обещанных 200k IOPS. Также мы смогли убедиться на собственном опыте, что система даёт хороший результат именно при большом количестве потоков. Мы не ставили перед собой целью выжать из системы больше, чем было заявлено. Уже на этапе подготовки тестовой среды мы были приятно удивлены работой дедупликации. Для этого мы организовали на SolidFire 10 томов по 1ТБ, на котором разместили по одной тестовой виртуальной машине. Диски перед тестами заполнялись случайными данными. Несмотря на то, что схема его работы довольно стандартна, качество работы в рамках кластера оказалось крайне эффективным.

Причём на каждой виртуальной машине этот блок генерировался отдельно, т.е. Чтобы это было быстрей, генерировали блок в 10 мб, потом им заполняли. Из 10ТБ заполненных данными — реально занятого пространства на массиве было 4ТБ. во всех машинах паттерн разный. 5, на FAS при таком подходе эффективность инлайн дедупликации стремилась к 0. Эффективность дедупликации — 1:2. Мы смогли получить 190k IOPS при отклике ~1 мс на нашем тестовом стенде.

Хочется отметить, что архитектурные особенности решения не позволяют получить высокий уровень производительности на небольшом количестве потоков. Один небольшой лун или всего одна тестовая виртуальная машина не смогут показать высоких результатов. Получить данное количество IOPS мы смогли при использовании всей ёмкости системы и при постепенном увеличении количества виртуальных машин, создающих нагрузку при помощи fio. Увеличивали мы их количество до того момента, как задержки не стали превышать 1,5 мс, после чего остановились и сняли показатели производительности.

Как я уже говорил ранее, перед запуском тестов мы заполняли диски рандомными данными. На производительности сказывается и заполненность дисковой подсистемы. Если же запустить тест без предварительного заполнения дисков, производительность будет намного выше при том же уровне задержек.

Мы также провели и наш любимый тест на отказоустойчивость путём выключения одной из нод. Чтобы получить наилучший эффект, для отключения была выбрана Master-нода. Ввиду того, что каждый сервер-клиент устанавливает собственную сессию с нодой кластера, а не через какую-то единую точку, то при отключении одной из нод деградируют не все виртуальные машины, а только те, которые работали с данной нодой. Соответственно со стороны СХД мы видим лишь частичное падение производительности.

Конечно, со стороны хостов виртуализации на некоторых дата-сторах падение производительности было до 0. Но уже в течение 30 секунд работоспособность была восстановлена без потери в производительности (стоит учитывать, что нагрузка в момент падения была на уровне 120k iops, которую потенциально способны выдать три ноды из четырех, соответственно потери в производительности мы и не должны были увидеть).

Со стороны SolidFire при этом началось перестроение массива. Таймер немного врёт, и процесс занял около 55 минут, что укладывается в обещанный вендором час. При этом нагрузку с СХД никто не убирал, и она оставалась на том же уровне в 120k IOPS.

Кластер поддерживает одномоментный выход из строя одной ноды, после чего запускается процесс ребилда кластера. Отказоустойчивость обеспечивается не только на уровне диска, но и на уровне ноды. При этом стоит учитывать, что при выходе из строя ноды вы теряете как в производительности, так и в объёме полезного пространства. Учитывая использование SSD и что в ребилде участвуют все ноды, восстановление кластера происходит в течение часа (ребил при отказе диска занимает около 10 минут). Минимальный размер кластера — четыре ноды. Соответственно вам всегда нужно иметь в запасе свободное пространство в размере одной ноды. Данная конфигурация позволит вам избежать неприятностей при выходе из строя одной из ноды до того момента, как вы ждёте приезда замены.

Для того, чтобы иметь доступ к историческим данным, вам необходимо развернуть так называемую Management Node, которая занимается тем, что берёт данные по API с SolidFire и заливает их в Active IQ. Как и на большинстве СХД, мониторинг производительности здесь отображается только в реальном времени. Вы имеете возможность работать с данными о производительности, эффективности, в том числе и с прогнозами роста. Если вы уже работали с системами NetApp, то наверняка уже могли сталкиваться с этим порталом. При чём вы можете получить доступ к этим данным даже со своего мобильного устройства, находясь где угодно в мире.

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

Как можно видеть, типы данных и гарантированный коэффициенты у них немного отличаются. К примеру, у SolidFire есть именно наш случай — Virtual Infrastructure с коэффициентом 4:1. И это без учёта использования снепшотов.

В основе архитектуры решения стоит Quality of Service (QoS), который собственно и позволяет добиться гарантированной производительности для каждого из томов.

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

  • Использование All-SSD позволяет добиться низких показателей задержки для I/O.
  • Scale-out легко прогнозирует показатели производительности.
  • Отсутствие классического RAID — предсказуемая производительность при
  • сбоях оборудования
  • Сбалансированное распределение нагрузки исключает появление узких мест в системе.
  • QoS помогает избегать «шумных соседей».

Помимо возможности задания максимальной и минимальной производительности, есть возможность предоставить тому производительность за рамками максимального ограничения (Burst). Каждый том имеет некую условную систему кредитов. Когда его производительность находится ниже максимальной отметки, ему начисляются эти кредиты, благодаря которым, на некоторое количество времени он может преодолеть максимальную отметку производительности. Такой подход позволяет размещать в хранилище большое количество приложений, требующих высокой производительности, и при этом уберечь их от негативного влияния друг на друга. Самое интересное, что QoS поддерживают не только на уровне томов массива, но и на уровне VVol’ов VMware, что позволяет гранулярно выделять ресурсы под каждую виртуальную машину. Полная поддержка VAAI и VASA API обеспечивает тесную интеграцию массива с виртуализатором.

Говоря об интеграции, решением от VMware всё далеко не заканчивается.

SolidFire, пожалуй, можно назвать наиболее автоматизируемой СХД, которая способна интегрироваться с любыми современными системами, системами виртуализации/контейнеризации, поддерживает системы управления конфигурациями, SDK есть для различных языков.

И так нам нужно создать 15 томов объёмом 1Тб, а на выходе получить их iqn, который мы передадим администраторам VMware для добавления датасторов. Я, как всегда, смотрю первым делом SDK для Python, при помощи которого я автоматизирую собственные рабочие процессы. У нас уже есть созданные предварительно аксес группы, в которых прописаны наши хосты VMware и заранее созданная политика QoS.

#!/usr/bin/env python
# -*- coding:utf-8 -*- from solidfire.factory import ElementFactory sfe = ElementFactory.create('ip', 'log', 'pass') for i in range(1,51): create_volume_result = sfe.create_volume(name='vol'+str(i), account_id=2, total_size=1099511627776, enable512e=True, qos_policy_id=1) id = create_volume_result.volume_id sfe.add_volumes_to_volume_access_group(volume_access_group_id=2, volumes=[id]) volumes = sfe.list_volumes(accounts=[2], limit=100).volumes
for volume in volumes: print volume.iqn

Или вот более подробное видео «Python SDK Demo» от самой SolidFire:

Такой подход к автоматизации делает SolidFire удобным не только для облачных провайдеров и аналогичных задач, но в соответствии с концепцией непрерывной интеграции и доставки (CI/CD) позволяет оптимизировать процесс разработки.

Как я упоминал — WebUI работает через API, и вы можете посмотреть все запросы и ответы через API Log.

К примеру, цикл «Comparing Modern All-Flash Architectures». Если вам интересно узнать больше о SolidFire, о его сравнении с конкурентами, о работе с системой и т.д., из полезного хочу порекомендовать их YouTube канал, на котором довольно большое количество полезного видео.

Это позволяет использовать снепшоты в качестве резервных копий и хранить их на внешних хранилищах как на вашей площадке, так и на внешних ресурсах, например, в Amazon. Из приятных возможностей системы можно назвать встроенный механизм резервного копирования снепшотов во внешнее S3 совместимое хранилище. Есть ещё один интересный момент — вы можете заливать данные в S3 хранилище в двух вариантах: Конечно, такой подход сложно назвать гибким, с точки зрения восстановления данных, но для некоторых случаев такое решение может быть полезно и вполне применимо.

  • Native — в данном случае будут заливаться уже дедуплицированные данные, но при этом восстановить этот том можно будет только на ту же систему, с которой он залит.
  • Uncompressed — здесь уже заливается полный набор блоков, что позволяет восстановить данный лун на любом другом кластере SolidFire.

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

Кстати, Артур, ведёт прекрасный Telegram-канал для всех, кто хочет быть в курсе новостей storage- направления и NetApp в частности. Отдельную благодарность в проведении тестирования хочу выразить Евгению Красикову из NetApp и Артуру Аликулову из «Мерлиона». В нём можно найти огромное количество полезных материалов, а кому мало просто почитать, а хочется ещё и пообщаться, есть ещё и чат storagediscussions.

в Hyatt Regency Petrovsky Park, где мы с Артуром будем говорить о SolidFire на одной из сессий. Если у вас остались вопросы или вдруг появились новые, приглашаю вас посетить NetApp Directions 2018, которая пройдет 17 июля 2018 г. Регистрация на мероприятие и все подробности.

А ещё в нашей компании есть вакансия.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Образ современного тестировщика. Что нужно знать и уметь

Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования. Бытует мнение, что простейший путь к IT лежит через тестирование. Сейчас же ...

[Из песочницы] Нейронная сеть с использованием TensorFlow: классификация изображений

Привет, Хабр! Представляю вашему вниманию перевод статьи «Train your first neural network: basic classification». Для создания нейронной сети используем python и библиотеку TensorFlow. Это руководство по обучению модели нейронной сети для классификации изображений одежды, таких как кроссовки и рубашки. Установка ...