about NetApp

Два параметра в свойствах FlexVol-тома NetApp, значения которых вы, возможно, не знали.

“minra” минимизирует (min) операцию упреждающего чтения (Read-Ahead, ra). Режим упреждающего чтения есть метод своеобразной оптимизации чтения. Алгоритм предсказания операций чтения старается определить, насколько высока вероятность, что следующие считываемые блоки будут располагаться последовательно, и, если да, то читает их с упреждением , read-ahead, в расчете, что данные, заранее прочитанные, понадобятся на следующей операции, а они у нас уже в памяти.

В версии DataONTAP 6.5 и ранее, алгоритм был довольно примитивен, и просто читал с упреждением блоки с диска, заполняя, подчас, память кэша чтения системы ненужными данными, например в случае равномерно-рандомного чтения. Поэтому в старых руководствах вы могли встретит рекомендации устанавливать в свойствах тома этот параметр в minra=on, то есть отключать упреждающее чтение. Это помогало сэкономить пространство кэша в случае заведомо рандомного характера рабочей нагрузки.

В версии 7, и в особенности в 7.3, алгоритм Read Ahead значительно усложнился и поумнел, и теперь предсказание упреждающего чтения работает значительно лучше и эффективнее. Поэтому для новых систем, начиная с 7.3, рекомендуется не выключать Read Ahead (НЕ ставить minra=on в свойствах тома), даже для рандомной нагрузки, предоставив работать умному алгоритму.

Второй параметр – “no_atime_upd” – отключает обновление времени последнего доступа к файлу (access time - atime), располагающемуся на файловой шаре с доступом по NFS или CIFS. В случае, если вы используете систему NetApp как NAS, и ваши приложения доступа к файлу НЕ пользуются данными last access time (это вообще используется сегодня сравнительно редко), то этот параметр лучше установить в on (выключить обновление времени последнего доступа). Этот параметр никак не влияет при использовании систем NetApp как SAN-хранилища, то есть когда том FlexVol хранит на себе LUNы.

Для файловых же операций его отключение в настояще время также почти не влияет на быстродейстие тома, по наблюдениям прирост составляет в районе 1-1,5%.

Таким образом, на сегодня, оба эти параметра остаются скорее как legacy параметры, и особого эффекта их настройка не приносит.

Я уже несколько раз упоминал в этом блоге о aggregate snap reserve, пришла пора  подробнее рассказать о том, что это, зачем использутся, и нужно ли это вам.

Вы уже наверняка знаете, что такое и зачем используется Snapshot reserve на уровне тома. Это некий зарезервированный объем общего пространства соответствующего тома, используемый для того, чтобы обеспечить доступность пространства на дисках при создании снэпшотов состояния тома. Это некая условная “граница”, которую может превысить снэпшот, но не может превысить содержимое тома, пользователю тома доступно для записи место, равное объем тома минус резервация на снэпшоты. Это резервирование гарантирует доступность места для хранения данных снэпшотов, а также упрошает администрирование тома, так как пока снэпшоты не вышли за пределы отведенного резерва, свободное пространство, доступное для записи на томе, стабильно и предсказуемо.

Подробнее и с поясняющими картинками про принцип работы Snap Reserve я писал в посте ранее.

Отмечу также, что величина резерва, заданная по умолчанию в 20% от объема тома может быть изменена, и 20% это не hardcoded value, а просто такая вот эмпирически выбранная когда-то величина “по умолчанию”. Можно сделать 50, 15, 10, и даже 0%. Например 0% сегодня рекомендованная величина Snapshot Reserve в случае использования тома для хранения SAN LUN-ов (вместо Snapshot Reserve используется Fractional (или LUN Overwrite) Reserve, о смысле которого я уже также ранее писал).

С Volume Snap Reserve мы более-менее разобрались, но что же такое и зачем нужен Aggregate Snap Reservation, равный, по умолчанию, 5% от объема aggregate?

Aggregate, по сути, представляет собой свообразный мета-volume, просто такой своеобразный том, находящийся в иерархии уровнем ниже обычного FlexVol-тома. Соответственно, задача у этой резервации точно такая же – хранить блоки, использованные в снэпшоте уровня aggregate.

Что же такое “снэпшот уровня aggregate”, кто его делает и зачем он используется?

Снэпшоты на aggregate использует, например, средство SyncMirror, это средство синхронной репликации, используемое, например, в решении MetroCluster.
Кроме того, такие снэпшоты используются для работы средства контроля целостности файловой структуры WAFL, аналога UNIX-ного fsck, ооочень редко на практике применяемого средства WAFL_check (я знаю немало админов NetApp, которые вообще не в курсе, что такое средство у NetApp есть).

