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 параметры, и особого эффекта их настройка не приносит.

Как я уже писал раньше, начиная с 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: Да на здоровье :)

Довольно долго наблюдаю, как некоторые конкуренты NetApp указывают на то, что системы хранения NetApp якобы лишены механизма Consistency Groups. Для начала, что такое Consistency Group как таковое.

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

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

Именно для этого такие разделы данных объединяют в логическую структуру под названием Consisency Group, операции над которой следует рассматривать “в целом”, либо целиком успешными, либо целиком неудачными и “откаченными”.

Итак, Consistency Groups на NetApp. Какова же ситуация сегодня на самом деле?

Consistency Groups на системах NetApp FAS существуют с версии Data ONTAP 7.2, однако работа с ними со стороны хоста производится через специальный API (ZAPI), который предоставляет, например, ПО SnapDrive. Работать с Consistency Groups можно как непосредственно из SnapDrive (UNIX/Windows), так и вызывая средства API из скриптов, например на Perl.

В рамках этого API так называемый “агент” (это может быть или собственный “высокоуровневый” продукт NetApp, например SnapManager for Oracle, SnapCreator, или же оперирующий вызовами API самодельный скрипт):

• Отдает команду участвующим в процессе контроллеру (или контроллерам, если наша consistency group расположена на разных контроллерах): start-checkpoint.
• Контроллеры приостанавливают (fence) процесс записи на тома, входящие в заданную consistency group (CG).
• Контроллеры подготавливают snapshot для указанных томов.
• Агент получает уведомление fence-success от всех участвующих контроллеров
• Агент отдает команду commit-checkpoint всем участвующим контроллерам
• Приняв команду контроллеры производят одновременное создание снэпшотов томов в CG
• По завершении контроллеры рапортуют об успешном завершении и снимают блокирование записи (unfence).

В случае использования интефейса SnapDrive команда создания снэпшота, использующая CG очень проста.
Допустим, у нас есть база данных (/u01/oradata/prod), расположенная на LUN-ах, лежащая на томах двух контроллеров – filer1 и filer2 (filer1:/vol/prodvol1 и filer2:/vol/prodvol1). Тогда процесс создания консистентной копии в снэпшоте с использованием snapdrive будет прост:

> snapdrive snap create -fs /u01/oradata/prod -snapname snap_prod_cg

Эта команда автоматически инициирует все процессы для всех задействованных в файловой системе /u01/oradata/prod LUN-ов, скомандует их контроллерам, и создаст консистентную копию с именем snap_prod_cg.
Аналогичным образом сработает команда для консистентной копии двух разных файловых систем (u01 и u02):

> snapdrive snap create -fs /u01/oradata/prod /u02/oradata/prod -snapname snap_prod_cg

Так что утверждение, что, якобы, на NetApp нет consistency groups действительности не соответствует. Они есть, работают, и достаточно активно используются, а утверждающим это специалистам конкурентов стоит обновить свои знания о состоянии дел в продукции конкурентов.

Подробнее о Consisency Groups и работе с ними в контексте Oracle:
TR-3858: Using Crash-Consistent Snapshot Copies as Valid Oracle Backups
Очень полезный документ о работе со снэпшотами баз Oracle, использования их как резервных копий, восстановления из них, в том числе много рассматривается тема consistency groups.
Одним из авторов документа является “гуру” темы использования NetApp под Oracle, сотрудник бразильского офиса – Neto, автор весьма интересного (и что еще лучше – регулярно пополняемого) блога на сайте NetApp.

Вот уже пару лет как у NetApp в номенклатуре продуктов находится интересный, но все еще не слишком известный широкому кругу пользователей продукт – PAM – Performance Acceleration Module, а в прошлом году к нему в компанию добавился еще один вариант – PAM-II (ныне Flash Cache).

Давайте разберемся подробнее что это, чем полезно и как применяется.

