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.

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

Администратору системы хранения иногда приходится перебрасывать данные с тома на том. Чуть ранее я уже рассказал про один из способов решения, инструменте ndmpcopy, позволяющий произвести копирование данных тома силами самой системы хранения, по протоколу NDMP.

Однако существует и другой способ копирования содержимого тома, это команда vol copy. Оба эти способа бесплатно присутствуют во всех системах хранения NetApp, но имеют отличия, давайте рассмотрим разницу.

ndmpcopy это копирование по сетевому протоколу NDMP. Даже когда это происходит в пределах одной системы, все равно это копирование происходит по сетевому сокету, и, как правило, этот процесс медленнее, чем копирование vol copy, который осуществляется непосредственно, а не по сети.

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

Ограничения при использовании vol copy таковы:

• Том-источник данных и том-получатель данных должны быть одного типа. Или оба flexible, или оба traditional
• Том-получатель должен быть равен или больше по объему, чем том-источник
• Обе системы хранения, участвующие в копировании, должны быть в доверительных отношениях (trust relationship), на обоих должен быть включен доступ по rsh (Remote Shell)
• Том-получатель на момент начала копирования должен существовать
• Нельзя скопировать root volume
• Том-получатель будет полностью затерт содержимым тома-источника
• Состояние тома-источника на момент запуска процесса должно быть online, а тома-получателя – offline.

Это опция, которая инициирует Cluster Failover системы не только в случае аппаратного отказа контроллера в целом, но и просто в случае потери сетевого соединения котроллером. В случае, когда высокая доступность данных есть определяющее требование, можно попытаться таким образом защититься от, например, отказа сетевого коммутатора, или отдельного порта.

Однако примите во внимание, что включение Negotiation Failover может вызывать ненужные “ложные” срабатывания “на каждый чих”, со всей последующей суетой в виде кластерного файловера, и прочим, так что применяйте ее с осторожностью, и с полным пониманием того, что вы хотите достичь.

По умолчанию Data ONTAP считает возможные проблемы коннективити проблемой на стороне  коммутатора, решаемые его силами, и не пытается на своей стороне преодолевать их. В жизни проблемы связи, кроме проблем на стороне коммутатора, могут быть порождены, к примеру, отключенным или оборванным кабелем. Система хранения, к которой, и к данным которой нет доступа по сети – все равно что отключенная. Поэтому начиная с Data ONTAP 7.2 появилась опция запуска кластерного файловера по причине потери сетевого соединения.

Примеры:

Сначала разрешим negotiated failover (nfo) на интерфйсах в файле /etc/rc file:

ifconfig e0a ‘hostname’-e0a netmask 255.255.255.0 nfo partner 10.10.1.102

Далее установим опции ONTAP:

fas> options cf.takeover.on_network_interface_failure on
fas> options cf.takeover.on_network_interface_failure.policy [ any_nic | all_nics ]

Если на вашей кластерной системе невелико количество сетевых портов, или вы не имеете избыточности в вашей сетевой инфраструктуре, то использование Negotiation Failover (NFO) может повысить отказоустойчивость вашей системы.

ВНИМАНИЕ: Если обе кластерные ноды включены в один сетевой коммутатор, и коммутатор отключен, то система хранения может войти в так называемый  failover loop при котором каждая из систем попытается сделать failover на своего партнера. Внимательно оцените вашу структуру сети, чтобы не допустить такого развития событий.

Подробнее смотрите в документации на соответствующие команды ONTAP:

ifconfig:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/cmdref/man1/na_ifconfig.1.htm

options:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/html/ontap/cmdref/man1/na_options.1.htm

В недрах OS Data ONTAP скрывается много удивительных гитик.
Вот, например, в каждой системе хранения NetApp, вернее в ее OS, имеется встроенный сниффер, запускаемый командой pktt, и собирающий дамп с интерфейса для последующей разборки, в формате стандартного юниксного tcpdump.

