Настройка fiber channel linux

Обновлено: 01.07.2024

Есть СХД HP StoragWorks MSA 2312fc которая через FC подключена в плату Emulex A8003A, ОС - CentOS последняя при включении сервера на этапе загрузки Emulex он поднимает соединение, пишет что все ок. далее грузится сама система - лампочки уже моргают, как будто соединения нет. хотя вроде как статус онлайн:

не понимаю, что дальше делать. как ЭТО дальше разбить на разделы и прочее? lsscsi не видит это устройство

на схд средствами администрирования нужно разрешить маки карт fibre channel для взаимодействия в полкой и доступа к томам, пока у Вас похоже всего лишь линк активен. после успешной настройки lsblk Вам покажет внешние тома

обычно софт для настройки берется с сайта производителя СХД, я своими рулил через ethernet, детектятся автоматически. Маки тоже видно средствами железки, просто добавляешь в правила доступа в гуе. Объединение дисков, типы разделов - все это в софте.

не нашел такой функции. есть Maps, где указывается, с каких интерфейсов можно коннектится. все меню уже облазил, не нашел где маки указать у меня сам массив еще в статусе Current Job Initialize (92%) из за этого может быть такое? Но при этом Health: OK

это не в Hosts случаем в GUI железки? добавил туда, ничего не изменилось вроде бы

при включении сервера на этапе загрузки Emulex он поднимает соединение, пишет что все ок. далее грузится сама система - лампочки уже моргают, как будто соединения нет. хотя вроде как статус онлайн:

не понимаю, что дальше делать. как ЭТО дальше разбить на разделы и прочее?

Найди того, кто в этом разбирается

Если msa нужно настроить тебе, то делается это не через HBA, а через веб-морду или ( сложнее ) ssh/telnet

Создаёшь raid, на нём нарезаешь lun'ы, потом lun'ы презентуешь хосту ( WWN'ам )

Если кроме самого MSA у тебя полноценная СХД ( сеть ) со свичами, ещё нужно настроить зонинг

они без кабеля, например, просто все равномерно моргают раз в секунду. когда сервер грузится и все подключено нормально, то на этаже загрузки платы FC на СХД загорается постоянно лампочка 4Gb и на сервере зеленая горит, а желтая равномерно мигает. далее, грузится ОК, и на СХД лампочка 4Gb перестает гореть и начинает моргать 2Gb (в общем, так же, как и соседнего порта FC - как будто связи нет). но при этом в системе по этому порту пишет Online, а в морде СХД по этому порту пишет оффлайн

Если msa нужно настроить тебе, то делается это не через HBA, а через веб-морду или ( сложнее ) ssh/telnet
Создаёшь raid, на нём нарезаешь lun'ы, потом lun'ы презентуешь хосту ( WWN'ам )

это я по идее сделал - разбил, создал

Если кроме самого MSA у тебя полноценная СХД ( сеть ) со свичами, ещё нужно настроить зонинг

не, мне надо самый примитив точка-точка, эту СХД будет использовать только 1 сервер

Найди того, кто в этом разбирается

готов заплатить, если тут такой есть:) по знакомым поспрашивал, никто не сталкивался

а в морде СХД по этому порту пишет оффлайн

Проверь настройку порта. Он может оказаться в loop вместо p2p

На стороне centos тебе ничего трогать не нужно. Если ты корректно выдал диски, после рескана они должны быть видны

В FC 2/4 Gbit и 8/16 Gbit не совместимы. ЕМНИП, разное кодирование сигнала

Может быть битый кабель или полудохлый SFP

это я по идее сделал - разбил, создал

router ★★★★★ ( 07.12.17 21:03:52 )
Последнее исправление: router 07.12.17 21:04:32 (всего исправлений: 2)

В Hosts нужно добавлять wwpn

lun'ы должны быть презентованы ( Provisioning -> Explicit Mapping ). LUN для начала выбери в диапазоне 0..255

Кстати, при маппинге нужно ещё и порты msa указать

После этого выполняешь рескан на хосте. Если ошибки нет, диски будут видны

Если ничего не получается, приводи скрины с маппингами lun'а, wwn'ами хоста, и настройками портов

router ★★★★★ ( 07.12.17 21:13:18 )
Последнее исправление: router 07.12.17 21:15:53 (всего исправлений: 1)

В FC 2/4 Gbit и 8/16 Gbit не совместимы. ЕМНИП, разное кодирование сигнала

Забыл уже. Это 1 и 8 несовместимы. Плюс в 10 и выше другое кодирование

Спасибо, буду пробовать. Если на самом схд все нормально настроить то в системе я должен сразу увидеть диски в lsscsi? Или какие то действия ещё нужны?

echo 1 > /sys/class/fc_host/host4/issue_lip делает rescan? по логам:

Нет, не делает. Только разрешает сканирование. После него нужно "- - -" в /sys/class/scsi_host/$HOST/scan

Эта статья описывает муки настройки fiber channel target поверх Centos.

Коллегам, хорошо разбирающимся в линукс, можно читать в качестве анекдота 🙂

В общем, это было увлекательное, но очень долгое путешествие.

Вдогонку за кроликом или fiber-channel, linux и много-много google: 14 комментариев

А CentOS зачем переставлять.
И прошу прощения, но какая может быть скорость на обычных дисках.
Ее можно сразу было рассчитать и не мучаться.
Вопрос про FC не задаю, понимаю, что было железо 🙂

И почему нельзя было впилить драйвера от RedHat?
Для него всегда все есть нормального качества, хоть и не OpenSource.

2Philzy: а фиг его знает. Так как я с линуксом на вы, то особо не разбирался. Надо все очистить, переставляем ))
А один раз я так зачетно удалил LVM-тома, что потом вообще установить Centos не смог :)))