Первое, что следует понимать, чтобы разобраться в том, что есть PAM и как его применяют:
PAM это не SSD!

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

Давайте разберемся, что такое SSD, и чем PAM не SSD.

Continue reading ‘PAM - Performance Acceleration Module’ »

Официально NetApp поддерживает совместимость только с UPS компании APC, до версии 7.2.1 это были модели SmartUPS (и Symmetra), с версии 7.3.2 добавились модели семейства Silcon. Вот официальный список:

После 7.2.1 официальный список был упразднен, и теперь базовая поддержка со стороны ONTAP осуществляется для всех моделей указанных выше линеек APC. Понятие “поддержка в OS” означает, что Data ONTAP может осуществить корректное завершение работы (shutdown) при использовании UPS перечисленных типов.

Используя возможности взаимодействия с UPS в ONTAP следует учитывать, что NetApp не использует SNMP Trap при работе с UPS, вместо этого он использует SNMP Get. Состояние UPS проверяется каждые 5 минут по сети Ethernet, в которую подключен UPS, с использованием SNMP. При этом Data ONTAP получает следующие параметры UPS:

• Работает ли он от сети, или находится на батареях
• При нахождении на батареях, каково оценочное оставшееся время

Когда обнаруживается переключение на батареи, интервал проверок состояния сокращается до 10 секунд. Когда уровень батарей достигает уровня, определенного как “Warning-Low” начинают поступать сообщения в систему EMS (Enterprise Messaging System), когда уровень заряда батарей снижается до “Critical-Low” отсылается сообщение в EMS и начинается процедура shutdown.

Если контроллер NetApp отслеживает состояние нескольких UPS (например отдельно для контроллера, для дисковых полок, и для сетевого оборудования), то процедура shutdown начинается при достижении уровня “Critical-Low” на любом из этих UPS.

Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились в той же IP-подсети, что и контроллер NetApp, а сетевое оборудование также должно быть подключено к UPS, чтобы, в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

Для управления UPS в консоли администратора есть команда ups:

ups add [-c <community>] <ip address>
ups [ disable | enable ] [ all | <ip address>]
ups status
ups set-limits [ all | <ip address>] <critical-time  (secs)><warn-time  (secs)>
ups print-limits [ all | <ip address>]

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

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

Алекс Макдональд, инженер NetApp, в своем блоге привел любопытную модель, оценивающую влияние фрагментации на эффективность, в случае случайного (random) по характеру доступа.

Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. И наконец он сравнил суммарное расстояние “seek” в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).

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

Несколько неожиданный для “здравого смысла” результат, однако, поразмыслив, нельзя не признать его правильным. “Случайное” помноженное на “случайное”  не дает “случайное в квадрате”. :)

Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество “вредоносного” seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

Нет времени писать на этой неделе большие трактаты. Поэтому отделаюсь маленькими заметками.

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

В одном из прошлых постов я привлекал внимание к проблеме разницы между “двоичными” и “десятичными” байтами. Ну вы помните, “программист думает, что в километре – 1024 метра”. Мы привыкли к тому, что разница эта есть, но она невелика настолько, что, как правило, ее можно проигнорировать. Подумаешь, всего 24 байта на целую тысячу!

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

Неожиданно выясняется, что разница между “Гибибайтом” и “Гигабайтом” превышает 7 процентов, а между “Тебибайтом” и “Терабайтом” – почти 10%!
Это уже более чем существенно!

Игнорировать 10-процентный эффект разницы уже нельзя. Так, например, если вы рассчитываете на 4-гигабитном канале передачи данных, скорость которого рассчитана из “двоичных байт” передавать хранимый на дисках объем данных, исчисленный из “десятичных байт”, вы получите “результат” отличающийся на более чем 7%, на каждом переданном гигабайте, просто по причине набегания этой ошибки.

Поиграть с величинами и понять масштабы проблемы можно, например, в онлайн-калькуляторе.

UPDATE: ВНИМАНИЕ! Данный текст устарел!

