24 накопителя SSD DC S3700: тесты хранилища ёмкостью 20 Тбайт и стоимостью $50000 – THG.RU

24 SSD DC S3700 | Хранилище из SSD на 18 Тбайт

Сколько существуют твердотельные накопители, столько продвинутые пользователи и профессионалы корпоративного сегмента объединяют их в RAID массивы. Соединив несколько SSD малой ёмкости, вы получите молниеносный и достаточно объёмный том. Для сборки такой конфигурации есть несколько объективных причин “за”, но есть и веские причины “против”. Рассмотрим основные.

Вы можете утверждать, что сегодня существует не так много поводов для объединения нескольких SSD. Цена за 1 Гбайт падает, а ёмкость растёт. Для людей, жаждущих вершин производительности, есть решения на PCI Express. Но мы такое мнение не разделяем, особенно после того, как Intel прислала нам 24 SSD DC S3700 для тестов (не пропустите нашу статью “Intel DC S3700: обзор и тест SATA SSD корпоративного класса”).

Семейство SSD DC S3700 обладает впечатляющими характеристиками. У старшей модели пиковая скорость последовательного чтения достигает 500 Мбайт/с, а записи – 460 Мбайт/с. Скорость чтения блоками по 4 Кбайт доходит до отметки 76000 IOPS, записи – 36000. Конечно, больше всего в этих накопителях привлекает увеличенная выносливость, защита данных, устойчивость к перепадам напряжения и цена около $2/Гбайт.

Как нам известно, минимальная ёмкостью SSD DC S3700 составляет 100 Гбайт. Две дюжины таких накопителей в правильных руках могут стать серьёзным оружием. Вы можете создать конфигурацию RAID 0 на 2,4 Тбайт. Однако для нашего эксперимента мы получили модели ёмкостью 800 Гбайт. Учитывая, что каждый такой SSD стоит примерно $2000, общая стоимость конфигурации приближается к числу в $50000.

Каждый флагманский SSD DC S3700 800 Гбайт содержит на борту целый Тбайт флэш-памяти. Даже с учётом резервирования мы получаем 745 Гбайт доступного пространства, в общей сложности – 18 Тбайт. Учитывая, что эти накопители рассчитаны на 10 циклов полной перезаписи в день в течение пяти лет, возможности кажутся безграничными.

Если вы по жизни имеете дело с хранилищами из твердотельных накопителей, то наверняка поймёте, что две дюжины SSD DC S3700 800 Гбайт в одном месте – это как заказной Rolls-Royce с салоном, отделанным кожей динозавра. Это слишком роскошно, чтобы быть правдой. К счастью, разговор с правильными людьми в компании Intel сделал такую возможность реальной. Так что же делать со всеми этими накопителями?

На ум пришло только одно: соединить их вместе и посмотреть, какова будет производительность.

Однако мы столкнулись с некоторыми трудностями. Если бы у нас было только восемь накопителей, всё было бы гораздо проще. Многие аппаратные RAID-контроллеры предлагают восемь разъёмов. Восемь SSD, в таком случае, получают по разъёму, и можно было бы перейти к тестам. Однако у нас 24 накопителя, и нам пришлось рассматривать альтернативные конфигурации. Мы могли использовать три RAID-карты, но тогда мы не смогли бы создать один том. Ещё можно подключить дюжину накопителей к одному контроллеру с помощью расширителя, однако в этом есть смысл только для HDD, которые не могут насытить канал 6 Гбит/с.

К тому же с таким числом накопителей физически трудно всё подключить. Для каждого SSD нужен один кабель питания и один кабель для передачи данных. Поэтому для удобства подключения необходима соединительная панель. Поскольку для нагрузки такой подсистемы хранения нужно много ресурсов, мы решили выполнить сборку с помощью сервера, оснащённого соединительной панелью на 24 разъёма. Intel откликнулась на нашу просьбу и предоставила систему с двумя Xeon E5, поддерживающую 80 линий PCI Express 3.0 и несколькими функциями, ориентированными на работу с хранилищами.

