about NetApp

Я уже упоминал, что в Data ONTAP есть очень полезная команда stats, с помошью котрой можно вывести массу информации о работе системы. К сожалению, формат вывода ее “человеконечитаемый”, в большинстве случаев, поэтому для того, чтобы извлечь из ее вывода что-нибудь полезное, приходится предпринять некоторые усилия.

Так, например, довольно интересной задачей яляется поиск и вывод так наываемых busy spindles, или физических дисков, нагрузка по вводу-выводу на которые превышает норму по аггрегейту. Такое случается иногда при несбалансированности aggregate, например, чаще всего, при добавении дисков, которые, в ряде случаев, могут потребовать “рестрайпинга данных”.

В community.netapp.com я увидел интересную строчку для использования в скрипте вывода такой информации:

watch -n 3 "ssh NetAppHost stats show disk:\*:disk_busy | awk '{FS=\":\"; print \$1 \" \" \$2 \" \" \$3 \" \" \$13}'| sed 's/%//g' | awk '\$4>40{print}'"

Можете воспользоваться, кому интересно, и расскажите как работает.

Когда вы поставили и запустили симулятор Data ONTAP 8, вы увидите, что он идет с 28 (2х14) “дисками”, размером 1GB. Этого в общем вполне достаточно для большинства целей использования, однако, если вам потребуется больше дисков, вы можете увеличить их количество (но не размер!) до 56 штук. Обратите внимание, что вы не можете увеличить размер дисков, он для симулятора не может превышать 1GB. Ну… например чтобы не было соблазна устраивать из не предназначенного для этого симулятора бесплатный “виртуальный сторадж” ;). Как говорил один большой друг СССР – “Doverjai no proverjai!” ;)

Но сперва стоит немного остановится на некоторых деталях.

В отличие от Data ONTAP 7, в версии 8 появился специальный user-mode shell (консоль админа, несмотря на внешнюю схожесть, шеллом как таковым не является). Он доступен для специального, отключенного в целях безопасности, пользователя diaguser.

Мы рассмотрим добавление дисков только для симулятора 7-Mode. Для Cluster-mode это возможно также, но чтобы не удлиннять пост я его опущу (если кому-то понадобится процедура для Cluster-mode Simulator – напишите).

Итак, начнем с того, что разблокируем diaguser, от имени которого в шелле мы проделаем операции добавления:

priv set advanced
useradmin diaguser unlock
useradmin diaguser password

Теперь зайдем с systemshell этм пользователем:

systemshell
login: diag
password: <password>

Далее нам придется поправить некий глюк, допущенный при сборке утилиты управления “дисками”. Добавим символьные линки на стандартные библиотеки, а то утилита не сможет их найти:

cd /lib
sudo mount -u -o rw /
sudo ln -s libc.so.6 libc.so.7
sudo mount -u -o ro /

Установим переменную пути:

setenv PATH "${PATH}:/sim/bin"
echo $PATH

И перейдем в директорию эмулированных устройств

cd /sim/dev
ls ,disks/

Тут вы увидите уже созданные 28 дисков. К ним мы сейчас добавим еще 28. Имена уже существующих файлов-дисков начинаются с v1 и v2, что означает, что они “подключены” к адаптерам v1 и v2. У нас есть еще два неиспользованных адаптера (v3 и v4), к каждому из которых мы “подключим” по 14 дисков (это похоже на то, как подключаются обычные FC-полки к адаптерам отдельной FC-“петлей”, каждая полка на 14 дисков на свой адаптер).

Для этого воспользуемся утилитой makedisk.main:

makedisks.main -h
sudo makedisks.main -n 14 -t 23 -a 2
sudo makedisks.main -n 14 -t 23 -a 3
ls ,disks/

Первая команда печатает пояснение по доступным ключам. Две другие создают по 14 дисков
(-n 14) с типом диска 23 (-t 23) на адаптерах 2 и 3 (-a 2 и -a 3). Симулятор Data ONTAP 8.0.1 поддерживает конструктивно только диски размером 1GB и менее. Даже если вы видите в подсказке команды диски большего размера, воздержитесь от соблазна попробовать добавить их в симулятор. С виртуальными дисками размером больше 1GB Data ONTAP упадет в panic при перезагрузке, и вам придется устанавливать симулятор заново.

Ну вот и все, что необходимо было сделать в шелле. Вернемся “по своим следам” из шелла в обычную админскую консоль, выйдя из шелла и запретив diaguser, перезагрузим симулятор и он увидит новые диски:

exit
useradmin diaguser lock
priv set admin
reboot

После перезагрузки необходимо назначить ownership новым дискам:

disk show -n
disk assign all
disk show -v

Теперь у вас в симуляторе 56 “дисков” по 1GB каждый. Они уже zeroed, и вы можете непосредственно добавить их в нужный вам aggregate.

Исходный текст был взят тут: https://communities.netapp.com/docs/DOC-9579

В ряде случаев, например когда вы планируете использовать несколько установленных симуляторов, подключенных в Operations Manager, необходимо задать каждому из этих симуляторов индивидуальный SystemID и Serial Number. В будущем в NetApp обещают генерировать при установке произвольный номер, а пока все симуляторы идут с одним. Поэтому нужно проделать небольшой трюк.

