Pull to refresh

Comments 22

показатели доступности и производительности FCoE не сопоставимы с показателями FC, так как передача данных требует дополнительных накладных расходов на инкапсуляцию в TCP/IP.
Какое отношение FCoE имеет к TCP/IP?
Конечно никакого) там Ethernet, поправили опечатку. Спасибо за комментарий.
Коллеги, я заранее прошу прощения если буду понят не правильно, т.к. не хочу никого задеть, но всё же очень хочу задать один вопрос: "эта статья написана одним человеком? Её ведь проверяли Ваши коллеги или нет?"

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

Извините пожалуйста, просто уж очень у меня от прочтения «подгорело», что я впервые за 3 года решил зайти в профиль чтобы спросить. Пишите ещё и много, у Вас это хорошо получалось.
Если какие-то предложения вызывают серьезные вопросы, то мы готовы их выслушать.
Вероятно, мы не смогли изложить мысли должным образом и с вашей помощью готовы раскрыть материал более подробно.

p.s. он прекрасный парень и профи своего дела.
Ok. Давайте начнем с простого — с заголовка и первого предложения которое содержит какой-либо ненулевой смысл.

1. Основные протоколы хранения: использование и перспективы
Что такое протоколы хранения данных? Я вот слыхал про сети хранения данных и протоколы передачи данных, а такую диковинную штуку впервые вижу. Именно из-за неразберихи в терминах, статья которая должна была быть, я так догадываюсь, о SAN, содержит вещи из другой предметной области (особенно радуют «протоколы объектного хранения»).

2. Не секрет, что на сегодняшний день проблемы производительности перемещаются из сферы СХД в область SAN сетей, так как СХД уже достигли огромных показателей производительности в ГБ/с и миллионах IOps, а текущие SAN сети не позволяют прокачивать через себя такие объёмы данных.
Может я чем-то не тем занимаюсь, но для меня это пока секрет. Укажите пожалуйста для каких сфер применения уже массово не хватает рабоче-крестьянских стареньких 8G FC например? Оставим разговоры про ISL — там и так всё понятно. 8G FC всё реже и реже встречается, но мне и тут не понятна эта фраза.
1. Под «протоколами хранения» понимаются протоколы используемые именно в 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Гбит/с?
Нет, серьезно, litweg прав, статья какая-то сумбурная. У вас заголовки:
SAN-сети на основе сетей Ethernet
  • NFS (Network File System)
  • SMB (Server Message Block)
  • InfiniBand (IB)
  • NVMe (NVM Express)
  • PCIe

Почему здесь смешаны и протоколы для доступа к файлам по сети, и типы физического подключения сети, и типы физического подключения дисков?
Вот аналогия вашим заголовкам более понятными словами:
  • HTTP
  • FTP
  • Ethernet
  • SAS
  • SATA
Cогласны с сумбурностью и понимаем, что нужно было чуть-чуть по-другому структурировать статью. Например вот так:

• InfiniBand
• NVMe
• PCIe
• SAN-сети на основе Ethernet
  1. NFS
  2. SMB

1. Взяли и придумали свой термин. Всего-то надо было написать — протоколы сетей 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).

Что касается 8G FC, то ни где и ни кто в здравом уме не будет подключать продакшн сервера без dual fabric, а это значит что адаптер на хосте в худшем случае один двухпортовый (а лучше две шт) и с любой современной СХД в active-active режиме мы получил пропускную способность (с точки зрения SAN а не СХД) не менее 1.6 ГБ/сек для одного хоста, что обычно хватает даже для media компаний.
Вы правы, только стоит уже переходить на 16Гб/с, потому что, к сожалению для многих, 8Гб/с не хватает. В media компаниях которые работают с несжатыми 4K/8K форматами видео — 8Гбит уже не достаточно несколько лет.
1. Спасибо, ваш вариант действительно лучше.

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ТБ гелевые диски, но они пока не очень то доступны.
А это что за такой формат, если 8к hdr с helium просит только 520МБ/с?
4k dpx гонять по сети на монтажках чтоли?
Именно, гоняют dpx последовательности. Особенно актуально для цветокоррекции.
Вы забыли момент что сейчас становятся популярны решения по типу vSAN (VSAN, CEPH, SolidFire, ScaleIO, Nutanix, Starwind и т.п.) и вобще стараются уже делать гиперконвергентные решения (хранилка+виртуализация в одном корпусе). Большие производители (EMC,Netapp,VmWare и т.п.) уже продают данные решения. А это все-таки Ethernet. И при наличии поддержки RDMA(RoCEv2,iWARP) довольно сильно сокращается latency (практически до решений IB, что уже быстрее FC), и получается что FC как протокол становится не нужен т.к. слишком узкоприменим. А скидку на разовую суммарную поставку коммутаторов Ethernet можно получить больше чем скидки раздельно на Ethernet+FC фермы. Либо оборудования понадобится меньше (не хватит скорости — можно например на 200Gbit Ethernet перейти) и плюс не надо будет поддерживать несколько технологий в ДЦ.

По latency:

image

Хорошее добавление. Мы не забыли этот момент, просто статья ориентирована не на гиперконвергентные решения, а на классических решениях SAN.
Обзоры этих решений заслуживают отдельной статьи, возможно, даже не одной.

Безусловно RoCE и iWARP сокращают latency, а вопрос затрат при переходе на них довольно дискуссионный.
А VSAN и Nutanix поддерживают RoCE?
У первых оно появилось совсем недавно и в HCL пока ни одного устройства, вот MS его умеет с 2012, но сама распределённая СХД пока в зачаточном состоянии.
vSAN, NetApp поддерживает iSER, который, в свою очередь, работает поверх RoCE или iWARP. Драйвера есть для VMware (есть KB), NetApp поддерживает «из коробки» iSER. Со стороны клиента нужны соответствующие адаптеры.
Что же будет оптимальным для небольших сред с 4-5 серверами и хранилкой при наличие Exchange'ей, кластеров 1С с SQL'ем, корпоративными порталами и т.д? Кто-то за FC с выделенным под это железом, а кто-то и за 10G, чтобы не плодить лишнего. Где та золотая середина, чтобы быть на волне производительности, масштабируемости, простоты управления и стоимости, минимум лет на 5-7?
Хорошим вариантом будет использование iSER в связке с RoCEv2.

На сколько хорошо рынок освоил эти технологии? Не станут ли они такой же туманной перспективой как и FCoE? На данный момент обратившись к интеграторам за конфигурированием железа для кластера виртуализации с 5ю ногами все как одно предлагают классический вариант с FC. Какие-то гиперконвергентные решения не сильно хотят обсуждать. В их рассуждениях классика это самый оптимальный вариант с гарантией на работу. Тем более, что если это решение идет в интерпрайс.

Не могу сказать, что рынок освоил iSER также хорошо как и FC, только потому что FC слишком давно на рынке. Есть решение с поддержкой iSER, как от именитых вендоров, так и от стартапов. По отчётам и исследованиям SNIA количество продуктов поддерживающих iSER постоянно растёт, особенно в all-flash решениях. Enterprise — это часто консервативные технологии, которые до них проверили другие. Сейчас iSER активней всего «обкатывается» в облачных провайдерах.

На самом деле, сложно говорить о зрелости технологии и ей освоении, когда она на рынке где-то 3-4 года.
Sign up to leave a comment.