about NetApp

Рассмотрим еще одну полезную команду для глубокой диагностики, позволяющую находить и анализировать проблемы канала передачи данных от диска к контроллерам на системах, использующих интерфейс FC к дискам. Это системы с полками DS14, которые постепенно заменяются на дисковые полки, работающие по SAS, в новых моделях FAS, но все еще широко распространенные в продакшне.

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


na_fcstat - Fibre Channel stats functions

Формат:
fcstat link_stats [ adapter number ]
fcstat fcal_stats [ adapter number ]
fcstat device_map [ adapter number ]

Continue reading ‘Оптимизация производительности. Часть 4. fcstat’ »

Приходящим с opennet.ru по некорректно озаглавленной ссылке: эти статьи НЕ про оптимизацию произвдительности систем хранения в целом, а про специальные инструменты и средства оптимизации производительности конкретно систем NetApp FAS! Если у вас не NetApp FAS, то вам, кроме вот этой первой статьи, будет неинтересно!

С неделю уже закопался в материалы по оптимизации производительности систем хранения, причем не только NetApp, но, все же, главным образом. И решил подкинуть вам полезных сведений, тем более из опыта знаю, что множество админов систем хранения NetApp, увы, имеют, зачастую, самые базовые представления об диагностике и траблшутинге проблем производительности. И это при том, что, зачастую, системы хранения, даже в базовой поставке, не считая всяких мегакрутых штук типа DFM и Performance Advisor, имеют достаточно средств “загрузить” среднего админа мыслями.

Для начала несколько вполне разумных рекомендаций от Тома Гамильтона, инженера NetApp, занимающегося в компании базами данных и оптимизацией производительности систем хранения для них. Когда вы их читаете, то кажется, что все это очевидная банальщина. Что, впрочем, не мешает все новым и новым людям их нарушать на практике, и огребать проблемы, как результат такого нарушения.

1. В первую очередь проверьте все уже известные проблемы (known issues) с софтом и оборудованием, которые часто перечисляют вендоры в документации и release notes. Вполне возможно, что ваша проблема с производительностью имеет хорошо известную причину и, соответственно, решение.
2. Рассматривайте всю систему целиком. Не занимайтесь ускорением “на 5%” отдельно взятых подсистем ее, когда, возможно, куда большие “затыки” существуют на других участках. Выбирайте как цель оптимизации наиболее существеные в общей картине участки системы. Низкое быстродействие IT-системы в целом далеко не всегда вызвано только лишь невысокой производительностью хранилища базы данных.
3. Измеряйте и переконфигурируйте систему поэтапно.  Не пытайтесь объять необъятное и поменять сразу все. Разделите рассмотренную вцелом систему на компоненты, оцените вклад в производительность на каждом этапе, и улучшайте производительность постепенно, начиная с участков, дающих наибольший вклад.
4. Делайте изменения в конфигурации по одному за раз. Если вы найдете причину и улучшите производительность системы, то, если изменений делалось много за раз, будет непросто найти что именно дало результат.
5. Продумайте и распишите по шагам все процедуры изменений, и, что не менее важно, “путей отступления”, “отката” в исходное состояние в случае неудачи. ДО того, как вы начнете что-то менять!
6. Не твикайте систему только ради того, чтобы потвикать! О-о… Даже и комментировать не стану :)
7. Помните про “Закон убывающей доходности”. Начиная с какого-то этапа, каждая следующая ступенька относительного прироста производительности будет вам стоить все дороже и дороже.

Правильная настройка системы хранения, и системы в целом, куда входят сервера и ПО, зачастую может дать весьма серьезный результат прироста производительности. Так, например, в TR-3557 приводится вот такая картинка для результатов базы Oracle 10g на HP-UX, работающей по 10G Ethernet NFS, для настроек по умолчанию OS, и для правильных настроек:

Всегда ищите главное, наиболее существенное “бутылочное горло” системы, и начинайте оптимизацию именно с него.

По опыту Тома Гамильтона, Top5 таких “узких мест” для системы хранения это:

1. “Затык” на уровне диска
2. На уровне интерфейса к дискам FC-AL или SAS
3. На уровне процессора контроллера или OS системы хранения
4. “Потолок” сетевой карты или target-адаптера
5. Проблемы настроек tread parallelism на клиенте

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