Решил сделать пост на специальную тему, порождающую много недопониманий и сложностей при конфигурировании сложных систем NetApp. В свое время, в бытность мою пресейлом, также много крови выпило. Поэтому решил написать "резюмирующий пост", вдруг кому пригодится.

Контроллеры систем хранения NetApp современных серий приходят с определенным числом встроенных портов FC (2 на контроллер на FAS2000, по 4 на FAS3×00, по 8 на FAS6000). Для кластерных (двухконтроллерных) систем количество удваивается. Кроме этого все модели (за исключением FAS2020 и 2040) имеют слоты расширения, куда можно установить те или иные интерфейсные карты. Однако существует ряд правил, определяющих возможные конфигурации.

Для начала о терминах.
Порты FC могут находиться в следующих состояниях:
Initiator - сторона "сервера". То, на чем работает использующее дисковый ресурс приложение, то, что “инициирует” процесс чтения или записи данных.
Target - сторона "диска". То, на чем создается и раздается дисковый ресурс, то что является “целью” для процессов чтения и записи данных, хранит их, и отвечает на запросы инициатора процесса.

В случае NetApp:
Target – a fibre channel port used for connecting LUNs to hosts or servers.
Initiator – a fibre channel port used for connecting disk shelves to the storage controller or to VTL

1. Можно ли смешивать в одном контролере карты расширения FC target(для подключения серверов) и карты расширения FC initiator, например для подключения ленточной библиотеки или дисков?

ДА

Карты расширения могут быть как target (в которые включаются хосты), так и initiator (в которые включаются дисковые полки). Обязательно проверьте по Configuration Guide, совместимость желаемых карт с вашей системой, допустимое количество устанавливаемых карт расширения определенного типа, и разрешенные для установки соответствующих типов карт слоты расширения.

2. Можно ли использовать FC-карты расширения И порты FC на контроллере для подключения к ним дисковых полок (и те и другие в режиме Initiator)?

ДА

Порты в режиме initiator могут работать одновременно, как на платах расширения, так и встроенные в контроллер.

3. Можно ли использовать FC-карты расширения как target (для подключения серверов) И одновременно использовать как target какие-то из портов FC на контроллере?

НЕТ

Использование как target-ов портов на картах расширения запрещает использование как target-ов встроенных портов контроллера. Их можно при этом продолжать использовать только как initiator-ы( подключать к ним дисковые полки).

4. Можно ли сконфигурировать часть портов многопортовой карты расширения FC как target (для подключения к ним серверов), а часть этих портов - как initiator (для подключения к ним дисковых полок)?

НЕТ

Каждая физическая карта расширения может находиться либо в режиме target, либо в режиме initiator только целиком.

5. Можно ли подключиться к части портов FC на карте расширения на скорости 2Gb/s, а к другим - на 4Gb/s?

НЕТ

Каждая многопортовая карта расширения может находиться в определенном режиме скорости FC только целиком.

6. Можно ли подключиться к портам одной карты расширения на скорости 2Gb/s, а к портам другой карты расширения - на 4Gb/s?

ДА

Разные физические карты расширения могут находиться в разных режимах скорости FC.

7. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты FC на контроллере могут произвольно находиться как в target-, так и в initiator-mode, по выбору админа. Однако установка платы расширения в target-mode запрещает использование target-mode на всех встроенных портах целиком.

8. Могу ли я использовать часть встроенных FC-портов контролера как target (для подключения серверов), а другую часть - как initiator (подключить к ним дисковые полки) даже если оба этих порта работают на одном FC-чипе (ASIC)?

ДА, но:
Если в системе нет карт расширения FC-target.

Встроенные порты 0a и 0b (а также 0c и 0d, 0e/0f, 0g/0h) обслуживаются одним ASIC-чипом на пару этих портов. Совмещать режимы для встроенных на контроллере портов можно произвольно.

Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb.
1. Мы хотим подключить к контроллеру дисковую полку.
2. Мы хотим получить на системе 4 порта для подключения к ним серверов.

