about NetApp

Часто приходится сталкиваться с принципиальным непониманием у клиентов разницы между NAS и SAN-подключением внешнего дискового массива.

??так, что есть что, чем отличается друг от друга и какие плюсы-минусы у каждого.

NAS хорошо знаком большинству пользователей, использующих в локальной сети своей организации файловый сервер. Файловый сервер - это NAS. Это устройство, подключенное в локальную сеть и предоставляющее доступ к своим дискам по одному из протоколов “сетевых файловых систем”, наример CIFS (Common Internet File System) для Windows-систем (раньше называлась SMB - Server Message Blocks) или NFS (Network File System) для UNIX/Linux-систем.
Остальные варианты встречаются исчезающе редко.

SAN-устройство, с точки зрения пользователя, есть просто локальный диск.
Обычные варианты протокола доступа к SAN-диску это протокол FibreChannel (FC) и iSCSI (IP-SAN). Для использования SAN в компьютере, который хочет подключиться к SAN, должна быть установлена плата адаптера SAN, которая обычно называется HBA - Host Bus Adapter.
Этот адаптер представляет собой с точки зрения компьютера такую своеобразную SCSI-карту и обращается с ней так же, как с обычной SCSI-картой. Отсылает в нее команды SCSI и получает обратно блоки данных по протоколу SCSI. Наружу же эта карта передает блоки данных и команды SCSI, завернутые в пакеты FC или IP для iSCSI.

На приведенном рисунке вы видите 1 диск, подключенный с NAS-устройства (внизу), и один диск, подключенный по SAN по протоколу iSCSI.

Здесь мы видим, как SAN-диск виден в диспетчере устройств. Microsoft iSCSI Initiator это софтверный (программный) адаптер протокола iSCSI, представляющийся системе как SCSI-карта, через которую идет обмен данными с SAN-диском.
В случае FC на его месте находился бы HBA FC, он тоже является с точки зрения OS “SCSI-адаптером”.

Когда мы подключаем компьютер к SAN, нужно сделать rescan all disks и вскоре в Disk Manager появится новый неотформатированный раздел. На нем обычным образом можно создать партицию, отформатировать ее и получить локальный диск, который физически будет являться выделенным разделом на большой системе хранения и соединяться с компьютером оптическим кабелем FC или сетью gigabit ethernet в случае использования iSCSI.

Каковы же плюсы и минусы обеих этих моделей доступа к данным системы хранения?

• NAS работает поверх локальной сети, используя обычное сетевое оборудование.
• Он работает преимущественно с файлами и информацией, оформленной как файлы (пример: документы общего пользования, word- и excel-файлы).
• Он позволяет коллективное использование информации на дисках (одновременный доступ с нескольких компьютеров).

• SAN работает в собственной сети, для использования которой нужен дорогостоящий Host Bus Adapter (HBA).
• Он работает на уровне блоков данных. Это могут быть файлы, но это могут быть и нефайловые методы хранения. Например база данных Oracle на т.н. raw-partition.
• Для компьютера это локальный диск, поэтому коллективное использование информации на SAN диске обычно невозможно (или делается очень сложно и дорого).

Плюсы NAS:

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

минусы NAS:

• невозможно использовать “нефайловые” методы.
• доступ к информации через протоколы “сетевых файловых систем” зачастую медленнее, чем как к локальному диску.

Плюсы SAN:

• можно использовать блочные методы доступа, хранение “нефайловой” информации (часто используется для баз данных, а также для почтовой базы Exchange).
• “низкоуровневый” доступ к SAN-диску обычно более быстрый, чем через сеть. Гораздо проще сделать очень быстрый доступ к данным с использованием кэширования.
• Некоторые приложения работают только с “локальными дисками” и не работают на NAS (пример - MS Exchange)

Минусы SAN:

• трудно, дорого или вовсе невозможно осуществить коллективный доступ к дисковому разделу в SAN с двух и более компьютеров.
• Стоимость подключения к FC-SAN довольно велика (около 1000-1500$ за плату HBA). Подключение к iSCSI (IP-SAN) гораздо дешевле, но требует поддержки iSCSI на дисковом массиве.

??так, что же общего между этими двумя методами? Оба этих метода используются для “сетевого хранения данных” (networking data storage).

Что из них лучше? Единственного ответа не существует. Попытка решить задачи NAS с помощью SAN-системы, как и обратная задача, зачастую есть кратчайший путь потратить большие деньги без видимой выгоды и результата. Каждая из этих “парадигм” имеет свои сильные стороны, каждая имеет оптимальные методы применения.

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

Приведенные ниже под катом результаты могут вас шокировать, оскорбить ваши чувства или иным способом задеть ваши убеждения. (Это Disclaimer такой, да;).

??менно по этой причине я стараюсь не заниматься сталкиванием вендоров в тестировании и не поддерживать Holy War. Но уж что выросло, то выросло.

Читать запись полностью »

Вполне возможно мне уже удалось заинтересовать некоторых моих читателей возможностями систем хранения Network Appliance. Однако одно дело слушать рассказы, а совсем другое - попробовать самому, ибо “даже маленькая практика стоит большой теории”.

?? тут я хотел бы рассказать о существовании поистине уникального для рынка систем хранения продукта - Симуляторе системы хранения NetApp. 

Пожалуй самым правильным будет процитировать тут заметку Dave Hitz в блоге NetApp об этом продукте:

Несколько лет назад мы начали получать жалобы от системных администраторов, которые использовали системы NetApp, примерно такого вида:

“Мне хочется попробовать новые возможности вашего нового релиза Data ONTAP, но все мои системы в продакшне, а мой босс не хочет покупать “железо” для моих экспериментов”

Чтобы решить эту проблему мы выпустили “ONTAP Simulator”. Симулятор это полная версия Data ONTAP, которая работает как процесс под Linux. Вместо реальных жестких дисков она открывает файлы с именами disk.1, disk.2 и так далее. Вместо физической сетевой карты она перехватывает raw-пакеты из Linux ethernet-драйвера.

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

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

Сперва люди только игрались им, но некоторые пользователи вскоре сумели сделать кое-что посерьезнее. Они используют симулятор для тестирования сложных конфигураций, включающих в себя системы с кластеризацией, удаленным реплицированием и долговременным архивированием информации, все с помощью нескольких симуляторов в одной Linux PC. Пользователи сообщали мне, что оказалось гораздо проще и быстрее найти ошибки конфигурации на симуляторе, чем если бы это было на реальном оборудовании, и это могло быть сделано еще до того как это реальное оборудование было куплено, привезено и установлено.
Пользователи используют симулятор также для того, например, чтобы познакомиться с новой версией OS Data ONTAP до апгрейда, для проверки как это заработает в их сетевой структуре и для отладки скриптов управления. Пользователям даже удалось выловить несколько багов Data ONTAP. За исключением низкоуровневых драйверов, симулятор в точности тот же самый код, что работает в реальном Data ONTAP, так что вы видите ровно то, как поведет себя реальная система. (С некоторыми исключениями: симулятор медленнее, у него жесткий лимит по доступной дисковой емкости, и мы не эмулируем FС, так что блочный доступ может быть только iSCSI).

Симулятор также “взросл” как и сам ONTAP. Когда мы были маленькой компанией-стартапом, мы сделали симулятор еще до того, как получили реальное “железо”. Позже инженеры обнаружили, что чаще быстрее и проще запускать эмулятор, чем загружать новую OS в реальную систему. Кроме этого инструменты дебаггинга удобнее работали в локальном процессе, чем в “железном” устройстве. Мы использовали симулятор в разработке почти 10 лет, прежде чем придумали, что это может быть также отличным инструментом для пользователей.

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

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

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

При необходимости можно даже установить “симулятор в симуляторе”, например я на своем рабочем ноутбуке использую ONTAP Simulator запущенный внутри виртуальной машины с установленным Linux-ом, работающей на бесплатном VMware Player. Конечно быстродействие такой системы оставляет желать лучшего, однако это вполне работоспособное решение при наличии досточного количества памяти на хост-машине.
Разнообразные готовые “виртуальные машины” с установленным Linux можно свободно скачать с вебсайта VMware.

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

Что еще почитать:
Learning Oracle RAC with the NetApp Simulator
by Sachin Garg

NetApp ONTAP Simulator and ESX Server
blog.scottlowe.org

iSCSI and ESX Server 3
blog.scottlowe.org

