Ошибка сетевого интерфейса ucs

Номер статьи: 0000204

Обычно настройку производят сотрудники банка. Драйвера и инструкции можно скачать по ссылке

Краткая инструкция по установке и настройке МикроМодуля 

TCP/IP

УСТАНОВКА МИКРОМОДУЛЯ:

1) Распаковать архив MM260816_IP.zip  на рабочую станцию в произвольный каталог.

    Например – C:temp .

2) Перезагрузить рабочую станцию. Войти в систему под учетной записью администратора или пользователя с правами администратора.

3) Запустить файл custom.bat

4) Нажимать кнопку «Далее» до завершения установки.

5) Установка завершена. МикроМодуль установлен в каталог C:UCS .

 Замечание.

   Автоматически выполняется установка и регистрация в системе COM-обертки — UCS_MA.ocx.

 НАСТРОЙКА МИКРОМОДУЛЯ:

1) Открываем на редактирование файл micromgl.cfg в папке C:UCS c помощью блокнота или любого текстового редактора.

 2) В данном файле есть блок параметров [PROXY].

Он имеет вид:

 [PROXY]

TYPE=IP

ADDR=172.16.32.177:4001

FMT=H

TO=3200

 В переменной «ADDR» нужно изменить IP-адрес  172.16.32.177 на тот, который присвоен терминалу.

Важно: изменить нужно только адрес, номер порта ( :4001 ) оставляем неизменным.

 3) Сохраняем и закрываем файл.

ПРОВЕРКА СВЯЗИ С ТЕРМИНАЛОМ:

1) Перейти в каталог C:UCSBIN .

2) Запустить файл test.bat

3) На терминале должна начаться операция «Инкассация».

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

 Замечания.

• 1) В bat выполняется запуск утилиты ucs_dt.exe. Лог утилиты: файл stdout.txt.
      В данном файле, при необходимости, можно увидеть ID подключенного терминала (TID).
      См. строку вида: 

               2016-10-14 14.11.08 {000014AC} L[0:300] : UCS_DT: Recevd (3100199997310210)

               TID в данном примере: 19999731.

 2) При возникновении вопросов, в тех. службу необходимо передавать логи:

Лог микромодуля:  файл ucs_comm.log

Лог утилиты ucs_dt: файл stdout.txt .

Просмотры: 4096

Introduction

This document describes commands used to troubleshoot network connectivity, drops, and CRC errors within different UCS, FIs, IOMs, and VIC adapters.

 Prerequisites

 Requirements

  This document assumes that you have knowledge of these topics:

• Cisco Unified Computing Systems (UCS) Virtual Interface Card (VIC)
• Cisco UCS B-Series and C-Series servers
• Cisco UCS Fabric extender I/O Module (IOM)
• Cisco UCS Fabric Interconnect (FI)
• Cisco Unified Computing System Manager (UCSM)
• Cisco Unified Computing System Manager (UCSM) Command Line Interface (CLI)
• Cut-through and store-and-forward switches
• Stomps

Components Used

The information in this document is based on these software and hardware versions:

• Cisco UCS Manager version 2.x and later
• Cisco UCS 6200, 6300, and 6400 Series Fabric Interconnect
• Cisco UCS 2200, 2300 and 2400 Series Fabric extender I/O Module
• Cisco UCS 1200, 1300, and 1400 Series Virtual Interface Card (VIC)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

 Background Information 

The Cisco UCS Fabric Interconnect is a cut-through switch like the Cisco Nexus 5000 Series Switches. It forwards bad frames like good frames. Bad frames get dropped by the destination server or when they pass through a piece of network equipment that is not cut-through.

Note: A CRC check is performed at the end of the frame to determine whether or not a frame has become corrupted.  Some switches can drop the frame once they detect a frame is corrupted. Cut through switches make the forwarding decision before they can perform the CRC check. Because of these frames that fail, a CRC check can still be switched by a cut-through switch. Other switches like the N7K are store and forward switches. Store and forward switches look at the entire frame before they make a forwarding decision.  A store and forward switch would drop a frame that failed a CRC check. If you experience CRC errors on an interface, it does not mean that interface is the source of the problem. To understand the architecture (cut-through vs store-forward) of the switches in the topology is imperative. Many times, you need to work your way backward to the source of the CRC error. Refer to this article for more details about cut-through and store-and-forward switches: Cloud Networking Switches                                                                     

Reasons for Bad Frames and CRC Errors

Some of the reasons for when you get bad frames and CRC errors can be:

• Bad physical connection; transceiver, copper, fiber, adapter, port expander, and so on.
• MTU Violation
• Received bad CRC stomped from neighboring cut-through switch.

Forwarding Mode Behavior (Cut-Through or Store-and-Forward)

UCS Fabric Interconnects (similar to Nexus 5000) utilizes both cut-through and store-and-forward switching. Forwarding mode is dependent on the ingress and egress data rate, as shown in table 1.

Note: Cut-through switching can be performed only when the ingress data rate is equivalent to or faster than the egress data rate.

Table 1 — Forwarding Mode Behavior (Cut-Through or Store-and-Forward) for UCS Fabric Interconnect

Ingress/ Source Interface	Egress/ Destination Interface	Forwarding mode
10 Gigabit Ethernet	10 Gigabit Ethernet	Cut-through
10 Gigabit Ethernet	1 Gigabit Ethernet	Cut-through
1 Gigabit Ethernet	1 Gigabit Ethernet	Store-and-forward
1 Gigabit Ethernet	10 Gigabit Ethernet	Store-and-forward
10 Gigabit Ethernet	40 Gigabit Ethernet	Store-and-forward
40 Gigabit Ethernet	10 Gigabit Ethernet	Cut-through
40 Gigabit Ethernet	40 Gigabit Ethernet	Cut-through
FCoE	Fibre Channel	Cut-through
Fibre Channel	FCoE	Store-and-forward
Fibre Channel	Fibre Channel	Store-and-forward
FCoE	FCoE	Cut-through

