Comments 46
Очень здорово и легко читать. Спасибо.
Каковы по вашему мнению перспективы на будущее у данного стандарта? Есть ли что противопоставить IB, который всё больше и больше входит в обиход?
У меня есть 3 железки связанные по FC 8 между собой, бекапы делаю с фермы виртуалок и раздаю по iscsi дальше ресурсы. Но на достаточно большой части серверов есть IB интерфейсы, но свитчи кусаются по стоимости. Вот думаю, ждать доступного IB, или купить уже доступные FC карточки и связать таким образом все хранилища.
Каковы по вашему мнению перспективы на будущее у данного стандарта? Есть ли что противопоставить IB, который всё больше и больше входит в обиход?
У меня есть 3 железки связанные по FC 8 между собой, бекапы делаю с фермы виртуалок и раздаю по iscsi дальше ресурсы. Но на достаточно большой части серверов есть IB интерфейсы, но свитчи кусаются по стоимости. Вот думаю, ждать доступного IB, или купить уже доступные FC карточки и связать таким образом все хранилища.
К сожалению, ничего не могу сказать про IB, и насколько он уже «всё больше и больше». Ни разу не довелось с ним на практике столкнуться.
Про вытеснение FC медью и iSCSI/NAS слышал ещё три или четыре года назад, что уже вот-вот. Но сколь-нибудь значительного изменения ситуации с тех пор не увидел.
Однако что-то советовать не возьмусь, поскольку работаю не у вендора/дистрибьютера/интегратора, а у заказчика и статистики уже пару лет не видел. А пару лет назад IB был слишком специфичен и дорог, чтобы вообще его рассматривать как вариант (если это не обусловлено специальными потребностями).
Сам бы я по понятным причинам выбрал FC :) Или iSCSI. Или NAS (Netapp), в зависимости от начальных условий и потребностей.
Про вытеснение FC медью и iSCSI/NAS слышал ещё три или четыре года назад, что уже вот-вот. Но сколь-нибудь значительного изменения ситуации с тех пор не увидел.
Однако что-то советовать не возьмусь, поскольку работаю не у вендора/дистрибьютера/интегратора, а у заказчика и статистики уже пару лет не видел. А пару лет назад IB был слишком специфичен и дорог, чтобы вообще его рассматривать как вариант (если это не обусловлено специальными потребностями).
Сам бы я по понятным причинам выбрал FC :) Или iSCSI. Или NAS (Netapp), в зависимости от начальных условий и потребностей.
Продажи оборудования FC продолжают расти, так что пока будущее есть, на плато ещё не вышли. Противопоставить IB можно наличие систем хранения данных у большинства вендоров. Системы хранения данных на IB — довольно большая редкость, нишевый рынок. Блочных систем для IB практически нет.
В NetApp E-Series есть карточка IB.
И для чего она там используется?
Для подключения хостов в High Performance Computing. Или о чём вы, могли быть варианты?
В HPC обычно используется файловый доступ. То есть, во-первых, HPC — редкость, во-вторых, блочного доступа на Инфинибенде всего несколько систем в мире. Это я всё к тезису о том, что рынок FC с рынком IB практически не пересекаются и заменить друг друга не могут (ну, да, могут, только рынок это не принял).
Спасибо за статью.
Имеется вопросы:
1. Есть ли технические средства (аппаратные или программные), которые позволяют захватить-разобрать FC обмен?
2. Может быть есть какие нибудь модели взаимодействия на языках высокого уровня?
3. Какая изменяется скорость доступа ( IOPS ) к дискам при FC?
Имеется вопросы:
1. Есть ли технические средства (аппаратные или программные), которые позволяют захватить-разобрать FC обмен?
2. Может быть есть какие нибудь модели взаимодействия на языках высокого уровня?
3. Какая изменяется скорость доступа ( IOPS ) к дискам при FC?
1. Есть. Но в основном они не доступны для конечных пользователей и по причине заоблачной стоимости не имеют практического смысла (в обычных условиях). Всякие АНБ такие средства имеют, но это довольно специфичные комплексы.
2. Зачем? Ну и непонятно что там можно делать на языке высокого уровня.
3. Немного не понял вопрос. Но если о пропускной способности, то 1 FC шнурок может теоретически пропустить около миллиона IOPS.
2. Зачем? Ну и непонятно что там можно делать на языке высокого уровня.
3. Немного не понял вопрос. Но если о пропускной способности, то 1 FC шнурок может теоретически пропустить около миллиона IOPS.
FC шнурок может теоретически пропустить около миллиона IOPS
Что-то я очень сомневаюсь.
Мне не удавалось получить больше 100к IOPS (блоками по 512) при тестировании 8Gb FC с NULL бэкендом.
Гонял как через прямой линк (хост-хост), так и через свич.
В качестве таргета Linux + SCST, железяки Qlogic 2562.
Миллион IOPS — это, скорее, для Infiniband задача выполнимая.
По крайней мере такие цифры присутствуют в некоторых документах.
Например:
Emulex LPe16000B Gen 5 Fibre Channel HBA Feature Comparison
Цитата про FC 16G: «The Emulex LPe16000B is the fastest generally available FC HBA evaluated by Demartek to date for these tests. The architecture enables all resources to be applied to a single-port, enabling 1.2 million IOPS on a single-port when needed»
Цитата про FC 8G: «Up to 4.6X faster in 8Gb Mode than the QLogic adapters – The LPe16002B achieved more than 922K IOPS running at 8Gb with 512 block sizes, while both the QLE2672 and QLE2562 were limited to 200K IOPS, using the same test parameters as the 16Gb tests»
Например:
Emulex LPe16000B Gen 5 Fibre Channel HBA Feature Comparison
Цитата про FC 16G: «The Emulex LPe16000B is the fastest generally available FC HBA evaluated by Demartek to date for these tests. The architecture enables all resources to be applied to a single-port, enabling 1.2 million IOPS on a single-port when needed»
Цитата про FC 8G: «Up to 4.6X faster in 8Gb Mode than the QLogic adapters – The LPe16002B achieved more than 922K IOPS running at 8Gb with 512 block sizes, while both the QLE2672 and QLE2562 were limited to 200K IOPS, using the same test parameters as the 16Gb tests»
По третьему вопросу: скорость доступа к дискам в IOPS от среды передачи не зависит.
тогда какой смысл тратить много денег на FC при существоании практически бесплатного iSCSI?
latency?
Ну и можно уточнить что считать средой передачи.
От конкретного одного шнурка зависит не так уж много — альтернативы есть. А вот с инфраструктурой в целом все несколько сложнее.
Ну и можно уточнить что считать средой передачи.
От конкретного одного шнурка зависит не так уж много — альтернативы есть. А вот с инфраструктурой в целом все несколько сложнее.
Ну допустим у вас есть 2 одинаковых системы, одна на FC, вторая на iSCSI. Сколько разницы этой latency вы получите?
Две одинаковых сферических системы в вакууме и стоить будут примерно одинаково.
Бесплатный iSCSI — это 1G и он реально сильно проигрывает FC (что не удивительно).
iSCSI 10G это уже не такое уж дешевое решение вполне сравнимое по ценам с FC при сравнимой производительности.
У меня в наличии есть IBM V3700 с FC 8G и штатным iSCSI если Вам сильно интересно могу бенчмарк какой-нибудь запустить. 10G эзернета у меня к сожалению нет, так что по нему я вам данных не дам.
Бесплатный iSCSI — это 1G и он реально сильно проигрывает FC (что не удивительно).
iSCSI 10G это уже не такое уж дешевое решение вполне сравнимое по ценам с FC при сравнимой производительности.
У меня в наличии есть IBM V3700 с FC 8G и штатным iSCSI если Вам сильно интересно могу бенчмарк какой-нибудь запустить. 10G эзернета у меня к сожалению нет, так что по нему я вам данных не дам.
«Почти бесплатный» iSCSI имеет место, если нет высокоактивных, в части потребления дисковых ресурсов, сервисов. То есть для небольшого количества виртуалок, файловых серверов и архивных хранилищ. В противном случае быстро выясняется, что инфраструктура iSCSI обходится дороже FC.
Что значит «высокоактивный»? FC при прочих равных выдает больше IOPS, чем iSCSI?
UFO just landed and posted this here
FC выдаст больший IOPS за счет следующих факторов:
1. Меньше слоев над физикой нагорожено. Соответственно, чтобы упаковать данные в FC требуется меньше действий.
2. Протокол заранее был спроектирован под низкую латентность и сети хранения с 1 слоя и дальше вверх.
iSCSI же был впихнут поверх существующего Ethernet/IP/TCP стека и, соответственно, наследует все его плюсы и минусы (такие как потери пакетов, ретрансмиты и прочие костыли). Большинство этих проблем, кстати, решено в Data Center Ethernet и работающем над ним FCoE (это не замена iSCSI, конечно, т.к. FCoE работает на 3 уровне, но тем не менее)
3. Тот факт, что в большинстве случаев для реализации iSCSI используется софтовый стек, а не железные HBA, тоже вносит свои задержки.
А вот будет ли заметна эта дополнительная латентность в работе конкретного софта — другой вопрос.
С ценами на FC интересное дело — свичи (те же Cisco MDS9148) стоят сильно дешевле 10Gbit Ethernet свичей (в 2-3 раза), но при этом FC HBA стоят в 2-3 раза дороже тех же 10Gbit Ethernet сетевых карт (Qlogic 2562 40~45т.р. против Intel X520-DA 16~18т.р., в кулоджике, правда, уже трансиверы стоят).
Так что, на мой взгляд, выбирать iSCSI особого смысла нет в настоящее время. Разве что на FCoE поглядеть.
1. Меньше слоев над физикой нагорожено. Соответственно, чтобы упаковать данные в FC требуется меньше действий.
2. Протокол заранее был спроектирован под низкую латентность и сети хранения с 1 слоя и дальше вверх.
iSCSI же был впихнут поверх существующего Ethernet/IP/TCP стека и, соответственно, наследует все его плюсы и минусы (такие как потери пакетов, ретрансмиты и прочие костыли). Большинство этих проблем, кстати, решено в Data Center Ethernet и работающем над ним FCoE (это не замена iSCSI, конечно, т.к. FCoE работает на 3 уровне, но тем не менее)
3. Тот факт, что в большинстве случаев для реализации iSCSI используется софтовый стек, а не железные HBA, тоже вносит свои задержки.
А вот будет ли заметна эта дополнительная латентность в работе конкретного софта — другой вопрос.
С ценами на FC интересное дело — свичи (те же Cisco MDS9148) стоят сильно дешевле 10Gbit Ethernet свичей (в 2-3 раза), но при этом FC HBA стоят в 2-3 раза дороже тех же 10Gbit Ethernet сетевых карт (Qlogic 2562 40~45т.р. против Intel X520-DA 16~18т.р., в кулоджике, правда, уже трансиверы стоят).
Так что, на мой взгляд, выбирать iSCSI особого смысла нет в настоящее время. Разве что на FCoE поглядеть.
Пункты 1-3 на мой взгляд на IOPS ну никак не влияют. Разве что у вас одно приложение на весь ЦОД читает/пишет в один поток и этому приложению надо дождаться данных от одного сискола, что бы сделать второй. Все что Вы описали — это та сама латентность, которая к «сферическому» количеству IOPS относится мало.
Да, какая-нибудь БД из-за латентности в итоге будет работать быстрее (мне тут больше нравится слово «эффективнее»), но я имел ввиду работу самой СХД. Если она выдает 1000 IOPS по iSCSI, то по FC она выдаст те же 1000 IOPS. Ну наверно надо будет IO depth чуть побольше, но это мелочи. К тому же предполагаю что латентность хорошо понизится при использовании SSD кешей на хостах.
Нагуглил ценник на MDS9148 — $12k. Свитч на 48 десяток сейчас стоит такие же деньги (и цена еще будет снижаться, в отличии от FC). Плюс эти десятки много кому нужны помимо СХД. Унификация — великая вещь. То, что iSCSI можно запустить на «софтовом HBA» тоже скорее плюс. Не каждому серверу надо много, но каждому надо.
Так что с моей колокольни пока что FC не у дел.
Да, какая-нибудь БД из-за латентности в итоге будет работать быстрее (мне тут больше нравится слово «эффективнее»), но я имел ввиду работу самой СХД. Если она выдает 1000 IOPS по iSCSI, то по FC она выдаст те же 1000 IOPS. Ну наверно надо будет IO depth чуть побольше, но это мелочи. К тому же предполагаю что латентность хорошо понизится при использовании SSD кешей на хостах.
Нагуглил ценник на MDS9148 — $12k. Свитч на 48 десяток сейчас стоит такие же деньги (и цена еще будет снижаться, в отличии от FC). Плюс эти десятки много кому нужны помимо СХД. Унификация — великая вещь. То, что iSCSI можно запустить на «софтовом HBA» тоже скорее плюс. Не каждому серверу надо много, но каждому надо.
Так что с моей колокольни пока что FC не у дел.
Влияют, но не так, как латентность бэкенда хранилища (дисков, SSD).
Оно, конечно, сферическое до какого-то момента, после которого уже начинает играть роль.
При таком кол-ве иопсов разницы действительно не будет. Когда же счет идет на десятки и сотни тысяч иопсов, то уже разница будет чувствоваться.
Я недавно брал MDS-ы с 16 активными портами за 140т.р. и брал Catalyst-ы 4500-X тоже с 16 портами за 300т.р.
Еще можно рассмотреть нексусы 5к за 550т.р. с 32 портами. Так что где вы нашли 48 десяток за 12 килобаксов я не знаю.
Унификация — это FCoE, который взял лучшее из обоих «миров»: низкую латентность и lossless передачу из FC и возможность работы на стандартном (относительно) оборудовании от iSCSI. Плюс теми же нексусами с универсальными портами можно связывать FCoE и FC сети прозрачно.
А еще мне в FC нравится его простота в эксплуатации, эдакий PnP.
С iSCSI же (особенно на 1Гбит сетях) требуется вагон телодвижений для обеспечения утилизации всех линков в Multipath и тому подобное.
Оно, конечно, сферическое до какого-то момента, после которого уже начинает играть роль.
Если она выдает 1000 IOPS по iSCSI, то по FC она выдаст те же 1000 IOPS
При таком кол-ве иопсов разницы действительно не будет. Когда же счет идет на десятки и сотни тысяч иопсов, то уже разница будет чувствоваться.
Нагуглил ценник на MDS9148 — $12k. Свитч на 48 десяток сейчас стоит такие же деньги (и цена еще будет снижаться, в отличии от FC).
Я недавно брал MDS-ы с 16 активными портами за 140т.р. и брал Catalyst-ы 4500-X тоже с 16 портами за 300т.р.
Еще можно рассмотреть нексусы 5к за 550т.р. с 32 портами. Так что где вы нашли 48 десяток за 12 килобаксов я не знаю.
Плюс эти десятки много кому нужны помимо СХД. Унификация — великая вещь.
Унификация — это FCoE, который взял лучшее из обоих «миров»: низкую латентность и lossless передачу из FC и возможность работы на стандартном (относительно) оборудовании от iSCSI. Плюс теми же нексусами с универсальными портами можно связывать FCoE и FC сети прозрачно.
А еще мне в FC нравится его простота в эксплуатации, эдакий PnP.
С iSCSI же (особенно на 1Гбит сетях) требуется вагон телодвижений для обеспечения утилизации всех линков в Multipath и тому подобное.
Да, кстати сам только столкнулся с ситуацией предлагают iSCSI для Oracle DB.
Никогда не пользовал ничего кроме FC, поясните пожалуйста какие грабли поджидают.
Никогда не пользовал ничего кроме FC, поясните пожалуйста какие грабли поджидают.
А какие железки? Скорости?
При имеющейся FC инфраструктуре — довольно странное предложение.
При имеющейся FC инфраструктуре — довольно странное предложение.
Основные камни — это цена. Говоря про «бесплатный» iSCSI, как правило имеют ввиду встроенные сетевые адаптеры и уже имеющиеся в инфраструктуре коммутаторы. Но это значит 1GE, как правило.
Коммутаторы 10GE стоят не дешевле (когда я смотрел в последний раз, были в 2 раза дороже), чем FC-шные 8G, при сравнимой производительности.
Аппаратные iSCSI HBA — тоже.
При этом от «лишней» отдельной сущности, коей всегда представляют FC-сеть, всё равно не уйти, если конечно есть намерение обеспечивать высокий уровень надёжности и доступности.
В целом же всё зависит от условий, потребностей и удобства. Мне, например, управление IP-сетями кажется более трудозатратным и менее удобным. Но это уже субъективно.
Коммутаторы 10GE стоят не дешевле (когда я смотрел в последний раз, были в 2 раза дороже), чем FC-шные 8G, при сравнимой производительности.
Аппаратные iSCSI HBA — тоже.
При этом от «лишней» отдельной сущности, коей всегда представляют FC-сеть, всё равно не уйти, если конечно есть намерение обеспечивать высокий уровень надёжности и доступности.
В целом же всё зависит от условий, потребностей и удобства. Мне, например, управление IP-сетями кажется более трудозатратным и менее удобным. Но это уже субъективно.
Начал гуглить и первой ссылкой попал на красивый документ, в котором сравниваются 10 Gb iSCSI и 8 Gb FC.
В общем заключение описывает, что 1Gb iSCSI годится для ненагруженных систем,
а 10Gb еще не созрел чтобы заменить FC. И грешат они на оверхид со стороны TCP и пр.
Документ правда 2008 года.
Технические выводы:
В общем заключение описывает, что 1Gb iSCSI годится для ненагруженных систем,
а 10Gb еще не созрел чтобы заменить FC. И грешат они на оверхид со стороны TCP и пр.
Документ правда 2008 года.
Технические выводы:
Key Findings: Third I/O found the efficiency of
8 Gb Fibre Channel to be higher than
10 Gb iSCSI in the following areas:
3.9x greater bandwidth power efficiency
10x greater bandwidth CPU efficiency
3.2x greater database power efficiency
2.8x greater database CPU efficiency
И грешат они на оверхид со стороны TCP и пр.
Документ правда 2008 года.
С тех пор в стеке протоколов TCP/IP, я вас уверяю, ничегошеньки не поменялось, как и за последние 20-30 лет. Да, какие-то хаки TCP добавлялись (вроде window scaling) но принципиально ничего нового.
Более того, даже FCoE тоже страдает такими же болезнями, судя по тестам.
Да вроде как нет, вот один старый тест: www.emulex.com/artifacts/ded15f52-c7e2-4a92-b10f-d7662c919f73/ibm_wp_all_oneconnect_sqlserver.pdf
Там FCoE во всех тестах даже немного впереди FC.
Да и с чего ей страдать теми же болезнями, если FCoE и iSCSI не имеют практически ничего общего?
С другой стороны, встречаются тесты прямо противоположные. Так что я не знаю кому верить :) Я сам FCoE не пробовал, нет свичей с DCB.
Там FCoE во всех тестах даже немного впереди FC.
Да и с чего ей страдать теми же болезнями, если FCoE и iSCSI не имеют практически ничего общего?
С другой стороны, встречаются тесты прямо противоположные. Так что я не знаю кому верить :) Я сам FCoE не пробовал, нет свичей с DCB.
Во внутренних тестах нетапа видел сравнение протоколов FC8 и iSCSI, FCoE, NFS (поверх 10Г). Так вот, все протоколы с правильно настроенными СХД и хостами на тех задачах показывали практически одинаковую производительность. Как по латенси, количеству операций чтения/записи, так и по пропускной способности. Иногда некоторые протоколы были немножко лучше чем FC8, как к примеру dNFS или pNFS. У iSCSI также есть свои ньюансы которые помогают получить "больше", такие как MCS (только для Windows) и количество одновременных сессий. Ну и конечно же Jumbo Frames. По крайней мере так у NetApp. Любая инфраструктура, это комплексное решение и далеко не всегда сеть — узкое место.
1. Знаю, что есть аппаратные анализаторы FC, но вживую их никогда не трогал. Программных средств такого уровня тоже не встречал. Да и потребности не возникало.
2. Может быть есть, я от разработки отошёл уже давно и такими вопросами не интересовался.
3. Если я правильно понял вопрос, то могу сказать, что конечно же любое оборудование между инициатором и таргетом (между приложением и данными на диске) приводит к задержкам доступа. В частности многомодовое волокно даёт latency примерно в 5 нс на метр. Но это имеет значение разве что на больших дистанциях (10 км и более). Большее влияние оказывает оборудование — буферизация, зонинг, контроль. Один коммутатор увеличивает задержку где-то на 200 мкс. Потому EMC и Brocade (остальные не знаю) рекомендуют чтобы между любыми двумя нодами, между которыми предполагается обмен, было не более трёх хопов (ISL).
2. Может быть есть, я от разработки отошёл уже давно и такими вопросами не интересовался.
3. Если я правильно понял вопрос, то могу сказать, что конечно же любое оборудование между инициатором и таргетом (между приложением и данными на диске) приводит к задержкам доступа. В частности многомодовое волокно даёт latency примерно в 5 нс на метр. Но это имеет значение разве что на больших дистанциях (10 км и более). Большее влияние оказывает оборудование — буферизация, зонинг, контроль. Один коммутатор увеличивает задержку где-то на 200 мкс. Потому EMC и Brocade (остальные не знаю) рекомендуют чтобы между любыми двумя нодами, между которыми предполагается обмен, было не более трёх хопов (ISL).
Transceivers, трансиверы или SFP — в случае FC-коммутаторов это отдельные модули, необходимые для подключения кабеля к порту. Различаются на коротковолновые (Short Wave, SW, SX) и длинноволновые (Long Wave, LW, LX). LW-трансиверы совместимы с многомодовым и одномодовым волокном. SW-трансиверы — только с многомодовым. И к тем и к другим кабель подключается разъёмом LC.
Есть ещё SFP xWDM (Wavelenght Division Multiplexing), предназначенные для передачи данных из нескольких источников на дальние расстояния единым световым пучком. Для подключения кабеля к ним используется разъём SC.
чушь. вам цыскин SFP с разъемом LC:
www.cisco.com/c/en/us/products/collateral/interfaces-modules/dwdm-transceiver-modules/product_data_sheet0900aecd80582763.html
разъем не коррелирует с тем, что решение уплотненное или неуплотненное.
UFO just landed and posted this here
Около 80% WDM SFP/SFP+ выпускаются с SC разъёмом
Щито? Да таких нынче днем с огнем не сыщешь. Все — только LC Duplex или Simplex.
Вот у Finisar поди найди хоть один с LC: www.finisar.com/products/optical-modules/sfp-plus
И это логично, ибо в маленький SFP даже один SC коннектор можно впихнуть лишь с трудом, про два я вообще молчу :)
UFO just landed and posted this here
Я вот только что от безделья задался вопросом: насколько полезным занятием было бы улучшение статей в русскоязычной википедии по айтишной терминологии? В первую очередь — всё, что связано с хранением данных. Сравните ту же статью по FC в русской и английской вики — разница в качестве существенная.
С одной стороны — сизифов труд. Все, кому нужны даже просто базовые знания на уровне энциклопедической статьи способны заглянуть в англоязычную вики, за подробностями — в документацию от вендоров, которую всё равно никто переводить не собирается. С другой стороны — это поможет немного добавить знаний в низкоквалифицированный слой под названием «мы в школе немецкий учили», что будет в целом полезно для рынка.
С одной стороны — сизифов труд. Все, кому нужны даже просто базовые знания на уровне энциклопедической статьи способны заглянуть в англоязычную вики, за подробностями — в документацию от вендоров, которую всё равно никто переводить не собирается. С другой стороны — это поможет немного добавить знаний в низкоквалифицированный слой под названием «мы в школе немецкий учили», что будет в целом полезно для рынка.
никто не сталкивался с ограничением в FC-AL в 8 Gb? Было не очень приятным открытием что FC-AL не работает в 16G =(
Sign up to leave a comment.
Основы Fibre Channel