Неправильное решение:
Купить 2-портовую карту в слот расширения, на два встроенных порта подключить полку, на два - сервера, и еще два сервера на два порта на карте расширения.
Карта расширения в target mode запрещает target mode на встроенных портах.

Правильное решение:
Купить 4-портовую карту, установить ее в target mode, а в два встроенных в контроллер порта включить дисковую полку. Останутся свободными еще два встроенных порта в режиме initiator, для подключения дисковых полок.

Пример:
У нас есть одноконтроллерная система FAS3140, с 4 встроенными в контроллер портами FC 4Gb/s.
1. Мы хотим подключить к контроллеру одну полку типа DS14MK4 (с дисками на 4Gb/s), и старую полку DS14MK2 (с дисками на 2Gb/s).
2. Мы хотим подключить 2 серверных хоста.

Неправильное решение:
Купить 4-портовую карту расширения, поставить ее в initiator mode, и включить в пару портов полку DS14MK4, а в пару - DS14MK2. Во встроенные в контроллер порты включить сервера.
Совмещать разные скорости FC на одной карте нельзя (но можно на встроенных портах)

Правильное решение:
Купить 2-портовую карту расширения, поставить ее в target mode, и включить в нее серверные хосты. Встроенные порты перевести в initiator mode, и включить в 2 из них DS14MK2, а в два - DS14MK4.

Ранее, в посте про надежность RAID-5 я уже писал про такой аспект дисков SATA, как надежность и величину UER (Unrecoverable Error Rate, иногда также называется UBE - Unrecoverable Bit Error).
Величина эта почти на порядок (в 10 раз) хуже, чем для дисков SAS/FC, причем причина тут конструктивная, а не просто в интерфейсе.
Однако, для небольших систем “начинающих”, в первую очередь роль играет цена.

Жесткий диск (и система хранения) характеризуется, в общем случае, двумя параметрами: емкостью (измеряется в Мегабайтах/Гигабайтах (MB/GB)), и быстродействием (измеряется в IOPS - Input-Output Operations per Second - Операций ввода-вывода в секунду ). И если емкости дисков непрерывно растут вот уже несколько лет, то показатели по IOPS замерли уже довольно давно.
Принято считать, что диск SATA дает 80-100 IOPS, диски SAS/FC - 140-160 для 10KRPM, 180-200 - 15KRPM.

Стоимость за мегабайт для дисков SATA весьма низка, на сегодня она составляет 0,17$/MB для диска SATA 1TB, однако около 0.83$/MB для диска SAS 300GB. (я оперирую ценами, взятыми из price.ru: SATA WD RE3 1TB 7200 - 170$, SAS Hitachi 300GB 15K - 250$)

Иная картина будет, если мы посчитаем стоимость IOPS-ов. Диск SATA при этом будет стоить 2,1$ за IOPS, а 15K SAS - 1.38$/IOPS

Допустим, перед нами стоит задача создать сторадж на 3 TB, при этом быстродействие его должно быть не хуже 3000 IOPS.

Рассмотрим два варианта:
Если мы рассматриваем только емкость, то будет все просто:
SATA 1TB нужно три штуки, при цене за диск в 170$ общая сумма хранилища заданного размера, без учета RAID будет 510$
Дисков SAS на 15KRPM емкостью 300GB будет нужно 10 штук, при цене за диск 250$ такая емкость будет стоить 2500$

Казалось бы вывод очевиден, SATA дешевле, причем раз в пять.
Но мы пока не учли второе требование, про 3000 IOPS.

Для быстродействия системы емкостью 3TB в 3000 IOPS, из расчета в 80 IOPS с каждого диска SATA, нам нужно распараллелить ввод-вывод не менее чем на 38 дисков. 38 дисков SATA, это будет стоить уже 6460$.
Однако для дисков SAS те же 3000 IOPS достижимы на всего 17 дисках, что стоит 4250$

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