Итак, “железо” готово. Осталось объединить 24 SSD DC S3700 с двухпроцессорным сервером 2U. Но мы упустили одну деталь. Из-за особенностей конфигурации этих накопителей мы вынуждены опираться на программный RAID, который часто подвергается критике. Но мы в этом проблемы не видим. Функциональность программного RAID за 15 лет прошла длинный путь, и, хоть она задействует ресурсы процессора, производительности нашего шестнадцатиядерного сервера определённо будет достаточно.

В первом раунде экспериментов мы пропустим самые надёжные, но отнимающие производительность режимы RAID (например, 5 и 6) в пользу более впечатляющего (но не безопасного) RAID 0, который позволит нам получить всю возможную ёмкость и производительность от такой конфигурации.

Всего один SSD DC S3700 по ёмкости больше, чем 12 дисков Intel X25-E 64 Гбайт корпоративного класса. Чтобы сравняться с массивом из 24-х накопителей по 800 Гбайт, понадобится более трёхсот SSD X25-E. Довольно впечатляющее получается сравнение.

24 SSD DC S3700 | Платформа для хранилища

Наша тестовая платформа имеет в своей основе системную плату Intel S2600IP. IP в названии означает предрелизное кодовое имя Iron Pass, а цифра 2600 ссылается на процессоры Xeon E5 на базе Sandy Bridge-EP для процессорного разъёма LGA 2011. Плата имеет 16 слотов DIMM DDR3 и кучу линий PCI Express, поэтому пространства для масштабирования достаточно.

Если хотите, можете установить только один процессор. Но мы решили использовать все возможности восьмиядерных чипов. Наш сервер работает на двух процессорах Xeon E5-2665 с частотой 2,4 ГГц, повышающейся до 3,1 ГГц в малопоточных приложениях.

Материнская плата S2600IP

Материнская плата S2600IP использует Intel PCH C602, ранее называемый Patsburg. Как уже упоминалось, линий PCIe предостаточно. Так и должно быть, ведь два CPU дают по 40 линий каждый. Плата имеет четыре слота x16, три слота х8 и один слот x8, ограниченный соединением второго поколения на четыре линии. Также Intel устанавливает специальный восьмилинейный слот расширения, где могут размещаться специальные дополнительные карты для работы с фирменными контроллерами накопителей.

Встроенная система хранения не совсем стандартная. Платформа Iron Pass поддерживает два разъёма SATA 6 Гбит/с, характерных для настольных плат 7-й серии. Встроенный в C602 модуль контроллера накопителей (SCU) добавляет восемь портов SAS, которые могут управляться либо программой Intel RSTe, либо драйвером LSI MegaSR. Это очень удобно, но мы не будем использовать данную подсистему сегодня. Мы просто загрузимся с одного из встроенных разъёмов SATA.

Естественно, чтобы насыщать процессоры такого сервера данными, нужно много оперативной памяти. Компания Kingston помогла нашему эксперименту, прислав 64 Гбайт памяти DDR3-1333 ECС 1,35 В. Каждый модуль KVR13LR9D4/8HC 8 Гбайт относится к семейству Server Premier. Эта линейка имеет модули памяти различного типа и характеризуется ограниченным списком поставщиков компонентов. Это важно для сборщиков, поскольку позволяет беспроблемно докупать память в будущем. Неплохо было бы иметь такую гарантию и для настольного сегмента. Мы несколько раз натыкались на хороший в плане разгона набор памяти, но выяснялось, что второй набор с таким же названием использовал другие чипы и вёл себя по-другому.

Сам корпус отличается несколькими функциями, ориентированными на хранилище. Лицевую часть корпуса 2U украшают двадцать четыре отсека для 2,5″ накопителей и столько же разъёмов в задней соединительной панели. С девятью портами мы можем подключить все двадцать четыре накопителя к одному адаптеру HBA (Host Bus Adapter) или RAID. К сожалению, расширитель, управляемый LSI, вводит слишком большую задержку и душит слишком много SSD. Если заменить SSD жёсткими дисками, то привлекательность такой конфигурации значительно возрастёт. Итак, мы пошли в обход расширителя, подсоединив накопители напрямую от задней соединительной панели к контроллеру. В идеале между ними ничего не должно быть, но в нашем случае от задней панели отказаться нельзя. По сути это единственный вариант для такого количества дисков.

24 SSD DC S3700 | Тестовый стенд и компоненты

HBA и аппаратный RAID