Почему не RH? А фиг его знает.
Насколько я понял апологета RH, драйвера-то впилить можно, но вот target-режима в qLogic в них нет, как и его поддержки в ядре. А если компилируешь ядро, то принципиальной разницы вроде как нет между дистрибутивами.
2Omnimod: Ага 🙁
Вся эта эпопея затянулась на 3 месяца (с февраля по апрель).

ps SCSI HBA на погонять есть ?

2Phylzy: FC я решил использовать, так как по гигабиту много не набэкапишь.

Ну и Round Robin от SCST мне реально понравился: на 4*2Гбит/с он грузил все четыре канала у карточки (по обеим фабрикам) на 20%. То есть на источники были нагружены линки в обе фабрики, причем поровну.

>>Плюс Round/Robin не суммирует скорость в канале, а всего лишь определяет пути связности, как и LACP. И на основании этого не мучаться с подобным решением.

Ведь таки не послушал ты меня. Раз вся свистопляска началась из-за батарейки, может просто стоило её заменить? 🙂

А что не так с Forever Incremental. ?
Я тут решил вплотную veeam-ом заняться

Кстати, забыл упомянуть: SCST поддерживает ALUA.
То есть вы можете сделать кластер из двух систем и презентовать его по FC.
Получится вполне неплохая альтернатива любому двухконтроллерному СХД entry-level.

Добавить комментарий Отменить ответ

Перейти с Порше на Жигули - такое себе решение!

Мысли в слух " а может перейти на proxmox " Что-то в последняя время ESXi не стабильно стал по обновлениям.…

FC использует свою адресацию, поэтому для указания, с таким устройством работать, используется WWN (World Wide Name, параметр node_name (есть ещё port_name (WWP), но они отличаются, хотя и похожи)):

где host10 - наше целевое устройство. Можно посмотреть в каталоге /sys/class/fc_host/, либо через утилиту systool:

Если необходимо узнать WWN адаптера, доступной по Fibre Channel, то информацию можно найти в каталоге:

, где rport-6:0-2 - один из доступных (в примере - только один) HBA.
Непосредственно WWN адаптера:

б) HBA Emulex

Запускаем исправленный install.sh и ставим утилиту.
После этого лучше сразу обновить карту последними прошивками: для это и нужны Linux Elxflash Offline, Firmware и Universal Boot.
Распаковываем Linux Elxflash Online ( ../x86_64/rhel-7/elxflashOnline-10.2.370.19 ), во вложеные каталоги ./boot и ./firmware распаковываем содержимое Universal Boot и Firmware и запускам эту утилиту:

Более подробное описание параметров доступны в "хелпе", а примеры - в файле ./lcreflsh.sh.

