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 диска.

Демонстрация изврата: