Часть 1: знакомство с панелью управления
Часть 2: развертывание Exchange Server
Часть 3: хранилище Storage Spaces
Продолжаем серию статей о виртуальной инфраструктуре на 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-диски на верхнем уровне. Такой тип хранилища позволяет более эффективно использовать ресурсы.
Запись и фильтрация данных в многоуровневом хранилище.
Чтобы получить такое умное хранилище и заставить его работать, нам пришлось повоевать. Проблема, с которой мы столкнулись, – низкая скорость обработки данных. Показатели записи SSD-дисков не превышали 100 Мбит/сек, что в 10 раз ниже необходимых для нормальной производительности. Проблема появилась сразу же при развертывании ВМ из шаблона: одна ВМ размером 10 Гб разворачивалась 30–40 минут, развертывание двух ВМ занимало порядка двух часов.
Подозрение пало на прошивку дисков: дефолтная не поддерживала одновременный доступ с разных нод кластера. После обновления прошивки развертывание нескольких ВМ перестало приводить к такому сильному падению производительности. Однако все происходило по-прежнему долго.
Мы продолжили искать проблему на самом нижнем уровне архитектуры и стали анализировать процесс обмена данными драйвера ОС с диском, а именно: чтение и запись секторов на диск. Существует два определения сектора: логический и физический. Логическим сектором оперирует драйвер операционной системы, физическим – непосредственно контроллер жесткого диска. В данное время жесткие диски делятся на три типа по соотношению размера логический/физический сектор:
Когда в пуле находятся диски одного типа, никаких проблем с создаваемым CSV-томом и располагающимися на нем файлами виртуальных жестких дисков нет. Проблемы начинаются, когда в пуле объединены диски разного типа. В нашем случае пул содержал 512 Native (SATA) и 512е (SSD) диски. Логично думать, что CSV-том будет создан с логическим сектором 512 байт. В реальности оказалось, что для вновь создаваемых ВМ разработчики установили по умолчанию создание CSV-тома с логическим сектором 4096.
В итоге получалась следующая картина:
Схема взаимодействия. Физический сектор учитывается только на уровне контроллера жесткого диска.
Сложилась ситуация, в которой у вышележащего диска логический сектор меньше, чем у нижележащего. Это привело к выполнению политики Read-Modify-Write: чтение сектора 4К в кэш, правка необходимых 512 байт, запись 4К обратно на диск. Как следствие, к катастрофическому падению производительности дисковой подсистемы во время записи в 8 раз.
Процесс записи 512-байтного сектора на носитель с 4096-байтным сектором.
В рамках Windows Server 2016 вышла обновленная версия Storage Spaces – Storage Spaces Direct. Как обещает вендор, в новом решении устранены проблемы текущей реализации программно-определяемой СХД и есть новые возможности:
Мы уже начали экспериментировать со Storage Spaces Direct и в ближайшее время расскажем о первых впечатлениях. Задавайте вопросы в комментариях.
Автор: Сергей Груздов
Часть 2: развертывание Exchange Server
Часть 3: хранилище Storage Spaces
Продолжаем серию статей о виртуальной инфраструктуре на Microsoft Hyper-V.
Сегодня расскажем, как устроено хранилище на базе Storage Spaces и с какими сложностями мы столкнулись при его построении.
Содержание
Архитектура хранилища
Проблема производительности хранилища на Storage Spaces
Что впереди: Storage Spaces Direct
Архитектура хранилища
Самой сложной задачей при создании облака 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-байтным сектором.
Мы нашли два пути решения проблемы:
- Пересоздание существующих виртуальных жестких дисков с размером логического сектора 4К. В итоге этот вариант нам не подошел, так как не все компоненты архитектуры поддерживают виртуальные диски, расположенные на томах с сектором 4096.
- Миграция существующих виртуальных жестких дисков во временное расположение и пересоздание тома CSV с размером логического сектора 512. Этот вариант мы и выбрали.
В таблице ниже показаны значения скорости до и после внедрения этого решения. В случае “после” проверка проводилась одновременным запуском тестирования DiskSpd на 15 виртуальных машинах.
Что впереди: Storage Spaces Direct
В рамках Windows Server 2016 вышла обновленная версия Storage Spaces – Storage Spaces Direct. Как обещает вендор, в новом решении устранены проблемы текущей реализации программно-определяемой СХД и есть новые возможности:
- Многопоточная дедупликация, которая позволяет выделять определенные ядра процессора на процесс дедупликации. В Storage Space сейчас доступна только однопоточная дедупликация на базе одного ядра процессора. Дедупликация в реальном времени невозможна, а сам процесс занимает много времени.
- Ребалансировка. Все данные можно перераспределять по томам. Это позволяет добиться большей производительности дисковой подсистемы. В Storage Space при добавлении новых жестких дисков в пул данные начнут попадать на добавленные жесткие диски только после заполнения изначально выделенных дисков.
- Различные варианты масштабирования. В Storage Spaces масштабирование происходит только путем добавления новых дисковых полок, что дорого и неудобно.
Мы уже начали экспериментировать со Storage Spaces Direct и в ближайшее время расскажем о первых впечатлениях. Задавайте вопросы в комментариях.
Автор: Сергей Груздов