Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Commands | about NetApp

Posts tagged ‘commands’

Замена диска на конкретный из spare

Хотя в подавляющем большинстве случаев это и не является необходимым в практике администратора, однако в Data ONTAP имеется механизм принудительного “вывода из строя” и замены диска на конкретный диск из spare.

Для принудительного назначения диска “вышедшим из строя” можно использовать команду

> disk fail <disk.name>

ОСТОРОЖНО! Эта команда относительно легко доступна, а вот “обратная” ей disk unfail требует повышенного уровня привилегий, и доступна только джедаям от третьего уровня и выше. Помеченный как fail диск становится для системы на самом деле fail, и никакие “вынуть-вставить” его от этого состояния не лечат!

Эта команда не позволяет назначить на замену конкретный spare. Если же стоит задача именно корректно заменить один конкретный диск на конкретный другой из блока spare, то следует применить команду

> disk replace start [-f] disk.name sparedsik.name

Эта команда инициирует процесс Rapid RAID Recovery, при котором, напоминаю, считывается все доступное содержимое непосредственно со “сбойного” диска, а не восстанавливается из parity, как при “обычном” RAID Recovery, что гораздо быстрее и меньше нагружает систему, а все что считать таким образом не удалось уже восстанавливается традиционным способом.

После завершения RAID Recovery назначенный для замены диск заменяется на указанный из spare, а сам, в свою очередь, передается в блок spare.

Отменить начавшуюся процедуру замены можно командой

> disk replace stop disk.name

Команда lock

Продолжим нашу серию про не слишком известные, но полезные команды, “в записную книжку админа”. На очереди у нас уже однажды упоминавшаяся команда lock.

Напомню вкратце. В системе совместного доступа, какой является NAS, для того, чтобы обеспечить отсутствие конфликтов доступа, используется метод так называемого “локирования” доступа к файлу.  Это необходимо для предотвращения возможности одновременной, но неснхронизированной записи в один и тот же файл от разных клиентов, не знающих о том, что сосед тоже решил изменить тот же самый файл, уже открытый одним клиентом. Для предотвращения такой ситуации, первый открывший файл клиент получает исключительные права на запись в файл (локирует файл на запись), остальные же – только на чтение, до тех пор, пока первый клиент не закончит записи в файл.
Возможно два типа локирования, так называемый file lock, при котором ограничивается доступ на запись в файл целиком для всех, кроме залокировавшего файл на запись клиента, и byte range lock, при котором ограничивается запись к определенному участку файла.

С помощью команды lock status можно посмотреть, какой хост и какой пользователь локировал тот или иной файл на NAS-системе.

fas1>  lock status –p cifs –h  (показывает локи сортированные по имени хоста)
CIFS host=172.18.2.107(VUSER01-VPC) owner=administrator state=GRANTED mode=Read-
denyN oplock=None fsid=0×0e1d66f7 fileid=0×000000d3
path=\word.doc(/vol/vol0/share1/word.doc)

 
fas1> lock status –p cifs –o (показывает локи, сортированные по пользователю или владельцу)
CIFS owner=root host=10.34.17.49(PC002-XP) pid=65279 offset=2147483539 len=1
excl=yes state=GRANTED fsid=0×0e1d66f7 fileid=0×000000d3
path=\word.doc(/vol/vol0/share1/word.doc)

Снять же ненужное (например ошибочно “зависшее”) локирование можно командой:

fas1> lock break -f file [-o owner -h host] [-p proto]

Обратите внимание, что, хотя команда lock break –f и поддерживается, но при использовании NFS v4 ее применение не рекомендуется, по причине ряда ненужных побочных эффектов снятия локирования таким образом.

Что есть что в выводе команды snap list?

?ногда приходится сталкиваться с неполным пониманием того, что именно и как выводится в команде snap list.

Давайте на примерах разберем “что есть что”, где и как.

У нас есть том vol1 на 100G, практически пустой.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/               80GB       17MB       79GB       0%  /vol/vol1/
/vol/vol1/.snapshot      20GB       61MB       19GB       0%  /vol/vol1/.snapshot
 
fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    0% ( 0%)  Mar 08 00:00  nightly.0
47% (29%)    0% ( 0%)  Mar 07 20:00  hourly.0
57% (32%)    0% ( 0%)  Mar 07 16:00  hourly.1
64% (29%)    0% ( 0%)  Mar 07 12:00  hourly.2
69% (32%)    0% ( 0%)  Mar 07 08:00  hourly.3
73% (29%)    0% ( 0%)  Mar 07 00:01  nightly.1
76% (30%)    0% ( 0%)  Mar 06 20:00  hourly.4
78% (31%)    0% ( 0%)  Mar 06 16:00  hourly.5

