about NetApp

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

Итак, в предыдущем посте я показал вам, почему "диск на два терабайта" вовсе не обладает емкостью в "два терабайта" (по крайней мере с точки зрения устройства, использующего "двоичную" арифметику. Однако в случае NetApp это не единственный "сюрприз" для новичка.

Я уже рассказывал в этом блоге, почему NeApp, наряду с некоторыми другими вендорами, использует на дисках сектор размером 520 байт, то есть на 8 байт больше, чем "традиционный", 512 байт. Использование такого сектора обеспечивает лучшую сохранность данных, устойчивость к некоторым специфическим дисковым ошибкам, и позволяет организовать, например, дедупликацию данных.
Однако использование такого сектора, и получение всех связанных с ним плюсов, также приводит к увеличению расхода raw-пространства, прежде чем оно станет usable.

Если в случае использование дисков SAS или FC мы можем просто задать необходимый размер сектора при низкоуровневом форматировании, то все сложнее с дисками SATA. Диски SATA имеют фиксированный сектор, размером 512 байт, и не имеют возможности задавать его размер произвольно, таково ограничение и негибкость протокола SATA.

Поэтому для того, чтобы обеспечить идентичный функционал как для SAS/FC, так и для SATA, в системах NetApp используется следующий метод.
Как вы уже знаете, логический сектор WAFL в OS Data ONTAP равен 4096 байт данных, то есть состоит из восьми "низкоуровневых" секторов диска. Если в случае SAS/FC мы храним дополнительную информацию о секторе в дополнительных 8 байтах на каждый из 8 секторов (суммарно на логический сектор WAFL мы получаем 64 байта таких данных), то, поскольку SATA нам такой возможности не предоставляет, мы вынуждены под хранение этих 64 байт занять отдельный сектор на диске, размером 512 байт. Таким образом, на каждые 8 секторов по 512 байт на диске SATA, мы занимаем один сектор, размером 512 байт, под хранение 64 байт служебных данных. Не слишком экономично, но у нас нет иного варианта.

Однако это, как нетрудно заметить, на 1/9 уменьшает доступную для хранения данных емкость диска SATA.

Технология "расширенного сектора" для FC и SAS-дисков принято называть "Block Checksum (BCS)", технологию "девятого сектора" - "Zone checksum" или "8/9th"

Для того, чтобы посмотреть сколько же в распоряжении NetApp оказывается емкости на диске, можно использовать команду sysconfig -r, которая покажет "правильную" (rightsized) емкость дисков в MiB и блоках.

Вот каковы результаты для диска SATA на "2TB"

Phys (MB/blks)
————–
1695759/3472914816

В прошлом посте я уже приводил выдержку из техспеки диска WDC RE4 на "2TB". В ней указывалось, что диск содержит 3 907 029 168 секторов. Почему же NetApp видит тут только 3 472 914 816?

Посчитаем:

Эффект "отбрасывания" каждого девятого сектора это будет для числа секторов коэффициент 0,88 "в периоде".
Умножим паспортное количество секторов на 0,88… и получим:

3 907 029 168 x 0.88… = 3 472 914 816 секторов размером 512 байт для хранения непосредственно данных.

Сколько же это в мегабайтах, или правильнее - в "мебибайтах"?

3 472 914 816 доступных секторов x 512 байт = 1 778 132 385 792 байт

1 778 132 385 792 байт/1024 = 1 736 457 408 kiB/1024 = 1 695 759 MiB = 1 656 GiB

Таким образом, в "двоичной арифметике", принятой в компьютере (и OS Data ONTAP в том числе), мы получаем доступной в NetApp емкость одного диска "SATA 2TB" равной чуть более 1,65 "тебибайт".

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

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

Все описанное выше не является недостатком систем хранения NetApp (как это, зачастую, желают представить некоторые из наших уважаемых конкурентов и оппонентов). Все описанное выше это не НЕДОСТАТОК, это СВОЙСТВО. Точно также, как "свойством", а не "недостатком" является описанное в предыдущем посте "уменьшение" размера диска при переходе от измерения емкости диска "в попугаях" к емкости "в слоненках".

Да, сперва нам кажется, что отдать 15% от "паспортной" емкости это довольно жестокое требование, в особенности по сравнению с другими системами, которые, как будто, такого "налога" и не требуют. Но помните, что всегда вы что-то получите назад (это свойство любых налогов, по крайней мере в нормальной стране;).

"Отобранный" у вас "каждый девятый сектор", вернется к вам более высокой надежностью хранения, возможностью использовать быстрый "RAID с двойной четностью", не страдающий недостатками "обычного RAID-6", возможностью использовать thin provisioning и дедупликацию.

В итоге, как показывает практика, вы получаете обратно в usable, заметно больше, чем эти отданные сперва "15%".
Обратите также внимание, что "15%" это только при использовании Zone Checksum на SATA.

При использовании дисков SAS/FC, использующих Block Checksum, например дисков SAS "450GB", их rightsized-емкость для системы будет равна 408,2GiB, что составляет уменьшение примерно на 9,5%.

В следующем посте мы обсудим формирование и ограничения aggregates и flexvol-ов.