Одним из результатов длительного технологического партнерства NetApp с такими компаниями как Oracle, Microsoft, SAP, Veritas/Symantec (и, с недавних пор, VMware) стала разработка семейства продуктов SnapManager.
SnapManager это программа, устанавливаемая на сервер, работающий с системой хранения NetApp, и позволяющая использовать функциональность снэпшотов для какой-либо прикладной системы, например MS Exchange, MS SQL Server, Oracle или SAP.

Для чего понадобилось создавать отдельный продукт для использования снэпшотов?

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

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

Путем глубокой интеграции в API соответствующих приложений SnapManager может производить всю необходимую сложную рутину согласованной работы приложения и системы хранения автоматически, сведя всю сложность настройки и управления к условным “двум кнопкам” - “Сохранить” и “Восстановить”. Все прочие формальности обеспечения взаимодействия прикладной задачи, такой как MS Exchange, Oracle или MS SQL Server, с системой хранения берет на себя SnapManager.

В настоящий момент в семейство продуктов входят:
Snapmanager for Exchange 2000/2003/2007
for MS SQL Server
for Oracle 9i and 10g on UNIX/Linux (Windows ожидается)
for SAP (on Solaris/Oracle)
for Sharepoint Portal Server.

Еще почитать:

SnapManager 2.0 for Oracle:
Leveraging NetApp Data ONTAP 7G for Database Backup, Recovery, and Clone Management
Tushar Patel Network Appliance, Inc. December 2006 | TR-3554

SnapManager 3.2 for Microsoft Exchange
Best Practices
Shannon Flynn, Network Appliance, Inc. August 2006 | TR-3233

Best Practices Guide:
SnapManager for Oracle with Oracle 9i and Oracle 10g
Blaine McFadden, Network Appliance, Inc. June 2006 | TR-3452

Одной из важных особенностей и ”интересностей” систем хранения Network Appliance является примененная в них технология снэпшотов (snapshots).

Ранее я уже писал о том, что сама технология снэпшотов в системах хранения данных была изобретена в NetApp и само слово является trademark компании, именно потому конкуренты вынуждены придумывать разнообразные собственные названия для подобных технологий, таких как PowerSnap (EMC), QuickShadow (HDS) и так далее.

Какие же технологии создания снэпшотов существуют?

Full Clone (или “Split-Mirror”)
Наиболее простое и “лобовое” решение. Мы резервируем место, равное по объему тому LUN, для которого мы хотим выполнить snapshot. При необходимости иметь несколько снэпшотов место пропорционально увеличивается.
По команде на создание снэпшота контроллер системы хранения по внутренней магистрали данных начинает быстро копировать содержимое LUN в зарезервированную область. Либо же постоянно поддерживает “зеркало” (”mirror”), а в момент “создания снэпшота” репликация основного раздела в “зеркало” останавливается (”split”)
Плюсы: наш snapshot это полная физическая копия LUN-а. На этом плюсы исчерпываются и начинаются минусы.
Минусы: Непроизводительные потери места на диске на зарезервированный под снэпшоты объем. Снэпшот не мгновенен (в случае full clone), либо удваивает количество операций записи в случае split-mirror. Время его создания зависит от объемов LUN-а (а также загрузки контроллера системы хранения). Процесс копирования сильно нагружает контроллер и приводит к значительному падению производительности системы хранения на время создания снэпшота.

Copy-on-Write (или Point-in-Time)
Попыткой решить основные проблемы снэпшота типа Full Clone явился снэпшот типа Copy-on-write. Основная идея его была такова: Если главная проблема в том, чтобы одномоментно копировать большой объем данных, то давайте будем копировать только изменяемые блоки, оставляя неизменные на своих прежних местах. При этом исходные блоки будут копироваться туда только тогда, когда прикладная система захочет их изменить. ?? вместо полной копии мы получим инкрементальную. В пул свободных блоков, зарезервированных под снэпшот, попадут только измененные в LUN-е блоки. Таким образом текущий LUN есть тот LUN как он есть, а в снэпшоте этого LUN ссылки на измененные блоки будут заменены на ссылки в пул снэпшота, на неизмененные версии блоков, скопированные туда перед их изменением.
Copy-on-Write - “Копирование-при-записи”
Плюсы: гораздо экономнее расходуется место. Нет необходимости сразу резервировать полный объем LUN-а. Один пул может обслуживать все LUN-ы системы хранения, расходуясь по мере накопления изменений.
Минусы: Кажда операция записи в случае использования copy-on-write превращается в три. Сперва прочитать исходный блок, затем перенести (записать) его в пул, и, наконец, записать блок, который мы изначально хотели записать.
То есть каждая операция записи становится операциями “чтение-запись-запись”. С соответствующим влиянием на общую производительность системы хранения.