Использование:
pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …
pktt pause {if | all}
pktt dump {if | all} [-d dir]
pktt stop {if | all}
pktt status [{if | all}] [-v]
pktt delete [filename.trc]+
pktt list

Команда pktt управляет простым встроенным средством сбора ethernet-трафика. Пакеты захватываются с указаного интерфейса в специальный trace buffer, и после этого записываются в файл на диске. Данные записываются в формате “tcpdump”, который может быть прочитан разнообразными средствами, такими как tcpdump, ethereal (wireshark), и прочими программами-анализаторами и просмотрщиками. Вывод можно также конвертировать (утилитой editcap) в различные другие употребимые форматы, например для Sniffer, NetMon, и snoop.

pktt может захватывать пакеты для всех поддерживаемых типов медиа.

pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …

Команда start запускает трассировку, (или рестартует ее, если pktt находился в положении paused). Данные собираются в память, и пишутся в кольцеой буфер в памяти в формате “tcpdump”. Опции могут быть следующие:

-b размербуфера
Устанавливает размер буфера, который может быть определен в килобайтах или мегабайтах, при задании ‘k’ или ‘m’ после числа. Если не определен, то будет равен 128K, если вы не задали также опцию -d, что немного, но может быть достаточно в ряде случаев. Если задана опция -d, то значение буфера по умолчанию равно 1M. Значение может быть от 8K до 32M, то в очень редких случаях стоит устанавливать его большим 1-2M. Максимальный объем пространства, доступного pktt в памяти, равен 64M.

-d директория
Определяет путь к существующей директории, куда будет записан файл дампа. Файл будет иметь имя “if.trc” где”if” это имя интерфейса (например e0, fa3, и так далее.). Если опция не указана, то данные будут собиратся только в памяти, и после его заполнения, данные будут перезаписываться по кругу. Однак в любой момент можно сбросить содержимое буфера на диск с помощью команды pktt dump. Обратите внимание, что если система не будет успевать записывать все пакеты, то будет расти показатель счетчика “dropped” в выводе статуса pktt. Помните, что запись дампа всего трафика на диск может вызвать значительную нагрузку на запись для системы, и замедлить ее работу, поэтому, если это возможно, всегда ограничивайте область трассировки определенными IP-адресами и интерфейсами. Кроме этого, если вам не нужно сохранять содержимое всего пакета, то вы можете обрезать его командой -m.

Имейте ввиду, что любой существующий файл .trc будет молча перезаписан при выполнении этой команды.

-s размер
Эта опция позволяет вам задать максимальный размер файла дампа. Величина может быть задана с указанием “k”, “m”, или “g”. По умолчанию - 1G. Этот параметр всегда используется вместе с опцией -d. После достижения максимального лимита по размеру, пакеты продолжают собираться в буфер, но уже не пишутся на диск.

-m длинапакета
Этот параметр задает длину обрабатываемых пакетов (обрезая все что выходит за заданные пределы). По умолчанию - 1514 байт, что подходит для обычного ethernet, но может быть недостаточно для gigabit ethernet с использованием jumbo frames. Иногда может быть использован для ситуаций, когда не обязательно сохранять полное содержимое пакета. Однако, во многих случаях полезно сохранять полное содержимое всего пакета. В этом случае, если пакеты имеют размер свыше 1514 байт, вы можете задать желаемый максимум. Имейте виду, что некоторые декодеры (как пример - snoop) не обрабатывают пакеты более 1514 байт. Декодер ethereal/wireshark не имеет такой проблемы.

-i ipaddr [-i ipaddr] …
Эта опция включает простую возможность фильтрации. Можно задать до чтырех IP-адресов, для которых (на которые и с которых) будет записываться трафик. Это, кроме всего прочего, ограничит записываемый трафик только IP-пакетами, то есть в него не попадут пакеты, например arp/rarp, и прочие подобные.

