Запускаем DirectPath I-O на Cisco UCS через vm-fex для vSphere

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;

Автор: kelevra

Источник