about NetApp

В предыдущей статье я показал, как поставить виртуальную машину, в виде которой сейчас идет симулятор 8.0.1 на сервер VMware ESX. А сейчас попробуем начать с ним работу.

Как я уже рассказывал в предыдущем посте, Data Ontap Simulator это виртуальная машина, в которой работает версия Data ONTAP 8 для выполнения в среде VM. Data ONTAP 8 базируется на OS FreeBSD, однако, вопреки распространенному (ошибочному) мнению, Data ONTAP 8 это НЕ FreeBSD. Это даже не программа под FreeBSD. Это самостоятельная OS, которая использует FreeBSD как загрузчик своего kernel space code, а также использует некоторые ее ресурсы, например driver model, и драйвера оборудования. Ситуация была примерно та же, что с гипервизором VMware ESX-не-i, если вы помните, там сперва грузился RedHat, под которым затем запускался как модуль собственно ESX, который уже Linux не являлся. Именно этим объясняется то, что мы в прошлой статье создали VM типа “FreeBSD 64-bit”, действительно, сперва VM загружается с использованием loader FreeBSD, а затем использует ее драйверную модель для внешних устройств.

Симулятор, как я уже рассказывал выше, это полноценная версия Data ONTAP, за некоторым исключением: установлено ограничение по поддерживаемой емкости, не работает протокол FC (но работает iSCSI) и, в настоящий момент, реализована только одноконтроллерная конфигурация. Но для экспериментов и обучения этого будет вполне достаточно.

Давайте, для начала, отключим на симуляторе Autosupport. Симулятор это экспериментальная площадка, и лучше будет не беспокоить поддержку NetApp странными сообщениями, которые будет при наших экспериментах посылать”в центр” служба Autosupport. Войдя в консоль даем команду:

options autosupport.enable off

Штатным образом Simulator приходит с набором из 28 “как-бы дисков” размером 1GB (как я уже сказал, для экспериментов этого объема достаточно). Изначально, только 3 диска назначены (assigned) контроллеру, и на них создан root volume на RAID-DP. Остальные диски помечены как unassigned. Назначим оставшиеся диски нашему симулятору:

disk assign all

Теперь добавим ключи-лицензии. Эти ключи предназначены только для симулятора, и не будут работать на физической системе. Можно установить только то, что используется на вашей продакшн-системе, или поставить дополнительные лицензии, чтобы посмотреть “что это и как работает”, или же просто все, и экспериментировать со всеми возможными фичами.

• a_sis MTVVGAF
• cifs DZDACHD
• disk_sanitization PZKEAZL
• http NAZOMKC
• flex_clone ANLEAZL
• iscsi BSLRLTG
• multistore NQBYFJJ
• nearstore_option ELNRLTG
• nfs BQOEAZL
• smdomino RKBAFSN
• smsql HNGEAZL
• snapmanagerexchange BCJEAZL
• snapmirror DFVXFJJ
• snapmirror_sync XJQIVFK
• snaprestore DNDCBQH
• snapvalidator JQAACHD
• sv_linux_pri ZYICXLC
• sv_ontap_pri PVOIVFK
• sv_ontap_sec PDXMQMI
• sv_unix_pri RQAYBFE
• sv_windows_ofm_pri ZOFNMID
• sv_windows_pri ZOPRKAM
• syncmirror_local RIQTKCL

Лицензионный ключ – это 7 заглавных букв после имени функции. Для того, чтобы ввести лицензионный ключ дайте команду:

license add XXXXXXX

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

Если же мы собираемся оставить 3 диска root vol в отдельном aggregate, то просто создавайте новый aggregate на оставшихся 25 дисках. Однако тут имеет смысле сделать небольшие изменения в опциях системы. Дело в том, что размер RAID-группы по умолчанию в Data ONTAP равен 16 дискам (а максимальный для дисков FC, SAS и виртуальных дисков симулятора – 28). Если вы создаете большой единый aggregate на всех 25 дисках, то, при установленном размере RAID-группы равной 16, он создастся так:

