about NetApp

Многие пользователи NetApp, в особенности их младших моделей (Low Enterprise Class, FAS2020 и FAS2050) часто жалуются на большие потери при создании usable space. Зачастую usable space может составлять всего 50% от raw, а иногда бывает и того менее.
Действительно, на системах с малым числом дисков, а зачастую именно такие попадают в сравнительно небольшие компании и проекты, величина пространства, которая отнимается по умолчанию из дискового пространства такой системы довольно велика. Чем больше в системе дисков, тем меньшую роль это играет, однако на небольших системах этот эффект довольно значителен.

Что с этим делать, и насколько это серьезная проблема?

Как вы уже знаете, индивидуальные настройки системы хранения NetApp находятся на создаваемом при первом запуске системы томе vol0 в директории /etc. В отличие от решений конкурентов, этот том не какой-то специальный, а самый обыкновенный, и все содержимое его за исключением занятого под /etc мы можем использовать для хранения пользовательских данных.

Однако такой том нужен для каждого из двух контроллеров, и, в случае использования RAID-4 мы потратим на их создание как минимум 2 диска на parity disks для их RAID-групп (и 4 в случае RAID-DP), плюс еще диски на parity для RAID-групп данных. Плюс hot spare. Вот и убегает, при создании системы с настройками “по умолчанию”, половина всех доступных дисков. Хотя, говоря начистоту, при использовании RAID-10 в “других система хранения” мы тоже получаем 50% usable от raw, но в данном случае все равно как-то жаба грызет.

??так, каким хитрым способом можно получить максимально возможное количество usable space на системе типа FAS2020A, с, допустим, дисками SATA 1TB 7200RPM?

С самого начала скажу, что нижеописанная схема никакой не Best Practices (а скорее даже Bad Practices), но тем не менее позволят получить максимум usable space на небольших системах, типа FAS2020. Если вас угораздило купить такую, да еще с небольшим количеством больших дисков SATA в базе, невзирая на все, что вам говорили при этом при продаже - читайте дальше.

Можно создать aggr0 из всего пары дисков в RAID-4 (1 диск данных и 1 диск parity), и разместить на нем vol0 для первого контроллера. На этом vol0 находится служебная информация, необходимая для загрузки и работы контроллера, директория /etc, поэтому создавать его придется на “полностью чистой” системе из меню Maintenace mode. Служебная директория займет примерно мегабайт 30. Остальное место, почти терабайт, мы можем использовать для хранения каких-нибудь наших данных. По умолчанию на vol0 создается директория home, в которой можно разместить homedir подключенных к NAS пользователей. Однако следует помнить, что быстродействие тома, построеного на RAID из всего двух дисков будет невелико. Так что лучше если это будут какие-нибудь не критичные к быстродействию данные

Оставшиеся 10 дисков мы распределяем таким образом: 1 диск оставляем в hot spare*, а все оставшиеся 9 помещаем в один большой aggregate, в одну RAID-группу типа RAID-4 или RAID-DP (1 или 2 pariy, 8 или 7 дисков данных). ?? на этой большой группе создаем vol0 для второго контроллера.
А все оставшееся место, за вычетом 30Mb на содержимое /etc, мы можем занять нашими данными, причем они будут распределены уже по “длинному” и, следовательно, более быстродействующему RAID.

Disk layout

Отмечу, что, если не ошибаюсь, начиная с ONTAP 7.3, для системы хранения NetApp назначается 2 диска hot spare на каждый контроллер, что для малых систем, на мой взгляд, чересчур расточительно. Это значение можно изменить в системных опциях*.

Преимущества:

1. Мы получаем величину usable space равную 75% от raw (из 12 дисков выпадают 3: 1 на parity на первом контроллере, 1 на parity на втором контроллере, 1 на общий spare)
2. Мы получаем большой раздел “одним куском”, и можем, например, создать на нем LUN размером 8TB (больше все равно не поддерживается на 2020)
3. Этот большой раздел получается относительно быстродейстующий, так как распределен на максимально возможное в данном случае количество дисков.