Main Forwarding ASICs Commands for UCS FIs, IOMs and VIC Cards

Tables 2 and 3 show the different commands that can be run from the different management endpoints in UCS to determine where the drops are coming from and why they are occurring.

In addition to the ASIC specific commands mentioned in table 2, these commands can be run from UCS FI NXOS shell to look for errors at the receive direction of interfaces:

show interface counters errors

Table 2 — Main Forwarding ASICs commands for UCS FIs and IOMs

UCS FI / IOM	Main FW ASIC Name	Commands	Purpose
Cisco UCS Fabric Interconnects
1Cisco UCS 6100 Series (Gen 1 FIs 61xx) End-of-Life and End-of-Sale)	Gatos	(nxos)# show hardware internal gatos	This command shows Gatos ASIC internals and driver information. The third column shows how many ports/interfaces are mapped to each ASIC.
(nxos)#show hardware internal gatos all-ports	This command shows driver information for all ports +  front panel port to ASIC mapping.
Cisco UCS 6200 Series (Gen 2 FIs 62xx)	Carmel	(nxos)# show hardware internal carmel	This command shows the Carmel ASIC internals and driver information. 5th column shows how many ports/interfaces are mapped to each Carmel ASIC.
(nxos)# show hardware internal carmel all-ports	This command shows driver information for all ports and front panel physical ports to ASIC mapping.
2(nxos)# show hardware internal carmel crc	This command shows information if any frames were received or transmitted with CRC errors or stomped for all ports.
(nxos)# show platform fwm info asic-errors X	This command shows non zero Carmel drop reasons error registers (where X is the Carmel ASIC number from 0-4).
(nxos)# show platform fwm info pif e1/X | grep asic	Use this command and you can map your interface to the Carmel ASIC ID “global_asic_num” (where X is the interface number).
(nxos)# show platform fwm info pif e1/X | grep drop	This command shows the number of frames, and it filters for the drop counter for a certain interface (where X is the interface number).
(nxos)# show hardware internal carmel all-ports detail | egrep -i «Carmel port|crc|frame_error»	This command filters for CRC and frame error counters for all ports.
Cisco UCS 6300 Series (Gen 3 FIs 63xx)	Trident2 (Broadcom ASIC)	(nxos)# show hardware internal bcm-usd info port-info	This command shows the mapping between each physical port to a front port on the Broadcom ASIC and this mapping is different between 6332 and 6332-16UP FIs.
(nxos)# show hard internal interface indiscard-stats front-port X	This command shows port internal discard counters for a certain front port on the Broadcom ASIC after the mapping is done that uses the previous command.
Cisco UCS 6400 (Gen 4 FIs 64xx)	Homewood ASIC	FI # connect nxos (nx-os)# show hardware internal interface asic counters module 1	This command shows the reason for the forwarding drops if reported on the interface.
FI # attach module 1 module-1# show hardware internal tah counters asic 0	This command shows the different counters of information tha use ASIC library. There is only one ASIC within this UCS Fabric interconnect model so always ASIC number 0.
FI # attach module 1 module-1# show hardware internal tah drop-reason counters module 0	This command shows the drop reasons and number of dropped packets.
Cisco UCS 64108 Gen 4 FIs	Cisco ASIC Heavenly	FI # connect nxos (nx-os)# show hardware internal interface asic counters module 1	This command shows the reason for the forwarding drops if reported on the interface
FI # attach module 1 module-1# show hardware internal tah counters asic 0	This command shows the different counters of  information that use the ASIC library. There is only one ASIC within this UCS Fabric interconnect model so always ASIC number 0.
FI # attach module 1 module-1# show hardware internal tah drop-reason counters module 0	This command shows the reason for the forwarding drops if reported on the interface.
Cisco UCS Mini (6324 Fabric Interconnect)	Monticello ASIC	(nxos)# show hardware internal mtc-usd port-status	This command shows the status of the ports for the Monticello ASIC. (nxos)# show hardware internal inband-mtc ?              ASIC   Show Monticello ASIC information              info. Show Monticello inband driver info              stats.  Show Monticello inband driver statistics. Please note KRs mapping for the blades within UCS Mini follow a different Port Mapping compared to a chassis with UCS IOMs, refer to TAC for more details.
Cisco UCS Fabric extender I/O Modules (IOMs)
1Cisco UCS 2100 IOM (Gen 1)	Redwood	FI # connect IOM <chassis ID> Fex-1# show platform software redwood sts	This command shows the interface status of the HIFs and NIFs within the Redwood ASIC and which HIFs are used by each blade.
Cisco UCS 2200 IOM (Gen 2)	Woodside	FI # connect IOM <chassis ID> fex-1# show platform software woodside sts	This command shows the interface status of the HIFs and NIFs within the Woodside ASIC and which HIFs are used by each blade. Note: There are two numberings for the HIFs, one is used when you troubleshoot from the IOM (after you connect to IOM) and the other is used when you troubleshoot the same HIF and run the commands from UCSM nxos. For example, blade 1 uses HIF numbers 28-31. You can use these numbers after you connect to IOM and run the related commands to that HIF. While these correspond to Eth1/1/1 — 4 from UCSM nxos as per show FEX detail.
FI # connect IOM <chassis ID> fex-1# show platform software woodside rate	This command shows the packet rates for active HIF or NIF ports.
FI # connect IOM <chassis ID> fex-1# show platform software woodside rmon 0 [NIx/HIx]    For example, you can filter some error counters using grep for all NIFs as below: fex-1# show platform software woodside rmon 0 nif_all | egrep -i	This command shows the received and transmitted packet sizes for a certain HIF or NIF and packet types like unicast, broadcast, or multicast. The Diff column is useful while you do live troubleshooting as it resets after each time you run the command to show you if packets are incrementing when you run the command again. You can also check if the Diff column shows new packets for these: RX_CRC_NOT_STOMPED  RX_CRC_STOMPED  TX_FRM_ERROR
FI # connect IOM <chassis ID> fex-1# show platform software woodside drops 0 [NIx/HIx]	This command shows the drop counters for a certain NIF or HIF.
FI # connect IOM <chassis ID> fex-1# show platform software woodside oper	This command shows the administrative control, MAC, and physical status, in addition to detected SFPs within the NIFs.
FI # connect iom <chassis ID> fex-1# show platform software woodside sfp 0 ni0 fex-1# show platform software woodside sfp 0 ni1 fex-1# show platform software woodside sfp 0 ni2 fex-1# show platform software woodside sfp 0 ni3	This command shows the transceiver details within the woodside IOM NIF ports.
Cisco UCS 2300 IOM (Gen 3) and Cisco UCS 2300 IOM version 2 (UCS-IOM-2304V2)	Tiburon (Broadcom ASIC)	# connect IOM <chassis ID> Fex-1# show platform software tiburon sts	This command shows the interface status of the HIFs and NIFs within the Tibrun ASIC and which HIFs are used by each blade. Tibrun ASIC comes from the 2248 FEX which has 48 HIF ports, so for UCS, there are some unused ports on the ASIC (NI0-7 and HI0-9 are unused). Note: in regards to the 40G backplane ports within Gen 3 IOMs, HIF status can normally be with the 40 Gig primary ports marked as UP, and the 40 Gig member ports are marked Down.
# connect IOM <chassis ID> fex-1# show platform software tiburon rate	This command shows the packet rates for active HIF or NIF ports.
FI # connect IOM <chassis ID> fex-1# show platform software tiburon rmon 0 [NIx/HIx] For example, you can filter some error counters using grep for all NIFs as shown: fex-1# show platform software tiburon rmon 0 nif_all | egrep -i ‘crc|ni|stomp|pause|err’	This command shows the received and transmitted packet sizes for a certain HIF or NIF and packet types like unicast, broadcast, or multicast. The Diff column is useful while you do live troubleshooting as it resets after each time you run the command to show you if any new packets are coming when you run the command again. You can also check if the Diff column shows new packets for these:  RX_CRC_NOT_STOMPED  RX_CRC_STOMPED  TX_FRM_ERROR
Cisco UCS 2408 (fourth-generation I/O Module) «Summerville» UCS-IOM-2408	Sundown	FI # connect iom <chassis ID> fex-1# show hardware internal tah sts	This command shows the interface status of the HIFs and NIFs within the Tahoe ASIC and which HIFs are used by each blade.
fex-1# show hardware internal tah sts detail	This command shows the NXOS to HIF port mapping, link-state, and operational speed.
fex-1# show hardware internal tah counters asic 0 nxos-port ? <0-44> Nxos-port num 0-31 hif/35 bif/36-43 nif	This command shows the detailed per-port counters The detailed interface counters can be viewed by referring to the NXOS port number. NXOS Ports 0-31 correspond to 32 HIF Ports NXOS ports 36-43 corresponds to the 8 NIF ports.