Сперва будет взято 16 дисков, из которых 2 будут RAID-DP parity и dparity, а остальные 14 будут data в RAID-группе rg0. Затем на оставшихся будет создана вторая RAID-группа (rg1), из оставшихся 9 дисков, которые, в свою очередь, станут двумя parity и 7 data. В дальнейшем, если в aggregate добавляются новые диски они добавляются в “неполную” RAID-группу, пока она не достигнет заданного в опциях размера в 16 дисков, а следующие создадут еще одну новую “неполную” группу.

Логично было бы, особенно на небольшом числе дисков, не полагаться на такую автоматику, а самостоятельно расчитать и создать RAID-группы, по возможности равного размера. То есть, с точки зрения порядка, аккуратности (да и производительности) вариант 12+12+1 hot spare будет лучше, чем 16+8+1hs. А в нашем случае мы поступим еще лучше, мы просто увеличим заданный размер RAID-группы до максимума (28), или, хотя бы до 25. Тогда все наши диски поместятся в одну группу. Дадим в консоли команду:

aggr options aggr1 raidsize 28

Теперь добавим оставшиеся unassigned диски в созданный aggr0

aggr add aggr1 24

Мы оставим один диск под spare, это требование Data ONTAP. Для того, чтобы в логах не валились сообщения о нехватке spares, проверьте значение опции:

options raid.min_spare_count 1

Здесь 1 – количество spare для данного контроллера. Одного будет вполне достаточно, а при количестве дисков более 16 поставить 0 система не даст.

Имеет смысл также уменьшить резерв под snapshots уровня aggregate. Что это я уже тоже писал в блоге, есл вкратце и в двух словах – это вам не надо, это для Metrocluster, синхронной репликации, и может помочь для ремонта сильно поврежденной WAFL. Если у вас этого всег нет, то можете этот резерв убрать и выключить расписание создания их.

snap reserve -A aggr1 0
snap sched -A aggr1 0

Отдельно отмечу, это ТОЛЬКО для специальных, внутренних снэпшотов уровня aggregate, на обычные и привычные пользовательские снэпшоты уровня volume и файлов это не влияет, они буду работать по-прежнему, и вы по-прежнему сможете их использовать.

Вот теперь все готово к созданию томов и экспериментам. Можете начать из консоли, или же подключить к симулятору System Manager, если вам в GUI привычнее. Симулятор, повторюсь, работает и ведет себя идентично реальной системе хранения (за вычетом FC, SnapLock и ограничения по объему хранения). К нему можно подключить любой софтовый продукт (System/Operations/Protection/Provision Manager, SnapManager, VSC), настроить на него репликацию, использовать его как получатель (secondary) или источник (primary) для SnapVault, и так далее.

В основу этого поста легла статья http://mtellin.com/2011/01/03/getting-started-with-the-netapp-ontap-8-0-1-simulator/.

В следующей статье я покажу, как можно добавить диски симулятору, сверх предустановленных 28, а также добавить serial console или изменить предустановленный серийный номер и SystemID, если вы планируете использовать несколько разных симуляторов в одной сети.

Как вы знаете, каждый контроллер в HA-паре системы хранения NetApp владеет собственным набором дисков. Когда-то, много лет назад, еще до систем серии 3000, использовался так называемый hardware ownership, при котором привязка к контроллеру происходила “физически”, на уровне полки и петли FCAL. Начиная с 3020 в системах NetApp применяется так называмый sowtware ownership, при котором владелец диска назначается согласно WWN этого диска, и появилась возможность более гибко назначать владельца и разделять диски между контроллерами. Например, можно даже имея одну дисковую полку произвольно назначить диски из нее разным контроллерам.

Иногда же возникает задача перераспределить диски, например передать часть дисков от одного контроллера-владельца другому.

Как это сделать показывает статья в Knowledge Base

KB ID: 1011998 Version: 3.0 Published date: 01/13/2011

Описание

