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

Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

В блогах я нашел описание любопытного эксперимента (по ссылке часть 5, смотрите в тексте ссылки на предыдущие 4 части).

Автор создавал сильно фрагментированный, кусками по 2MB и 128KB (5000 и 60000 кусков соответственно), файл, общим размером 10GB, и тестировал на нем последовательные чтения и записи. В качестве дискового хранилища использовались как диски самого сервера (на графиках - DAS), так и раздел на SAN-хранилище EMC Symmetrix DMX-2.

Вот как описывает тестовое оборудование сам автор: The server was a standard DL580 with 4 single-core sockets (2.0GHz Xeon) with 4GB of RAM. The disk array was a DMX2 with 10K rpm 146GB FC drives in a RAID10 config. The test LUN was 96GB in size (with 8GB disk slices from 24 spindles). Two Emulex LP8000 HBAs were load balanced with PowerPath.

Первый результат был обескураживающим. В случае использования высокопроизводительного SAN-стораджа, результаты для фрагментированного и дефрагментированного файла, и тестирования последовательной записи блоками по 1К,  были практически идентичными. Очевидно, что эффективное кэширование и хороший запас быстродействия DMX “съели” возможное снижение быстродействия из за присутствия фрагментов.

Далее автор создал аналогичный раздел на дисках серверов (DAS), и протестировал его.

И тут мы уже видим значительный эффект от фрагментированности файла при последовательном доступе (почти 30% снижение быстродействия).

Далее автор уменьшил размеры “блоков фрагментации” до 128KB (то есть увеличил количество фрагментов своего 10GB тестового файла), и проверил эффект на последовательном чтении.

И снова мы видим, что эффект хорошо заметный на DAS, практически отсутствует на высокопроизводительном SAN-массиве.

Проявляется ли хоть как-то эффект от фрагментации вообще? Автор обнаружил лишь один параметр:

На файле размером в 10GB, состоящим из 60 тысяч хаотически разбросанных по диску фрагментов заметно выросло время Latency, задержек чтения. Обратите внимание, что для такого же 10GB-файла с 2MB блоками, разбитого на 5000 таких же разбросанных фрагментов, не было даже и такого эффекта.

И, наконец, автор измерил время ряда операций:

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

Любопытная новость обнаружилась в блоге Дейва Хитца, вице-президента, сооснователя компании, и первого блоггера NetApp (теперь в корпоративном каталоге блоггеров уже десятки имен, но он был первым,и одним из первых блоггеров в индустрии систем хранения вообще).

За прошедшие 52 недели, то есть, по простому, за календарный год (364 дня), NetApp, впервые в своей истории, отгрузила клиентам 1000 петабайт объема хранения, то есть, иначе, ровно экзабайт дискового пространства. Единица с восемнадцатью нулями байт.
Такая вот веха.

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

• sysconfig -a : показывает развернутую информацию по аппаратной конфигурации
• sysconfig -d : показывает информацию о дисках, подключенных к контроллеру
• version : показывает версию Data ONTAP OS version.
• uptime : показывает время uptime
• dns info : выводит данные по dns, такие как число попаданий в кэш dns и промахов
• nis info : выводит название домена nis, серверов yp, и т.д.
• rdfile : похоже на "cat" в Linux, используется для отображения содержимого текстового файла
• wrfile : создает/перезаписывает файл. Похоже на "cat > filename" в Linux
• aggr status : показывает статус aggregate
• aggr status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• aggr show_space : показывает использование пространства на aggreate, WAFL reserve, overheads и т.д.
• vol status : выводит информацию о томе
• vol status -s : показывает spare disks системы
• vol status -f : показывает сбойные (failed) диски системы
• vol status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• df -h : отображает использование пространства на томе
• df -i : отображает количество inode на всех томах
• df -Ah : отображает данные "df" применительно к aggregate

продолжение следует

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

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

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

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

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

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

Хочу обратить внимание моих читателей на существование специальной группы на YouTube, под названием NetApp TV. В этой группе выкладываются видеоподкасты, скринкасты и демонстрации различных технологий NetApp. Может быть интересно.
Вот, например, рассказ про новинку - NetApp Data Motion.
Data Motion это средство прозрачной и непрерывающей миграции данных (и работающей с этими данными нагрузки в виде клиентов) между системами хранения NetApp, что-то вроде того, что делает VMware vMotion для виртуальных машин, но для данных.
Требует лицензии SnapMirror и Multistore, в продакшн выходит на ONTAP 8 в начале следующего года.