Какое же решение использует NetApp?
Третье.
Тут следует вспомнить тот факт, что в основании системы хранения лежит собственная внутренняя файловая система NetApp под названием WAFL - Write Anywhere File Layout.
Одной из ее особенностей является то, что файловая система устроена так, что никогда не перезаписывает блоки, единожды записанные на диск, до полного удаления файла, лишь дописывая его и изменяя указатели на актуальную “таблицу размещения файлов”.

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

Ситуация в каком-то смысле обратная технологии copy-on-write, в отличие от нее мы не переносим исходное содержимое блоков “в сторону”, перезаписывая его затем. Мы наоборот, производим “перезапись” путем записи нового блока “в сторону”, оставляя прежний блок на месте, а затем просто переставляем на новый блок указатель в “актуальной” “таблице размещения файлов” (на самом деле “таблице inodes”, поскольку Data ONTAP и WAFL несет в основе своей близкую к unix-подобной схему организации файловой системы).

Что это нам дает?
Во первых количество снапшотов становится практически неограниченным. В настоящий момент количество снэпшотов на том равно 255, количество томов - 500 (на контроллер). Отсюда легко видно, что общее количество снэпшотов, которые теоретически можно использовать на системе хранения NetApp равно 127000. Это значительно выше обычного числа в 8-14 снэпшотов на систему для большинства конкурентов.
Второй момент заключается в том, что снэпшоты не ухудшают параметры системы хранения при своем создании и использовании. ??менно это ухудшение вызывает необходимость ограничить количество снэпшотов на систему хранения в случае снэпшотов вида copy-on-write.
Третий момент - снэпшоты занимают на диске ровно то место, которое равно по объему изменениям между снэпшотами. То есть не объем LUN-а и даже не объем зарезервированного pool-а. А просто объем изменений. Нет изменений - место не занимается. Точка.
Ну и наконец немаловажный факт - снэпшоты в системах хранения NetApp есть всегда и при этом бесплатны. Они просто есть. Это такое же свойство файловой системы WAFL и OS Data ONTAP как, например, hardlinks и softlinks в линуксной Ext2FS. ??ми можно не пользоваться, но они все равно есть.

Дополнительных денег стоят как правило какие-то дополнительные функции для использования снэпшотов, например SnapRestore для восстановления тома целиком, SnapManager - ПО для использования функциональности snapshots с прикладной задачей, такой как Exchange, Oracle или MS SQL или SnapDrive - ПО для управления, создания и использования снэпшотов непосредственно с хост-сервера Windows или UNIX/Linux. О практическом использовании снэпшотов в дополнительных программных продуктах, использующих возможности снэпшотов в системе ханения NetApp, и о том, что эти продукты дают на практике я еще подробнее напишу отдельным постом.

 Еще почитать:

File System Design for an NFS  File Server Appliance 
Dave Hitz, James Lau, & Michael Malcolm | Network Appliance | TR 3002

BEST PRACTICES GUIDE FOR DATA PROTECTION WITH FILERS RUNNING FCP
Nick Wilhelm-Olsen, Brett Cooper | October 1, 2002 | TR3202

Oracle9i for UNIX:  Backup and Recovery Using a NetApp Filer in a SAN Environment
Richard Jooss | Brian Casper | 04/2004 | TR 3210

Guidelines for Using Snapshot Storage Systems for Oracle Databases
Nabil Osorio and Bill Lee, Oracle Corporation October 2001

Сравнительные результаты систем FAS270 и FAS3020

 Перед чтением рекомендую ознакомиться с дисклеймером

Читать запись полностью »

“Скорость FC вдвое(вчетверо) быстрее iSCSI”. Так ли это?

Давайте рассмотрим подробно.

