Основы Fibre Channel

    Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

    Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).

    Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.
    Оригинал
    Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.
    IBM Redbook «Introduction to SAN and System Networking»

    Начало


    По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.



    FC-0 — уровень физических интерфейсов и носителей. Описывает физическую среду: кабели, коннекторы, HBA, трансиверы, электрические и оптические параметры.

    FC-1 — уровень передачи и кодирования. Здесь описывается как данные будут кодироваться перед передачей и декодироваться после. На этом уровне определяются три основные функции:

    FC-2 — уровень кадрирования и сигналов. Определяет структуру и организацию передаваемой информации, а также контроль и управление её передачей. Функции, осуществляемые на этом уровне:

    FC-3 — уровень базовых служб. Уровень заложен, для новых функций, которые могут быть внедерены в Fibre Channel в будущем. На этом уровне обеспечивается шифрование и сжатие данных перед отправкой, а также такие вещи как расщепление потока данных (striping) по нескольким путям. Но я не сталкивался с реализациями таких штук пока.

    FC-4 — уровень отображения протоколов. Описывает протоколы, которые могут использовать FC в качестве транспорта и, собственно, порядок использования (маппинг этих протоколов на нижние уровни FC0-3). Применительно к SAN это могут быть:
    • Fibre Channel Protocol for SCSI-3 (SCSI-FCP) — проброс SCSI
    • Fibre Channel Link Encapsulation (FC-LE) — проброс TCP/IP


    А теперь подробнее об этих и других непонятных словосочетаниях. В данной статье рассмотрим только нижние три уровня, как наиболее значимые при создании и управлении инфраструктурой FC SAN.

    FC-0


    Я, пожалуй не буду приводить сложных таблиц разновидностей кабелей, передатчиков и их характеристик. Во-первых, потому что неудобно тут вставлять таблицы, во-вторых, потому что эти таблицы есть везде, где хоть что-то написано про FC (русская википедия, нерусская википедия), в-третьих (и ключевое), — на мой взгляд, главное понять суть, а справочные данные найти не проблема.
    А суть в том, что есть два типа волокна: многомодовое и одномодовое.
    Многомодовое (Multimode Fiber, MMF) — относительно широкое в сечении (50-62,5 микрон), предназначенное для коротковолновых лазерных лучей. «Многомодовое» значит, что свет по каналу может проходить разными путями — множественно отражаясь от стенок волокна. Это делает кабель менее чувствительным к перегибу, но снижает силу и качество сигнала, что ограничивает данный тип только небольшими дистанциями — до 500 м.
    Одномодовое (Singlemode Fiber, SMF) — волокно малого диаметра (8-10 микрон), сигнал по которому передаётся длинноволновым лазером, свет которого не виден человеческому глазу. Тут свет может перемещаться единственным путём — по прямой, соответственно сигнал передаётся быстрее и точнее, но оборудование для обеспечения такого рода сигналов стоит значительно дороже, так что используется, в основном, для связи на больших расстояниях (до 50 км). К перегибам и вообще любым искривлениям одномодовое волокно куда чувствительнее.
    Тут рядом есть более подробная статья про типы волокна.
    Стоит иметь ввиду, что для соединения двух устройств используется два кабеля. Один используется для передачи, другой для приёма. Потому важно подключить их корректно (Tx одной стороны к Rx другой).

    Отдельно хочу упомянуть про такой термин как тёмная оптика (dark fiber). Сей термин не значит, что она как-то специальным образом тонирована. Это просто выделенные оптические линии связи, как правило, для связи на больших расстояниях (между городами или далеко отстоящими зданиями), которые берутся в аренду, и для использования которых не требуется дополнительное оборудования усиления сигнала (его обеспечивает владелец). Однако, так как это просто оптический кабель, отданный в ваше полновластное распоряжение, до тех пор пока вы не пустите по нему свой световой сигнал, он остаётся «тёмным».

    Плавный переход от FC-0 к FC-1 и обратно обеспечивает ASIC — элемент таких устройств как HBA, дисковых массивов и коммутаторов.
    Из Википедии:
    ASIC (аббревиатура от англ. application-specific integrated circuit, «интегральная схема специального назначения») — интегральная схема, специализированная для решения конкретной задачи. В отличие от интегральных схем общего назначения, специализированные интегральные схемы применяются в конкретном устройстве и выполняют строго ограниченные функции, характерные только для данного устройства; вследствие этого выполнение функций происходит быстрее и, в конечном счёте, дешевле. Примером ASIC может являться микросхема, разработанная исключительно для управления мобильным телефоном, микросхемы аппаратного кодирования/декодирования аудио- и видео-сигналов (сигнальные процессоры).

    В оборудовании Fibre Channel ASIC состоит из следующих функциональных элементов:
    • Encoder / Decoder — обеспечивает кодирование каждых 8 бит передаваемых данных в 10-битное представление. И декодирование обратно принимаемых данных.
    • SERDES (Serializer / Deserializer) — преобразует параллельный поток 10-битных порций данных в последовательный поток 10-битных порций данных.
    • Transceiver — преобразует электрические импульсы в световые сигналы.

    ASIC


    Transceivers, трансиверы или SFP — в случае FC-коммутаторов это отдельные модули, необходимые для подключения кабеля к порту. Различаются на коротковолновые (Short Wave, SW, SX) и длинноволновые (Long Wave, LW, LX). LW-трансиверы совместимы с многомодовым и одномодовым волокном. SW-трансиверы — только с многомодовым. И к тем и к другим кабель подключается разъёмом LC.
    Есть ещё SFP xWDM (Wavelenght Division Multiplexing), предназначенные для передачи данных из нескольких источников на дальние расстояния единым световым пучком. Для подключения кабеля к ним используется разъём SC.

    FC-1


    8/10 и 64/66

    Первое, что происходит на этом уровне — кодирование / декодирование информации. Это довольно мудрёный процесс, в ходе которого каждые 8 бит поступающей информации преобразуются в 10-битное представление. Делается это с целью повышения контроля целостности данных, отделения данных от служебных сигналов и возможности восстановления тактового сигнала из потока данных (сохранение баланса нулей и единиц).
    Это ведёт к заметному снижению полезной пропускной способности, ибо как можно подсчитать, 20% потока данных является избыточной служебной информацией. А ведь кроме всего прочего, немалую часть этого потока может занимать служебный трафик.
    Однако хорошая новость в том, что кодирование 8/10 используется в оборудовании 1G, 2G, 4G и 8G. В части реализаций 10G и начиная с 16G кодирование осуществляется по принципу 64/66, что существенно увеличивает полезную нагрузку (до 97% против 80% в случае 8/10).

    Ordered sets

    В русской википедии этот термин переведён как "упорядоченные наборы". В то время как на мой взгляд, слово order тут стоит понимать не в значении «порядок», а в значении «приказ, команда».
    Для начала стоит упомянуть ещё один термин, используемый в контексте FC — transmission word — минимальная порция данных для передачи, равная 4 байтам. Если передаваемая информация меньше по объёму, то transmission word дополняется специальными заполняющими байтами (fill bytes), которые вырезаются на приёмнике.
    Так вот, ordered sets — это специальные служебные transmission words. Делятся на три категории:
    1. Разделители фреймов (Start-of-Frame, SOF и End-of-Frame, EOF).
    2. Два базовых сигнала — IDLE (порт готов принимать или передавать данные) и R_RDY (receiver ready — порт освободил буфер для приёма очередной порции данных)
    3. Базовые последовательности (primitive sequences):
      • NOS (Not Operational) — порт обнаружил разрыв / отсутствие соединения
      • OLS (Offline State) — порт инициирует установление соединения, или порт получил NOS, или порт переходит в состояние off-line
      • LR (Link Reset) — инициализация сброса соединения. Отправляется в случае получения OLS или каких-то ошибок приёма-передачи (как правило, на уровне Flow Control). Отправивший порт очищает свои буферы и их счётчики
      • LRR (Link Reset Response) — ответ на LR. Отправивший порт очищает свои буферы и их счётчики


    Инициализация соединения (Link initialization)

    При установлении физического соединения между портами A и B, между ними происходит следующий «обмен веществ»:


    FC-2


    Фреймы (Кадры, Frames)

    Все данные, передаваемые в среде Fiber Channel разбиваются на фреймы (кадры). Структура фрейма следующая:
    • SoF — 4 байта (1 tw) — идентификатор начала фрейма.
    • Header — 24 байта (6 tw) — заголовок. Содержит такую информацию как адрес источника и приёмника, тип фрейма (FT-0 — управляющий или FT-1 — данные), номер последовательности и порядковый номер фрейма в ней и прочая служебно-контрольная информация.
    • Data — 0-2112 байт (0-528 tw) — непосредственно данные (например, SCSI-команды).
    • CRC — 4 байта (1 tw) — контрольная сумма.
    • EoF — 4 байта (1 tw) — идентификатор конца фрейма.


    Промежутки между фреймами заполняются специальными «заполняющими словами» — fill word. Как правило, это IDLE, хотя начиная с FC 8G было стандартизовано использование ARB(FF) вместо IDLE, в целях снижения электрических помех в медном оборудовании (но по-умолчанию коммутаторами используется IDLE).

    Последовательности (Sequences)

    Чаще всего источник стремится передать приёмнику гораздо больше информации, чем 2112 байт (максимальный объём данных одного фрейма). В этом случае информация разбивается на несколько фреймов, а набор этих фреймов называется последовательностью (sequence). Чтобы в логическую последовательность фреймов не вклинилось что-то лишнее при параллельной передаче, заголовок каждого фрейма имеет поля SEQ_ID (идентификатор последовательности) и SEQ_CNT (номер фрейма в последовательности).

    Обмен (Exchange)

    Одна или несколько последовательностей, отвечающих за какую-то одиночную операцию, называется обменом. Источник и приёмник могут иметь несколько параллельных обменов, но каждый обмен в единицу времени может содержать только одну последовательность. Пример обмена: инициатор запрашивает данные (последовательность 1), таргет возвращает данные инициатору (последовательность 2) и затем сообщает статус (последовательность 3). В этот набор последовательностей не может вклиниться какой-то посторонний набор фреймов.
    Для контроля этого процесса заголовок каждого фрейма включает поля OX_ID (Originator Exchange ID — заполняется инициатором обмена) и RX_ID (Responder Exchange ID — заполняется получателем в ответных фреймах, путём копирования значения OX_ID).

    Классы обслуживания (Classes of Services)

    Различные приложения предъявляют разные требования к уровню сервиса, гарантии доставки, продолжительности соединения и пропускной способности. Некоторым приложениям требуется гарантированная пропускная способность в течение их работы (бэкап). Другие имеют переменную активность и не требуют постоянной гарантированной пропускной способности канала, но им нужно подтверждение в получении каждого отправленного пакета. Для удовлетворения таких потребностей и обеспечения гибкости, FC определяет следующие 6 классов обслуживания.

    Class 1

    Для этого класса устанавливается выделенное соединение, которое резервирует максимальную полосу пропускания между двумя устройствами. Требует подтверждения о получении. Требует чтобы фреймы попадали на приёмник в том же порядке, что вышли из источника. Ввиду того, что не даёт другим устройствам использовать среду передачи, используется крайне редко.

    Class 2

    Без постоянного соединения, но с подтверждением доставки. Не требует соответствия порядка отправленных и доставленных фреймов, так что они могут проходить через фабрику разными путями. Менее требователен к ресурсам, чем класс 1, но подтверждение доставки приводит к повышенной утилизации пропускной способности.

    Class 3

    Без постоянного соединения и без подтверждения доставки. Самый оптимальный с точки зрения использования ресурсов фабрики, но предполагает, что протоколы верхних уровней смогут собрать фреймы в нужном порядке и перезапросить передачу пропавших фреймов. Наиболее часто используемый.

    Class 4

    Требует постоянного соединения, подтверждение и порядок фреймов как и класс 1. Главное отличие — он резервирует не всю полосу пропускания, а только её часть. Это гарантирует определённое QoS. Подходит для мультимедиа и Enterprise-приложений, требующих гарантированного качества соединения.

    Class 5

    Ещё до конца не описан и не включен в стандарт. Предварительно, класс, не требующий соединения, но требующий немедленной доставки данных по мере их появления, без буферизации на устройствах.

    Class 6

    Вариант класса 1, но мультикастовый. То есть от одного порта к нескольким источникам.

    Class F

    Класс F определён в стандарте FC-SW для использования в межкоммутаторных соединениях (Interswitch Link, ISL). Это сервис без постоянного соединения с уведомлениями о сбое доставки, использующийся для контроля, управления и конфигурирования фабрики. Принцип похож на класс 2, но тот используется для взаимодейтсвия между N-портами (порты нод), а класс F — для общения E-портов (межкоммутаторных).

    Flow Control

    В целях предотвращения ситуации, когда отправитель перегрузит получателя избыточным количеством фреймов так, что они начнут отбрасываться получателем, FC использует механизмы управления потоком передаваемых данных (Flow Control). Их два — Buffer-to-Buffer flow control и End-to-End flow control. Их использование регламентируется классом обслуживания. Например, класс 1 использует только механизм End-to-End, класс 3 — Buffer-to-Buffer, а класс 2 — оба эти механизма.

    Buffer-to-Buffer flow control

    Принцип технологии — кредит в каждый дом отправка любого фрейма должна быть обеспечена наличием кредита на отправку.
    Все поступающие на вход порта фреймы помещаются в специальную очередь — буферы. Количество этих буферов определяется физическими характеристиками порта. Один буфер (место в очереди) соответствует одному кредиту. Каждый порт имеет два счётчика кредитов:
    TX BB_Credit — счётчик кредитов передачи. После отправки каждого фрейма, уменьшается на 1. Если значение счётчика стало равным нулю — передача невозможна. Как только от порта-приёмника получено R_RDY, счётчик увеличивается на 1.
    RX BB_Credit — счётчик кредитов приёма. Как только фрейм принят и помещён в буфер, уменьшается на 1. Когда фрейм обрабатывается или пересылается дальше, счётчик увеличивается на 1, а отправителю отправляется R_RDY. Если значение счётчика падает до 0, то в принципе, приём новых фреймов должен быть прекращён. На практике, из-за ошибок синхронизации кредитов может возникнуть ситуация, что источник прислал ещё один-несколько фреймов уже после того как RX BB_credit стал равен нулю. Данная ситуация называется buffer overflow. В большинстве реализаций порт обрабатывает такие ситуации «по-доброму» — за счёт резервных буферов. Хотя некоторое оборудование в таких случаях может сынициировать Link Reset.

    Отсюда исходит сильное влияние расстояния между портами на производительность. Чем выше расстояние и больше пропускная способность, тем больше фреймов будет отправлено (читай кредитов передачи потрачено) ещё до того как получатель получит хотя бы первый. Ситуацию облегчает особенность архитектуры FC-коммутаторов. Дело в том, что количество буферов не закреплено жёстко за каждым портом (кроме восьми обязательных), а является общим для всех. И в случае определения «дальних линков» (автоматически или вручную) количество выделяемых коммутатором буферов для этого порта увеличивается. Другой плюс общей памяти — не требуется гонять буферы от одного порта к другому внутри коммутатора.

    End-to-End flow control

    Реализуется счётчиком EE_Credit, который определяет максимум фреймов, которые источник может отправить приёмнику без получения подтверждения (Acknowledge, ACK). В отличие от BB_Credit распространяется только на фреймы с данными, а обмен/учёт происходит между конечными нодами.

    Конец


    Изначально мне казалось, что статья будет раза в два меньше, но в ходе написания всплыло много деталей, без которых счастье казалось не полным. Ещё кучу вещей, которые хотелось бы осветить, пришлось пока отбросить — процесс написания грозил стать бесконечным. Если у кого-то возникнут замечания, предложения и пожелания к тому, про что ещё стоит написать, буду признателен. И спасибо всем, кто дочитал до этого места.

    Были использованы материалы из следующих источников:
    IBM Redbook «Introduction to SAN and System Networking»
    EMC «Network Storage Concepts and Protocols»
    Brocade «SAN Fabric Administration Best Practices Guide»
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 46

      +2
      Очень здорово и легко читать. Спасибо.
      Каковы по вашему мнению перспективы на будущее у данного стандарта? Есть ли что противопоставить IB, который всё больше и больше входит в обиход?
      У меня есть 3 железки связанные по FC 8 между собой, бекапы делаю с фермы виртуалок и раздаю по iscsi дальше ресурсы. Но на достаточно большой части серверов есть IB интерфейсы, но свитчи кусаются по стоимости. Вот думаю, ждать доступного IB, или купить уже доступные FC карточки и связать таким образом все хранилища.
        0
        К сожалению, ничего не могу сказать про IB, и насколько он уже «всё больше и больше». Ни разу не довелось с ним на практике столкнуться.
        Про вытеснение FC медью и iSCSI/NAS слышал ещё три или четыре года назад, что уже вот-вот. Но сколь-нибудь значительного изменения ситуации с тех пор не увидел.
        Однако что-то советовать не возьмусь, поскольку работаю не у вендора/дистрибьютера/интегратора, а у заказчика и статистики уже пару лет не видел. А пару лет назад IB был слишком специфичен и дорог, чтобы вообще его рассматривать как вариант (если это не обусловлено специальными потребностями).
        Сам бы я по понятным причинам выбрал FC :) Или iSCSI. Или NAS (Netapp), в зависимости от начальных условий и потребностей.
          0
          Продажи оборудования FC продолжают расти, так что пока будущее есть, на плато ещё не вышли. Противопоставить IB можно наличие систем хранения данных у большинства вендоров. Системы хранения данных на IB — довольно большая редкость, нишевый рынок. Блочных систем для IB практически нет.
            +1
            В NetApp E-Series есть карточка IB.
              0
              И для чего она там используется?
                0
                Для подключения хостов в High Performance Computing. Или о чём вы, могли быть варианты?
                  0
                  В HPC обычно используется файловый доступ. То есть, во-первых, HPC — редкость, во-вторых, блочного доступа на Инфинибенде всего несколько систем в мире. Это я всё к тезису о том, что рынок FC с рынком IB практически не пересекаются и заменить друг друга не могут (ну, да, могут, только рынок это не принял).
                    0
                    Так минутку, редкость это СХД с IB или HPC?
                    Мой тезис был относительно «Системы хранения данных на IB — довольно большая редкость».
                      –1
                      HPC редкость, а СХД на IB к ним — ещё большая редкость :).
          0
          Спасибо за статью.
          Имеется вопросы:
          1. Есть ли технические средства (аппаратные или программные), которые позволяют захватить-разобрать FC обмен?
          2. Может быть есть какие нибудь модели взаимодействия на языках высокого уровня?
          3. Какая изменяется скорость доступа ( IOPS ) к дискам при FC?
            0
            1. Есть. Но в основном они не доступны для конечных пользователей и по причине заоблачной стоимости не имеют практического смысла (в обычных условиях). Всякие АНБ такие средства имеют, но это довольно специфичные комплексы.
            2. Зачем? Ну и непонятно что там можно делать на языке высокого уровня.
            3. Немного не понял вопрос. Но если о пропускной способности, то 1 FC шнурок может теоретически пропустить около миллиона IOPS.
              0
              FC шнурок может теоретически пропустить около миллиона IOPS

              Что-то я очень сомневаюсь.

              Мне не удавалось получить больше 100к IOPS (блоками по 512) при тестировании 8Gb FC с NULL бэкендом.
              Гонял как через прямой линк (хост-хост), так и через свич.
              В качестве таргета Linux + SCST, железяки Qlogic 2562.

              Миллион IOPS — это, скорее, для Infiniband задача выполнимая.
                +1
                По крайней мере такие цифры присутствуют в некоторых документах.
                Например:

                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»

                  0
                  Ага, интересно, спасибо! Значит, ограничение в самом HBA, а не в фабрике.
              0
              По третьему вопросу: скорость доступа к дискам в IOPS от среды передачи не зависит.
                0
                тогда какой смысл тратить много денег на FC при существоании практически бесплатного iSCSI?
                  0
                  latency?

                  Ну и можно уточнить что считать средой передачи.
                  От конкретного одного шнурка зависит не так уж много — альтернативы есть. А вот с инфраструктурой в целом все несколько сложнее.
                    0
                    Ну допустим у вас есть 2 одинаковых системы, одна на FC, вторая на iSCSI. Сколько разницы этой latency вы получите?
                      +1
                      Две одинаковых сферических системы в вакууме и стоить будут примерно одинаково.

                      Бесплатный iSCSI — это 1G и он реально сильно проигрывает FC (что не удивительно).
                      iSCSI 10G это уже не такое уж дешевое решение вполне сравнимое по ценам с FC при сравнимой производительности.

                      У меня в наличии есть IBM V3700 с FC 8G и штатным iSCSI если Вам сильно интересно могу бенчмарк какой-нибудь запустить. 10G эзернета у меня к сожалению нет, так что по нему я вам данных не дам.
                    +2
                    «Почти бесплатный» iSCSI имеет место, если нет высокоактивных, в части потребления дисковых ресурсов, сервисов. То есть для небольшого количества виртуалок, файловых серверов и архивных хранилищ. В противном случае быстро выясняется, что инфраструктура iSCSI обходится дороже FC.
                      0
                      Что значит «высокоактивный»? FC при прочих равных выдает больше IOPS, чем iSCSI?
                      • UFO just landed and posted this here
                          0
                          Input/Output Operations Per Second.
                          0
                          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
                            Пункты 1-3 на мой взгляд на IOPS ну никак не влияют. Разве что у вас одно приложение на весь ЦОД читает/пишет в один поток и этому приложению надо дождаться данных от одного сискола, что бы сделать второй. Все что Вы описали — это та сама латентность, которая к «сферическому» количеству IOPS относится мало.
                            Да, какая-нибудь БД из-за латентности в итоге будет работать быстрее (мне тут больше нравится слово «эффективнее»), но я имел ввиду работу самой СХД. Если она выдает 1000 IOPS по iSCSI, то по FC она выдаст те же 1000 IOPS. Ну наверно надо будет IO depth чуть побольше, но это мелочи. К тому же предполагаю что латентность хорошо понизится при использовании SSD кешей на хостах.
                            Нагуглил ценник на MDS9148 — $12k. Свитч на 48 десяток сейчас стоит такие же деньги (и цена еще будет снижаться, в отличии от FC). Плюс эти десятки много кому нужны помимо СХД. Унификация — великая вещь. То, что iSCSI можно запустить на «софтовом HBA» тоже скорее плюс. Не каждому серверу надо много, но каждому надо.
                            Так что с моей колокольни пока что FC не у дел.
                              +1
                              Влияют, но не так, как латентность бэкенда хранилища (дисков, SSD).
                              Оно, конечно, сферическое до какого-то момента, после которого уже начинает играть роль.

                              Если она выдает 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 и тому подобное.
                          0
                          Да, кстати сам только столкнулся с ситуацией предлагают iSCSI для Oracle DB.
                          Никогда не пользовал ничего кроме FC, поясните пожалуйста какие грабли поджидают.
                            0
                            А какие железки? Скорости?
                            При имеющейся FC инфраструктуре — довольно странное предложение.
                              0
                              Деталей не знаю пока.
                              FC был на всех прошлых работах.

                              Здесь все на iSCSI как говорят.
                              +1
                              Основные камни — это цена. Говоря про «бесплатный» iSCSI, как правило имеют ввиду встроенные сетевые адаптеры и уже имеющиеся в инфраструктуре коммутаторы. Но это значит 1GE, как правило.
                              Коммутаторы 10GE стоят не дешевле (когда я смотрел в последний раз, были в 2 раза дороже), чем FC-шные 8G, при сравнимой производительности.
                              Аппаратные iSCSI HBA — тоже.
                              При этом от «лишней» отдельной сущности, коей всегда представляют FC-сеть, всё равно не уйти, если конечно есть намерение обеспечивать высокий уровень надёжности и доступности.
                              В целом же всё зависит от условий, потребностей и удобства. Мне, например, управление IP-сетями кажется более трудозатратным и менее удобным. Но это уже субъективно.
                                –1
                                Начал гуглить и первой ссылкой попал на красивый документ, в котором сравниваются 10 Gb iSCSI и 8 Gb FC.

                                В общем заключение описывает, что 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


                                  0
                                  И грешат они на оверхид со стороны TCP и пр.
                                  Документ правда 2008 года.

                                  С тех пор в стеке протоколов TCP/IP, я вас уверяю, ничегошеньки не поменялось, как и за последние 20-30 лет. Да, какие-то хаки TCP добавлялись (вроде window scaling) но принципиально ничего нового.
                                    0
                                    Более того, даже FCoE тоже страдает такими же болезнями, судя по тестам.
                                      +1
                                      Да вроде как нет, вот один старый тест: www.emulex.com/artifacts/ded15f52-c7e2-4a92-b10f-d7662c919f73/ibm_wp_all_oneconnect_sqlserver.pdf
                                      Там FCoE во всех тестах даже немного впереди FC.

                                      Да и с чего ей страдать теми же болезнями, если FCoE и iSCSI не имеют практически ничего общего?

                                      С другой стороны, встречаются тесты прямо противоположные. Так что я не знаю кому верить :) Я сам FCoE не пробовал, нет свичей с DCB.
                                        +1
                                        Во внутренних тестах нетапа видел сравнение протоколов FC8 и iSCSI, FCoE, NFS (поверх 10Г). Так вот, все протоколы с правильно настроенными СХД и хостами на тех задачах показывали практически одинаковую производительность. Как по латенси, количеству операций чтения/записи, так и по пропускной способности. Иногда некоторые протоколы были немножко лучше чем FC8, как к примеру dNFS или pNFS. У iSCSI также есть свои ньюансы которые помогают получить "больше", такие как MCS (только для Windows) и количество одновременных сессий. Ну и конечно же Jumbo Frames. По крайней мере так у NetApp. Любая инфраструктура, это комплексное решение и далеко не всегда сеть — узкое место.
                        0
                        1. Знаю, что есть аппаратные анализаторы FC, но вживую их никогда не трогал. Программных средств такого уровня тоже не встречал. Да и потребности не возникало.
                        2. Может быть есть, я от разработки отошёл уже давно и такими вопросами не интересовался.
                        3. Если я правильно понял вопрос, то могу сказать, что конечно же любое оборудование между инициатором и таргетом (между приложением и данными на диске) приводит к задержкам доступа. В частности многомодовое волокно даёт latency примерно в 5 нс на метр. Но это имеет значение разве что на больших дистанциях (10 км и более). Большее влияние оказывает оборудование — буферизация, зонинг, контроль. Один коммутатор увеличивает задержку где-то на 200 мкс. Потому EMC и Brocade (остальные не знаю) рекомендуют чтобы между любыми двумя нодами, между которыми предполагается обмен, было не более трёх хопов (ISL).
                        0
                        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
                            0
                            Около 80% WDM SFP/SFP+ выпускаются с SC разъёмом

                            Щито? Да таких нынче днем с огнем не сыщешь. Все — только LC Duplex или Simplex.

                            Вот у Finisar поди найди хоть один с LC: www.finisar.com/products/optical-modules/sfp-plus

                            И это логично, ибо в маленький SFP даже один SC коннектор можно впихнуть лишь с трудом, про два я вообще молчу :)
                              0
                              поди найди хоть один с LC

                              LC SC
                              • UFO just landed and posted this here
                                  0
                                  Объясните мне как можно в SFP(+) впихнуть SC? И каким боком волновое разделение относится к типу коннектора?
                                    0
                                    Отвечу сам себе — действительно, впихивали, но это только одно волокно, старые модули на 100Мбит. Выглядит внушительно :)

                                    Да, я еще три года назад брал модули WDM одноглазые, тогда уже все они были LC. Похоже только Opticin упорно делало монстров с SC.
                        • UFO just landed and posted this here
                            0
                            Я вот только что от безделья задался вопросом: насколько полезным занятием было бы улучшение статей в русскоязычной википедии по айтишной терминологии? В первую очередь — всё, что связано с хранением данных. Сравните ту же статью по FC в русской и английской вики — разница в качестве существенная.
                            С одной стороны — сизифов труд. Все, кому нужны даже просто базовые знания на уровне энциклопедической статьи способны заглянуть в англоязычную вики, за подробностями — в документацию от вендоров, которую всё равно никто переводить не собирается. С другой стороны — это поможет немного добавить знаний в низкоквалифицированный слой под названием «мы в школе немецкий учили», что будет в целом полезно для рынка.
                              0
                              никто не сталкивался с ограничением в FC-AL в 8 Gb? Было не очень приятным открытием что FC-AL не работает в 16G =(

                              Only users with full accounts can post comments. Log in, please.