Недостатки:

1. Мы, по сути, делаем резко асимметричную систему, в которой контроллер 1 практически не занят, и вся рабочая нагрузка по обслуживанию доступа к данным ложится на второй.
2. RAID-4 менее отазоустойчив, чем RAID-DP, в особености на SATA, и обеспечивает более долгое время ребилда в случае сбоя.
3. 1 spare на 2 контроллера это “не рекомендованная” NetApp конфигурация.
4. Такая схема разбиения “не рекомендуется” NetApp для использования.

Так что на свой страх и риск.

* Необходимо изменить системный параметр:
set options raid.min_spare_count 1

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

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

filer01> config
Usage:
config clone
config diff [-o ] [ ]
config dump [-f] [-v]
config restore [-v]

Команда простая и понятная. Сперва вы сохраняете (dump) конфигурацию с системы хранения. Это проделывается с содержимым /etc/configs. Далее вы можете клонировать (clone) эту конфигурацию на другую систему, или сравнить ее (diff) с ранее сделанным дампом конфига. Запуск diff это отличный способ сравнить два конфига между двумя моментами времени, если вы не уверены или не помните что вы изменяли. ??, наконец, вы можете воспользоваться средствами восстановления (restore), однако не забудьте, что это потребует перезапуска системы хранения.

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

Новая полезная команда для администратора CIFS NAS появилась в версии 7.3 (и новее). Любому win-админу известно, какая катавасия начинается с доступом, когда становится много пользователей и групп безопасности. Юзеру “Петя” позволено то, но не позволено это, но когда он входит в группу “Менеджеры”, то ему позволяется еще вот это и это, но зато запрещается вон то, что раньше было разрешено индивидуальному пользователю (как известно, в системе безопасности NT DENY всегда перекрывает ALLOW). ?? такое спагетти из прав работает до тех пор, пока однажды не запутается намертво, заставляя админа лезть на стену. ?? вот тут пригодится инструмент, который покажет что не так, не просто access denied, а почему, и отчего.

Например
sectrace add -a -path /vol/software

выведет в лог что-то наподобие:

Sun Feb 1 13:10:52 IST [jim: sectrace.filter.allowed:info]: [sectrace index: 2] Access allowed because ‘Synchronize, Read Attributes’ permission (0×100080) is granted on file or directory (Access allowed by an explicit access control entry) - Status: 1:58720452:0:0 - 10.1.20.107 - NT user name: support\administrator - UNIX user name: root(0) - Qtree security style is NTFS and NT ACL is set on file/directory - Path: /vol/software/

Возможные опции: sectrace add, sectrace remove, sectrace show, sectrace print-status

Подсмотрено у http://filers.blogspot.com/

По умолчанию, TCP-окно Snapmirror равно 1,994,752 байт. В структурах, где SnapMirror используется для репликации данных через WAN, такое значение может заметно замедлять процесс репликации. Важно правильно вычислить верные настройки TCP-окна, и соответствующим образом их установить. Базовая формула такова:

Window Size = Round Trip Delay X Desired Rate

Таким образом, если у вас используется канал 10Mb/s и средний RTD равен 100ms, то window size должен быть 125,000 байт.

Несколько замечаний о этом TCP Window size:

Это теоретически минимальное возможное окно, используемое SnapMirror, и может не быть самым оптимальным. Попробуйте несколько вариантов в районе этой цифры, чтобы выбрать наилучшее.
Установить размер TCP window size можно в файле /etc/snapmirror.conf в параметре wsize.
Это надо установить и на системе-получателе репликации.

Другая возможность, которая должна помочь в тонкой настройке, это установка опции:

options snapmirror.delayed_acks.enable off

Эта установка выключает TCP/IP delayed acknowledgments. В сетях с высоким значением задержки, это может дать выгоду. По умолчанию она включена.