Вы уже знаете, что системы хранения NetApp - мультипротокольны. В зависимости от введенных лицензий они позволяют работать с данными по протоколам CIFS и NFS (как NAS), а также по "блочным" протоколам, таким как FC, FCoE и iSCSI (IP-SAN). Но немногие знают, что кроме перечисленных протоколов, данные с NetApp также могут быть также доступны по протоколам HTTP (WebDAV) и FTP.

По умолчанию работа демона ftpd выключена. Для его включения введите в командной строке консоли контроллера команду:

> options ftpd

Вы увидите список опций, относящихся к ftpd:

Как вы видите, изначально ftpd остановлен (ftpd.enable off),вы можете включить его командой options ftpd.enable on.

Далее вы можете установить параметр ftpd.dir.override на директорию, которую вы хотите отдавать по FTP (options ftpd.dir.override /vol/vol1/my-home/my-shared-directory/). Теперь можно попробовать войти с помощью ftp-клиента и скорее всего вы увидите что-то типа 530 Login incorrect - User has no home directory., если директория, указанная в ftpd.dir.override это не корень тома. Это может означать, что пользователь, которым вы входите, не имеет так называемых traversal rights для директории, отдаваемой по FTP, поэтому вам нужно исправить это, либо если вы используете Data ONTAP 7.3.0 или старше, то в можете включить опцию ftpd.bypass_traverse_checking (options ftpd.bypass_traverse_checking on).

В заключение хочу напомнить, что протокол ftp это довольно простой и даже примитивный, в особенности с точки зрения безопасности данных, протокол. Все логины и пароли, а также содержимое файлов данных пересылается "открытым текстом", а реализованные в более современных и совершенных серверах ftp методы безопасного подключения и передачи данных в имеющемся в Data ONTAP ftpd не используются. Кроме того, надо понимать, что протокол ftp, как и сервер ftpd в системах NetApp никогда не планировался для напряженной и интенсивной работы, и, наверняка, не тестировался как следует ни на безопасность, ни на стабильность работы, играя сугубо вспомогательную роль, поэтому организовывать на нем "рапидшару", открытую во внешний интернет, наверное все же не стоит.

Источник: http://www.m4r3k.org/english/netapp/ftp-services-on-netapp/

В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.

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

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

Начиная со следующего месяца на русском языке будет “на пробу” выходить ежемесячная “электронная газета”, она же рассылка по e-mail – Tech ONTAP. Возможно, что некоторые, интересующиеся тематикой, уже получают ее на английском.

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

“Квантовый скачок” в управлении виртуальными инфраструктурами – новинки компании, объявленные на VMworld 2009: NetApp® Rapid Cloning Utility (RCU) v2.1, SnapManager® for Virtual Infrastructure (SMVI) v2.0, и Virtual Storage Console v1.0. Краткий обзор возможностей.

Пример из жизни: Консолидация серверов и хранилищ среды Windows для экономии бюджета IT – описание и анализ проекта по консолидации, осуществленного в компании Osiris Terapeutical. Практический пример перевода IT-инфраструктуры конечного клиента NetApp и VMware в виртуальную инфраструктуру, уроки и достижения этого проекта.

Ускорение репликации данных по низкоскоростным линкам – технические детали появившейся в свежем релизе Data ONTAP 7.3.2 опции компрессии трафика репликации SnapMirror, позволяющей, в ряде случаев, сэкономить до 70% трафика, и ускорить процедуры репликации данных на удаленный сайт.

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

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

С учетом того, что на сегодня на этот блог ходит в месяц три с половиной тысячи уников, из них почти две тысячи с той или иной степени регулярно, не считая подписанных по RSS,  мне кажется, что эта задача вполне достижимая.

Так что вот вам баннер, вот вам и ссылка на нем:

http://communicate.netapp.com/forms/ru-tot-regform?REF_SOURCE=EMM

Ступайте и подпишитесь. Будет интересно. Гарантирую отсутствие спама. Почтовый ящик хорошо бы рабочий (компании), но если другого нет, то пойдет то, что есть. Страна – разумеется Россия, не надо по привычке Гондурас и Зимбабве выбирать. :)

Очередная заметка “по существу” как и всегда – в четверг и понедельник.