В этом выводе, колонка %/used показывает объем, занятый снэпшотами, деленный на количество использованных в настоящий момент блоков на томе, независимо от того, заняты ли они в активной файловой системе, или снэпшотах. Первое число – накопительная сумма для всех показанных снэпшотов. Второе число (в скобках) – только для конкретного снэпшота.

Снэпшоты тома vol1 занимают 78% всех занятых на томе блоков, каждый из снэпшотов занимает примерно 29-32% занятых блоков.

Колонка %/total показывает объем занятый снэпшотами, деленный на общий объем диска. Он включает в себя пространство для данных, плюс snapshot reserve, то есть все использованные и свободные блоки тома. На томе 100GB занято примерно 61MB в снэпшотах, что составляет менее 1% общего объема (поэтому значение – 0).
Значение (в скобках) вычисляется аналогично вышеприведенному для %/used.

Давайте посмотрим, как все изменится, если мы уменьшим размер тома vol1 со 100GB до 1GB.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/              819MB       17MB      801MB       2%  /vol/vol1/
/vol/vol1/.snapshot     204MB       61MB      143MB      30%  /vol/vol1/.snapshot

fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    1% ( 1%)  Mar 08 00:00  nightly.0
47% (29%)    1% ( 1%)  Mar 07 20:00  hourly.0
57% (32%)    2% ( 1%)  Mar 07 16:00  hourly.1
64% (29%)    3% ( 1%)  Mar 07 12:00  hourly.2
69% (32%)    4% ( 1%)  Mar 07 08:00  hourly.3
73% (29%)    4% ( 1%)  Mar 07 00:01  nightly.1
76% (30%)    5% ( 1%)  Mar 06 20:00  hourly.4
78% (31%)    6% ( 1%)  Mar 06 16:00  hourly.5

Теперь мы видим, что снэпшоты заняли большее относительное пространство на томе в целом (%/total), то есть занятых ? пустых, но процент блоков в снэпшотах, относительно всех только занятых блоков на томе (%/used) остался неизменным.

Как всем этим полагается правильно пользоваться?

Величины %/used и %/total полезны при оценке того, насколько правильно выбрана величина snapshot reserve. Нехватка резерва приводит к тому, что снэпшоты “вылезают” за пределы резерва, и начинают занимать место в пространстве данных. Когда команда df показывает величину заняости диска больше 100% – это как раз такой случай: снэпшоты переполнили пространство резерва и начали заполнять пространство собственно данных. Это не страшно, особенно если для тома работает autogrow (и есть место на aggregate) или autodelete (и вы можете безболезненно удалить некоторые старые снэпшоты), но, тем не менее, этого следует избегать для более однозначной организации данных.

Когда вы решаете удалить тот или иной снэпшот, рекомендуется пользоваться командой snap delta или snap reclaimable, чтобы выбрать наиболее эффективный с точки зрения освобождения места снэпшот.
Число после точки в имени снэпшота увеличивается со взятием нового снэпшота. Например, сли вы берете снэпшот каждый час, то hourly.1 взятый в 9 утра, станет hourly.5 в 13:00. Также это работает и в случае daily- или weekly-снэпшотов.
Обратите внимание, что снэпшоты с явно заданным именем (то есть не те, что создаются по расписанию), а также снэпшоты, созданные SnapMirror и SnapVault не изменяют своего имени при создании новых.

Полезные команды: aggr show_space

Продолжим понемногу рассказ о полезных в работе админа системы хранения командах Data ONTAP.

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

fas1> df -Ah aggr_vm
Aggregate                total       used      avail capacity
aggr_vm                  454GB       31GB      422GB       7%
aggr_vm/.snapshot         23GB     2547MB       21GB      10%

Другая доступная нам для обзора состояния на уровне aggregate - это команда aggr show_space

fas1> aggr show_space –h aggr_vm
  Aggregate ‘aggr_vm’
  Total space    WAFL reserve    Snap reserve    Usable space   BSR NVLOG    A-SIS
        531GB            53GB            23GB           454GB         0KB     79MB
Space allocated to volumes in the aggregate
Volume                          Allocated            Used       Guarantee
esx_swap                           3103MB           391MB            none
vm_align                             16GB            16GB            none
p1newDataStore                     6190MB          6073MB            none
misc                               5817MB           248MB            none
Aggregate                       Allocated            Used           Avail
Total space                          31GB            22GB           422GB
Snap reserve                         23GB          2547MB            21GB
WAFL reserve                         53GB          5851MB            47GB 

Как видите, тут уже видно гораздо больше деталей.

Полезные команды: nfsstat

Несколько ранее я рассказывал уже о средствах анализа нагрузки системы по протоколу CIFS, например с помошью команды cifs top. Для анализа статистики нагрузки протокола NFS пригодится команда nfsstat.

