Схд тиринг что это
Практические аспекты применения тиринга
Среди стандартного функционала, предоставляемого различными СХД корпоративного уровня, тиринг стоит на особом месте.
Этот функционал в теории очень хорош, однако на практике большинство клиентов не получают от него желаемой пользы.
Что такое тиринг?
Тиринг (Tiering) — умение системы хранения данных автоматически балансировать нагрузку по разным типам дисков. Например, горячие данные, к которым наиболее часто обращаются пользователи, должны на основании определенных алгоритмов перемещаться на самые быстрые диски (SSD / SAS 15K); умеренно используемые данные переносятся на средний уровень хранения (SAS 10K); и, наконец, холодные данные, к которым идет обращение реже всего, хранятся на самых медленных и дешевых дисках (NL-SAS 7K).
Как работает тиринг?
Согласно маркетинговым заявлениям, перемещение данных на основании частоты обращений автоматически раскладывает данные на тот уровень, который необходим. Однако на практике, из-за особенностей реализации алгоритма, данные не всегда распределяются по уровням хранения правильно.
Типичный пример. В течение дня базы данных, к которым постоянно обращаются пользователи, попадают на верхний уровень хранения, как и должно быть. Вечером, при наступлении окна бэкапа, СХД видит, что теперь самые горячие данные — это не база данных, а бэкап, и успешно мигрирует бэкап на быстрые диски, а базы данных — на медленные. На следующее утро, в начале рабочего дня, во время Boot strom, все пользователи начинают логиниться в систему, а на вернем уровне в это время — ночной бэкап. СХД понимает, что держит необходимые в это время данные на медленных дисках, начинает их потихоньку перемещать. Что в совокупности c одновременными массовыми обращениями к этим данным значительно сказывается на общей скорости работы СХД.
Аналогичных сценариев много, например, локальные периодически возмущения вроде окончания квартала, когда бухгалтерия поднимает какие-то архивы, а СХД начинает выносить эти данные наверх, и т.д.
Получается, что в реальной жизни доверять СХД автоматическое распределение данных оказывается нецелесообразно. Все понимают, что база данных должна лежать на быстрых дисках, и с самого начала можно ее туда положить без какого-либо анализа обращений.
Поэтому ведущие производители, изначально выпустив данный функционал вслед за EMC, больше не акцентируют на нем внимание как на конкурентном преимуществе — на продуктовых презентациях максимум упоминают в ключе «у нас тоже есть тиринг». Некоторые из производителей в принципе отказались от реализации тиринга в своих системах за ненадобностью. Однако, есть и удачные примеры реализации автоматического многоуровневого хранения.
Хороший пример реализации тиринга
В качестве удачного примера работы тиринга можно привести СХД Fujitsu. В них анализ обращений к данным осуществляется сторонним сервисом, который работает на сервере, анализирует обращение к данным и ведет журналирование. Только после окончания длительного периода наблюдений (например, 1 месяц, или полгода, как администратор сочтет нужным), запускается команда на перемещение данных. Можно настроить так, что цикл анализа стартует раз в неделю, и длится положенный срок. В итоге перемещение данных происходит не автоматически на лету, а на основании статистики, собираемой за весь цикл анализа. Поэтому никакие временные данные, бэкапы, видеоархивы не будут влиять на работу.
Можно ли обойтись без тиринга?
Системные администраторы могут изначально разделить данные по двум-трем-четырем уровням хранения, в соответствии с имеющимися задачами. Функционал распределения пространства по запросу (thin provisioning) доступен у всех корпоративных СХД и позволяет как угодно растягивать тома. В этом случае данные размещаются один раз вместо постоянной миграции, которая дополнительно нагружает дисковую подсистему и процессор СХД. Этот вариант в целом удобней, быстрее и эффективней использования тиринга.
Иногда вместо единой СХД с тирингом для всех задач сразу (базы данных, видеонаблюдение, виртуальные машины, медиаконтент и др)., имеет смысл построить решение на нескольких СХД, оптимизированных под конкретные процессы. Каждая отдельная система при этом будет обладать необходимыми характеристиками, скоростью и функционалом.
Альтернатива — технология Flash Cache
Когда мы говорим о тиринге, необходимо также вспомнить о такой интересной пограничной технологии, как Flash Cache (Flash Pool, SSD Cache и др., — названия отличаются у разных брендов). Это функционал использования SSD накопителей как расширение памяти контроллера.
Преимущества этого подхода в том, что самые горячие данные находятся в кэше контроллера, увеличенного за счет SSD дисков. При этом в SSD кэше находится только копия данных, оригинальные данные продолжают храниться на медленных дисках. Как только данные перестают быть горячими, система от них избавляется, причем не миграцией на медленные диски, а просто затиранием, и далее в SSD кэш записываются новые актуальные данные. Таким образом, замена данных на верхнем уровне хранения происходит значительно быстрее, т.к. требуется только считать новые данные без перемещения.
Для управления Flash Cache возможно задавать различные настройки, выделить для кэш каких-то томов отдельно и т.д. В целом данная технология хорошо работает и у всех производителей дает значимый прирост к скорости.
В каких задачах тиринг имеет преимущество?
На наш взгляд, существует два варианта инсталляций, в которых тиринг хорошо работает:
В таких инсталляциях нивелируются слабые места технологии тиринга, и горячие данные поднимаются наверх четко в соответствии с количеством обращений.
В заключение можем сказать, что несмотря на то, что в некоторых инсталляциях тиринг действительно дает значимые преимущества, для большинства клиентов оптимально будет использовать технологию Flash Cache, вручную установить распределение данных по уровням хранения или разнести задачи на разные СХД. А для самых требовательных к скорости инсталляций — рекомендуем хранилища полностью на SSD дисках.
СХД QSAN в качестве конкурента продукции брендам Tier 1
Современная IT инфраструктура сейчас уже немыслима без использования систем виртуализации. А виртуализация наиболее полно раскрывает свои возможности в случае использования централизованной системы хранения данных. Да и помимо этой немаловажной роли найдутся другие задачи, где может потребоваться СХД: масштабные проекты по видеонаблюдению, хранение больших массивов данных, работа с медиа и прочее.
Среди систем хранения, присутствующих на рынке в настоящее время, хотим обратить ваше внимание на СХД тайваньского производителя Qsan Technology серии XCubeSAN.
QSAN как самостоятельная компания появилась в 2008 году. Изначально команда QSAN занималась разработкой и OEM производством RAID контроллеров для различных производителей СХД. Чуть позже, заручившись поддержкой таких грандов среди ODM производителей, как Compal и Gigabyte (да-да, Gigabyte не только производит известные всем материнские платы и видеокарты, а также много чего из сектора Enterprise), перешли на производство своих собственных СХД. В России производитель присутствует почти с самого своего основания (т.е. уже почти 9 лет) и прошел за это время долгий путь от никому не известного вендора до поставщика решений, которые могут успешно конкурировать с так называемыми брендами Tier 1.
Итак, QSAN XCubeSAN – это последнее поколение СХД, сочетающее в себе максимально возможное количество технологий. Основной девиз производителя – сделать функционал Enterprise доступным малым и средним компаниям. Главное, на что следует сразу же обратить внимание, — это совершенно официальная поддержка вендором дисков сторонних производителей. Поэтому никто не будет вам связывать руки (и выворачивать карманы в поисках денежных знаков) при выборе дисковой подсистемы. Конечно, стоит сразу оговориться, что придерживаться листа совместимости в сегменте Enterprise – это, что называется, must have, иначе можно столкнуться с весьма неприятными проблемами в процессе эксплуатации.
Отдельно стоит отметить в контексте использования сторонних дисков набирающее все большую популярность построение хранилищ на базе SSD (и даже All Flash Storage). Если для некоторых типов брендированных жестких дисков еще возможны цены, близкие к «магазинным», то для SSD даже с большими проектными скидками приблизиться по стоимости, например, к HGST или Intel нереально. А это значит, что All Flash на базе QSAN будет просто не досягаем по цене при сравнении с брендами Tier 1.
Аппаратные компоненты СХД
Линейка QSAN XCubeSAN состоит из трех серий, имеющих индексы моделей XS1200, XS3200 и XS5200. Различаются они типом процессора (Pentium/Xeon, 2-4-8 ядер), что в свою очередь сказывается на пиковой производительности. В остальном «железо» и софт полностью идентичны. Поэтому в обзоре мы не будем акцентировать внимание на конкретной модели, т.к. информация применима по сути ко всем (разумеется, с некоторыми поправками).
Доступны 4 вида корпусов:
Все модели с дисками LFF (3.5”) поддерживают в том числе и установку дисков/SSD форм фактора SFF (2.5”) без каких-либо дополнительных опций.
26 дисков в корпусе 2U
Первые три вида корпусов едва ли кого-то удивят. А вот корпус 2U26 в настоящее время является весьма интересным форм-фактором. Такая высокая плотность размещения дисков достигается за счет утончения салазок для дисков, а также особому расположению ребер жесткости корпуса СХД. На текущий момент ни у кого из производителей нет подобных решений: типичное число отсеков для 2U – это 24-25. А лишние отсек-два для дисков совсем не лишние, так как позволяют более гибко подойти к вопросу построения RAID групп и не экономить на hot spare.
Универсальная салазка с диском
Далее – внутренние компоненты: блоки питания, модули охлаждения, контроллеры. Все они задублированы для обеспечения отказоустойчивости. И, разумеется, поддерживают «горячую» замену. Нет, конечно же, можно заказать СХД и с одним контроллером. Но весь прогрессивный мир давно уже пришел к выводу, что переплата за второй контроллер – это спокойствие заказчика и непрерывный доступ к сервисам, расположенным на СХД.
Задняя панель
Контроллер построен на базе процессора Intel Xeon/Pentium D-1500, который специально предназначен для использования во встраиваемых решениях. В качестве ОЗУ используется память типа DDR4 с обязательной поддержкой ECC. На плате для этого имеется 4 разъема (2 для младшей модели). Поддерживается двухканальный режим с максимальным объемом до 128ГБ (32ГБ для младшей модели). Имеется SATA DOM модуль, на котором установлена операционная система.
Контроллер, вид сверху
Для связи с внешним миром имеются два порта 10GbE iSCSI RJ-45 (обратно совместимы с 1GbE), выделенный порт управления, а также 2 порта miniSAS HD для подключения полок расширения через интерфейс SAS 12G. Помимо этого есть разъемы для подключения консоли и ИБП через COM или USB порты.
Контроллер, вид сзади
Помимо встроенного интерфейса имеются два слота для карт расширения: PCI-E x8 Gen3 и PCI-E x4 Gen2. Поддерживаются разнообразные варианты хост разъемов:
Карты расширения
Можно как угодно комбинировать интерфейсы, в том числе и совмещать в рамках одной системы Fibre Channel и iSCSI. Единственное ограничение – конфигурация портов в обоих контроллерах должна быть одинаковой. В максимальной конфигурации в СХД с двумя контроллерами может быть до 16 портов FC 16G или до 20 портов 10G iSCSI. Конечно же меряться максимальными значениями — неблагодарное занятие, но с точки зрения практики наличие большого количества интерфейсов не только может повысить производительность в ряде сценариев, но и позволит в пределах 6-10 серверов отказаться от использования дорогостоящих коммутаторов Fibre Channel или 10Gb Ethernet.
Для защиты кэша контроллеров от внезапного отключения электропитания используется модуль Caсhe-to-Flash, состоящий из батареи или конденсатора и SSD с интерфейсом PCI-E M.2. Использование столь быстрого накопителя необходимо, чтобы успеть скопировать содержимое кэша пока элемент питания поддерживает работу контроллера. На всю операцию отводится не более 2 минут, даже если объем кэша будет максимальным — 128ГБ. При этом емкости батареи хватит на 3-4 подобных цикла, то есть, можно быть спокойным даже при повторных отключениях питания. Также хотим отметить, что для обслуживания модуля Caсhe-to-Flash не нужно извлекать блок питания, а уж тем более контроллер. Модуль имеет функцию «горячей» замены и доступен с задней панели.
Для расширения дисковой емкости возможно подключение полок XCubeDAS, которые доступны в тех же корпусах, что и сами СХД: 2U12, 3U16, 4U24, 2U26. Причем, нет никакого ограничения на конфигурацию «головы» и полок, можно сочетать их в любой комбинации. Однако, максимальное количество полок не может превышать 10, что в большинстве случаев более, чем достаточно, так как количество дисков рамках одной системы может достигать 286.
Кстати, в самой схеме подключения полок расширения к СХД имеется у QSAN имеется свое ноу-хау, связанное с обеспечением отказоустойчивости. Физически полка подключается к «голове» двумя кабелями SAS, как и у всех прочих вендоров. Но логически каждый контроллер СХД видит оба контроллера полки, в том числе и через соседа, посредством внутренней шины. В итоге, в случае перекрестного выхода из строя контроллера СХД и контроллера JBOD система продолжит свою работу (здесь, конечно, важным замечанием является то, что при такой ситуации никто не выдергивал кабели между компонентами).
Связь СХД и полки расширения
Согласны, что возникновение подобного инцидента маловероятно, но если есть дополнительная защита (за которую никто денег не просит), то работать с таким решением как-то спокойнее.
Раз уж затронули тему ноу-хау, не лишним будет отметить поддержку технологии Wake-on-SAS, благодаря которой можно управлять питанием полок расширения через кабели SAS. Это может потребоваться, чтобы включать/выключать полки расширения вместе с «головой» в правильном порядке в автоматическом режиме. Конечно, выключают СХД совсем не часто. Но когда настает такой момент, совсем не лишним будет контроль действий администратора со стороны автоматики системы. Ведь, например, отключение полки раньше «головы» может привести к развалу RAID группы, если эта группа «размазана» по нескольким юнитам.
Резюмируя, можно сделать вывод, что аппаратная составляющая QSAN XCubeSAN обладает возможностями по построению совершенно разнообразных решений (от наиболее простых и бюджетных до весьма продвинутых), может интегрироваться с любыми SAN сетями (в том числе и гетерогенными), а также позволяет использовать жесткие диски и SSD сторонних производителей.
Возможности программной составляющей СХД
Основой является Linux-подобная операционная система собственной разработки — SANOS уже 4-ой версии. Управление осуществляется через браузер. Интерфейс представлен на нескольких языках, в том числе на русском. Поддерживаются стандартные протоколы http и https с возможностью изменения номеров портов для большей безопасности. Интерфейс не требует установки Java, Flash и прочих сторонних средств. Также можно осуществлять управление через протокол ssh (правда, с чуть урезанным функционалом).
Интерфейс представляет собой вертикальное меню основных функций и область просмотра, занимающую основную часть экрана. Освоиться с навигацией и управлением – дело нескольких минут, поскольку все достаточно интуитивно понятно. Если вы когда-либо работали с СХД любого вендора, тут без проблем разберетесь. В интерфейсе, если что, есть поясняющие подсказки в отношении тех или иных значений параметров. Документация, разумеется, присутствует и обязательна к ознакомлению перед началом эксплуатации.
Интерфейс управления. Также доступен для ознакомления
Важной особенностью концепции управления СХД QSAN XCubeSAN является минимум ограничений на используемые конфигурации и максимум настроек для них. Здесь никто не будет вам навязывать, например, заранее предопределённые конфигурации по дискам. Для большинства ключевых функций имеются широкие возможности по настройке, а не просто включить/выключить. Поэтому ограничением при построении конфигураций будет выступать скорее ваш здравый смысл, нежели программное обеспечение.
Обслуживание системы в процессе эксплуатации предусматривает оповещение администратора о возникших проблемах с СХД. QSAN XCubeSAN может рассылать подобную информацию по e-mail, отправлять сообщения на syslog сервер и выдавать SNMP trap. Помимо этого, о текущем состоянии можно узнать из WebGUI: подробный мониторинг аппаратных датчиков, текущую производительность всей системы, отдельных дисков, томов и портов ввода/вывода.
Отдельно хотим отметить функцию интеграции СХД с источниками бесперебойного питания. Поддерживается связь с ИБП через COM и USB порты, а также через Ethernet. Итогом такой связи является возможность выключения СХД по команде от ИБП. Чаще всего в случае внезапного отключения электричества достаточно корректно завершить работу серверов, а СХД можно просто отключить от питания. Но если организовывать процесс аварийного отключения по всем правилам, то подобная интеграция СХД и ИБП будет очень кстати, т.к. позволит корректно выключить всю инфраструктуру, в том числе и систему хранения.
Раз уж зашла речь о возможных инцидентах с оборудованием, то нельзя не отметить современную тенденцию большинства вендоров по внедрению автоматической системы отсылки информации о состоянии оборудования в «облачные» сервисы, с целью анализа этой информации в Big Data и прогнозирования возможных сбоев. Сервис, безусловно, полезный, но в нашей стране он сталкивается с ожесточенным сопротивлением со стороны пользователей, которые не хотят делиться подобными данными с кем-то извне. Это может быть обусловлено разными причинами: политиками безопасности на месте эксплуатации, страхом, что будет отправлена конфиденциальная информация либо платностью такой услуги. Отчасти по этой причине QSAN не предоставляет сервис автоматического сбора данных о состоянии своих СХД. Вместо этого, для эффективной диагностики систем СХД имеет расширенный режим логирования всех внутренних процессов. Поэтому администратору достаточно отправить в техподдержку файл с debug info, чтобы инженеры смогли максимально точно определить источник проблемы.
Обновление прошивки производится «на ходу» без остановки работы системы. Для современной СХД это уже стандарт де факто, но не упомянуть об этом нельзя.
Пространство хранения в QSAN XCubeSAN основано на модной сейчас концепции пулов. Физические диски объединяются в RAID группы, которые, в свою очередь, образуют пулы. Популярность пулов в настоящее время обусловлена тем, что, в отличие от классических RAID групп, они являются в своем роде надстройкой в виде виртуализации дискового пространства и позволяют совершать ряд операций наиболее безболезненно по отношению к данным. И в первую очередь это – такая обыденность, как расширение пространства хранения. Добавление новых дисков в RAID группу всегда было весьма рисковой операцией, так как во время перестройки группы никакие алгоритмы RAID не обеспечивают защиту данных. К тому же процесс перестройки весьма небыстрый (в зависимости от объема и типа дисков мог достигать нескольких дней и даже недель), диски в этот момент испытывают повышенную нагрузку, что только может ускорить выход одного из них из строя. Поэтому, если произойдет сбой диска, то все данные, расположенные в группе, уйдут в небытие. Восстановление из резервной копии и восполнение каким-то образом измененных данных с момента создания бэкапа никак не добавит энтузиазма администраторам для проведения операций по расширению массива.
При использовании пулов, наоборот, все весьма просто. Команда расширения пула – это создание еще одной или нескольких RAID групп с присоединением их к существующим группам. В результате администратору будет доступно общее пространство как единое целое несмотря на то, что состоит оно из нескольких кусков. Рекомендуется расширять существующий пул группами такого же уровня, что и исходный, в целях получения максимальной производительности. Но при необходимости можно «склеить» в один пул, например, группы RAID5 и RAID6. Просто следует помнить, что в таком случае производительность будет ограничиваться самым медленным звеном.
В рамках единого пула можно совмещать не только группы с различными уровнями RAID, но и различные типы дисков. Более того, СХД может автоматически перемещать данные между дисками в соответствии с востребованностью этих данных. Такой функционал по перемещению данных называется тиринг (tiering). В тиринг-пуле может быть до трех уровней:
Для тиринг-пула можно гибко задавать расписание, когда и с каким приоритетом производить миграцию данных (хоть каждый час). Но разумным значением будет перемещение 1-2 раза в сутки, чтобы это не оказывало сильного влияния на текущие задачи и, вместе с тем, было эффективно с точки зрения итоговой производительности. Важно, что все эти настройки можно изменять «на лету».
Для томов, созданных на тиринг-пуле, можно указывать начальное положение, а также в каком направлении перемещать данные. Для всех томов доступна подробная статистика: что и куда было перемещено.
Помимо тиринга другим способом повышения быстродействия является SSD кэширование. В этом случае часто востребованные данные копируются на выделенные SSD. Хотим сразу заострить внимание на том, что в СХД QSAN SSD кэш работает не только для операций чтения, но и для операций записи. Сам кэш физически располагается на выделенных SSD, которые не доступны для хранения данных. Самих SSD в составе кэша может быть несколько (в том числе разного объема), все они используются совместно. Если используется кэш на запись, то число SSD должно быть кратно двум. Это необходимо для защиты данных (зеркалирование), т.к. в случае отказа одного из SSD важно не потерять содержимое кэша, которое еще не было записано на диски. В случае использования кэша только на чтение необходимости защищать его нет, т.к. он содержит всего лишь копию данных, расположенных на дисках.
Статистика работы кэша
В отличие от продуктов других вендоров, где функция SSD кэша имеет лишь единственную настройку «включить/выключить», в QSAN XCubeSAN данный функционал вовсе не представляет собой «черный ящик». Для всех томов, которым необходимо кэширование, выбирается «профиль поведения», в соответствии с которым данные попадают в кэш. Есть несколько предопределенных профилей (база данных, файл сервер, web сервер), а также возможность создать новый, конкретно под ваши задачи. Для него необходимо указать, какими блоками производить кэширование, а также задать количество запросов на чтение/запись, после которого блок будет скопирован в кэш. Благодаря такой гибкости в настройках данной опции СХД QSAN XCubeSAN могут показывать лучшие результаты в плане производительности в ряде пользовательских задач, нежели СХД других производителей.
Без такого важного функционала, касающегося безопасности данных, как снапшоты современной СХД уже и не существует. В QSAN это, разумеется, тоже присутствует. Снапшоты работают по технологии copy-on-write. Могут создаваться вручную и по расписанию с частотой вплоть до 15 минут. Есть интеграция с Microsoft VSS для создания консистентных с точки зрения приложений снапшотов. Также они могут монтироваться в виде томов в том числе и с правами на запись.
Функции, которые основаны на технологии снапшотов также не оставлены без внимания. Это – репликация и клонирование. Они отличаются друг от друга тем, что клонирование – это создание копии тома в рамках единой системы, а репликация – это создание копии на другой физической СХД. Обе операции выполняются блочным асинхронным методом. Минимально возможный интервал – 15 минут. В качестве приемного устройства при репликации не обязательно должна быть точно такая же модель СХД. Главное, чтобы это тоже была СХД QSAN. В качестве транспорта выступает протокол iSCSI. Возможна работа через низкоскоростные каналы, в том числе и через Интернет. Имеется поддержка многопутевого ввода/вывода для обеспечения отказоустойчивости процесса и утилизации пропускной способности имеющихся каналов связи. А чтобы репликация не мешала работе основных сервисов компании, в настройках можно активировать traffic shaping. Поддерживаются различные топологии при репликации: одно и двухсторонние, один-ко-многим, многие-к-одному. Таким образом, возможно построение катастрофоустойчивых решений (disaster recovery) с различными конфигурациями.
Стоит отметить, что из всего перечисленного функционала только две технологии являются платными и подлежат дополнительному лицензированию. Это – тиринг и SSD кэширование. Остальные функции доступны сразу «из коробки» без каких-либо ограничений. Да и две указанные лицензии приобретаются один раз на весь срок эксплуатации без привязки к объему данных, количеству полок расширения и пр. Да и не стоит забывать, что СХД Qsan поддерживает установку сторонних SSD. Так что довольно часто имеет смысл просто разместить данные, критичные к производительности дисковой подсистемы, на твердотельных накопителях и не заморачиваться, например, тем же тирингом.
XCubeSAN – это флагманская платформа QSAN, которая продолжает совершенствоваться. В частности, в стадии разработки находятся такие функции, как QoS, синхронная репликация и интеграция с VMware SRM. Все это будет доступно пользователям при будущих обновлениях прошивок. Но и с текущим функционалом XCubeSAN выглядит достаточно солидно на фоне конкурентов, что позволяет ей стать ядром IT инфраструктуры компании любого масштаба.
Проверка в деле
Познакомившись с аппаратными и программными особенностями СХД QSAN XCubeSAN, пришло время для испытаний этой платформы в деле.
Сегодня можно с уверенностью сказать, что производительность любых конфигураций с жесткими дисками на современных СХД разных вендоров плюс-минус одинаковая и определяется производительностью самих дисков. Могут быть отличия из-за различных алгоритмов кэширования или особенностей реализации RAID групп. Но эти отличия едва ли стоят детального изучения. В Enterprise сегменте ключевыми характеристиками оборудования, напрямую влияющими на его выбор, являются беспроблемная работа в составе программно-аппаратного комплекса и квалифицированная техническая поддержка. Поэтому выискивать с лупой разницу в производительности между, например, СХД, как это делают при обзорах консьюмерского «железа», никому не интересно. Однако показатели производительности все же играют роль в некоторых топовых конфигурациях, когда узким местом могут стать вовсе не накопители. Так что все приведенные ниже тесты были проведены в конфигурации All Flash.
Чтобы попытаться «положить» систему во время теста, вызвав насыщение контроллеров СХД запросами, потребуется достаточно большое количество SSD. К сожалению, мы не располагаем в постоянном доступе столь большим их количеством. Поэтому в этой статье мы приводим результаты тестов, которые проводили специалисты из StorageReview, когда писали свои обзоры СХД QSAN XCubeSAN. Они использовали 24 штуки Toshiba PX04SV SAS 3.0 SSD. Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД, но вполне хватит показать, на что в принципе способна серия XCubeSAN.
В тестах использовалось две системы на 26 дисков: младшей серии XS1200 и старшей серии XS5200. Помимо ответа на вопросы по поводу общей производительности, можно также понять, что дает более производительный процессор в СХД (на самом деле между сериями есть еще разница в объеме предустановленной кэш памяти, но в данных тестах этот показатель был одинаковый).
Если кому не интересно смотреть графики тестов, можете смело проматывать к выводам. Для остальных предоставляем более детальную информацию.
Описание стенда:
4 node Cluster на базе серверов Dell PowerEdge R740xd
На СХД было создано 2 пула RAID10 по 12 дисков в каждом. По одному пулу на каждый контроллер СХД. На каждом пуле было создано по одному тому размером
5TB.
В качестве тестового ПО использовался пакет VDBench от Oracle, который помимо тестов на случайный и последовательный доступ эмулирует работу баз данных SQL и Oracle, а также работу VDI окружения.