Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Диплом (диплом).docx
Скачиваний:
74
Добавлен:
23.03.2015
Размер:
7.14 Mб
Скачать

2.2 Мережі та віртуалізація

З впровадженням технологій віртуалізації і появою віртуальних машин виникла очевидна потреба в комутації трафіку між ними. З цією метою були розроблені віртуальні комутатори, такі як VMware vSwitch або Cisco Nexus 1000V - в англомовній літературі їх зазвичай називають Virtual Embedded (або Ethernet) Bridge (VEB). За своїм функціоналом вони відповідають звичайним комутаторів Ethernet, тільки виконані програмно на рівні гіпервізора. Трафік між віртуальними машинами в рамках «свого» сервера комутується локально, не виходячи за його межі (див. Рис. 2.1). А прочий трафік (із зовнішніми МАС-адресами) - направляється у зовнішню мережу.

http://www.osp.ru/FileStorage/ARTICLE/ZHurnal_setevyh_reshenij_LAN/2013-02/02_13/13137328/ZHurnal_setevyh_reshenij_LAN_1_(138).png

Рис. 2.1 Комутація трафіку віртуальних машин всередині сервера (VEB) і винесення цього процесу в зовнішній комутатор (VEPA).

Віртуальні комутатори можуть бути модульними, як, наприклад, вже згаданий Cisco Nexus 1000V. Він складається з двох основних компонентів: модуль Virtual Ethernet Module (VEM) функціонує на базі гіпервізора і відповідає за комутацію трафіку віртуальних машин, а модуль управління Virtual Supervisor Module (VSM) може бути встановлений на зовнішньому сервері. Один комутатор Nexus 1000V здатний підтримувати безліч модулів VEM на фізичних серверах. А для управління всім цим господарством (вирішення завдань конфігурування, моніторингу, діагностики та ін) досить одного модуля VSM. По суті, все як у звичайному модульному пристрої: VEM - це аналог лінійної карти, а VSM - плати управління.

У віртуальних комутаторів VEB є свої переваги: ​​локальна комутація трафіку всередині сервера не приводить до будь-якої додаткової навантаженні на мережу, до того ж для реалізації такої комутації не потрібно зовнішнє обладнання. Дане рішення відрізняється невисокою вартістю і забезпечує мале значення затримки. Але у нього є і серйозні мінуси: до віртуальних комутаторів далеко не завжди застосовні традиційні прийоми конфігурування та управління, а курсує через них трафік неможливо відстежити звичайними засобами моніторингу. Такі комутатори часто перебувають у віданні фахівців, що відповідають за сервери, тоді як за всі інші (апаратні) комутатори відповідають мережеві адміністратори, що створює проблеми для цілісного управління всією мережею. Крім того, підтримка роботи віртуальних комутаторів означає додаткове завантаження процесорів сервера.

Інший підхід до комутації трафіку віртуальних машин складається у винесенні цього процесу в зовнішні комутатори. Для його реалізації були розроблені кілька технологій, дві основні описані в документах IEEE 802.1Qbg (Edge Virtual Bridging) і 802.1BR (Bridge Port Extension), які на даний момент знаходяться у фінальній стадії затвердження. Розробка першої із зазначених технологій, в основу якої покладено механізм Virtual Ethernet Port Aggregator (VEPA), була ініційована компанією HP. Технологія 802.1BR народилася в Cisco Systems. Спочатку її стандартизацією займалася група 802.1Qbh, але потім було вирішено виділити цю технологію в окремий стандарт 802.1BR, щоб дистанціювати її від стандартів серії 802.1Q, «відповідальних» за тегування трафіку Ethernet.

Як приклад реалізації технології VN-Tag розглянемо так звані віртуальні інтерфейсні карти (Virtual Interface Card, VIC) компанії Cisco.

http://www.osp.ru/FileStorage/ARTICLE/ZHurnal_setevyh_reshenij_LAN/2013-02/02_13/13137328/ZHurnal_setevyh_reshenij_LAN_3_(592).png

Рис. 2.2. Приклад реалізації технології VN-Tag з використанням віртуальних інтерфейсних карт (Virtual Interface Card, VIC) компанії Cisco.

Насправді, це цілком реальний мережевий адаптер з портами 10 GbE і підтримкою технології FCoE, але спеціально підготовлений до роботи в віртуалізованих середовищах. На його базі можуть бути сформовані до 256 віртуальних інтерфейсів vNIC, які, відповідно до концепції виносів, стають логічним продовженням зовнішнього комутатора Ethernet. У результаті кожної віртуальній машині виділяється віртуальний порт на фізичному комутаторі (див. Рис. 2.2), який бере на себе турботу не лише про комутації трафіку, а й про дотримання встановлених правил безпеки, якості обслуговування і пр.