В своем обычном виде команда nfsstat показывает общую статистику по всму трафику NFS и RPC, и полезна при настройке и поиске ошибок сетевой передачи. Однако, если вы включите в системных опциях Data ONTAP по умолчанию выключенную опцию nfs.per_client_stats.enable, то вам будет доступна статистика отдельно по каждому клиенту NFS (под клиентом понимается хост, но не пользователь).

Включим учет статистики раздельно по клиентам:

fas1> options nfs.per_client_stats.enable on

fas1> nfsstat –h [ip | hostname] – покажет статистику отдельно по конкретному клиенту

fas1> nfsstat –l – покажет статистику по 256 клиентам по убыванию NFS-активности

Подробнее о команде:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel732_vs/html/ontap/cmdref/man1/na_nfsstat.1.htm

FlexShare - управление приоритетами томов

FlexShare это технология управления приоритетами в обслуживании томов данных, своеобразный квази-QoS (хотя и не QoS в чистом виде). Эта технология входит во все современные версии Data ONTAP, бесплатна, однако сравнительно малоизвестна.
FlexShare задает отноительный приоритет (а не абсолютный, как в “чистом” QoS) обслуживания для томов данных. Если с ее помощью вы зададите пониженный приоритет томам данных, используемым для, например, хранения дистрибутивов, образов виртуальных машин, резервных копий, и прочих данных, время доступа к которым не является для ваших задач критичным, и наоборот, повысите приоритет для томов с базой данных или критичными для бизнеса виртуальными машинами, то контроллер будет распределять свое “внимание” и процессорные “тики” не равномерно, как по умолчанию, а в соответствии с заданными приоритетами. В результате вы сможете несколько улучшить показатели быстродействия для критичных данных.

no FlexShare

no FlexShare


with FlexShare

with FlexShare

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

fas> priority on

Для более детального управления следует воспользоваться командой priority set:

fas> priority set volume vol1 level=high system=low cache=reuse

Эта команда указывает высокий приоритет обслуживания тома vol1 для операций пользователей и приложений, устанавливает для данного тома пониженный приоритет системным задачам его обслуживания, а также задает политику использования кэша с более быстрым сбросом (flush) его содержимого, по сравнению c политикой по-умолчанию.
Уже установленные приоритеты можно посмотреть с помощью команды:
fas> priority show volume

Остальные опции команды priority вы как всегда можете найти во встроенном хелпе и в выводе команды help priority.

Скорость RAID Reconstruction

При выходе из строя жесткого диска система начинает процесс RAID reconstruction. Время его завершения зависит от загрузки системы задачами ввода-вывода и установленного приоритета задачи реконструкции. Это приоритет (вернее степень влияния на производительность системы в целом задачей реконструкции) может быть настроен с помощью системной опции:

fas1> options raid.reconstruct.perf_impact [high | medium | low]

Обратите внимание, эта опция и ее изменение глобально (для всех RAID-групп системы в целом), и, что важно, не работает для уже запустившейся reconstruction. То есть увидеть слишком долгий процесс восстановления, поменять ее на high и ждать, что процесс ускорится, не стоит.

По умолчанию она установлена в medium, и менять ее стоит только если вы в самом деле хорошо представляете зачем вы это делаете.

Недокументированные команды: hammer

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

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

*** WARNING *** Hammer is a system level stress test.
CPU utilization may approach 100 percent
with very high disk IO rate when hammer is run.
This may adversely affect system performance
and may cause loss of filer service.
Hammer is an undocumented, unsuppported command.

usage: hammer [abort|pause|restart|status|
       [-f]<# Runs><fileName><# BlocksInFile> (<# Runs> == -1 runs hammer forever)|
       fill <writeSize> (use all available disk space)]

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

filer1*> hammer -f 5 /vol/vol0/hammer.txt 400
Mon Dec  8 12:32:02 GMT [blacksmith:warning]: blacksmith #0: Starting work.
filer1*> hammer status
blacksmith #0: file /vol/vol0/hammer.txt, 580 KB of 1600 KB writesize 4096 bytes, iteration 1 of 5 – Writing
filer1*> hammer status
blacksmith #0: file /vol/vol0/hammer.txt, 1600 KB of 1600 KB writesize 4096 bytes, iteration 1 of 5 – Writing
filer1*> hammer status
blacksmith #0: file /vol/vol0/hammer.txt, 652 KB of 1600 KB writesize 4096 bytes, iteration 2 of 5 – Writing
filer1*> hammer status
blacksmith #0: file /vol/vol0/hammer.txt, 1600 KB of 1600 KB writesize 4096 bytes, iteration 2 of 5 – Writing
filer1*> Mon Dec  8 12:32:13 GMT [blacksmith:info]: blacksmith #0: No errors detected. Stopping work

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

Недокументированные команды: filersio

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

vol copy или ndmpcopy?

Администратору системы хранения иногда приходится перебрасывать данные с тома на том. Чуть ранее я уже рассказал про один из способов решения, инструменте 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.
20/0.117

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