about NetApp

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

??спользование Storage Pools это довольно частая тема для дискуссии с моими коллегами и пользователями. Многая информация о устройстве и механизмах работы не слишком распространена или известна, поэтому я решил провести мое собственное исследование на этот счет, и поделиться его результатами.

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Сперва давайте посмотрим вкратце на разницу, между архитектурным подходом с традиционными RAID-группами и Storage Pools.

На первом рисунке - архитектура традиционной RAID-группы. Вы назначаете диск RAID-группе, затем нарезаете ее пространство на LUN-ы, и назначаете хостам. Вы, на массиве в целом, используете множество RAID-групп, основываясь на ваших требованиях по уровню защиты данных, емкости, производительности, и так далее. На картинке ниже приведен подход с использованием пулов. На приведенном примере использованы так называемые "гомогенные пулы", из дисков одинакового типа. Вы просто назначаете диски в пул, и берете LUN-ы из пула. Когда вам нужно больше пространства, вы можете расширить пул, добавив в него дисков. Процессы администрирования и сложность устройства и организации системы хранения значительно сокращаются. Но чем вы платите за это, и о каких особенностях при проектировании, создании и использовании вы должны помнить?

Давайте подробнее посмотрим на то, как устроен внутри storage pool…

Картинка выше показывает, что скрывается "под капотом" у механизма storage pool. В приведенном примере создан storage pool типа RAID-5 из 5 дисков. FLARE создает из 5 специальную "внутреннюю" Private RAID-5 4+1 группу. Далее на этой группе создается 10 специальных Private LUN равного размера. В моем эксперименте я использовал диски, размером 143GB (133GB usable), и массив создал 10 Private LUN-ов, каждый размером 53.5GB, что дало мне размер пула ~530GB. Это столько, сколько вы могли бы ожидать от RAID5 4+1 RAID group (133*4 = 532GB).

Когда вы создаете LUN в таком пуле, и назначаете его хосту, ввод-вывод происходит несколько иным, чем обычно, способом во FLARE LUN. В традиционном (оставим в стороне Meta-LUNs чтобы упростить изложение) FLARE LUN, операции ввода-вывода поступают на один LUN на дисковой системе хранения, которые затем пишутся на набор дисков, составляющий RAID-группу.

Однако, когда хост записывает на Pool LUN, пространство на RAID-группе распределяется фрагментами (slice) по 1GB. Для Thick LUNs, это пространство последовательно и полностью заранее зарезервировано. Поэтому если некто создает 10GB Thick Pool LUN, его фрагменты по 1GB распределяются равномерно по 10 внутренним Private LUNs, то есть общим счетом 10x 1GB фрагментов. Когда хост пишет на Pool LUN, то LBA (Local Block Address) сообщает хосту непосредственное 1:1 соотношение с Pool LUN; то есть, LBA сопоставляет фрагменту 0-1GB для хоста фрагмент внутреннего LUN0, который содержит этот первый кусок, размером 1GB; LBA 1-2GB пишется на внутренний Private LUN1, LBA 2-3GB пишет на внутренний Private LUN3…. ?? так далее, как показано ниже:

Все эти LUN-ы нагружают одну и ту же Private RAID group, поверх которой они созданы, следовательно - одни и те же диски. Я полагаю, что EMC создает эти внутренние LUN-ы для равномерного распределения очереди ввода-вывода по устройствам.

Засада #1: Очень важный аспект - это понять смысл рекомендации EMC создавать пул, использующий диски в RAID-5, количеством дисков кратным пяти (5, 10, 15, 20, 25, 30, и так далее). Повторяю, это ОЧЕНЬ важный момент, не следование ему и не полное понимание его, может привести к неожиданным результатам Алгоритм создания пулов в FLARE пытается создавать Private RAID-5 groups в конфигурации 4+1, когда это возможно. Как пример, если вы проигнорировали рекомендации про "кратность пяти" при добавлении, например создали пул из 14 дисков, вы можете не получить ту емкость, на которую вы рассчитывали. FLARE создаст 2x 4+1 R5 Private RGs, и на оставшихся дисках - 1x 3+1 Private RG, НЕ одну 13+1 Private RG, как вы, возможно, думали. В результате вы получите заметно меньше места, чем рассчитывали.

В моем случае, используя диски 143GB (133GB usable), в 14-дисковом пуле R5 я получу (4*133)+(4*133)+(3*133)=~1460GB. А не ожидаемые (13*133)=1730GB. Разница порядка 300GB; довольно заметно! Наилучшим вариантом будет взять еще диск, и создать пул из 15 дисков в R5 pool, получив 3x 4+1 RG. Важно это понимать, если вы не хотите разбираться с разозленным клиентом, у которого пропало неизвестно куда дисковое пространство при конфигурировании массива

Далее давайте посмотрим на некоторые моменты, относящиеся к дисковой производительности для данных в пуле, при его расширении.