romx: Хочу также обратить внимание, что в речь идет именно о тонкой настройке и оптимизации определенных вариантов конфигурации, так как настройки SnapMirror по умолчаню выбраны для удовлетворительной работы в любых условиях. Если вы не уверены в том, что вы делаете, то лучше оставьте по умолчанию. Помните первое правило профессионала: “Работает - не трогай!” :)

Оригинал тут:
http://rajeev.name/blog/2008/03/18/optimizing-snapmirror-performance/
(будьте внимательны, на хостинге этой страницы сейчас сидит веб-червяк-троян!)

Команда консоли sysstat похожа на vmstat и iostat свернутые в одну команду. Она сообщает данные производительности систем хранения, такие как CPU utilization, размеры дискового трафика, объемы ввода-вывода, как сетевого, так и по FC, а также трафик передачи данных на ленту, если она используется. При запуске без опций, sysstat печатает новую строку каждые 15 секунд, с базовым набором информации. Вы можете прервать вывод нажав control-C (^c) или установить при запуске определенный интервал работы (-c count ) для автоматической остановки через заданное время.
Список ключей команды:

-f статистика FCP
-i статистика iSCSI
-b расширенная статистика SAN (’blocks’)
-u расширенная статистика загрузки системы (’utilization’)
-x расширенный (’extended’) формат вывода. Включает в себя все доступные поля вывода.

Обратите внимание, что вывод производится в формате шире чем 80 символов, и предназначен скорее для “off-line” анализа, чем для непосредственного чтения с экрана.

-m отображает статистику по загрузке CPU на многопроцессорных системах. Применимо только на многопроцессорных системах, не работает на однопроцессорных.

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

Cache age : возраст в минутах старейшего read-only блока в кэше. Значение в этой колонке показывает, насколько быстро операции чтения проходят через память системы; когда система читает очень большие файлы, значение buffer cache age будет низким. Кроме этого, если чтение преимущественно случайное, то cache age также будет низок. Если вы столкнулись с проблемой низкой производительности на чтении, то значение этого поля сможет помочь определить что вам нужно больше кэша, или нужно проанализировать работу приложения, чтобы снизить уровень “случайности” его запросов.

Cache hit : Величина в процентах для WAFL cache hit rate. Показывает, в скольки процентах читаемых с WAFL блоков они оказывались при этом уже в кэше. Прочерк в этой колонке, означает, что в измеряемый период данные не читались.

CP Ty : Тип (’type’) Consistency Point (CP). Показывает, что было причиной создания CP в рассматриваемом интервале. Тип CP может быть:

- не было CP в заданный интервал (не было записей на диск в указанный период времени)

(число) число CP, созданных в заданном интервале

B : Back to back CPs (CP generated CP) (система настолько загружена, что она начинает писать новую CP сразу за окончанием записи предыдущей)

b : задержанные back to back CPs (CP generated CP) (условия, вызвавшие состояние back to back стали хуже)

F : CP вызван заполнением NVLog (половина nvram log была заполнена, и он был сброшен на диск)

H : CP вызван high water mark (редко встречается. Система полностью заполнила одну половину nvram logs, и решила сбросить данные на диск).

L : CP вызван low water mark

S : CP вызван операцией создания snapshot

T : CP вызван таймером (каждые 10 секунд система хранения сбрасывает данные кэша на диск (flush))

U : CP вызван сбросом данных на диск (flush)

: продолжение CP с предыдущего интервала (означает, что CP все еще создается, например во время 1-секундного интервала)

Символ, следующий далее, показывает проходящую фазу создания CP на момент окончания интервала замера. Если CP завершился полностью во время интервала измерения, то второй символ будет пустой. Фазы могут быть следующие:

0 ??нициализация
n обработка обычных файлов
s обработка специальных файлов
f сброс измененных данных на диск
v сброс измененного суперблока на диск

Большинство перечисленных выше значений можно увидеть только в случае предельно малых интервалов замеров, или на сильно загруженных системах, так как сброс CP происходит очень быстро. Обычно в поле CP ty вы будете видеть ‘T’, штатный сброс Consistency Point по таймеру.

Давайте разберем пример.