Приведенная процедура смены контроллера-владельца диска применима к любой системе, поддерживающей software-based ownership (на сегодняшний день все выпускаемые системы используют software-based ownership).

Процедура

В разбираемом примере, FilerA владеет spare-диском, который мы хотим передать контроллеру FilerB.

1. Получим Disk ID

FilerA> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 6 FC:B - FCAL 10000 68000/139264000 69536/142410400

2. Перейдем в режим повышенных привилегий (advanced mode)

FilerA*> priv set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.

3. Удалим текущего владельца диска

FilerA*> disk remove_ownership 0b.22
Volumes must be taken offline. Are all impacted volumes offline(y/n)?? yes
FilerA*> Sat Jan 14 17:46:42 GMT [FilerA: raid.config.spare.disk.missing:info]: Spare Disk 0b.22 Shelf 1 Bay 6 [NETAPP X272_HJURE073F10 NA14] S/N [xxxxxx] is missing.

Внимание:

• Команду disk remove_ownership можно дать сразу на группу дисков, разделив их имена пробелами, disk remove_ownership 6c.64 6c.65 6c.66 снимет владельца со всех перечисленных дисков.
• В случае систем серии 30×0, проверьте установку опции options disk.auto_assign. Если она установлена в on, то когда вы снимете владельца с дисков, система автоматически назначит их назад. По этой причине убедитесь, что перед началом операции эта опция установлена в off. Можно ее включить назад, после передачи диска контроллеру.
• Сообщение volumes must be taken offline это предохранительная мера, вы должны подтвердить, что не удаляете диск с данными из активного тома/aggregate. В данном примере мы перемещаем spare-диск, а не диск, уже назначенный в RAID.

4. Подключаемся к контроллеру FilerB и переходим в advanced mode

FilerB*> priv set advanced
Warning: These advanced commands are potentially dangerous; use
them only when directed to do so by NetApp
personnel.

5. Назначаем нового владельца

FilerB*> disk assign 0b.22
Sat Jan 14 17:47:32 GMT [FilerB: diskown.changingOwner:info]: changing ownership for disk 0b.22 (S/N xxxxxx) from unowned (ID -1) to FilerB (ID xxxxxx)

6. Проверяем, что диск теперь spare у нового контроллера

FilerB*> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 8 FC:B - FCAL 10000 68000/139264000 69536/142410400

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

Несколько слов о такой теме, которая, как я заметил, часто вызывает замешательство и непонимание.

Для начала кратко о том, что такое aggregate и как они соотносятся с RAID-группами (например для тех, кто тут впервые, пришел из поисковика, и еще не разглядел, что тут порядка двух сотен постов, в которых о многом написано не по разу).

Aggregate это “уровень виртуализации” для физических дисков в системах хранения NetApp, это своеобразный виртуальный мета-том, на котором можно размещать уже непосредственно адресуемые пользователем тома, сетевые шары для NAS или LUN для SAN. Использование такого уровня виртуализации, например, позволяет равномерно распределять операции ввода-вывода по всем нижележащим дискам, увеличивая общую произвдительность, а также с легкостью увеличивать и уменьшать в объемах лежашие поверх него ресурсы – тем самые тома, LUN, сетевые шары, и так далее. Aggregate это одна из самых полезных и эффктивных “фич” систем хранения NetApp.

Однако вопросы возникают вокруг темы создания, и дальнейшего увеличения самого aggregate, путем добавления в его структуру физических дисков. Как это делать правильно, и почему часто это проделывается неправильно – об этом сегодня и пойдет речь.

В физической иерархии aggregate находится на уровне, на котором в традиционных системах хранения находится volume. Ниже него лежат непосредственно физические диски, на которых организованы RAID-группы. Каждый aggregate может занимать одну или, обычно, несколько сконкатенированных RAID-групп, причем размер этих групп в количестве дисков может быть разным. NetApp рекомендует, если нет каких-то особых причин, создавать минимально возможное количество максимально “длинных” aggregate. Это повышает производительность ввода-вывода всех лежащих на них томов и LUN.

