about NetApp

Начиная с версии 3.0 флагманский продукт компании VMware - ESX Server поддерживает три типа подключения внешней дисковой системы: FC, iSCSI и NFS.
На сегодняшний день примерно 90% инсталляций VMware используют FC. В оставшихся 10% царит iSCSI, а на долю NFS пока приходится совсем малое количество систем.
Отчего так?

Причин я вижу две. Во первых, поддержка подключения дисковых систем хранения по NFS появилась только в ESX 3, то есть сравнительно недавно. А enterprise-сисадмины существа подозрительные, недоверчивые, злопамятные и консервативные (привет, коллеги!).
?? во вторых, в среде IT все еще довлеет мнение, что NAS “это что-то такое несерьезное, коробка от списанного сервера под столом, с виндой или линуксом, для хранения экселевских файлов нашей бухгалтерии и mp3-шек”, устройство, с обычным названием, хорошо отражающим отношение к ней сисадмина - “файлопомойка”. Какое там enterprise, работает и ладно.
Однако с известных пор, и стараниями известной вам компании, все это уже не совсем так.

Как это сделано:

Если у вас есть NAS работающий по NFS, например любой NetApp, или, возможно, EMC Celerra (хотя, как вы догадываетесь, и не все NAS “одинаково полезны”), то вы можете подключить созданный на нем дисковый ресурс как “сетевой диск” по протоколу NFS.

При этом вы НЕ используете VMFS (собственную файловю систему VMware для ее datastores), вы НЕ создаете LUN и НЕ монтируете эти LUNы ни в ESX (традиционный способ VMFS/LUN), ни в виртуальную машину (способ RDM/LUN - Raw Disk Mapping).
Вы получаете для своего ESX “сетевой диск”, и просто размещаете на нем файлы виртуальных дисков vmdk и vmx так, как будто это локальный диск вашего ESX, отформатированный в VMFS.

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

?? все? ?? все.

Чем вы платите:

1. Примерно, в среднем, 5% производительности на дисковых операциях.

2. Примерно, в среднем, 5% большей загрузкой процессоров хост-серверов ESX.

?? то и другое приведено на максимально возможной и максимально тяжелой тестировочной нагрузке, заметно превышающей существующую в реальной жизни.
Официальные результаты сравнения быстродействия протоколов от VMware тут: http://www.vmware.com/files/pdf/storage_protocol_perf.pdf
Там много интересных подробностей, но если лень читать - примите вышеприведенные цифры.
Чуть более подробный документ, совместное исследование той же темы NetApp-ом и VMware тут: http://media.netapp.com/documents/tr-3697.pdf

Что вы получаете (плюсы):

1. Простое и эффективное использование всех фич NetApp, таких как thin provisioning (динамическое выделение пространства тому по мере его потребности в месте, а не сразу в момент нарезки тома или LUN), дедупликация, снэпшоты. Почему, и за счет чего это так, я остановлюсь отдельно.

2. Эффективное “умное” кэширование, в том числе и с использованием PAM (Performance Acceleration Module).

3. Легкое управление: создание, удаление, перенос, резервное копирование и восстановление.

4. Отказоустойчивость и “многопутевость” подключения, обеспечиваемая отказоустойчивостью IP.

5. В ближайшей перспективе возможность использования 10Gb Ethernet. (Ну, как “в перспективе”. Купить 10Gb, в том числе и порты расширения этого стандарта в NetApp вы можете уже сейчас, разве что это пока все же дороговато. Хотя, наверное, не намного дороже, чем перейти на 8Gb FC. А то может и дешевле уже.)

6. В еще большей перспективе вы можете использовать сверхвысокопроизводительную многоузловую grid-систему Data ONTAP GX, которая сейчас уже доступна и работает в качестве NFS NAS (но пока очень ограниченно применима как SAN).

Что вы не получаете (минусы):

1. Вы, скорее всего не сможете использовать VCB (VMware Consolidated Backup) - автономную бэкап-систему VMware ESX.
Довольно сомнительный на мой взгляд недостаток, учитывая примитивность самого VCB, с учетом наличия при этом, как альтернативы, снэпшотов и SMVI. Но вдруг кто-то себе жизни не видит без него.
Также в блоге Ника Триантоса описывается остроумный способ “псевдо-VCB” - просто смонтировать файлы vmdk как разделы в linux-машине и, при наличии утилиты чтения NTFS, вы сможете делать пофайловый бэкап содержимого даже и windows-разделов.
Также обратите внимание, что работа по NFS, с недавних пор, стала доступна для VCB, входящего в версию 3.5, но есть ограничения.