pktt pause {if | all}
Команда “pause” приостанавливает сбор трафика с указаных интерфейсов. Незаписанные данные в буфере сбрасываются на диск. С помощью команды pktt start без других опций, можно возобновить сбор данных.

pktt dump {if | all} [-d dir]
Команда dump вызывает сброс содержимого кольцевого буфера в памяти в файл на диске. Если задана опция -d dir, то файл будет создан в указанной директории, в противном случае - в корневой директории root volume. Имя файла всегда равно if.trc (где if это название интерфейса), и содержимое записывается в формате “tcpdump”. Если файл уже существует, то он будет молча перезаписан.

pktt stop {if | all}
Эта команда выполнит остановку сбора дампа для всех заданных (или вообще всех) интерфейсов. Если вы пишете на диск, то все незаписанные на этот момент данные в буфере будут сброшен на диск. Если вы не задали файл записи дампа, то все данные в буфере будут потеряны. Это действие не требует подтверждения, так что будьте аккуратны.

pktt status [{if | all}] [-v]
Эта команда покажет вым состояние буфера и файла дампа для действующей трассировки. Используя “pktt status -v” вы получите полный статус всех интерфейсов.

pktt delete [filename.trc]+
Эта команда позволит вам удалить один или неколько файлов дампа в корневой директории. Длжен быть указан хотя бы один файл.

pktt list
Показывает список всех файлов трассировки в корневой директории.

Примеры:
pktt start e0
Эта команда начинает захват трафика с интерфейса “e0″. Весь трафик пищется в кольцевой буфер, размером 128K. Или же, если предыдущая команда приостановила сбор дампа, то она его возобновит.

pktt start fa3 -d / -s 100m -b 2m
Эта команда начинает захватывать дамп трафика на интерфейсе “fa3″, и писать в файл под названием “/fa3.trc” которому будеи позволено расти до максимальног размера в 100MB, с использованием буфера в 2MB.

pktt start el10 -d /home -m 10k -b 500k -i ehost1 -i ehost2
Эта команда начинает захватывать пакеты на и с определенных хостов, в данном примере “ehost1″ и “ehost2″ записывая их в файл “/home/el10.trc”. Пакеты размером до 10K записываются в буфер, размером 500K buffer. Отметьте, это будет работать только в том случае, если имена заданных хостов будут успешно резолвиться в DNS.

pktt start all -b 128k -i 172.20.4.1
Все интерфейсы начинают записыват дамп трафика на и с определенного IP-адреса. Это простой и быстрый способ посмотреть трафик, сли вы не уверены в том, какой интерфейс используется, но хотите увидеть пакеты с одного или более адресов IP.

MAC Load-Balancing
Этот алгоритм используется не так часто, так как ему присущ ряд недостатков. Основанный на использовании MAC алгоритм балансировки вычисляет XOR между MAC-адресами пар источника и получателя. Источником будет MAC-адрес сетевой карты хосте, подключенного к контроллеру  NetApp. Получателем будет MAC-адрес VIF-интерфейса контроллера NetApp. Алгоритм работает хорошо, когда хосты и контроллер NetApp размещаются в одной подсети или VLAN. Когда хост расположен в другой подсети относительно контроллера NetApp, мы сталкиваемся с недостатками алгоритма. Для понимания того, что происходит, нам надо разобраться с тем, что происходит с фреймом Ethernet, когда он маршрутизируется по сети.

Допустим, мы хотим соединить Host1 с Controller1.

Host1 IP address - 10.10.1.10/24 (default gateway для Host1 - 10.10.1.1)
Controller1 IP address - 10.10.3.100/24 (default gateway для Controller1 - 10.10.3.1)

Выше мы задали для Host1 и Controller1 две отдельные подсети. Единственный путь передачи данных в том случае - через роутер. В рассматриваемом случае, роутер для подсетей 10.10.1.1 и 10.10.3.1 это один и тот же физический роутер, эти адреса просто два физических его интерфейса. Задача роутера - связать две подсети, и обеспечить передачу данных между ними.