Одной из ошибок настройки при работе кластерной системы NetApp FAS является проблема подключения к LUN через “неродной” для этого LUN-а контроллер.

Кластер контроллеров FAS работает таким образом, что каждый LUN имеет некий preferred path для доступа, будучи “привязанным” к какому-то из контроллеров кластерной пары.

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

Этот процесс снижает производительность, нагружает оба контроллера, загружает ненужным трафиком кластерный интерконнект, и ухудшает responce time и latency, поэтому работы через “чужой” узел кластерной пары следует избегать.

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

1. Определите, к какому из LUN доступ осуществляется через порт FCP target партнерской (“чужой”) ноды.
   a. lun stats -o  (LUN STATISTICS)
2. Определите какой из хостов получает доступ к этому LUN через канал партнерской ноды
   a. lun config_check -A  (LUN CONFIG CHECK)
   b. lun show -v  (LUN CONFIGURATION)
   c. igroup show -v  (INITIATOR GROUPS)
3. Определите порт FCP target основной ноды кластера, который должно использовать для доступа к этому LUN.
   a. fcp show cfmode  (FCP CFMODE)
   b. fcp show adapters  (FCP TARGET ADAPTERS)
4. Проверьте соединение инициатора хоста с основным портом FCP target и конфигурацию MPIO на хосте.
5. Убедитесь, что доступ по партнерскому пути вместо основного прекращен на обоих узлах кластера.
   a. sysstat -b 1

Убедитесь также, что настройки MPIO правильны, и не влияют на выбор пути доступа. Рекомендуется на каждом из хостов установить соответствующий host utility kit.

Оригинал текста, на основе которого сделан пост взят там: 
http://ibmnseries.blog.com/2009/10/13/partner-path-misconfigured/

Любопытные сведения найдены в блоге одного из сотрудников NetApp:

• NetApp была первой компанией из производителей систем хранения, представившей поддержку 10Gb Ethernet в своей продукции, еще в 2006 году.
• Количество отгружаемых компанией “портов” 10Gb Ethernet за год, с июня 2008 по июнь 2009 выросло на 150%
• В настоящий момент более 11% всех портов на поставляемых в системы хранения картах расширения Ehernet это порты 10Gb Ethernet.

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

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

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

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

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

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

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

С удовольствием объявляю о пополнении в русскоязычной библиотеке NetApp Best Practices на сайте компании Netwell:

Руководство по наилучшим методам использования систем хранения NetApp с MS Exchange 2007®
Brad Garvey, Shannon Flynn | NetApp | TR 3578

Руководство по установке и настройке дедупликации в системах NetApp FAS и V-Series
Carlos Alvarez | NetApp | TR-3505-0309

Один из клиентов NetApp - фотохостинг Flickr, принадлежащий ныне Yahoo, взял недавно новую высоту.
Четыре миллиарда закачанных пользовательских фотографий, при этом следует помнить, что при выбранной Flickr архитектуре хранения, каждая фотография хранится в виде 4-5 файлов разного разрешения, то есть суммарное количество файлов хранения еще в 4-5 раз больше.

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

Однако 4 миллиарда это не рекорд. Так, другой клиент NetApp, компания Facebook, хранит свыше 15 миллиардов фотографий (на апрель этого года).

Не совсем по тематике блога о системах хранения, но тем не менее весьма любопытный документ был недавно опубликован.
Те же авторы, Eduardo Pinheiro и Wolf-Dietrich Weber, их работу Failure trends in large disk drive population мы разбирали недавно, плюс Bianca Schroeder из Carnegie Mellon University, ныне University of Toronto, за ее отчет я также возьмусь в скором времени, опубликовали анализ сбоев в DRAM серверов Google, наблюдаемых в течении 2,5 лет: “DRAM Errors in the Wild: A Large-Scale Field Study”.

Результаты довольно пугающи. В среднем на каждый модуль DRAM приходилось по 3751 ошибке в год. Хороший аргумент за однозначный выбор ECC DRAM в серверах.
Из неожиданных результатов, как и в случае жестких дисков, выяснилось, что высокая температура также слабо коррелирует с вероятностью появления ошибок в DRAM.
Подробный 12-страничный документ можно взять по ссылке: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Решил сделать пост на специальную тему, порождающую много недопониманий и сложностей при конфигурировании сложных систем 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.

Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"

Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"

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

Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин.
Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах).
Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90%  места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).

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

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

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

Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они  их видит только “по номеру”.
В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один.
Ситуацию пояснят рисунки:

Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"