Для OS Data ONTAP семейства G7 (версий 7.х.x) максимальный размер aggregate был равен 16TB.
В версиях семейства G8 (8.x.x), для нового формата, под названием 64-bit aggregate, его размер варьируется в зависимости от мощности контроллера, и достигает 100TB для систем FAS6080, самых мощных на сегодня.

Подходить к созданию aggregate следует очень вдумчиво и аккуратно, так как то, что aggregate это фундамент в основе всех вышележащих структур, накладывает на его создание большую ответственность. Просчеты при создании aggregate будут влиять на все использующие его структуры выше. Кроме того, добавленные в aggregate диски нельзя из него извлечь не уничтожая весь aggregate вместе со всеми вышележащими структурами – LUN-ами, томами и сетевыми шарами, вместе со всем их содержимым.

Для того, чтобы создать aggregate, надо отдать команду в командной строке админской консоли, или запустить мастер в FilerView web-GUI. И там и там от нас потребуется задать величину RAID-групп.

Какой же должна быть величина этих RAID-групп в количестве дисков?
На сегодня, максимальный размер RAID-групп для дисков FC и SAS равен 28 дискам (то есть, например, для RAID-DP это 26 дисков данных и 2 диска parity), а для дисков SATA – 16 дисков (в версии 8.0.1 будет увеличена до 20).
Однако “рекомендованные величины”, выбранные “по умолчанию”, несколько меньше, это 16 и 14 дисков соответственно. (Все для типа RAID – RAID-DP).

“Если не знаете что делать – не делайте ничего” гласит по легенде главное правило в учебнике по пилотированию самолетов. Последуем ему и мы. Если вы не знаете, какие параметры при создании aggregate нужно выбрать, например размер RAID-групп – рекомендую вам оставить параметры по умолчанию.

Однако какие параметры стоит рассмотреть в том случае, если мы хотим разобраться и создать максимально оптимизированную структуру RAID?

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

То есть  между вариантами распределения 26 дисков в виде: 22 диска (RAID-DP 20+2) и 4 (RAID-DP 2+2) или же 13 и 13 (RAID-DP 11+2), следует предпочесть второе, несмотря на то, что в первом случае одна из групп будет значительно крупнее, второй вариант будет иметь в целом гораздо более стабильное быстродйствие в IOPS.

Создавать группы равного размера в принципе дело несложное в том случае, если количество дисков, которыми мы располагаем, заранее определено. Но что делать, если нам понадобится добавить дисков в aggregate, причем количество добавляемых дисков не 13, а заметно меньше, то есть создать из добавляемых дисков целую новую RAID-группу и растянуть на нее aggregate у нас не выйдет?

Допустим, у нас есть 6 дисков, на которые мы хотим увеличить наш aggregate, лежащий на двух группах RAID-DP по 13 дисков каждый.

У нас есть два варианта:

Вариант 1. Мы може просто, не особо думая, добавить эти диски командой aggr add <aggrname> 8a.1, 8a.2, 8a.3 (и прочие необходимые нам диски), или соответствующим GUI-мастером. Если ранее мы задали, что наш aggregate имеет размер RAID – 13 дисков, то вновь добавленные диски образуют третью RAID-группу rg2 (вдобавок к имещимся rg0 и rg1) размером 6 дисков (RAID-DP 4+2). Если в дальнейшем мы будем добавлять в этот aggregate еще дисков, то диски автоматически станут наращивать эту группу, пока она не достигнет размера 13 дисков, после чего начнется новая группа rg3.
Результат в целом простой, но не совсем для нас желательный. Для системы с высокими требованиями по производительности мы можем столкнуться с ситуацией, когда производительность ввода-вывода системы будет заметно колебаться в зависимости от того, какая порция данных на каком RAID окажется.
Хотя этот эффект часто не слшком ярко выражен, и часто переоценивается, но мы хотели бы его избежать.