1 End-of-Sale and End-of-Life Announcement for the Cisco UCS 6100 Series Fabric Interconnects and Cisco UCS 2100 Series IO Modules: Cisco UCS 6100 Series Fabric Interconnects

2 Mode details on some columns of show hardware internal carmel crc command:

• MM rx CRC = CRC on this link; Problem is L1 issue; Check eye height; shut, no shut; replace cable;
• MM Rx Stomp = STOMP on the remote switch; Go check the same output on the switch across this link;
• FI Rx Stomp = If MM Rx CRC and MM Rx Stomp are blank; L2/policy violation, most commonly MTU violation; Check QoS MTU settings.

Table 3 — The main commands to troubleshoot connectivity, drops, and CRC errors for Cisco UCS VIC cards.

UCS VIC Generation	Example of the VIC card model	Commands	Purpose
Cisco UCS 1200 VIC (Gen 2)	an example is the  1225 VIC, 1240 VIC, 1280 VIC, etc	Blades example: FI# connect adapter 1/1/1 adapter 1/1/1 # connect adapter 1/1/1 (top):1# show-log adapter 1/1/1 (top):1# attach-mcp adapter (mcp):1# uifportstatus adapter (mcp):3# dcem-macstats 0       <<<< Stats for port-1 adapter (mcp):3# dcem-macstats 1       <<<< Stats for port-2 adapter 1/1/1 (mcp):1# vnic adapter 1/1/1 (mcp):1# lifstats For Standalone C-Series UCS: # scope chassis /chassis # show adapter  (get the PCIe slot #) /chassis # connect debug-shell <PCIe slot #> (this command can only work when Server is powered on) adapter (top):1# attach-mcp adapter (mcp):1# uifportstatus	These commands can be run after connecting to the adapter of a Cisco UCS B or C series servers. The macstats command gives information about the status of the physical ports, packet sizes, and if there are any stomped or non-stomped frames received.
Cisco UCS 1300 VIC (Gen 3)	an example is the 1380 VIC
Cisco UCS 1400 VIC (Gen 4)	Example is: (VIC1440): PCIe based mLOM card for M5 blades (UCSB-MLOM-40G-04) ·        (VIC1480): PCIe based MEZZ card for M5 blades (UCSB-VIC-M84-4P) ·        (VIC1455): PCIe card for M5 Rack servers (UCSC-PCIE-C25Q-04) ·        (VIC1457): PCIe based mLOM card for M5 Rack servers (UCSC-MLOM-C25Q-04)	—  Check PCIe Link status adapter (top):1# attach-mcp adapter (mcp):1# pcie_links pp,pps type link config link status state 0,0   host gen3x16     gen3x16     UP adapter (mcp):2# exit —  Check Ethernet Link status adapter (top):2# attach-mcp adapter (mcp):1# uifportstatus       ASIC        Port   UIF Port State Speed   0   0    UP      25g   0   1    UP      25g   1   0    UP      25g   1   1    UP      25g adapter (mcp):2# exit —  Check Ethernet error counters adapter (top):3# attach-macd adapter (macd):1# macstats 0                DELTA                TOTAL DESCRIPTION                  112                  112 Rx good packets                  112                  112 Rx total received packets                14574                14574 Rx bytes for good packets                14574                14574 Rx bytes                  104                  104 Rx multicast frames <snip>	These commands can be run after connecting to the adapter of a Cisco UCS B or C series servers deployed with 4th Gen VIC adapter.