NetApp объявил о выпуске новой модели в линейке FAS2000, так называемых “low-enterprise class”.

Штучка получилась чрезвычайно любопытная.
Судите сами:

• Тот же конструктив (2U, на 12 дисков), что и FAS2020.
• Четыре онбордных Gigabit Ethernet порта на контроллер (8 на двухконтроллерную систему). Транкировать (в пределах котроллера) – можно.
• Онбордный SAS-порт (2 на двухголовую, соответственно), позволяющий подключать к ним новую SAS-полку DS4243 (24 диска).
• Два FC 4Gb/s остались.
• Поддержка Data ONTAP 8 (как в 7-Mode, так и в Cluster-mode (ex-GX!)).
• На 30% выше поддерживаемая емкость (136TB), чем у FAS2050 (при подключении полок расширения, конечно).
• Примерно вдвое выше производительность, чем у FAS2050 (по SPC-1 и SFS2008).
• Вдвое больше памяти и вдвое больше процессорных ядер (dualcore vs. singlecore) на контроллере.
• Максимальный размер aggregate – 30TB (на 64-bit aggregate под ONTAP 8.0), 200 томов FlexVol.

Цены… Хорошие цены, разумные, грамотные, спрашивайте у своего партнера. :) Кстати, что логично, изменились цены и на FAS2020/2050, если вас душила жаба – посмотрите, может уже можно договориться ;)

Слева направо: 2 порта FC 4Gb/s, порт SATA, system console (в RG-45), ACP (out-of-band management для SAS-полки DS4243), BMC (Baseoard Management Console), 4 порта Gigabit Ethernet.

Контроллер – взаимозаменяемый с FAS2020!
Что, вообще говоря, означает возможность апгрейда FAS2020 в 2040 простой заменой контроллера (не знаю насчет “на ходу”, но не исключено ;).

Новость слегка расстройственная для владельцев FAS2050, особенно в свете более низкой цены FAS2040, и значительно более высокой объявленной производительности. Ну что-ж, ждем FAS2070. :)
Зато на FAS2050 есть слот расширения PCIe, в который можно ставить расширения портов (2/4-port FC, 2-port GigE, iSCSI Target HBA, 2-port SAS (Disk extension) и UW-SCSI (Tape))

Кстати, немного не забыты и владельцы FAS2050. Теперь для 2050 есть 10Gbit-карта в слот расширения PCIe, которую, судя по всему, можно задействовать для FCoE.

С первого взгляда заметный минус 2020/2040 только отсутствие слота расширения, однако мощная “набивка” портами в “базе” решает большинство необходимых задач.

“Спрашивайте в магазинах города” :)

Продолжим внимательное чтение отчета специалистов Google - Failure Trends in a Large Disk Drive Population (pdf 242 KB) опубликованный на конференции FAST07, и содержащий статистический анализ отказов "популяции" 100000 дисков consumer-серий примерно за пять лет срока их службы.

Это четвертая, заключительная статья, предыдущие:
Насколько можно доверять величине MTBF?
Приводит ли большая нагрузка к повышению вероятности отказа?
Насколько полезен и стоит доверия SMART?

Мы обнаружили, что основной параметр отказоустойчивости, приводимый производителями, MTBF - Mean Time Before Failure, бесполезен, и не коррелирует вообще с реальными показателями отказов. Мы узнали, что SMART бесполезен едва ли не более, чем полезен, и что значительная часть отказов происходит без корреляции с показаниями SMART. Наконец, мы с неожиданностью поняли, что общепринятая "аксиома" о том, что высокая нагрузка повышает вероятность выхода из строя дисков - как правило, неверна.

Но главный сюрприз у нас еще впереди.

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

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

Как мы видим, повышение рабочей температуры до 40 градусов включительно приводит к снижению уровня отказов, но даже дальнейшее повышение ее до 50 и более поднимает его незначительно (отказы при температуре 50 градусов примерно соответствуют уровню отказов при температуре 30 градусов). Напротив, дальнейшее понижение температуры до 20 и менее, ведет к почти десятикратному росту отказов, относительно оптимальной температуры в 35-40 градусов!
(Большой статистический разброс результатов, показанный T-образными отметками, вызван снижением общего количества “испытуемых” дисков в предельных температурных областях)