Вариант 2. Несколько более хитрый. Как я уже сказал выше, мы не можем вывести уже введенные в aggregate диски. Также мы не можем уменьшить уже установленный в aggregate размер RAID-групп (ведь на дисках уже могут располагаться данные). Однако мы можем увеличивать размер RAID-группы в параметре входящих в нее дисков, вплоть до максимального размера, равного 28 для SAS/FC и 16/20 для SATA. Как вы уже знаете, особенностью использованного у NetApp типа RAID, как RAID-4, так и RAID-DP, является то, что добавление в них новых дисков и увличение RAID производится без необходимости полного перестроения RAID, как это привычно при использовании, например, RAID-5. Новый диск добавляется в RAID-4 или RAID-DP, и сразу же на него можно писать, расширив RAID-группу на размер этого диска.

Начнем с того, что зададим в свойствах aggregate размер его RAID-групп больше, чем было установлено ранее (13), в случае необходимости добавления 6 дисков зададим их величину в 16 дисков.

fas1> aggr options aggr1 raidsize 16

После выполнения этой команды мы получаем тот же aggregate, только теперь вместо двух заполненных RAID-групп на 13 (11d+2p) дисков, мы имеем две неполных RAID-группы по 13 дисков (11d+2p), с максимальным размером 16 (13d+2p). Слдующей командой мы добавляем 6 наших дисков в aggr1:

fas1> aggr add aggr1 8a.1, 8a.2, 8a.3, 8a.4, 8a.5, 8a.6

Логика добавления дисков неполные RAID-группы проста. Если в aggregate имеются неполные группы, то сперва системе следует заполнить эти группы до максимального зачения, начиная с самой младшей, затем переходя к следующей. Таким образом диски 1, 2, 3 добавятся RAID-группе rg0, а 4, 5, 6 – группе rg1. При необходимости можно и вручную задать какой диск в какую группу будет добавляться.

В итоге мы добились нужного нам. Мы добавили 6 дисков, расширили aggregate, и избежали создания неравномерно разбитых RAID в этом aggregate. Обратите внимание, что все эти действия по изменению размеров RAID-группы и добавлнию дисков осуществляются “на ходу”, не прерывая работы системы, перестроения RAID не требуется, и емкость добавленных дисков становится немеленно доступна системе.

Когда я, еще в 2007 году писал небольшой обзор программы IOmeter, которой как раз незадолго до этого измерял показатели производительности некоторых моделей систем хранения NetApp, я не предполагал, что эта небольшая заметка станет с той поры “бестселлером” блога. Неожиданно для себя я обнаружил, что подробного описания работы с таким популярным средством тестирования и измерения на русском языке просто нет. Не так давно коллега track написал гораздо более подробное описание настройки и работы с IOmeter, и c его любезного согласия, я публикую этот текст у себя в блоге.

Программа IOmeter - это популярный тест для тестирования производительности дисковой подсистемы и локальной сети. Тест является “100% синтетикой”.
К сожалению, некоторая неочевидность процесса тестирования в нем, устаревший внешний вид, отсутствие полноценного онлайн-хелпа, и документации, а также русскоязычного описания, часто вызывают затруднения при попытках его использовать. Также в интернете практически отсутствует подробное описание методики работы с ним, и описание используемых терминов и фич.
Continue reading ‘Тестирование с помощью программы IOmeter’ »

Вы уже знаете, что системы хранения NetApp - мультипротокольны. В зависимости от введенных лицензий они позволяют работать с данными по протоколам CIFS и NFS (как NAS), а также по "блочным" протоколам, таким как FC, FCoE и iSCSI (IP-SAN). Но немногие знают, что кроме перечисленных протоколов, данные с NetApp также могут быть также доступны по протоколам HTTP (WebDAV) и FTP.

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

> options ftpd

Вы увидите список опций, относящихся к ftpd:

Как вы видите, изначально ftpd остановлен (ftpd.enable off),вы можете включить его командой options ftpd.enable on.

