angle-left

SSD read cache vs Tier 0 на примере СХД DELLEMC ME4

У заказчика случилась неприятность. У него поднята виртуальная инфраструктура из пяти серверов DELLEMC R740 с ESXi 6.7 и одной СХД DELLEMC ME4084. В один непрекрасный момент различные виртуальные машины начали страдать от нехватки производительности, к тому же миграция ВМ даже самого незначительного размера временами выполнялась подозрительно долго.
Как оказалось, всему виной одна виртуальная машина, которая без ограничений потребляла ресурсы ЦП и хранилища. Для нас она сыграла роль бенчмарка в проде, с которым были опробованы две конфигурации из заголовка статьи. Сразу предупрежу, что конфигурация не богатая, но с другой стороны тиринг вообще решение "для бедных".
Для начала несколько слов о логическом устройстве системы хранения ME4. Диски собираются в RAID-группы, добавляются в пулы. В пуле создаются тома, которые уже презентуются хостам. Система двухконтроллерная, обработкой запросов к дискам одного пула целиком занимается один контроллер. Если в системе создан только один пул, работать будет только один контроллер, второй будет существовать только для отказоустойчивости, запросы он обрабатывать не будет.
Поэтому на СХД заказчика создано два пула (A и B), каждый закреплен за своим контроллером и конфигурация их идентична.
Далее я приведу часть конфигурации, которая не изменялась, а затем - две конфигурации для сравнения (с кэшем на чтение и с тирингом).
Характеристики виртуальной машины "бенчмарка":
  • 4 vCPU.
  • Объём виртуального диска ~130ГБ (thick provisioning).
  • Характеристик а ввода-вывода: случайная запись 43% блоком ~8КБ, случайное чтение 57% блоком ~32КБ.
Подключение хостов через два 16Гб FC-коммутатора.
Конфигурация СХД для пула B в пределах которого всё происходило.
Случай 1.
Дисковая группа 0. Read cache без отказоустойчивости. 2шт SSD Samsung MZILT960HAHQ0D3. Совокупный объём 1.8ТБ.
Дисковая группа 1. ADAPT RAID (а-ля виртуализированный RAID-6). 12шт HDD Seagate DL2400MM0159. Совокупный объём 19.1ТБ.
Со стороны гипервизора видим следующую картинку, ~2.3К IOPS на запись, ~3.2 IOPS на чтение:
Со стороны СХД порядка 65-70% запросов чтения уходят в кэш (кстати cache read ahead работает в режиме adaptive). Порядка 250 IOPS на запись и очереди длиной по 4-5 (а то и 10) запросов к каждому физическому диску:
 
Случай 2.
Дисковая группа 0. RAID-1 на тех же 2шт SSD Samsung MZILT960HAHQ0D3. Совокупный объём 940ГБ.
Дисковая группа 1. Всё тот же ADAPT RAID на 12 HDD-дисках без изменений.
Дисковая группа 0 добавлена в пул B, соответственно для этого пула начинает работать тиринг. В конфигурации пула Tier affinity выбран Performance, т.е. запись в первую очередь на SSD.
Со стороны гипервизора видим (голубеньким показана интересующая виртуалка):
За первый час работы в таком режиме на Performance tier легло порядка 190ГБ данных, то есть в приципе вся виртуалка. Порядка 97% запросов (и чтение и запись) обрабатывается на Tier 0, т.е. SSD. При этом число IOPS прилетающее на СХД - порядка 20K. Если посмотреть на потребление ЦП виртуалкой, оно возросло более двух раз (интересующий интервал обведён в красный овал):
Снижение частоты в правом конце графика - результат лимита по IOPS, выставленного в свойствах виртуальной машины.
До ограничения ВМ, получив прирост в скорости обработки ввода-вывода, смогла догрузить ЦП и увеличить количество запросов почти в 4 раза, работая по сути на одной зеркалированной SSD. При этом все остальные диски на СХД расслабились, очереди опустели, количество запросов снизилось до 20-50 на один физический диск.
Понятно что в обоих случаях система работала на износ. Но данный пример наглядно показывает, как легко и непринуждённо тиринг может повысить производительность за счёт размещения на производительных носителях небольшого объёма востребованных данных (менее 200 ГБ при общем размере тома 15ТБ) .
Вперед