Когда Host1 передает frame предназначенный для Controller1, он отправляет его на роутер по адресу default gateway, так как видит, что адрес 10.10.3.100 это IP-адрес не его локальной подсети, потому он отправляет его в адрес default gateway, по которому расположен роутер, в надежде, что роутер знает что с ним делать дальше, и найдет путь к получателю.

с Host1 на Host1Router

-IP Source: Host1 (10.10.1.10)
-MAC Source: Host1
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: Host1DefaultRouter

с Host1Router на Controller1

-IP Source: Host1 (10.10.1.10)
-MAC Source: Controller1DefaultRouter
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: VIFController1

Обратите внимание: MAC-адреса источника и получателя меняются, когда фрейм передается по сети. Так работает маршрутизация, и когда маршрутизаторы встречаются на пути несколько раз, то и MAC будет изменен несколько раз по пути от источника к получателю. Не важно сколько раз конкретно, главное что он меняется когда фрейм попадает в локальный сегмент контроллера. MAC источника будет являться MAC-ом роутера, а получателем – MAC-адрес VIF контроллера. Для полного понимания проблемы, допустим у нас есть четыре 1Gbps канала, объединенных в Etherchannel на Controller1. Допустим у нас есть 50 хостов в той же подсети, что и  Host1. Пары source и destination для соединения Host1 к Controller1 будут ровно теми же, что и любых других хостов в подсети host1, так как  MAC-адреса source и destination всегда будут равны Controller1DefaultRouter и VIFController1.

IP Load-Balancing
IP Load-Balancing это параметр по умолчанию для всех NetApp MultiMode VIF и наиболее часто используемый на практике метод построения MultiMode VIF на сегодня. Алгоритм не отличается от уже рассмотренного алгоритма с использованием MAC, который мы расмотрели выше. Разница только в том, что мы используем IP-адреса Источника (Source) и Получателя (Destination), которые, если вы посмотрите рассмотренный ранее вариант, никогда не менятся, в отличие от  адресов MAC. Факт того, что IP-адреса не меняются, создает сценарий, в котором у вас больше шансов получить уникальные пары, что, в результате, приводит к более равномерному распределению трафика по физическим линкам.

Для правильного понимания механизма работы следует учесть один важный момент, касающийся пар IP-адресов source и destination: при вычислении пар source-destination принимаются во внимание только последние октеты адресов. Это означает, что в адресе 10.10.1.10 будет использован для идентификации только 10 – последний октет адреса, в адресе 10.10.3.100 - только 100. Принимать во внимание этот момент следует в случае развертывания системы в сети, состоящей из нескольких подсетей, в этом случае может получиться так, что адреса из разных подсетей (но с одинаковым последним октетом) будут передаваться по одному физическому линку.

IP Aliasing
Понимание принципов алгоритмов Load-Balancing позволяет вам, как администратору, использовать их к собственной выгоде. Все NetApp VIF и физичские интерфейсы имеют возможность назначить им так называемые “алиасы”. Это просто дополнительный адрес для самого VIF. Рекомендуется назначит адреса(для VIF + определенное количество алиасов) равное числу физических линков в EtherChannel между контроллером и коммутатором, к которому подключен контроллер. Таким образом если вы используете VIF, состоящий из  4 штук 1Gbps линков в виде MultiMode VIF между контроллером и коммутатором, то назначьте один адрес для VIF и добавьте к нему три алиаса для того же VIF.

Простое назначение дополнительных адресов не поможет использовать преимущества дополнительных адресов. Вы должны убедиться, что хосты, которые смонтировали данные с контроллеров NetApp используют все эти адреса. Этого можно достичь несколькими разными путями, в зависимости от того, какие протоколы используются для доступа к данным, ниже приведены некоторые примеры для NFS.

