Archive for the ‘commands’ Category.

Как начать новую жизнь с Clustered Data ONTAP и FCP









Всем привет ! :)

Сегодня мы рассмотрим в подробностях процесс настройки SAN на cDOT с подключением к Cisco MDS.

Как вы знаете из документации, Clustered Data ONTAP требует использования NPIV при работе с Fiber Channel. NPIV расшифровывается как N-Port ID Virtualization, и мы не будем путать эту аббревиатуру с NPV (N-Port Virtualization). Это две разные вещи, хоть и гуглятся бок о бок ;)

NetApp использует NPIV для того, чтобы абстрагироваться от используемого железа на пути от FC HBA до клиентского оборудования. Поскольку мы используем логические интерфейсы – LIF – мы можем не только создавать несколько логических портов на одном физическом порту HBA, но и использовать для них разные WWPN. 

Это особенно удобно при создании зон, FC-зоны создаются с использованием WWPN логических интерфейсов, а подлежащие «железные» порты могут меняться в любой момент. 

Например, возьмем двухнодовый кластер FAS6250, на каждой голове которого мы используем 2 FC-адаптера:

netapp_clus::*> fcp adapter show -fields fc-wwnn,fc-wwpn 

node                 adapter fc-wwnn                           fc-wwpn                  

———-           ——-   ———————–         ———————–  

netapp_clus-01 2a         50:0a:09:80:89:4c:bc:6d  50:0a:09:81:89:4c:bc:6d   

netapp_clus-01 2b         50:0a:09:80:89:4c:bc:6d  50:0a:09:82:89:4c:bc:6d  

netapp_clus-02 2a         50:0a:09:80:8f:ab:bd:cd  50:0a:09:81:8f:ab:bd:cd   

netapp_clus-02 2b         50:0a:09:80:8f:ab:bd:cd  50:0a:09:82:8f:ab:bd:cd  

Мы видим, что адреса портов на LIF’ах отличаются от адресов на физических портах:

netapp_clus::> net int show -vserver vs1   

(network interface show)             

Vserver  Logical                         Status         Network                    Current             Current  Is     

             Interface                   Admin/Oper Address/Mask               Node                Port       Home 

————————————————————————————————————— 

vs1        

             netapp_clus-01_fc_lif_1 up/up    20:04:00:a0:98:21:30:55 netapp_clus-01    2a      true             

             netapp_clus-01_fc_lif_2 up/up    20:05:00:a0:98:21:30:55 netapp_clus-01    2b      true

             netapp_clus-02_fc_lif_1 up/up    20:06:00:a0:98:21:30:55 netapp_clus-02    2a      true 

             netapp_clus-02_fc_lif_2 up/up    20:07:00:a0:98:21:30:55 netapp_clus-02    2b      true

В этом логе отображена конфигурация Vserver’а, на котором поднято 4 LIF’а. Они привязаны к физическим портам и имеют собственные виртуальные WWPN. Если в будущем нам потребуется заменить карточку HBA в слоте 2, идентификаторы портов на LIF’ах при этом не изменятся, и нам не придется переделывать зоны.

Переходим к следующему звену нашей сети - FC-свитчам. В данном проекте мы используем Cisco Nexus 5020, и для работы с cDOT нам понадобится включить на нем NPIV.

nxs5020-vcloud1# conf t

nxs5020-vcloud1(config)# feature npiv

Проверяем себя на адекватность:

nxs5020-vcloud1# show feature | i npiv 

npiv                  1         enabled

Проверяем, что у нас настроены VSAN’ы zoneset’ы и зоны

В этом примере мы используем VSAN 101, и у нас настроен  один zoneset, с одной zone. 

Пример настройки zoneset:

nxs5020-vcloud1# show zoneset brief vsan 101 

zoneset name test-zoneset vsan 101   

  zone test-zone

Пример настройки zone:

nxs5020-vcloud1# show zone vsan 101 

zone name test-zone vsan 101   

  fcalias name esxtest-1-vmhba2 vsan 101     

  pwwn 20:00:00:25:b5:00:00:1a      

  fcalias name netapp_clus-01_fc_lif_2 vsan 101     

  pwwn 20:05:00:a0:98:21:30:55

Для простоты чтения конфига, алиасы в этом примере названы так же, как и интерфейсы на Vserver.

Теперь, когда у нас настроены свитчи и есть связность между СХД и серверами, нам осталось настроить LUN’ы и отдать их хостам. 

Для этого нужно:

создать initiator group

добавить WWPN’ы хостов в эту группу

Создать LUN