Если вы видели материнские платы с чипсетами Intel или AMD, то наверняка замечали, что количество разъёмов SATA у них и близко не доходит до 24-х. Само собой разумеется, нужны вспомогательные устройства для подключения всех наших SSD.

RAID-карты Intel HBA/встроенные

RAID-карты RMSKB080 и RMSJB080 (на изображении выше) Intel продаёт как решения начального уровня. Хотя они и выглядят как настоящие аппаратные RAID-контроллеры, по сути это просто замаскированные адаптеры HBA. С точки зрения функциональности модели KB и JB идентичны. Просто JB вставляется в упомянутый выше специальный слот.

Наши контроллеры основаны на чипе LSI SAS2308 PowerPC. Их даже можно принять за переименованные HBA LSI 9207-8i. Карты 9207-8i изначально не обладают функцией RAID (режим Initiator-Target), однако RMSKB080 поставляется с прошивкой, включающей данную функцию (режим Integrated RAID). Однако нам они приглянулись не за аппаратный RAID, а за их возможность подключать накопители непосредственно к хосту. Таким образом, наш сервер может выполнять все вычисления для RAID-массивов программно.

В случае необходимости у нас есть адаптер Intel RMS25CB080, и мы можем опробовать аппаратный режим RAID. Но всего с одной картой раскрыть производительность 24 накопителей вряд ли удастся. Модель CB разработана на базе PCIe LSI SAS2208 Gen3 с кэшем DDR3 на 1 Гбайт и более мощным процессором PowerPC, поэтому она может управлять более сложными по вычислениям чётности уровнями RAID (5/6), которые картам KB не по зубам. RAID 0 и 1 не требуют сложных вычислений, однако калькуляция чётности для RAID 5 и 6 нуждается в большей процессорной мощности.

Стоит отметить, что три этих решения Intel работают только на совместимых с Xeon E5 материнских платах. Вам придётся использовать платформу с LGA 2011 от Intel, в противном случае карты даже не запустятся. Тем не менее, расширение выполнено в особом форм-факторе, поэтому это не очень важный недостаток. Стоимость RMSKB080 составляет треть от цены LSI 9207-8i, но, как нам известно, их нельзя перепрошивать для расширения совместимости. К тому же, прошивка от IR до режима IT, похоже, тоже не поддерживается. Intel продаёт другие продукты с более широкой совместимостью, но именно эти модели предназначены исключительно для данной платформы.

Программный RAID: не так уж и страшно

Итак, мы будем использовать возможности операционной системы для создания нашего RAID-массива. Windows уже давно поддерживает чередование, зеркалирование и даже RAID 5. Однако производительность в целом невелика, и при настройке не хватает гибкости. В Windows 8 через программу Storage Spaces были реализованы интересные концепции, однако для нашего эксперимента они бесполезны.

Linux – совсем другое дело. Современные дистрибутивы Linux включают несколько вариантов RAID. По аналогии с управлением дисками в режимах RAID в Windows, управление логическим томом происходит через файловую систему. Однако главный козырь Linux – это утилита mdadm, отвечающая за создание томов RAID 1/0/5/6 (плюс смешанные режимы наподобие RAID 50/60). Мы можем определить размер полосы и даже назначить системную память для кэша, также как аппаратный RAID-адаптер. Возникает заманчивая перспектива превратить наш сервер на базе Xeon в один большой RAID-контроллер.

Уровни RAID 5/6 требуют сложных вычислений для создания и восстановления массивов. Эти алгоритмы выигрывают от расширений инструкций, встроенных в архитектуры типа PowerPC. К счастью, процессоры x86 могут ускорять такие вычисления, если ПО рассчитано на их использование. Mdadm была разработана с учётом этого, и использует данное преимущество, где только возможно, а сообщество разработчиков может улучшать её по мере необходимости.

24 SSD DC S3700 | Результаты тестов

Масштабирование скорости случайных операций блоками по 4 Кбайт в RAID 0

Количество потоков против глубины очереди

