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

Якщо коротко, то технологія дозволяє віртуальним машинам одержувати доступ до фізичних пристроїв
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
), в який я буду заганяти виртуалки, в останній потрібно дозволити доступ через додавання ключа:
  1. відкриваю
    ucsm
    → вкладка
    vm
    filter: all
    лкм
    на
    vmware
    export vCenter extension
    , вказую яку-небудь директорію, куди впаде файл
    cisco_ucs_vmware_vcenter_extn.xml
    . Взагалі-то я не дуже люблю робити скріншоти, але такий залізком приємно рисануться:
    ucs manager virtual machines
  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
      network host io performance
      :
      high performance
      → у списку
      Vlan
      вибираю одну радіокнопку у третій колонці напроти віла
      mgmt
      ;
    2. теж саме роблю для транкового порту
      vm-trunk-ucs
      . Тільки замість вибору радіокнопки, у першій колонці наголошую галочками всі виланы. мається на увазі, що необхідні виланы
      ucsm
      вже створені;
    3. тепер треба зробити, щоб ці два профілю потрапили в
      vds
      . Лкм по одному з них, вибрати вкладку
      profile clients
      → зелений
      [+]
      праворуч →
      name
      :
      all
      ,
      datacenter
      :
      all
      ,
      folder
      :
      all
      ,
      virtual distributed switch
      :
      all
      . З другим профілем те ж саме. Повинно вийти приблизно так:
      vds ports
      через невеликий час цей
      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
      ліниво, тому скріншот:
      adapter 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 change settings
      ;
    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
простіше показати скріншотом:
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 interface profile association
. Вибираю
select existing server
і з'явилася табличці вибираю саме лезо, який потрібно асоціювати з створеним профілем. Після натискання на кнопку
ok
буде питання-попередження від
ucsm
, що лезо ребутнется, робимо? відповідаю ствердно і чекаю, поки
ucsm
підготує лезо до роботи.
Поки
ucsm
готує лезо, варто звернути увагу на вкладку
network
серверного профілю. Виглядати вона повинна приблизно так:
server profile
після успішного виконання весь цей розділ необхідно повторити для створення другого шаблону і профілю, який буде працювати з фабрикою
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</code версії> <code>6
та
esxi</code версії> <code>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</code версії> <code>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</code версії> <code>5.5
:
vcsa 5.5 uplinks
А ось список аплінк курця
vcsa</code версії> <code>6.0
:
vcsa 6.0 uplinks
Зрозуміло, зв'язати мережевий інтерфейс з неіснуючим аплинком неможливо, про що красномовно повідомляє віконце з помилкою:
error
Це було дуже прикро. Моє запитання на цю тему в
supportforums.cisco.com
проігнорували, а на
communities.vmware.com
у відповідь отримав виступ якогось клоуна з групи
vmware employees
, який зовсім не розбирався в темі, але навіщо-то ставив тупі питання. На
vcsa</code версії> <code>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
з'явиться значення
Активний
. В
ucsm
це буде виглядати так:
ucs virtual machines
bond. james bond. чи ні?
Хочу показати як виглядає виртуалка, яка віддає приблизно 14 гігабіт/с. Зрозуміло, це відбувається з участю
irqbalance
з правильно налаштованим лінуксом:
top - 13:35:03 up 9 days, 17:41, 2 users, load average: 0.00, 0.00, 0.00
Завдання: 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 мегабіт/с.
корисні посилання
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.