Fibre Channel междугородние беды

52

Мне нужна свежая пара глаз.

Мы используем 15-километровую волоконно-оптическую линию, по которой мультиплексированы оптоволоконный канал и 10GbE (пассивный оптический CWDM). Для FC у нас есть лазеры на большие расстояния, подходящие до 40 км ( Skylane SFCxx0404F0D ). Мультиплексор ограничен SFP, которые могут делать макс. 4Gb оптоволоконный канал Переключатель FC - это серия Brocade 5000. Соответствующие длины волн составляют 1550, 1570, 1590 и 1610 нм для FC и 1530 нм для 10GbE.

Проблема в том, что ткани 4GbFC почти никогда не бывают чистыми. Иногда они на некоторое время даже с большим трафиком на них. Затем они могут внезапно начать выдавать ошибки (RX CRC, RX-кодирование, RX-несоответствие и т. Д.) Даже с минимальным трафиком. Я прилагаю некоторые ошибки и графики движения. В настоящее время ошибки составляют порядка 50-100 ошибок за 5 минут при трафике 1 Гбит / с.


оптика

Вот суммарная выходная мощность одного порта (собранная sfpshowна разных коммутаторах)

ЕДИНИЦЫ А-САЙТА = uW (микроватт)
**********************************************
Fab1
SW1 TX 1234.3 RX 49.1 SW3 1550 нм (ко)
      RX 95.2 TX 1175.6
Fab2
SW2 TX 1422,0 RX 104,6 SW4 1610 нм (нормально)
      RX 54,3 TX 1468,4      

На данный момент мне кажется интересным асимметрия уровней мощности. В то время как SW2 передает с 1422uW, который SW4 получает с 104uW, SW2 принимает только сигнал SW4 с аналогичной исходной мощностью только с 54uW.

Наоборот для SW1-3.

В любом случае, SFP имеют чувствительность RX до -18 дБм (около 20 мкВт), так что в любом случае все должно быть в порядке ... Но ничего не происходит.

Некоторые SFP были диагностированы производителем как неисправные (1550 нм показаны выше с «ко»). 1610nm, видимо, в порядке, они были протестированы с использованием генератора трафика. Арендованная линия также была проверена более одного раза. Все в пределах допусков. Я жду замен, но по какой-то причине я не верю, что это улучшит ситуацию, так как, по-видимому, хорошие тоже не выдают ошибок ZERO.

Ранее было задействовано активное оборудование (своего рода устройство 4GFC) до того, как поставить сигнал на линию. Понятия не имею почему. Это оборудование было ликвидировано из-за проблем, поэтому теперь у нас есть только:

  • лазер дальнего действия в выключателе,
  • (новый) 10 м LC-SC мономодный кабель к мультиплексору (для каждой ткани),
  • выделенная линия,
  • то же самое, но наоборот на другой стороне ссылки.


FC переключатели

Вот конфиг порта от Brocade portcfgshow(очевидно, что так с обеих сторон)

Номер зоны: 0
Уровень скорости: 4G
Заполнить слово (включено) 0 (простаивает)
Заполнить слово (текущий) 0 (холостой ход)
AL_PA Offset 13: OFF
Магистральный порт включен
Long Distance LS
VC Link Init OFF
Желаемое расстояние 32 км
Зарезервированные буферы 70
Locked L_Port OFF
Заблокирован G_Port OFF
Отключено E_Port OFF
Заблокированный E_Port OFF
ISL R_RDY Режим выключен
RSCN подавлен
Постоянный Отключить ВЫКЛ
ЛОС ТОВ включить ВЫКЛ
Возможность NPIV ВКЛ
QOS E_Port OFF
Автоотключение порта: OFF
Ограничение скорости выключено
EX порт отключен
Зеркальный порт выключен
Восстановление кредита на
F_Port Buffers OFF
Задержка ошибки: 0 (R_A_TOV)
NPIV PP предел: 126
Режим CSCTL: OFF

Форсирование ссылок на 2GbFC не приводит к ошибкам, но мы купили 4GbFC и хотим 4GbFC.

графики ошибок и трафика

Я не знаю, где искать больше. Есть идеи, что попробовать дальше или как действовать дальше?

Если мы не можем заставить работать 4GbFC надежно, мне интересно, что делают люди, работающие с 8 или 16 ... Я не предполагаю, что "несколько ошибок здесь и там" приемлемы.

