Комментарии 33
НЛО прилетело и опубликовало эту надпись здесь
Пожалуйста. Заинтересует более подробный рассказ на кукую-нибудь из этих тем?
Насколько я помню, первые разговоры про 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 будут чрезмерно большими? На данный момент вряд ли.
2. А насчет оверхеда — вопрос очень хороший, но спорный и объемный (поэтому я от него уклонюсь :)). Оверхеды действительно можно уменьшить, но тогда в жертву будут принесены другие вещи. Теряется совместимость с предыдущими стандартами. Да и есть ли такие задачи, для которых задержки SCSI Express будут чрезмерно большими? На данный момент вряд ли.
Может быть с 11 года что-то поменялось, но речь шла именно про замену SCSI (и вообще, протоколов блочного уровня) на что-то более быстрое.
Речь идёт про возможность снижения latency до наносекундных значений. Сотни микросекунд реальность уже сейчас. В принципе, можно представить себе что-то порядка 50мкс. Но дальше — слишком долго и много перекодировать (в заголовках).
Для кеша latency является ключевой характеристикой. Чем он меньше, тем быстрее решение.
Речь идёт про возможность снижения 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]
Скорость света 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 при работе с памятью».
Вы ещё возмутитесь «зачем вам такая низкая latency при работе с памятью».
Эхх. Тэг сарказм надо было тоже ставить. а не только экстремальный.
Латенси блочного устройства складывается из задержки на среде передачи, задержки на контроллере и задержки на доступе к данным самого контроллера.
Вы рассматриваете частный случай устройства воткнутого напрямую, а я размышляю даже о порнографичном iSCSI у которого можно даже забыть про латенси устройства и контроллера, а на первый план выходит латенси среды передачи.
Но суть в том, что пока внутренняя латенси устройства много больше чем латенси внешнего общения контроллера устройства. Это всеравно, как проектировать подвеску и трансмиссию под 250 км/ч при том что на имеющемся двигателе и геометрии корпуса больше 60 не поедешь.
На мой личный вкус SAS замечательная обертка SCSI и жить ему еще долго и счастливо, ибо обеспечивает одну из лучших сред передачи с малыми (по сравнению с аналогами) потерями. Если еще придумают как его запихивать в оптоволокно (10 метров — не серьезно) — я буду вообще счастлив, ибо смена протокола при переходах с локальных хранилищ на разнесенные — добра не приносит.
Низкая латенси при работе с памятью — ет круто. Осталось найти программно, аппаратную среду которая будет это использовать.А то отработает такты раньше/быстрее/лучше/глубже, а потом сидит и виляет хвостиком с довольным видом, ждет новой задачи.
Латенси блочного устройства складывается из задержки на среде передачи, задержки на контроллере и задержки на доступе к данным самого контроллера.
Вы рассматриваете частный случай устройства воткнутого напрямую, а я размышляю даже о порнографичном iSCSI у которого можно даже забыть про латенси устройства и контроллера, а на первый план выходит латенси среды передачи.
Но суть в том, что пока внутренняя латенси устройства много больше чем латенси внешнего общения контроллера устройства. Это всеравно, как проектировать подвеску и трансмиссию под 250 км/ч при том что на имеющемся двигателе и геометрии корпуса больше 60 не поедешь.
На мой личный вкус SAS замечательная обертка SCSI и жить ему еще долго и счастливо, ибо обеспечивает одну из лучших сред передачи с малыми (по сравнению с аналогами) потерями. Если еще придумают как его запихивать в оптоволокно (10 метров — не серьезно) — я буду вообще счастлив, ибо смена протокола при переходах с локальных хранилищ на разнесенные — добра не приносит.
Низкая латенси при работе с памятью — ет круто. Осталось найти программно, аппаратную среду которая будет это использовать.А то отработает такты раньше/быстрее/лучше/глубже, а потом сидит и виляет хвостиком с довольным видом, ждет новой задачи.
Можно популярную статью о текущих положениях в SAN?
На эту тему можно конечно, но только если что-то новое. О основах на русском уже сто лет как отлично написал Пантюхин Василий из EMC. Если хотите что-то о чем он не писал, то огласите тему, возможно меня заинтересует.
P.S. Вот ещё его блог: hengooru.blogspot.ru/
P.S. Вот ещё его блог: hengooru.blogspot.ru/
Ссылку на статью, видимо, надо было дать вот эту:
hengooru.blogspot.ru/2011/08/fibre-channel-16gbps.html
hengooru.blogspot.ru/2011/08/fibre-channel-16gbps.html
На данный момент во мне бурлит только одна тема, но она на стыке SAN/LAN — это ethernet фабрики (см. brocade VDX). Всё таки вещь уникальная, новая.
Да сколько ж она у вас «новая» будет-то? Уже минимум пару лет как в продакшн вышла.
Замечательная статья. Если можете — пожалуйста исправьте на картинке опечатку. «Четыри» — всетаки глаза режет.
Четырёхзначные индексы разьёмов задолбали, прям русский автопром какой-то.
Чуть в сторону от темы, но всё же интересно, где «подвис» интеловский ThunderBolt, который, казалось бы, должен идеально подойти на межстораджевые связи и прочую инфраструктуру, место которой сейчас занято FC.
Чуть в сторону от темы, но всё же интересно, где «подвис» интеловский ThunderBolt, который, казалось бы, должен идеально подойти на межстораджевые связи и прочую инфраструктуру, место которой сейчас занято FC.
НЛО прилетело и опубликовало эту надпись здесь
InfiniBand!
На самом деле, сравнивать с ICL нельзя, так как к портам ICL устройства не подключишь.
На самом деле, сравнивать с ICL нельзя, так как к портам ICL устройства не подключишь.
НЛО прилетело и опубликовало эту надпись здесь
Brocade DCX десктопный???
Thunderbolt десктопный?!
НЛО прилетело и опубликовало эту надпись здесь
А чем вас не устраивает Thunderbolt в качестве такового? Это PCI-Express, на расстояние в три метра, 10 Гбит/сек есть.
НЛО прилетело и опубликовало эту надпись здесь
Вы знаете, все интерфейсы когда-то прошли путь от «максимально убогого» до широко распространённого, поэтому аппелировать к убогости несколько странно.
Про FC тоже отлично всё, спасибо. Позволю себе напомнить, что пока большая тройка вендоров SAN всего несколько лет назад зависла на FC и IC для стораджей, пришла небольшая такая компания NetApp, реализовала систему «NAS на iSCSI через 10GbaseT» и взорвала рынок хранилок, оттяпав себе бОльшую рынка. Пока «распальцованная» тройка втирала всем про «только FC, только IC!». Это я к тому, что не следует переоценивать технологии по их возрасту, очень многим не нужны фичи FC/IC, а достаточно просто большой и обьёмной хранилки. Для которой TB выглядит превосходно.
Про FC тоже отлично всё, спасибо. Позволю себе напомнить, что пока большая тройка вендоров SAN всего несколько лет назад зависла на FC и IC для стораджей, пришла небольшая такая компания NetApp, реализовала систему «NAS на iSCSI через 10GbaseT» и взорвала рынок хранилок, оттяпав себе бОльшую рынка. Пока «распальцованная» тройка втирала всем про «только FC, только IC!». Это я к тому, что не следует переоценивать технологии по их возрасту, очень многим не нужны фичи FC/IC, а достаточно просто большой и обьёмной хранилки. Для которой TB выглядит превосходно.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тенденции и будущие возможности протокола SCSI