Далее вы можете установить параметр ftpd.dir.override на директорию, которую вы хотите отдавать по FTP (options ftpd.dir.override /vol/vol1/my-home/my-shared-directory/). Теперь можно попробовать войти с помощью ftp-клиента и скорее всего вы увидите что-то типа 530 Login incorrect - User has no home directory., если директория, указанная в ftpd.dir.override это не корень тома. Это может означать, что пользователь, которым вы входите, не имеет так называемых traversal rights для директории, отдаваемой по FTP, поэтому вам нужно исправить это, либо если вы используете Data ONTAP 7.3.0 или старше, то в можете включить опцию ftpd.bypass_traverse_checking (options ftpd.bypass_traverse_checking on).

В заключение хочу напомнить, что протокол ftp это довольно простой и даже примитивный, в особенности с точки зрения безопасности данных, протокол. Все логины и пароли, а также содержимое файлов данных пересылается "открытым текстом", а реализованные в более современных и совершенных серверах ftp методы безопасного подключения и передачи данных в имеющемся в Data ONTAP ftpd не используются. Кроме того, надо понимать, что протокол ftp, как и сервер ftpd в системах NetApp никогда не планировался для напряженной и интенсивной работы, и, наверняка, не тестировался как следует ни на безопасность, ни на стабильность работы, играя сугубо вспомогательную роль, поэтому организовывать на нем "рапидшару", открытую во внешний интернет, наверное все же не стоит.

Источник: http://www.m4r3k.org/english/netapp/ftp-services-on-netapp/

Одной из ошибок настройки при работе кластерной системы NetApp FAS является проблема подключения к LUN через “неродной” для этого LUN-а контроллер.

Кластер контроллеров FAS работает таким образом, что каждый LUN имеет некий preferred path для доступа, будучи “привязанным” к какому-то из контроллеров кластерной пары.

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

Этот процесс снижает производительность, нагружает оба контроллера, загружает ненужным трафиком кластерный интерконнект, и ухудшает responce time и latency, поэтому работы через “чужой” узел кластерной пары следует избегать.

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

1. Определите, к какому из LUN доступ осуществляется через порт FCP target партнерской (“чужой”) ноды.
   a. lun stats -o  (LUN STATISTICS)
2. Определите какой из хостов получает доступ к этому LUN через канал партнерской ноды
   a. lun config_check -A  (LUN CONFIG CHECK)
   b. lun show -v  (LUN CONFIGURATION)
   c. igroup show -v  (INITIATOR GROUPS)
3. Определите порт FCP target основной ноды кластера, который должно использовать для доступа к этому LUN.
   a. fcp show cfmode  (FCP CFMODE)
   b. fcp show adapters  (FCP TARGET ADAPTERS)
4. Проверьте соединение инициатора хоста с основным портом FCP target и конфигурацию MPIO на хосте.
5. Убедитесь, что доступ по партнерскому пути вместо основного прекращен на обоих узлах кластера.
   a. sysstat -b 1

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

Оригинал текста, на основе которого сделан пост взят там: 
http://ibmnseries.blog.com/2009/10/13/partner-path-misconfigured/

Сайзинг под базы Oracle есть критически важный параметр для создания системы хранения достаточной производительности. Сбор данных perfstat* и Oracle STATSPACK позволит выбрать правильно сконфигурированную систему хранения NetApp, как в плане размера, так и производительности.

Важно помнить несколько вещей, когда вы собираете статистику системы:

• Собирайте данные, когда система под большой нагрузкой
• Собирайте данные со всех хостов инфраструктуры
• Собирайте данные в perfstat и STATSPACK за один период времени

Установка Oracle STATSPACK.

STATSPACK это утилита диагностики произвдительности СУБД, которая доступна начиная с Oracle8i. STATSPACK это дальнейшее развитие утилит BSTAT и ESTAT. Рекомендуется установить timed_statistics в true. Для установки STATSPACK выполните следующие шаги:

1. Создайте PERFSTAT Tablespace:

