Brocade SAN Часть 7: Базовое решение проблем

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

Устранение неполадок должно начинаться в центре SAN-фабрики. Поскольку коммутаторы расположены между хостами и устройствами хранения данных, начиная с них, можно сузить путь поиска. После устранения возможных неисправностей внутри фабрики, посмотрите есть ли проблемы на стороне хранилища или на стороне хоста и продолжите более подробную диагностику уже там. Использование этого подхода может помочь быстро определить и изолировать проблему. Сначала вам нужно определить в чем проблема. Некоторые симптомы очевидны, например, перезагрузка коммутатора без вмешательства пользователя или более неясная, например, ваше хранилище имеет прерывистую связь с конкретным хостом. Независимо от симптома, вам нужно будет собирать информацию с устройств, которые непосредственно участвуют в системе. Вообще данный раздел призван не сколько помочь вам в решении конкретных проблем, сколько научить собирать необходимую информацию, которая поможет определить причины неисправностей. Понимание того — какую информацию и где, в случае какого-то сбоя вам необходимо смотреть, сильно сократит время диагностики проблемы, даже если вы обращаетесь за помощью к вендору.

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

Небольшая сводная таблицы проблем и команд, при помощи которых можно понять их причины.

Теперь рассмотрим несколько типичных проблем, предлагаемых самим Brocade:

• Вышло время скачивания прошивки (firmwaredownload)
  • В большинстве случаев это связано с очень медленной передачей данных по сети, если это занимает более 30 минут. В данном случае рекомендуется воспользоваться USB накопителем и обновить прошивку с него.
• Невозможность прямого обновления до версии FOS 7.4.0
  • Если на вашем коммутаторе установлена FOS 7.2 или более ранняя, у вас нет возможности прямого обновления до FOS 7.4, необходимо первоначально обновиться до FOS 7.3, а затем уже до FOS 7.4. Это же правило действует и при откате.
• Невозможно закачать прошивку на коммутатор
  • Прошивка, которую вы пытаетесь закачать, несовместима с данным коммутатором. Проверьте её версию и модель коммутатора, для которого пытаетесь загрузить прошивку.
• Вы получаете уведомление «firmwaredownload is already in progress»
  • Это вполне нормальное поведение, если процесс обновления прошивки уже идёт. Необходимо дождаться завершения этого процесса. За процессом обновления прошивки можно наблюдать при помощи команд firmwareDownloadStatus и firmwareShow
• При включении FIPS коммутатор постоянно перезагружается
  • Когда FIPS включен, коммутатор запускает условные тесты каждый раз, когда он перезагружается. Если тесты не работают на вашем коммутаторе, он постоянно перезагружается. Поскольку доступ к загрузочному PROM отключен, вы не можете выйти из перезагрузки. Вы должны отправить коммутатор обратно поставщику услуг коммутатора для ремонта.
• Сервер мониторинга не получает SNMP трапы от фабрики
  • Проверьте работу фаерволов между коммутаторами и сервером
  • Если у сервера несколько адресов, убедитесь в правильной настройке маршрутизации
• Неработоспособность одного из линков в ISL транке
  • Воспользуйтесь командой trunkdebug для получения информации о состоянии транк портов. Команда trunkDebug отображает возможную причину по которой порты не собираются в транк. Возможные причины:
    • Коммутатор не поддерживает транкинг
    • Требуется лицензия на транкинг
    • Транкинг не поддерживается в режиме взаимодействия с коммутатором
    • Транкинг отключен
    • Порт не является E_Port
    • Порт не поддерживает 2, 4 или 8 Гб/с
    • Порт подключается к коммутатору, отличному от того, к которому вы планируете
    • Порты имеют различную скорость или они настроены на недопустимую скорость
    • Порты настроены в разных режимах long distance
    • Разница в длине кабеля между транковыми каналами больше разрешенной

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

Выявление узких мест (Bottlenecks)
Узким местом является порт в фабрике, где кадры не могут пройти так быстро, как должны. Другими словами, узким местом является порт, где предлагаемая нагрузка больше, чем его доступная пропускная способность. Узкие места могут вызвать нежелательное ухудшение пропускной способности на различных линках.

