Let's Mortal Combat begin!
Врубаем на фоне https://music.yandex.ru/album/6122697/track/45591444 и погнали!
Истоки
FibreChannel - начало 1988. Изначально проектировался для удаленного обращения к дисковым устройствам через передачу по сети SCSI блоков.
iSCSI - начало 1998. Подстраивание широко-распространенного уже на тот момент сетевого IP-протокола для передачи по сети SCSI блоков.
Структура кадров
Из 2148 байт максимального размера фрейма FibreChannel - 2112 байт полезной информации - 98,3% полезной нагрузки в пропускной способности сети
В стандартном(!) IP-пакете максимальный размер 1500 байт + 20 байт Ethernet фрейма на 1460 байт полезной нагрузки. Итого 96% полезной нагрузки в пропускной способности сети. При этом для передачи одного и того же объема SCSI информации потребуется на 44,7% больше пакетов (2112 байт vs 1460 байт).
Итого, очень грубо, сложив яблоки и помидоры, получаем примерную разность в эффективности протоколов FC и iSCSI в 47% при стандартном(!) размере ip-пакета. Если не учитывать повторные отправки пакетов при потерях, об этом далее.
Но в IP-протоколе есть механизм для решения этого вопроса - jumbo frame. Который позволяет увеличить длину пакету до 9000+ байт.
Вот и 1й подводный камень - для эффективной работы iSCSI необходимо настраивать Jumbo frame на всех сетевых устройствах на пути доступа от сервера до хранилища.
Задержки
Ваши приложения уверены, что работают с локальным диском, поэтому ожидают быстрого времени отклика. Комфортно для приложений - не более 10 мс, для транзакционных типа СУБД - не более 5 мс. SAN-сеть должна это обеспечить.
Обычно для iSCSI используют существующие пользовательские локальные сети, которые подвержены всплескам трафика, и в этом случае iSCSI трафик будет конкурировать с обычным трафиком. Только задержки и потерю iSCSI трафика сразу почувствуют ваши приложения!
И это 2й подводный камень - для решения этой проблемы нужно дополнительно использовать несколько механизмов IP-протокола: VLAN и QoS.
Собственно ниже пример от Intel, как это делается на конвергентных адаптерах для FCoE, но смысл тот же, что и для iSCSI - без изоляции и приоритизации трафика на всём пути следования вы не можете гарантировать стабильную работу SAN-сети.
Или же есть второй путь - построение выделенной физически SAN-сети на отдельных Ethernet-коммутаторах, достаточной производительности.
И вот появляется 3й подводный камень - для адекватной работы приложений с хранилищем через iSCSI необходима пропускная способность от сервера до хранилища не менее 10Гбит/с. Расчёты приводить уже не буду под это дело. Но попытки натянуть iSCSI на 1Гбит встречаю регулярно.
Собственно FibreChannel лишён конструктивно этих недостатков. Здесь только SCSI трафик, ему не с кем конкурировать, только с самим собой. Ну это надо учитывать при планировании больших инфраструктур.
Доставки пакетов
IP-протокол допускает потерю пакетов (lossy-протокол) и имеет механизм повторной отправки.
FibreChannel не допускает потерю пакетов в принципе (lossless-протокол).
Он использует встроенные в протокол механизмы проверки всего пути следования трафика, определения оптимальной пропускной способности и торможения трафика на отправителе при необходимости для избегания случаев переполнения буферов на портах и отбрасывания пакетов. Возможно вы этого не знали.
Что ещё умеет FibreChannel и вы, возможно, про это не знали
Каждый коммутатор FibreChannel из коробки является фабрикой.
Это значит, что у него внутри уже реализованы такие сервисы как:
- Fabric Login Server (аналог в IP - dhcp-сервер)
- Name Server (аналог в IP - dns-сервер)
- Fabric Controller (аналог в IP - контроллер домена)
То есть просто включив несколько адаптеров в сеть вы уже получаете их связность между собой, независимо от дополнительных сервисов. Дальше можно работать с ограничением видимости по зонам, транками и прочее.
Человеческий фактор
В некоторых случаях это был чуть ли не решающий фактор при выборе решения.
У меня есть заказчики, где SAN-сеть на FibreChannel работает как швейцарские часы уже лет 10. И никакие настройки и кризисы локальных сетей, никакие сменяющиеся по 4му разу админы не могут её уронить :)
Настраивать и поддерживать iSCSI-сеть (не инициаторы и таргеты) для рядового админа, на мой взгляд - сложнее и более трудоёмко. Где-то не проявишь бдительность и аккуратность - будешь ловить дисковые проблемы.
И это, на мой взгляд, 4й подводный камень.
И что теперь, только FC?
Есть возможность строить и развивать FC - лучше строить и развивать FC, те же 32Гбит/с. Но сейчас объективно нет прямых поставок FC-коммутаторов от производителей и, соответственно, полноценной поддержки. Используются альтернативные каналы, что добавляет к стоимости.
Ethernet стал очень хорош. Доступны 25/40 и 100Гбит/с, большой выбор производителей коммутаторов и плат, более доступен по цене. И все слабые места в целом перекрываются сверху повышенной пропускной способностью и учитыванием подводных камней. Главное, как и всегда, грамотно подойти к планированию ваших сетей, как локальных, так и SAN.
С уважением, КС.
Подписывайтесь, чтобы ничего не пропустить.