Posts tagged ‘tips’

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

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ‘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

Оптимизация на 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 база, то, может быть, можно и попробовать.

Четыре главных ошибки при конфигурировании дедупликации на NetApp

Как вы заметили, стандартными днями публикации в этом блоге являются понедельник и четверг. В эти дни выходят мои собственные заметки в блоге. Но недавно я решил “расширить предложение”, и по средам тут будут публиковаться наиболее интересные публикации переводов постов из англоязычных блогов, в частности из blogs.netapp.com – директории официальных блоггеров NetApp, где, зачастую, встречаются очень интересные посты, увы, по причине “англоязычности” часто проходящие мимо внимания русскоязычных пользователей.

Сегодня – пост Кейта Аасена, инженера службы поддержки пользователей в NetApp, где он рассказывает об основных ошибках пользователей при конфигурировании дедупликации на системах хранения NetApp.

The 4 Most Common Misconfigurations with NetApp Deduplication

Posted by Keith Aasen - CSE Virtualization

Работая сервисным инженером мне приходится встречаться с пользователями из самых разных отраслей. Когда я рассказываю пользователям про наши типичные показатели экономии пространства при дедупликации данных на “боевых” системах VMware, которые составляют 60-70% изначального объема, я часто встречаюсь со скептическим отношением: “Ну, мол, это у них, у нас-то данные особенные”, часто отвечают мне, “Поверю, только когда сам увижу”. Мы демонстрируем результат, и мне нравится слышать в ответ: “О, это совсем не то, что про вас рассказывали нам ваши конкуренты!

Совсем недавно один из наших клиентов перенес более 600 виртуальных машин, занимавших на его действующей системе хранения 11,9TB, на новый дисковый массив NetApp, причем это были 600 виртуальных машин разного содержимого, с различными OS, с различными в них приложениями и их конфигурациями, и после дедупликации это заняло всего 3,2TB – 73% экономии!

Но иногда встречаются пользователи, которые звонят с вопросами: “Эй, а у нас тут дедупликация дала всего 5%, в чем дело?” Такие невысокие показатели дедупликации, по моему опыту, являются следствием какой-нибудь из перечисленных ниже типичных ошибок.

Ошибка №1 – Неправильно изначально включенная дедупликация (или забытая опция –s для scan)

Как уже указывал в своем блоге Dr.Dedupe, NetApp рекомендует использовать дедупликацию для всех данных VMware. Вы можете заметить, что если вы используете наш продукт Virtual Storage Console (VSC), плагин к vCenter, то созданные в нем датасторы VMware автоматически идут с включенной опцией дедупликации для них. Мы советуем оставлять включенной эту опцию, и вот почему.

Когда для тома включена дедупликация (ASIS), то контроллер отслеживает все записываемые на этот том блоки данных. Когда наступает время запуска процесса дедупликации, то контроллер просматривает все отслеженные ранее блоки, и устраняет дубликаты среди них. Но только среди тех, которые он перед этим уже отследил при записи! Что же делать, если у вас уже на диске было несколько виртуальных машин, для которых опция дедупликации не была включена изначально при их создании? Если вы не указали контроллеру NetApp специально просканировать блоки уже лежащих на его дисках данных, то эти виртуальные машины и их данные не будут обработаны дедупликацией! Это приведет к снижению результатов, показываемых дедупликацией. Но хорошая новость состоит в том, что это легко поправить. Запустите дедупликацию с опцией scan в VSC, или же вручную, из консоли управления укажите у команды sis ключ –s.

image

Выше – рассматриваемое действие в VSC, ниже – в System Manager, другом нашем инструменте управления контроллером системы хранения.

image

Для предпочитающих командную строку это будет sis start -s /vol/myvol, удивительно как много могут сделать всего два дополнительных символа.

Это, по моим наблюдениям, самая популярная ошибка, но благодаря все большему количеству наших пользователей, которые создают разделы для VMware с помощью VSC, она становится все менее распространенной.

Ошибка №2 – Включенное резервирование пространства под LUN

На контроллере NetApp у нас есть несколько различных уровней включения резервирования пространства, в зависимости от ваших потребностей. Но для VMware используются главным образом два. Первый – это резервирование на уровне тома (volume reservation). Оно резервирует пространство в объеме пула aggregate, и обеспечивает вам уверенность в том, что объект, который вы помещаете на том, на него поместится, и для него найдется достаточно места. Внутри такого тома вы можете создавать LUN-ы для VMware. Тут вы тоже можете выбрать вариант резервирования пространства под LUN, которое займет сразу все необходимое пространство на томе под создаваемый LUN. И с этим есть две проблемы. Первая – что вам так делать, на самом деле, не нужно. Вы уже зарезервировали место на уровне тома на aggregate, с помощью volume space reservation, вам не нужно резервировать его еще раз, с помощью LUN space reservation. Вторая – LUN reservation означает, что LUN всегда будет занимать зарезервированное пространство. То есть LUN , созданный с заданным размером 600GB, всегда займет на дисках эти 600GB, даже если он пустой, даже если на нем успешно поработала дедупликация.