При начальной загрузке прервите ее и войдите в SIMLOADER.

Выполните там две следующие команды:

SIMLOADER> set bootarg.nvram.sysid=1111111101
SIMLOADER> set SYS_SERIAL_NUM=1111111101

SystemID это 10-значное число. Последние две цифры должны быть уникальны в пределах Cluster-mode кластера для того, чтобы обеспечить уникальность UID дисков. Таким образом первые 8 цифр определяют кластер, а последние 2 – ноду в этом кластере. Впрочем, если вы используете симулятор только как 7-mode, вам это не важно, назначьте туда любое 10-циферное число.

Дайте команду:

SIMLOADER> boot

Войдите в Boot Menu нажатием Ctrl-C и выберите там Maintenance mode boot

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

UPD: Приведенный метод, к сожалению, НЕ РАБОТАЕТ для Simulator версии 8.1, он работает только для 8.0.1

Иногда бывает нужно создать пользователя, не имеющего на системе хранения других прав, кроме read-only, например для задач демонстрации и обучения, только для получения каких-то данных или снятия показаний, или же иных подобных применений. Сделать такого пользователя можно с помощью механизма RBAC – Role-Based Access Control (кстати по RBAC в техбиблиотеке Netwell лежит дельная переведенная документация).

Пример  создания роли read-only user при помощи DataONTAP Powershell Toolkit.


#Create read-only role:
New-NaRole ro_role -Capabilities  login-*
#Add read-only capabilities to this from attached file:
$caps = Get-Content .\RoRoles.txt
ForEach ($cap in $caps)
{
  Set-NaRole ro_role -AddCapabilities  $cap
}
#Create read-only group:
New-NaGroup ro_group ro_role
#Create read-only user:
New-NaUser ro_user rouserpassword ro_group


Файл RoRoles.txt со списком вызовов API DataONTAP можно скачать тут.

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. Используемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

Итак, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. Используя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

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

Использование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

Досадная недоработка в конфигураторе NetApp, не позволяющая купить FAS3210 без сконфигурированного MPHA, для которого требовалась дополнительная карта портов SAS, занимающая один из двух слотов расширения контроллера, и, например, мешавшая получить в 3210 и 10GB Ethernet и Flash Cache разом, в одной системе –  устранена.

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

Теперь нет нужды в хитрых маневрах, чтобы купить FAS3210 с 10G Ethernet и Flash Cache (по факту, весьма популярный вариант), конфигуратор исправлен, и теперь такую конфигурацию можно без проблем сконфигурировать и заказать.

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ‘vol0’, к примеру).

Для устранения этой проблемы Data ONTAP автоматически изменяет имена таких дублирующихся ресурсов, добавляя цифру в скобках. Однако проблема (по крайней мере в 7.x) в том, что такие авто-переименованные ресурсы нельзя переименовать вручную. Но можно переименовать исходный, который вызвал автопереименование последующих. Результат будет такой:

fas1> vol status
  Vol_data    online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on
  Vol_data(2) online          raid_dp, flex     create_ucode=on
 
fas1> vol rename vol_data vol_data_orig
fas1> vol status
  Vol_data_orig  online    raid_dp, flex     create_ucode=on
  Vol_data  online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on

Как вы видите, можно выкрутиться из этой ситуации переименовывая тома вручную по одному.

Лучше, конечно, в такую ситуацию не попадать, и проверять на возможность дублирования ресурсы (аггрегейты и тома) до миграции. Самым лучшим будет заранее разработать name convention, препятствующую дублированию имен ресурсов на разных стораджах, и следовать ей при развертывании.

Помощь, как всегда, была найдена в TFM  ;) – NetApp Storage Management Guide.

How you manage duplicate volume names

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

Самый удобный вариант – организовать подключение по SSH, однако, для того, чтобы не передавать пароль, сгенерировать заранее public key, и авторизоваться на консоли NetApp с его помощью.

Вот как это сделать с помощью популярного PuTTY.

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

Выберите пользователя, для которого мы будем устанавливать ключ. Помните также, что если вы используете выполнение каких-то скриптов от стороннего, специально сконфигурированного пользователя (например используя RBAC – Role-based Accees Control), то это надо будет также проделать и для него. Закрыв доступ для всех ключей, кроме заранее сконфигурированных, вы заблокируете таких пользователей также.

Далее нам надо создать на контроллере поддиректорию для файла ключей, она должна располагаться внутри директории sshd
полный путь, таким образом, с точки зрения стораджа будет выглядеть примерно так (для пользователя root):

/vol/vol0/etc/sshd/root/.ssh/

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

Смонтируйте root-vol в директорию на вашем компьютере по NFS или CIFS.

Перейдите в директорию /mountpoint/etc/sshd и создайте в ней директорию с именем нужного пользователя, например мы будем использовать для администрирования пользователя romx, а для исполнения скриптов пользователя scripter.

Перейдите в созданную директорию и создайте в ней поддиректорию с именем .ssh (с точкой в начале!)