Привязать LUN к этой igroup.

При создании igroup нам нужно правильно указать тип ОС. Это, в частности, поможет системе правильно использовать ALUA. 

netapp_clus::> igroup create -vserver vs1 -igroup esxtest_fcp_igrp  -protocol fcp -ostype vmware

После этого мы можем добавить в группу наши инициаторы:

netapp_clus::> igroup add -vserver vs1  -igroup esxtest_fcp_igrp –initiator 20:00:00:25:b5:00:00:1a

И в результате мы получаем настроенную igroup:

netapp_clus::> igroup show -vserver vs1 

Vserver   Igroup              Protocol  OS Type   Initiators 

——————————————————————————— 

vs1       esxtest_fcp_igrp  fcp         vmware    20:00:00:25:b5:00:00:1a

Осталось совсем немного – создать LUN (обязательно правильно указать тип ОС, иначе мы обеспечим себе потенциальную потерю производительности):

netapp_clus::> lun create -vserver vs1 -path /vol/fcp/test -size 250g -ostype vmware

Привязать его к igroup:

netapp_clus::> lun map -vserver vs1 -path /vol/fcp/test -igroup esxtest_fcp_igrp

И проверить, что мы нигде не ошиблись:

netapp_clus::> lun show -vserver vs1 

Vserver   Path                           State   Mapped   Type           Size 

—————————————————————————– 

vs1         /vol/fcp/test                online  mapped   vmware      250GB

netapp_clus::> lun mapped show -vserver vs1 

Vserver    Path                     Igroup                LUN ID  Protocol 

———————————————————————– 

vs1          /vol/fcp/test          esxtest_fcp_igrp  0          fcp

Вот и все ! Новый LUN готов к использованию нашим ESX-хостом.


pktt: встроенный сборщик ethernet dump

Внутри Data ONTAP зачастую находится много полезных штук, к сожалению, часто малоизвестных “рядовому админу”, особенное если “все и так работает”.
Одна из таких архиполезных для траблшутинга сети штук - встроенный сборщик дампа пакетов на сетевом интерфейсе. Особенно полезно то, что формат собираемого дампа позволяет напрямую открывать его в популярнейшем инструменте анализа дампов - Wireshark.
Если вы настроили CHAP authentification в iSCSI, и что-то пошло не так, или что-то странное творится при доступе к файлам по SMB, то лучший способ - собрать дамп и посмотреть что происходит в сети на стороне стораджа.

Для этого выясним сперва, на каком интерфейсе нас будет интересовать ethernet-трафик.

netapp> ifconfig -a

e0a: flags=0xe48867 mtu 1500
inet 10.10.10.140 netmask 0xffffff00 broadcast 10.10.10.255
ether 00:0c:29:89:3f:3c (auto-1000t-fd-up) flowcontrol full
e0b: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:46 (auto-1000t-fd-up) flowcontrol full
e0c: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:50 (auto-1000t-fd-up) flowcontrol full
e0d: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:5a (auto-1000t-fd-up) flowcontrol full
lo: flags=0×1b48049 mtu 9188
inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1
losk: flags=0×40a400c9 mtu 9188
inet 127.0.20.1 netmask 0xff000000 broadcast 127.0.20.1

Запустим команду pktt, указав ей собирать дамп на заданном интерфейсе, и маркировать файл дампа датой сбора.

netapp> pktt start e0a -d /etc/log
e0a: started packet trace

netapp> pktt status
e0a: Packet tracing enabled; packets truncated at 1514 bytes.
e0a: Trace buffer utilization = 2% of 1048320 bytes, 258 packets
e0a: 0 bytes written to file /etc/log/e0a_20131108_173928.trc
e0a: Currently tracing to file /etc/log/e0a_20131108_173928.trc
e0a: 258 packets seen; 0 packets dropped; 24936 total bytes seen

lo: Packet tracing enabled; packets truncated at 1514 bytes.
lo: Trace buffer utilization = 99% of 130816 bytes, 1011 packets
lo: 1387 packets seen; 0 packets dropped; 160568 total bytes seen

losk: Packet tracing enabled; packets truncated at 1514 bytes.
losk: Trace buffer utilization = 99% of 130816 bytes, 282 packets
losk: 40901 packets seen; 0 packets dropped; 21761277 total bytes seen

Когда нужный интервал сбора пройден, остановим pktt.

netapp> pktt stop e0a
e0a: Tracing stopped and packet trace buffers released.
Fri Nov 8 17:42:25 EST [sim81:cmds.pktt.write.info:info]: pktt: 280 packets seen, 0 dropped, 32046 bytes written to /etc/log/e0a_20131108_173928.trc.

