about NetApp

Официально NetApp поддерживает совместимость только с UPS компании APC, до версии 7.2.1 это были модели SmartUPS (и Symmetra), с версии 7.3.2 добавились модели семейства Silcon. Вот официальный список:

После 7.2.1 официальный список был упразднен, и теперь базовая поддержка со стороны ONTAP осуществляется для всех моделей указанных выше линеек APC. Понятие “поддержка в OS” означает, что Data ONTAP может осуществить корректное завершение работы (shutdown) при использовании UPS перечисленных типов.

Используя возможности взаимодействия с UPS в ONTAP следует учитывать, что NetApp не использует SNMP Trap при работе с UPS, вместо этого он использует SNMP Get. Состояние UPS проверяется каждые 5 минут по сети Ethernet, в которую подключен UPS, с использованием SNMP. При этом Data ONTAP получает следующие параметры UPS:

• Работает ли он от сети, или находится на батареях
• При нахождении на батареях, каково оценочное оставшееся время

Когда обнаруживается переключение на батареи, интервал проверок состояния сокращается до 10 секунд. Когда уровень батарей достигает уровня, определенного как “Warning-Low” начинают поступать сообщения в систему EMS (Enterprise Messaging System), когда уровень заряда батарей снижается до “Critical-Low” отсылается сообщение в EMS и начинается процедура shutdown.

Если контроллер NetApp отслеживает состояние нескольких UPS (например отдельно для контроллера, для дисковых полок, и для сетевого оборудования), то процедура shutdown начинается при достижении уровня “Critical-Low” на любом из этих UPS.

Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились в той же IP-подсети, что и контроллер NetApp, а сетевое оборудование также должно быть подключено к UPS, чтобы, в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

Для управления UPS в консоли администратора есть команда ups:

ups add [-c <community>] <ip address>
ups [ disable | enable ] [ all | <ip address>]
ups status
ups set-limits [ all | <ip address>] <critical-time  (secs)><warn-time  (secs)>
ups print-limits [ all | <ip address>]

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

В прошлый раз мы нашли и посмотрели команду filersio – внутренний генератор нагрузки ввода-вывода. Однако оказывается, такая штука, как stress test tool, внутри Data ONTAP есть не одна.

Еще один инструмент нагрузочного тестирования системы хранения – hammer

hammer это в чистом виде stress load generator, не делающий ничего, кроме нагрузки. Если вы хотите не просто “подвесить систему”, но еще и наблюдать за тем, что эта нагрузка дает вам в плане показателей, воспользуйтесь средствами sysstat или stats.

В заключение еще раз предостерегу вас от экспериментов с такими командами на рабочей системе с данными. Все это небезопасно, и может в лучшем случае привсти к временной неработоспособности или недоступности системы, а в худшем – к случайной потере ваших данных.

В недрах Data ONTAP кроме малоизвестных команд можно отрыть и какие-то совсем загадочные вещи. Занятие по отрыванию таких загадок никак нельзя рекомендовать как безопасное, но иногда находятся интересные штуки.

Вот, например, команда filersio (доступна в advanced mode)

filer1*> filersio
The following commands are available; For more information
filersio help
asyncio_pause asyncio_active spc1
status stop


Эта команда включает встроенный генератор ввода-вывода нагрузки на систему хранения.

filer1*> filersio asyncio_active 50 -r 50 4 0 10m 60 5 /vol/vol0/filersio.test -create -print_stats 5
filersio: workload initiated asynchronously. Results will be displayed on the
console after completion
filersio: starting workload asyncio_active, instance 0

Read I/Os       Avg. read       Max. read       Write I/Os      Avg. write      Max write
                latency(ms)     latency(ms)                     latency(ms)     latency(ms)
6087            0               11              6216            3               981
4410            0               471             4300            5               1551
5323            0               11              5375            4               1121
5439            0               113             5379            4               1151
4354            0               105             4304            5               1674
4307            0               411             4300            5               1171
5459            0               20              5371            5               1260
5384            0               180             5379            4               1071
5439            0               211             5375            4               1011
4396            0               71              4300            5               1311

Statistics for active_active model, instance 0
Running for 60s
Total read latency(ms) 16383
Read I/Os 51687
Avg. read IOPS 861
Avg. read latency(ms) 0
Max read latency(ms) 471
Total write latency(ms) 286501
Write I/Os 51413
Avg. write IOPS 856
Avg. write latency(ms) 5
Max write latency(ms) 4891
filersio: instance 0: workload completed successfully


Напомню еще раз, что все команды, доступные в advanced mode, могут быть небезопасны, не требуются для повседневного администрировани и конфигурирования, и использование их требует ясного понимания возможных результатов и рисков использования и настоятельно не рекомендуется на “боевых” системах с рабочими даными. И уж тем более это так для команд из “недокументированного” и “слабодокументирванного” списка.

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

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