2 - УПРАВЛЕНИЕ HBA
Для управления Emulex HBA используется утилита hbacmd, входящая в состав ранее установленного пакета Application Kit.
Выбор топологии:

где host6 - номер устройства, которое можно определить из:

hbacmd - утилита управления HBA Emulex из пакета пакета OneCommand:

в) HBA QLogic

По умолчанию FC HBA стартует в режиме инициатора (initiator mode), поэтому надо карту при инициализации перевести в режим цели (target mode).
Для этого есть два варианта:
1) дописать в параметры ядра ещё один (и перегрузиться, конечно):

2) создать файл /etc/modprobe.d/qla2xxx.conf с такой строкой:

При использовании второго варианта надо помнить, что данного вида карты инициализируются на очень раннем этапе загрузки, когда ещё "работает" образ initrd, то просто перезагрузка ничего не даст - необходимо пересобрать initrd, чтобы инициализация прошла:

Проверка, что карта в нужном режиме:

Кроме данного параметра можно, при установке 2-х карт включить , указав соответствующий параметр ядра:

, где ql2xfailover - поддержку fallover-режима (активное резервирование при установке не менее 2-х плат HBA); ConfigRequired - указывает, как осуществлять привязку (bind) устройств: 0 - всех обнаруженных ОС, 1 - только устройств, определённых в файле /etc/qla2xxx.conf (по умолчанию: 0).
Более подробно о параметрах драйвера qla2xxx.ko.
К сожалению, параметр ql2xfailover можно использовать не всегда: во многих дистрибутивах в сборках qla2xxx этот функционал исключают (как и FC-target). Почему - могу только догадываться: возможно, чтобы не создавать конкуренцию дорогим решениям. Надо, при случае, попробовать собрать драйвер самому по данной инструкции: How to Configure the FC QLogic Target Driver for 22xx/23xx/24xx/25xx/26xx Adapters.
Управлять FC будем с помощью Linux SCSI Target (LIO), используя программу управления targetcli:

И запустим службу восстановления конфигурации (Restore LIO kernel target configuration):

Теперь вся работа - утилитой targetcli:

Если после запуска мы будет находиться не в корне (например, /qla2xxx), то выйдем на него:

Посмотрим исходное состояние:

Ветка qla2xxx - это указание наличия FC карты QLogic и её поддержки в системе.
Запросим информацию по этой ветке:

Создадим объект хранилища для нашей будущей Цели (target):

В примере устройство /dev/md125 - программный RAID массив.
Создаём саму Цель:

где 2100001b32180465 - WWN карты Fibre Channel, установленной в системе, берётся из вывода info узла /qla2xxx (см.выше).
Создаём лист доступа (ACL, access control list) с WWN карт, имеющих доступ к данной:

Привязываем ранее созданное блочное устройство к Цели:

Смотрим результат наших операций:

Если всё устраивает, сохраняем конфигурацию (специально, если отключено автоматическое сохранение (по умолчанию)):

Указывается, что текущая конфигурация сохранена в /etc/target/saveconfig.json, а в /etc/target/backup находятся 10 предыдущих вариантов.
Если возникает желание/необходимость что-то удалить, переходим в нужную ветку дерева и удаляем, например, LUN:

Теперь посмотрим, доступен ли наш LUN на целевой системе, Инициаторе, пересканировав доступные LUN:

где X - номер нашего FC HBA.
Смотрим, доступен ли соответствующий LUN в системе Инициатора:

Чтобы добавить одно заданное устройство, выполним:

Чтобы удалить заданное устройство, выполним:

где <H> <B> <T> <L> — это хост, шина, целевой номер устройства и логический номер (host, bus, target, LUN) соответственно. Соответствующие устройству номера можно найти в каталоге /sys (только для ядер версии 2.6), файле /proc/scsi/scsi или выводе команды dmesg.
Удалить (отключить) LUN:

2. Infiniband

Infiniband - сравнительно молодой интерфейс, идея создания которого была в замене современной сетевой инфраструктуры Ethernet и Fibre Channel.

а) Общая информация по настройке

б) HCA: QLogic

в) HCA: Mellanox

3. iSCSI

4. Программный RAID