Следующий график показывает величины отказов в зависимости от температур для разных "возрастных групп" (речь, конечно не идет о "трех годах работы" при определенной заданной температуре, так как наблюдение проводилось, как уже было сказано, в течение 9 месяцев) Результаты также подтверждают вышеприведенное наблюдение, расширяя его по "координате возраста".

"Переохлаждение" для дисков, то есть работа при температурах ниже 30 градусов (имеется ввиду, конечно же, температура самого диска как устройства, как ее определяет встроенный температурный датчик SMART), для устройств сроком до двух лет эксплуатации включительно, в два-три раза повышает величину отказов, даже по сравнению с ранее считавшимися "перегревом" температурами выше 45! Только для дисков старше 3 лет перегрев становится причиной повышенного выхода из строя. Снова видно, что для дисков, переживших 3 года, вероятность отказа сильно падает. Видимо где-то в районе трех лет проходит какая-то довольно заметная граница работоспособности.

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

Результат, по-видимому, еще стоит осмысления и оценки.

Являющиеся частью стандарта ATA, средства мониторинга и предсказания ошибок, носящие название S.M.A.R.T - Self-Monitoring, Analysis and Reporting Tool присутствуют в контроллерах всех дисков ATA (как PATA, так и SATA) с 90-х годов. По мысли разработчиков этих средств, они должны предотвратить неожиданные выходы из строя, так как SMART оценивает ряд критичных параметров диска, и пытается предсказать вероятность таких сбоев, а также ожидаемое время до сбоя.

Группа исследователей Google на протяжении 9 месяцев анализировала данные S.M.A.R.T. в 100 тысячах дисков, расположенных в его датацентрах, выявляя взаимосвязи между отказами дисков, и показаниями этой службы. Было выявлено несколько критичных параметров, события которых чаще других вызывали впоследствии отказы таких дисков.

Scan Errors

Жесткий диск обычно постоянно проверяет чтение с поверхности физических дисков, и, в случае каких-либо затруднений в этом уведомляет S.M.A.R.T. В рассматриваемой популяции примерно 2% дисков на момент начала исследования имело ненулевые показатели Scan Errors, причем такие диски достаточно равномерно распределились между различными производителями и их моделями, то есть не шла речь о заведомо дефектных партиях. На графике ниже приведены показатели вероятности отказов для дисков, имевших ошибки Scan Error, и не имевших таких, по всем рассмотренным возрастным группам.

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

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

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

Вероятность отказа после возникновения первого Scan Error, в зависимости от возраста диска.

В случае "нового" диска (с возрастом до 8 месяцев), если диск пережил первые несколько дней после регистрации Scan Error без сбоя, то вероятность его сбоя в дальнейшем относительно невелика и практически не возрастает. Однако чем "старше" диск на момент возникновения Scan Error, тем выше вероятность того, что на протяжении ближайших месяцев после Scan Error случится отказ. Для дисков возраста от года и старше, прирост такой вероятности за наблюдаемые 8 месяцев близок к линейному, что означает практическую неизбежность отказа, рано или поздно (к концу 8 месяца она дошла до 40%).

Вероятность отказа в зависимости от количества ошибок Scan Error. Рассмотрены варианты 1-2 ошибки и больше 2 зарегистрированных S.M.A.R.T. ошибок Scan Error. Множественные Scan Errors сильно увеличивают вероятность отказа, даже по сравнению с относительно высоким уровнем отказов после единичного Scan Error.

Таким образом, следует считать "пороговым" (threshold) значением для "scan error" - единицу. После первого же зарегистрированного scan error, вероятность отказа диска в следующие 60 дней становится выше в 39 раз!

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

В рассматриваемой популяции дисков ненулевое значение reallocation count имело примерно 9% дисков. Хотя некоторые диски имели значительно более высокие значения reallocation count чем другие, но, по утверждениям авторов, наблюдавшийся и описанный тренд был примерно равен для всех рассмотренных моделей и не зависел от производителя и марки дисков.

Также, как и в случае со scan error, рост этого параметра прямо связан с повышенной вероятностью отказа диска в самое ближайшее время. В среднем зарегистрированное повышение вероятности отказа составляло 3-6 раз. Эффект влияния этого параметра S.M.A.R.T. на вероятность выхода из строя хотя и был значительно менее выраженным, чем в случае scan error, но также явно фиксировался.

Графики роста уровней ежегодных отказов, в зависимости от возраста дисков, и наличия или отсутствия у них ошибок Reallocate.

