Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .

Центры Обработки Данных Блоги (Data Center)

363 просмотров
0 Комментариев

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

690 просмотров
0 Комментариев

При анализе подключения Cisco UCS к сети важно понимать, каким образом пакеты передаются непосредственно между элементами UCS. По причине специфического поведения Cisco UCS Fabric Interconnect по сравнению с обычными коммутаторами и с Cisco Nexus поиск возможных ошибок конфигурации и сетевых неполадок будет несколько отличаться от стандартного набора процедур на классическом оборудовании уровня доступа.

Ключевые термины в рамках данной статьи:

  1. Fabric Interconnect (FI) - коммутаторы, используемые одновременно как сетевые устройства при передаче LAN и SAN трафика, так и как средство управления сетевыми и серверными настройками Cisco UCS с помощью Cisco UCS Manager. Коммутаторы FI не обмениваются трафиком серверов напрямую - соединения между FI необходимы для синхронизации параметров Active и Subordinate процессов UCS Manager.
  2. I/O Module (IOM/FEX) - модули расширения, устанавливаемые в UCS 5108 chassis для обеспечения связности между сетевыми адаптерами серверов и FI. Два модуля IOM подключаются без пересечения к двум FI для создания двух независимых путей для прохождения трафика от сетевых адаптеров.
  3. vNIC - виртуальные сетевые адаптеры, презентуемые операционной системе, установленной на сервере. Количество данных адаптеров будет определяться типом физического сетевого адаптера в сервере и количеством физических соединений между модулями IOM и коммутаторами FI.
  4. vEth - виртуальный Ethernet интерфейс на FI, который создается для каждого vNIC  (на одном из двух FI, A или B, если не была выбрана опция Fabric Failover, и на обоих, если опция применена). Физические интерфейсы FI, обращенные в сторону модулей IOM выступают в качестве высокоскоростных каналов приема трафика множества карт vNIC. FI "передает" трафик на соответствующий vEth после прочтения метки VNTag, которая устанавливается во фреймы при передаче между IOM и FI.

Cisco UCS Fabric Interconnect являются связующим звеном между серверами и остальным сетевым оборудованием центра обработки данных, а также систем хранения данных в некоторых вариантах подключения. Однако, имея внешнее сходство с коммутаторами Cisco Nexus, FI по умолчанию передает данные между своими интерфейсами не как традиционный коммутатор. Такой режим работы получил название End-host mode (EHM), и его рекомендуется использовать в большинстве вариантов подключения Cisco UCS. В режиме EHM передача фреймов от сетевых адаптеров серверов через FI на исходящие интерфейсы идет путем процедуры, называемой пиннинг (Pinning). Каждому виртуальному сетевому адаптеру при создании назначается путь через один из двух FI (Fabric A или Fabric B). Трафик данного vNIC направляется на соответствующий выбранному пути модуль IOM, от которого по одному из физических каналов поток достигает FI.

Для пересылки фрейма на соответствующий Uplink интерфейс коммутатор FI обращается к политике пиннинга для карты vNIC, от которой данный трафик поступил. В правиле пиннинга либо задан конкретный интерфейс коммутатора FI (Static pinning), либо правило определено как динамическое. В последнем случае FI выбирает один из доступных Uplink интерфейсов, на котором разрешен к передаче соответствующий VLAN (Dynamic pinning). При осуществлении пересылки никаких изменений, за исключением изъятия VNTag, с фреймом не производится.

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

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

Преимущество подобного принципа пересылки фреймов состоит в том, что EHM исключает необходимость использования STP на участке от FI до вышестоящих коммутаторов, при этом такие механизмы, как Port-Channel, по-прежнему можно использовать. Так как FI всегда направляют трафик в строго определенные Uplink интерфейсы, а также благодаря реализованному на коммутаторах FI механизму устранения повторов и зацикливаний фреймов (Deja Vu check), появление петель коммутации исключается.

При необходимости FI может быть переведен в режим классической коммутации (Switching mode), но в таком случае становится обязательным использование STP для устранения возможных петель коммутации и правила пиннинга более не применяются.
 

Поиск пути прохождения трафика по MAC-адресу

В случае возникновения проблем с производительностью UCS или при поиске неполадок на уровне сети одной из частых задач на стадии сбора предварительной информации становится поиск пути, по которому трафик от конкретного MAC-адреса (vNIC) идет через модули IOM и коммутаторы FI на вышестоящее оборудование.


Предположим ситуацию, в которой необходимо установить местоположение (шасси и слот с сервером) MAC-адреса 00:11:22:33:44:55, а также путь, по которому трафик от данного MAC-адреса поступает на вышестоящее оборудование. Процедура разбивается на несколько этапов, последовательность которых может варьироваться.

Необходимо определить:

  1. FI, обслуживающий данный MAC-адрес (vNIC).
    Cluster# connect nxos a
    Cluster-A(nxos)# show mac-address address 0011.2233.4455
    VLAN          MAC Address                Type             Age         Port

    -------------+--------------------------+--------------+-------------+----------
    100           0011.2233.4455             dynamic        10            veth901
    Cluster# connect nxos b
    Cluster-B(nxos)# show mac-address address 0011.2233.4455
    Total MAC Addresses: 0
  2. Местонахождение сервера с данной картой vNIC (номер шасси и слот с сервером)
    Cluster-A(nxos)# show interface veth901
    vethernet901 is up
       Bound Interface is Ethernet1/1/1
    В данном выводе присутствует запись о неком интерфейсе Ehternet1/1/1, номер которого на самом деле указывает позицию сервера (первая цифра – номер шасси, третья – номер слота с нужным сервером).
  3. Uplink на FI, через который трафик этого vNIC покидает UCS.
    Cluster-A(nxos)# show pinning interface veth901
    SIF Interface        Sticky       Pinned Border interface
    --------------------+------------+--------------------------------
    veth901              No           Eth1/5
  4. Интерфейс FI, на который этот трафик поступает от модуля IOM.
    Cluster-A(nxos)# show fex <chassis#> detail

    Fex Port                    State             Fabric Port
    Eth1/1/1                    Up                 Eth1/11
  5. Uplink интерфейс IOM-а.
    Cluster-A(nxos)# show interface fex-fabric
               Fabric          Fabric             Fex
    Fex        Port            Port State         Uplink
    1          Eth1/11         Active             1
  6. Интерфейс модуля IOM в сторону карты vNIC. Опционально можно также вывести диаграмму подключения в GUI и CLI UCS Manager.
    Cluster# connect iom <chassis#>
    fex-1# show platform software woodside sts (для FI 62xx и IOM 220x)
    Вывод данной команды отобразит в CLI диаграмму портов IOM в зависимости от его модели с расположением серверов согласно их слотам в шасси и соответствующие им внутренние интерфейсы модуля IOM.

Отобразим на рисунке найденные интерфейсы

В следующей статье по UCS будут рассмотрены полезные команды для поиска неполадок на пути прохождения трафика и рекомендации по избежанию распространенных проблем.

---

Антон Погребняк
инструктор-консультант учебного центра Fast Lane в России

СоздатьДля создания публикации, пожалуйста в систему