WAFL как “файловая система”, вследствие своей архитектуры, поразительно устойчива, 99% админов NetApp действительно никогда не сталкиваются с необходимостью “лечить” WAFL. “Уронить” WAFL в принципе возможно (“Если один человек чего сделал, то другой завсегда сломать может”(с)) но это, как показывает моя практика, довольно нетривиальная задача.

Если вы “уронили” WAFL настолько, что потребовалось использование WAFL_check, то очень сильно сократить этот процесс может наличие автоматически создаваемых снэпшотов аггрегейта. Впрочем, как я знаю, он заработает и без них, однако, на большой системе, починка может занять на пару порядков больше времени, вместо десятков минут – несколько дней.

Также, с использованием снэпшотов уровня aggregate вы можете сделать SnapRestore для aggregate целиком, вместе со всеми томами и LUN-ами на нем, если зачем-то это вам понадобилось.

Кроме этого следует обратить внимание, что какой-то объем пространства на уровне aggregate (то есть не распределенного в volumes, а непосредственно в aggregate) используют следующие средства:

1. Deduplication  начиная с версии 7.3 хранит свою базу fingerprints непосредственно на уровне aggregate, таким образом, при использовании deduplication вам понадобится какое-то небольшое пространство на aggregate не занятое томами, обычно в зарезервированные 5% эта база помещается
2. Синхронная версия репликации SnapMirror до версии 7.2.2 записывала данные, попадающие в NVRAM, в специальный файл на root volume по пути /etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]. Начиная с 7.2.7 эти данные пишутся также на уровне aggregate. Руководство Data ONTAP Online Data Backup and Recovery Guide рекомендует, в случае использования Sync SnapMirror иметь на aggregate место в объеме 20x емкости NVRAM на системе-получателе (destination).
   (обратите внимание, что у NetApp есть два различных средства synchronous replication – SyncMirror и SnapMirror Synchronous mode)
3. Наконец, не стоит забывать, что запас незанятого места на aggregate довольно значительно снижает величину фрагментации, а правильнее “non-contiguous block factor”. Напомню, что файловая система (любая, NTFS, ext3, WAFL, почти любая современная файловая система), когда ей необходимо записать файл, сперва ищет у себя фрагмент непрерывно свободного пространства, куда и пишет содержимое этого файла. Если, как это обычно бывает при сильно заполненной файловой системе, такого места отдельным, непрерывным куском нет, то файловая система начинает дробить записываемые данные файла на более мелкие фрагменты, которые уже могут располагаться непоследовательно. В наихудшем случае, файловая система располагает свободным местом только в виде отдельных, непоследовательных блоков, разбросанных по файловой системе. Наличие запаса свободного места с точки зрения файловой системы резко улучшает эту ситуацию, и позволяет не накапливать фрагментацию.

Таким образом, как вы видите, идея держать гарантированно небольшое свободное пространство на уровне aggregate имеет определенные основания на системном уровне. Если вы уверены, что ничем из перечисленного вы не пользуетесь, а 5% зарезервированных на aggregate вам жалко, то вы можете уменьшить эту величину, аналогично ситуации с volume snap reservation, , например до 2-3%, практика показывает, что этого достаточно. Можно, хотя это и не рекомендуется, и вовсе отключить эту резервацию. Обратите также внимание, что, как и в случае с volume snap reserve, отключение reservation не отключает возможность использования snapshots, если на структуре (volume или aggregate, соответственно) есть свободное место. Это просто средство некоторого упрощения жизни и работы админа, и только.
Помните, тем не менее о том, что у NetApp за каждым default value стоит какая-то причина, и прежде чем вы не уясните эту причину, я бы не рекомендовал “твикать” не глядя, это все же не “реестр венды” ;).

Посмотреть текущее состояние резервирования и назначенное расписание создания снэпшотов на aggregate:

fas1> snap sched –A
Aggregate aggr0: 0 1 4@9,14,19 - установлено расписание создания снэпшота aggregate в 9, 14 и 19 часов, и хранение с ротацией одного дневного и 4 таких "почасовых" снэпшота.

fas1> snap sched –A aggr0 0 0 0 - создание снэпшотов aggregate aggr0 отключено.

Для изменения величины или отключения резервирования на aggregate вам нужно использовать команду:

fas1> snap reserve –A aggr0 3 – устанавливаем величину резервирования для aggr0 равную 3%

Не секрет, что компания IBM продает под названием IBM N-series системы хранения, являющиеся, произведенными для IBM, знакомыми нам системами NetApp FAS. Отличаются они корпусом (вернее передней лицевой панелью), а также “брендированным” IBM-ом софтом. Ну и, конечно, саппортом, оказываемым IBM, и рядом подобных же отличий в процессе продаж и сопровождении (например для системы IBM N-series можно купить диски поштучно, а не целой полкой, как у NetApp).

Но вот как обстоят дела с софтовой совместимостью, например, можно ли установить в качестве партнера репликации SnapMirror к IBM N-series систему NetApp FAS?

