Pull to refresh

Comments 33

UFO just landed and posted this here
Пожалуйста. Заинтересует более подробный рассказ на кукую-нибудь из этих тем?
Да. С интересом бы прочитал подробнее про SCSI и Multilink SAS.

Спасибо.
Насколько я помню, первые разговоры про SCSI express начались в 2011 году (IDF) и там речь шла в первую очередь не о SCSI, а о P-n-P PCI Express с хотплагом и уменьшенным оверхедом от SCSI. Основная проблема — для MTD (memory technology devices) SCSI протокол (как и любой другой протокол блочного уровня) слишком медленный — он даёт до 90% от общего latency при обслуживании, например, памяти с батрейкой. Новые SSD на чтение уже начинают приближаться к оперативной памяти, и основное, что их тормозит — это необходимость кодировать/раскодировать данные в довольно сложный протокол взаимодействия с кодированием WWN и флагов в каждый запрос.
1. Вы перепутали SCSI Express с NVM Express.
2. А насчет оверхеда — вопрос очень хороший, но спорный и объемный (поэтому я от него уклонюсь :)). Оверхеды действительно можно уменьшить, но тогда в жертву будут принесены другие вещи. Теряется совместимость с предыдущими стандартами. Да и есть ли такие задачи, для которых задержки SCSI Express будут чрезмерно большими? На данный момент вряд ли.
Может быть с 11 года что-то поменялось, но речь шла именно про замену SCSI (и вообще, протоколов блочного уровня) на что-то более быстрое.

Речь идёт про возможность снижения latency до наносекундных значений. Сотни микросекунд реальность уже сейчас. В принципе, можно представить себе что-то порядка 50мкс. Но дальше — слишком долго и много перекодировать (в заголовках).

Для кеша latency является ключевой характеристикой. Чем он меньше, тем быстрее решение.
Окститесь батюшка. 50 мкс это 5*10(-5) сек.
Скорость света 299 792 458 м / с. За 50 мкс свет проходит 15 км.
В пределах отдельно взятого ЦОД такие латенси конечно круть, но при репликации с внешкой уже через 15 км получим удвоение изза ограничений скорости света.
Извините, но полэкватора делить на скорость света (репликационные реалии при работе с ЦОД в Токио из Лондона), дают нам 0,066 сек.
Так же не забывайте физический seek&read time. Если мы спилим латенси на контроллере диска с 0.2 мс до 0.05 мс, а seek time самого харда (шпинтели) как был так и стоит на 2 мс — нафига оно надо то? У ССД seek time считается равным 0.1 мс. Тут профит уже более или менее ясен, но становится понятно другое — нишевость решения. Настолько низкие латенси нужны настолько мало и редко, при том в основном для кеширования. А для кеширования как бы уже есть штука с оочень низкой латенси — называется RAM. И всетаки висит не на PCI шине за южным (северным) мостом, а напрямую подцеплена к процессору.
В общем поддерживаю мысль замены SCSI: Нафига пытаться натягивать на глобус интерфейс 30-ти летней давности — отправьте его уже на пенсию и дайте дорогу молодым.
[extreme sarcasm]В конце концов у него есть смысловой потомок под названием USB (SCSI как бы исторически разрабатывался для подключения всего: от сканеров до флоповодов, но по остальным направлениям был пристукан USB и своей безбожной стоимостью и сохранился только в storage направлении).технически та же связка контроллер-устройство, параллельная архитектура, латенси и скорости конечно хромают, но это в принципе вопрос разработки.[/extreme sarcasm]
При чём тут вообще сеть? Речь про latency блочных устройств. И касается он не ответа клиентам или репликации между дата-центрами, а времени ответа дискового устройства на запросы ОС.