2. Вы не сможете использовать внутри виртуальных машин MSCS - Microsoft Cluster Services - кластерную систему Microsoft. Ей нужны RDM(Raw Disk Mapping)-диски, то есть LUN-ы подключеные внутрь VM как raw-диски. Зачем нужен MSCS при наличии VMotion, HA и DRS? Ну может MSCS у нас бесплатен (в составе MS Windows Server Enterprise), а лицензия VMware HA за деньги, или мы по каким-то внутренним причинам переносим без изменений в виртуальную инфраструктуру физическую серверную систему на MSCS, почем знать.

В обоих этих случаях вы можете совместить NFS и LUN-ы SAN. Выбор одного варианта не отбирает и не запрещает вам второй.

Частый вопрос:
Q: “Будет ли это все работать у меня, если мои виртуальные сервера - Windows?”
A: “Да, к NAS, с дисками по NFS, подключается не “гостевая” виртуальная OS, а сам ESX. А для гостевых OS диски, получаемые ESX-ом c системы хранения, выглядят как локальное пространство дисков ESX-сервера, и с NFS как таковым виртуальные машины дела не имеют, все для них уже сделал ESX. Ваша виртуальная машина создает диск, и вы получаете на NFS-томе обычные файлы vmdk, словно это локальный диск ESX под VMFS”.

Характерный комментарий к одному из постов на эту тему:
“Dan Pancamo said:
950 VMs across 35 ESX servers. ALL on Netapp over NFS for more than a year now. FC/iSCSI? No thanks!”

Ну что, убедил посмотреть тему повнимательнее и пересмотреть предубеждения?

Еще почитать на тему:

Nick Triantos, один из разработчиков NetApp
VMware over NFS (07.09.2007)

Обзор Gartner:
Choosing Network-Attached Storage for VMware: What You Should Know

Mark Mayo
VMware Server and NFS? Am I alone?

Chuck Hollis, Вице-президент EMC по технологическим альянсам, вечный оппонент Хитца, который никогда не упустит в своем блоге возможности злобно куснуть NetApp ;), придерживается того же мнения:
Storage Protocols and VMware (4.12.2007)
VMware Virtual Infrastructure 3 – Climbing The Mountain (21.12.2006)

Ничего удивительного, ведь NAS продают и EMC.
Using EMC Celerra IP Storage with VI3 over iSCSI and NFS.

Dan Pancamo
Why VMware over Netapp NFS

Ну и наконец еще раз упомяну на мой взгляд интереснейший, полезнейший и очень активно пополняющийся блог Михаила Михеева, преподавателя по теме VMware VI в УЦ Микроинформ. Если вы занимаетесь VMware, то имеет смысл на него подписаться, множество важной и интересной информации собранной “на просторах” там публикуется.
Вот, например, все о теме NFS: http://www.vm4.ru/search?q=NFS

Ну что-ж. Так и не уложил в один пост всю тему. To be continued.

Мне в очередной раз на хвосте мышко притащила свежие слухи о ближайшем будущем этой темы.

Во первых, многие заметили, произошел отказ от аббревиатуры A-SIS, в пользу более понятного NetApp Dedupe и просто Deduplication. Шаг естественный. Немногие сходу вспомнят, что A-SIS это Advanced Single Instance Store, еще меньше - поймут о чем речь. Переход от “инженерной” аббревиатуры к “самоописывающему” названию есть вполне правильный путь.

Во вторых, проект “Дедупликация” скоро будет иметь две ветви: FAS Deduplication (ныне существует), и VTL Deduplication, ожидаемый давно, и обещаемый в первом ограниченно доступном для клиентов виде в конце этого года (сейчас она проходит ограниченное бета-тестирование).
Казалось бы, что за труд внедрить уже работающую технологию на параллельной линейке той же компании? Однако же как оказалось не все так просто. По сути под названием VTL Deduplication мы будем иметь некий принципиально новый продукт.
Не зря официальные лица так настойчиво повторяли весь год про “backup-oriented” и “stream optimized”.

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

Так, например, в VTL Dedupe, кроме уже известного режима post-process, который сохранился, добавится и некий inline. То есть система будет пытаться проводить дедупликацию в том числе и непосредственно “в онлайне”, в процессе поступления данных на диски, аналогично online compression.

Практический кейс: У меня есть 100 идентичных образов виртуальных машин по 1GB каждая (ну например 100 установленных Windows XP, отличающихся только несколькими байтами hostname). Я бэкаплю их на диски NetApp со включенной дедупликацией. Сколько понадобится выделить под это места? Нет, не 1GB. Даже несмотря на дедупликацию сперва нам нужно будет все 100GB, а затем 99GB нам вернутся, когда система завершит цикл дедупликации, происходящий в постпроцессе, в “оффлайне”.
В случае VTL Dedupe скорее всего какая-то часть дедупликации пройдет уже в процессе записи.