Да, это возможно, SnapMirror и SnapVault совместимы между NetApp FAS и IBM N-series, однако помните, что должны соблюдаться соответствия версий Data ONTAP между этими системами (например, в случае использования Volume SnapMirror, получатель репликации должен иметь версию Data ONTAP равную или новее, чем источник). Что может быть определенной проблемой, так как IBM заметно запаздывает с выпуском новых версий Data ONTAP под N-series.

Я уже пару раз писал в этом блоге о чрезвычайно полезной программке IOmeter, предназначенной для нагрузочного тестирования и измерения производительности серверов, систем хранения и сети. К моему удивлению, эти две статьи приводят на мой скромный блог громное количство народу, так как, как оазалось, подробного описания использования IOmeter (а тем более на русском) в интернете просто нет. Программа же не вполне “интуитивно понятна”, и, зачастую, именно этим объясняется то, что такой замечательный, гибкий и удобный, и при этом абслютно бесплатный инструмент тестирования находится в определенном “загоне”.

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

Недавно я пролистывал чрезвычайно полезный сам по себе блог Антонио Хосе Родригеса Нето, системного инженера бразильского отделения NetApp, специализрующегося на вопросах использования систем хранения NetApp и баз данных Oracle. В одном из постов я углядел любопытную рекомендацию относительно установки и использования параметра Align I/Os, которую обычно всегда оставлял по умолчанию. Этот параметр устанавливает смещение паттернов ввода-вывода, и значение по умолчанию его – 512 байт (sector boundary).

Neto справедливо указывает, что для современных систем хранения имеет смысл устанавливать его значение в 4096 байт, как более соответствующего структурам и нормам работы дискового хранилища, обычно располагающегося не на физическом диске как таковом, а на RAID-группе, имеющей более крупный размер элемента данных. В частности, в случае NetApp это блок WAFL, как раз и имеющий размер 4KB.

Кстати, по ссылке Neto демонстрирует тест FAS3140A на 96 дисках FC 300G 15K, при трех серверах load-generator под RedHat Linux, подключенных по 4Gb FC, и показывающего свыше 100K IOPS на нагрузке 4KB блоками и 100% random write. Очень впечатляющий результат.

“Умный, честный и партийный. В одном человеке бывают вместе только два свойства из трех” шутили в пору моего детства (кстати шутка обрела второе дыхание в нынешней России).
??ли же есть вариант, особенно для IT -  “быстро, хорошо и дешево”.

EMC, кажется, нашла еще один вариант ;)

Я бы, на месте NetApp, не упустил бы возможности оттоптаться ;)

Я упоминал об этой ситуации в статье о новых системах серий 3200 и 6200, хочу привлечь внимание к этой ситуации еще раз, и более настойчиво, так как она неочевидна, и может создать проблемы “напрасных ожиданий” для пользователя.

Как вы знаете, новинкой NetApp в новых сериях стал специальный модуль расширения IOXM, в который можно установить дополнительные карты, например портов ввода-вывода. Вы можете приобрести систему 3240 или 3270 в конфигурациях с IOXM или без него (здесь и далее все говоримое также верно и для соответствующих моделе серии 6200).

Однако, обратите внимание, что, если вы купили систему без IOXM, то есть один контроллер и ниже него пустой слот под заглушкой, в дальнейшем, позже, в такую систему вы не сможете добавить IOXM. Во первых он просто не продается отдельно, как отдельный партномер. Во вторых chassis с IOXM и без него, к сожалению, отличается где-то на внутреннем, системном уровне, и in the field один в другой не преобразуются.

Также вы можете приобрести систему FAS3210 либо в варианте “один chassis и два контроллера в нем” (этот вариант называется FAS3210A или “dual controller”), либо “два chassis, по одному контроллеру в каждом” (FAS3210 или “single controller”). Для FAS3210 варианта с IOXM нет.

Для суммирования всего сказанного визуально, нарисуем нижеследующую табличку:

Таким образом нельзя: купить 3210 с IOXM, и нельзя добавить IOXM позже в систему 3240/70, купленную изначально без IOXM. Теоретически, правда, существует вариант Upgrade 3240/70A to 3240/70AE, но технически он выполняется как заказ системы AE, привоз ее, снятие и возврат в NetApp системы A и установка на ее место AE. ?? я не уверен (уверен что не), что такое будет производиться в России.

Все вышесказанное действительно и для систем серии 6200.

При этом обратите внимание, что апгрейд FAS3210 в любую вышестоящую систему, например FAS3240 или 3270, а также, соответственно, FAS6240 и 6270 для FAS6210 осуществляется не просто заменой контроллера в chassis, но заменой контроллера вместе с chassis, так как он, по всей видимости, также где-то на внутреннем уровне отличается, хотя внешне и такой же.

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

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

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

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

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

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

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

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