Да, и кстати, мы находимся в контакте со всеми производителями (FC-коммутаторы, MUX, SFP, ...) За исключением того, что SFP должны быть изменены (некоторые были изменены ранее), никто не знает. Brocade SAN Health говорит, что с тканью все в порядке. MUX, ну, это пассивно, это всего лишь призма, природа в лучшем виде.

Любые снимки в темноте?


ПРИЛОЖЕНИЕ: Ответы на ваши вопросы

@ Chopper3: это второе поколение Brocades, демонстрирующее проблему. Раньше у нас было 5000, сейчас у нас 5100. Вначале, когда у нас еще был активный MUX, мы один раз арендовали лазер дальнего действия, чтобы включить его в выключатель, чтобы провести тесты в течение дня, в течение этого дня, конечно, он был чистым. Но, как я уже сказал, иногда это так просто. И иногда это не так. Альтернативные коммутаторы означали бы восстановление всей сети SAN с теми, которые только для тестирования. Альтернативные SFP, ну, их так сложно найти.

@ longneck: линия арендована. Это темное волокно (9um monomode), поэтому на нем больше никого нет. Конечно, есть соединения. Я не могу пойти и посмотреть, но я должен верить, что они были сделаны правильно. Как я уже сказал, линия была проверена и перепроверена (с использованием оптического рефлектометра во временной области). Очевидно, у вас нет всего этого оборудования, потому что оно слишком дорогое.

@mdpc: Какой тип кабеля вы считаете «неправильным»? До коммутатора все однорежимно, да. Разъемы тоже правильные. Да, я знаю, что есть зеленые, где волокно обрезается под определенным углом и т. Д. Но у нас есть правильные для всего, что я знаю.


Отчет о проделанной работе № 1

У нас было две матрицы (= 2x2 коммутатора) с Brocade 5100 с FabricOS 6.4.1 и две матрицы (еще 2x4 коммутатора) на FabricOS 7.0.2.

На длинных расстояниях ISL (по одному в каждой матрице) оказалось, что при установке FOS 6.4.1 на большие расстояния выдает предупреждения о настройке инициализации VC и, следовательно, слова заполнения. Но это только предупреждения. FOS 7.0.2 требует , чтобы вы вносили изменения в VCI и заполняли слово для междугородных ссылок.

Установка FOS 6.4.1 в настройке LS (междугородная связь) с неправильной настройкой VCI и заполняющим словом сделала всю фабрику неработоспособной (застрявшей в контуре SCN, используйте, fabriclog -sчтобы видеть, вы больше нигде не видите, нет ошибки порта счетчики или что-нибудь увеличивающееся).

В настоящее время я даю избиение одной матрице с ИМХО более правильными настройками, и, кажется, все в порядке, тогда как другая без большого трафика все еще имеет ошибки здесь и там.

progress1

Короче говоря:

  • Мы устранили активную часть MUX (FC retimer).
  • Мы помещаем SFP на большие расстояния в само оборудование.
  • Просто чтобы быть уверенным, что мы купили новые кабели для одномодового подключения, чтобы подключить конечное оборудование к оставшейся пассивной части MUX.
  • Сейчас мы пробуем несколько конфигов на большие расстояния.

Это почти чёрная магия. Все, что происходит, в основном эмпирически, кажется, никто не знает, каковы точные причины что-то делать. («Мы попробовали это, и это не сработало, потом мы попробовали это, и это сработало, поэтому мы придерживались этого». Но, похоже, никто не знает почему.)

Я буду держать вас в курсе.


Отчет о проделанной работе № 2

Мы получили новые лазеры для одной из тканей по гарантии. Это очень чистый даже на 4GbFC.

Они передают примерно 2 мВт (3 дБм), в то время как остальные только на 1,5 мВт (1,5 дБм), хотя этого действительно должно быть достаточно.

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

Использование sfpshowSFP, производящего фактические ошибки RX, показывает

Статус / Ctrl: 0x82
Аварийные флаги [0,1] = 0x5, 0x40
Предупреждающие флаги [0,1] = 0x5, 0x40

Теперь я должен выяснить, что это значит. Не уверен, было ли это там раньше.

Что ж, сначала я проясню голову после недели отпуска. 8-)