Этот момент часто не учитывают люди, планирующие использование SATA на задачах primary storage.

Если перед вами стоит задача не просто создать емкость хранения, без учета показателей по быстродействию, что, вообще говоря имеет только одно применение - хранилище архивных и резервных копий, а систему хранения, обеспечивающую приемлемую скорость работы приложения его использующего, то вам следует забыть про гигабайты, и ориентироваться, в первую очередь, на производительность дисков, на IOPS. Необходимый объем вы получите “автоматичски”.
Сегодня, во многих случаях, при планировании системы хранения, производительность есть ее “первичное”, ключевое свойство .
Или, иначе говоря: “GB are free, IOPS cost you money” - “Гигабайты бесплатно, вы платите только за доставку ИОПСы”

Сегодня я бы хотел провести для вас своеобразный "мастер-класс говнилок", или, если угодно, "сеанс черной магии", разумеется "с последующим ее разоблачением". Я воспользуюсь для этого статьей небезызвестного блоггера Чака Холлиса, почти официального "говнильщика" компании EMC. В части "разоблачений" мне поможет Вэл Берковичи, блоггер NetApp, некоторое время назад сделавший показательный разбор одного из постов Чака.

Чак выбрал своей темой сравнительный анализ результатов получения Usable Space из Raw на трех разных платформах хранения - EMC Clariion, HP EVA и NetApp FAS. Ну за EVA, я надеюсь, вступится еще кто-нибудь, я же разберу двух оставшихся, тем более что я по EVA не спец, однако уверен, что и там вполне могут быть схожие "результаты".

Вэл очень показательно сравнивает манеры, при проведении такого сравнения с поведением фокусника. Сначала нам показывают нечто вполне обычное и привычное. Колоду карт. Кролика и шляпу. Женщину в ящике ;) Мы осматриваем их, и вынуждены согласиться, что да, никакого подвоха тут нет (обычно уже на этом этапе что-то не так, и хитрость уже спрятана, чтобы вовремя сработать).

На втором этапе фокусник превращает рассмотренные нами обычные предметы в что-то необычное. Что-то исчезает, что-то видоизменяется, и так далее. Вы потрясены.

Тут все зависит от того, хотите ли вы быть одураченными. Если да, как обстоит дело в большинстве случаев, вам ничего не остается как согласиться с фокусником: "Да все так, кролик исчезает в шляпе, а женщина перепилена", даже несмотря на то, что в глубине души вы и понимаете, что вас где-то провели. Но ведь вы внимательно следили!

В свое время, в каждом выпуске журнала “Юный Техник”, известный фокусник Эмиль Кио давал описания какого-нибудь незамысловатого фокуса (ну у него их много в запасе было), с объяснениями "как".

Попробую и я показать вам в каком месте у Чака начинается "ловкость рук".

Итак, начало, The Pledge, "предъявление предметов".

Чак предлагает нам сравнить величины Usable Space на каком-нибудь простом и знакомом примере. Например инфраструктура хранения для MS Exchange.

Возьмем для примера шляпу диски FC 146GB, определим, что мы хотим получить на выходе пространство, равное емкости 120 дисков (около 17,5TB), и посчитаем, сколько дисков нам придется купить для системы, чтобы эти условия соблюсти.

Мы берем руководства Best Practices по установке для соответствующих систем, и начинаем, оперируя ими, рассчитывать пространство, "делать сайзинг" как это называется у нас.

Повторюсь, я не слишком большой спец в области конфигурирования EMC, поэтому я просто возьму анализ для CX4 самого Чака. Я не стану переписывать тут весь его пост, за подробностями можно пройти непосредственно к нему, покажу лишь сам принцип. Итак, перед нами стоит задача получить на выходе usable-емкость 120 дисков на 146GB. Что добавится к этой величине?