Oracle NFS -  хосты с Oracle должны монтировать тома NFS равномерно распределяя их по доступным  IP-адресам контроллера. Если у вас есть 4 различных NFS ресурса, то смонтируйте их используя для доступа четыре различных IP-адреса контроллера. Каждый ресурс будет иметь различную пару из источника и получателя (source and destination pair) и полоса передачи между хостом и контроллером будет использована более эффективно.

VMware NFS – хосты ESX должны монтировать каждый NFS Datastore через различные IP-адреса контроллера NetApp. Такой вариант наилучшим способом использует один интерфейс VMkernel (адрес источника (source)). Если у вас больше датасторов, чем  IP-адресов, то просто распределите датасторы по доступным IP-адресам контроллера NetApp поравномернее.

Обратите внимание: Когда вы назначаете алиас интерфейсу, и у вас установлены и включены партнерские отношения между двумя контроллерами (и, естественно, их физическими интерфейсами) кластера NetApp, то в случае кластерного файловера алиасы также перенесутся на партнерский интерфейс

Ну и, наконец, обещанные шаблоны:

Continue reading ‘Multimode VIF в NetApp (часть 2)’ »

NDMP – Network Data Management Protocol – это разработанный еще в 90-х годах компаниями NetApp и Legato(ныне EMC Software Group) сетевой IP-протокол, и концепция архитектуры резервного копирования для NAS-устройств. Основной идеей, создавшей концепцию NDMP, являлось желание дать NAS-системам хранения, представляющим из себя обычно довольно мощный сервер сам по себе, возможность самостоятельно, своими силами осуществлять резервное копирование своего содержимого.

(Дальше много текста с картинками)

Continue reading ‘NDMP – что это, и как использовать?’ »

Возможно вы уже знакомы с так называемым special boot menu, которое появляется, если при загрузке с сериальной консоли нажать Ctrl-C. Любопытно, что кроме 6 предлагаемых вариантов, в этом меню есть и скрытые варианты. Например, если туда, вместо предлагаемых номеров, ввести WAFL_check [aggrname], где [aggrname] это имя соответствующего аггрегейта, то начнется подробная проверка консистентнсти WAFL на нем. Это может помочь если, по какой-то причине, состояние дисков и WAFL на них настолько нарушено, что система хранения не загружается, или не в состоянии разрулить проблему обычными средствами.

По сути это аналог fsck в single mode для привычных unix-type filesystem.

Пример:

Special boot options menu will be available.
NetApp Release 7.0.4P1: Mon Feb 27 14:36:15 PST 2006
Copyright (c) 1992-2006 Network Appliance, Inc.
Starting boot on Sat Mar 24 15:36:18 GMT 2007
(1) Normal boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Initialize all disks.
(4a) Same as option 4, but create a flexible root volume.
(5) Maintenance mode boot.
Selection (1-5)? WAFL_check aggr01
Sat Mar 24 15:38:15 GMT [wafl.vol.inconsistent:ALERT]: Aggregate aggr01 is inconsistent. Please contact NetApp Customer Support.
Sat Mar 24 15:38:15 GMT [raid.vol.replay.nvram:info]: Performing raid replay on volume(s)
Sat Mar 24 15:38:15 GMT [raid.cksum.replay.summary:info]: Replayed 0 checksum blocks.
Sat Mar 24 15:38:15 GMT [raid.stripe.replay.summary:info]: Replayed 0 stripes.
Checking aggr01…
WAFL_check NetApp Release 7.0.4P1
Starting at Sat Mar 24 15:38:17 GMT 2007
Phase 1: Verify fsinfo blocks.
Phase 2: Verify metadata indirect blocks.
Phase 3: Scan inode file.
Phase 3a: Scan inode file special files.
Phase 3a time in seconds: 9
Phase 3b: Scan inode file normal files.
(inodes 5%)
(inodes 10%)
…
(inodes 92%)
(inodes 97%)
(inodes 99%)

Следует также отметить, что не зря эта команда запрятана так далеко и неочевидно. WAFL зарекомендовала себя чрезвычайно стабильной и надежной файловой системой, и нужда в таком своеобразном fsck возникает, на самом деле, очень редко.

