Облако на Microsoft Hyper-V, часть 3: хранилище Storage Spaces

Сегодня расскажем, как устроено хранилище на базе Storage Spaces и с какими сложностями мы столкнулись при его построении.

17 ноября 2016  •  Сергей Груздов

Часть 1: знакомство с панелью управления

Часть 2: развертывание Exchange Server

Продолжаем серию статей о виртуальной инфраструктуре на Microsoft Hyper-V.

Сегодня расскажем, как устроено хранилище на базе Storage Spaces и с какими сложностями мы столкнулись при его построении.

Содержание

Архитектура хранилища

Самой сложной задачей при создании облака Cloud-V оказалось создание быстрого программно-определяемой СХД на базе Microsoft Storage Spaces.

В основе хранилища — кластер на базе двух серверов Dell PowerEdge 730 с подключенным к ним дисковым массивом Dell PowerVault 3060e.

Архитектура Storage Spaces.

Вместо традиционной сети хранения SAN мы построили конвергентную локальную сеть с пропускной способностью 40 Гбит. В кластере развернули роль Scale-out-file server с поддержкой компонентов SMB Direct и SMB Multichannel.

SMB Multichannel позволяет балансировать подключения узлов вычислительного кластера к ресурсам хранилища при наличии нескольких сетевых адаптеров на сервере. Мы использовали сетевые адаптеры Mellanox ConnectX-3 Pro 40GbE, поддерживающие функцию ROCE (RDMA over Converged Ethernet).

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

Взаимодействие приложения и дискового хранилища: без RDMA (слева) и с RDMA (справа).

Высокая производительность программно-определяемой СХД Storage Spaces достигается за счет использования разного типа дисков (SATA, SAS, SSD). Фактически у нас получилось многоуровневое хранилище, данные в котором распределяются по разным типам дисков в зависимости от интенсивности использования. Storage Spaces фильтрует данные и отправляет редко используемые на нижний уровень (HDD), а “горячие” данные – на быстрые SSD-диски на верхнем уровне. Такой тип хранилища позволяет более эффективно использовать ресурсы.

Запись и фильтрация данных в многоуровневом хранилище.

Проблема производительности хранилища на Storage Spaces

Чтобы получить такое умное хранилище и заставить его работать, нам пришлось повоевать. Проблема, с которой мы столкнулись, – низкая скорость обработки данных. Показатели записи SSD-дисков не превышали 100 Мбит/сек, что в 10 раз ниже необходимых для нормальной производительности. Проблема появилась сразу же при развертывании ВМ из шаблона: одна ВМ размером 10 Гб разворачивалась 30–40 минут, развертывание двух ВМ занимало порядка двух часов.

Подозрение пало на прошивку дисков: дефолтная не поддерживала одновременный доступ с разных нод кластера. После обновления прошивки развертывание нескольких ВМ перестало приводить к такому сильному падению производительности. Однако все происходило по-прежнему долго.

Мы продолжили искать проблему на самом нижнем уровне архитектуры и стали анализировать процесс обмена данными драйвера ОС с диском, а именно: чтение и запись секторов на диск. Существует два определения сектора: логический и физический. Логическим сектором оперирует драйвер операционной системы, физическим – непосредственно контроллер жесткого диска. В данное время жесткие диски делятся на три типа по соотношению размера логический/физический сектор:

  • 512 Native – логический 512, физический 512;
  • 512е – логический 512, физический 4096;
  • 4096 Native – логический 4096, физический 4096.

Когда в пуле находятся диски одного типа, никаких проблем с создаваемым CSV-томом и располагающимися на нем файлами виртуальных жестких дисков нет. Проблемы начинаются, когда в пуле объединены диски разного типа. В нашем случае пул содержал 512 Native (SATA) и 512е (SSD) диски. Логично думать, что CSV-том будет создан с логическим сектором 512 байт. В реальности оказалось, что для вновь создаваемых ВМ разработчики установили по умолчанию создание CSV-тома с логическим сектором 4096.

В итоге получалась следующая картина:

Схема взаимодействия. Физический сектор учитывается только на уровне контроллера жесткого диска.

Сложилась ситуация, в которой у вышележащего диска логический сектор меньше, чем у нижележащего. Это привело к выполнению политики Read-Modify-Write: чтение сектора 4К в кэш, правка необходимых 512 байт, запись 4К обратно на диск. Как следствие, к катастрофическому падению производительности дисковой подсистемы во время записи в 8 раз.

Процесс записи 512-байтного сектора на носитель с 4096-байтным сектором.

Мы нашли два пути решения проблемы:

  1. Пересоздание существующих виртуальных жестких дисков с размером логического сектора 4К. В итоге этот вариант нам не подошел, так как не все компоненты архитектуры поддерживают виртуальные диски, расположенные на томах с сектором 4096.
  2. Миграция существующих виртуальных жестких дисков во временное расположение и пересоздание тома CSV с размером логического сектора 512. Этот вариант мы и выбрали. В таблице ниже показаны значения скорости до и после внедрения этого решения. В случае “после” проверка проводилась одновременным запуском тестирования DiskSpd на 15 виртуальных машинах.

Что впереди: Storage Spaces Direct

В рамках Windows Server 2016 вышла обновленная версия Storage Spaces – Storage Spaces Direct. Как обещает вендор, в новом решении устранены проблемы текущей реализации программно-определяемой СХД и есть новые возможности:

  • Многопоточная дедупликация, которая позволяет выделять определенные ядра процессора на процесс дедупликации. В Storage Space сейчас доступна только однопоточная дедупликация на базе одного ядра процессора. Дедупликация в реальном времени невозможна, а сам процесс занимает много времени.
  • Ребалансировка. Все данные можно перераспределять по томам. Это позволяет добиться большей производительности дисковой подсистемы. В Storage Space при добавлении новых жестких дисков в пул данные начнут попадать на добавленные жесткие диски только после заполнения изначально выделенных дисков.
  • Различные варианты масштабирования. В Storage Spaces масштабирование происходит только путем добавления новых дисковых полок, что дорого и неудобно.

Мы уже начали экспериментировать со Storage Spaces Direct и в ближайшее время расскажем о первых впечатлениях. Задавайте вопросы в комментариях.

Расскажите друзьям и коллегам о статье
  • Поделиться
  • Плюсануть
  • Поделиться

Подписка на новые статьи

Новые статьи почтой

Пишем редко, но по делу

Последние статьи

Рассказали об основных пунктах соглашения, зонах ответственности сторон и о том, как применяются инциденты.
31 августа  •  Михаил Соловьев

Что делать, чтобы сайт рос без боли.

11 августа  •  Дмитрий Сорокин

Разбираемся в работе архивирования и чем оно может быть полезно.

04 августа  •  Александр Васильев

Комментарии