Несколько лет назад начался переход от colocation к облачной модели ИТ-сервисов. Запросы рынка к облачным сервисам оказали существенное влияние на развитие систем хранения данных и требования, предъявляемые к их производительности.

 

Выбор СХД для корпоративного облака

При использовании виртуализации для корпоративного облака нагрузка со стороны виртуальной инфраструктуры на систему хранения произвольная. Разные приложения одновременно обращаются к СХД с разным профилем нагрузки — распределение ее невозможно спрогнозировать. При этом должны соблюдаться жесткие требования к количеству операций ввода-вывода (IOPS) и времени отклика (latency).

Под такой тип нагрузки лучше всего подходят системы хранения данных, построенные на базе твердотельных накопителей (SSD). Но еще несколько лет назад емкость SSD-накопителей была небольшой, а цена — очень высокой, что ощутимо влияло на конечную стоимость сервиса.

Чтобы найти баланс между высокой производительностью и большим объемом невостребованного дискового пространства, в виртуальном дата-центре можно использовать SSD-кеш на всех системах хранения (в пределах 5–15% от общей дисковой емкости), что снизит время отклика и увеличит производительность без добавления избыточного количества дисков. Высокая производительность такого подхода хорошо ощутима на решениях VDI (Virtual Desktop Infrastructure), где дедуплицированные данные занимают мало места в кеше и при этом создается впечатление, что диски виртуальных серверов размещены на SSD-томе.

WARNING


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

NetApp FAS3250

Рассмотрим системы хранения данных виртуального дата-центра, построенного на оборудовании HPE и NetApp. Эти компании лидируют в производстве быстрых, гибких и отказоустойчивых систем хранения, их СХД дают максимальную производительность при разнородной нагрузке.

Первой продуктивной системой хранения с использованием SSD-кеша была NetApp FAS3250, в которую устанавливались Flash Cache PCI-платы емкостью 1 Тбайт на каждый контроллер. Далее нарастить полезную емкость без снижения производительности позволили смешанные дисковые полки Flash Pool (по четыре SSD-диска на каждую полку с дисками других типов). Такой вид кеширования (Flash Pool) позволял ускорять операции чтения и записи, что было невозможно при использовании Flash Cache.

В основе архитектуры Data ONTAP (ОС NetApp) лежит файловая система WAFL (Write Anywhere File Layout), которая новые данные всегда пишет в свободное место, как при последовательной записи, что позволяет таким системам хранения иметь небольшой RAM-кеш контроллера при высоких показателях производительности. Подобная архитектура позволила получать хорошие результаты на произвольную запись даже на NL-SAS-дисках. Например, средние значения write при тестировании: 72 763 Кбит/с, 18 190 IOPS, latency — 1,7 мс. Данные получены с тестового виртуального сервера (программа тестирования fio, тестировался RAW-раздел без файловой системы), размещенного на NL-SAS-дисках (собран из 94 дисков по 2 Tбайт). Во время тестирования системы хранения были нагружены данными.

По умолчанию на дисковом уровне данные защищены технологией RAID-DP (как вариант модифицированного RAID 6). Если на других системах хранения часто применяется RAID 1 («зеркало»), то недостатки RAID 6 при случайной перезаписи нивелируются благодаря WAFL.

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

Можно продуктивно использовать NFS как основной протокол подключения к дисковым массивам NetApp. Среди прочего данный тип подключения позволяет получить гибкую легко масштабируемую инфраструктуру при выносе части облака в резервный дата-центр, где также применяется технология Flash Pool при сайзинге системы хранения NetApp FAS8040.

 

3PAR

Рассмотрим системы хранения 3PAR, линейки 74xx и 84xx. По результатам нескольких лет работы с массивами можно с уверенностью отнести их к числу лучших систем хранения для применения в виртуализированных средах. 3PAR для ускорения операций чтения на более медленных типах дисков предлагают использовать SSD-кеш с возможностью тиринга. Например, для размещения данных используется составной том: на SAS-дисках (~45%), на наиболее медленных NL-SAS (~50%) и на SSD (~5%). Так, на массиве нужно задать только изначальное процентное соотношение и периодичность миграции горячих и холодных блоков. Далее массив анализирует, к каким данным наиболее часто происходит обращение, и, набрав статистику, с определенной периодичностью производит миграцию с более медленного на более быстрый уровень и наоборот. Когда часть блоков располагается на «медленных» дисках, помогает SSD-кеш, работающий одновременно с тирингом. Также полезен механизм Dynamic Optimization, позволяющий на уровне системы хранения мигрировать виртуальные серверы на более производительный тип дисков без прерывания сервиса.