Появившийся на Wndows Vista, а позднее и на Windows Server 2008 протокол SMB2.0, дальнейшая разработка Microsoft своего сетевого протокола, показывает заметное улучшение производительности, однако требует для своей работы пока не слишком распространенных платформ Vista и Server 2008.

Но для тех, кто уже перешел на новые платформы, интересно будет узнать, что SMB2.0 поддерживается в протоколе CIFS в NetApp FAS начиная с версии ONTAP 7.3.1
Для включения SMB2.0 надо изменить значение системной опции options cifs.smb2.enable

Любопытное исследование, показывающее эффект от перехода на SMB2.0 с Jumbo Frames в гигабитной локальной сети найдено тут:
http://www.alternativerecursion.info/?p=48

Пожалуйста, обратите внимание, что SMB2.0 поддерживается только в Vista, Windows 7 и Server 2008, включать его при использовании в сети клиентов XP и Server 2003 нельзя.

Официальный документ из технической библиотеки NetApp:
SMB 2.0 – Next Generation CIFS protocol in Data ONTAP®

NetApp Data Motion – новая технология “непрерывающей” миграции данных между системами хранения NetApp. Эта технология несколько напоминает VMware vMotion, но для хранилищ данных, при которой виртуальные машины могут, не прерывая работы, мигрировать между хост-серверами, например в зависимости от их загрузки, или состояния. Это также чем-то похоже на VMware Storage vMotion, но выполняется целиком “аппаратно”, средствами системы хранения, и не привязано к какому-либо софтверному решению на хостах.

Она объявлена для версий новой “линейки” Generation 8, но в январе выйдет и в “Classic”, “Generation 7”, в версию Data ONTAP 7.3.3, для тех, кто вынужден оставаться на старой линейке.

Для работы NetApp Data Motion необходимы следующие компоненты и лицензии:

1. Multistore – лицензия позволяющая создавать на контроллере NetApp так называемые vFilers, “виртуальные файлеры”, изолированные, виртуализованные средствами самого NetApp ONTAP, “псевдофайлеры”. Раньше эта лицензия обычно использовалась для того, чтобы разделить физический “файлер” на несколько “виртуальных”, например для того, чтобы подключить его в многодоменную CIFS-сеть, или раздать такие “виртуальные файлеры” различным администраторам подразделений в крупной организации или компании-провайдере услуг хранения. Однако идея NetApp, стоящая за Multistore была куда шире.
2. SnapMirror в режиме Semi-sync – лицензия на средство репликации данных между системами хранения NetApp, осуществляемое, в данном случае, в “квази-синхронном” режиме, по IP-сети.
3. Средство управления Provisioning Manager версии 4, являющееся частью продукта Operations Manager v.4. Это сравнительно новый для пользователя продукт, обеспечивающий GUI-управление, в том числе и процессом Data Motion, размещающийся на администраторском компьютере.

Процесс миграции заключается в предварительной репликации данных с одной физической системы хранения, где находится мигрируемый vFiler, на другую, когда предварительная baseline replication завершена, то, с помощью Provisioning Manager-а администратор может отдать команду, и vFiler “переключится” с одного контроллера на другой, на котором уже к тому времени будут находиться его данные, при этом ресурсы, такие как, естественно, данные, адреса, имена шар, LUN и их маппинг, также смигрируют вслед за vFiler.

Пока технология не лишена недостатков и ограничений.