Known Issue for Clearing Carmel ASIC Interface Counters on 2nd Gen FI

The clear counters command can not take effect for Carmel ASIC due to this issue, and the workaround is to watch the counters if they increment:

«Cisco bug ID CSCuy10606

Clear Counters does not Clear «Show Hardware Internal carmel crc» on FI

Related Information

• Technical Support & Documentation — Cisco Systems
• Cisco bug ID CSCvj91316 : IOM 2300 series fabric extender (IOM) can corrupt packets:

  Cisco bug ID CSCvj91316

• Cisco bug ID CSCuy30027 : Need reload mechanism for 2348 FEX when CRC errors are seen [FEX2348 & IOM2304 share same internals & ASIC]:

  Cisco bug ID CSCuy30027

• Cisco UCS Manager CLI User Guides: Products Installation and Configuration Guides List

• Cisco Live- UCS 40G Fabric Interconnect 6332 Overview BRKCOM-20022: Cisco live
• CCNA Data Center DCICT 200-155 Official Cert Guide, egress ports and cut-through switches, page 172
• Cisco UCS Fabric Interconnect spec sheet:

UCS B Series Blade Servers 6200 Spec Sheet

UCS B Series Blade Servers 6332 Spec Sheet

UCS B Series Blade Servers 6454 Spec Sheet

Автор Сообщение

11 июн 2014, 07:11

R_KING

Еще вопрос — firmware и BIOS обновлять последовательно с повышением версии или можно на initial сразу накатить последнее обновление?

11 июн 2014, 10:48

R_KING

11 июн 2014, 11:07

R_KING

Неужели никто с таким модулем не сталкивался?

15 июн 2014, 23:06

real1st

18 июн 2014, 16:03

R_KING

19 июн 2014, 10:01

real1st

19 июн 2014, 10:30

R_KING

19 июн 2014, 11:47

Время на прочтение
14 мин

Количество просмотров 5.9K

Eсли вкратце, то технология позволяет виртуальным машинам получать прямой доступ до физических устройств pci на сервере с гипервизором. Однако, при использовании этой технологии перестают работать почти все полезные вещи, которые позволяет кластер vSphere: fault tolerance, high availability, снапшоты, vMotion и DRS с ним же.

Более того, когда виртуальная машина использует устройство напрямую, минуя гипервизор, то это устройство перестаёт быть доступно самому гипервизору. Например, если прокидывать сетевушку внутрь виртуалки через DirectPath I/O, то, да, ресурсы гипервизора на обработку трафика от виртуальной машины больше не используются — это хорошо. Плохо то, что прокинутую сетевушку сможет использовать только одна виртуалка. Технология, получается, весьма спорная, если не сказать больше — бесполезная. Но не всё так однозначно.

восхитительный Cisco UCS

Скажу откровенно, я довольно нудный тип, которого почти невозможно чем-то восхитить. Даже если это получилось, я не всегда захочу это показать, а там где захочу, то не всегда сумею. До того, как я познакомился с blade-системами Cisco, я, честно говоря, даже и не знал что фирма Cisco производит сервера. Оказалось, производит, да ещё такие, которыми я не устаю восхищаться.

Всю жизнь я работаю с серверами, немного пореже в руки перепадали blade-системы. Когда я первый раз увидел UCS manager то стало понятно, что нахрапом его не возьмёшь. Почему? хотя бы потому, что кнопочки вкл на сервере нет. Пока не сформирован service profile (профиль) из определённого набора конфигурационных параметров, то железка бесполезна.

В конфигурационных параметрах профиля из лезвия можно вылепить всё что угодно: параметры биос, последовательность загрузки, адреса ip-kvm, hba, версии прошивок, параметры и mac-адреса сетевушек (iscsi и обычных). Всё это сделано очень гибко, с удобной иерархией и возможностью задавать пулы массово изменяющихся параметров, таких как адреса и маки. Соответственно, пока всё это не изучено, то лезвие запустить не получится.

сетевая часть лезвий

О конфигурировании я здесь рассказывать не буду. По этой теме у фирмы Cisco, как и для всего остального, есть довольно внятная документация. Да и в интернете, в том числе на хабре, об этом написано некоторое количество статей. Я хотел бы остановиться на сетевой части blade-систем Cisco UCS. Сетевая часть здесь тоже особенная. Дело в том, что в серверах-лезвиях отсутствуют сетевые интерфейсы. Как же тогда лезвия работают с сетью? всё таки сетевой адаптер в каждом лезвии есть: это Virtual Interface Card (vic).