SQL> CREATE TABLESPACE statspack
DATAFILE ‘/path_to_file.dbf’ SIZE 200M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K
SEGMENT SPACE MANAGEMENT AUTO
PERMANENT
ONLINE;

2. Запустите catdbsyn.sql и dbmspool.sql как SYS из SQLPLUS

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/dbmspool.sql

3. Запустите скрипт

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/spcreate

Можете начинать пользоваться Oracle STATSPACK.

Сбор Oracle Statspack с помощью Perfstat с хоста Unix.

Как я могу собирать данные Oracle Statspack и Perfstat одновременно?

Для Perfstat версии 6.28 или позднее мы можем собирать данные Oracle Statspack из Perfstat используя единую команду Perfstat. Это работает для версии perfstat под unix, и не работает для версии perfstat под Windows.

Небольшая выжимка их манов к Perfstat:

Требования:

1. Perfstat может собирать данные Oracle STATSPACK только с одного хоста.
2. Инстанс Oracle должен быть запущен до того, как будет вызван Perfstat.
3. Используйте флаг -o чтобы передать специфические опции statspack в perfstat.

Опции и значения по умолчанию:

oracle_host=`hostname`
sqlplus=”sqlplus”
oracle_login=”perfstat/perfstat”
runas=”"
sysdba=”false”

-oracle_host - умолчание для localhost, может быть одним из хостов, определенных с помощью -h из команд perfstat

-sqlplus - может быть использован для того, чтобы определить абсолтный путь к команде ’sqlplus’

-runas - может использоваться для запуска sqlplus от имени другого пользователя (то есть пользователь Unix, где установлен Oracle, обычно не root.)

-sysdba - может использоваться для подключения к oracle как sysdba, игнорируя параметр oracle_login. Ключ sysdba вводит следующие команды в логин к sqlplus:

• a. sqlplus /nolog
• b. connect / as sysdba.

Примеры:

perfstat.sh -a oracle
perfstat.sh -h host1 -a oracle -o oracle_host=host1
perfstat.sh -h host1 -a oracle -o oracle_host=host1,sqlplus=/oracle/bin/sqlplus/
perfstat.sh -a oracle -o oracle_login=user/pass
perfstat.sh -a oracle -o runas=oracle,sysdba=true

Более сложные примеры:

perfstat.sh -a oracle -t 5 -i 5 -f filer -o runas=oracle, sysdba=true >/opt/perfstat.out

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

Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:

• a. sqlplus /nolog
• b. connect / as sysdba.

Еще почитать:
http://www.akadia.com/services/ora_statspack_survival_guide.html
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9096
http://www.dba-oracle.com/art_statspack.htm
http://www.datadisk.co.uk/html_docs/oracle/awr.htm

Взято тут:
http://blogs.netapp.com/databases/2009/07/gathering-oracle-statspack-data-for-netapp.html

* perfstat - собственная утилита - shell-script NetApp для сбора статистики, может быть скачана с вебсайта NOW: http://now.netapp.com/NOW/download/tools/perfstat/

Многие пользователи 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

Итак, если я вас убедил взять и попробовать использовать дедупликацию, то сделать это можно разными путями. Например таким:
Допустим лицензия на дедупликацию получена и введена.
Включить ее можно любым из доступных для управления системой хранения способов, например через командную строку. Но давайте посмотрим как это сделать с помощью нового System Manager-а, о котором я рассказывал совсем недавно. System Manager это приложение администрирования систем хранения NetApp, в виде MMC-оснастки (Microsoft Management Console) для любой Windows-системы.
Вот так включается дедупликация для тома, при его создании:

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

Страница управления томами также имеет средства запуска процесса вручную, например немедленно.

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

Ну и, наконец, если у вас используется VMware, и вы выбрали для хранения его датастора том по NFS, о преимуществах такого решения я много писал, то для такого случая есть специальный “мастер”.

Напомню, что NetApp гарантирует не менее чем двукратное снижение используемой емкости хранения, при использовании дедупликации и thin provisioning-а для систем VMware.