Традиционный вопрос обычно выглядит так:
— Хочу 100500 IOPS!
или:
— Хочу 20 терабайт.
Потом выясняется, что IOPS на самом деле нужно не так много и можно обойтись несколькими SSD, а с 20 терабайт (4 диска по нынешним временам) хотят снять весьма прилично, и в реальности это получится многоуровневое хранилище.
Как подойти к этому правильно и спланировать заранее?
Нужно последовательно ответить на несколько ключевых вопросов, например:
- Приоритет защиты целостности данных (например при сбое диска).
- Требуется производительность, но не ценой защиты.
- Умеренные требование к ёмкости.
- Размер бюджета для построения смешанного решения.
- Удобство управления и мониторинга.
Процесс создания хранилища на Storage Spaces
Основные технологии:
- Storage Spaces - Виртуализованное хранилище: отказоустойчивое и производительное.
- Failover Clustering - Высокодоступный доступ к хранилищу.
- Scale-Out File Server (SOFS) и Cluster Shared Volumes (CSV) - Масштабируемый и унифицированный доступ к хранилищу.
- SMB3 - Отказоустойчивый и производительный протокол, использующий SMB Multichannel, SMB Direct, и SMB Client Redirection.
- System Center, PowerShell и In-box Windows Tooling - Управление / конфигурирование / обслуживание.
Достоинства Storage Spaces: Гибкое и недорогое решение по хранению данных, полностью основанное на массовом оборудовании и ПО Microsoft.
Материал предполагает знакомство с основами Storage Spaces (доступны тут и тут).
По шагам:
1 |
Оценка решения |
Определить ключевые требования к решению, характеристики успешной инсталляции. |
2 |
Дизайн SDS (предварительный) |
Подбор существующих блоков (аппаратных и программных) под требования, выбор топологии и конфигураций. |
3 |
Тестовое развёртывание |
Проверка выбранного решения в реальном окружении, возможно, в уменьшенном масштабе (Proof-of-Concept, PoC). |
4 |
Валидация |
Проверка на соответствие требованиям пункта 1. Обычно начинается с синтетической нагрузки (SQLIO, Iometer и т.д.), итоговая проверка осуществляется в реальном окружении. |
5 |
Оптимизация |
По результатам предыдущих шагов и выявленных сложностей подстройка и оптимизация решения (добавить / убрать / заменить аппаратные блоки, модифицировать топологию, переконфигурировать ПО и т.д.), вернуться к пункту 4 |
6 |
Развёртывание (в реальной среде) |
После оптимизации первоначального решения до сформулированных требований наступает период внедрения финальной версии в реальную эксплуатационную среду. |
7 |
Рабочий процесс |
Фаза эксплуатации. Мониторинг, устранение неполадок, модернизация, масштабирование и т.д. |
Первый шаг был описан выше.
Определение архитектуры Software Defined Storage (предварительное)
Основные моменты:
- Работа тиринга.
- Подсчёт количества HDD и SSD.
- Оптимизация соотношения SSD:HDD.
- Определение требуемого количества дисковых полок.
- Требования к SAS HBA и кабельной инфраструктуре.
- Определение количества серверов хранения и конфигураций.
- Определение количества дисковых пулов (Pool).
- Конфигурирование пулов.
- Подсчёт количества виртуальных дисков.
- Определение конфигураций виртуальных дисков.
- Вычисление оптимального размера виртуального диска.
Общие принципы
Необходимо установить все обновления и патчи (а также прошивки).
Старайтесь сделать конфигурацию симметричной и целостной.
Учтите возможные сбои и создайте план для устранения последствий.
Почему важны прошивки
Ключевые требования: тиринг
Многоуровневое хранение (тиринг) значительно увеличивает общую производительность системы хранения. Однако, SSD диски обладают сравнительно небольшой ёмкостью и высокой ценой за гигабайт и несколько повышают сложность управления хранилищем.
Обычно тиринг всё-таки используется, и «горячие» данные помещаются на производительный уровень SSD дисков.
Ключевые требования: тип и количество жестких дисков
Тип, ёмкость и количество дисков должны отражать желаемую ёмкость системы хранения. Поддерживаются SAS и NL-SAS диски, но дорогие SAS 10/15K диски не так часто нужны при использовании тиринга с уровнем хранения на SSD.
Типичный выбор*: 2-4 ТБ NL-SAS, модель от одного производителя с последней стабильной версией прошивки.
* Типичные значения отражают актуальные рекомендации для работы с виртуализованнными задачами. Другие типы нагрузки требуют дополнительной проработки.
Расчёт по ёмкости:
Где:
a) Количество жёстких дисков.
b) Количество дисков — ближайшее сверху чётное значение к получившемуся числу.
c) Типичный размер блока данных (в гигабайтах).
d) Запас на расширение ёмкости.
e) Потери на обеспечение целостности данных. Two-way mirror, three-way mirror, parity и прочие типы массива предлагают разный запас «прочности».
f) Каждый диск в Storage Spaces хранит копию метаданных (о пулах, виртуальных дисках) + при необходимости нужно предусмотреть запас на технологию fast rebuild.
g) Емкость диска в гигабайтах.
Расчёт по производительности:
Где:
a) Количество жёстких дисков.
b) Количество дисков — ближайшее сверху чётное значение к получившемуся числу.
c) Количество IOPS, которое планируется получить с уровня жёстких дисков.
d) Процент записи.
e) Пенальти на запись, отличающееся для разных используемых уровней массива, которое необходимо учесть (для системы в целом, например, для 2-way mirror 1 операция записи вызывает 2 записи на диски, для 3-way mirror записей уже 3).
f) Оценка производительности диска на запись.
g) Оценка производительности диска на чтение.
* Расчёты приведены для отправной точки планирования системы.
Ключевые требования: тип и количество SSD
С жёсткими дисками разобрались, пора посчитать SSD. Их тип, количество и объем базируется на желаемом максимуме производительности дисковой подсистемы.
Увеличение ёмкости SSD уровня позволяет переместить больше задач на быстрый уровень с помощью встроенного tiering engine.
Так как количество столбцов (Columns, технология распараллеливания работы с данными) в виртуальном диске должно совпадать для обоих уровней, увеличение количества SSD обычно позволяет создать больше столбцов и увеличить производительность HDD уровня.
Типичный выбор: 200-1600 ГБ на MLC-памяти, модель от одного производителя с последней стабильной версией прошивки.
Расчёт по производительности*:
Где:
a) Количество SSD дисков.
b) Количество SSD — ближайшее сверху чётное значение к получившемуся числу.
c) Количество IOPS, которое планируется получить с уровня SSD.
d) Процент записи.
e) Пенальти на запись отличающееся для разных уровней массива, необходимо учесть при планировании.
f) Оценка производительности SSD на запись.
g) Оценка производительности SSD на чтение.
* Только для отправной точки. Обычно, количество SSD существенно превышает необходимый минимум для производительности из-за дополнительных факторов.
Рекомендованное минимальное количество SSD в полках:
Тип массива |
JBOD на 24 диска (2 столбца) |
JBOD на 60 дисков (4 столбца) |
Two-Way Mirror |
4 |
8 |
Three-Way Mirror |
6 |
12 |
Ключевые требования: соотношение SSD:HDD
Подбор соотношения — это баланс производительности, ёмкости и стоимости. Добавление SSD улучшает производительность (бОльшая часть операций происходит на SSD уровне, увеличивается количество столбцов в виртуальных дисках и т.д.), но существенно увеличивает стоимость и снижает потенциальную ёмкость (вместо ёмкого диска ставится небольшой SSD).
Типичный выбор: SSD:HDD*: 1:4 – 1:6
* По количеству, а не ёмкости.
Ключевые требования: количество и конфигурация дисковых полок (JBOD)
Дисковые полки различаются по многим показателям — количество устанавливаемых дисков, количество портов SAS и т.д.
Применение нескольких полок позволяет учесть их наличие в схемах отказоустойчивости (с помощью функции enclosure awareness), но также увеличивает дисковое пространство, необходимое для Fast Rebuild.
Конфигурация должна быть симметричной во всех полках (имеются ввиду кабельное подключение и расположение дисков).
Типичный выбор: количество полок >=2, IO модулей в полке — 2, единая модель, последние версии прошивок и симметричное расположение дисков во всех полках.
Обычно количество дисковых полок выбирается из общего числа дисков с учётом запаса для расширения и отказоустойчивости с учётом полок (с помощью функции enclosure awareness) и/или добавления SAS путей для пропускной способности и отказоустойчивости.
Расчёт:
Где:
a) Количество JBOD.
b) Округлённое вверх.
c) Количество HDD.
d) Количество SSD.
e) Свободные слоты для дисков.
f) Максимальное количество дисков в JBOD.
Ключевые требования: SAS HBA и кабели
Топология SAS кабелей должна обеспечивать подключение каждого сервера хранения к JBOD-полкам с помощью как минимум одного SAS-пути (то есть один порт SAS в сервере приходится на один порт SAS в каждом JBOD).
В зависимости от количества и типа дисков в JBOD-полках, суммарная производительность может легко достичь предела одного 4x 6G SAS порта (~2,2 ГБ/с).
Рекомендуется:
- Количество портов SAS на сервер >=2.
- Количество SAS HBA на сервер >=1.
- Последние версии прошивок SAS HBA.
- Несколько путей SAS к полкам JBOD.
- Настройки Windows MPIO: Round-Robin.
Ключевые требования: конфигурация серверов хранения
Здесь необходимо принять во внимание такие особенности как производительность серверов, количество в кластере для отказоустойчивости и удобства обслуживания, характеристики нагрузки (суммарные IOPS, пропускная способность и т.д.), применение технологий разгрузки (RDMA), количество портов SAS на JBOD и требования multipath.
Рекомендуется 2-4 сервера; 2 x процессора 6+ ядер; памяти >= 64 ГБ; два локальных жёстких диска в зеркале; два порта 1+ GbE для управления и два порта 10+ GbE RDMA для обмена данными; порт BMC либо выделен, либо совмещён с 1GbE и поддерживает IPMI 2.0 и/или SMASH; SAS HBA из предыдущего пункта.
Ключевые требования: количество дисковых пулов
На этом шаге учитываем, что пулы — это единицы как для управления, так и отказоустойчивости. Сбойный диск в пуле влияет на все виртуальные диски, расположенные на пуле, каждый диск в пуле содержит метаданные.
Увеличение количества пулов:
- Увеличивает надёжность системы, так как увеличивается количество элементов отказоустойчивости.
- Увеличивает количество дисков для резервного пространства (т.е. дополнительное пенальти), так как Fast Rebuild работает на уровне пула.
- Увеличивает сложность управления системой.
- Уменьшает количество столбцов в Виртуальном Диске (Virtual Drive, VD), снижая производительность,, так как VD не может растягиваться на несколько пулов.
- Снижает время для обработки метаданных пула, таких как ребилд виртуального диска или перенос контроля пулом в случае сбоя в кластере (улучшение производительности).
Типичный выбор:
- Количество пулов от 1 до количества дисковых полок.
- Диски/Пул <=80
Ключевые требования: конфигурация пулов
Пул содержит данные по-умолчанию для соответствующих VD и несколько настроек, влияющих на поведение хранилища:
Опция |
Описание |
RepairPolicy |
Sequential vs Parallel (соответственно, ниже нагрузка на IO, но медленно, или высокая нагрузка на IO, но быстро) |
RetireMissingPhysicalDisks |
С опцией Fast Rebuild выпавшие диски не вызывают восстановление пула, если выставлено значение Auto (при значении Always перестроение пула запускается всегда с использованием Spare диска. Но не сразу, а через 5 минут после первой неудачной попытки записи на этот диск). |
IsPowerProtected |
True означает, что все операции записи считаются выполненными без подтверждения со стороны диска. Отключение питания может вызвать повреждение данных, если нет защиты (подобная технология появилась и на жёстких дисках). |
Типичный выбор:
- Hot Spares: No
- Fast Rebuild: Yes
- RepairPolicy: Parallel (default)
- RetireMissingPhysicalDisks: Auto (default, рекомендуется MS)
- IsPowerProtected: False (default, но если включить — производительность существенно возрастает)
Ключевые требования: количество виртуальных дисков (VD)
Принимаем во внимание следующие особенности:
- Соотношение SMB папок, обслуживающих клиентов, к CSV слою и соответствующему VD; должно быть 1:1:1.
- Каждый виртуальный диск с тирингом имеет выделенный кэш WBC; увеличение количества VD может улучшить производительность для некоторых задач (при прочих равных).
- Увеличение количества VD увеличивает сложность управления.
- Увеличение количества нагруженных VD облегчает распределение нагрузки сбойного узла на другие элементы кластера.
Типичный выбор количества VD: 2-4 на каждый сервер хранения.
Ключевые требования: конфигурация виртуальных дисков (VD)
Доступны три вида массива — Simply, Mirror и Parity, но для задач виртуализации рекомендуется только Mirror.
3-way mirroring, по сравнению с 2-way, удваивает защиту от сбоя диска ценой легкого снижения производительности (выше пенальти на запись), уменьшения доступного пространства и соответствующего увеличения стоимости.
Сравнение видов зеркалирования:
Количество пулов |
Тип зеркала |
Накладные расходы |
Устойчивость пула |
Устойчивость системы |
1 |
2-way |
50% |
1 диск |
1 диск |
3-way |
67% |
2 диска |
2 диска |
|
2 |
2-way |
50% |
1 диск |
2 диска |
3-way |
67% |
2 диска |
4 диска |
|
3 |
2-way |
50% |
1 диск |
3 диска |
3-way |
67% |
2 диска |
6 дисков |
|
4 |
2-way |
50% |
1 диск |
4 диска |
3-way |
67% |
2 диска |
8 дисков |
Microsoft для Cloud Platform System (CPS) рекомендует 3-way mirror.
Ключевые требования: количество столбцов
Обычно, увеличение количества столбцов увеличивает производительность VD, однако могут возрасти и задержки (больше столбцов — больше дисков, которые должны подтвердить выполнение операции). Формула для вычисления максимального количества столбцов в конкретном зеркалированном VD:
Где:
a) Округление в меньшую сторону.
b) Количество дисков в меньшем уровне (обычно, это количество SSD).
c) Отказоустойчивость по дискам. Для 2-way mirror это 1 диск, для 3-way mirror это 2 диска.
d) Количество копий данных. Для 2-way mirror это 2, для 3-way mirror это 3.
Если выбрано максимальное количество столбцов и произошёл сбой диска, то в пуле не найдется нужного числа дисков для соответствия числу столбцов и, соответственно, fast rebuild будет недоступен.
Обычный выбор — 4-6 (на 1 меньше, чем вычисленный максимум для работы Fast Rebuild). Такая возможность доступна только в PowerShell, при построении через графический интерфейс система сама выберет максимально возможное количество столбцов, до 8.
Ключевые требования: опции виртуальных дисков
Опция Virtual Disk |
Соображения |
Interleave |
Для случайных нагрузок (виртуализованных, например), размер блока должен быть больше или равен крупнейшему активному запросу, так как любой запрос крупнее этого будет разбит на несколько операций, что снизит производительность. |
Размер кэша WBC |
Значение по-умолчанию — 1 ГБ, что является разумным балансом между производительностью и отказоустойчивостью для большинства задач (увеличение размера кэша увеличивает время переноса при сбоях, при переносе CSV тома обязательна процедура сброса и восстановления, а также возможны проблемы из-за отказа в обслуживании). |
IsEnclosureAware |
Повышается уровень защиты от сбоев, если возможно — рекомендуется использовать. Для активации необходимо соответствие количества дисковых полок уровню массива (доступно только через PowerShell). Для 3-way mirror нужно 3 полки, для dual parity 4 и т.д. Эта функция позволяет пережить полную потерю дисковой полки. |
Типичный выбор:
Interleave: 256K (default)
WBC Size: 1GB (default)
IsEnclosureAware: использовать по возможности.
Ключевые требования: размер виртуальных дисков
Получение оптимального размера VD на пуле требует вычислений для каждого уровня хранения и суммирования оптимальных размеров уровней VD. Необходимо также резервировать место для Fast Rebuild и метаданных, а также для внутренних округлений при вычислениях (погребено в глубинах стека Storage Spaces, так что просто резервируем).
Формула:
Где:
a) Консервативный подход, оставляет несколько больше неразмеченного места в пуле, чем необходимо для работы Fast Rebuild. Значение в GiB (степень числа 2, GB является производной степени 10).
b) Значение в GiB.
c) Резервное пространство для метаданных Storage Spaces (все диски в пуле содержат метаданные как пула, так и виртуальных дисков).
d) Резервное пространство для Fast Rebuild: >= размера одного диска (+ 8GiB) на каждый уровень в пуле в дисковой полке.
e) Размер уровня хранения и так округлён вверх на несколько «плиток» (Storage Spaces разбивает каждый диск в пуле на куски, называемыми «плитка», которые используются для построения массива), размер плитки равен размеру единицы Storage Spaces (1GiB), помноженному на число столбцов; поэтому округляем размер вниз к ближайшему целому, чтобы не выделить лишнего.
f) Размер кэша на запись, в GiB, для нужного уровня (1 для SSD уровня, 0 для HDD уровня).
g) Количество дисков в конкретном уровне конкретного пула.
Spaces-Based SDS: следующие шаги
С первоначальными оценками определились, переходим дальше. Изменения и улучшения (а они обязательно появятся) в полученные результаты будем вносить по итогам тестирования.
Пример!
Что хочется получить?
- Высокий уровень отказоустойчивости.
- Целевая производительность: 100K IOPS с SSD уровня, 10K IOPS с HDD уровня при случайной нагрузке блоками 64К с чтением записью 60/40
- Ёмкость — 1000 виртуальных машин, 40GB каждая и 15% резерва.
Оборудование:
Диски ёмкостью 2/4/6/8TB
IOPS (R/W): 140/130 R/W IOPS (заявленные характеристики: 175 MB/s, 4.16ms)
SSD ёмкостью 200/400/800/1600GB
IOPS
Read: 7000 IOPS @ 460MB/s (заявлено: 120K)
Write: 5500 IOPS @ 360MB/s (заявлено: 40K)
SSD в реальных задачах показывают заметно отличающиеся от заявленных цифры :)
Дисковые полки — 60 дисков, два SAS модуля, 4 порта на каждом ETegro Fastor JS300.
Вводные данные
Tiering необходим, поскольку требуется высокая производительность.
Требуется высокая надёжность и не очень большая ёмкость, используем 3-way mirroring.
Выбор дисков (исходя из требований по производительности и бюджета): 4TB HDD и 800GB MLC SSD
Расчёты:
Шпиндели по ёмкости:
Шпиндели по производительности (мы же хотим получить 10K IOPS):
Итоговая ёмкость существенно превосходит изначальные оценки, так как необходимо уложиться в требования по производительности.
SSD уровень:
Соотношение SSD:HDD:
Количество дисковых полок:
Расположение дисков в полках:
Увеличим количество дисков, чтобы получить симметричное распределение и оптимальное соотношение SSD:HDD. Для простоты расширения также рекомендуется заполнять дисковые полки полностью.
SSD: 32 -> 36
HDD: 136 -> 144 (SSD:HDD 1:4)
SSD/Enclosure: 12
HDD/Enclosure: 48
Кабели SAS
Для отказоустойчивого подключения и максимизации пропускной способности необходимо каждую дисковую полку подключить двумя кабелями (два пути от сервера к каждой полке). Итого 6 портов SAS на сервер.
Количество серверов
Исходя из требований по отказоустойчивости, IO, бюджета и требований организации multipath — берём 3 сервера.
Количество пулов
Количество дисков в пуле должно быть равно или меньше 80, берем 3 пула (180/80 = 2.25).
HDDs/Pool: 48
SSDs/Pool: 12
Конфигурация пула
Hot Spares: No
Fast Rebuild: Yes (резервируем достаточно пространства)
RepairPolicy: Parallel (default)
RetireMissingPhysicalDisks: Always
IsPowerProtected: False (default)
Количество виртуальных дисков
На основании требований используем 2 VD на каждый сервер, итого 6 равномерно распределённых по пулам (2 на пул).
Конфигурация виртуальных дисков
На основании требований по устойчивости к потере данных (например, нет возможности заменить сбойный диск в течении нескольких дней) и нагрузки, используем такие настройки:
Resiliency: 3-way mirroring
Interleave: 256K (default)
WBC Size: 1GB (default)
IsEnclosureAware: $true
Количество столбцов
Размер виртуального диска и уровней хранения
Итого:
Серверов хранения: 3
SAS портов/сервер: 6
SAS путей от сервера к каждой полке: 2
Дисковых полок: 3
Количество пулов: 3
Количество VD: 6
Virtual Disks/Pool: 2
HDD: 144 @ 4TB (~576TB сырого места), 48/полка, 48/пул, 16/полка/пул
SSD: 36 @ 800GB (~28TB сырого места), 12/полка, 12/пул, 4/полка/пул
Размер Virtual Disk: SSD Tier + HDD Tier = 1110GB + 27926GB = 28.4TB
Общая полезная ёмкость: (28.4)*6 = 170TB
Накладные расходы: (1 – 170/(576+28)) = 72%
Комментарии (13)
Shablonarium
08.05.2015 02:09А где можно почитать про основы всего этого?
Vinchi
08.05.2015 02:25+1в интернете, на технете. Смотря что понимать под «всего этого» :)
Если имеет ввиду storage spaces — в тексте как раз есть ссылки на технет.
Если вообще про SDS — тут множество производителей с различными решениями и взглядами на вопрос
iklementiev
08.05.2015 12:25Мы пробовали строить кластерные storage spaces в корпусах супермикро с дублированными экспандерами.
В итоге, серверы видели вместо одной физической корзины — две. Дублирование было из-за multipath'а, судя по всему.
В итоге, диски, находящиеся в одной физической корзине, могли, по мнению сервера, оказаться в двух разных. Enclosure Awareness в данном случае оказывалось в пролете.
Можете объяснить с технической стороны, почему так может происходить и нет ли таких спецэффектов с Fastor JS300? Сколько корзин показывает Get-StorageEnclosure при наличии двух путей до нее?
И чтобы два раза не вставать. Fastor JS300 как близнец похожа на Quanta MESOS M4600H. Их что то объединяет? А то некоторые MVP считают, что «Quanta suck»: www.aidanfinn.com/?p=18097. Можете прокомментировать?ETegro_Technologies Автор
08.05.2015 14:47Добрый день!
Мы строили системы и на JS200, и на JS300 — всё было в порядке, виделся один набор multipath дисков на обеих нодах, количество enclosure по детекту совпадало с физическим количеством (пробовали параллельное подключение и каскады).
На микре могла быть какая-то проблема с прошивкой экспандеров, они всегда были криворуки по этой части.
Что считает MVP — сказать сложно, он не раскрывает тему. Не нравятся ему в принципе взаимодействие с компанией или конкретные нюансы работы/особенности архитектуры, тайна сия велика есть. Могу только повториться — мы пробовали все варианты работы полок, негативного опыта не было.
vanxant
А не выгоднее будет в данном случае раскошелиться на более оборотистые HDD?
ETegro_Technologies Автор
SAS 15K дают около 400 иопсов со шпинделя, для 100К IOPS нужно 250 дисков.
vanxant
Речь про замену ваших HDD со 140 иопсами.
ETegro_Technologies Автор
По производительности нужно 45 штук, по ёмкости (считаю 1.2TB) 70.
По цене обойдутся плюс-минус одинаково, но на 2 полках не работает enclosure awareness (нужно минимум 3).
Альтернатива жизнеспособная, кому что понравится.
ETegro_Technologies Автор
Тут специфичный пример, весьма небольшая ёмкость HDD уровня.
reff
Пруф дадите?
В расчётах принимал значения равные (RPM/iops: 15000/170, 10000/120, 7200/70), а тут — бац! — оказывается диск выдаёт 400 иопсов.
ETegro_Technologies Автор
Конечно дадим, с тех пор 7.2К диски немного подросли.
Вы какой размер блока брали?
reff
Спасибо. Исправьте ошибку в тексте статьи.
Правильно будет «оценки влияния».ETegro_Technologies Автор
Хех, столько лет никто не замечал опечатки. Поправили.