nfs хранилище что это
Основные протоколы хранения: использование и перспективы
В этой статье мы проведем небольшой обзор наиболее популярных протоколов, которые используются для построения сетей хранения данных (SAN). Также рассмотрим перспективы развития и использования отдельных протоколов, опираясь на общедоступные роудмапы производителей.
Не секрет, что на сегодняшний день проблемы производительности перемещаются из сферы СХД в область SAN сетей, так как СХД уже достигли огромных показателей производительности в ГБ/с и миллионах IOps, а текущие SAN сети не позволяют прокачивать через себя такие объёмы данных.
Общие тенденции
Существующие сети FC 8Гб/с и Ethernet 10Гб/с уже не справляются c современными СХД, даже Ethernet 25/50 Гб/с не может обеспечить приемлемые задержки при работе с последними моделями СХД, использующими NVMe диски.
Многие ИТ-специалисты, занимающимся настройкой и администрированием инфраструктуры хранения, задаются вопросом о модернизации SAN-сетей. Почему же это так важно и необходимо на сегодняшний день? Сформулируем несколько основных причин:
По существующим прогнозам, в перспективе двух лет (по данным Gartner, в течение 18 месяцев) all-flash массивы будут комплектоваться более производительными SSD-дисками, а в сочетании с быстрым интерконнектом (например, NVMe) и новыми протоколами (например, iWARP) производительность all-flash массивов повысится ещё на два порядка, что приведёт к необходимости модернизировать SAN.
Сравнение протоколов
Все SAN сети, будь то Ethernet, PCI Express, SAS, NVMeoF, FC, FCoE или InfiniBand, должны поддерживать одинаковый функционал, а именно:
На сегодняшний день протоколы хранения данных можно разделить на две условные группы:
Fibre Channel (FC)
Fibre Channel — популярный протокол хранения, обеспечивающий низкие задержки и высокую пропускную способность за счёт своих архитектурных особенностей. Fibre Channel не требователен к ресурсам и отлично подходит для передачи большого объёма данных, так как все операции FC выполняются на стороне HBA, разгружая центральный процессор.
Новые версии протокола Fibre Channel обратно совместимы с прошлыми редакциями, что открывает хорошие перспективы для модернизации и масштабирования. Например, если внедрять FC 32Гб/с, то всё ещё можно будет использовать FC 8Гб/с и 16Гб/с, т.е. можно поэтапно менять FC-коммутаторы и FC адаптеры.
В ближайшее время FC будет обновлён до 64Гб/с и 128Гб/с (уже сейчас есть коммутаторы, поддерживающие агрегацию 4-х портов 32Гб/с в один канал 128Гб/с для соединения коммутаторов).
Простота настройки и удобство в администрировании позволили FC стать одним из наиболее распространенных протоколов хранения. Большинство администраторов SAN-сетей во всем мире знает, как он устроен и какие преимущества обеспечивает при решении различных задач. При этом FC всё ещё сложнее, чем Ethernet, хотя и обладает большим количеством средств управления и мониторинга.
FCoE (Fibre Channel over Ethernet)
Идея создания FCoE заключалась том, чтоб консолидировать операции ввода-вывода и, как следствие, обеспечить безопасное размещение в одном «проводе» различных типов траффика. Такая задумка подразумевала снижение совокупной стоимости владения системой (TCO) за счет уменьшения числа кабелей и адаптеров, а также снижения показателей по энергопотреблению. При этом показатели доступности и производительности FCoE не сопоставимы с показателями FC, так как передача данных требует дополнительных накладных расходов на инкапсуляцию в Ethernet.
К тому же, FCoE добавляет сложность в развёртывании и администрировании всей системы, повышая уровень требований к обслуживающему персоналу и поддержке решения. Несмотря на надежды производителей FCoE на повсеместное внедрение, до сих пор данный протокол не смог вытеснить FC и развивается очень медленными темпами. Распространение FCoE на рынке SAN в настоящий момент минимально.
По данным Fibre Channel Industry Association (FCIA) в прогнозных показателях FCoE скорость протокола зависит от реализаций Ethernet.
iSCSI (Internet Small Computer System Interface)
iSCSI строится на двух наиболее часто используемых протоколах:
Считается, что iSCSI 10Гбит обеспечивает такое же количество IOps и пропускную способность, как и сопоставимый ему FC 8Гбит, но это не совсем так. Хотя пропускная способность iSCSI и выше, но его эффективность ниже, чем у FC за счёт дополнительных накладных расходов.
Производительность iSCSI зависит от существующий инфраструктуры Ethernet (на сегодняшний день минимально рекомендованная сеть для iSCSI – 10Гбит). В ближайшем будущем (по данным Gartner, 10–12 месяцев) стоит планировать переход на 25/40/50GbE, если будет необходимость использовать высокопроизводительные all-flash СХД.
SAN-сети на основе сетей Ethernet
Протоколы iSCSI, NFS, SMB, FCoE используют Ethernet-сети для передачи данных, поэтому использовать данные протоколы в общих сетях не целесообразно. Это приводит нас к необходимости развёртывания выделенных сетей для использования их в качестве SAN.
Такие сети должны работать параллельно с другими основными сетями и отделять пользовательский траффик от траффика данных серверов. Однако из-за разделения сетей увеличивается сложность администрирования и общая стоимость владения.
Единственное исключение — это использование общих сетей для объектного хранения, т.к. в данном случае обеспечение минимальных задержек и максимальной производительности не так критично.
NFS (Network File System)
Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработанный Sun Microsystems в 1984 году. NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера.
NFS просто конфигурируется и администрируется, т.к. используется поверх сетей Ethernet. Как и в других протоколах, использующих Ethernet, скорость и задержки целиком зависят от реализации сети на нижнем уровне и чаще всего «упираются» в ограничения стандарта 10GbE.
NFS часто используется как протокол начального уровня для построения SAN-сети для виртуализации. По прогнозам Gartner, такой тренд сохранится в течение последующих 10 лет.
SMB (Server Message Block)
SMB — это сетевой протокол для общего доступа к файлам, который позволяет приложениям компьютера читать и записывать файлы, а также запрашивать службы серверных программ в компьютерной сети. Разработан компанией Microsoft для реализации «Сети Microsoft Windows» и «Совместного использования файлов и принтеров». С увеличением пропускной способности сетей передачи данных SMB стал одним основных протоколов файлового доступа, применяемых в СХД. В системах хранения SMB чаще всего используется в сетях 10GbE, из-за этого его производительность сильно зависит от реализации, настроек и используемых компонентов сети.
До версии SMB 3.0 протокол в основном использовался для передачи файлов в локальных сетях. С новой версией, поддерживающей технологию SMB-Direct (использование RDMA), стал активно применяться в кластерах виртуализации на базе MS Hyper-V как протокол доступа к общему пулу хранения.
Как и NFS, SMB часто используется в качестве протокола начального уровня при построении SAN-сети для виртуализации. Эта тенденция также должна сохраниться в ближайшее десятилетие.
InfiniBand (IB)
InfinBand — высокоскоростной протокол, обеспечивающий очень большую пропускную способность и низкие задержки. Используется, преимущественно, в отрасли высокопроизводительных вычислений (HPC) и в качестве интерконнекта при создании высокопроизводительных СХД.
Наиболее явным недостатком этой технологии является сложность в настройке и администрировании. Как следствие, работа с IB требует квалифицированного персонала.
Среди трудностей повсеместного распространения InfinBand можно отметить ограниченные средства для мониторинга производительности и диагностики проблем, а также не самую лучшую совместимость с разными операционными системами.
В сравнении с FC и Ethernet протокол InfiniBand более «дорог» для внедрения и обслуживания. К тому же, существует лишь несколько считанных компаний, которые производят оборудование и программное обеспечение для работы с IB.
NVMe (NVM Express)
NVMe — это достаточно новый высокопроизводительный протокол доступа к твердотельным накопителям, подключенным по шине PCI Express. Аббревиатура «NVM» в названии обозначает энергонезависимую память (Non-Volatile Memory), в качестве которой в SSD повсеместно используется флеш-память типа NAND.
Протокол был разработан с нуля. Основные цели его разработки – низкие задержки и эффективное использование высокого параллелизма твердотельных накопителей. Последняя задача решается за счёт применения нового набора команд и механизма обработки очередей ввода-вывода, оптимизированного для работы с современными процессорами.
На данный момент технология NVMe еще не получила широкого распространения. В основном протокол используется для внутреннего соединения в серверах и СХД. Спецификация NVMe также позволяет инкапсулировать его в другие протоколы, такие как Ethernet, FC и InfiniBand, и масштабировать протокол в более крупных сетях. Впрочем, поскольку NVMe использует прямой доступ к памяти (RDMA), латентность протокола несущей должна быть очень низкой для нормальной работы протокола.
В 2017 году ожидается активное внедрение NVMe, так как многие производители серверных платформ представляют новые модели с поддержкой двухпортовых NVMe-устройств, что позволит проектировать отказоустойчивые решения для хранения.
Ожидается, что в ближайшие несколько лет NVMe будет использоваться в качестве внешнего межсетевого интерфейса, аналогичного PCIe и InfiniBand. Например, он может использоваться в небольших специализированных сетях хранения из десятков узлов или устройств в однородной среде хранения. Гораздо шире NVMe будет использоваться в качестве внутреннего интерконнекта.
PCIe имеет очень низкие задержки и используется преимущественно в серверах для подключения плат расширения, в том числе и высокопроизводительных NVMe дисков. Некоторые новые продукты от известных производителей используют PCIe в качестве протокола подключения серверов через небольшие PCIe коммутаторы, т.е. PCIe получается использовать только в небольших SAN-сетях.
Только несколько производителей СХД в мире используют PCIe для внешних подключений, что и определяет узкоспециализированное применение данного протокола.
Так как PCIe не использует SCSI и требует собственного протокола для передачи данных, он может увеличить пропускную способность за счёт уменьшения задержек, по сути, работая на скорости чистой PCIe-линии. Такие решения требуют применения проприетарных драйверов, что делает их сложно администрируемыми и приводит к невозможности создавать гетерогенные инфраструктуры, а также встраивать такие решения в существующие SAN сети.
На сегодняшний день основная используемая реализация технологии — это PCIe 3.x, в которой производительность увеличена на 40% по сравнению PCIe 2.x.
По количеству линий PCIe масштабируется от 1ГБ/с до 16ГБ/с. В 2017 году выходит новый стандарт PCIe 4.x, который увеличит производительность в 2 раза, т.е. максимальная производительность достигнет 32ГБ/с.
Протоколы объектного хранения
К объектному хранению относится большое количество новых протоколов, которые работают поверх HTTP, через API. На сегодняшний день многие новые приложения разрабатываются с учётом использования данных протоколов, это особенно актуально для программного обеспечения для резервного копирования.
Производительность этих протоколов сильно зависит от нижнего уровня, чаще всего это Ethernet. Основное функциональное применение протоколов объектного хранения — работа с неструктурированными данными. Ввиду этого они используются в рамках ЦОДов, а также широко применяются для доступа к данным и записи в облачные пулы хранения.
Протоколы объектного доступа требуют передачи и хранения большого объёма метаданных, что всегда добавляет накладные расходы, особенно в сравнении протоколами блочного доступа.
За последние несколько лет было разработано множество протоколов объектного доступа. Наиболее популярные из них – SOAP, S3, OpenStack Swift. В ближайшем будущем (по данным Gartner, в течение 5 лет) данные технологии будут вызывать особый интерес.
Вывод
Развитие SAN-протоколов напрямую зависит от развития приложений и профилей нагрузки.
Такие приложения и типы нагрузок, как в HPC, аналитике Big Data и активных архивах, будут двигать SAN в сторону создания СХД c очень низкими задержками и высочайшей пропускной способностью, а также с поддержкой разделяемого доступа с использованием NVMe.
Протоколы, которые будут внедряться в ближайшем будущем (такие как 40/100GbE ), файловые протоколы (такие как NFS over RDMA и SMB-Direct) и текущие блочные протоколы (такие как FC 16Gb/s), уже сейчас слишком медленные для следующего поколения Flash и гибридных СХД.
Основным протоколом на ближайшее десятилетие останется FC, так как под него создана вся необходимая инфраструктура. Многие будут переходить на FC 16Гб/c, затем на FC 32Гб/с и более новые версии.
InfiniBand, PCIe и NVMe останутся протоколами для подключения конечных устройств, межузловых подключений в кластерах или интерконнекта с малыми задержками. При этом будут и небольшие узкоспециализированные решения для SAN-сетей, в которых необходимы минимальные задержки и максимальная пропускная способность. FCoE, iSCSI, NFS, SMB или объектные протоколы будут использоваться преимущественно в качестве внешних протоколов.
C каждым годом растёт интерес к объектным системам хранения. Это происходит за счёт увеличения количества неструктурируемых данных, появления новых задач по их обработке и новых требований к хранению информации.
• The Fibre Channel Roadmap, FCIA 2016.
• Dennis Martin. Demartek Storage Networking Interface Comparison, Demartek 2016.
• Valdis Filks, Stanley Zaffos. The Future of Storage Protocols, Gartner 2017.
Бюджетная виртуализация. NFS vs iSCSI, что выбрать?
Статья опубликована в журнале «Системный Администратор»
Тестируем и выбираем тип хранилища для небольших виртуальных сред.
Введение
При построении виртуальной инфраструктуры бюджетного уровня, порой, даже у профессионалов возникает вопрос, какой тип хранилища и протокол доступа к нему использовать. Различные источники говорят по разному и часто сбивают с толку. Попробуем разобраться, как оно есть на самом деле.
Почему не FC
Безусловно лучшим решением для построения высокопроизводительных и надежных сетей хранения данных(далее СХД) для любых задач, является использование оптических каналов и Fibre Channel Prototocol(FCP).
FCP инкапсулирующий SCSI команды, изначально разрабатывался с учетом всех тонкостей блочного обмена данными. В нем отсутствуют основные недостатки классических сетевых протоколов типа TCP/UDP, в которых данные могут теряться или приходить не последовательно, что не приемлемо для SCSI. Заголовок пакета FCP минимален в отличии от того же iSCSI, что значительно сокращает накладные расходы. Аппаратные контроллеры FC — HBA(Host Bus Adapter) полностью берут на себя генерацию заголовков пакетов снимая тем самым нагрузку с центральных процессоров. А высокопроизводительные оптические каналы (2Gb/4Gb/8Gb и выше) обеспечивают надежную передачу данных на большие расстояния.
О FC и сетях хранения, построенных с его применением, написаны целые книги [1] и перечислять его достоинства можно долго, но хочется сказать о его главном недостатке.
Высокая стоимость отдельных компонентов FC(HBA, коммутаторы и тому подобное) и суммарная стоимость конечной реализации, пожалуй, является определяющим фактором заставляющим отказаться от сетей хранения на базе FC. Так же далеко не каждая инфраструктура, в том числе и виртуальная, нуждается в FC. Например для полноценной работы нескольких десятков виртуальных машин(ВМ) не обязательно строить дорогостоящую систему хранения. А все технологии, присущие виртуализации (живая миграция ВМ, высокая доступность и так далее) так же реализуемы на iSCSI или NFS. Более того, некоторые платформы виртуализации, например такие как ProxmoxVE [3] или CloudStack [2] и вовсе не умеют работать с FC, тогда использование как iSCSi и NFS доступно на всех платформах. В общем, можно сказать однозначно, что NFS и iSCSI — быть! А вот, что и где эффективнее использовать, поговорим далее.
Немного о NFS
Network File System (NFS) — является протоколом сетевого доступа к файловым системам. NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов (Remote Procedure Call) на сервер. Если разложить структуру протокола NFS по уровням эталонной модели OSI, то выглядеть это будет примерно так:
— На прикладном уровне, выполняется собственно сам NFS, осуществляющий вызовы удаленных процедур (RPC), которые и производят различные операции с файлами и каталогами на сервере.
— Далее, RPC-вызовы передаются протоколу XDR (eXternal Data Representation), который работает на презентационном уровне и является меж платформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
— После унификации данных, сервис RPC (Remote Procedure Call), с клиентской стороны обеспечивает запрос удаленных процедур и их выполнение на сервере, представляя функции сеансового уровня. На этом, слои, специфичные для NFS заканчиваются. После чего данные инкапсулируются в стандартные TCP/UDP пакеты и отправляются дальше на лежащие ниже уровни эталонной модели OSI.
Стоит отметить, что в большинстве реализаций, NFS использует именно TCP в качестве транспортного протокола. 
Таблица №1. Сопоставление уровней модели OSI и NFS
На практике, NFS реализуется очень просто и абсолютно прозрачно для любых клиентских приложений, которые и не подозревают, что их данные фактически находятся на NFS-сервере.
Пожалуй, за счет своей простоты, реализация NFS-сервера и клиента присутствует во всех современных Linux/Unix дистрибутивах, а так же в новых версиях Windows Server (2008 и выше).
NFS в контексте виртуализации
Прежде всего, NFS позволяет построить масштабируемое и легкое в управлении сетевое хранилище данных без использования дорогостоящего оборудования. Для работы NFS, достаточно обычного Gigabit Ethernet.
При этом весь функционал платформ виртуализации, такой как: горячая миграция виртуальных машин, балансировка нагрузки, высокая доступность, миграция между хранилищами, доступен так же, как при использовании FC.
К минусам NFS, стоит отнести не возможность предоставления ВМ блочного устройства или его логического раздела(LUN) целиком (Raw Device Mapping), что доступно при использовании протоколов FC и iSCSI. При использовании NFS, диски ВМ могут быть только в виде файлов, что делает кластеризацию ВМ не возможной. Так же NFS, не позволяет выполнить загрузку гипервизора по сети с системы хранения.
В случае с блочными устройствами и соответствующими протоколами (FC и iSCSI) некоторые платформы виртуализации, например VMware vSphere и Citrix XenServer создают на подключенных хранилищах собственную, кластерную файловую систему(ФС), что может оказаться эффективнее NFS работающей зачастую поверх обычных ФС. В дополнение к и так весомым минусам, можно отнести отсутствие в NFS какой-либо авторизации, кроме не всегда удобной возможности разграничивать доступ к хранилищу по ip-адрессам.
Отдельным минусом хочется выделить, проблемы производительности NFS. За счет внутренних особенностей протокола и высоких накладных расходов, связанных с инкапсуляцией нескольких протоколов высокого уровня в стандартный пакет TCP, сокращается объем полезной нагрузки (реальных данных) в пакете. Для оптимизации производительности и отказоустойчивости NFS, необходим ряд более тонких настроек, выполнение которых можно отнести к минусам протокола.
Вопросам оптимизации производительности будет просвещена отдельная статья.
Немного о iSCSI
Internet Small Computer System Interface () – сетевой протокол, обеспечивающий взаимодействие объектов (Целей и Инициаторов) в сетях хранения данных. Стоит обратить внимание на то, что в данной статье рассматривается только программно реализуемый iSCSI. Поэтому, под объектами подразумеваются серверы, операционные системы, платформы виртуализации выступающие в роли Инициаторов и блочные устройства расположенные в системах хранения (являющиеся Целями). В iSCSI, так же как и в FC транслируются SCSI команды, а данные передаются блоками только в качестве транспорта, iSCSI использует стандартный стек TCP/IP вместо FCP, а средой передачи являются стандартный Ethernet(1Gb/10Gb) вместо более надежной оптики. 
Таблица №2. Уровни протокола iSCSI.
По функционалу, iSCSI, очень похож с FC, но значительно дешевле. Сегодня, программная реализация iSCSI доступна во всех современных ОС, а основной сферой его применения является виртуализация, в которой он поддерживается практически всеми платформами.
В контексте виртуализации iSCSI позволяет так же как и в случае с NFS, построить масштабируемое сетевое хранилище с возможностью использовать все присущие виртуализации функции.
К особенностям iSCSI в противовес NFS можно отнести возможность предоставления виртуальным машинам, диска (LUN в терминологии SCSI) целиком (Raw device mapping), что позволяет строить кластеры из нескольких ВМ. Так же на LUN-ах можно размещать произвольную файловую систему. В случае с iSCSI, возможна авторизация по связке имени и пароля.
К минусам, можно отнести более сложный чем с NFS, процесс настройки требующий немного больше навыков. Так же как и в случае с NFS, iSCSI имеет большие накладные расходы в связи со многоуровневой инкапсуляцией данных.
Тестовый стенд NFS vs iSCSI
Так как тема статьи ориентированна на инфраструктуры начального уровня то и тестовый стенд решено было собрать крайне бюджетный.
В качестве хранилища был выбран старый сервер с одноядерным процессором, 1 гигабайтом оперативной памяти и обычной сетевой картой Gigabit Ethernet без TOE (TCP Offload Engine). Дисковая система была представлена тремя новенькими SATA дисками.
В качестве ОС был выбран CentOS 6.3 установленный на отдельный жесткий диск не задействованный в тестах.
Один из жестких дисков был отформатирован в ext4 и выполнял роль NFS хранилища. Использовался NFS версии 4.
Последний из трех жесткий диск без каких либо приготовлений был полностью экспортирован как iSCSI-Target.
Использовался tgt версии 1.0.24
LVM(Logical Volume Management) использовался только на диске с ОС!
Прмечание: Я специально не акцентирую внимание на марках оборудования и конкретных частотах/оборотах и других характеристиках. В рамках данного тестирования, проводится сравнение двух протоколов относительное друг друга, и выявление создаваемой ими нагрузки на одном и том же оборудовании и тех же задачах.
Безусловно, данная конфигурация не является примером системы хранения даже для домашнего использования. А показатели ее производительности будут больше пугающими чем оптимистичными. Но, для сравнительного тестирования большего, на мой взгляд, ничего и не нужно.
В качестве узла виртуализации был выбран не менее бюджетный, но более производительный сервер с двухядерным процессором, 8 гигабайтами памяти и обычной сетевой картой Gigabit Ethernet без каких либо аппаратных функций.
В качестве ОС использовался Proxmox VE 2.1.
Методика тестирования
Так как в случае с NFS, диски ВМ могут храниться только в виде файлов. А iSCSI-диски могут быть подключены к ВМ напрямую. Было решено создать на NFS хранилище диск ВМ в размер всего хранилища в формате RAW дабы немного уровнять позиции протоколов.
Базовые тесты
На Proxmox-хосте был создана виртуальная машина с установленной ОС Windows Server 2003 Enterprise R2 (образ ее лежал на отдельном хранилище).
К виртуальной машине, в качестве локальных SCSI-дисков были подключены iSCSI-диск на прямую и RAW-файл с NFS-хранилища.
Вначале были проведены синтетические тесты производительности дисков с использованием ПО HD Tune Pro v3.50 внутри ВМ.
Далее были выполнены практические тесты с копированием различного рода данных.
Утилита FIO (Flexible I/O tester)[4]
На сегодняшний день, это, пожалуй, наиболее перспективное средство для тестирования дисковых массивов и систем хранения. В отличии от классического iometer [5], последний релиз которого датируется 2006 годом, FIO активно развивается и совершенствуется. Утилита позволяет гибко описать тесты с помощью конфигурационных файлов, в которых можно задать любые условия.
Для использования FIO, была установлена ВМ с ОС Ubuntu 12.04 к которой были подключены оба тестируемых хранилища в качестве локальных SCSI-дисков.
Конфигурация тестов
Тест на чтение
Запуск: fio read.ini
Содержимое read.ini
[readtest]
blocksize=4k
filename=/dev/
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
Тест на запись
Запуск: fio write.ini
Содержимое write.ini
[writetest]
blocksize=4k
filename=/dev/
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32
Каждый тест был проведен по три раза после чего в таблицу заносилось среднее значение. Тестирование проводились последовательно. Вначале с одним хранилищем, затем с другим. В один момент времени в работе было только одно хранилище! Кроме выполняемых тестов, ни сервер выполняющий функции хранилища, ни узел виртуализации не были заняты другой работой, кроме стандартных процессов ОС.
Результаты тестирования
Результаты FIO
Выводы
ВыводыКак видно, из сводных таблиц, в большинстве тестов, на одном и том же оборудовании и тех же задачах, iSCSI показывает лучшие результаты производительности. При использовании iSCSI нагрузка на ЦПУ как на хосте, так и у ВМ значительно выше. Такая же ситуация и с нагрузкой на сеть. В тех же задачах, iSCSI генерирует значительно больше трафика чем NFS. В свою очередь нагрузка NFS более равномерная и прогнозируемая.
Отдельно хочется отметить, сильную деградацию производительности NFS при большем количестве операций записи. И хотя в некоторых синтетических тестах на запись, NFS показала лучший результат, время самих тестов, было значительно дольше, чем в случае с iSCSI. В практических же тестах на запись, хорошо видны более высокие показатели iSCSI.