Второй момент, натолкнувший меня на мысль о принципиально ином продукте, был сведениями о том, что VTL Dedupe будет оперировать переменными размерами блока.

Напомню вкратце принцип работы FAS Deduplication.
Система хранения NetApp FAS устроена таким образом, что для каждого блока данных WAFL “внутри системы” вычисляется и хранится некая хэш-строка. Она довольно давно используется для дополнительного контроля целостности данных при их обработке в системе. Как я понимаю, для дедупликации просто воспользовались уже существующей в системе возможностью. Следствием стало то, что включение дедупликации как таковой, почти никак не затрагивает производительность самой системы. Ведь система и так уже эту функцию имела, добавился только некий процесс с существующими данными, осуществляемый в фоне, с низким приоритетом. Это позволило использовать дедупликацию в том числе и для систем хранения “общего применения”, что на сегодня не предлагает ни один из конкурентов.

??так, каждый 4kb-блок WAFL сопровождается хэш-строкой, идентифицирующей, с той или иной степенью достоверности, его уникальность. Если мы находим два идентичных хэша, то мы можем предположить, что соответствующие им блоки данных также иденичны. Для того, чтобы избежать так называемой “hash collision”, когда по какой-то причине один и тот же хэш соответствует разным блокам, такое возможно при не слишком сложном алгоритме вычисления хэша (который применяется в NetApp, дабы не грузить излишне систему) система проводит для таких блоков “контрольную проверку” путем простого побайтного сравнения этих 4kb-блоков. Если блоки действительно совпали, то один из них освобождается, а в таблице размещения указатель на него переставляется на оставшийся.

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

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

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

Однако, как и в случае с FAS Deduplication, NetApp сохранил очень приятную для нас, “конечников”, модель с бесплатной лицензией. То есть лицензия-то все равно есть, и для включения дедупликации она все равно нужна, но она бесплатна. Нужно ее только заказать через вашего партнера. То есть ситуация как с лицензией для iSCSI. Она есть, но она бесплатна.

?? еще несколько слов в заключение. Уважаемые ребята из московского представительства: Роман, Роман, Саша :). Я знаю, что вы меня читаете ;) Бога ради, если вы считаете, что я вдруг опять ненароком тут засветил какую-то Страшно Охраняемую Военную Тайну, которую Рано Показывать Публике - свяжитесь со мной, что-нибудь придумаем, исключительно из соображений доброй воли. Угум?

Что есть что на горизонте.

Стремительное продвижение технологий в повседневность IT-служб иногда поразительно. Сегодня, когда интерфейсы Gigabit Ethernet устанавливаются уже даже в ноутбуки, реальностью становится 10Gigabit Ethernet, который еще пару лет назад был чем-то из области лабораторных изысканий. Что же принесет нам этот виток скоростной гонки интерфейсов – давайте посмотрим.

RDMA

RDMA это Remote DMA. Для тех, кто за заботами сегодняшнего дня забыл об основах, позволю себе немного поликбезничать.
DMA, или Direct Memory Access, это классическая технология ввода-вывода данных с помощью специального программируемого контроллера DMA – прямого доступа к памяти.

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

Проблема с загрузкой процессора при вводе-выводе была решена использованием процедуры DMA – Direct Memory Access. Процессор единожды сообщает специальному контроллеру DMA, с какого или в какой адрес в памяти он желает осуществить перемещение данных, а контроллер исполняет, по завершении уведомляя процессор об исполнении. Получает или передает байты жестким дискам, выводит массивы данных в видеоконтроллер или превращает «цифру» в звук.
Результат обычно весьма впечатляющ. IT-шники со стажем должны помнить, какой эффект давал переход жестких дисков персональных компьютеров с режима PIO (Programmed Input-Output) к DMA (и в дальнейшем к UltraDMA), степень загрузки процессора на интенсивных дисковых операциях снижалась в разы.

Но DMA это лишь локальные операции, проще говоря, возможные только в области памяти и устройств одного компьютера. А что если сделать технологию DMA возможной для разных и между компьютерами?
Так родилась идея RDMA – Remote Direct Memory Access.

Технология эта отнюдь не нова. За ее разработкой следит представительный RDMA Consortium, куда входят многие гранды индустрии, такие как IBM, Cisco, NetApp, EMC, HP, Intel, Microsoft, общим числом около 50. Она шумела как новинка еще в 1998 году, а в 2003 году RDMA Consortium объявил о завершении всех запланированных спецификаций. Однако множество проблем в реализации ограничили ее применение high-end HPC (high-performance computing) системами. RDMA той или иной форме применялась на системах Cray, Silicon Graphics и ряде других, столь же легендарных «небожителей».
Однако шли годы, и то, что было уделом экспериментальных и сверхвысокопроизводительных вычислений стало нашей повседневностью, вот и до 10G Ethernet очередь дошла.