В комплексе с IO Module (iom) в корзине эти две железки позволяют создавать реальным серверам виртуальные сетевые интерфейсы в необходимом количестве. Оно, конечно, ограничено, но ограничение довольно большое — должно хватить всем. так зачем же нам сотня сетевых интерфейсов на лезвии? незачем, если мы не используем виртуализацию. Вот тут-то настаёт время Валеры вспомнить о бесполезном DirectPath I/O, который выступает теперь уже совсем в другом свете.

Во второй части документации от vSphere, внезапно, обнаруживается, что DirectPath I/O на Cisco UCS поставляется с блекджеком и шлюхами работает и со снапшотами, и с fault tolerance, и с high availability, и с vMotion за которым неразлучно следует DRS. «Клёво!» — подумал я, когда прочитал об этом. «Сейчас быстро сделаю, будет всем щастье» и обломался. Ни в документации Cisco, ни в документации VMWare я не нашёл чего-то, похожего на инструкцию, как все это сделать. из всего, что мне удалось найти было лишь что-то, очень удалённо напоминающее попытку сделать пошаговую инструкцию. Этот сайт уже сдох, поэтому ссылка на веб-архив.

ещё немного воды

Я решил написать подробный мануал в первую очередь — для себя, чтобы, столкнувшись с задачей второй раз, ничего не забыть, быстро и успешно всё повторить. Во-вторую очередь для всех остальных, хотя я прекрасно осознаю, что большинство читателей, и, возможно, я и сам в будущем, никогда не встретимся с Cisco UCS. Спасибо импортозамещению в том числе.

Для того, чтобы успешно работать с DirectPath I/O на UCS нужно хорошо понимать как работает virtual distributed switch (vds) у vSphere. Усли понимания нет или запустить его не удалось, и вы думаете, что выполнив этот мануал удасться запустить всё, что здесь описывается — это ошибка. Запустить, может, и получится, но потом очень легко сломается вследствие неверных действий из-за непонимания.

То же самое относится к UCS manager. Описывать работу с vds, как и большую часть конфигурирования UCS manager в рамках данной статьи я не буду. Инструкций у VMWare, Cisco, разных how-to, вопросов-ответов на форумах и прочего в интернет более чем достаточно.

интеграция ucsm и vcsa

Для того, чтобы ucsm мог создать vds в vCenter Server Appliance (vcsa), в который я буду загонять виртуалки, в поcледний нужно разрешить доступ через добавление ключа:

1. открываю ucsm → вкладка vm → filter: all → лкм по vmware → export vCenter extension, указываю какую-нибудь директорию, куда упадёт файл cisco_ucs_vmware_vcenter_extn.xml. Вообще-то я не очень люблю делать скриншоты, но такой железкой приятно рисануться:
   
2. теперь нужно импортировать это расширение в vcsa. VMWare утверждает, что все операции с vCenter начиная с версии 5.1 можно делать через веб-клиент. Может быть это и так, но каким образом импортировать этот файлик через веб-клиент я не нашёл ни в версии 5.1, ни в 5.5, ни в 6.0.

поэтому открываю vmware vsphere client версии 6.0 → верхнее меню → plugins → manage plugins → на пустом месте открывшегося окна со списком плагинов нажимаю пкм → new plug-in... → browse... → cisco_ucs_vmware_vcenter_extn.xml → register plug-in.

после успешной регистрации в списке должен появиться новый плагин Cisco-UCSM-xxx, где вместо xxx будет ключ, которому я сделал обфускацию в скриншоте выше.

теперь vcsa готов принимать команды от ucsm.

vds для vm-fex

vm-fex работает через virtual distributed switch, который нужно создавать и конфигурировать в ucsm, а последний в свою очередь применяет эту конфигурацию к vcsa через интеграцию, описанную в предыдущей части. Вся работа в этой части будет происходит в ucsm во вкладке vm, поэтому я не буду в каждом пункте ссылаться на неё.

1. пкм по vmware → configure vCenter → в поля name, description и hostname (or ip address) записываю данные своего vcsa: ares, gallente tackler, 10.7.16.69 → два раза next → разделы folders и datacenters пропускаю → finish;
2. пкм на ares → create datacenter → в поля name и description записываю данные своего datacenter, который уже создан в vcsa: dc → next → раздел folders пропускаю → finish;
3. пкм на dc → create folder → в поля name и description записываю данные папочки, в которой будет vds: ucs → next → раздел DVSs пропускаю → finish;
4. пкм на ucs-main → create DVS → в поля name и description записываю данные своего vds: ucs-main → OK → admin state: enable.
5. vds готов, теперь создам port profiles. По сути это то же самое, что и distributed port group, но в терминологии cisco. У меня их всего две штуки: один профиль транковый, где разрешены все виланы, в другом нетэгированный вилан с менеджмент-сетью для виртуальных машин, гостевые системы которых по каким-то причинам не могут тегировать трафик:
   1. пкм port profiles → в поля name и description записываю данные профиля vm-mgmt-ucs → host network io performance: high performance → в списке VLANs выбираю одну радиокнопку в третьей колонке напротив вилана mgmt;
   2. тоже самое делаю для транкового порта vm-trunk-ucs. Только вместо выбора радиокнопки, в первой колонке отмечаю галочками все виланы. подразумевается, что необходимые виланы в ucsm уже созданы;
   3. теперь надо сделать, чтобы эти два профиля попали в vds. Лкм по одному из них, выбираю вкладку profile clients → зелёный [+] справа → name: all, datacenter: all, folder: all, distributed virtual switch: all. Со вторым профилем то же самое. Должно получиться примерно так:
      
      через небольшое время этот ucs-main появился в vcsa. Если этого не произошло, то стоит заглянуть во вкладку fsm — скорее всего, там будет написана причина.

лезвия для гипервизоров