Влияние reallocation на вероятность отказа в ближайшие 8 месяцев (пунктиром показаны статистические отклонения). По горизонтали - месяцы, прошедшие с момента регистрации reallocaion, по вертикали - вероятность отказа (survival probability - "вероятность выживания" - величина обратная вероятности отказа). Через 8 месяцев из популяции, имевшей хотя бы один reallocaton, остаются в строю примерно 85% дисков.

Влияние возраста диска в месяцах, на вероятность отказа после reallocation. В зависимости от общего возраста диска, меняется вероятность его отказа после возникновения reallocate.

Влияние единичных реаллокаций (от 1 до 4), множественных (выше 4) и сравнение с "контрольной группой". Множественные реаллокации, по сравнению с первой же обнаруженной, уже сравнительно мало влияют на вероятность отказа в целом, в отличие от ситуации с Scan Error.

В оригинальной работе также рассмотрены влияния на вероятность отказов таких параметров, как Offline Reallocation (вероятность отказа после такого события в 21 раз выше нормы в следующие 60 дней), Probational Counts (в 16 раз выше нормы, в следующие 60 дней) и ряда других.

Сводный график зарегистрированных S.M.A.R.T. событий в наблюдаемой группе. Суммарное количество превышает 100%, так как возможно возникновение нескольких ошибок одновременно.

Таким образом, очевидно, что, на сегодня, S.M.A.R.T., как средство Self-Monitoring, Analysis and Reporting, выполняет свою работу неудовлетворительно. Около трети сбоев (36%) в рассматриваемой дисковой популяции в 100 тысяч дисков не было никак диагностировано его средствами, и произошло внезапно для S.M.A.R.T. Анализ, проведенный группой инженеров Google, также выявил недостатки в текущей, общепринятой настройке "порогов" (threshold) срабатывания средств уведомления о предстоящей аварии, во многих случаях эти пороги следовало бы значительно поднять.

Бесспорны перспективы средств автоматического мониторинга и предсказания, встроенные в диски, однако, на сегодня, доверять безоглядно нынешним средствам, какими являются S.M.A.R.T. и системы, построенные на его базе, и строить оценку вероятности отказов жестких дисков исключительно на оценке S.M.A.R.T. не следует.

Продолжение следует.

Ранее: О надежности жестких дисков: MTBF – что это?

Приводит ли большая нагрузка к увеличению вероятности выхода дисков из строя?

В конце августа NetApp объявил о новинке в ряду своего оборудования – дисковой “полке” на 24 диска SAS. Эта полка – новый мэйнстрим, и в перспективе она планирует заменить собой все сегодня выпускаемые и используемые такого рода продукты: DS14MK2 (для дисков FC 2Gb/s), DS14MK4 (для дисков FC 4Gb/s) и DS14MK2-AT (для дисков SATA).

Продукт новый, необычный, и с перспективами, давайте смотреть подробнее.

Несколько слов о имени. Расшифровка такая: DS – Disk Shelf, дисковая полка, первая “4” – высота в 4U, “24” – 24 диска, “3” – Интефейс SAS 3Gbps.

Так как по мнению аналитиков SAS это новый лидер в enterprise-дисках, предназначенный сменить FC, то неудивителен интерес NetApp к этой области. Так, по мнению Gartner, выглядит прошлое (2007) и будущее (2012) рынка жестких дисков, а это уже совсем рядом.

Отсюда ясно, отчего NetApp проявляет большой интерес к SAS, ведь до сих пор его “мэйнстримом” были именно диски FC.

Первым опытом использования SAS в системах хранения NetApp приходится на 2007 год, когда были выпущены в свет модели FAS2020 и FAS2050, относящиеся к “low enterprise”, на которых использовались диски SAS и SATA в базовом “конструктиве”, корпусе на 12 и 20 дисков соответственно. Системы себя хорошо зарекомендовали и показали хорошие перспективы для SAS, так что новая дисковая полка это “второй выход”, уже на всем спектре выпускаемых систем, включая самые мощные FAS6000.

С набивкой дисками 1TB SATA: 24TB в размере 4U, и почти четверть петабайта raw data в стандартном 42U шкафу.

Вид дисковой полки сзади. Для варианта с дисками SAS нужна будет установка всех четырех блоков питания, для варианта с SATA – достаточно только пары.