Основной идеей, родившей и развивающей RDMA как концепцию, была «размещать нужные данные непосредственно в память приложения», минуя многочисленное каскадное буферирование «из буферов сетевого адаптера в буфера сетевого протокола, из него в буфера OS, из них в буфера дисков, и так далее». ??менно поэтому в приложении к RDMA часто используется термин «zero-copy», то есть «отсутствие копирования», имея ввиду, конечно же, вот такое вот многократное промежуточное копирование между источником и получателем данных.

Наиболее известной реализацией RDMA и его «zero-copy» в применении к системам передачи данных на сегодняшний день является Infiniband, разработанный в соответствии с этими требованиями. На сегодняшний день это наиболее известная сетевая система для высокопроизводительных кластерных интерконнектов, в свое время, за счет своей открытости и меньшей цены, вытеснившая из этой области проперитарный Myrinet.

iSCSI – SCSI over IP
Я уже не раз писал о iSCSI, и останавливаться подробно наверное нет смысла. Сегодня уже все так или иначе находящиеся в теме систем хранения знают что это. iSCSI это способ передавать обычные и привычные SCSI-пакеты «упакованными» (модное словечко: «инкапсулированными») в IP-пакеты, и транспортировать их в любой среде передачи IP, например по Ethernet-сети. Тем самым между сервером и его жесткими дисками может находиться не традиционный 68-жильный кабель WideSCSI, а сетевые карты, ethernet-коммутаторы, провода Cat5, СКС, и прочие привычные скорее для «сетевиков» вещи. В наше время, когда в области передачи данных все явственнее происходит конвергенция «все в Ethernet-провод», когда даже будущее такого консервативного протокола как FibreChannel его основным локомотивом, компанией Bocade, видится, по ее заявлениям, в виде FCoE – FibreChannel-over-Ethernet, ничего удивительного, что iSCSI нашел себе сегодня широчайшее применение.

TOE – TCP Offload Engine
iSCSI, как протокол в целом, состоит, по сути, из двух независимых частей. Также отдельно они, как правило, и реализуются в оборудовании. Одна часть – «SCSI», и все относящееся к этому протоколу. Вторая – «i» - TCP/IP и все касающееся его.
Как известно, iSCSI может быть реализован полностью программно, и, в ряде случаев это совсем неплохой выбор, недорогой и исключительно гибкий. При этом задачи поддержки протокола осуществляет специальная программа – iSCSI Initiator, которые сейчас существуют во всех распространенных операционных системах. Эта программа создает в системе «виртуальный SCSI-адаптер», с которым могут обычным образом взаимодействовать прикладные программы. В дальнейшем она производит на центральном процессоре системы собственно задачи инкапсуляции SCSI-пакетов в IP-пакеты и отправку их драйверу сетевого интерфейса Ethernet, как обычное приложение или драйвер.

Такая модель дает нам беспрецедентную гибкость реализации, однако, очевидно, создает дополнительную нагрузку на центральный процессор, которую, при скоростях вплоть до Gigabit Ethernet еще можно обычно игнорировать, но на скоростях 10Gigabit Ethernet это уже становится сложно. Поэтому для 10GigE-систем как правило применяются те или иные «аппаратные» реализации.

«Аппаратизация» iSCSI может быть осуществлена раздельно по рассмотренным выше частям. Мы можем сделать сетевую карту, которая будет самостоятельно производить всю TCP/IP-шную рутину, такую как расчет контрольных сумм и сборка фрагментов, такое устройство называется TCP Offload Engine – TOE. При этом «SCSI-адаптер» в системе у нас остается виртуальным.

Либо сделать полную реализацию обоих частей протокола, то есть аппаратный SCSI-адаптер, на выходе которого будет не WideSCSI-разъем, а сетевой интерфейс, медный или оптический. Реализация же самого протокола для системы и ее приложений, как и ранее, будет для приложения и операционной системы полностью скрыта.

Как правило адаптеры 10Gbit Ethernet имеют в себе либо TCP Offload Engine, сохраняя программную реализацию SCSI, на CPU системы, в драйвере. Либо полную аппаратную реализацию. Такие адаптеры принято называть, как и в FibreChannel-системах – HBA – Host Bus Adapter.

iWARP
iWARP это Internet Wide Area RDMA Protocol – протокол работы RDMA по IP-сетям, основанный на концепциях Virtual Inerface Architecture, и, в определенном смысле, может рассматриваться как некий «Infiniband-over-IP».

