about NetApp

На днях, NetApp официально опубликовал результаты бенчмарка SPC-1, главного бенчмарка по демонстрации производительности на блочном (SAN) доступе.

Как вы знаете, в Data ONTAP 8.1.x Cluster-mode появилась новая возможность – кроме доступа к системе хранения как к NAS, по протоколу NFS или CIFS/SMB, теперь возможна и работа с блочным стораджем, то есть как SAN-утройства. В версии 8.1 кластер SAN был ограничен 4 узлами (2 HA-парами), но, как я и предполагал, этот размер будет постепенно увеличиваться, и вот уже в 8.1.1 он был увеличен до 6 узлов (нод) в кластере. Напомню, что для NAS (NFS) максмальный размер кластера составляет 24 узла.

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

?? если для NAS NetApp достаточно давно показывал свои результаты в бенчмарке SPEC sfs2008, в том числе и для Cluster-mode, то для блочных протоколов, таких как FC или iSCSI, или FCoE, таких данных не было. А отсутствие результатов бенчмарков всегда тревожит, как же оно там, на самом деле, не на бумаге маркетинговых буклетов?

Наконец, на прошлой неделе, NetApp показал свои (почти)топовые результаты, для 6-узлового кластера, с использованием контроллеров FAS6240, под управлением Data ONTAP 8.1.1.

??нтересно, что бенчмарк SPC-1 требует публиковать цену тестируемой конфигурации (в терминах SPC-1 – TSC, Tested Storage Configuration), и, следовательно, вычислять параметр $/IOPS, “цену транзакции”. Но тут следует обратить внимание, что не запрещается искусственно занижать “листовую” цену продукта (например указав в цене уже некий “дисконт” относительно листпрайса), получая более “выгодно выглядящие” $/IOPS. Показатель $/IOPS приводится вместе с показателем IOPS, достигнутым на тестировании, даже в короткой версии результата, так называемом executive summary, в то время, как за полной конфигурацией тестируемой системы и за опубликованными на нее ценами, надо идти в full disclosure report.

NetApp на тестировании SPC-1 всегда приводит в качестве цены на систему полный, официальный листпрайс на момент тестирования, без дисконтов, и, что интересно, со включенным SupportEdge 24×7х4h на 3 года. Специально хочу напомнить, что листпрайс в реальной жизни не является реальной ценой продажи, так как в подавляющем числе случаев при продаже для конечного пользователя из цены вычитаются разнообразные, порой значительные, в десятки процентов, дисконты (скидки).

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

18 июня 2012 года NetApp опубликовал официальный отчет о тестировании 6-узлового кластера в SAN, на протоколе доступа FC 8Gb/s и тестируемом объеме ~72TB (~193TB raw, 36% от raw), 432 диска SAS 450GB в 18 полках, показав результат 250 039,67 IOPS, и, при листпрайсе $1 672 602, показатель $/IOPS составил 6,69$/IOPS SPC-1.

За подробностями – в executive summary и в full disclosure report.

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. ??спользуемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

??так, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

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

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. ??спользуя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

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

??спользование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

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

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

По оси X – количество подключаемых в SAN хостов-серверов, по Y – цена оборудования без учета стоимости работы и времени, только “железо”.

Цены брались “real-life” и “street price” (не list price). Разумеется dual fabric и по два порта на хост, и так далее, как положено в реал лайфе. Выбиралось оборудование за минимальную цену, выполняющее поставленную задачу, но, естественно, из доступного данному партнеру списка вендоров (поэтому, главным образом, Cisco и IBM (Brocade)). В подсчет включались HBA и NIC, коммутаторы, SFP, кабеля, лицензии на порты, где нужны, и так далее.

Результат любопытен, и показывает неоднозначность вопроса “дороговизны”. Так, например, на 1-8 хостов стоимость решения 10G Ethernet в разы перекрывает тот же 8G FC, а вот на 16-24 хоста в SAN все уже не столь очевидно (больше 24 хостов анализ не производился, там уже начинаются “директоры” и совсем иного класса оборудование).

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

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

Так вот, обратите внимание, что из того факта, что на “зашаренном” volume вы видите LUN-ы на нем созданные как файлы, не следует, что “LUN-ы это файлы”.

Если вы, допустим, бэкапите такие LUN-ы, то бэкапить их надо ТОЛЬКО как содержимое volume, то есть от “корня”, вместе с томом, либо с qtree, если последний используется. ??наче вы потеряете при таком копировании metadata (они хранятся внутри volume), определяющие внутри NetApp LUN именно как LUN, и не сможете восстановить его на прежнее место как LUN, то есть как устройство с блочным доступом.

То есть, для бэкапа содержимого LUN, например это LUN01, лежащий на томе vol1,  недостаточно просто скопировать “файл”, лежащий по адресу //filer1/vol1/LUN01, нужно копировать целиком vol1!

Аналогична ситуация и с восстановлением. Восстанавливать надо том вместе со всеми LUN-ами на нем, а не просто отдельный “файл” LUN-а, так как, в противном случае, не будут востановлены специфические метаданные SAN-объекта.

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

Разумеется, все изложенное выше касается только “бэкапа со стороны стораджа” (например по NDMP), а не бэкапа “изнутри” OS, работающей с данным, смонтированным на нее LUN-ом, как своей файловой системой.

Еще читать: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb37566

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

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

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

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

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

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

ДА

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

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

ДА

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

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

НЕТ

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

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

НЕТ

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

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

НЕТ

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

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

ДА

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

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

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

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

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

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

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

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

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

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

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

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

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

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