Как правило, для файлового доступа к системе хранения NetApp с Windows используется протокол CIFS, однако его можно реализовать и через более традиционный для UNIX-сред протокол NFS. Простейший пример зачем: ну например у вас просто нет лицензии CIFS, но есть NFS, и покупать довольно дорогую лицензию ради нескольких Windows-компьютеров вы не хотите, а NFS – уже есть. Или, допустим, ваша задача более подходит под stateless-протокол NFS.

Для поддержки NFS под Windows, Microsoft выпускает бесплатный продукт Services for UNIX (SFU), куда входит и клиент NFS. Рассмотрим как правильно все настроить, в случае использования системы NetApp FAS с лицензией NFS, клиентского компьютера Windows и пакета SFU.

Описание найдено тут, я его просто перевел.

Continue reading ‘Как настроить доступ PCNFS (SFU) на NetApp’ »

Практикующим windows-сисадминам уже довольно неплохо знаком интересный продукт Microsoft – PowerShell – “прокачанная” командная строка. Многие админы уже хорошо освоились с использованием PowerShell в повседневной практике для написания скриптов.

Однако можно использовать средства PowerShell и для администрирования систем хранения NetApp. Для этого была написана специальная объектная библиотека, которую можно скачать с сайта communities.netapp.com, а для того, чтобы разобраться в предоставляемых средствах советую начать с документа:

NetApp PowerShell Survival Guide

PowerShell необходимой версии 2.0 включен в поставку Windows Server 2008 и 2008 R2, и Windows 7, а также может быть скачан и установлен на Server 2003 и XP.

Обратите, однако, внимание, что PowerShell недоступен для версии 2008 Core (но есть в 2008 R2 Core), то есть для Windows 2008 Server без GUI, хотя как раз логично было бы именно там увидеть PowerShell. Однако –  для 2008 Core PS нет. Почему это так, если в двух словах, это это связано с рядом внутренних архитектурных возможностей, которые из 2008 были “выпилены” за компанию вместе с GUI, но которые необходимы для работы PS.

Ссылка для скачивания (требуется логин в communities) библиотеки DataONTAP для PS:
http://communities.netapp.com/docs/DOC-6138

Ссылка не требующая логина, на версию этой библиотеки, скачанной мною 11.02.2011:
http://www.divshare.com/direct/14030272-955.zip

Если вы используете систему 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

По моему одной из самых распространенных проблем при подключении файлера NAS в сеть домена AD является проблема с неверно выставленным временем и/или неверным часовым поясом.

Корень проблемы кроется в том, что для аутентификации в домене AD, член домена (в нашем случае – файлер NetApp) использует Kerberos, тикеты которого помечаются временем их выпуска, и если время на компьютере, включающемся в домен, и контроллере домена не совпадают более чем на 15 минут (так называемый “time skew”), то тикет Kerberos “протухает”, аутентификация не проходит, и соединение с доменом не может быть выполнено.

Поэтому, если вы столкнулись со странным поведением файлера NetApp при подключении его в домен Active Directory, ошибками в логах и так далее, первым делом проверьте ситуацию с установленным временем на файлере, правильность синхронизации с локальным NTP (обычно локальным NTP в домене является контроллер домена), правильность выставленной Time Zone (идентичной между установкой файлера и установкой контроллера домена) и отсутствие “сдвига времени” между файлером и контроллером домена AD.

Бродя по бесконечным просторам внутренних пространств вебсайта NetApp обнаружил там в глухом уголке чрезвычайно полезную вещь, каковой и поделюсь.
Называется Data ONTAP Cookbook.

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

• Как создать том
• Настроить NFS export
• Сконфигурировать порт FC
• Изменить размер LUN
• Создать и настроить VIF/ifgrp
• Настроить SnapMirror
• …и так далее, всего 70 страниц.

Скачать можно тут: http://www.divshare.com/download/12748580-cab

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

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

Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts

Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.

В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:

fas1> options admin.hosts 192.168.1.254

Другой вариант – указать их в таком виде:

fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com

Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

В блоге 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.