С того момента, когда возросшие скорости Ethernet-сетей стали явной проблемой для чисто программной реализации TCP/IP, разработчики задумались над методами разгрузки процессоров, и одним из них стал TOE – TCP Offload Engine – аппаратная реализация TCP/IP на микросхеме контроллера ethernet-адаптера. Такое решение значительно разгружает центральный процессор от задач поддержки передачи данных, которая теперь, в значительной мере, может осуществляться самим контроллером сети. Особенно это стало важно при увеличении скорости и переходе к 10Gbit Ethernet, работа над такими объемами может серьезно нагрузить и довольно мощный современный процессор. А ведь у него есть и другие задачи, кроме как считать контрольные суммы IP-пакетов.

Чаще всего с помощью iWARP передаются такие «вышележащие» протоколы, как SCSI RDMA Protocol (SRP), iSCSI Extensions for RDMA (iSER), Sockets Direct Protocol (SDP) и NFS-over-RDMA.
Как видите, интерес Network Appliance к данной технологии понятен и объясним.

iSER – iSCSI Extensions for RDMA - это расширение протокола iSCSI, позволяющее ему работать по сетям, предоставляющим RDMA-сервис, например по Infiniband или iWARP. Он позволяет передавать данные непосредственно из и в буфер данных SCSI, минуя многочисленные промежуточные копирования данные из одного буфера в другой при традиционной обработке и передаче данных.
Целью создания iSER была попытка избежать проблемы фрагментации TCP при работе «классического» iSCSI, который, как вы помните, унаследовал от TCP/IP сетей, кроме массы полезного, и неприятную проблему фрагментации, которая, на больших скоростях передачи, характерных для 10Gbit Ethernet может приводить к заметному ухудшению latency. Суть проблемы заключается в том, что, при передаче, согласно природе TCP, пакеты могут приходить получателю в произвольном порядке, и дело получателя расставить их в нужном порядке, прежде чем передавать на обработку. Однако, пока получателю не придет пакет «номер два», он не может передать в SCSI буфер уже принятые пакеты номер «один», «три», «четыре» … «десять», которые вынуждены дожидаться прихода заплутавшего по сети «второго».
Вследствие этого возможны плохопредсказуемые задержки, которые были незначительны на небольших скоростях, но уже не могут игнорироваться на высоких.
Для решения этой проблемы iSER использует «zero-copy»-возможности RDMA вместо обычного способа инкапсуляции в TCP.
В качестве протокола передачи на транспортном уровне может использоваться, кроме «нативного» SDP – Socket Direct Protocol, и специально разработанный для потоковых передач протокол SCTP – Stream Control Transmission Protocol (RFC4960), являющийся функционально объединяющим преимущества TCP и UDP для целей передачи «потоковых» данных.

Первоначально этот протокол разрабатывался для целей передачи телефонии через IP, но прекрасно подошел и для других потоковых нужд современной Сети. Поддержка SCTP широко присутствует во множестве распространенных операционных системах, например IBM AIX v5, Cisco IOS v12, FreeBSD v7, Linux 2.4/2.6, HP-UX, Sun Solaris 10.
RDMA и NetApp

Компанию NetApp и RDMA связывает многое. NetApp является одним из учредителей вышеупомянутого RDMA Consortium, и еще в 2002 году начала продавать любопытный продукт для своих систем хранения - DAFS Database Accelerator, решение, базирующееся на протоколе DAFS – Direct Access File System. Это RDMA-based протокол, ориентированный на работу с высокопроизводительными базами данных.
Однако, несмотря на хорошие бенчмарки, согласно которым доступ к сетевому хранилищу NFSv4 через сетевой интерфейс (использовалась специальная карта Emulex VirtualInterface) превосходил по параметрам доступ к локальным дискам системы, продукт не стал бестселлером, и вскоре незаметно исчез из прайс-листа, по видимому придя на рынок слишком рано.

Но сегодня продукты c RDMA появляются на рынке, используя уже широко и активно распространяющиеся 10Gbit Ethernet-системы. Среди их производителей стоит назвать, например, такие имена, как Chelsio Communications, производящий такой интересный продукт, как Chelsio S310SR – 10G-адаптер с TCP Offload Engine, аппаратным iSCSI, виртуализацией и RDMA. Причем цена за пару, в так называемом Evaluation Kit на сайте производителя, показана ниже чем 2000$ за карты с SR optical interface и ниже 1500$ за карты с «медным» CX4.
Существуют и версии в «мезонинном» исполнении, для установки в blade-системы, например в HP Type II Blade Systems или IBM Blade Center H.

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

Experiences with NFS over IB and iWARP RDMA
OpenFabric Workshop, Sonoma, CA
May 1, 2007

InfiniBand and 10-Gigabit Ethernet for I/O in Cluster Computing
July 26-28 Cluster Symposium 2005