Как я уже упоминал в начале, для того, чтобы запустить лезвие, нужно навесить на него профиль. Чтобы это сделать, профиль нужно сначала создать. Создание профилей для серверов — это не цель данного документа, поэтому я подразумеваю, что всё необходимое для формирования профиля уже есть. Затрагивать я буду только то, что имеет отношение к vm-fex, без чего DirectPath I/O не заработает. На каждом лезвии я буду делать по четыре статических сетевых интерфейса. Все четыре будут привязаны к одной фабрике с failover на вторую. Половина лезвий будет работать с фабрикой а, другая половина, соответственно, с b.

Первый интерфейс останется в обычном vSwitch. Второй интерфейс будет подключен в обычный vds. Третий интерфейс будет подключен в ucs-vds. вообще-то участие интерфейса в виде uplink в ucs-vds смахивает на атавизм, т.к. от него ничего не зависит. Но если этого не сделать, то проброс виртуальных интерфейсов не работает — я проверял Четвёртый интерфейс я планировал подключить в дополнительный vds в виде софтового cisco nexus 1000v, чтобы можно было более гибко конфигурировать порты виртуалок, но руки до него пока не дошли.

Все интерфейсы я добавляю в свичи без stand by на уровне VMWare, т.к. failover реализован на уровне UCS. Замечу, что для обычных лезвий или серверов с двумя интерфейсами, не резервируемыми на уровне подключения, такая схема неверна. Не стоит её бездумно повторять на не-UCS.

создание adapter policy

adapter policy — это сборник настроек для каждого сетевого интерфейса в сервере. Первый adapter policy будет для четырёх статических интерфейсов гипервизора, а второй для динамических.

1. вкладка servers → policies → root → пкм по adapter policies → create ethernet adapter policy → name: nn-vmw, resources:
   1. transmit queues: 4, ring size: 4096;
   2. receive queues: 4, ring size: 4096;
   3. completion queues: 8, interupts: 16;
   4. переписывать options лениво, поэтому скриншот:
      
2. снова вкладка servers → policies → root → пкм по adapter policies → name: nn-vmw-pt, resources:
   1. transmit queues: 8, ring size: 4096;
   2. receive queues: 8, ring size: 4096;
   3. completion queues: 16, interupts: 32;
   4. остальное то же самое. очередей больше в два раза, потому что для работы проброса динамических интерфейсов нужно минимум по 8 очередей. Источник в подтверждение привести пока не могу. Если снова найду, то добавлю.

создание vnic template с группировкой

Для того, чтобы на лезвии были сетевые интерфейсы, нужно создать их шаблоны. Шаблоны можно использовать напрямую в каждом профиле, а можно сгруппировать через lan connectivity policy. Во втором случае для каждого серверного профиля или шаблона профиля достаточно будет лишь указать нужный lan connectivity policy, который сделает всё необходимое.

Создаю два шаблона для статических интерфейсов. Один шаблон будет работать с фабрикой a с failover на b, второй наоборот.

1. вкладка lan → policies → root → пкм по vNIC templates → create vnic template → name: trunk-a → fabric id: a, enable failover → target: adapter и vm (внимание! поменять эту настройку в готовом шаблоне уже не получится) → template type: updating template → отмечаю галочками все виланы → в mac pool выбираю предварительно созданный пул мак-адресов → connection policies: dynamic vnic. Второй шаблон trunk-b такой же за исключением fabric id: b.
2. под группировкой я подразумеваю lan connectivity policy: вкладка lan → policies → root → пкм по lan connectivity policies → create lan connectivity policy → name: esxi4-trunk-a кнопкой [+] add далее добавляю 4 сетевых интерфейса:
   1. ставлю галочку напротив user vnic template и заполнять остаётся всего три поля: name: nic0, vnic template: выбираю созданный в предыдущем пункте trunk-a, adapter policy: nn-vmw, созданный ранее;
   2. повторяю ещё три раза для name: nic1..nic3;

Повторяю весь раздел для name: esxi4-trunk-b с привязыванием соответственно к фабрике b.

создание bios policy

bios policy — это настройки bios: то что можно изменить, зайдя в bios setup. Нет смысла открывать консоль и заходить туда на каждом лезвии, если всё это можно сделать централизованно сразу для пачки лезвий.

1. вкладка servers → policies → root → пкм по bios policies → create bios policy:
   1. name: fex;
   2. не лишним будет поставить галочку напротив reboot on bios settings change;
   3. так же я обычно ставлю радиокнопку reset напротив resume on ac power loss — сервер же;
2. в разделе processor:
   1. virtualization technology (vt): enabled;
   2. direct cache access: enabled;
3. в разделе intel direct io все радиокнопки в состояние enabled;
4. к работе DirectPath I/O это не относится, но ещё мне нравится включать boot option retry в разделе boot options;
5. это обязательный минимум для работы DirectPath I/O. Остальное по необходимости, или сразу жать Finish.

Другие настройки можно сменить уже после создания полиси.

создание service profile

Из него формируется то, что будет вешаться непосредственно на лезвие и в соответствии с чем железка будет сконфигурирована. Серверный профиль можно сделать напрямую, а потом клонировать. Но правильней делать его из шаблона, настройки которого будут наследоваться и меняться на всех зависимых серверных профилях. Шаблон серверного профиля включает в себя массу настроек, которые здесь не рассматриваются, подразумевая, что они уже выполнены без моей помощи. Здесь я рассмотрю только то, что нужно для работы DirectPath I/O.

Вкладка servers → service profile templates → пкм по root → create service profile template. name: esxi4-a, type: updating template. Вторую настройку нельзя будет сменить на готовом шаблоне, поэтому очень важно на забыть установить её при создании.