Marki
источник
8
Прежде всего, отличный вопрос, для чего именно этот сайт, молодец. Во-вторых, есть ли у вас доступ к альтернативным коммутаторам / SFP - в идеале, к другой марке / модели, которую вы можете обменять для тестирования?
Chopper3
4
Отличное обновление, продолжайте в том же духе, жаль, что у меня не было предложений или советов, но вы на правильном пути, приятно найти нового пользователя на SF, который знает свое дело :)
Chopper3
1
Есть ли согласованность во времени или продолжительности ошибок? Они всегда происходят в N час? Они всегда длятся X минут? Можете ли вы соотнести их с погодой, ближайшими спортивными событиями или другим явлением? Прерывистые проблемы - самые трудные ошибки, чтобы их можно было раздавить, и я обычно начинаю их атаковать, отображая время и продолжительность их появления на доске. Надеемся, что появятся скороговорки, которые могут быть связаны с другим явлением .
dotancohen
2
Вы отслеживаете их на доске, видимой для всех ? Я не буду нажимать, но я очень рекомендую это. Как вы и сказали, вам нужна свежая пара глаз, и, возможно, кто-то в вашей организации увидит, как закономерность проявляется в зависимости от времени / продолжительности, а не обязательно от симптомов.
dotancohen
1
Привет Марки. Я не совсем знаком с тем, о чем вы говорите, но после вашего последнего обновления кажется, что проблема была устранена заменой SFP? Если это так, то, вероятно, хорошая идея опубликовать это как ответ и задать новый вопрос, если у вас есть дополнительные проблемы.
Марк Хендерсон

Ответы:

4

Хорошо, я думаю, мне нужно опубликовать ответ. Одним словом это: настаивать .

На мой взгляд, проблема не решена на 100%, так как у нас все еще есть одна матрица с 1 (одной) ошибкой CRC. Другой чистый. Но я могу жить с этим.

В любом случае мы не будем продолжать использовать модули CWDM в течение очень долгого времени, а перейдем к пассивному мультиплексору DWDM в следующем году, поскольку наша инфраструктура сильно изменится. Очевидно, что DWDM-лазеры дешевле, чем CWDM-лазеры. О, мы увидим, и, возможно, у меня будет много вопросов, чтобы спросить вас :-)


Обновите Nope до вышеуказанного, мы снова купили CWDM, и это действительно дешевле. AFAICS для некоторых приложений, однако, вы должны использовать DWDM, потому что для него нет CWDM-лазеров. Наконец, мы попытались максимально приблизиться к производителю, и все это получилось примерно на 1/5 цены по сравнению с покупкой у дистрибьютора или даже интегратора.


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

  • удалить активную часть MUX (не могу сказать, что сожалею об этом, но также не уверен, что это, наконец, еще один источник ошибки или нет)
  • тщательно проверить SFP

(И, конечно, вся стандартная диагностика, меняйте одну вещь за раз, смотрите, что происходит и т. Д., Вам не нужно об этом говорить. Поэтому мы также проверили каждую линию, кабель и т. Д., К сожалению, за наш счет.)

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

PS. Да, и флаги, которые я упомянул в моем последнем обновлении, ничего плохого не указывали, но я не помню, что именно они имели в виду. Когда я найду утверждение, я обновлю ответ для полноты картины.


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

Да и кстати, DWG-трансиверы 8GbFC дешевле только по сравнению с 8G CWDM ;-) Самый дешевый способ - это 4GbFC на CWDM, а затем использовать ISL-транкинг (если у вас есть лицензия)

Marki
источник
Я не видел этого, когда это спросили, к сожалению. Я не могу сказать вам точно, что это поможет, но если вы используете пустые слова, вы посылаете много света. Это означает, что каждый неиспользуемый кадр потребляет много энергии и выделяет много тепла в SFP, я думаю. Изменение заполняющего слова на другой режим (я использую режим 3, но у меня другой коммутатор и SFP) может позволить вам увеличить пропускную способность с меньшим количеством ошибок.
Василий
@Basil Я знал, что использование правильного слова для заполнения было проблемой для синхронизации слов в 8GFC, но я думал об этом следующим образом ...
Marki
Рекомендуется в любое время, когда вы можете использовать его - насколько я могу судить, вопрос в том, сколько помех создает свободный SFP-кадр.
Василий