Performance Characterization of a 10-Gigabit Ethernet TOE

Head-to-TOE Evaluation of High-Performance Sockets over Protocol Offload Engines

Вполне возможно мне уже удалось заинтересовать некоторых моих читателей возможностями систем хранения 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

Одним из наиболее популярных т.н. “синтетических” тестов является программа 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 и запустить новый цикл.

Синхронная
Синхронная репликация - это зеркалирование данных на две системы хранения или два дисковых раздела внутри одной системы.
Популярный RAID-1 («зеркало») для дисковых контроллеров есть по сути просто синхронная репликация на два диска, выполняемая контроллером диска. При этом каждый блок данных записывается более или менее одновременно, параллельно, на оба устройства. Аналогичным образом это осуществляется на два «диска» в разных дисковых системах хранения.
Это «идеальная репликация», обе копии данных полностью идентичны, потому что пока данные не будут гарантированно записаны на оба устройства, оно не может приступить к записи следующего блока.
Однако теоретическая идеальность в реальной жизни оказывается ограничением.

Как мы видим, общая скорость системы ограничена самым узким каналом передачи данных. Если мы соединены с системой хранения FC-каналом в 4GB/s, а система хранения синхронно реплицируется на удаленную систему по каналу в 10MB/s, то скорость обмена по FC-каналу 4GB/s будет 10MB/s и ни байтом больше.

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

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

«Полусинхронная»
Вариантом, сочетающим в себе возможности синхронной и асинхронной репликации, является так называемая «semi-synchronous» репликация, или «полусинхронная».
В этом случае репликация проводится синхронной до тех пор, пока это позволяет быстродействие системы или канала связи. А затем, вместо замедления и остановки операций записи, временно переключается в асинхронный режим, продолжая обрабатывать поступающие данные без задержек, отправляя данные репликации в асинхронном режиме до тех пор, пока не возникнет возможность восстановить синхронный режим.

Проблемы консистентности
Для любой репликации отличной от синхронной серьезной проблемой является также “проблема консистентности”. Рассмотрим ее на простом примере.
Узел хранения А асинхронно реплицирует данные на узел хранения Б.
На устройстве хранения работает база данных, которая обрабатывает запросы, например финансовой системы.

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

Если вы работаете с базами данных и используете асинхронную или semi-synchronous репликацию, то не забывайте об этой особенности асинхронности в применимости к репликации баз данных и подобных им задач.

??нтересной особенностью систем хранения NetApp является использование необычного типа RAID - Type 4.

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

RAID - аббревиатура, расшифровываемая как Redundant Array of Independent Disks - “отказоустойчивый массив из независимых дисков” (раньше иногда вместо Independent использовалось слово Inexpensive). Концепция структуры, состоящей из нескольких дисков, объединенных в группу, обеспечивающую отказоустойчивость родилась в 1987 году в основополагающей работе Паттерсона, Гибсона и Катца.

??сходные типы RAID-массивов

RAID-0
Если мы считаем, что RAID это “отказоустойчивость”(Redundant…), то RAID-0 это “нулевая отказоустойчивость”, отсутствие ее. Структура RAID-0 это “массив дисков с чередованием”. Блоки данных поочередно записываются на все входящие в массив диски, по порядку. Это повышает быстродействие, в идеале во столько раз, сколько дисков входит в массив, так как запись распараллеливается между несколькими устройствами.
Однако во столько же раз снижается надежность, поскольку данные будут потеряны при выходе из строя любого из входящих в массив дисков.

RAID-1
Это так называемое “зеркало”. Операции записи производятся на два диска параллельно. Надежность такого массива выше, чем у одиночного диска, однако быстродействие повышается незначительно (или не повышается вовсе).

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

RAID-2
Остался полностью теоретическим вариантом. Это массив, в котором данные кодируются помехоустойчивым кодом Хэмминга, позволяющим восстанавливать отдельные сбойные фрагменты за счет его избыточности. Кстати различные модификации кода Хэмминга, а также его наследников, используются в процессе считывания данных с магнитных головок жестких дисков и оптических считывателей CD/DVD.

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

RAID-5
Попытка обойти это ограничение породила следующий тип RAID, в настоящее время он получил, наряду с RAID-10, наибольшее распространение. Если запись на диск “блока избыточности” ограничивает весь массив, давайте его тоже размажем по дискам массива, сделаем для этой информации невыделенный диск, тем самым операции обновления избыточности окажутся распределенными по всем дискам массива. То есть мы также как и в случае RAID-3(4) берем дисков для хранения N информации в количестве N + 1 диск, но в отличие от Type 3 и 4 этот диск также используется для хранения данных вперемешку с данными избыточности, как и остальные N.
Недостатки? А как же без них. Проблема с медленной записью отчасти была решена, но все же не полностью. Запись на массив RAID-5 осуществляется, тем не менее, медленнее, чем на массив RAID-10. Зато RAID-5 более “экономически эффективен”. Для RAID-10 мы платим за отказоустойчивость ровно половиной дисков, а в случае RAID-5 это всего один диск.