Диски hotspare - EMC рекомендует иметь 1 диск hot spare на каждые 30 дисков данных.

Пространство для snapshots - возьмем эту величину равной 10% от usable

Секторный оверхед - Clariion также как NetApp FAS использует увеличенный до 520 байт сектор, то есть примерно 1.5% к пространству usable.

Но что это? Внимательный взгляд уже видит первую ловкость. Отчего это Чак берет в качестве типа RAID для такой большой системы - RAID-5?

Даже если вас не убедила моя "дюжина ножей"(пост раз и пост два) в спину RAID-5, довольно будет и того, что это не рекомендует даже сам EMC в тех самых Best Practices, на которые сам же Чак Холлис и ссылается:

страница 15, документ #H4060, Oct. 2007:

It is generally accepted that RAID 1/0 is a better choice for random-write environments like Exchange

В том числе это так и для DMX (стр. 7-49):

http://www.emc.com/collateral/hardware/solution-overview/h4067-microsoft-exchange-server-symmetrix.pdf

As a matter of Best Practice, EMC generally recommends RAID1 to be the primary choice in RAID configuration for reasons of reliability and availability and performance for high-end deployments of Microsoft Exchange Server.

Вот он, трюк. Сейчас посмотрим, что получится в результате.

Кроме этого, Чак еще пару раз "забывает" о некоторых моментах, так, например, говоря о рекомендации делать right sizing на 10% для дисков в RAID на NetApp, для того, чтобы, при необходимости, можно было ввести в RAID диск слегка отличающийся по "геометрии", например спустя несколько лет, если поставляемые на замену диски отличаются от оригинальных в количестве секторов, он напрочь "забывает" это учесть в своем расчете для CX4, несмотря на то, что на это прямо указывается в Best Practices EMC.

Также не забудем и про пресловутый Vault на первых 5 дисках. Если в случае использования RAID-5 у нас были шансы использовать этот маленький пятидисковый RAID-5 в составе системы, также целиком выполненной в RAID-5, то в случае RAID-10 деть этот небольшой RAID-5 нам некуда, придется не использовать его для данной задачи вовсе.

Использовать же эти 5 дисков в составе большого RAID-10 нельзя, так как Vault на них уменьшает их "аппаратную геометрию", и они становятся "несовместимыми" по размерам с остальными дисками системы. То есть минус 5 дисков целиком.

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

Что же у нас получилось?

А вот что:





Разительная разница по сравнению с цифрами, приведенными у Чака, не правда ли?

"Ловкость рук, и никакого мошенства".





 

Теперь займемся нашим NetApp FAS.

Исходные данные те же.

120 дисков по 146GB емкости в Usable, сколько должно быть в Raw?

Исходный ход расчета Чака оставим без изменений, но будем опять внимательно смотреть "за руками".

Вот оно!

One thing is extremely clear — running out of snap reserve looks to be a very bad thing in a NetApp environment — there’s no place to put an incoming write, usually resulting in catastrophic application failure.  By comparison, other approaches (e.g. CX4 and EVA) simply stop trying to capture before-write data if you run out of reserve — the application itself continues to run.

…

It is recommended to have a 100% space reservation value set for volumes hosting LUNs containing Exchange data.

Разумеется в таком анализе не обойдется без традиционной спекуляции на тему 100% LUN space reservation. Как-то даже слишком предсказуемо.

Обязателен, неизбежен и абсолютно необходим ли 100% space reservation, как необходимо отдать 100% от объема data disks при создании RAID-10?

НЕТ.

Вы не можете уменьшить количество дисков, уходящих под "зеркало" в RAID-10, в котором Usable еще до всех "вычетов" всегда будет менее 50% от Raw.

Однако можете уменьшить количество места, отдаваемое под fractional LUN reservation в NetApp FAS, так как его уменьшение не ведет к неработоспособности.

Я уже останавливался ранее на том, что же скрывается за fractional (LUN space) reservation.