В разделе networking выставляю dynamic vnic connection policy в значение create a specific dynamic vnic connection policy. number of dynamic vnics. В соответствии с табличкой в мануале значение по-умолчанию у меня здесь 54: модель ucs у меня 6296, модели iom во всех корзинах 2208, значит в соответствии с последней строчкой максимальное число vif может быть 58 для mtu 9000 и 58 с mtu 1500, всего 116. Данная информация соответствует действительности лишь отчасти.

Очевидно, что индус, который писал мануал не до конца разобрался в вопросе. Правда в том, что если полиси адаптеров содержат завышенные значения количества очередей и ring size, то 54 динамических интерфейса лезвие переварить не может. От завышенных значений я отказаться не могу — на серверах будет огромная нагрузка по трафику, гораздо больше 10 гигабит на порт (о том как это так — напишу дальше). Методом математического тыка значений в полисях адаптеров и количества vif я выяснил, что в моём случае здесь успешно выставляется число 33 и остаётся небольшой запас для дополнительных статических интерфейсов. Вдруг понадобится.

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

adapter policy: nn-vmw-pt, protection: protected. Это значит, что динамические интерфейсы, которые ucsm создаст для DirectPath I/O на каждом лезвии будут равномерно разбросаны по обоим фабрикам. Не могу вспомнить, почему я решил так сделать. Возможно, просто интуиция. Возможно также, это неверно и динамические интерфейсы стоит прибивать к той же фабрике, что и статические. Время покажет. Переделать недолго, несложно и виртуалки для переделки останавливать не придётся.

how do would you like to configure lan connectivity?: use connectivity policy. Вот тут-то я и воспользуюсь группировкой шаблонов сетевых интерфейсов, которая создавалась до этого. lan connectivity policy: esxi4-trunk-a.

Раздел vnic/vhba placement проще показать скриншотом:

В разделе operational policies нужно выставить созданный недавно bios policy. На этом можно создание шаблона серверного профиля завершаю, finish.

Из шаблона теперь можно создать непосредственно сам профиль. Вкладка servers → service profile templates → root → пкм по esxi4-trunk-a → create service profiles from template. naming prefix: test, name suffix starting number: 1, number of instances: 1. это значит что из шаблона будет создан единственный профиль c именем test1.

Теперь нужно ассоциировать профиль с лезвием. Вкладка servers → service profiles → root → пкм по test1 → change service profile association. Выбираю select existing server и в появившейся табличке выбираю само лезвие, который нужно ассоциировать с созданным профилем. После нажатия на кнопку ok будет вопрос-предупреждение от ucsm, что лезвие ребутнётся, делаем? отвечаю утвердительно и жду, пока ucsm подготовит лезвие к работе.

Пока ucsm готовит лезвие, стоит обратить внимание на вкладку network серверного профиля. Выглядеть она должна примерно так:

после успешного выполнения весь этот раздел необходимо повторить для создания второго шаблона и профиля, который будет работать с фабрикой b вместо фабрики a.

женитьба

Женитьбой в автомобилестроении называют момент соединения силового агрегата с кузовом. Это название для данного раздела тоже отлично подходит.

Процесс установки esxi я пропущу. Это очень просто и совсем неинтересно. Напишу лишь, что esxi я ставил из образа Vmware-ESXi-5.5.0-2068190-custom-Cisco-5.5.2.3.iso, который качал здесь, а потом обновлял до ESXi550-201512001.zip отсюда. В результате, по утверждениям vCenter, получилась версия 5.5.0-3248547. Как вариант, можно сразу установить Vmware-ESXi-5.5.0-3248547-Custom-Cisco-5.5.3.2.iso (ссылка) — результат должен быть тот же. Хотя установочный образ esxi специально подготовлен для серверов Cisco, он почему-то не включает в себя драйвер cisco virtual machine fabric extender (vm-fex).

Его нужно скачивать отдельно: нужен файл cisco-vem-v161-5.5-1.2.7.1.zip из ucs-bxxx-drivers-vmware.2.2.6c.iso. Этот драйвер надо залить в гипервизор и установить: esxcli software vib install -d /tmp/cisco-vem-v161-5.5-1.2.7.1.zip. Кстати говоря, все вышеприведённые ссылки качаются свободно, нужно только зарегистрироваться. Единственное, что нельзя скачать свободно, — это vCenter. Я использую VMware-VCSA-all-6.0.0-3634788.iso (он же 6.0u2), но так же имеется успешный стенд с VMware-VCSA-all-6.0.0-2800571.iso. Установку vcsa, добавления в него гипервизоров и создании кластеров я так же пропущу.

Стоит, наверное, аргументировать почему я выбрал vcsa версии 6 и esxi версии 5.5. веб-клиент у всех предыдущих vcsa почти полностью написан на flash. его тормоза ещё можно было бы пережить, но для доступа к консоли виртуалок требуется плагин vmware, работающий через npapi, который chrome похоронил с песнями и плясками в сентябре 2015. Учитывая недоступность некоторых функций в vmware vsphere client, запускать его совсем не хочется, оставаясь на веб-клиенте. В шестой версии vcsa с этим стало всё хорошо, можно спокойно пользоваться.

Что касается esxi, то в версии 5.1 я наступил на весьма неприятный баг, который не давал менять конфигурацию iscsi через host profile. Без профилей, после того, как их уже распробовал, жить очень грустно. Кроме того, в vds на 5.5 появились фильтры, что весьма приятно. С их помощью можно реализовать функциональность, для которой раньше приходилось ставить cisco nexus 1000v. С esxi версии 6.0 тоже не сложилось: в ucs-bxxx-drivers-vmware.2.2.6c.iso/VM-FEX/Cisco/VIC/ESXi_6.0/README.html написано: Not supported.

