В этой статье мы проведем небольшой обзор наиболее популярных протоколов, которые используются для построения сетей хранения данных (SAN). Также рассмотрим перспективы развития и использования отдельных протоколов, опираясь на общедоступные роудмапы производителей.
Не секрет, что на сегодняшний день проблемы производительности перемещаются из сферы СХД в область SAN сетей, так как СХД уже достигли огромных показателей производительности в ГБ/с и миллионах IOps, а текущие SAN сети не позволяют прокачивать через себя такие объёмы данных.
Общие тенденции
Существующие сети FC 8Гб/с и Ethernet 10Гб/с уже не справляются c современными СХД, даже Ethernet 25/50 Гб/с не может обеспечить приемлемые задержки при работе с последними моделями СХД, использующими NVMe диски.
Многие ИТ-специалисты, занимающимся настройкой и администрированием инфраструктуры хранения, задаются вопросом о модернизации SAN-сетей. Почему же это так важно и необходимо на сегодняшний день? Сформулируем несколько основных причин:
- Во-первых, плотность хранения данных постоянно растёт, увеличиваются объёмы как HDD дисков, так и флэш-накопителей. Уже сейчас на рынке доступны HDD объёмом 10ТБ и SSD до 3.2ТБ.
- Во-вторых, скорость флэша и гибридных СХД растёт в двух аспектах: увеличивается пропускная способность и уменьшаются задержки. Например, последние модели NVMe-накопителей имеют производительность порядка 3ГБ/с и задержки в 20 мкс.
- В-третьих, потребность в обработке миллионов IOps. Уже сейчас один NVMe-диск способен выдавать до 700+ тысч IOps.
- В-четвёртых, потребность увеличивать производительность на один порт подключения. Если раньше с одного порта QSFP+ на протоколе InfiniBand получали максимум 56Гб/с, то уже в этом году есть решения с производительностью 200Гб/с на порт.
С учетом всех этих факторов ключевыми характеристиками протоколов доступа становятся высокая пропускная способность и быстрое время отклика.
По существующим прогнозам, в перспективе двух лет (по данным Gartner, в течение 18 месяцев) all-flash массивы будут комплектоваться более производительными SSD-дисками, а в сочетании с быстрым интерконнектом (например, NVMe) и новыми протоколами (например, iWARP) производительность all-flash массивов повысится ещё на два порядка, что приведёт к необходимости модернизировать SAN.
Сравнение протоколов
Все SAN сети, будь то Ethernet, PCI Express, SAS, NVMeoF, FC, FCoE или InfiniBand, должны поддерживать одинаковый функционал, а именно:
- идентифицировать хост и СХД;
- иметь возможность маршрутизировать траффик;
- разделять сеть на подсети и изолировать в них траффик;
- обеспечивать возможность использования нескольких путей к СХД;
- управлять подключением устройств к сети;
- приоритизировать траффик.
Учитывая схожий реализуемый функционал, можно сказать, что различия между протоколами сводятся к удобству использования, параметрам производительности и издержкам реализации. Так, некоторые протоколы имеют более развитые средства управления и мониторинга, что делает их более простыми для внедрения, администрирования и эксплуатации. Другие протоколы имеют лучшую производительность, но представляются более сложными в плане интеграции в текущие SAN-сети.
На сегодняшний день протоколы хранения данных можно разделить на две условные группы:
- используемые для подключения серверов приложений (FC, FCoE, iSCSI, NFS, SMB);
- используемые для подключения в рамках кластера или в качестве интерконнекта внутри СХД (InfiniBand, NVMe, PCIe).
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 строится на двух наиболее часто используемых протоколах:
- SCSI — протоколе обмена блоками данных между компьютером и хранилищем
- IP — сетевом транспортном протоколе, широко применяемом в корпоративных сетях Ethernet.
iSCSI — это низкобюджетное решение для внедрения. Администрирование таких инсталляций очень простое, хотя для обеспечения отказоустойчивости необходимо строить выделенную сеть для iSCSI, что приближает нас к сетевой реализации, очень похожей на FC SAN.
Считается, что 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
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Гб/с и более новые версии.
In?niBand, 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.
Комментарии (19)
litweg
26.05.2017 01:08+2Коллеги, я заранее прошу прощения если буду понят не правильно, т.к. не хочу никого задеть, но всё же очень хочу задать один вопрос: "эта статья написана одним человеком? Её ведь проверяли Ваши коллеги или нет?"
Просто она написана человеком, который совсем никогда не работал с тем о чем написана эта статья. Он вероятно конечно прекрасный парень и профи своего дела, но про SAN черпал информацию из всяких статей на wikipedia и других интернетов — реального опыта и близко не было. Тут как бы сложно найти два подряд идущих предложения, которые как минимум не вызывают серьёзных вопросов.
Извините пожалуйста, просто уж очень у меня от прочтения «подгорело», что я впервые за 3 года решил зайти в профиль чтобы спросить. Пишите ещё и много, у Вас это хорошо получалось.raidixteam
26.05.2017 12:48Если какие-то предложения вызывают серьезные вопросы, то мы готовы их выслушать.
Вероятно, мы не смогли изложить мысли должным образом и с вашей помощью готовы раскрыть материал более подробно.
p.s. он прекрасный парень и профи своего дела.litweg
26.05.2017 14:25+1Ok. Давайте начнем с простого — с заголовка и первого предложения которое содержит какой-либо ненулевой смысл.
1. Основные протоколы хранения: использование и перспективы
Что такое протоколы хранения данных? Я вот слыхал про сети хранения данных и протоколы передачи данных, а такую диковинную штуку впервые вижу. Именно из-за неразберихи в терминах, статья которая должна была быть, я так догадываюсь, о SAN, содержит вещи из другой предметной области (особенно радуют «протоколы объектного хранения»).
2. Не секрет, что на сегодняшний день проблемы производительности перемещаются из сферы СХД в область SAN сетей, так как СХД уже достигли огромных показателей производительности в ГБ/с и миллионах IOps, а текущие SAN сети не позволяют прокачивать через себя такие объёмы данных.
Может я чем-то не тем занимаюсь, но для меня это пока секрет. Укажите пожалуйста для каких сфер применения уже массово не хватает рабоче-крестьянских стареньких 8G FC например? Оставим разговоры про ISL — там и так всё понятно. 8G FC всё реже и реже встречается, но мне и тут не понятна эта фраза.raidixteam
26.05.2017 16:211. Под «протоколами хранения» понимаются протоколы используемые именно в SAN сетях, в англоязычных публикация, есть понятие «storage protocols», обозначающее протоколы передачи данных в привязке к используемым в сетях хранения данных, протоколам передачи данных. Кстати Вас не смущает, что существует сеть хранения данных?
А вообще протоколов передачи много, есть даже RFC 1149 на передачу IP пакетов посредством почтовых голубей, так что с его помощью можно организовать целую сеть хранения данных.
Что касается, термина «протоколы объектного хранения» — это калька с английского «Object Storage Protocols», в статье можно было использовать другие формулировки – например — «протоколы объектного доступа к системах хранения данных». так работает в основном с западными компаниями, то не произвольно проскакивают англицизмы. В блоге EMC – например прям так и пишут https://community.emc.com/docs/DOC-33680
2. Массово не хватает 8Гбит для производства кино, сейчас самый популярный формат при видеомонтаже коммерческий фильмов — несжатый 4K. Один такой формат требует 1.5ГБ/с. Обычно на одной рабочей станции одновременно обрабатывают 2-4 потока, т.е. на одну монтажную станцию нужно 3-6ГБ/с. В производстве фильмов участвуют несколько таких станций.
Только вчера прилетел проект 45ГБ/с на запись с 5 серверов, т.е. по 5ГБ/с с каждого. С ограничением для СХД 2U, а для серверов 1U. Как это впихнуть в 8Гбит/с?ValdikSS
27.05.2017 11:08Нет, серьезно, litweg прав, статья какая-то сумбурная. У вас заголовки:
SAN-сети на основе сетей Ethernet
- NFS (Network File System)
- SMB (Server Message Block)
- InfiniBand (IB)
- NVMe (NVM Express)
- PCIe
Почему здесь смешаны и протоколы для доступа к файлам по сети, и типы физического подключения сети, и типы физического подключения дисков?
Вот аналогия вашим заголовкам более понятными словами:
- HTTP
- FTP
- Ethernet
- SAS
- SATA
raidixteam
01.06.2017 15:54Cогласны с сумбурностью и понимаем, что нужно было чуть-чуть по-другому структурировать статью. Например вот так:
• InfiniBand
• NVMe
• PCIe
• SAN-сети на основе Ethernet
- NFS
- SMB
litweg
28.05.2017 03:021. Взяли и придумали свой термин. Всего-то надо было написать — протоколы сетей SAN.
2. Я читал много историй успеха для media с тех подробностями (в основном зарубежные правда), но Ваши требования какие-то слегка странные как мне кажется (тут должна быть картинка лица с недоверчивым прищуром). Лучше покажите возможное решение которое удовлетворит всем этим требованиям и не забудьте указать требуемую емкость СХД.
Проблема в следующем:
NL SAS. Вы не можете использовать для этого кейса большие enterprise NL диски (обычно в таких кейсах только их и используют), которые хорошо справляются с sequential write (блок от 256К и более). Вы их натолкате максимум 12 штук в одну полку 2U — больше пока не придумали. Возьмем например один вариант от Seagate на 8ТБ (ST8000NM004) — у вас наверняка будут меньше, т.к. он по меркам enterprise совсем свежий и его нигде нет и линейная скорость в Вашем варианте будет меньше. У него sequential write = 249 МБ/сек. Если умножить на 12, то получим всего-то 2988 МБ/сек. То есть Вы без учета всякий raid penalty даже одну рабочую станцию не обслужите.
SFF SAS. Вы не сможете использовать бOльшее количество 2.5" дисков по той же причине. Если опять же взять enterprise SAS/SATA, которые сейчас максимум 1.8 — 2 ТБ, то их вы натолкаете 25 шт. на полку или меньше. Рекордсмены достигают на запись (последовательно 256k и более) 135-140 МБ. Выходит всего 3500 МБ/сек — даже одну рабочую станцию на обслужите.
SSD бывает много и разных, но по моим подсчетам, которые я не могу привести здесь Вы наверное могли бы получить максимум 7 — 7.3 ГБ / сек на запись на бекенде. Это при использовании дисков объемом не менее 3.84 ТБ. Иначе Вы свой массив за несколько десятков секунд заполните полностью таким потоком. Это всё ещё не хватает даже для одного клиента.
И последнее — что Вы будете использовать в качестве контроллеров, которые Вы хотите засунуть в теже 2U к дискам? Вы конечно же делали тесты производительности и эта железка конечно же с легкостью прокачает Вам 45 ГБ/сек? Я такие решения знаю, но они сильно больше чем 2U.
P.S Вы писали: Уже сейчас на рынке доступны HDD объёмом 10ТБ и SSD до 3.2ТБ.
Исправьте, а то я тут в прошлом году трогал SSD объемом 15.36 ТБ форм-фактора 2.5". Другого форм фактора такие были доступны года 4 назад ещё если не больше (tomahavk).
litweg
28.05.2017 03:11Что касается 8G FC, то ни где и ни кто в здравом уме не будет подключать продакшн сервера без dual fabric, а это значит что адаптер на хосте в худшем случае один двухпортовый (а лучше две шт) и с любой современной СХД в active-active режиме мы получил пропускную способность (с точки зрения SAN а не СХД) не менее 1.6 ГБ/сек для одного хоста, что обычно хватает даже для media компаний.
raidixteam
01.06.2017 15:58Вы правы, только стоит уже переходить на 16Гб/с, потому что, к сожалению для многих, 8Гб/с не хватает. В media компаниях которые работают с несжатыми 4K/8K форматами видео — 8Гбит уже не достаточно несколько лет.
raidixteam
01.06.2017 15:571. Спасибо, ваш вариант действительно лучше.
2. Требование не наши, а заказчика, но какие есть, и нам с ними работать и убеждать как сделать лучше. Производительность же в 45ГБ/с на 5 клиентов, остаётся, сейчас прорабатывается решения на PCIe NMVe со скоростью каждого накопителя 6ГБ/с на запись и чтение.
2.1. В 2U полку можно напихать 24 диска 3.5", у supermicro есть решение. У HGST 8TB уже давно на рынке, так что можно на них строить.
2.2. По нашим тестам большинство дисков на потоке уже сейчас выдают 180-200МБ/с, но, действительно, не очень целесообразно их использовать.
2.3. На PCIe SSD на запись на бэкенде получали 26ГБ/с, конечно не с одного диска, а с 5-ти. Модели тут указать не можем, к сожалению.
2.4. Хотим PCIe NVMe использовать, пока 26ГБ/с, но тут надо оптимизировать ещё.
2.5. По нашим тестам на чтение и запись с 226 NL-SAS на бэкенде в RAID6 получаем 15ГБ/с.
3. 15ТБ от известного корейского бренда — это, конечно, хорошо, но они же предлагают 32ТБ, а упомянутый вами Seagate ещё в 2016 представил 60ТБ SSD, но основные игроки на рынке хранения предлагают сейчас SSD объёмом 3.2ТБ. Что касается 10ТБ, то HGST конечно выпустил 12ТБ гелевые диски, но они пока не очень то доступны.
Egorkkk
31.05.2017 00:14А это что за такой формат, если 8к hdr с helium просит только 520МБ/с?
4k dpx гонять по сети на монтажках чтоли?raidixteam
01.06.2017 15:58+1Именно, гоняют dpx последовательности. Особенно актуально для цветокоррекции.
Gasaraki
26.05.2017 12:29Вы забыли момент что сейчас становятся популярны решения по типу vSAN (VSAN, CEPH, SolidFire, ScaleIO, Nutanix, Starwind и т.п.) и вобще стараются уже делать гиперконвергентные решения (хранилка+виртуализация в одном корпусе). Большие производители (EMC,Netapp,VmWare и т.п.) уже продают данные решения. А это все-таки Ethernet. И при наличии поддержки RDMA(RoCEv2,iWARP) довольно сильно сокращается latency (практически до решений IB, что уже быстрее FC), и получается что FC как протокол становится не нужен т.к. слишком узкоприменим. А скидку на разовую суммарную поставку коммутаторов Ethernet можно получить больше чем скидки раздельно на Ethernet+FC фермы. Либо оборудования понадобится меньше (не хватит скорости — можно например на 200Gbit Ethernet перейти) и плюс не надо будет поддерживать несколько технологий в ДЦ.
По latency:
raidixteam
26.05.2017 12:38Хорошее добавление. Мы не забыли этот момент, просто статья ориентирована не на гиперконвергентные решения, а на классических решениях SAN.
Обзоры этих решений заслуживают отдельной статьи, возможно, даже не одной.
Безусловно RoCE и iWARP сокращают latency, а вопрос затрат при переходе на них довольно дискуссионный.
oleggmg
31.05.2017 14:18Что же будет оптимальным для небольших сред с 4-5 серверами и хранилкой при наличие Exchange'ей, кластеров 1С с SQL'ем, корпоративными порталами и т.д? Кто-то за FC с выделенным под это железом, а кто-то и за 10G, чтобы не плодить лишнего. Где та золотая середина, чтобы быть на волне производительности, масштабируемости, простоты управления и стоимости, минимум лет на 5-7?
raidixteam
01.06.2017 15:59Хорошим вариантом будет использование iSER в связке с RoCEv2.
oleggmg
02.06.2017 23:36На сколько хорошо рынок освоил эти технологии? Не станут ли они такой же туманной перспективой как и FCoE? На данный момент обратившись к интеграторам за конфигурированием железа для кластера виртуализации с 5ю ногами все как одно предлагают классический вариант с FC. Какие-то гиперконвергентные решения не сильно хотят обсуждать. В их рассуждениях классика это самый оптимальный вариант с гарантией на работу. Тем более, что если это решение идет в интерпрайс.
Skyroger2
raidixteam
Конечно никакого) там Ethernet, поправили опечатку. Спасибо за комментарий.