about NetApp

Я уже несколько раз упоминал в этом блоге о 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.

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

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

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

Лучше то, что лучше работает на ваших данных и ваших задачах.

Обратите внимание, что использование дедупликации или компрессии не исключает одно другого. Вы вполне можете использовать И дедупликацию И компрессию на одном и то же томе. Или же выбрать что-то одно. Зависит от вашей задачи и характера даных.

Вот какой рисунок приводит NetApp по поводу эффективности дедупликации и компрессии в одном из своих документов (выше – лучше):

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

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

Как я уже писал раньше, начиная с Data ONTAP 8.0.1, для пользователей систем хранения NetApp становится доступной опция компрессии хранимых на дисках данных. Эта возможность довольно популярна среди современных файловых систем, например она хорошо работает в NTFS. Теперь эта возможность, дополняющая дедупликацию, появилась у NetApp.

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

Преимущество хранения скомпрессированного файла очевидно. В такой форме файлы занимают значительно меньше места на диске. Насколько меньше – зависит от характера данных. Например уже обработанные тем или иным компрессором файлы, а также цифровое видео и аудио, обычно также сжатое тем или иным алгоритмом, уже практически не сжимается. Исполняемые файлы, например программы, сжимаются примерно на 25-35%. Файлы данных, такие, как документы Word и Excel – обычно на 30-50 процентов.

Недостаток, в принципе, тоже очевиден. Операции запаковки и распаковки больше обычного нагружают процессор системы. Насколько сильно – зависит от характера данных, а также мощности процессоров.

Еще одним неявным преимуществом хранения данных в таком виде, которое часто недооценивается, является, как ни парадоксально, улучшение показателей производительности считывания с дисков для сжатых файлов. Ведь если мы храним файл, сжатый на 50%, то для того, чтобы считать его с дисков (сжатый), нам придется прочесть с этих дисков в память поток байт вдвое меньший, чем для некомпрессированного файла. Лучше, следовательно, могут стать и показатели IOPS системы.
Платим за это мы потенциально большей нагрузкой на процессор, все верно. Однако, в наше время, производительности процессоров на такие несложные, хорошо известные и эффективные алгоритмы, как онлайн-компрессия, хватает с огромным запасом.  Во многих случаях разница в загрузке процессора даже оказывается ниже измеряемого уровня. Пожертвовать ради увеличения дисковой производительности единицами процентов загрузки процессоров, мощность которых непрерывно растет кадый год, по сравнению с показателями в IOPS для дисков, которые застыли и не улучшаются уже довольно давно, бывает вполне неплохим вариантом “обмена”.

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

Теоретически мы могли бы попробовать архивировать отдельно составляющие файл блоки WAFL размером 4KB, используя компрессию на уровне блоков , но что делать с высвободившемся от такой компрессии местом? WAFL не может работать с местом на таком “субблочном” уровне. Если у нас есть файл, который занимает 3 блока WAFL по 4KB, то еть имеет размер в 12KB, и файл сжимается вдвое, то после компрессии на уровне блоков WAFL мы получим три наполовину пустых блока WAFL, однако свободное место на них (так называемые tail-ы) использовать не получится – субблочное пространство не адресуется в ONTAP, и файл по прежнему будет занимать три блока – 12KB.

Выход – в использовании групповой обработки. Каждый хранимый файл последовательно делится на так называемые compression groups, размером 32KB, то есть состоящие из 8 блоков WAFL, с которыми и производятся неободимые операции. Compression Groups рассматриваются как единый объект воздействия компрессии. Поделенный на такие группы файл считывается только в той части, что необходима. Если нам нужно изменить блок данных в середине, то считывается в память 32KB данных, содержащих данный блок, блок изменяется, и затем группа компресируется и записывается.

Любопытно, что перед тем, как компрессировать группу, Data ONTAP проводит “на лету” оценку эффективности компрессии. Если компрессия незначительна (очевидно, что это менее 1/8 размера), то группа записывается в исходном виде. Таким образом, файл сжатого видео, записанный на “сжатый” том, будет записан в “исходном” его состоянии, время и процессор на сжатие явно несжимаемго не тратятся. Оценка же производится для 32KB групп. Если внутри в целом несжимаемого файла обнаружится последовательный блок размером 32KB и более, пригодный для сжатия, он будет сжат обычным образом.

Как обычно, коротко, в вопросах и ответах.

Q: Сколько это стоит?
А: Данная лицензия будет доступна бесплатно, как, например, было и есть с дедупликацией.