?? для начала давайте разберем что такое “скорость”.
В применении к интерфейсу передачи данных “скорость” это скорость передачи электрического сигнала в меди или оптического сигнала в оптоволокне.
Парадоксально, но факт, скорость передачи сигнала что в оптическом FC, что в медном iSCSI близка до такой степени, что мы можем разницу скорости передачи электрического сигнала на физическом уровне проигнорировать. Тем более, что существует также и “медный” FC и оптический Ethernet (например 1000Base-FX).
Таким образом на физическом уровне скорость передачи сигналов для обоих интерфейсов близка и несущественна для нашей задачи. Более того, иногда скорость сигнала в оптическом кабеле может быть меньше скорости в медном.

Где же кроется разница?

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

??так, что же с пропускной спообностью?
Давайте рассмотрим нашу проблему на примере аналогии.

У нас имеется точка А и точка Б. Расстояние между ними для упрощения вычислений - 60 км.
Скорость транспорта на дороге - 60 км/ч.
У нас в наличии имеется два автобуса, ПАЗик на 20 человек и ??карус на 40.
В точку А прибывают пассажиры, которых надо доставить в точку Б.
Если количество пассажиров оказывается, например, 40, то для доставки их из точки А в точку Б нужно одна поездка ??каруса или две поездки ПАЗика. То есть ??карус в данном случае оказывается вдвое эффективнее.
Однако если пассажиров в точке А всего 20 или менее, то неважно что за автобус мы используем, в обоих случаях мы перевезем пассажиров за одно и то же время.

При этом “скорость” будет в обеих случаях 60 км/ч, то есть оба автобуса потратят один и тот же час на перевозку человекобайта из точки А в точку Б.

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

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

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

Если приложение не обеспечивает на одном конце интерфейса количество данных, превышающее по объему 1 гигабит в секунду (и, соответственно, не потребляет их с такой скоростью), то разница для этого приложения между FC и iSCSI будет только в цене.

Примечание для экспертов: Я намеренно сейчас уклоняюсь от залезания в дебри обсуждения задержек, initiator и target queues, форматов пакетов, скорости обработки процессорами интерфейсов, “и прочая и прочая”. Цель - ухватить суть проблемы и увидеть лес за деревьями.

Создает ли ваше приложение такой траффик к системе хранения данных вы сможете и сами, просто оцените в Windows Perfmon параметр Logical Disk - Disk Reads(Writes) Bytes/sec и Disk Queue для того, чтобы понять, не возникает ли у вас “очередь” на входе на “эскалатор”.
Подробнее о измерении производительности средствами perfmon я писал ранее.

Примечания:
Цитаты:
1. “Refractive Index - все оптически прозрачные материалы имеют коэффициент преломления, равный отношению скорости света в вакууме к скорости света в материале. Для оптоволокна он равен 1,45-1,50, т.е. скорость света в ВОЛС около 200000 км/с” (тут)
2. “Скорость распространения сигнала по кабелю [Twisted Pair EIA/TIA 568] или, обратный параметр – задержка сигнала на метр длины кабеля. … Типичные величины скорости распространения сигнала – от 0,6 до 0,8 от скорости распространения света в вакууме.” (тут)

Одним из наиболее популярных т.н. “синтетических” тестов является программа IOmeter. ??значально эту программу разработали в Intel, но когда процесс разработки остановился, то были открыты исходные коды и в настоящий момент тест поддерживается энтузиастами OpenSource. ??зредка программа обновляется. В настоящий момент основные вебсайты программы это www.iometer.org и страница разработки на SourceForge.

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

Описания методики тестирования системы хранения с помощью программы IOmeter (версия 2006.07.27)

Программа состоит из GUI-фронтенда iometer.exe (есть только под windows) и генератора нагрузки dynamo.exe (бывает под windows, linux, solaris, netware), управляемого из GUI по сети.

Запускаем на сервере, к которому подключен тестируемый раздел на системе хранения, программу dynamo из комплекта поставки iometer, она будет осуществлять нагрузку для тестирования.
dynamo бывает под windows, linux, может быть собрана под solaris.

Ключи запуска выводятся по /?

Указывается компьютер (имя или ip), на котором установлен GUI frontend IOmeter. (/i )

Указывается имя “менеджера”, на котором запущен dynamo (/n ), будет показано в GUI.