sysstat.txt (для более удобного вида отключите в нотепаде word wrap и расширьте окно)

Что мы можем сказать о данной системе?
Это малозагруженная, практичеси находящаяся в покое система (параметры CPU, Disk Usage и Total), использующая CIFS и FCP (небольшие ненулевые значения показывают фоновые операции по этим протоколам). Большиство операций в этой покоящейся системе совершается в виде чтения содержимого кэша (значение Cache hit). Кэш практически пуст, на что указывает монотонное возрастание значения Cache age, данные лежат, и ничто их не вытесняет. Consistency Points создаются исключительно сбросом по таймеру, что нормальное поведение для незагруженной системы.
Довольно высокие значения Disk read write при малой загрузке CPU, практически нулевом сетевом траффике и операциях ввода-вывода по блочным протоколам указывает на работу процесса Disk Scrubbing, фонового процесса контроля целостности данных и дисков, при котором система перечитывает и перезаписывает данные на дисках, возможно также что работает дедупликация, хотя она обычно дает повыше чем 1-3% загрузку, также, возможно, это признак работы дефрагментации WAFL (wafl reallocate).

Так выглядит типичный вывод sysstat малонагруженной типовой системы NetApp FAS.

А вот так выглядит система под рабочей нагрузкой: sysstat3.txt

Как видите, уже заметно нагружен процессор (это FAS6070, поэтому запас еще весьма существеннен ;), около 20%. Так как система используется как SAN, то весь трафик идет по колонке FCP. Несмотря на заметную нагрузку, ниже приведенный отчет по utilization показывает производительность около 15000 IOPS, и около 23 MB/s чтения с дисков ( и 70-90MB/s по интерфейсам FC), это не перегрузило систему. Большой объем кэша на чтение позволяет 90% операций читаться из кэша, а не с дисков.
Возраст самого старого блока в кэше составляет примерно 10-12 минут, то есть кэш еще далек от заполнения.
Здесь уже периодически проскакивают символы, показывающие фазу сброса CP, и само время записи CP увеличилось, так как вырос объем записи, хотя он и составляет всего около 1/10 от объемов чтения.

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

Оригинал тут:

http://unixfoo.blogspot.com/2007/11/netapp-performance-monitoring-sysstat_16.html
А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.

Очень часто владельцы систем хранения NetApp, читающих тут меня, или слушающих на семинарах про новые фишки этих систем, думают: “Ну на словах-то они все мастера загибать, пока сам не увижу, сам не пощупаю, пока на своей системе, в моей собственной задаче не увижу как работает - ни в жизнь не поверю!” ?? тут они по своему правы. Маркетинговые балаболы давно заслужили недобрую славу в нашей отрасли.

Однако тут у NetApp есть совершенно убойный ответ: вы можете получить временные полнофункциональные лицензии, установить их на свою собственную систему и включить для оценки любой желаемый на ней функционал, с тем, чтобы проверить его работу и применимость в вашей конкретной задаче. А потом уже, не торопясь, с полным владением всеми деталями, убедившись и протестировав все досконально решать, покупать вам такую опцию или нет.
Хотите посмотреть как работает “вживую” FlexClone? SnapMirror? CIFS NAS? NFS с Oracle или VMware?

На сайте NOW (NetApp on Web), по адресу http://now.netapp.com/eservice/evallicense (этот адрес требует авторизации вашим логином, как и весь NOW) можно сгенерировать для вашей системы хранения evaluation licenses на любую опцию систем хранения NetApp.

Если ваш уровень доступа не позволяет вам зайти на эту страницу, то покажите этот адрес сотруднику вашего поставщика-партнера NetApp, с партнерским уровнем доступа эта странца отрывается точно, однако многие партнеры даже и сами не знают о существовании возможности самостоятельно генерировать evaluation licenses для своих клиентов.

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

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

??мейте ввиду, что установленные на систему лицензии передаются в комплекте логов для автосаппорта, и злоупотребление ими на “боевой системе” легко отслеживается. Это я так пальцем грожу, если что ;)