Вы ещё возмутитесь «зачем вам такая низкая latency при работе с памятью».
Эхх. Тэг сарказм надо было тоже ставить. а не только экстремальный.
Латенси блочного устройства складывается из задержки на среде передачи, задержки на контроллере и задержки на доступе к данным самого контроллера.
Вы рассматриваете частный случай устройства воткнутого напрямую, а я размышляю даже о порнографичном iSCSI у которого можно даже забыть про латенси устройства и контроллера, а на первый план выходит латенси среды передачи.
Но суть в том, что пока внутренняя латенси устройства много больше чем латенси внешнего общения контроллера устройства. Это всеравно, как проектировать подвеску и трансмиссию под 250 км/ч при том что на имеющемся двигателе и геометрии корпуса больше 60 не поедешь.
На мой личный вкус SAS замечательная обертка SCSI и жить ему еще долго и счастливо, ибо обеспечивает одну из лучших сред передачи с малыми (по сравнению с аналогами) потерями. Если еще придумают как его запихивать в оптоволокно (10 метров — не серьезно) — я буду вообще счастлив, ибо смена протокола при переходах с локальных хранилищ на разнесенные — добра не приносит.
Низкая латенси при работе с памятью — ет круто. Осталось найти программно, аппаратную среду которая будет это использовать.А то отработает такты раньше/быстрее/лучше/глубже, а потом сидит и виляет хвостиком с довольным видом, ждет новой задачи.
Можно популярную статью о текущих положениях в SAN?
На эту тему можно конечно, но только если что-то новое. О основах на русском уже сто лет как отлично написал Пантюхин Василий из EMC. Если хотите что-то о чем он не писал, то огласите тему, возможно меня заинтересует.

P.S. Вот ещё его блог: hengooru.blogspot.ru/
Это тоже, но вообще у него много различных статей по FC, поэтому не привел конкретную, а дал ссылку на ресурс.
На данный момент во мне бурлит только одна тема, но она на стыке SAN/LAN — это ethernet фабрики (см. brocade VDX). Всё таки вещь уникальная, новая.
Да сколько ж она у вас «новая» будет-то? Уже минимум пару лет как в продакшн вышла.
Новая в моем понимании она будет пока не получит какого-нибудь распространения. Вы очень много инсталляций видели?
Да порядочно. А что в вашем понимании «много»? «Сколько орехов составляет кучу?»
Оттого, что эникейщик Сережа (установка и администрировани 1C: Предприятия «под ключ») не видел ни одной инсталляции с FC, разве это может делать его чем-то, что «пока не получило какого-нибудь распространения»?
И предвосхищаю Ваш возможный вопрос с целью потролить — что же будет если ethernet фабрики так и не станут широко применяемой технологией? Ответ: они умрут молодыми.
Замечательная статья. Если можете — пожалуйста исправьте на картинке опечатку. «Четыри» — всетаки глаза режет.
Четырёхзначные индексы разьёмов задолбали, прям русский автопром какой-то.

Чуть в сторону от темы, но всё же интересно, где «подвис» интеловский ThunderBolt, который, казалось бы, должен идеально подойти на межстораджевые связи и прочую инфраструктуру, место которой сейчас занято FC.
UFO just landed and posted this here
InfiniBand!

На самом деле, сравнивать с ICL нельзя, так как к портам ICL устройства не подключишь.
UFO just landed and posted this here
Brocade DCX десктопный???
Thunderbolt десктопный?!
UFO just landed and posted this here
А чем вас не устраивает Thunderbolt в качестве такового? Это PCI-Express, на расстояние в три метра, 10 Гбит/сек есть.
UFO just landed and posted this here
Вы знаете, все интерфейсы когда-то прошли путь от «максимально убогого» до широко распространённого, поэтому аппелировать к убогости несколько странно.
Про FC тоже отлично всё, спасибо. Позволю себе напомнить, что пока большая тройка вендоров SAN всего несколько лет назад зависла на FC и IC для стораджей, пришла небольшая такая компания NetApp, реализовала систему «NAS на iSCSI через 10GbaseT» и взорвала рынок хранилок, оттяпав себе бОльшую рынка. Пока «распальцованная» тройка втирала всем про «только FC, только IC!». Это я к тому, что не следует переоценивать технологии по их возрасту, очень многим не нужны фичи FC/IC, а достаточно просто большой и обьёмной хранилки. Для которой TB выглядит превосходно.
UFO just landed and posted this here
UFO just landed and posted this here
Thunderbolt существенно дешевле. Он дешевле даже 10Гбит ethernet, который, напомню, весьма активно продвигается и используется в стораджевых моделях «NAS + iSCSI вместо SAN + FC/IC»
Sign up to leave a comment.

Articles