Q: Это будет работать только для Data ONTAP 8?
A: Нет, еще какое-то время будет продолжаться развитие ветви “семерки”, и, по предварительным данным, в ней тоже будет доступна компрессия. Если у вас активна подписка на обновление ПО, и вы можете поставить новую версию ONTAP на вашу систему, в ней будет и компрессия. Но вообще говоря, стоит уже задуматься о переходе на Generation 8.

Q: Это вместо дедупликации?
A: Нет, это работает независимо, и может компресировать даже уже дедуплицированные тома! И дедупликацию, и компрессию, вы можете использовать независимо, и даже одновременно, на одних и тех же томах.

Q: А если дедупликация уже дедуплицировала, разве остается что-то, что можно еще и сжать?
A: Конечно. Вот, например, описание эксперимента, в котором оценивалась эффектвноссть дедупликации и компрессии: http://habrahabr.ru/blogs/sysadm/104979/
Кроме этого, представим, что у нас на диске лежит сто одинаковых документов. После дедупликации у нас на диске останутся занятыми только блоки одного экземпляра (и по 99 ссылок на них из других файлов). Но этот единственный файл, в свою очередь также можно скомпрессировать! На дедупликацию и содержимое остальных, дедуплицированных файлов это не повлияет. Они просто будут ссылться на компрессированные блоки.

Q: Когда компрессировать получается лучше, чем дедуплицировать?
A1: Представим себе, что на диске лежит множество файлов, которые уникальны по содержимому. То есть, например, текстовая база документов. Каждый, кто архивировал текстовые файлы знает, что такие файлы хорошо компрессируются. Однако вероятнее всего, в неповторяющихся файлах, дедупликация будет неэффективна. Ведь в таких файлах наверняка нет кусков по 4KB размером, строго идентичных до байта. Любая неидентичность в пределах блока WAFL в 4KB отменяет возможность дедупликации.
A2: Другой вариант, сильно ухудшающий возможности дедупликации – смещение. Даже незначительное смещение в содержимом файлов мешает правильно сработать дедупликации. Но ничуть не ухудшает возможности компрессии.

Q: А что вообще лучше, дедупликация или компрессия?
A: Для разных применений – лучше разное. Что-то лучше дедуплицируется, пример – файлы дисков виртуальных машин, что-то – компрессируется, пример – большинство баз данных, или хоумдиры документов с малым количеством дублирующихся между разными пользователями данных, или бэкапы с переменным смещением, сильно портящие “статистику” дедупликации. Наконец, вы можете компрессировать уже дедуплицированные данные.
Конечно, дедупликация несколько меньше нагружает систему по процессорным ресурсам и почти не влияет на производительность, так как работает, в отличие от компрессии, в “оффлайне”. Но в ряде случаев и нагрузкой компрессии можно пренебречь, а экономия пространства – штука нелишняя. Смотрите по обстановке.

Q: Круто, спасибо!
A: Да на здоровье :)

С выходом в активную жизнь Data ONTAP 8 с ее cluster-mode в этом блоге я начинаю менять используемую терминологию. Теперь, во избежание путаницы, я буду называть “cluster-classic”, который был в ONTAP 7 – как “HA-кластер” (High Availability), а под кластером “просто” будет подразумеваться multinode-cluster или ONTAP 8 cluster-mode.

Как вы знаете, HA-кластерная функцинальность систем NetApp позволяет прозрачно для приложений и задач, в случае отказа одного из контроллеров HA-кластерной пары, перенести все его ресурсы, то есть IP-адреса, сетевые имена, WWN-ы FC, а следовательно доступ к сетевым шарам, LUN-ам, и так далее, с вышедшего из строя контроллера на действующий. Таким образом доступ ко всем ресурсам полностью сохраняется и не требует перенастройки клиентов или “фабрики” для продолжения доступа.

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

Значительно ускорить этот процесс можно с помощью операции Hardware-assisted Takeover, которая использует для определеня состояния контроллера возможности RLM – автономного аппаратного микроконтроллера, который по основной своей задаче предназначен для удаленного “out-of-band” администрирования, и работает как независимое аппаратное устройство. RLM был опциональным устройством в системах серии 3000/6000, и встроен в контроллер для серии 3100 и новее. Будучи “внешним” для системы watchdog-ом, RLM позволяет значительно сократить время кластерного takeover, быстро определяя и сообщая состояние своего контроллера. RLM даже имеет автономное (хотя и не слишком длительное по времени автономной работы) питание, и остается включенным в сети даже, например, при полной потере электропитания контроллером, позволяя определять даже такое событие.