В четыре имеющихся контроллерных слота на указанные месте ставятся новые контроллерные модули IOM3. Применение двух оставшихся слотов в настоящее время никак не описывается, и они остаются пустыми.

Контроллер IOM3 (Input-Output Module, 3GBps) это разработка NetApp, выполненная в соответствии с рекомендациями организации SBB – Storage Bridge Bay Working Group, создавшей спецификации на слот контроллера дисковой полки SAS. Потенциально любой SBB-контроллер может работать с SBB-совместимой полкой (хотя, на практике, конечно существует много способов сделать и так, что это работать не будет).  В этой рабочей группе в настоящее время состоят практически все значительные игроки рынка систем хранения, такие как EMC, Sun, NetApp, Intel, Xyratex, Infortrend, Adaptec, Emulex, Dell, LSI и другие.

На контроллерах IOM3 слева направо:
2 порта интерфейса ACP – Alternate Control Path. Это новая идея NetApp, специальный, out-of-band (независимый от канала передачи данных) порт управления контроллерами полок. Контроллеры всех полок в системе образуют по этим портам свою собственную IP-сеть управления, через которую “голова” системы может делать такие вещи, как считывать диагностику и осуществлять управление, считывать сообщения POST, а также заливать прошивку.

Данные дисков по этому каналу НЕ ПЕРЕДАЮТСЯ. Также наличие или отсутствие этого канала (обрыв, неисправность, неправильная настройка) никак не влияет на работоспособность системы и на возможность считывать и записывать данные на диски дисковой полки.

2 порта 3Gbps wide SAS. Наличие четырех портов SAS при стандартной установке двух контроллеров IOM3, позволяет организовать подключение типа Multipath High Availability (MPHA).

Более плотная дисковая “упаковка” в DS4243 позволяет получить на 30% больше емкости в том же физическом объеме (например в стойке на colocation в датацентре, per Unit).

Частый вопрос: Если раньше мы использовали 4Gbps FC, а сейчас мы получили 3Gbps SAS, означает ли это, что скорость стала на четверть меньше?
Ответ: НЕТ, не стала. На два контроллера мы имеем 4 порта так называемых “Wide SAS”  по 3Gbps, способные работать одновременно, то есть теоретическая, агрегированная полоса передачи данных с дисков достигает 12Gbps, то есть в три раза выше, чем в случае FC.
Тем не менее следует понимать, что в реальной жизни вы вряд ли увидите заметный прирост скорости по сравнению с полкой FC 4Gbps только по этой причине, как правило даже полоса в 4Gbps на современных дисковых полках используется далеко не полностью. Как я уже писал ранее, увеличение неиспользуемой части полосы пропускания не увеличивает реальное быстродействие системы. Но может быть, когда-нибудь…

Также в новой дисковой полке ниже энергопотребление “на TB” что также может пригодиться, в особенности для “больших систем”. Мы привыкли к тому, что затраты на “электричество” питания (как и “холода” кондиционеров, что взаимосвязано) считать как бы и не принято. Однако я уже приводил пример такой большой инфраструктуры хранения, как Facebook, который тратит только на электричество для питания своего оборудования в датацентрах миллион долларов в месяц. 10% экономии в этом случае могут вылиться в совсем невиртуальные деньги.

Итак, для использования новой дисковой полки в новой или уже установленной системе вам понадобится карта интерфейса SAS (2-портовая для FAS2050, 4-портовая для всех остальных) в слот PCIe, ну и, конечно, сам свободный слот в контроллере.

Думаю, что новые модели контроллеров будут уже выпускаться с “набортными” портами SAS, как сейчас обстоит дело с портами FC.

На данный момент использование DS4243 не поддерживается в системах Metrocluster, что связано с ограничениями на максимальную длину соединения SAS – 5 метров. Возможно, после появления конвертера SAS-FC эта проблема будет также решена.

Также пока нет поддержки этих полок в системах VTL.

Дисковая полка будет поставляться в двух вариантах “набивки”: полная, на 24, и “половинка” – на 12 дисков. Смешивать SAS и SATA по прежнему будет нельзя, однако “полки SAS” и “полки SATA” теперь могут сосуществовать на одной системе гораздо более гибко. Все нынешние и будущие диски NetApp будут поддерживаться в новой полке.
Также обратите внимание, что конструктив дискового “фрейма” для DS4243 несовместим с дисковым фреймом FAS2020/2050, хотя диски при этом и те же самые, однако просто снять их и переставить в новую полку нельзя.