Если бы мы тестировали только один SSD, можно было бы просто провести увеличение глубины очереди. Один системный процесс давал бы последовательные команды, создавая различную глубину очереди. Это неплохо работает для SSD на базе SATA, особенно, если учесть, что тестировать их при очерёдности более 32-х команд не имеет смысла. Однако такая методика не подходит для проверки SSD на PCIe и RAID-массивов. В конце концов, генераторы нагрузки выдыхаются на высоких глубинах очереди с одним потоком. Вместо этого, чтобы вытянуть максимум производительности, нам необходимо запустить несколько потоков на различной глубине очереди.

Данная диаграмма демонстрирует динамику показателей. Мы начали с глубины очереди в одну команду в одном потоке, и закончили 32-мя потоками, “бомбардирующими” массив на глубине очереди в 32 команды. При одном потоке скорость произвольной записи блоками по 4 Кбайт останавливается на 100000 IOPS. Нагружая массив 32-мя потоками, мы можем получить производительность в 1000000 IOPS. Именно поэтому мы расширили количество потоков до 32 и варьируем глубину очереди в этих пределах.

Масштабирование скорости случайного чтения блоками по 4 Кбайт в RAID 0

В RAID массиве вы определённо захотите видеть масштабирование. С увеличением количества накопителей мы хотим наблюдать соразмерное повышение производительности. Затем, давая более тяжёлые задачи, мы хотим, чтобы производительность росла вместе с интенсивностью нагрузки. В RAID 0 трудностей с этим возникнуть не должно. В конце концов, издержек немного и надоедливая отказоустойчивость нас не сдерживает.

Сразу из первого графика мы можем сделать интересные выводы. Во-первых, получить 1010755 IOPS на массиве RAID 0 из 24-х накопителей очень приятно. Это почти 4 Гбайт/с пропускной способности. Во-вторых, пропасть между 8x SSD DC S3700 и 16 накопителями огромна. Разница почти 100% или 400000 IOPS. Такой же процент прироста мы видим при переходе с четырёх на восемь накопителей. Прирост между 16x и 24x должен быть ближе к 50%, но здесь мы явно упираемся в бутылочное горлышко, поскольку скорость увеличивается только на 25%.

В общей сложности масштабирование отличное. Неразумно ждать от накопителей в конфигурациях 4x/8x/16x/24x уровня производительности отдельного SSD. Если разделить пиковый показатель скорости произвольного чтения всех 24-х накопителей, получается, что каждый SSD DC S3700 обеспечивает 42114 операций ввода/вывода в секунду. Для одного SSD DC S3700 800 Гбайт заявлена скорость чтения блоками по 4 Кбайт до 76000 IOPS. На первый взгляд, мы потеряли очень много производительности. Но, если учесть реалии масштабирования, мы рады видеть хотя бы половину от максимального уровня. Факт того, что мы получили 42000 IOPS/на каждый SSD в массиве из 24-х штук и 50000 IOPS в массиве из 16 или меньше, можно сказать, чудесный.

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

Масштабирование скорости случайной записи блоками по 4 Кбайт в RAID 0

Результаты тестов записи порадовали нас не меньше.

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

На данном этапе важно отметить, что это результаты свежих накопителей. Мы не провели достаточно записи на SSD, чтобы они достигли состояния, когда требуется активация механизма “уборки мусора”. Из-за ограничений по времени, которые дала Intel на тесты этих накопителей, провести нашу сессию записи не удалось. Тем не менее, заявленная производительность флагманской модели в стационарном состоянии достигает 36000 IOPS. Поэтому существенного снижения производительности мы не ждём. Массив из 24 накопителей уже достигает 980000 IOPS – это приблизительно 41000 операций записи в секунду на каждый SSD. Через несколько лет использования массива RAID 0 из 24-х SSD мы предположительно получим 860000 операций записи блоками по 4 Кбайт. Насколько велика эта цифра?

Если бы это были обычные настольные диски, мы бы собрали их в массив. Без функции TRIM производительность может значительно снизиться, из профилактических мер поддержания скорости с течением времени остаётся только жертвовать полезной ёмкостью. По этой причине линейка Intel SSD DC S3700 и большинство других SATA-дисков корпоративного класса, уже используют резервирование. В модели на 800 Гбайт полезная ёмкость составляет только 745 Гбайт из 1024 Гбайт. Но в взамен вы получаете стабильную производительность в устоявшемся состоянии SSD. Следовательно, усиление записи тоже ниже, отсюда и 10 циклов перезаписи в день в течение пяти лет, которые Intel декларирует для линейки SSD DC S3700.