Для того, чтобы включить Hardware-assisted Takeover, при наличии на контроллере OS Data ONTAP 7.3 и новее, дайте в консоли команду

fas> options cf.hw_assist.enable on

Для того, чтобы изменить IP-адрес для получения партнером уведомлений об отказе, используйте команду (по умочанию это адрес порта e0a):

fas > options cf.hw_assist.partner.address <IP or hostname>

Подробнее смотрите во встроенной документации на систему Data ONTAP вашей версии, по словам ‘hardware-assisted takeover’.

Простая как мычание формула “быстрее – значит лучше” завладела умами в Enterprise также крепко, как в массовом рынке “больше мегагерцев – значит лучше” (или “больше мегапикселей – значит лучше”). С появлением на рынке новой спецификации интерфейса 8Gb/s FC начал раскручиваться новый виток этой маркетинговой истерии. “А у вас еще не используется 8Gb/s? Тогда мы идем к вам!”.

Однако нужен ли он на самом деле в конкретно вашей задаче, и даже более того, готовы ли вы, и ясно представляете ли себе все скрытые “засады” от перехода на 8Gb/s FC, стоящие за простым “увеличением вдвое скорости FC”?
Ранее в этом блоге я уже отвечал на первую часть этого вопроса, и показывал, что пока ваши приложения не уперлись в bandwidth нынешнего интерфейса, расширение вдвое полосы пропускания незагруженного интерфейса по сути равно расширению вдвое полосности автодороги, по которой проезжает один грузовик в минуту. Скорости грузовика от пункта А в пункт Б это не увеличит, а цену дороги (и стоимость доставки груза, в результате) увеличит несомненно.

На вторую часть этого вопроса, о скрытых “засадах” перехода, о которых вы, возможно, не задумывались, отвечает инженер NetApp Archie Hendryx в его блоге на сайте NetApp Communities.

Например, вы можете столкнуться с тем, что пассивная FC-инфраструктурв (кабели, патч-панели и прочее), нормально работавшие на 4Gb/s, будут сыпать CRC errors, Protocol errors, Code violations, которые могут снизить реальную скорость передачи данных по FC-сети даже ниже ранее нормально работавших без retry и ошибок каналов 4Gb/s. Те проблемы, например несоблюдение правильных углов перегиба волокна, или незначительное загрязнение концов оптических pigtails (пыль, отпечатки пальцев), которые никак не влияли на работу 4Gb/s FC, могут быть серьезной проблемой для более “строгого” к соблюдению спецификаций 8Gb/s FC. И если в небольшой инфраструктуре вы можете, крякнув, вписать в бюджет следующего года полную прекладку или аудит кабельного волокна, увеличив в разы, по результату, стоимость такого “апгрейда”,  то в больших инфраструктурах это, зачастую, просто физически невозможно.

Ранее нормально работавшая годами без вмешательства FC-инфраструктура может стать ежедневным источником головной боли, и непрекращающейся борьбы с загадочно вылезающими то тут, то там проблемами. Следует трезво понимать и представлять себе такую опасность, и быть готовым к ней. А как первый шаг – задаться вопросом из другого рекламного ролика: “А если не видно разницы – то зачем платить больше?”

Я уже упоминал вам понятие Right Sizing. Это размер дисков в секторах, который принято брать при создании RAID, и обычно он несколько меньше доступного физического объема дисков.
Почму так важно использовать именно рекомендованный вендором сстем хранения right sizing, и “своими руками” уменьшать емкость дисков, доступную на системе хранения?

Вот вам пример – два диска, разных производителей, оба считающиеся “600GB SAS” (p/n X422A-R5), но при этом второй больше первого на 12117MB.

RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)

Казалось бы пустяк, но совсем не пустяк, если ваш  RAID собран без учета right sizing из дисков бОльшего размера, а на замену вышедшему из строя приехал меньший по размерам. Он просто не сможет встать в RAID, так как для использования в RAID заданный размер диска в секторах (графа Used blcks) должен быть точно равен во всех дисках, входящих в RAID. Именно для этого выбирается некое “наименьшее общее”, для всех типов поставляемых вендором дисков данного партномера, и именно исходя из этого размера строится RAID.

В данном случае, как вы видите, выбран размер в 560000 MB или 1146880000 блоков.

