отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Поиск и устранение неполадок на оборудовании Cisco UCS Fabric Interconnect (Часть 2)

New Member

В условиях стабильной работы Cisco UCS имеется потребность в создании некой статистической выкладки, цель которой – зафиксировать нормальные показатели среднего количества трафика, поступающего через интерфейсы FI. Часть данных цифр можно собрать из GUI Cisco UCS Manager, но в данной статье будет обращено внимание на получение статистики из CLI с настройкой аварийных уведомлений и корректирующих действий при превышении заданных определенных порогов частоты ошибок на интерфейсах.
Рассматриваемые команды достаточно тривиальны, но всё же требуют определенной внимательности и, как и любая настройка Cisco UCS, некоторой предварительной работы.

В Части 1 была рассмотрена процедура поиска интерфейсов элементов Cisco UCS (vNIC -> HIF -> IOM -> NIF -> FI Port -> FI -> vEth -> Uplink Port), результаты которой теперь можно использовать в других командах CLI, где потребуется указывать номера нужных интерфейсов.

Существует набор CLI команд, позволяющих изучить поведение трафика на сетевых адаптерах vNIC. Для этого потребуется зайти в режим работы с конкретным сервером и затем запустить MCP (Master Control Program).

Temp-A# connect adapter 1/1/1
adapter 1/1/1 # connect
No entry for terminal type "dumb";
using dumb terminal settings.
adapter 1/1/1 (top):1# attach-mcp
No entry for terminal type "dumb";
using dumb terminal settings.

Затем, используя команду vnic, можно найти соответствие между символическими именами сетевых адаптеров vNIC и логическими интерфейсами LIF, которыми они представлены в системе.

adapter 1/1/1 (mcp):1# vnic
vnic id        : internal id of vnic, use for other vnic cmds
vnic name/mac  : ucsm provisioned name (-n) or mac address (-m)
vnic type      : enet=ethernet, enet_pt=dynamic ethernet, fc=fcoe
vnic h:bb:dd.f : host pci bus/device/function id
vnic state     : state of vnic
lif            : internal logical if id, use for other lif/vif cmds
lif state      : state of lif
vif uif        : bound uplink 0 or 1, =:primary, -:secondary, >:current
vif ucsm       : ucsm id for this vif
vif idx        : switch id for this vif
vif vlan       : default vlan for traffic
vif state      : state of vif
------------------------------------------ --------- --------------------------
                 v n i c                     l i f             v i f           
id  name           type    h:bb:dd.f state lif state uif  ucsm   idx vlan state
--- -------------- ------- --------- ----- --- ----- --- ----- ----- ---- -----
 13 vnic_1         enet    0:06:00.0 UP      2 UP    =>0   723    18    2 UP  
 14 vnic_2         enet    0:07:00.0 UP      3 UP    =>1   724    20    2 UP  
 15 vnic_3         fc      0:08:00.0 UP      4 UP    =>0   725    19  101 UP  
 16 vnic_4         fc      0:09:00.0 UP      5 UP    =>1   726    21  102 UP  

Сетевому адаптеру vnic_1 в данном случае соотнесен LIF 2 и VIF 723. Команда lifstats <lif#> позволит теперь изучить статистику по данному адаптеру по различным показателям, таким как количество фреймов разного типа и размера, прошедших через vNIC.

adapter 1/1/1 (mcp):2# lifstats 2
               DELTA                TOTAL DESCRIPTION
           121331817            121331817 Tx unicast frames without error
             1171244              1171244 Tx multicast frames without error
              468170               468170 Tx broadcast frames without error
        566065244188         566065244188 Tx unicast bytes without error
            87872199             87872199 Tx multicast bytes without error
           263183943            263183943 Tx broadcast bytes without error
            49882405             49882405 Tx TSO frames
            97236693             97236693 Rx unicast frames without error
             7443238              7443238 Rx multicast frames without error
             2463357              2463357 Rx broadcast frames without error
         80214585415          80214585415 Rx unicast bytes without error
           648886997            648886997 Rx multicast bytes without error
           828622859            828622859 Rx broadcast bytes without error
            17250998             17250998 Rx frames len == 64
            13535952             13535952 Rx frames 64 < len <= 127
            58449896             58449896 Rx frames 128 <= len <= 255
             5047808              5047808 Rx frames 256 <= len <= 511
             1504377              1504377 Rx frames 512 <= len <= 1023
               85483                85483 Rx frames 1024 <= len <= 1518
            11268774             11268774 Rx frames len > 1518
               2.758Mbps                  Tx rate
             406.487kbps                  Rx rate