Однако скорость записи снижается пропорционально увеличению количества дисков в массиве (в отличие от RAID-0, где она только растет). Это связано с тем, что при записи блока данных массиву нужно заново рассчитать блок избыточности, для чего прочитать остальные “горизонтальные” блоки и пересчитать в соответствии с их даными блок избыточности. То есть на одну операцию записи массив из 8 дисков (7 дисков данных + 1 дополнительный) будет делать 6 операций чтения в кэш (остальные блоки данных со всех дисков, чтобы рассчитать блок избыточности), вычислять из этих блоков блок избыточности, и делать 2 записи (запись блока записываемых данных и перезапись блока избыточности). В современных системах частично острота снимается за счет кэширования, но тем не менее удлиннение группы RAID-5 хотя и вызывает пропорциональное увеличение скорости чтения, но также и соответственное ему снижение скорости записи.
Ситуация со снижением производительности при записи на RAID-5 иногда порождает любопытный экстремизм, например, http://www.baarf.com/ ;)

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

RAID-6
Дальнейшее развитие идеи RAID-5. Если мы рассчитаем дополнительную избыточность по иному нежели применяемому в RAID-5 закону, то мы сможем сохранить доступ к данным при отказе двух дисков массива.
Платой за это является дополнительный диск под данные второго “блока избыточности”. То есть для хранения данных равных объему N дисков нам нужно будет взять N + 2 диска.Усложняется “математика” вычисления блоков избыточности, что вызывает еще большее снижение скорости записи по сравнению с RAID-5, зато повышается надежность. Причем в ряде случаев она даже превышает уровень надежности RAID-10. Нетрудно увидеть, что RAID-10 тоже выдерживает выход из строя двух дисков в массиве, однако в том случае, если эти диски принадлежат одному “зеркалу” или разным, но при этом не двум зеркальным дискам. А вероятность именно такой ситуации никак нельзя сбрасывать со счета.

Дальнейшее увеличение номеров типов RAID происходит за счет “гибридизации”, так появляются RAID-0+1 ставший уже рассмотренным RAID-10, или всяческие химерические RAID-51 и так далее.
В живой природе к счастью не встречаются, обычно оставаясь “сном разума” (ну, кроме уже описанного выше RAID-10).

“Но тут наступило утро, и Шахеразада прекратило дозволенные речи”.

Как именно в NetApp используется необычный тип RAID, каким образом удалось обойти присущие этому типу недостатки и чем вызван такой “особый путь” данной системы хранения - смотрите в следующей серии!

Одним из камней, лежащих в основании системы хранения NetApp, наряду с собственной версией UNIX-подобной OS, является внутренняя файловая система, собственная разработка компани, под названием WAFL - Write Anywhere File Layout - “Файловая система с записью повсюду” :)

Откуда такое название, и что она дает системам хранения Network Appliance?

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

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

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

К особенностям “программно-аппаратной” реализации файловой системы следует также отнести и “аппаратный журнал” - NVRAM. В отличие от журналируемых файловых систем “обычного типа”, в которых журнал вместе с данными хранится на том же самом диске (обычно в особой области данных), журнал в WAFL размещен в специальном аппаратном устройстве, которым оснащены все системы хранения NetApp - устройстве Non-Volatile RAM, модуле оперативной памяти с батарейным питанием.

Несмотря на то, что блок NVRAM внутри NetApp выглядит очень похоже на Write-back cache у большинства вендоров систем хранения и серверов (плата с модулями DRAM и батареей резервного питания), функция его полностью иная.

Ну и, наконец, важной особенностью и отличием от широкоизвестных журналируемых файловых систем является параллельная поддержка двух схем разграничения доступа, т.н. “UNIX-style” и ACL(Access Control List) или “Windows-style”. Это связано с необходимостью поддержки на одном устройстве как файлов UNIX-”мира”, так и Windows-систем.
Таким образом, работая как NAS, устройства NetApp могут обслуживать как UNIX- так и Windows-машины, обращающиеся к одним и тем же файлам. Взаимное соответствие пользователей двух “миров” настраивается через таблицы взаимных соответствий пользователей, при этом система хранения понимает, что пользователь jmith подключающийся по NFS и DOMAIN\JohnSmith (или johnsmith@domain.local) это один и тот же человек, и соответствующим образом разрешает ему доступ к данным вне зависимости от того, как он в систему хранения попадает, через NFS или CIFS.

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