Приступим к свадьбе. В одном из прошлых разделов я создал vds, который уже должен быть в vcsa. Дело за малым: добавить один из четырёх интерфейсов лезвия в vds. И тут меня ждал жестокий облом. Один из сетевых интерфейсов гипервизора должен быть связан с с одним из аплинков vds. Вот как выглядит список аплинков здорового человека vcsa версии 5.5:

А вот список аплинков курильщика vcsa версии 6.0:

Разумеется, связать сетевой интерфейс с несуществующим аплинком невозможно, о чём красноречиво сообщает окошко с ошибкой:

Это было очень обидно. Мой вопрос на эту тему в supportforums.cisco.com проигнорировали, а на communities.vmware.com в ответ получил выступление какого-то клоуна из группы vmware employees, который совсем не разбирался в теме, но зачем-то задавал тупые вопросы. На vcsa версии 5.5 очень не хотелось по причине выпиленного npapi из chrome, поэтому пришлось копнуть глубже. Оказалось, что все аплинки у vds, созданный ucsm на месте, а вот веб-клиент их показать почему-то не может.

Проблема решилась добавление хоста в vds через vmware vsphere client. Единственное, что немного омрачило результат — не получалось выбрать конкретный аплинк, к которому привязывался сетевой интерфейс. Но и эта проблема в итоге решилась добавлением esxi в vds через host profile. Вероятно, возможен ещё один способ добавления esxi в vds — через консольный клиент или sdk, но я этот способ не пробовал, поэтому не могу достоверно утверждать, работает ли.

Как я уже упоминал выше, для работы DirectPath I/O достаточно добавить один сетевой интерфейс в vds, созданный ucsm. Назначить esxi адрес в этом vds необходимости нет. Более того, это вредно ввиду ограниченности количества динамических интерфейсов. Поэтому в моей конфигурации один сетевой интерфейс у esxi живёт в обычном vSwitch для того, чтобы в аварийной ситуации или при недоступности vcsa, связность до esxi можно было восстановить, а два других в обычном vds версии 5.5.

Но вернёмся к нашим баранам запуску DirectPath I/O на виртуальной машине. Единственное, что осталось сделать — это выключить виртуальную машину, мигрировать сеть в ucs-vds, убедиться что сетевой адаптер виртуальной машины — это vmxnet3, поставить галочку reserve all guest memory в настройках памяти и запустить. Результат не заставит себя ждать. В информации о сетевой карте в строке DirectPath I/O появится значение Active. В ucsm это будет выглядеть так:

bond. james bond. или нет?

Хочу показать как выглядит виртуалка, которая отдаёт примерно 14 гигабит/с. Разумеется, происходит это с участием irqbalance и с правильно настроенным линуксом:

top - 13:35:03 up 9 days, 17:41,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 336 total,   1 running, 334 sleeping,   0 stopped,   1 zombie
Cpu0  :  1.4%us,  8.5%sy,  0.0%ni, 90.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  1.0%us,  7.8%sy,  0.0%ni, 91.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  1.4%us,  4.4%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.3%us,  8.1%sy,  0.0%ni, 90.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  2.5%us,  9.3%sy,  0.0%ni, 81.4%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Cpu5  :  1.8%us,  9.5%sy,  0.0%ni, 83.6%id,  0.0%wa,  0.0%hi,  5.1%si,  0.0%st
Cpu6  :  1.8%us,  6.6%sy,  0.0%ni, 86.3%id,  0.0%wa,  0.0%hi,  5.2%si,  0.0%st
Cpu7  :  2.6%us,  8.8%sy,  0.0%ni, 83.9%id,  0.0%wa,  0.0%hi,  4.7%si,  0.0%st
Cpu8  :  2.9%us,  8.3%sy,  0.0%ni, 83.3%id,  0.0%wa,  0.0%hi,  5.4%si,  0.0%st
Cpu9  :  1.0%us,  8.0%sy,  0.0%ni, 91.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  1.3%us,  8.9%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu11 :  1.3%us,  9.3%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.7%us,  3.1%sy,  0.0%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  1.1%us,  5.3%sy,  0.0%ni, 88.0%id,  0.0%wa,  0.0%hi,  5.6%si,  0.0%st
Cpu14 :  2.9%us,  8.7%sy,  0.0%ni, 81.9%id,  0.0%wa,  0.0%hi,  6.5%si,  0.0%st
Cpu15 :  1.8%us,  9.0%sy,  0.0%ni, 82.4%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Mem:   8059572k total,  3767200k used,  4292372k free,   141128k buffers
Swap:  4194300k total,        0k used,  4194300k free,   321080k cached

Такое положение вещей как-бэ намекает, что можно позволить себе и больше. Да, действительно можно. Вопрос в том как отдавать. В фабриках ucs (они же свичи) не предусмотрена агрегация линков с серверами. Городить много интерфейсов и делать ecmp? Всё гораздо проще, делать вообще ничего не надо. Любой виртуальный интерфейс лезвия Cisco UCS имеет такое же ограничение пропускной способности на котором корзина подключена к фабрикам. А вот корзина уже подключается к фабрикам как раз через port-channel максимум восьми десятигигабитных линков в каждую фабрику. Итого, теоретический предел одного сетевого интерфейса — это 80 гигабит/с.

полезные ссылки

• кусок мануала о DirectPath I/O от VMWare;
• DirectPath I/O на Cisco UCS через vm-fex;
• cisco customer image for vmware esxi 5.5u2 install cd;
• cisco customer image for vmware esxi 5.5u3a install cd;
• скачивание патчей для esxi;
• драйвер cisco vm-fex для esxi;
• cisco vm-fex best practices;
• неприятный и неисправленный баг в esxi 5.1;