Столбец DELTA показывает разницу в значениях по строкам между данным и предыдущим вводом этой команды.

В конце прошлой части была упомянута команда show platform software woodside sts для коммутаторов Fabric Interconnect 62xx. Данная команда позволяет отобразить физическую картину подключения внутренних и внешних интерфейсов модулей IOM.

На рисунке видно, что в данный момент подключены только сервера blade1 – blade4 и у IOM 1 (fex-1) задействованы внутренние интерфейсы HIF 15, 19, 23, 27 и 31 (символ ‘|’ под номером HIF).

Статистику по этим HIF интерфейсам можно увидеть в выводе команды show platform software woodside rate.

Внизу таблицы представлены только задействованные блейд серверами перечисленные выше интерфейсы HIF. Данные по каждому HIF можно уточнить, используя команду show platform software woodside rmon 0 hi<hif#>

(показана часть вывода)

Здесь в первую очередь следует обратить внимание на строки TX_PKTTOTAL  RX_PACKETTOTAL и  TX_PAUSE RX_PAUSE. Первая, очевидно, сообщает количество принятых и преданных пакетов, вторая – количество переданных и принятых Pause-фреймов, большое количество которых намекает на заторы на пути трафика.

Для получения информации о частоте потерь пакетов на интерфейсах модуля IOM, в том числе для разных значений Class of Service можно выполнить команду show platform software woodside loss.


Механика данной команды такова, что вводить ее потребуется дважды и в выводе будет отображена статистика только для тех интерфейсов, которые пострадали от потерь пакетов за время между вводами команды.

 

Уведомления о превышении порогов допустимого уровня ошибок.
Для получения уведомлений о том, что частота ошибок на интерфейсах в системе UCS выходит за пределы заданных средних или абсолютных значений, можно воспользоваться специальными пороговыми политиками Statistics Threshold Policy в GUI Cisco UCS Manager.

Данные политики могут быть применены к следующим компонентам UCS:

  • Интерфейсы Uplink Ethernet
  • Серверные интерфейсы, шасси и коммутаторы FI
  • Серверы и их элементы
  • Интерфейсы Fibre Channel

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

В разделе GUI Admin->Stats Management->Collection Policies для нескольких типов элементов (adapter, chassis, fex, host, port, server) можно задать интервал времени сбора статистики (Collection) и интервал времени генерации отчетов (Reporting).

Пример Threshold Policy можно увидеть в разделе LAN->Internal LAN->Threshold Policies. В выпадающем меню Stats Class можно выбрать категорию событий, для которых будут определяться пороги срабатывания.

Затем в пункте Threshold Definition необходимо добавить одно или несколько правил, задающих диапазон значений счетчика ошибок и уровень аварийного сообщения, с которым это событие будет отображаться в Faults,Events разделе (Critical, Major и т.д.)

В меню Property Type можно выбрать конкретный тип ошибок. Max будет означать максимальное значение за последний отчетный измерительный интервал (Reporting Policy), Min, соответственно, минимальное значение, а Delta – самое свежее значение счетчика за текущий измерительный интервал сбора статистики (Collection Interval). Иными словами, Delta – это самое актуальное значение счетчика. Normal Value показывает ожидаемое значение счетчика и только превышение его на некоторую величину будет вызывать появление аварийного события. В примере на скриншоте Normal Value имеет значение 0.0, а Alarm Trigger (Above Normal Value) для уровня критичности Major – 10 и 7. Это означает, что если счетчик окажется в значении 0.0+10 в текущий момент времени (из-за Delta), то появится аварийное сообщение. Если значение упадет ниже 0.0+7, событие будет переведено в статус cleared. Ненулевое значение Normal Value имеет смысл, если в качестве счетчика стоит, например, Ether Tx Stats Total Packets Delta Avg, что не характеризует какую-то ошибку, а указывает среднее количество пакетов на передачу.
В самом низу окна настройки есть опциональное поле, которое позволяет выключить соответствующий интерфейс FI в случае ошибки на время Auto Recovery Time (по умолчанию – 10 минут).

В следующих частях будут рассмотрены моменты, связанные с решением вопросов SAN подключений.

284
Просмотры
5
Полезный материал
0
Комментарии