Масштабирование скорости последовательных операций блоками по 128 Кбайт в RAID 0

Масштабирование скорости последовательного чтения блоками по 128 Кбайт в RAID 0

Прогоняя тесты последовательного чтения блоками по 128 Кбайт, мы получили почти 2 Гбайт/с на четырёхдисковом массиве и больше 4,2 Гбайт/с на массиве из 24-х SSD DC S3700. Если бы мы получили 500 Мбайт/с на SSD, как заявляет Intel, то массив из 24x SSD обеспечил бы примерно 12 Гбайт/с. Каждая карта-контроллер от Intel использует восемь линий PCI Express третьего поколения, поэтому каждая карта должна обеспечить более 4000 Мбайт/с.

В любом случае, мы имеем огромную пропускную способность. Получается, что как будто мы считываем однослойный DVD-диск каждую секунду. Такую скорость мы получаем с первого по последний сектор, поскольку не опираемся на кэширование. Здесь только чистая производительность флэш-памяти.

Масштабирование скорости последовательной записи блоками по 128 Кбайт в RAID 0

Скорость записи оказалась ещё лучше. Массив из 24x SSD подбирается к отметке в 5 Гбайт/с (4,8 Гбайт/с). Конфигурации 16x и 8x ближе к уровню 3 Гбайт/с, а четыре диска в массиве при записи оказались всего на пару процентов медленнее, чем при чтении.

Когда что-то идёт не так

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

Может быть, в этом виноват размер блоков данных, который мы выбрали для данных массивов RAID 0? Нет. После обширного тестирования мы остановились на блоках по 64 Кбайт. Каждая передача блока 128 Кбайт обслуживается двумя накопителями, поскольку 128 Кбайт делятся на два равных блока по 64 Кбайт, в соответствии с нашей установкой. При достаточном количестве параллельных запросов всё должно быть в порядке.

Как мы уже видели в предыдущей серии тестов, при произвольной передаче блоками по 4 Кбайт масштабирование тоже отличное. Поэтому, возможно, проблема в пропускной способности. Каждый накопитель может осуществлять последовательную передачу больших объёмов данных на скорости выше 400 Мбайт/с, а для тестов с блоками по 4 Кбайт SSD DC S3700 не могут переварить больше 300 Мбайт/с в, и мы в любом случае рассчитываем потерять большую часть скорости. Так что вполне логично, что мы сталкиваемся с ограничениями, урезающими пропускную способность.

Изучив модули RMS25KB/JB IR, мы обнаружили, что они работают в режиме PCI Express 3.0 и способны гонять данные туда и обратно к SSD DC S3700 с минимальным влиянием на их производительность. Как это часто бывает, виновником является крайне важная вещь: соединительная плата SAS/SATA на 24 отсека.

Печально, но факт. Двадцать четыре отсека состоят из трёх модулей на восемь дисков присоединённых к внешней части нашего сервера. Каждый оснащён двумя портами SAS 8087 (по одному на четыре устройства), и они просто не могут пропускать данные беспрепятственно. Мы не уверены, сможет ли другая соединительная панель нормально работать в нашей ситуации, а отказаться от имеющейся в условиях данного эксперимента невозможно.

Тестирование различных профилей сервера

Профили задач

Пока будут существовать тестовые программы, генерирующие операции ввода/вывода, профессионалы будут пытаться имитировать с ними особые задачи. Мы провели SSD DC S3700 через серию различных испытаний, работающих по корпоративным шаблонам ввода/вывода.

Профиль веб-сервера

Профиль веб-сервера достаточно сложный, он состоит из восьми разных размеров блоков передачи данных. Вдобавок к передачам по 0,5 Кбайт, 4 Кбайт и 8 Кбайт есть файлы других размеров. Данный профиль на 100% состоит из операций чтения, однако наши массивы из SSD DC S3700 почти также сильны в операциях произвольной записи.

С увеличением количества накопителей масштабирование происходит по аналогии с предыдущими тестами. При удвоении количества SSD в массиве (с четырёх до восьми) производительность тоже удваивается, а конфигурация 24х обгоняет массив 8х более чем на 100%.

Профиль базы данных