а) Создание RAID-массива
Для работы с программным RAID в Linux используется утилита mdadm. Создание с её помощью массива RAID1:

Сканирование системы на наличие массивов и вывода информации по ним (в форме для добавления в файл конфигураций /etc/mdadm/mdadm.conf):

б) Мониторинг состояния массива
Состояние RAID-массива отслеживается через файл /proc/mdstat:

Информация о конкретном дисковом разделе:

Мониторинг состояния массива - разовая проверка:

Для постоянной периодической проверки эту команду надо внести в файл, например, mdRAIDmon, размещённый в папке /etc/cron.haurly/.
Или, для пятиминутной проверки внести в файл /etc/crontab следующую строку:

Проверки работы системы оповещения:

в) Работа с разделами на RAID-массиве
Удаление LVM и RAID, где он размещён:

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

г) Поддержка bitmap
Включение поддержки bitmap с хранением:

Просмотр включенных bitmap:

Отключение на RAID-массиве использование bitmap:

Параметр bitmap в свойствах массива означает добавление дополнительной информации для восстановления RAID в случае сбоев. Сборка массива при замене жёсткого диска будет происходить быстрее, но общая производительность массива снизится примерно на 5% в случае размещения bitmap на том же диске, что и RAID или в самом RAID-массиве (по умолчанию).

е) Очистка дисков от метаданных RAID
Отмонтируем все разделы, размещённые на удаляемом RAID и остановим этот массив:

Стираем суперблок, хранящий информацию о массиве, на всех дисках, входящих в удаляемый массив:

Если не получилось, то делаем прямым затиранием:

Выключаем систему, отключаем девственно чистые диски. :\

5. Работа с LVM

а) Отключение/подключение диска с LVM

Это требуется, например, после подключения диска с LVM к системе через, например, USB конвертер. Если отключать диск без некоторых дополнительных действий, то в системе останутся "зависшими" подключения, что может вызвать некоторые проблемы.
Для отключения надо:
1) отмонтировать все разделы на этом диске;
2) выполнить команду:

3) удаляем блочное устройство (в современных системах происходит автоматически, но вдруг понадобится) /dev/sdf:

Всё, можно отключать питание.
Если LVM не подключается автоматически, то вручную это делается так (для устройства hostX, где X - номер в системе):

Теперь можно монтировать.

б) Создание томов LVM

Посредством утилиты fdisk создаём (описано в предыдущем пункте) на новом диске таблицу разделов и раздел на нём.
Создание новых томов (физического, группы и логического) на дополнительном диске /dev/sdb:

Добавляем новую запись к файл /etc/fstab и на этом заканчивается настройка.

в) Восстановление удалённых томов

Если случайно был удален том LVM (или специально, но потом понадобилось восстановление) - механизм резервного копирования метаданных volume group может спасти ситуацию.
Настройка архивирования находится в файле /etc/lvm/lvm.conf в секции backup.
По умолчанию архивирование включено, папка для архивов - /etc/lvm/archive и содержит архивы изменения vg за 30 дней.
Посмотреть чего менялось можно командой

Здесь видно имя файла архива и команда, перед (или иногда после) которой архивирование метаданных VG было выполнено.
В данном случае были удалены некоторые LV и после них создан новый.
Чтобы узнать, попал новый LV поверх старых (тогда естественно данные будут перезаписаны, зависит от количества записей в новый LV) надо посмотреть в архиве до удаления параметры extent_count и stripes нужного LV. stripes это номер начала блока на PV, extent_count - количество.
LV может состоять из нескольких сегментов, в каждом будет свой набор extent_count и stripes.
Потом посмотреть эти же параметры нового LV, но в архиве поcле создания нового LV.
Если эти регионы не пересеклись - значит новый LV создался в другом месте, чем удаленные LV.
Восстановление метаданных:

это откатит все изменения с текущего момента до нужного архива, предшествующего указанной в vgcfgrestore -l команде.
Дальше остается только активировать восстановленные LV командой

г) Изменение размеров томов

Изменение размеров физического тома - задача весьма сложная и обычно не применяется. Безопаснее либо удалить физический том, изменить размер раздела и создать том заново, либо (как в данном примере) создать на доступном свободном пространстве дополнительный физический том и объединить его в группу томов, для которых требуется расширение.
При необходимости увеличить доступный объём дискового пространства на, например, корневом разделе, необходимо воспользоваться имеющимся функционалом LVM:
1) смотрим (например, утилитой fdisk) (пакет util-linux), где у нас есть свободное место на подключённых накопителях:

