четверг, 16 января 2014 г.

Storage Spaces - вопросы масштабирования

При реализации высоко доступной СХД на базе Windows server 2012 (Clustered Storage Spaces), у одного из наших клиентов возникла проблема масштабирования.
Те вопросы, которые возникли, хотя и не столь уникальны, но если ими не задаться на этапе создания дискового пула и виртуальных дисков, то в последствии, при увеличении емкости пула и в частности виртуальных дисков, возможно столкнуться с определенными трудностями.


Итак:
1. Кластеризованый Storage Spaces не поддерживает тонкие диски.
2. При создании виртуального диска, важным свойством является NumberOfColumns.

С первым пунктом все ясно - забыть о петабайтных виртуальных дисках на пуле, из пары физических дисков, размером на пару сот гигов ;)
Хотя здесь плюсы тонких дисков скорее не столько в неограниченном виртуальном дисковом пространстве, сколько в возможности создать на одном пуле, виртуальные диски разных типов (разный уровень избыточности, производительности и т.п.) Например сделать три вирт.диска, размером равным размеру пула (минус избыточность), но с разными свойствами (тот же NumberOfColumns или Interleave).... В общем - животное-конь/формы-сфера/расположение-вакуум)

Что же касается NumberOfColumns, то дело в следующем - Storage Spaces при создании виртуального диска, умет располагать блоки/страйпы (strip) этого диска не на одном физическом диске (как обычно в классических рэйд массивах), а на нескольких.

Рис.1

Когда виртуальный диск создается из графической консоли, то нет явного способа повлиять на то, как будут располагаться блоки на дисках (извратный способ из гуи в конце статьи). Из картинки выше, видно, что при желании увеличить размер виртуальных дисков, в пул придется добавлять физические диски не просто по одному, а исходя из свойства ранее созданного виртуального диска NumberOfColumns.
В приведенном примере, для увеличения vdisk-1, нужно добавить один физический диск в пул, для увеличения vdisk2- два диска , для vdisk3 - один.

Так же не стоит удивляться, когда у вас свободно одно кол-во пространства в пуле, а при расширении виртуального диска, не получается все это пространство использовать (в данном контексте избыточность естественно учитывается). Все дело в тех же страйпах (своего рода свойство аффинити работает:)).
Т.е. если к нашей схеме, на рисунке выше (будем считать, что все виртуальные диски имеют избыточность равную Raid-1), добавить еще один диск в пул, то........лучше нарисовать новый рисунок:)
Легенда:
Vdisk-1 Vdisk-1 Mir - Виртуальный диск с NumberOfColumns = 3 (Stripe — данные; Stripe mirror — копия данных)
Vdisk-2 Vdisk-2 Mir - Виртуальный диск с NumberOfColumns = 2 (Stripe — данные; Stripe mirror — копия данных)
Vdisk-3 Vdisk-3 Mir - Виртуальный диск с NumberOfColumns = 1 (Stripe — данные; Stripe mirror — копия данных)

HDD 1
HDD 2
HDD 3
HDD 4
HDD 5
HDD 6
HDD 7
HDD 8
HDD 9
HDD 10
HDD 11
Stripe 1
S1
S1 Mir
Stripe 2
S1 Mir
Н
S2
S1
Stripe 1 mirror
S2 Mir
S3
S2 mirr
О
s2 mirr
S3
S3 mirr
S1 mirr
S3 mirr
В
S3 mirr
S4
S4 mirr
S5
Ы
S5 mirr
S4
S4 Mir
S5
S2
Й
S5 Mir
S6
S6 Mir
S7
S7 Mir

S2 mirr
S3
S3 mirr
S4
S4 mirr
S5
S5 mirr
S6
S6 mirr
S7
Д
S7 mirr
S8
S8 Mir
S8
S6
S8 mirr
И
S9
S9 mirr
S9
S6 mirr
S9
S9 Mir


С




















К
БЛОКИ ДИСКОВ ПОД СТРАЙПЫ УСЛОВНЫ

Логика такая - страйп с данными не должен пересекаться со страйпом, где копия этих данных (RAID-1). 
Т.е. если добавить 1 диск в пул (HDD 11), то vdisk1 расширить можно на два блока данных+копия (HDD1/2/10 и 3/4/5 данные и HDD 6/7/8 и 9/10/11 копии соответственно) , vdisk 2 расширить возможно на три блока данные+копия, а vdisk3 аж на шесть блоков. И всё! Какой из vdisk-ов не расширяй, максимум можно будет использовать всего ДВА условных блока, от нового HDD11 в пуле. Если добавить еще диск (HDD12), то под vdisk3 возможно будет уже использовать практически всю емкость дисков HDD11 и HDD12. Для vdisk1 и vdisk2 добавление HDD12 практически бесполезно (почему так, надеюсь стало ясно) - для зеркала, что бы утилизировать все вновь добавляемое пространство при расширении виртуального диска, необходимо добавлять в пул диски по такой формуле 'NumberOfColumns*2'.
При создании нового vdisk'а, ограничение (если диск с избыточностью) будут те же.
Собственно иногда поэтому, при добавлении нового диска в пул, мы видим что доступная ёмкость пула равна размеру вновь добавленного диска, а вот использовать всю эту емкость для расширения имеющихся виртуальных дисков или создания новых, мы не можем.

Резюме вроде бы напрашивается само собой - создавать виртуальные диски из PowerShell при помощи New-VirtualDisk, с использованием в качестве одного из аргументов 'NumberOfColumns 1'
..., но тогда мы лишаемся одного из плюсов Storage Spaces - производительность!

PS: Все вышеизложенное, субъективное понимание работы Storage Spaces, основанное больше на логике, на понимании принципа affinity и паре экспериментов. Как реально распределяются блоки на диски в пуле я не в курсе (да и не искал). Как влияет на производительность размер блока и количество частей на которые этот блок бъётся (Interleave + NumberOfColumns) мне так же не известно (возможно потестится как нибудь).

Важно (наверное:)): В Windows Server 2012 R2, при создании виртуальных дисков в Clustered Storage Space, можно использовать в качестве избыточности - четность. При четности, схема аффинити не так сильно ограничивает масштабирование и при создании/увеличении виртуального диска, утилизировать возможно гораздо больше свободного места.

Изврат или как повлиять на NumberOfColumns, при создании виртуальных дисков из консоли 'Диспетчер серверов / Server Manager':
Создаем пул, исходя из того, что по умолчанию Storage Spaces будет размазывать блок на максимально возможное кол-во дисков. Т.е. что бы получить схему vdisk-3 (Рис.1)  (избыточность = Raid-1), надо создать пул из 2-х дисков. Что бы получить vdisk-2, в пуле должно быть 4 диска.

Комментариев нет:

Отправить комментарий