Указывается имя (ip-адрес) компьютера “менеджера” для коммуникации с ним по сети. (/m )

Указывается номер порта для связи dynamo и GUI, если не указан, то будет взят по умолчанию 1066. Должен быть свободно пропущен через межсетевые экраны и файрволлы для обеспечения взаимодействия dynamo и IOmeter GUI.

Если небходимо, можно назначить исполнение на конкретном CPU (см. подсказку по /?).

Пример:

dynamo /i testadmin /m 192.168.0.10 /n generator001

testadmin - имя (или ip-адрес) компьютера где будет работать iometer
192.168.0.1 - адрес (можно dns-имя) сервера нагрузки (где исполняется dynamo)
generator001 - произвольное имя генератора нагрузки, показываемое в iometer GUI.

Если dynamo уже запущен, то при старте Iometer тот найдет присутствующие в сети Managers, покажет их и разрешит использование. При отсутствии удаленных dynamo будет запущен локальный dynamo, для тестирования локальных ресурсов.

Каждый процессор менеджера тестирования с запущенным dynamo представлен отдельным worker. На каждый worker можно назначить свой тест.
Worker это процесс, который будет исполнять тест. По умолчанию количество workers равно количеству процессоров (ядер, HyperThreading pseudo-CPUs). Но можно создать дополнительные workers кнопкой на тулбаре.
Дополнительно могут быть добавлены workers для тестирования интерфейсов локальной сети (см. тулбар).
Сброс workers и реконнект к менеджерам там же, на тулбаре.

В Iometer открываем конфигурационный файл, отключаем в параметрах открытия Managers and Workers, чтобы не искало чужих managers, настроенных в конфигурационном файле. В дальнейшем, если записать конфигурационный файл на своей тестировочной инфраструктуре, можно открывать и с настройками workers.

Выбираем нужного нам manager и его worker
В закладке Disk Targets выбираем объект, например смонтированный LUN системы хранения.
Желтым цветом показаны логические дисковые разделы с файловой системой, ДОСТУПНЫЕ НА ЗАП??СЬ.
Голубым - физические разделы без партиции на них.
Перечеркнутый значок означает, что на диске не найден тестовый файл.
Отмечаем нужный крестиком слева. На данном LUNе (в случае использования файловой системы) будет при первом запуске создан тестовый файл iobw.tst. Операции при тестировании будут проводиться с ним.
ВН??МАН??Е: по умолчанию этот файл будет занимать все свободное место на диске!
Это может занять продолжительное время при первом запуске. Ожидайте. По завершении создания файла начнется тест. При необходимости тестовый файл может быть обычным образом скопирован на другие разделы, чтобы не создавать его там заново.

Для того, чтобы ограничить размер тестирования введите размер файла в 512b-блоках в поле Maximum Disk Size. Например: “16777216″ sectors (8GiB).

Starting disk Sector, Outstanding IOs и Test Connection rate оставляем в состоянии по умолчанию.

В закладке Access Specifications в правой панели перечислены импортированные из конфигурационного файла преконфигурированные паттерны.
Выбираем worker у менеджера и добавляем для него из правой в левую панель необходимый паттерн.
Патернов одновременно может быть назначено несколько.
Каждый worker может иметь свои паттерны.
В конкретном случае добавляем только один только одному worker-у.

На закладке Results Display будем наблюдать ход теста.
Варианты вывода: Start of test - накопительный, или Last Update - последний замер. Период замера показывает движок Update Frequency (от 1 секунды до “бесконечности”). В случае “бесконечности” результаты отображаться не будут.
ВН??МАН??Е: это влияет только на отображение результатов, само тестирование непрерывно и в записанном результате будет показано наивысшее значение.

В группе Display назначены по умолчанию 6 индикаторов (от Total I/O per second до Interrupts per second). ??ндикаторы могут быть изменены нажатием на кнопку их имени. Оставим по умолчанию.

В закладке Test Setup указываем имя теста в поле Test Description (это будет занесено в лог тестирования для опознания результатов). Например ‘fc dbpattern’.
Поле Run Time - время исполнения теста. Если тест состоит из нескольких запусков, то это длительность ОДНОГО запуска. Устанавливаем 1 минута.
Поле Ramp Up Time это время “разгона” системы перед началом замера. Устанавливаем 15 секунд.
Остальные поля оставляем по умолчанию.