В случае пула, состоящего из 5 дисков, все довольно просто для понимания, потому что пул располагается на всего одной внутренней RAID-группе 4+1, которая и обслуживает ввод-вывод, но что получается в случае, если мы расширим пул? Помните, что вы должны расширять этот пул дисками, в количестве кратном пяти, давайте добавим еще 5 дисков, что даст нам общую емкость 530*2 = ~1060GB. "Под капотом" этот пул теперь выглядит так:

После добавления второго набора из 5 дисков, FLARE создает еще одну внутреннюю RAID-группу 4+1, и еще 10 внутренних LUN-ов на этой RAID-группе. На момент создания этих внутренних LUN-ов, они пусты и не содержат никаких данных.

Засада #2: Отметьте, что если Storage Pool расширен, существующие данные не "ре-страйпятся" по новым дискам. Чтения с исходного Pool LUN по-прежнему будут идти с первых 5 дисков, это также останется так при перезаписывании в LUN данных, уже записанных на момент расширения пула. Таким образом не ожидайте значительного увеличения производительности для уже созданных LUN-ов, расширяя пул дополнительными дисками.

В моих экспериментах я назначил такой Pool LUN в VMware поместил на него одну VM, а потом расширил пул, и поместил на него другую VM. Перед размещением второй VM на LUN, данные располагались так, как показано на картинке выше. Данные распределились по группе Private LUN, созданных на первой Private RAID group, на группе Private LUN второй RAID-группы. Когда я клонирую другую VM на LUN, это выглядит так:

Данные VM1 по прежнему распределены по первой внутреннней RG и первым 10 внутренним LUN-ам, как и предполагалось, но данные VM2 распределены по обоим внутренним RAID-групам, по всем 20 внутренним LUN-ам! Подумайте также вот еще о чем: 2 VM, на ОДНОЙ VMFS, в ОДНОМ Storage Pool, одна распределяет ввод-вывод по 5 дискам, а другая - по 10 дискам! Вторая VM будет иметь отличную производительность, так как распределяет свои данные по 10 дискам, но первая VM при этом по прежнему работает только с 5 дисками. Обе эти VM размером 100GB (как я сделал при своем эксперименте), так что на картинке не показаны все фрагменты-слайсы, но в целом картина именно такая. Действительное размещение должно было изобразить 100 фрагментов (1 фрагмент (slice) = 1GB как было указано ранее) распределенных по Private LUNs 0-9 для VM1, и 50 фрагментов по Private LUNs 0-9 и 50 фрагментов по Private LUNs 10-19 для VM2. Если я по прежнему буду держать эти VM на Pool LUN, они будут продолжать использовать равномерный страйпинг по 10 дискам, ДО ТЕХ ПОР, ПОКА не будет заполнена данными первая Private RAID group, после этого любые операции записи обоих VM будут снова использовать только страйпинг на 5 дисков второй Private RAID grop.

Такой дисбаланс возникает оттого, что у вас, на момент расширения, по прежнему есть место на первой RAID группе, алгоритм распределения слайсов по внутренним LUN использует простой алгоритм round robin. Если место на пуле заполнено, перед тем, как пул был расширен, то происходить будет что-то подобное следующему (не проверялось, экстраполировано из ранее проанализированного поведения):

На этом рисунке синие сегменты соответствуют "прочим" данным, заполняющим пул. Если пул близок к заполнению, и после этого расширяется, а затем вторая VM помещается на него, то вторая VM не может быть рассредоточена на пространство первой Private RAID Group (так как она уже полна) поэтому фрагменты-слайсы будут помещены ТОЛЬКО на вторую Private RAID group, и распределены только по 5 дискам, вместо 10, как в варианте ранее. Теперь представим себе ситуацию, когда VM создана до того, как первая внутренняя RAID Group заполнилась. Часть из операций ввода-вывода этих VM будет распределена по всем 10 дискам, а остальные по оставшимся 5 дискам, когда первая Private RAID group заполнится доверху.

Засада #3: Как показано выше, если вы расширяете storage pool когда он окончательно заполнен, или непосредственно перед этим, вы можете получить непредсказуемую производительность, зависящую от того, как расширяется пул, распределение по физическим дискам ввода-вывода для данных, расположенных в пуле, и их страйпинг, будет зависеть от того, как, когда и в каком порядке эти данные были записаны на пул. Все становится еще более сложным, если вы проигнорируете рекомендацию добавлять в пул диски в количестве, кратном пяти. Если вы имеете только 4 диска, и хотите расширить пул ими, то вы получите комбинацию 2x 4+1 RG, и 1x 3+1 RG. При этом, некоторые из операций ввода-вывода будут распределены по всего 3 дискам, вместо 5 или 10.