Функция обнаружения узких мест не требует лицензии и по умолчанию отключена. Она настраивается для каждого коммутатора в отдельности. Лучшая практика заключается в том, чтобы обеспечить их своевременное обнаружение.

Своевременное обнаружение болтнеков позволяет вам выполнить следующие действия:

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

Для включения системы обнаружения узких мест, необходимо выполнить команду bottleneckmon —enable. По умолчанию она только отслеживает состояние портов и вы имеете возможность просмотреть историю срабатывания тригера, если же вы хотите получать уведомления, то необходимо в команду добавить ключ -alert.

Функция bottleneck detection обнаруживает два типа узких мест:

• По задержкам (Latency bottleneck)
• По перегрузкам (Congestion bottleneck)

Причём вы имеете возможность получать алерты только по одному из типов, указав его в ключе -alert: -alert=latency или -alert=congestion. Без указания же типа, включается для обоих.

Проверить состояние мониторинга можно следующим образом:
IBM_2498_24G_FSW1:admin> bottleneckmon —status
Bottleneck detection — Enabled
==============================

Switch-wide sub-second latency bottleneck criterion:
====================================================
Time threshold — 0.800
Severity threshold — 50.000

Switch-wide alerting parameters:
================================
Alerts — No

Теперь вы имеет возможность просматривать информацию о срабатывании данного тригера:
IBM_2498_24G_FSW1:admin> bottleneckmon —show
==================================================================
Mon Jan 08 11:37:42 MSK 2018

==================================================================
List of bottlenecked ports in most recent interval:
None
==================================================================
Number of
From To bottlenecked ports
==================================================================
Jan 08 11:37:32 Jan 08 11:37:42 0
Jan 08 11:37:22 Jan 08 11:37:32 0
Jan 08 11:37:12 Jan 08 11:37:22 0
Jan 08 11:37:02 Jan 08 11:37:12 0
Jan 08 11:36:52 Jan 08 11:37:02 0
Jan 08 11:36:42 Jan 08 11:36:52 0
Jan 08 11:36:32 Jan 08 11:36:42 0
Jan 08 11:36:22 Jan 08 11:36:32 0
Jan 08 11:36:12 Jan 08 11:36:22 0
Jan 08 11:36:02 Jan 08 11:36:12 0
Jan 08 11:35:52 Jan 08 11:36:02 0
Jan 08 11:35:42 Jan 08 11:35:52 0
Jan 08 11:35:32 Jan 08 11:35:42 0
Jan 08 11:35:22 Jan 08 11:35:32 0
Jan 08 11:35:12 Jan 08 11:35:22 0
Jan 08 11:35:02 Jan 08 11:35:12 0
Jan 08 11:34:52 Jan 08 11:35:02 0
Jan 08 11:34:42 Jan 08 11:34:52 0
Jan 08 11:34:32 Jan 08 11:34:42 0
Jan 08 11:34:22 Jan 08 11:34:32 0
Jan 08 11:34:12 Jan 08 11:34:22 0
Jan 08 11:34:02 Jan 08 11:34:12 0
Jan 08 11:33:52 Jan 08 11:34:02 0
Jan 08 11:33:42 Jan 08 11:33:52 0
Jan 08 11:33:32 Jan 08 11:33:42 0
Jan 08 11:33:22 Jan 08 11:33:32 0
Jan 08 11:33:12 Jan 08 11:33:22 0
Jan 08 11:33:02 Jan 08 11:33:12 0
Jan 08 11:32:52 Jan 08 11:33:02 0
Jan 08 11:32:42 Jan 08 11:32:52 0

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

Поиск проблем с производительностью можно осуществлять не только при помощи консоли, но и при помощи Brocade Network Advisor. На графиках и шкалах это прекрасно видно. Хочу порекомендовать вот этот небольшой вебинар на тему траблшутинга при помощи BNA. Коротко, ясно и наглядно.

На этом первая часть, входящая в состав курса BCFA — завершена. Оставшиеся 7 частей входят уже в курс BCFE.

Как и всегда — я приглашаю задавать вас вопросы, если мне не удалось что-то объяснить понятным языком или у вас возникли дополнительные вопросы.