В Cycling Option выбираем из выпадающего списка
“Cycle # Outstanding IOs — …”
Это установит тестирование с прогрессивно увеличивающимся количеством потоков выполнения (Outstanding IOs).
В поле # of Outstanding IOs указываем
Start:1 End:256 Power:2 Exponential Stepping.
При этом количество потоков будет увеличиваться экспоненциально: 1,2,4 … 128,256.
Значение Outstanding IOs от 1 до 8 относится к очень “легким” программам, 128 и 256 - очень “тяжелым”. Целиком тест покажет нагрузочную способность в зависимости от интенсивности ввода-вывода от сервера.
Также можно увеличивать количество параллельно работающих workers, не забудьте предварительно их создать и назначить им паттерны нагрузки!
При выборе соответствующих вариантов тестирования становятся доступны поля ввода значений для этих режимов.
Каждый из таких потоков будет исполняться 1 минуту, итого 9 минут (+15 секунд ramp up на каждый тест) на полный тест паттерна.

Все готово.

Нажимаем на Start Tests (зеленый флажок в тулбаре). Если тестовый файл не был создан, то ожидаем, пока он будет создан, после чего начнется тестирование. Будет запрошено имя и раcположение файла результатов (по умолчанию results.csv). Желательно дать имя соответствующее профилю тестирования, например ‘fc dbpattern.csv’ для упрощения дальнейшего разбора.
Запустив тест пожно пойти посмотреть текущие результаты на “градусниках” в закладке Results Display.
В statusbar внизу программы отображается прогресс выполнения группы тестов.

По завершению тестирования одного паттерна перейти в Access Specifications и поменять паттерн. ??зменить описание теста в Test Setup и запустить новый цикл.

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

Одной из причин, приведших к использованию “сетей хранения” - SAN - было стремление уйти от жестко “распределеного” по серверам пространства хранения. Сервер с двумя дисками 144GB в RAID1 обладает пространством хранения в 144GB, даже если использует для своей работы значительно меньше (например 5GB OS + 15GB DB = 20GB, остаток неиспользуемого пространства - 124GB).
Но, к сожалению, использовать там где оно нужно это неиспользуемое место на локальных дисках DAS (Direct Attached Storage) для работы практически невозможно. Сейчас мы не рассматриваем разные попытки выхода из положения, например путем создания на свободном месте пространства дисков архивной “файлопомойки” с помощью DFS или просто в виде множества shares.

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

Однако довольно скоро использующие SAN столкнулись с другим вариантом непроизводительного расхода простанства.

Представим себе реальную практическую ситуацию в компании, использующей централизованный SAN-storage.
DB-админ создает новую базу данных, для размещения которой ему нужен новый дисковый раздел (LUN - Logical Unit Number - логический “диск” в SAN-сети). Текущий объем базы 10GB. Однако чтобы в случае необходимости была возможность роста объемов DB-админ намеревается просить больше. “Рост в течении года будет ну например вдвое. Ну хорошо, значит 20GB минимум, ну на всякие непредвиденные расходы попрошу еще 10. ??того 30GB. Как говорится ‘проси больше - дадут меньше’, напишу в заявке 50 GB. Должно хватить.”

Заявка попадает к администратору SAN, которому всегда есть чем заняться кроме как высчитывать место.
“Ох уж эти мне DB-админы. Куда они столько места расходуют? ?? все ходят, все просят еще и еще. Сколько там? 50GB? ?? через месяц опять придут просить увеличить? Такая морока. Ладно, нарежу им по 75GB, или даже по 100GB, чтобы два раза не вставать, может так хоть оставят в покое подольше?”

??так, реально используемые 10GB данных вольготно расположились на пространстве вдесятеро большем (ну или впятеро, если следовать заявке dbadmin). Беда заключается в том, что, несмотря на все технологические достижения SAN в области экономии пространства, то пространство хранения, которое “нарезано” на LUN-ы уже недоступно для использования, кроме как той системой, которой принадлежит LUN, даже в том случае, если оно физически не используется внутри этого LUN-а.
Дорогостоящее пространство на FC-дисках занято, хотя и не используется, и не может быть использовано там, где оно, вдруг может понадобиться. ?? так на каждом из десятков, возможно сотен, LUN-ов.