Простое отключение резервирование пространства для LUN даст вам эффект от дедупликации данных на нем (да, кстати вы можете сделать это прямо на ходу, не останавливая VM, использующую этот LUN).

image

Ошибка №3 – Неверно выравненная VM

Проблема с неверным выравниванием партиций для некоторых гостевых операционных систем с нижележащей структурой блоков системы хранения хорошо документирована. Во многих случаях проблема неправильного выравнивания вызывает уменьшение результатов экономии пространства при дедупликации, ниже ожидаемых величин. Наши клиенты часто бывают поражены тем, как много блоков мы можем дедуплицировать даже между неодинаковыми OS, например между Windows 2003 и Windows 2008, или между Windows XP и Windows 2003. Но если начальное смещение партиции одной OS отличается от такого же смещения другой, то результат дедупликации будет почти нулевой.

Кроме снижения результатов экономии при дедупликации и большего занятого на дисках объема, неверное выравнивание партиции оказывает довольно значительную дополнительную нагрузку на контроллер системы хранения (любой системы хранения, не только NetApp). Поэтому было бы очень неплохо исправить эту ситуацию. На рынке существует множество программных инструментов для выполнения этого действия, включая утилиту MBRalign, которую получают клиенты NetApp в составе нашего пакета VSC (Virtual Storage Console). Когда вы поправите неправильное выравнивание ваших VM, вы увидите не только улучшение показателей экономии пространства в результате дедупликации, но и снижение уровня загрузки процессоров на контроллерах системы хранения.

Ошибка №4 – Большой объем данных в VM

Это, правда, не ошибка конфигурации, а, скорее, особенность дизайна системы. Большинство наших пользователей не отделяют данные VM от системного VMDK с OS. Возможность держать все содержимое VM в одной директории выглядит слишком заманчиво, чтобы ей пренебречь. Пользователь обычно все равно получает довольно неплохие результаты дедупликации, даже если данные приложения смешаны с блоками данных самой OS. Часто пользователи держат по настоящему большие разделы виртуальных дисков, где блоки данных OS лежат вместе с большими базами данных, репозиториями образов, или базами электронной почты, все внутри одного диска VM. Такие большие разделы смешанных данных скорее всего не будут дедуплицироваться с высокими показателями экономии. В общем-то нет ничего страшного в такой схеме, но если вы переместите VMDK с такими данными на отдельные разделы с аналогичными данными, то показатели дедупликации для таких VMDK, и для VMDK с файлами OS, хранящимися по отдельности друг от друга, будут заметно выше. Но, в принципе, оба варианта вполне рабочие.

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

Консольный кабель и переустановка системы

Иногда пользователям попадается система хранения с “богатым прошлым”, “доставшаяся в наследство”, или иной странный некомплект. Часто встает вопрос, как привести такую систему в исходное состояние, избавившись от “тяжелого наследства” установленной конфигурации прежних владельцев.

Для начала, вам следует найти консольный кабель. Он идет в комплекте поставки но, в случае, когда концы системы утеряны, бывает с ними же уходит и кабель.

В качестве консольного кабеля прекрасно подойдет аналогичный консольный кабель RJ-45-to-DB-9 от оборудования Cisco. Его распиновка такова:

Pinouts RJ45
Pin# Signal
1    connected to pin 8
2    Not connected
3    TXD (from appliance)
4    GND
5    GND
6    RXD (to appliance)
7    Not connected
8    connected to pin 1 

Для справки также привожу распиновку стандартного RS-232 serial DB-9

Pinouts DB9
Pin# Signal Data Flow Description
1    DCD    input     data carrier detected
2    SIN    input     serial input
3   SOUT    output    serial output
4    DTR    output    data terminal ready
5    GND    N/A       signal ground
6    DSR    input     data set ready
7    RTS    output    request to send
8    CTS    input     clear to send
9     RI    input     ring indicator 

Для сброса системы в “состояние с завода” следует выполнить в консоли загруженной системы, войдя от имени root, следующие команды:

>priv set advanced

>halt -c factory

После перезагрузки все ранее сделанные изменения конфигурации в /etc сотрутся, и будет запущен стартовый скрипт setup, обеспечивающий начальную установку впервые включенной системы.

Если необходимо сменить неизвестный или утерянный пароль root, следует, с подключенным к serial port кабелем и консолью, включить контроллер, и, при загрузке, на предложенную подсказку, нажать Ctrl-C и выбрать (3) Change password.

Обратите внимание, что сбросить пароль root возможно только с консольным подключением в контроллер.

Как избежать работы с LUN через “чужой” контроллер кластера.

Одной из ошибок настройки при работе кластерной системы 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/

20/0.151

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