about NetApp

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

В случае если мы говорим об “эффективности хранения”, то это соотношение между количеством купленных байт (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 (черного)

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

СУБД на двухузловом кластере 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-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-DP w/thinpro” объем занятого в usable space места меньше, чем allocated, а allocated space выше, чем raw. Это связано с работой thin provisioning, когда место занимает только действительно записанные даные, несмотря на то, что объем представленного OS раздела жесткого диска, во избежание “системной паники”, может быть больше, чем реально занимаемое этими данными на диске место.

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

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