То есть мы получаем ситуацию, описанную выше с DAS, но на новом технологическом уровне и за значительно бОльшие деньги. ;)
??сследования показывают, что на современных системах хранения степень заполнения LUN-ов данными как правило от четверти до половины его общего объема. ?? это еще достаточно оптимистическая оценка.

??менно решению этой проблемы посвящена концепция thin provisioning-а. К сожалению термин этот достаточно новый, и адекватного перевода на русский для него пока не устоялось, я предпочитаю использовать словосочетание “экономное распределение”.

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

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

??спользование thin provisioning-а позволяет эффективно расходовать имеющееся пространство системы хранения, а экономия места на SAN-сторадже может выражаться во вполне осязаемых тысячах долларов, которые пожирает ежегодно бюджет IT-подразделения на неизбежное расширение емкостей хранения. При этом, прошу отметить, вы отнюдь не принуждены экономить и затягивать пояс. Нет, просто в рассмотренном выше случае про базу данных и ее админа, dbadmin получит свои 50GB, по крайней мере размер выделенного LUN-а ему будет такой. Однако из свободного пространства системы хранения вычтется те 10GB, которые он займет своей базой. Ну а когда через год она у него подрастет до 20, вот тогда и вычтется 20. То есть несмотря на выделение вашей кредитной карточке банка ‘SAN Bank’ ;) лимита в 20 тысяч долларов, которые вы вправе при необходимости потратить, общий объем доступных банку в этот момент для операций средств отнюдь не уменшается на 20K$.

Если не брать во внимание “динозавров иных эпох” типа IBM MVS и прочих мэйнфреймов, первой эту идею реализовала “в железе” компания 3PAR (и следом ряд других столь же малоизвестных пока компаний: Compellent, EqualLogic, Pillar Data), а уж затем о технологии thin provisioning-а заговорили все.

Одной из первых среди крупных вендоров “первого эшелона” thin provisioning для своих систем реализовала также и NetApp, причем, как и ранее, возможности thin provisioning-а стали доступны в том числе и для ранее выпущенных систем NetApp после обновления внутренней OS.
Это стало возможным не только за счет реализации многих ключевых особенностей систем хранения Network Appliance как встроенных функций внутренней OS, но и за счет продуманной и эффективной внутренней файловой системы WAFL и структур ”виртуализованных томов” FlexVol в OS Data ONTAP G7, которые позволяют реализовать возможности концепции thin provisioning просто, “бесшовно” и с минимальным возможным ущербом для производительности.

??з известных вендоров систем хранения безусловно стоит упомянуть также системы Hitachi Tagmastore USP, в которых этим летом также, в той или иной степени, наконец была реализована идея “экономного распределения” емкости с использованием их методов виртуализации (хотя, как оказалось, и со множеством ограничений по использованию).
Для NAS эту технологию в какой-то степени реализовала и EMC в своих системах Celerra.

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

Еще почитать:

NETAPP THIN PROVISIONING: BETTER FOR BUSINESS
Paul Feresten and Quinn Summers, Network Appliance, Inc.
March 2007 | WP-7017-0307

Thin Provisioning in a NetApp SAN or IP SAN Enterprise Environment
Richard Jooss, Network Appliance, Inc.
June 2006, TR-3483

NetApp eases storage provisioning pain
By Jo Maitland, News Director
15 Nov 2004 | SearchStorage.com

Deduplication, Thin Provisioning: Top Storage Trends
By Chris Preimesberger July 6, 2007

ESG group analysis: Thin Provisioning
By Tony Asaro Senior Analyst April 2006

3PAR Thin Provisioning
By: Geoffrey Hough, Sr. Marketing Manager with Sandeep Singh, Product Manager

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

Впрочем, не поленюсь тут его повторить:

Это сделанные мной лично тесты на имеющемся у меня в лаборатории оборудовании NetApp и других компаний-вендоров. Данные тесты не спонсированы и никак не связаны с компанией Network Appliance. Результаты тестов не могут считаться официальными данными производительности, приводятся только для удовлетворения любопытства и не подразумевают никаких обещаний со стороны компании или лично меня, blah-blah-blah. Ф-фух. :)

Читать запись полностью »