Скажу честно, тема непроста, но понять ее можно. Вот, если вкратце, на пальцах:

LUN space reservation это место, выделяемое и резервируемое на томе в том случае, если вы планируете использовать snapshot для LUN,и есть риск, что значительная часть объема этого LUN будет перезаписана. В этом случае резервирование пространства размером с весь LUN гарантирует нам то, что можно будет создать snapshot с этого LUN и место для нормальной работы с этим LUN-ом еще останется.

По умолчанию, руководствуясь правилом "прежде всего - не навреди" Data ONTAP действительно предлагает наиболее "консервативную" установку, в виде 100% reserve, гарантирующую, что даже если админ совсем ничего не понимает, и ставит систему Enter-ом, соглашаясь со всеми дефолтными настройками, то ничего смертельно опасного для его данных при работе не произойдет.

Означает ли это, что никаких других возможностей не предусматривается? Нет, не означает.

Можно ли не использовать 100% LUN space reservation, и чтобы при это все работало? Да, запросто.

Какие еще возможности есть? Можно, например, автоматически увеличивать размер тома, на котором расположен LUN, с тем, чтобы места хватало и на LUN, и на создаваемые Snapshots. А можно настроить автоматическое удаление старых снэпшотов, при создании более новых, если им не хватает места.

Ну и, наконец, если места не хватило, то предусмотрена возможность корректного автоматического размонтирования LUN-а, на котором невозможно продолжать запись.

И все это - без необходимости резервировать 100% от usable space под LUN space reservation.

Давайте посчитаем по нашей методике raw space, взяв желаемый usable добавим к нему все "вычеты", "оверхеды" и "резервации", добавим диски parity RAID из расчета 2 диска на каждые 14 дисков (RAID-DP), и, наконец, hot spare (два на первые 100, и по два на каждые следующие 84), и посмотрим что получилось (все дробные величины округлялись в большую сторону до целочисленных значений, указанные на диаграмме значения показывают доли секторов диаграммы и не всегда равны процентам в таблице).





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

EMC_vs._NetApp.xlsx

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

1. Представить себя как "независимое лицо", незаинтересованное в определенном "предвзятом" результате. Например проведите сравнение параллельно для нескольких вендоров.
2. Продемонстрировать все исходные материалы, упирая на их доступность.
3. Всегда аппелировать к вендорским Best Practices, пусть даже отдельные части их и будут проигнорированы, а сами они могут быть "outdated", устаревшими. Мало кто полезет проверять все подробности в 150-страничном PDF-е, в лучшем случае прочтет указываемое вами предложение в тексте, зачастую без контекстной связи.
4. Всегда сравнивать системы в выгодном для себя контексте. Ваша система имеет низкую производительность? Сравнивайте на задачах архивного хранения и резервного копирования. Система высокопроизводительна, но дорогостояща? Сконфигурируйте минимально возможную, пусть и неприменимую в реальной жизни конфигурацию. Малопроизводительна, но дешева? Активно пользуйтесь сравнением соотношения price/performance. Владея инициативой при написании документа - заставьте противника обороняться на неудобном для него поле.
5. Не забудьте о психологическом давлении и субъективности восприятия. Хорошее название для сравнительного документа "Вся правда о…". Почаще упоминайте "свободность" и "открытость" (“хорошо!”) в пику "проперитарности" и "закрытости" (“плохо!”).
6. Проводя в тексте нужный трюк, постарайтесь отвлечь от него внимание, например ссылками на какие-либо документы, или цитаты авторитетов. Актуальность их обычно не проверяется. Хорошо работают графики таблицы, иллюстрирующие ваши выводы, тем боле, что чаще всего перепроверять данные никто не полезет.
7. Отлично работают: “правильная” группировка результатов, а также маленькие хитрости, типа смешивания единиц измерения, неуказание единиц, нелинейная шкала отображения для графиков, и так далее.