Archive for the ‘tricks’ Category.

Одинаковые имена томов и аггрегейтов на системе хранения

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ???vol0’, к примеру).

Для устранения этой проблемы Data ONTAP автоматически изменяет имена таких дублирующихся ресурсов, добавляя цифру в скобках. Однако проблема (по крайней мере в 7.x) в том, что такие авто-переименованные ресурсы нельзя переименовать вручную. Но можно переименовать исходный, который вызвал автопереименование последующих. Результат будет такой:

fas1> vol status
  Vol_data    online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on
  Vol_data(2) online          raid_dp, flex     create_ucode=on
 
fas1> vol rename vol_data vol_data_orig
fas1> vol status
  Vol_data_orig  online    raid_dp, flex     create_ucode=on
  Vol_data  online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on

Как вы видите, можно выкрутиться из этой ситуации переименовывая тома вручную по одному.

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

Помощь, как всегда, была найдена в TFM  ;) – NetApp Storage Management Guide.

How you manage duplicate volume names

Аутентификация в админской консоли по заранее сконфигурированному ключу SSH

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

Самый удобный вариант – организовать подключение по SSH, однако, для того, чтобы не передавать пароль, сгенерировать заранее public key, и авторизоваться на консоли NetApp с его помощью.

Вот как это сделать с помощью популярного PuTTY.

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

Выберите пользователя, для которого мы будем устанавливать ключ. Помните также, что если вы используете выполнение каких-то скриптов от стороннего, специально сконфигурированного пользователя (например используя RBAC – Role-based Accees Control), то это надо будет также проделать и для него. Закрыв доступ для всех ключей, кроме заранее сконфигурированных, вы заблокируете таких пользователей также.

Далее нам надо создать на контроллере поддиректорию для файла ключей, она должна располагаться внутри директории sshd
полный путь, таким образом, с точки зрения стораджа будет выглядеть примерно так (для пользователя root):

/vol/vol0/etc/sshd/root/.ssh/

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

Смонтируйте root-vol в директорию на вашем компьютере по NFS или CIFS.

Перейдите в директорию /mountpoint/etc/sshd и создайте в ней директорию с именем нужного пользователя, например мы будем использовать для администрирования пользователя romx, а для исполнения скриптов пользователя scripter.

Перейдите в созданную директорию и создайте в ней поддиректорию с именем .ssh (с точкой в начале!)

Убедитесь, что директория успешно создалась, выйдите на уровень /mountpoint, например командой cd ../../../ и размонтируйте шару.

Вы получили следующую структуру на контроллере NetApp: /etc/sshd/romx/.ssh и /etc/sshd/scripter/.ssh соответсвенно.

Теперь сгенерируем пары ключей. Запустите программу puttygen.exe, входящую в состав пакета PuTTY.

putty-listing

Убедитесь, что используете security algorithm SSH2-DSA (Data ONTAP умеет использовать cipher для SSH только TripleDES), щелкните “Generate!” и поводите мышкой для генерации случайной инициализацонной последовательности.

putty-gen

Ключ сгенерирован, теперь надо указать контроллеру NetApp использовать для аутентификации этот ключ. Запишите его в файл с расширением .ppk, например romx.ppk

Не указывайте никакую passphrase.

putty-keygened-pic

Скопируйте из файла public-информацию, затем создайте в созданной на контроллере директории файл authorized_keys (без расширения) и запишите туда скопированный фрагмент. Обратите внимание, что в текстовом редакторе, где вы это проделываете, должен быть выключен режим перевода строк, иначе в ваш ключ могут попасть лишние символы перевода строки. Вся последовательность public key должна располагаться в файле в одну строку! Сохраните файл. Обратите внимание на то, что файл должен не иметь расширения!

key in-line

Теперь включите на контроллере режим использования преконфигурированных ключей:

filer1> options ssh.pubkey_auth.enable on

Давайте протестируем подключившись с помощью программы plink из состава PuTTY, и запросив что-нибудь из консоли:

c:\putty> plink.exe -i romx.ppk romx@filer1 vol status

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

Также рекомендуется для аккаунта, исполняющего скрипты, из соображений безопасности, запретить “лишние” возможности. Подробнее об ограничении прав аккаунта смотрите в документе RUS TR-3358 Role-Based Access Control for Data ONTAP 7G.

Network boot

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

Оптимизация на Large Sequental Read

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

Эта опция оптимизирует работу WAFL при работе большими последовательными блоками. Я могу ошибаться, но, исходя из моего понимания процессов за которые она отвечает, сказываться она будет не просто при включении, а при включении и последующей записи на том, или после реаллокации блоков на томе (вы помните, надеюсь, что WAFL не перезаписывает однажды занятые блоки, поэтому структура для уже записанных данных, на момент включения опции, никак не изменится). Поэтому, возможно, заметить эффект от ее использования получится не сразу же.

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.

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

Рассмотрим еще одну полезную команду для глубокой диагностики, позволяющую находить и анализировать проблемы канала передачи данных от диска к контроллерам на системах, использующих интерфейс 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’ »

Оптимизация производительности. Часть 1.

Приходящим с 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, и для правильных настроек:

image

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

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

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

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

Как настроить доступ PCNFS (SFU) на NetApp

Как правило, для файлового доступа к системе хранения 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’ »

PowerShell и администрирование 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

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

time skew при настройке подключения в домен AD

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

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

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