Убедитесь, что директория успешно создалась, выйдите на уровень /mountpoint, например командой cd ../../../ и размонтируйте шару.

Вы получили следующую структуру на контроллере NetApp: /etc/sshd/romx/.ssh и /etc/sshd/scripter/.ssh соответсвенно.

Теперь сгенерируем пары ключей. Запустите программу puttygen.exe, входящую в состав пакета PuTTY.

Убедитесь, что используете security algorithm SSH2-DSA (Data ONTAP умеет использовать cipher для SSH только TripleDES), щелкните “Generate!” и поводите мышкой для генерации случайной инициализацонной последовательности.

Ключ сгенерирован, теперь надо указать контроллеру NetApp использовать для аутентификации этот ключ. Запишите его в файл с расширением .ppk, например romx.ppk

Не указывайте никакую passphrase.

Скопируйте из файла public-информацию, затем создайте в созданной на контроллере директории файл authorized_keys (без расширения) и запишите туда скопированный фрагмент. Обратите внимание, что в текстовом редакторе, где вы это проделываете, должен быть выключен режим перевода строк, иначе в ваш ключ могут попасть лишние символы перевода строки. Вся последовательность public key должна располагаться в файле в одну строку! Сохраните файл. Обратите внимание на то, что файл должен не иметь расширения!

Теперь включите на контроллере режим использования преконфигурированных ключей:

filer1> options ssh.pubkey_auth.enable on

Давайте протестируем подключившись с помощью программы plink из состава PuTTY, и запросив что-нибудь из консоли:

c:\putty> plink.exe -i romx.ppk romx@filer1 vol status

В результате мы должны получить вывод команды vol status (или любой другой), использовав аутентификацию подключения по заранее сконфигурированному ключу, без необходимости вводить пароль при логине данным пользователем.

Также рекомендуется для аккаунта, исполняющего скрипты, из соображений безопасности, запретить “лишние” возможности. Подробнее об ограничении прав аккаунта смотрите в документе RUS TR-3358 Role-Based Access Control for Data ONTAP 7G.

Как вы, возможно, слышали, загрузить систему хранения NetApp можно по сети, сравнительно традиционным для UNIX-систем способом загрузки OS (ядра и rootfs) через TFTP. Это может помочь, например, если из за неисправности имеющегося ядра, которое располагается в системах NetApp на внутренней CF-карточке.

Для того, чтобы загрузиться с TFTP необходимо при загрузке прервать обычное выполнение процедуры загрузки нажав при включении системы Ctrl-C (или в случае повреждения собственного загрузочного ядра OS система окажется там сама), оставшись в “биосе”. В качестве “биоса” в системах хранения NetApp используется специальный загрузчик, под названием LOADER (в более ранних системах, например FAS270 или FAS3020/3050 использовался немного другой метод – CFE – Common Firmware Environment).

Как для LOADER, так и для CFE для загрузки системы хранения с помошью netboot вам нужно скачать с сайта NetApp netboot-версию OS Data ONTAP нужной вам версии и типа платформы (для современных систем это всегда версия с индексом платформы Q, для FAS3020/3050 индекс платформы будет E, для старых, MIPS-based систем, например FAS270 – M).

Netboot-версия Data ONTAP 7.3.5.1 (наиболее свежей 7.х на момент написания этого поста) имеет размер 27,4MB (7351_netboot.q), версия Data ONTAP 8.0.1 – 144,6MB (801_netboot_q.tgz) и представляют собой kernel и rootfs завернутые в tar.gz, загружающиеся традиционным образом в память.

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

В подсказке LOADER необходимо настроить сетевой интерфейс и запустить сетевую загрузку.

LOADER> ifconfig e0a -addr=192.168.1.10 -mask=255.255.255.0 -gw=192.168.1.1
e0a: Link speed: 1000BaseT FDX
Device e0a:  hwaddr 00-A0-98-03-48-AB, ipaddr 192.168.1.10, mask 255.255.255.0
        gateway 192.168.1.1, nameserver not set

Доступные опции для команды ifconfig можно посмотреть введя в подсказке LOADER команду help ifconfig

Проверяем работу сети пингуя default gateway:

LOADER> ping 192.168.1.1
192.168.1.1 (192.168.1.1) is alive
192.168.1.1 (192.168.1.1): 1 packets sent, 1 received

Запускаем команду netboot

LOADER> netboot tftp://192.168.1.11/tftproot/netapp_7.2.3_x86_64
Loading:. . . . . . . . . . .

Далее Data ONTAP загружается обычным образом. Если /etc , хранящийся на root volume, при этом доступен, то система запустится штатным образом, восстановив все рабочие настройки, если же система повреждена значительно, и, например /etc также  недоступен, то можно попробовать загрузиться без /etc (выбрав соответствующую опцию в boot menu) инициализировать диски, создать новый aggregate, и запустить установку OS “начисто”.

Обратите внимание, что для netboot доступны только встроенные ethernet-порты, не те, что возможно у вас на системе установлены на карте расширения, которая в момент начальной загрузки еще недоступна.

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

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

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.