Підтримка продуктами VIC технології VMware VMDirectPath дозволяє істотно підвищити продуктивність і знизити затримку мережевої взаємодії віртуальних машин. Вона робить можливим пряму взаємодію між віртуальними інтерфейсами vNIC і віртуальними машинами в обхід гіпервізора (див. Рис. 2.3).

http://www.osp.ru/FileStorage/ARTICLE/ZHurnal_setevyh_reshenij_LAN/2013-02/02_13/13137328/ZHurnal_setevyh_reshenij_LAN_4_(3220).png

Рис. 2.3 Різні режими взаємодії між віртуальними інтерфейсами vNIC і віртуальними машинами при використанні віртуальних інтерфейсних карт (Virtual Interface Card, VIC) компанії Cisco.

При необхідності можна використовувати механізм VMware VMotion, наприклад, для динамічного розподілу навантаження.

Мережеві адаптери нового покоління, оптимізовані для роботи в віртуалізованих середовищах, можуть не тільки направляти трафік віртуальних машин у зовнішню мережу, але й самостійно його комутувати. Прикладом такого продукту служить адаптер Brocade Fabric Adapter (FA) 1860, який містить один або два фізичних порти: 10 Гбіт / с (Ethernet, FCoE) або 16 Гбіт / с (Fibre Channel). При використанні цього адаптера можливі три варіанти комутації трафіку віртуальних машин (див. Рис. 2.4).

http://www.osp.ru/FileStorage/ARTICLE/ZHurnal_setevyh_reshenij_LAN/2013-02/02_13/13137328/ZHurnal_setevyh_reshenij_LAN_5_(682).png

Рис. 2.4 Різні варіанти комутації трафіку віртуальних машин при використанні адаптера Brocade Fabric Adapter (FA) 1860.

Перші два - це вже розглянуті нами локальна комутація силами віртуального комутатора (адаптер FA 1860 в даному випадку взагалі не задіюється) і винесення комутації в зовнішню мережу із застосуванням технології VEPA. Третій варіант в Brocade називають апаратним віртуальним комутатором (Hardware Based VEB).

При використанні цього варіанта весь трафік від віртуальних машин направляється на локальний мережевий адаптер для комутації: якщо трафік призначено віртуальної машини, що перебуває на тому ж сервері, він прямує назад гіпервізорами, якщо ні - йде в мережу. Даний варіант комутації використовує стандартний формат кадру Ethernet. До переваг технології Hardware Based VEB фахівці Brocade відносять низьку завантаження процесора сервера, а також можливість (правда, лише часткову) для настроювання політик безпеки і використання механізму якості обслуговування (QoS), до недоліків - обмеження з управління трафіком.

Другий і третій варіанти у вирішенні Brocade засновані на використанні технології віртуалізації PCI-пристроїв Single-Root I / O Virtualization (SR-IOV), розробленої групою фахівців PCI Special Interest Group. Ця технологія вводить поняття «віртуальної функції» - Virtual Function (VF) і дозволяє розділяти мережевий пристрій PCI на кілька віртуальних екземплярів, які працюватимуть безпосередньо з віртуальними машинами

Например, при использовании метода разделения ресурсов SR-IOV в рамках одного физического адаптера FA 1860 может быть создано 255 виртуальных экземпляров. К сожалению, как отмечают специалисты Brocade, технология SR-IOV имеет свои ограничения: в текущей спецификации предусматривается только передача входящего/ исходящего трафика виртуальных машин, а локальная коммутация осуществляется программным коммутатором гипервизора. Кроме того, виртуальный экземпляр адаптера VF не может вести себя как полноценный физический PCI-адаптер и поэтому требуется дополнительная инсталляция драйверов для гипервизора операционной системы VMware ESX и Microsoft HyperV, а также для BIOS серверов. Такая поддержка только планируется производителями этих операционных систем, что затрудняет применение методов Hardware Based VEB и VEPA.

Багато експертів вважають найбільш перспективними технології на зразок VEPA, коли мережеве взаємодія між віртуальними машинами виводиться у фізичну мережу. Однак ряд причин, в тому числі вже згадана затримка з виходом необхідних для механізму SR-IOV драйверів для популярних гіпервізорів, ускладнюють реалізацію цих технологій. Власне, з точки зору розробників середовищ віртуалізації цілком логічно виглядає відсутність у них великого ентузіазму щодо створення інструментів, які дозволять вивести з-під їх контролю такий важливий процес, як взаємодія віртуальних машин.

У цьому зв'язку показовою є позиція Cisco. Просуваючи технологію 802.1BR з метою забезпечити «проникнення» мережі вглиб сервера, вона не менш активно розвиває і свій віртуальний комутатор Nexus 1000V, який виконує локальну комутацію трафіку віртуальних машин всередині сервера. Правда, при цьому функції управління цим процесом - модуль Virtual Supervisor Module (VSM) - виносяться назовні.