Появляется все больше и больше решений, которые отходят от традиционного подхода к унифицированному хранению данных.
Это специализированные складские помещения, адаптированные под задачи конкретного направления бизнеса.
Ранее я рассказывал о системе Infinidat InfiniBox F2230. Сегодня в центре моего обзора SolidFire. 
«Кто, черт возьми, ненавидит системы хранения данных» @ Дэйв Хит, основатель NetApp
В конце 2015 года NetApp объявила о покупке стартапа SolidFire, основанного в 2010 году.
Интерес к этим системам обусловлен разным подходом к управлению хранением данных и предсказуемой производительностью.
Решения SolidFire дополняют линейку продуктов NetApp, в которую входят серии All Flash FAS (AFF), EF и E. Это также позволило через полтора года вывести на рынок новый продукт — NetApp HCI (Hyper Converged Infrastructure), использующий SolidFire в качестве подсистемы хранения данных.
«Мы разрабатываем новую систему хранения данных, предназначенную для очень крупных центров обработки данных облачных вычислений.В последнее время появляется все больше решений, уходящих от традиционного подхода унифицированного хранилища, способного решить любую задачу, к специализированному СХД, предназначенному для решения задач конкретного направления бизнеса.По сути, идея заключается в том, что многие компании переносят вычисления из своих офисов или собственных центров обработки данных в эти крупные вычислительные облачные центры обработки данных, где у них есть десятки тысяч клиентов, и вся их информация консолидируется в одном месте.
Поэтому мы создаем новую систему хранения данных, предназначенную для обслуживания этих крупных центров обработки данных».
Дэйв Райт, генеральный директор SolidFire, 2012 г.
Не так давно Я уже рассказывал о системе Infinidat InfiniBox F2230. , который идеально подходит для задач поставщиков услуг.
К этому классу устройств можно отнести и сегодняшнего участника нашего обзора SolidFire. Основатель SolidFire Дэйв Райт и его команда пришли из RackSpace, где они разработали эффективную систему хранения, которая обеспечивает линейную производительность в многопользовательской среде, будучи при этом простой, легко масштабируемой и с гибкими возможностями автоматизации.
В попытке решить эту проблему родился SolidFire.
Сегодня линейка SolidFire состоит из четырех моделей с разным соотношением IOPS/TB. 
10 (MLC) используются для хранения данных, а в качестве NVRAM используется Radian RMS-200. Правда, уже есть планы по переходу на модули NVDIMM .
Самое интересное здесь то, как SolidFire получает и хранит данные.
Все мы знаем об ограниченном ресурсе SSD-накопителей, поэтому логично, что для их наибольшей безопасности сжатие и дедупликация должны происходить на лету, до записи на SSD. Когда SolidFire получает данные от хоста, он разбивает их на блоки по 4 КБ, после чего блок сжимается и сохраняется в NVRAM. Затем происходит синхронная репликация этого блока в NVRAM на «соседний» узел кластера.
Затем SolidFire получает хэш сжатого блока и ищет хэш-значение в индексе хранимых данных на уровне кластера.
Если блок с таким хэшем уже существует, SolidFire обновляет только его метаданные ссылкой на этот блок, но если блок содержит уникальные данные, он записывается на SSD, и для него также записываются метаданные.
Этот механизм хранения данных и метаданных очень похож на то, как работает объектное хранилище.
Наш тестовый кластер из четырех узлов
Уже появились слухи, что эта линейка скоро обновится.
Стоит отметить одну очень важную вещь — кластер SolidFire способен работать как с узлами с разной «плотностью IOP/TB», так и объединять узлы разных поколений в рамках одного кластера.
Во-первых, это делает использование данной системы более предсказуемым с точки зрения аппаратной поддержки, а также облегчает процесс миграции со старых узлов на новые, когда вы просто добавляете новые и удаляете старые из кластера в реальном времени (ожидая только чтобы кластер пересобрался) без простоя, т.к.
есть поддержка как Scale Out, так и Scale Back. SolidFire доступен в трех решениях:
- SolidFire как отдельный продукт на базе серверов Dell/EMC.
- в составе FlexPod SF на серверах Cisco,
- как часть NetApp HCI на своей платформе.
а также 64 ГБ встроенной системной памяти/кэша чтения.
В таблице характеристик также указана производительность каждого узла.
Это один из тех случаев, когда производительность вашей СХД вы знаете еще на этапе покупки.
Такая производительность гарантирована (при профиле нагрузки 4Кб, 80/20) для каждого узла.
Соответственно, покупая кластер из Х узлов или расширяя существующее решение, вы понимаете, какой объем и какую производительность вы в конечном итоге получите.
Конечно, при определенных условиях можно выжать больше производительности из каждого узла, но данное решение создано не для этого.
Если вы хотите получить миллионы операций ввода-вывода в секунду в форм-факторе 2U на одном томе, вам лучше присмотреться к другим продуктам, например AFF. Наилучшую производительность в SolidFire можно получить при большом количестве томов и сеансов.
Главная страница интерфейса
Управление хранилищем довольно простое.
Фактически у нас есть два пула ресурсов: том и IOPS. Выделяя один тип ресурсов и зная их конечное количество, мы четко понимаем и другие возможности нашей системы.
Это снова делает расширение системы чрезвычайно простым.
Нужна дополнительная производительность? Рассмотрим SF4805 или SF19210 с «менее плотным» соотношением IOPS/TB. Нужен объем? Мы смотрим в сторону SF9605 и SF38410, которые обеспечивают меньше IOPS на Гбит. С точки зрения администратора СХД система выглядит довольно скучно.
Такие вещи, как дедупликация и сжатие, работают по умолчанию.
Также доступны репликация и снапшоты, причем репликацию можно организовать для всей линейки продуктов NetApp (кроме E-серии).
Именно эта простота, на мой взгляд, и кроется за цитатой Дэйва Хитса из названия статьи.
Учитывая, что данная система предполагает интеграцию с различными системами динамического распределения ресурсов, без участия администратора и без дополнительных трудозатрат, вы скоро забудете, как выглядит интерфейс SolidFire. Но об интеграции мы поговорим позже.
Мы в "Онланте" провел нагрузочное тестирование, чтобы подтвердить обещанные 200 тыс.
операций ввода-вывода в секунду.
Дело не в том, что мы не доверяем производителю, но мы привыкли все пробовать самостоятельно.
Мы не ставили перед собой цели выжать из системы больше, чем было заявлено.
Также нам удалось на собственном опыте убедиться, что система дает хорошие результаты именно при большом количестве потоков.
Для этого мы организовали на SolidFire 10 томов по 1ТБ, на которых разместили одну тестовую виртуальную машину.
Уже на этапе подготовки тестовой среды мы были приятно удивлены производительностью дедупликации.
Несмотря на то, что схема его работы вполне стандартна, качество работы внутри кластера оказалось чрезвычайно эффективным.
Перед тестированием диски были заполнены случайными данными.
Чтобы сделать это быстрее, был сгенерирован блок размером 10 МБ, а затем заполнен им.
Причем на каждой виртуальной машине этот блок генерировался отдельно, т.е.
закономерность во всех машинах разная.
Из 10 ТБ, заполненных данными, реально занятое место в массиве составило 4 ТБ.
эффективность дедупликации — 1:2,5; на FAS при таком подходе эффективность встроенной дедупликации стремилась к 0. На нашем тестовом стенде нам удалось получить 190k IOPS с откликом ~1 мс.
Хотелось бы отметить, что особенности архитектуры решения не позволяют получить высокий уровень производительности на небольшом количестве потоков.
Одна маленькая луна или всего одна тестовая виртуальная машина не сможет показать высокие результаты.
Такое количество операций ввода-вывода в секунду нам удалось получить за счет использования всей мощности системы и постепенного увеличения количества виртуальных машин, создающих нагрузку с помощью fio. Мы увеличивали их количество до тех пор, пока задержки не превышали 1,5 мс, после чего останавливались и снимали показатели производительности.
Заполненность дисковой подсистемы также влияет на производительность.
Как я уже говорил ранее, перед запуском тестов мы заполняли диски случайными данными.
Если запустить тест без предварительного заполнения дисков, производительность будет намного выше при том же уровне задержек.
Мы также провели наш любимый тест отказоустойчивости, отключив один из узлов.
Для получения наилучшего эффекта для отключения был выбран Мастер-нода.
Из-за того, что каждый клиентский сервер устанавливает свою сессию с узлом кластера, а не через какую-то единственную точку, при отключении одного из узлов деградируют не все виртуальные машины, а только те, которые работали с этим узлом.
Соответственно, со стороны хранилища мы видим лишь частичное падение производительности.
Конечно, со стороны хостов виртуализации на некоторых хранилищах данных падение производительности было до 0. Но в течение 30 секунд производительность восстанавливалась без потери производительности (стоит учитывать, что нагрузка в момент падения была на уровне 120 тыс.
операций ввода-вывода в секунду, что соответствует трем узлам из четырех, поэтому потери производительности мы увидеть не должны).
В то же время SolidFire начал восстановление массива.
Таймер немного врет, и процесс занял около 55 минут, что укладывается в обещанный производителем час.
При этом нагрузку с СХД никто не снимал, и она осталась на том же уровне 120k IOPS. Отказоустойчивость обеспечивается не только на уровне дисков, но и на уровне узлов.
Кластер поддерживает немедленный выход из строя одного узла, после чего запускается процесс восстановления кластера.
Учитывая использование SSD и тот факт, что в ребилде участвуют все узлы, восстановление кластера происходит в течение часа (пересборка при выходе из строя диска занимает около 10 минут).
Стоит учитывать, что при выходе узла из строя вы теряете и производительность, и полезное пространство.
Соответственно, вам всегда необходимо иметь свободное место в размере одного узла.
Минимальный размер кластера — четыре узла.
Такая конфигурация позволит вам избежать проблем, если один из узлов выйдет из строя, пока вы ждете прибытия замены.
Как и в большинстве СХД, мониторинг производительности здесь отображается только в режиме реального времени.
Чтобы иметь доступ к историческим данным, вам необходимо развернуть так называемый узел управления, который берет данные через API от SolidFire и загружает их в Active IQ. Если вы уже работали с системами NetApp, то, возможно, вы уже сталкивались с этим порталом.
У вас есть возможность работать с данными о производительности, эффективности, включая прогнозы роста.
Более того, вы можете получить доступ к этим данным даже со своего мобильного устройства в любой точке мира.
Раз уж я упомянул работу встроенной дедупликации, то расскажу и об эффективности хранения в целом.
Как и в серии AFF, NetApp обеспечивает гарантированный коэффициент эффективности хранения в зависимости от типа хранимых данных.
Как видите, их типы данных и гарантированные шансы немного отличаются.
Например, у SolidFire есть именно наш случай — Virtual Infrastructure с соотношением 4:1. И это не учитывая использование снапшотов.
Архитектура решения основана на принципе качества обслуживания (QoS), который фактически позволяет гарантировать гарантированную производительность для каждого тома.
QoS — одна из важнейших функций для поставщиков услуг и других предприятий, которым необходимо обеспечить гарантированный уровень производительности хранилища.
Некоторые скажут, что QoS не является чем-то новым и реализован многими другими поставщиками.
Другой вопрос, как это работает. В то время как в традиционном хранилище больше внимания уделяется приоритезации и ограничению скорости, SolidFire, в свою очередь, использует интегрированный подход для достижения гарантированной производительности.
- Использование All-SSD позволяет добиться низкой задержки ввода-вывода.
- Масштабирование позволяет легко прогнозировать показатели производительности.
- Никакого классического RAID – предсказуемая производительность при
- отказы оборудования
- Сбалансированное распределение нагрузки устраняет узкие места в системе.
- QoS помогает избежать «шумных соседей».
Каждый том имеет определенную систему условных зачетов.
Когда его результативность ниже максимальной оценки, ему начисляются эти кредиты, благодаря которым он в течение определенного периода времени может превышать максимальную оценку успеваемости.
Такой подход позволяет разместить в хранилище большое количество приложений, требующих высокой производительности, и в то же время защитить их от негативного влияния друг на друга.
Самое интересное, что QoS поддерживается не только на уровне томов массива, но и на уровне VMware VVols, что позволяет гранулированно распределять ресурсы для каждой виртуальной машины.
Полная поддержка VAAI и VASA API обеспечивает тесную интеграцию массива с виртуализатором.
Говоря об интеграции, на этом решение от VMware не заканчивается.
SolidFire, пожалуй, можно назвать самой автоматизированной системой хранения данных, которая может интегрироваться с любыми современными системами виртуализации/контейнеризации, поддерживает системы управления конфигурациями, доступен SDK для различных языков.
Как всегда, первое, на что я обращаю внимание, — это Python SDK, с помощью которого я автоматизирую свои рабочие процессы.
И так нам нужно создать 15 томов емкостью по 1ТБ и на выходе получить их iqn, который мы передадим администраторам VMware для добавления датасторов.
У нас уже есть заранее созданные группы доступа, в которых прописаны наши хосты VMware и заранее созданная политика QoS.
Или вот более подробное видео «Python SDK Demo» от самого SolidFire: Такой подход к автоматизации делает SolidFire удобным не только для облачных провайдеров и подобных задач, но и в соответствии с концепцией непрерывной интеграции и доставки (CI/CD) позволяет оптимизировать процесс разработки.#!/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
Как я уже упоминал, WebUI работает через API, и вы можете просматривать все запросы и ответы через журнал API.
Если вам интересно узнать больше о SolidFire, чем он отличается от конкурентов, как работать с системой и т. д., я хотел бы порекомендовать их.
YouTube канал , на котором довольно большое количество полезных видео.
Например, цикл «Сравнение современных All-Flash-архитектур».
Одной из приятных особенностей системы является встроенный механизм резервного копирования снимков на внешнее хранилище, совместимое с S3. Это позволяет использовать снапшоты в качестве резервных копий и хранить их на внешнем хранилище как на своем сайте, так и на внешних ресурсах, например, в Amazon. Конечно, этот подход сложно назвать гибким с точки зрения восстановления данных, но для некоторых случаев такое решение может оказаться полезным и вполне применимым.
Есть еще один интересный момент — загрузить данные в хранилище S3 можно двумя вариантами:
- Родной — в этом случае будут загружены уже дедуплицированные данные, но восстановить этот том можно только в ту же систему, из которой он был загружен.
- Несжатый — сюда уже загружен полный набор блоков, что позволяет восстановить эту луну на любом другом кластере SolidFire.
В целом мы остались более чем довольны нашим опытом работы с SolidFire. Обещанную производительность мы получили, производительность встроенной дедупликации была выше всяких похвал, а возможности интеграции и автоматизации также оставили крайне положительное впечатление.
Влияние отказа узла, а точнее его минимальное влияние на производительность системы в целом, распределение нагрузки и отсутствие единой точки отказа, которая могла бы сильно повлиять на производительность, делают эту систему чрезвычайно привлекательной.
Несмотря на то, что кластер может работать только через iSCSI, наличие транспортного узла FC делает эту систему более универсальной.
Особую благодарность хотелось бы выразить Евгению Красикову из NetApp и Артуру Аликулову из Merlion за проведение тестирования.
Кстати, Артур, водитель замечательный Telegram-канал для всех, кто хочет быть в курсе новостей систем хранения данных и NetApp в частности.
В нем можно найти огромное количество полезных материалов, а для тех, кому не просто нужно читать, но и хочется пообщаться, есть еще хранилище чатаобсуждения .
Если у вас остались вопросы или вдруг появились новые, приглашаю вас посетить NetApp Directions 2018, которая пройдет 17 июля 2018 года в отеле Hyatt Regency Petrovsky Park, где мы с Артуром поговорим о SolidFire на одной из сессий.
Регистрация на мероприятие и все детали.
В нашей компании также есть вакансия.
Теги: #Хранение данных #Системное администрирование #Хранение данных #Система хранения данных #ланит #онланта #SolidFire
-
Советы По Успеху В Интернет-Маркетинге
19 Oct, 24 -
«Я Слышу Голоса» Или У Siri Есть Лицо?
19 Oct, 24 -
Определите Автора Поста В Комментариях
19 Oct, 24