Предположим, что у нас есть /dev/sda1 - загрузчик (т.е. /boot) и /dev/sda2 - собственно корень системы (т.е. /) и имеет формат Linux LVM. И на том же диске есть ещё свободное неразделённое место.
2) формируем новый раздел на свободном месте накопителя (в данном случае /dev/sda) новый раздел в интерактивном режиме:

На запрос "Команда (m для справки)" жмём n (создание нового раздела), p (первичный раздел), 3 (номер нового раздела: 1 и 2 уже есть, новый будет /dev/sda 3 ), начальный и конечный блок оставляем как есть (или указываем необходимый объём, если будем использовать не всё доступное пространство).
После создания раздела необходимо указать его тип "Linux LVM": наживаем t, затем выбираем созданный раздел (наш - 3) и указываем его тип - 8e.
Затем p (просмотреть созданные изменения): если всё устраивает - w (записать изменения и выйти), если не устраивает перенастраиваем или жмём q (выйти без изменений) и всё заново.
Внесённые изменения ещё не известны ядру, поэтому сообщаем ядру, чтобы оно приняло изменения, командой:

Создаём новый физический том на созданном разделе:

Смотрим, на какой группе томов расположен корневой раздел /dev/sda2:

Добавляем к этой группе созданный нами раздел /dev/sda3:

Смотрим путь, по которому доступен целевой логический том:

Выделяем целевому тому необходимое место:

В качестве альтернативного пути может быть использован любой:
1) через mapper: /dev/mapper/lvmpart-root;
2) через любой путь в каталоге /dev/disk/.
Теперь остаётся изменить размер файловой системы, размещённой на целевом логическом томе. Это производится для каждой файловой системы по своему:

Кроме этого изменение размера: XFS - в примонтированном состоянии, EXT x - не имеет значения (но отмонтированно представляется более безопасным для данных вариантом),
Для EXT x есть возможность (и она использована в примере) создания файла отката вносимых изменений: в представленном варианте - old_LVM.e2undo. В случае необходимости изменения отменяются утилитой e2undo (пакет e2fsprogs):

Для увеличения размера целевой файловой системы всё сделано.
При необходимости уменьшить размер всё производится в обратном порядке, но действия производятся только на размонтированных файловых системах. Т.е., в случае с корневым разделом надо предварительно загрузиться с LiveCD с поддержкой LVM2. ВАЖНО!: операция уменьшения невозможна для XFS.

Теперь вносим изменения в группы томов и физические тома.

д) Дополнительная информация

6. Некоторые особенности настройки FreeNAS 10

Смена пароля root через CLI:

Так же надо назначить IP адрес:

В 10 версии полностью переработаны интерфейсы: и графический (GUI) и консольный (CLI).
Если используется Fibre Channel карта для работы с СХД на базе FreeNAS, то для создания и презентации соответствующего LUN надо использовать ctladm. По сути: в интерфейсе WebGUI настраивается iSCSI, а для работы активировать FC интерфейс:

Хорошо поддерживаются FC-карты QLogix (устройство isp X ).

Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

Продолжаю вещать на тему прояснения основных представлений об 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, трансиверы, электрические и оптические параметры.

Fibre Channel Protocol for SCSI-3 (SCSI-FCP) — проброс SCSI
Fibre Channel Link Encapsulation (FC-LE) — проброс TCP/IP

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

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

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

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

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

8/10 и 64/66

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

Ordered sets

Разделители фреймов (Start-of-Frame, SOF и End-of-Frame, EOF).
Два базовых сигнала — IDLE (порт готов принимать или передавать данные) и R_RDY (receiver ready — порт освободил буфер для приёма очередной порции данных)
Базовые последовательности (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, между ними происходит следующий «обмен веществ»:

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

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

Конец

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

Были использованы материалы из следующих источников:
IBM Redbook «Introduction to SAN and System Networking»
EMC «Network Storage Concepts and Protocols»
Brocade «SAN Fabric Administration Best Practices Guide»

Читайте также: