Назад | Перейти на главную страницу

Как фреймы Fibre Channel заполняются и проходят через фабрику?

Пытаюсь понять, как на самом деле кадры Fibre Channel заполняются и отправляются через коммутируемую структуру. Я понимаю WWNN WWPN, WWNN - это WWN фактического HBA, а WWPN - это WWN фактических портов на карте. Таким образом, если HBA имеет 4 порта, все они имеют один и тот же WWNN, но разные WWPN. Тем не менее, все еще не уверен, где WWNN играет роль в коммуникации в фабрике. Во-вторых, процесс FLOGI, с помощью которого новый узел N_port пытается войти в структуру и получить динамический FCID. После завершения PLOGI узел N-порта может отправить свой WWPN. Это поддерживает отношения между WWPN и FCID ....

Наконец, адресация FC представляет собой комбинацию идентификатора домена, идентификатора области и идентификатора порта. Все 8бит. Насколько я понимаю, он используется для определения того, где в структуре находится интерфейс? Итак, если у меня есть два коммутатора, домен 1 и домен 2, 0100000 будет означать первую область коммутатора 00 и порт 00?

Кроме того, я все еще не уверен, как один хост отправляет данные другому хосту. При просмотре кадра FC есть поля для идентификатора назначения и идентификатора источника, которые представляют собой 24-битные адреса FC или идентификаторы FCID. У меня вопрос: заполняются ли эти DestID и SourceID HBA хоста или переключателем FC? Я думал, что хост знает свои собственные WWNN и WWPN только от HBA?

Во-вторых, я не вижу нигде в кадре Fibre Channel, где бы использовались WWNN или WWPN. Если только они не используются в процессах FLOGI и PLOGI для получения динамического идентификатора FCID.

Спасибо за вашу помощь. Ценить это.

PS Я использую Cisco MDS и на наших хостах fcinfo для сбора информации, я не вижу способа получить FCID с помощью fcinfo на каждом хосте? Вот почему я не понимаю, поддерживает ли хост список FCID назначения или нет.

Кроме того, для хостов, подключенных напрямую, без включения коммутатора, объединяются ли хосты друг в друга?

Вначале хост знает WWNN и WWPN.

Что ж, забудьте WWNN. WWNN теоретически должен быть одинаковым на всех портах всех адаптеров главной шины компьютера, но это случается редко. Обычно это то же самое на одном HBA, но я видел случай многопортового HBA с несколькими WWNN. Так что это немного беспорядок.

После входа в структуру (FLOGI / PLOGI) хост узнает свой P_ID от коммутатора. И коммутатор узнает WWPN / WWNN от хоста. Следовательно, коммутаторы знают, какой WWPN назначен один к одному какому 24-битному P_ID.

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

  • с какими WWPN мне разрешено общаться?
  • каков текущий P_ID WWPN, который я помню как свое блочное устройство (мой жесткий диск)?

Многие думают, что WWPN работает аналогично MAC-адресу, потому что числа выглядят «похожими». У них почти нет ничего общего и они играют разные роли.

WWPN или WWNN никогда не используются в качестве адреса; P_ID есть. По аналогии с DNS и IP, WWPN - это что-то вроде my.node.com: определяет адрес (111.112.113.114), но не служит адресом во время фактического общения; 111.112.113.114 делает. В FC P_ID будет фактическим адресом, используемым в кадрах.

Это не идеальная аналогия. WWPN не так удобочитаемо, как DNS-имя. И P_ID немного более полезен, чем IP, поскольку сам его формат помогает коммутаторам FC быстро узнать, как обрабатывать кадр. Во всяком случае, это большая картина.

Кстати, в FC нет ничего похожего на MAC-адрес (хорошо для нас!) - под адресацией P_ID нет низкоуровневой адресации.

Предостережение - я не знаю, что MDS-материал более новый (FC-SW и т.д.), что-то меняет, но это (ужасно) обратно совместимый протокол, так что ...

Насколько я понимаю, FC всегда выглядит как петля для устройств на нем. В каждом цикле может быть более одного устройства, но сам FC не имеет концепции маршрутизации или коммутации, все это обрабатывается коммутаторами (или другими трюками, но не внутри «обычных» кадров FC, без поддержки тегов VLAN и т. Д., Ну, может быть, с FC -SW).

Домены - это логические группы этих циклов.

Страница Википедии на самом деле неплохо.