У нас по заданному пути окажется файл с дампом, который мы можем скопировать на машину с Wireshark.

Теперь откроем файл .trc, прямо в Wirrshark, и приступим к знакомому процессу разбора в этом замечательном инструменте.

Соответствие команд 7-mode и C-mode

Если вам в скором времени предстоит переход на Clustered Data ONTAP, или если вы админ системы хранения, хорошо знакомый с Data ONTAP 7-mode, которому предстоит администрировать Cluster-mode, то рекомендую посмотреть документ, недавно опубликованный в библиотеке NetApp:

Clustered Data ONTAP® 8.2
Command Map for 7-Mode Administrators

В нем в таблицу собраны команды Cluster-mode, соответствующие, по выполняемым действиям, командам 7-mode. То есть если вы знаете как, допустим, создать том на aggregate в 7-mode, и не знаете какой командой это делается в Clustered ONTAP, то вот этот документ вам поможет.

Брать можно здесь: https://library.netapp.com/ecm/ecm_download_file/ECMP1196780

Замена диска на конкретный из 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

fpolicy – простая блокировка файлов по расширению в NAS

Если вы используете систему NetApp как NAS, то есть как файловое хранилище по протоколу CIFS, то вы можете настроить в ней несложную блокировку нежелательных файлов по расширению (это конечно не сработает при смене расширения, но уже само по себе хоть что-то). Механизм этот назывется fpolicy и описан в документации.

filer> fpolicy create Media screen
File policy Media created successfully.
filer> fpolicy ext inc set Media .mp3
filer> fpolicy monitor set Media -p cifs -f create,rename
filer> fpolicy options Media required on
filer> fpolicy enable Media -f
Thu Feb 10 14:12:52 CST [hounas04: fpolicy.fscreen.enable:info]: FPOLICY: File policy Media (file screening) is enabled.
File policy Media (file screening) is enabled.
filer>

Не забудьте также отдельно включить fpolicy в целом, установив соответствующую опцию системных настроек

filer> options fpolicy.enable on

Далее можно посмотреть на установленные параметры и статистику работы.

filer> fpolicy show Media

File policy Media (file screening) is enabled.

No file policy servers are registered with the filer.

Operations monitored:
File create,File rename
Above operations are monitored for CIFS only

List of extensions to screen:
.MP3

List of extensions not to screen:
Extensions-not-to-screen list is empty.

Number of requests screened          :  0
Number of screen failures            :  0
Number of requests blocked locally   :  0

Долгожданный EMC Celerron грядет :)

Продукт, о котором долго говорили, результат скрещения жабы с мотоциклом Celerra и CLARiiON, настоящего (еще более настоящего;) Unified Storage от EMC, базирующегося на файловой системе shenanigan-ского блочного стораджа – VNX.

Да уж, давайте, давайте, заждались (потирает ручонки), наконец-то посоревнуемся за пользователей всерьез, без глупого лечилова про “настоящий fibre channel”.

Источник: http://www.theregister.co.uk/2011/01/04/emc_vnx_unified_storage/

Подробности, по всей видимости - 18.01.

PS. Интересно, съест ли свою шляпу Чак Холлис? ;)

UPD: Подробности нашлись на SearchStorage

UPD: Да, вернулся в эфир чуть раньше, сначала предполагал запостить это 17, в понедельник, накануне официального анонса, но так как прошла утечка, и народ в интернетах загомонил, решил не ждать, да и вам интереснее.

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

Дисконтный код от NetApp на VMworld 2010

В блоге Vaughan Stewart-а, “главного блоггера NetApp по VMware” найдена полезная информация. NetApp предлагает специальный скидочный код для покупки full conference pass for individuals для VMworld в San Francisco, а также VMworld в Copenhagen. С дисконтом NetApp цена снижается с $1745 до $1495 (USD) и с € 1150 до € 950 (Euro).

Использовать код можно при регистрации на VMworld по следующему адресу:

http://www.vmworld.com/registration.jspa?sponsorCode=NAPP

Просто введите один из этих кодов при завершении покупки билета:

San Francisco code: NETAPP_EB_US2010
Copenhagen code: NETAPP_EB_EMEA2010

Дополнение: Как пишет Nick Howell, дисконт NetApp работает и “задним числом”, то есть, если вы уже приобрели билет за полную цену, вы можете получить вашу скидку, послав запрос по email: VMworld2010Registration@vmware-events.com.

Что есть что в выводе команды 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 

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

21/0.167

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