Posts tagged ‘options’

minra и no_atime_upd в свойствах тома NetApp

Два параметра в свойствах FlexVol-тома NetApp, значения которых вы, возможно, не знали.

“minra” минимизирует (min) операцию упреждающего чтения (Read-Ahead, ra). Режим упреждающего чтения есть метод своеобразной оптимизации чтения. Алгоритм предсказания операций чтения старается определить, насколько высока вероятность, что следующие считываемые блоки будут располагаться последовательно, и, если да, то читает их с упреждением , read-ahead, в расчете, что данные, заранее прочитанные, понадобятся на следующей операции, а они у нас уже в памяти.

В версии DataONTAP 6.5 и ранее, алгоритм был довольно примитивен, и просто читал с упреждением блоки с диска, заполняя, подчас, память кэша чтения системы ненужными данными, например в случае равномерно-рандомного чтения. Поэтому в старых руководствах вы могли встретит рекомендации устанавливать в свойствах тома этот параметр в minra=on, то есть отключать упреждающее чтение. Это помогало сэкономить пространство кэша в случае заведомо рандомного характера рабочей нагрузки.

В версии 7, и в особенности в 7.3, алгоритм Read Ahead значительно усложнился и поумнел, и теперь предсказание упреждающего чтения работает значительно лучше и эффективнее. Поэтому для новых систем, начиная с 7.3, рекомендуется не выключать Read Ahead (НЕ ставить minra=on в свойствах тома), даже для рандомной нагрузки, предоставив работать умному алгоритму.

Второй параметр – “no_atime_upd” – отключает обновление времени последнего доступа к файлу (access time - atime), располагающемуся на файловой шаре с доступом по NFS или CIFS. В случае, если вы используете систему NetApp как NAS, и ваши приложения доступа к файлу НЕ пользуются данными last access time (это вообще используется сегодня сравнительно редко), то этот параметр лучше установить в on (выключить обновление времени последнего доступа). Этот параметр никак не влияет при использовании систем NetApp как SAN-хранилища, то есть когда том FlexVol хранит на себе LUNы.

Для файловых же операций его отключение в настояще время также почти не влияет на быстродейстие тома, по наблюдениям прирост составляет в районе 1-1,5%.

Таким образом, на сегодня, оба эти параметра остаются скорее как legacy параметры, и особого эффекта их настройка не приносит.

Блокировка трафика протоколов на портах

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

И мы хотели бы гарантировать, что каждый трафик будет существовать только в своей сети. До ONTAP 7.3 минимальные средства такого управления были только для iSCSI. Можно было разрешить или запретить iSCSI на конкретном порту, и только. Но начиная с 7.3 появилась новая возможность.

fas> options interface.cifs.blocked e0b
fas> options interface.iscsi.blocked e1a,e1b,e1c,e1d
fas> options interface.nfs.blocked e0a,e0c
fas> options interface.snapmirror.blocked e0d

Из приведенных примеров, как мне кажется, все понятно. Обратите внимание, что настройки на обоих контроллерах кластера должны быть строго идентичны! Также имейте ввиду, что данные настройки не работают для iSCSI HBA и TOE-карт, то есть это только для обычных NIC, как onboard, так и карт расширения.

20/0.135

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.