3PAR использует виртуализацию дискового пространства, а именно все однотипные физические диски в массиве разбиваются на кусочки (чанклеты) по 1 Гбайт, из которых строятся логические диски с заданным типом RAID. Далее из этих логических дисков создаются тома, что позволяет увеличить быстродействие, так как в операциях чтения/записи принимают участие все однотипные диски, установленные в массив.

Когда выходит из строя один из дисков, процесс ребилда (перестроения) занимает значительно меньше времени, чем при классическом подходе, когда используются отдельные диски под spare. Здесь как раз сказывается архитектура организации хранения на низком уровне. Массивы 3PAR не выделяют отдельных дисков под spare, они используют зарезервированные чанклеты, которые расположены на всех дисках, то есть при выходе одного диска из строя данные перемещаются со всех однотипных дисков массива на все, а не с многих на один, как в классическом сценарии.

 

All-flash

Долгое время построение систем хранения данных на базе SSD оставалось оправданно только для бизнес-критичных задач, так как SSD-носители были довольно дорогими и отличались небольшим сроком службы. SSD-диски имели достаточно низкий ресурс на запись/перезапись. Как только производители систем хранения смогли добиться высокого количества циклов перезаписи, стоимость all-flash-систем начала снижаться, а в некоторых случаях оказалась сопоставимой со стоимостью SAS. Стало возможным развертывание бизнес-критичных приложений в виртуальной среде с максимальным быстродействием и минимальным временем отклика.

INFO


Сегодня лидеры отрасли предлагают интересные решения с применением SSD-дисков емкостью 7,68 Tбайт и 15,36 Tбайт в одном накопителе в зависимости от форм-фактора.

Рассмотрим особенности работы all-flash систем хранения на примере HP 3PAR 8450. Массивы 3PAR разносят все тома по всем SSD-носителям массива, что при равномерном распределении нагрузки предотвращает износ конкретных дисков. При этом чип ASIC в каждом контроллере исключает запись нулевых блоков. Вместо центрального процессора массива он выполняет операции детектирования нулей, аппаратной поддержки XOR (для подсчета контрольных сумм в RAID 5, RAID 6), дедупликации и другие операции. Эти системы хранения позволяют использовать четыре контроллера в рамках одной системы в режиме Active/Active. Так, каждый из контроллеров может работать с каждым томом, и поэтому нагрузка равномерно распределяется по всем контроллерам. Чтобы избежать проседания производительности при выходе контроллера из строя или при его перезагрузке, кеш на запись зеркалируется между четырьмя контроллерами.

Одна из востребованных функций all-flash-массивов — QoS (Quality of Service), позволяющая гарантированно получать требуемые значения IOPS, latency в рамках виртуальной инфраструктуры.

Массивы 3PAR можно использовать в рамках двух разнесенных площадок, появляется возможность предложить функциональность Peer Persistence (разнесенный отказоустойчивый кластер VMware). В этом решении LUN с дисками виртуальных серверов реплицируется между массивами в разнесенных дата-центрах. К LUN создаются активные и пассивные пути, которые видны хостам ESXi. Реплика основного LUN представлена тем же WWN, что и основной. Поэтому для среды VMware переключение LUN с основного на резервный происходит прозрачно. Применение Peer Persistence позволяет нам автоматизировать процесс переключения между площадками и не требует привлекать дополнительные решения, как, например, VMware Site Recovery Manager.

При использовании all-flash-массива на двух площадках RTT будет относительно высоким в сравнении с локальной площадкой, поэтому лучше применять асинхронную репликацию с удаленной площадкой или условно синхронную репликацию данных, когда массив на основной площадке не ждет подтверждения записи, а сразу стремится записать новые данные на удаленную площадку. Используя условно синхронную репликацию на SSD-дисках, можно сохранить высокую производительность локальной площадки и в то же время получить хороший RPO на удаленной.

4 комментария

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Magisk. Модифицируем прошивку Android с комфортом

Скажи, ты когда-нибудь вносил изменения в прошивку? Не Xposed, а более низкоуровневые — на…