Подробнее (и по-английски) об устройстве файловой системы WAFL можно подсмотреть тут:
File System Design for an NFS File Server Appliance
Dave Hitz, James Lau, & Michael Malcolm | Network Appliance | TR 3002 http://www.netapp.com/library/tr/3002.pdf

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

Для начала следует определить два основных общепринятых понятия, используемых для измерения производительности.
Первый из них – Input-Output Operations Per Second – IOPS - показывает количество операций ввода-вывода в секунду, которые способно обработать устройство. Этот параметр прежде всего характеризует скорость обработки коротких запросов, и наиболее часто применим для оценки таких задач, как OLTP-база данных и близких к ней.
Операции базы данных как правило характеризуются обменом относительно небольшими блоками (как правило 4-8KB). Каждая такая операция по считыванию или записи блока является одним IOPS-ом. Таким образом, чем выше показатель производительности в IOPS, тем выше производительность базы данных.

Другим параметром, характеризующим производительность, является Скорость передачи данных, так называемый traffic throughput, измеряемый в MB/s, то есть количеством мегабайт, проходящих по интерфейсу ввода-вывода в секунду.
Этот параметр характеризует скорость обработки в случае больших блоков, классическая задача, для которой критичен именно параметр MB/s, это аудио-видео обработка, резервное копирование и DSS-базы данных.

Какой же из этих параметров более «правильный», какой более важен? Разумеется оба.
Однако следует понимать, что оба этих параметра связаны между собой «обратно пропорционально». Увеличение величины в IOPS вызывает снижение величины в MB/s и наоборот.

Чтобы понять почему так, нужно рассмотреть простой пример и аналогию.
По дороге следует переместить из А в Б большое количество человек. Возможно два варианта: мы можем перевозить их в их личных автомобилях или же усадить в автобусы. Пропускная способность дороги конечно же будет выше в случае перевозки людей автобусами, то есть «большими блоками». Однако методы общественного транспорта обычно вступают в конфликт с индивидуальными целями и маршрутами. Хорошо если в Б у нас огромный завод, на который устремлен основной поток из А. Можно погрузить все «байты» в один большой пакет-автобус на входе, и выгрузить его на остановке у завода, куда собственно и направляются все наши «байты».
Однако если наши байты не едут на завод, а разъезжаются по индивидуальным и независимым делам-«операциям», каждый имея индивидуальный маршрут, то доставка их «автобусом»-большим пакетом приведет напротив к большим потерям времени. В этом случае транспортировка индивидуальными автомобилями будет более выгодна. Однако общий пропускной объем дороги заполненной индивидуальными «пакетами»-авомобилями везущими по нескольку байт каждый, разумеется будет ниже, чем при перевозке большим пакетом-«автобусом».
Таким образом увеличение пропускной способности в MB/s за счет укрупнения пакетов приводит к снижению IOPS, и наоборот, рост операций в секунду «доставленных к цели пассажиров» нашей дороги-интерфейса, запруженной автомобилями, приводит к снижению ее пропускной способности в MB/s. Нельзя одновременно достичь высоких показателей в IOPS и в MB/s просто по физическим свойствам существующего оборудования.
Либо большие пакеты-«автобусы» и их мало («операций в секунду»), либо маленькие индивидуальные пакеты-«автомобили», каждый осуществляющий индивидуальную «операцию» по доставке данных, но заполняющие всю дорогу, и общий human traffic в результате невелик.

Отсюда видно, что широко разрекламированная величина пропускной способности интерфейса SATA-II дисков в 300MB/s далеко не всегда (а чаще и вообще никогда) не будет достижима на практике. Более того, в случае использования таких дисков для операций с базой данных OLTP роль будет играть не столько потоковая производительность интерфейса, сколько гораздо реже публикуемая максмальная величина IOPS диска, в настоящий момент равная для SATA 7200rpm примерно 50 IOPS, и в случае OLTP-нагрузки выиграет не диск с самыми высокими данными по мегабайтам в секунду, а самый быстродействующий по IOPS - параметру, напрямую связанному с рассмотренной выше «латентностью», такой как, например, диск с интерфейсом FC и скоростью вращения 15Krpm, для которого величина IOPS достигает 200. При прочих равных диски SATA всегда проиграют в случае работы с базой данных не только дискам FC, но и традиционным SCSI.
Однако в случае использования дисков на задачах считывания и записи аудио-видеоданных, или резервного копирования, характеризующихся большим и постоянным потоком данных большими блоками, диски SATA вполне могут быть не хуже значительно более дорогостоящих FC или SCSI, легко выигрывая у них за счет цены за хранимый мегабайт.

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