“Эффективность”: что это значит для системы хранения?

“Эффективность” это, в общем случае, соотношение между “вложенным” и “полученным”.

В случае если мы говорим об “эффективности хранения”, то это соотношение между количеством купленных байт (raw) и тем объемом, который в результате можно записать вашими данными (usable).

Аспект эффективности к сожалению все еще несколько недооценивается, когда перед клиентом стоит задача выбора системы хранения.
Приведу простой пример.

В некоем проекте встречаются два вендора, назовем их Вендор А и Вендор Б.
Оба вендора предлагают нам систему сходных свойств, идентичной емкости. Будучи ушлым клиентом, мы сразу интересуемся тем, сколько стоит терабайт у каждого из этих вендоров, надеясь из этого параметра выбрать самую лучшую по цене систему.

Мы узнаем, что диски вендора А стоят по 1000$ за TB. А диски вендора Б стоят 1500$ за тот же TB. На 50% дороже! Казалось бы вопрос решен, решение от Вендора А обойдется нам на 50% дешевле. Часто на этом выбор и останавливается. Но не спешите.

Углубляясь в тенические характеристики мы узнаем, что система Вендора А на нашей задаче имеет эффективность хранения 30%, то есть из купленного десятитерабайтного стораджа нам достанется всего 3ТB, а система Вендора Б – 70% = 7TB.

Теперь если мы посчитаем, почем обойдутся нам терабайты не просто raw, а именно usable пространства, то есть эффективной емкости, то ситуация заметно изменится.

Получающийся usable space у Вендора А будет стоить 3333$, а вот usable space у Вендора Б - 2142$.

Итак, мы видим, что параметр эффективности может очень сильно влиять на цену итогового решения, и, несмотря на то, что его относительно редко указывают в характеристиках системы, его влияние на цену решения может быть весьма значительным.

Увы, вычисление эффективности есть процесс достаточно нелинейный, требующий знаний “внутренней механики”, а также особенностей реализации хранения в проекте, поэтому ее измерение достаточно непросто, и требует знаний, и понимания специфика решения, а не просто “сравнения чисел крайних значений на спидометрах у двух моделей автомобилей”.

Чтобы не быть голословным теоретиком, давайте рассмотрим какой-нибудь практический пример, и оценим, как влияет показатель эфективности.

Возьмем некоторую практическую задачу построения enterprise-class системы ERP, использующей Oracle RAC, работающий с ним слой приложений и middleware (Oracle Fusion Middleware suite и Oracle Weblogic), отдел тестирования и разработки приложений. Кроме того, не забудем про резервное копирование и DR. Для правильного распределения данных по быстродействию и приоритетам, в используемой системе хранения применяются диски FC (полки голубого цвета) и SATA (черного)

 image

Рассмотрим подробнее:

image

СУБД на двухузловом кластере RAC с ASM на Oracle Enterprise Linux, хранит свои данные в LUN-ах, подключенных по FC (линии красного цвета) через дублированную по путям FC-фабрику.

Для правильного распределения и использования ресурсов, большая часть оставшейся инфраструктуры, такой как middleware и приложения, а также сервер управления и отдел dev/test преимущественно расположены в среде виртуализации VMware ESX. Часть критичных приложений же, как мы видим на рисунке, оставлены в физических серверах OEL.

Все перечисленные сервера работают со своими данными через сеть Gigabit Ethernet. Сеть передачи данных хранения, в которой движется трафик iSCSI или NFS, отделен в отдельную физическую сеть (на рисунке “Gigabit Storage Network”) от локального интранета приложений и клиентов.

Давайте сперва грубо прикинем емкость. Допустим, для хранения баз данных RAC нам нужно не менее 8TB usable space. Давайте прикинем, какой уровень RAID сколько raw disks потребует (например, возьмем FC-диски 300GB 15KRPM).

  RAID-10 RAID-6 RAID-50 RAID-DP
Raw 16TB 9TB 9TB 9TB
Usable 8TB 8TB 8TB 8TB
effectiveness 50% 88% 88% 88%
max # of disk loss 1 2 1 2
performance high low medium high

 

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

Так, например, если задаче требуется терабайт места на диске, никто никогда из сисадминов не “нарежет” ей LUN размером ровно терабайт. Необходим объем на возможный прирост данных, чтобы не оказаться в какой-то момент с вставшей системой оттого, что логи внезапно заполнили все свободное место на рабочем диске. По этой причине LUN для записи N гигабайт данных займет на usable space дисковой системы емкость N+XX%, где XX, в зависимости от решения систадмина, может быть от 10-20 до 100%, так как увеличение LUN-а на традиционных системах обычно сопряжено с кучей сложно решаемых, а иногда и совсем не решаемых проблем, и многие админы предпочитают создать LUN заранее, “раз и навсегда”, и в дальнейшем не возиться с потенциально трудоемкими и небезопасными процедурами увеличения. А так как это распределенное, но незанятое данными место естественным образом вычитается из пространства доступного для записи на диски, то снижается и эффективность.

Эффективность хранения, напомним, это соотношение места, которое мы можем использовать, заполнив своими данными, к общему купленному объему raw data на жестких дисках.