Таким образом, наилучшим решением использовать storage pools является завести в него сразу, в момент создания все диски, которые вы планируете использовать под pool. То есть, допустим, если у вас есть полная полка дисков в Clariion или VNX, используйте под pool все 15 дисков из нее. Это даст вам 3x 4+1 RAID-группы, а данные, которые вы на нее будете записывать, будут равномерно распределены между всеми 15 дисками. Хорошей мыслью будет не создавать пулы из небольшого количества дисков, собираясь потом часто расширять их добавлением новых дисков, так как вы столкнетесь с уже описанными выше проблемами.

Существует еще одна проблема с расширением пулов. Допустим, мы создали пул из 15 дисков, и начали размещать в него данные. Все ваши операции ввода-вывода равномерно распределены на все 15 дисков. Но вот вам понадобилось место, и вы решили расширить пул. Следуя правилу добавлять диски в количестве кратном пяти, казалось бы, никаких сложностей не возникнет. Однако, хотя вы можете их добавить, вы рискуете получить неожиданный результат.

Перед расширением, ваш 15-дисковый R5 pool выглядит так:

Все данные распределены по 15 дискам, но пул практически полон; если пул в такой ситуации будет расширен, то вот как будут размещаться на нем любые новые VM (в общем случае - любые данные):

Когда пул расширен, новые данные будут распределены всего по 5 дискам, вместо исходных 15! Так что если вы помещаете новую VM а систему хранения, ожидая что она будет страйпиться на множество дисков, и иметь высокую производительность по вводу-выводу, вы будете сильно огорчены тем, что, на самом деле, данные, записанные после расширения, окажутся распределены всего по 5 добавленным дискам, и только.

Засада #4: С этой точки зрения понятна рекомендация расширять пулы таким количеством дисков, из скольки они были изначально созданы. То есть, если у вас используется 15-дисковый пул, то следует расширять его еще 15 дисками, чтобы новые записываемые на пул данные, могли воспользоваться всеми преимуществами распределения ввода-вывода по множеству дисков (читай: чтобы добавляемый после такого расширения пула LUN имел производительность не хуже, чем уже созданные на нем). Я слышал про такие рекомендации при расширении удваивать количество дисков, но они мне представляются все же чрезмерными. В качестве примера: если у вас имеется 15-дисковый пул, и вы добавляете в него 15 дисков, вы, теоретически, получите некоторые операции ввода-вывода распараллеленные на 30 дисков; а в следующий раз вам понадобится для расширения по такой модели 30 дисков? А в следующий - 60? Всегда понимайте и здраво оценивайте влияние выбранной модели использования и требования по производительности, прежде чем выберете тот или иной вариант..

Надеюсь, что EMC объявит в будущем возможность ребаланса для пулов, такую, например, как в последних версиях микрокода для VMAX, что решит большинство этих проблем. Но пока, вам следует иметь ввиду и побеспокоиться об этих проблемах заранее, на этапе дизайна и развертывания базовой конфигурации, использующей возможности Storage Pool.

Еще один момент, которым стоит озаботиться, это необходимость следить за изменением default SP owner для Pool LUN. Так как LUN организован поверх внутренних Private LUN-ов, могут возникнуть проблемы с производительностью, так как используется драйвер перенаправления для доступа к LUN-ам с другого SP; убедитесь, что правильно сбалансировали pool LUN-ы между SP, в момент их создания.

??спользование Thin LUNs требует принятие во внимание дополнительного, особого уровня оценки, так как они не используют предраспределение емкости сегментами, размером 1GB, вместо этого они пишут экстенты, размером 8K. Это может вызвать даже более значительную непредсказуемость, чем описана в случаях выше. При использовании Thin Provisioning на хосте добавляется еще один уровень сложности, как-нибудь позже я напишу пост о особенностях работы пулов при использовании thin provisioning. Кроме того, как вы видите, я не касался ряда тем, относящихся к работе пулов на RAID10, возможно я продолжу эту тему позднее

В общем случае, если требуется предсказуемый уровень производительности, по прежнему лучше предпочесть традиционные RAID-группы (но не забывайте, что множество новых фич EMC будут тогда вам недоступны, они работают только на пулах, прим romx.). У пользователей могут быть задачи с рабочей нагрузкой, требующие использования выделенных дисков и классических RAID-групп, и я не вижу причин для того, чтобы как и раньше использовать для них традиционные RAID-группы (причины - все новые фичи, перечисленные выше, которые требуют для своей работы использования пулов, при romx.). Речь идет в данном случае о понимании требований и переводе их в правильный дизайн системы хранения; хорошая новость тут в том что EMC дает необходимую гибкость. Несомненно, использование пулов дисков это способ снять множество проблем у администраторов системы хранения, но архитектор системы всегда должен видеть и понимать все ограничения и возможности того или иного дизайна. Уровень FAST VP поверх storage pools это отличное решение для большинства пользователей, и важно отметить, что ЕД??НСТВЕННЫЙ способ получить автоматизированный storage tiering - это именно использовать Pool-based LUNs.