Профиль базы данных очень прост. Передача данных блоками по 8 Кбайт на 67% состоит из операций чтения и на 33% – записи.

Массив 24x достигает отметки 500000 IOPS. Это неудивительно, поскольку при увеличении размера блока данных вдвое по сравнению с 4 Кбайт, за секунду происходит ровно половина операции ввода/вывода от того значения. Поскольку в тестах чтения и записи блоками 4 Кбайт производительность приближается к 1000000 IOPS, 500000 IOPS в профиле базы данных – это вполне ожидаемый результат. Пропускная способность – это IOPS, умноженный на размер блока передачи, поэтому она, по сути, остаётся одинаковой во всех тестах.

Профиль MS Exchange

Наиболее традиционные задачи почтового сервера в профиле Iometer отлично подходят для нашего тестирования. Для достоверности мы имитируем активность почтового ящика MS Exchange с блоками 32 Кбайт, на чтение идёт 62% всех операций, на запись – 38%.

Это первый результат, который не поддаётся нормальному объяснению. Прогон за прогоном, массив из 24-х накопителей достигал 200000 IOPS. К слову, 200000 IOPS – это целых 6,25 Гбайт/с. Массив на 3 Тбайт, состоящий из четырёх SSD DC S3700, достигает 40000 IOPS независимо от глубины очереди. Здесь мы имеем абсолютно стабильную пропускную способность более 1200 Мбайт/с. Показатель восьмидискового массива в два раза выше, 24-дискового – в четыре раза выше. Может быть, мы нашли идеальные настройки? Поскольку результат слишком хорош, чтобы быть правдой, его стоит рассматривать с толикой недоверия.

Профиль файлового сервера

По сложности профиль файлового сервера почти не отличается от веб-сервера, только здесь 20% транзакций приходятся на запись, большая часть блоками по 4 Кбайт. Данный тест неплохо демонстрирует среднюю потребительскую/клиентскую нагрузку.

В среднем каждая операция ввода/вывода имеет размер блока данных приблизительно 11 Кбайт.

Добавляя больше SSD DC S3700, мы видим отличное, плавное масштабирование. Производительность увеличивается линейно с увеличением количества накопителей и интенсивностью нагрузки, с 50000 IOPS на четырёхдисковом массиве до 325000 IOPS на массиве 24x.

Идём ва-банк

До этого момента мы не использовали кэширование диска в Linux, чтобы повысить показатели в тестах. Однако Linux – хитрая ОС. Любая явно не выделенная память идёт под кэш, и если она нужна для других целей, то освобождается. В нашем случае почти все 64 Гбайт памяти DDR3-1333 от Kingston свободны для кэширования накопителей или файловых систем, поскольку сам сервер под CentOS 6 использует не так много памяти.

Для тестирования массива дисков мы вовсе отключили кэширование, чтобы понять, на что способны сами SSD. Но теперь, когда результаты производительности известны, давайте посмотрим, что будет, если добавить в работу два четырёхканальных контроллера и восемь модулей DDR-1333.

Произвольные операции блоками по 4 Кбайт с кэшированием ввода/вывода

Позволив OS кэшировать произвольные передачи блоками 4 Кбайт, мы, как и говорили, видим различные показатели производительности. Потенциала хватает и для более высоких показателей, но только если система запросит данные из кэша. Программа может кэшировать LBA в DRAM, если доступ к ним уже был осуществлён во время прогона.

Произвольное чтение четырёхкилобайтовых блоков тестируется при очерёдности от 1-й до 32-х команд, в 1-32 потока. На диаграмме ниже представлены результаты 36 прогонов, создающих матрицу 20-секундных тестов.

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

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

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

Эта динамика имеет обратный эффект при переходе на последовательную передачу.

Последовательные операции блоками по 128 Кбайт с кэшированием ввода/вывода

Ограничив тестовый диапазон LBA всего 32 Гбайтами, мы можем кэшировать всю тестовую область в DRAM. Это не заняло много времени, особенно, когда мы считываем и записываем тысячи мегабайт в секунду. Тест мы проводили десять минут, затем взяли среднюю пропускную способность в Мбайт/с.

Здесь неважно, сколько дисков в массиве. Вся область LBA на 32 Гбайта кэшируется за секунду, после чего пропускная способность для чтения достигает 23000 Мбайт/с и держится в течение всего 10-минутного теста. Пропускная способность для операций чтения тоже очень велика – 14 Гбайт/с. Похоже на жульничество, но так ли это? Необязательно. Это одна из причин, почему кэш DRAM используется в первую очередь. Мы просто позволили операционной системе делать то, что она должна, и воспользовались этим.

Max IOPS

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

Во-первых, мы создали задачу по произвольному чтению блоками по 4 Кбайт, распределили её по области LBA на 32 Гбайт и позволили ей поработать несколько минут. Через некоторые время система скэшировала всю область LBA на 32 Гбайт и мы получили максимальный эффект от выполнения запросов прямо из DRAM. Как высоко мы забрались?

До 3136000 IOPS или 12000 Мбайт/с. На данной отметке мы используем почти всю вычислительную мощь нашего двухпроцессорного сервера. Создание достаточно тяжёлой нагрузки для максимизации операций ввода/вывода – это тяжёлая работа, к тому же нужно учитывать ещё и интенсивные расчёты для управления RAID. После серии проб и ошибок максимум, что нам удалось выжать – 3136000 IOPS. И всё благодаря массиву на 19 триллионов байт и 16-ти физическим ядрам. Это достаточно яркие цифры для завершения эксперимента.

24 SSD DC S3700 | Отличный выбор. Если денег хватит…

Современные SATA-накопители уже приближаются к верхней границе интерфейса SATA 6 Гбит/с. Он ещё протянет некоторые время, но на горизонте уже есть новые быстрые интерфейсы и форм-факторы. Сегодня обход потолка производительности SATA не совпадает с целями клиентского хранилища и не совместим с назначением SSD DC S3700. Сейчас самое главное – предоставить покупателю смесь доступности, гибкости и функциональности в SATA-накопителе.

Конечно, доступность – понятие растяжимое. Тем не менее, SSD DC S3700 был разработан для организаций, ищущих выгодное хранилище для развёртывания больших систем. Старые пользовательские накопители Intel используются в дата-центрах всех размеров, и SSD DC S3700 нацелен на покупателей данного сегмента. Эта модель даёт покупателю больше ёмкости и опций по цене, с которой дебютировало семейство SSD 320 3 Гбит/с.

Естественно, создание массива на 18 Тбайт из SSD 800 Гбайт – занятие не из дешёвых. Каждый такой накопитель стоит $2000. Хотите собственный супербыстрый массив? Будьте готовы выложить за него около $50000 (и это без учёта стоимости достаточно быстрого сервера). Конечно, это дорого. Но по сравнению с тем, сколько такая ёмкость и скорость обошлась бы раньше, SSD DC S3700 определённо выигрывает от более быстрой и более экономичной NAND-памяти, созданной по производственному стандарту 25 нм.

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

Всё могло оказаться далеко не так хорошо без должного сервера, который может управлять такой конфигурацией. Для наших целей понадобилась вся производительность двух чипов Xeon E5. Мы успешно определили границу возможностей SSD и нашей тестовой платформы, и результат оказался очень высок. Вычисления для RAID 0 не занимают много ресурсов процессора, но дают достаточно тяжёлую нагрузку на подсистему хранения.

Награда действительно стоит усилий. Нам удалось превратить 17880 Тбайт в один невероятно быстрый том. 1000000 IOPS при чтении блоками 4 Кбайт – это здорово, но почти 1000000 IOPS для записи – просто великолепно. Показатель скорости последовательных операций тоже впечатляет. До этого момента программный RAID ещё никогда так не блистал.

Это, возможно, самый большой сюрприз для всех. Если бы мы проводили тестирование программного RAID под Windows, то получили бы лишь небольшую часть производительности, которую видели при использовании mdadm. По крайней мере, данная тема заслуживает дальнейшего исследования. Быстрые комплектующие и открытый код создали программное решение, которые во многих ситуациях может быть прекрасной альтернативой аппаратному RAID. Поскольку существует много версий mdadm, а документации касательно SSD-массивов совсем мало, вполне возможно, что дальнейшая настройка может повысить полученные сегодня результаты. К сожалению, SSD DC S3700 находились в наших руках недолго, а открытых вопросов осталось много. Но это тема уже для другой статьи.