Решением данной проблемы является так называемый принцип “thin provisioning”, или “экономного распределения места”. При таком подходе LUN с данными на дисках занимает ровно то место, сколько занимают записанные  него данные, а при необходимости динамически расширяется за счет свободного пока никем не занятого на дисках пространства, но не занимает на нем “выделенного, но неипользуемого” места заранее, не отбирает его у других задач, и не снижает эффективности. Метод thin provisioning довольно активно внедряется производителями систем хранения в своих продуктах, некоторые, такие как 3PAR, в принципе построены вокруг этой парадигмы. Одним из первых, наряду с 3PAR, thin provisioning внедрили и NetApp, тем более, что принципы работы WAFL, структуры размещения данных, используемый в системах хранения NetApp, позволяет легко этот принцип реализовать.

Итак, давайте примерим, что же получится при размещении данных.

В рассматриваемой схеме thin provisioning рекомендуется для данных серверов приложений и middleware. Предположим, что у нас есть 20 виртуальных машин VMware, несущих разнообразные приложения Oracle на Linux и Windows. Каждой виртуальной машине выделен файл виртуального диска, размером 80GB. Но в действительности на этом диске занято 60GB, остальное выделено как резерв на случай увеличения занимаемого объема (это может быть, например, необходимость установить на OS этой виртуальной машины обновления и патчи, рост объема хранимых данных, и так далее). Таким образом на диске каждой машины мы имеем примерно 25% запас неиспользуемого места.

Суммарный объем данных всех 20 виртуальных машин равен 60х20=1200GB, а объем занятого на дисках системы хранения этими виртуальными машинами равен 80×20=1600GB.

Допустим, что сисадмин системы хранения выделил на размещение виртуальных машин application and middleware, объемом 1600GB раздел равный 2TB.
Давайте сравним эффективность решения от NetApp, с использованием RAID-DP и thin provisioning, и “классического” размещения.

  RAID-10 RAID-5,6,50 RAID-DP w/thinpro
raw space, GB 4000 2250 1350
usable space, GB 2000 2000 1200
allocated space, GB 1600 1600 1600
stored data, GB 1200 1200 1200
effectiveness 30% 53,3% 89%

Обратите внимание, что в случае “RAID-DP w/thinpro” объем занятого в usable space места меньше, чем allocated, а allocated space выше, чем raw. Это связано с работой thin provisioning, когда место занимает только действительно записанные даные, несмотря на то, что объем представленного OS раздела жесткого диска, во избежание “системной паники”, может быть больше, чем реально занимаемое этими данными на диске место.

Таким образом, вы видите, что с использованием новых технологий повышения “эффективности хранения” нам удалось решить ту же задачу, на которую нам бы пришлось потратить 4TB raw-дисков при использовании RAID-10,  всего на 1350GB raw disks, при использовании RAID-DP и thin provisioning.

Вот что такое высокая эффективность хранения.

5 комментариев

  1. Георгий:

    Цитата: “Допустим, что сисадмин системы хранения выделил на размещение виртуальных машин application and middleware, объемом 1600GB раздел равный 2TB. Давайте сравним эффективность решения от NetApp, с использованием RAID-DP и thin provisioning, и “классического” размещения.”
    Вот на мой не сильно просвещенный взгляд… В случае выделения LUN-ов под виртуальные машины разве будет работать “thin provisioning” без “space reclamation”? Взять тот-же документ по “thin provisioning” - “TR-3483″. В нем явно говорится, что при создании - удалении файлов объем занятых блоков под LUN будет только расти… Ну и собственно “space reclamation” вроде не под все есть… Разве не так?

  2. Георгий:

    Да, конечно, со временем thin-LUN действительно вырастет. Но _со_временем_, а до того момента он будет занимать меньше места. А thick-LUN сразу займет все зарезервированное место, хотя и не будет использвать его для хранения данных.
    Кроме того есть весьма ясное впечатление, что индустрия договорилась о методах space reclamation в рамках стандартного протокола SCSI (и тот же TRIM в SATA, например), и вскоре удастся реализовывать space reclamaton неким стандартным, единым образом для всех OS.

  3. Георгий:

    Ага, ну я рад, что себе правильно представлял. Спасибо! :-)
    Да, по моему не очень богатому опыту, когда я отдавал LUN для datastore VMware то он вырас практически сразу после того, как с ним произвели какие-то манипуляции админ ESX. Так что в этом случае “со временем” свелось к тому-же “сразу”. :-)
    Впрочем будем надеяться, что space reclamation появится везде!

  4. Георгий:

    Он мог наполнить его eager-zeroed thick дисками VMDK, которые при создании принудительно “заливаются нулями”. Также губительно для thin provisioned LUN себя ведет “дефрагментация” на уровне OS хоста.
    Рекомендую на этот счет посмотреть Best Practices TR-3428 и TR-3749.

  5. Георгий:

    Да, похоже на то. Документы обязательно посмотрю. Они у меня есть, но руки не доходят. :-) Спасибо!

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

20/0.143

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.