Этот размер и принято называть Right Sizing, и именно исходя из этого размера, а не макетинговых чисел типа “600GB” правильно считать емкость дисковой системы.

Ну, потихоньку-полегоньку надо начинать привыкать к “восьмерке”.

Еще 3 сентября на NOW появилась версия под названием 8.0.1RC1 и я уже сталкивался с некоторым непониманем того, что такое теперь у NetApp RC.

Если вы знакомы со старой моделью именвания релизов, то помните названия GA – General Availability и GD – General Deployment.

Начиная с июня 2010 года, то есть с версии 7.3.4 и также для всех дальнейших 8.0.х действует новая, упрошенная модель именования релизов. Теперь, если по простому, то нынешний RC это старый GA, а нынешний GA это старый GD.
Теперь версии будут называться RC – Release Candidate, наиболее свежие версии, опубликованные, протестированные, и предназначенные для  ознакомления, использования и годные для установки в продакшн; и GA – General Available, протестированные всеми способами, в том числе подтвержденные на “пять девяток”, что занимает определенное дополнительное время, и GA становятся доступны несколько позднее. Добавление функциональности между RC и GA не производится.

Что же добавилось в 8.0.1?

• Поддерживается новое “железо”, о котором нам объявят в ноябре.
• Появилась поддержка Flash Cache АКА PAM-II, который не поддерживался в версии 8.0.0, что многих сильно огорчало. Теперь поддержка есть для всех PAM, причем как для 7-Mode, так и для Cluster-Mode.
• Теперь есть поддержка SMB 2.0 для 7-Mode. Ранее она была доступна только в “семерке”, а недавно опубликованные результаты показывают значительные преимущества использования SMB 2.0, причем в сетях с задержками в десятки миллисекунд (например распределенные и соединенные через WAN и VPN сети Windows ) разница в производительности с SMB 1.0/CIFS по настоящему огромная.
• Теперь возможно использования root vol (vol0) на 64-bit aggregate, то есть нет нужды держать отдельный “старый” маленький aggregate только ради root vol, жертвуя минимум двумя-тремя дисками на каждом из двух контроллеров. Однако помните, что это не позволит вам “откатиться” на старую версию, только с полной переустановкой системы.
• Появилась поддержка в 7-Mode возможности Volume Snapmirror Compression, которая уже была в наиболее свежих версиях ONTAP “седьмой” ветки, а также (ограниченно) поддерживается Multistore (на уровне 7.3.2). Правда Data Motion для vfiler, базирующийся на функциональности 7.3.3, пока не поддерживается.
• Зато (в 7-Mode только) появилась возможность под названием Data Motion for Volumes, при котором можно мигрировать тома, содержащие LUN (то есть только блочный доступ), не прерывая к ним доступа, на ходу, на другие aggregates. Обратите внимание, типы aggregates должны быть одинаковы, то есть это НЕ способ мигрировать с 32-bit на 64-bit. Средство преобразования типов aggregates вновь обещается, и вновь задерживается.
• Увеличен верхний лимит длины RAID-группы типа RAID-DP для SATA: с 16 до 20.
• В 7-Mode поддерживается онлайн-компрессия данных на WAFL, но только на 64-it aggregates.
• Наконец то увеличен размер тома, на котором возможна дедупликация, для всей линейки, начиная с 2040 (напомню, что 2020 и 2050 в 8.0 не поддерживаются), теперь дедупликация возможна на томе размером 16TB, для всех контроллеров (только для 7-Mode).
• Поддерживается VAAI – VMware vStorage API for Array Integration, новый API для offload операций хранения с хоста VMware ESX, например создание eager zeroed thick volume, а также новый метод локирования данных на LUN при совместном к ним доступе через VMFS (только для 7-Mode).
• Много добавлений по мелочи, например появилась поддержка CDP – Cisco Discovery Protocol, полезного для разбирательств с сетевой инфраструктурой. Команда работы с VIF (Virtual Interface, нетапповским названием для EtherChannel) теперь не vif, а ifgrp. Появилась полезная команда storage show fault, а также поддержка SSL v2 и v3.

Пока нет:

• IPv6
• SnapLock
• Не изменились доступные данному типа контроллера размер 64-bit aggregate, то есть по прежнему: 2040 – 30TB; 3040,3140,3160,3070 – 50TB; 6030,6040,3170 – 70TB; 6070,6080 – 100TB.

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

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