1. Пока не поддерживаются LUN с работой по FC. Но работает iSCSI. Поддержка FC будет реализована позднее в 2010 году. Разумеется работает NFS и CIFS, однако, в случае CIFS, текущая, на момент миграции, сессия CIFS будет прервана, и ее надо будет переустановить (что связано со stateful-природой CIFS как протокола).
2. Необходимо, чтобы оба контроллера, и источник и получатель миграции,  находились в одной IP-подсети.
3. Оба контроллера (пока) должны быть однотипными, в случае неоднотипности, миграция возможна с контроллера с меньшим размером NVRAM на бОльший (но в этом случае миграция будет однонаправленная). Также (пока) не поддерживается вариант миграции данных с FC/SAS-дисков на SATA.
4. Естественно не поддерживаются traditional volumes (кто-то их использует по доброй воле еще?).
5. Мигрируются все тома, принадлежащие данному vFiler.
6. SnapLock и FlexCache (пока) не поддерживаются.
7. Дедуплицированные данные переносятся дедуплицированными, и сохраняют доступность в своем дедуплицированном виде, но соответствующие им метаданные на “получателе” репликации надо заново перегенерировать, чтобы новые записываемые данные могли также дедуплицироваться вместе со старыми, так как метаданные (база фингерпринтов) остаются на уровне aggregate, и не мигрируют.
8. Мигрированные FlexClones - “развернутся”, “девиртуализируются”, и займут “положенное им по объему” (это, к сожалению, свойство их репликации с помощью SnapMirror).
9. Пока управление процессами Data Motion возможно только через GUI Operations Manager-а, не через командную строку.

Будем надеяться, что значительная часть ограничений, присущих любому продукту “версии 1.0” со временем будет устранена. Сама же Data Motion это логичный шаг в направлении глобальной стратегии NetApp – построении “облачного” распределенного хранилища, с глобальным “пространством хранения”, распределенным и прозрачно мигрирующим между множеством различных физических хранилищ.

В основу поста легла заметка в блоге Аарона Делпа, по новостям с NetApp Insight 2009, и презентации Ларри Туше, инженера “команды виртуализации” NetApp.

Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.

Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

В блогах я нашел описание любопытного эксперимента (по ссылке часть 5, смотрите в тексте ссылки на предыдущие 4 части).

Автор создавал сильно фрагментированный, кусками по 2MB и 128KB (5000 и 60000 кусков соответственно), файл, общим размером 10GB, и тестировал на нем последовательные чтения и записи. В качестве дискового хранилища использовались как диски самого сервера (на графиках - DAS), так и раздел на SAN-хранилище EMC Symmetrix DMX-2.

Вот как описывает тестовое оборудование сам автор: The server was a standard DL580 with 4 single-core sockets (2.0GHz Xeon) with 4GB of RAM. The disk array was a DMX2 with 10K rpm 146GB FC drives in a RAID10 config. The test LUN was 96GB in size (with 8GB disk slices from 24 spindles). Two Emulex LP8000 HBAs were load balanced with PowerPath.

Первый результат был обескураживающим. В случае использования высокопроизводительного SAN-стораджа, результаты для фрагментированного и дефрагментированного файла, и тестирования последовательной записи блоками по 1К,  были практически идентичными. Очевидно, что эффективное кэширование и хороший запас быстродействия DMX “съели” возможное снижение быстродействия из за присутствия фрагментов.

Далее автор создал аналогичный раздел на дисках серверов (DAS), и протестировал его.

И тут мы уже видим значительный эффект от фрагментированности файла при последовательном доступе (почти 30% снижение быстродействия).

Далее автор уменьшил размеры “блоков фрагментации” до 128KB (то есть увеличил количество фрагментов своего 10GB тестового файла), и проверил эффект на последовательном чтении.

И снова мы видим, что эффект хорошо заметный на DAS, практически отсутствует на высокопроизводительном SAN-массиве.

Проявляется ли хоть как-то эффект от фрагментации вообще? Автор обнаружил лишь один параметр:

На файле размером в 10GB, состоящим из 60 тысяч хаотически разбросанных по диску фрагментов заметно выросло время Latency, задержек чтения. Обратите внимание, что для такого же 10GB-файла с 2MB блоками, разбитого на 5000 таких же разбросанных фрагментов, не было даже и такого эффекта.

И, наконец, автор измерил время ряда операций:

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