Показ дописів із міткою SDN. Показати всі дописи
Показ дописів із міткою SDN. Показати всі дописи

субота, 28 листопада 2015 р.

OpenVSwitch в системі CentOS7: базові налаштування

Вступ

OpenVSwitch (OVS) -- це програмне забезпечення з відкритим кодом, яке призначене для створення у системах з віртуалізацією компонента, еквівалентного за функціональністю керованому Ethernet-комутатору. Наразі OVS використовується здебільшого в системах Linux з усіма найпоширенішими гіпервізорами для віртуалізації -- KVM, VirtualBox, Xen.
OVS типово встановлюється на фізичному сервері-носії, що використовується для запуску віртуальних машин, та є альтернативою для використання мостів Linux (Linux bridges), маючи значно ширшу функціональність. OVS також є вдалою альтернативою комерційним продуктам на зразок віртуального комутатора Cisco Nexus 1000V.

В даній статті розглядаються базові дії зі встановлення та налаштування OVS в системі CentOS7, що є вільно поширюваним аналогом комерційної системи RHEL7. У якості гіпервізора для віртуалізації використовується KVM та інструментальний пакет libvirt.

Встановлення

Встановити пакунки, необхідні для збірки 

# yum install gcc libatomic install make python-devel \
    openssl-devel kernel-devel graphviz kernel-debug-devel \
    autoconf automake rpm-build redhat-rpm-config libtool

Завантажити архів з кодом пакунку в домашню теку та разархівувати його:

# cd
# wget http://openvswitch.org/releases/openvswitch-2.4.0.tar.gz
# tar xzvf openvswitch-2.4.0.tar.gz

Покласти копію архіва з кодом в теку /root/rpmbuild/SOURCES:

# mkdir -p /root/rpmbuild/SOURCES
# cp openvswitch-2.4.0.tar.gz /root/rpmbuild/SOURCES

Запустити процес збірки:

# cd openvswitch-2.4.0
# rpmbuild -bb rhel/openvswitch.spec

Встановити RPM-пакунок, який був створений внаслідок збірки:

# yum localinstall /root/rpmbuild/RPMS/x86_64/openvswitch-2.4.0-1.x86_64.rpm

Скопіювати скрипти керування сервісами в належні місця та налаштувати автоматичний запуск сервісу:

# cp rhel/usr_lib_systemd_system_openvswitch-nonetwork.service \
    /usr/lib/systemd/system/openvswitch-nonetwork.service
# cp rhel/usr_lib_systemd_system_openvswitch.service \
    /usr/lib/systemd/system/openvswitch.service
# systemctl enable openvswitch.service

Примітка: для того щоб уникнути проблем з запуском сервісу потрібно відімкнути SELinux.

OVS зберігає свою конфігурацію у власній базі даних, що знаходиться у теці /etc/openvswitch. Щойно встановлений OVS створює пусту базу даних:

# ovs-vsctl show
4a2b3832-7f57-43c8-9e56-b80974d4ea40
    ovs_version: "2.4.0"

Створення базового моста

Застосування OVS здійснюється шляхом створення мостів, які можна порівняти з типовим Ethernet-комутатором -- до нього під’єднуються інтерфейси, налаштовуються 802.1Q VLAN, виконуються процеси Spaning-Tree Protocol (STP), тощо. За звичай на сервері-носії достатньо створити єдиний OVS-міст:

# ovs-vsctl add-br ovsbridge0
# ip link set ovsbridge0 up
# ip addr show ovsbridge0
5: ovsbridge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 96:34:45:9c:6e:4e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9434:45ff:fe9c:6e4e/64 scope link 
       valid_lft forever preferred_lft forever
# ovs-vsctl show
...
    Bridge "ovsbridge0"
        Port "ovsbridge0"
            Interface "ovsbridge0"
                type: internal
...

Для коректного поводження системи з мостом ovsbridge0 під час перевантажень системи та перезапусків мережевого сервісу необхідно створення файлу /etc/sysconfig/network-scripts/ifcfg-ovsbridge0 з наступним вмістом:

DEVICE=ovsbridge0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static

Під’єднання до OVS-моста фізичних інтерфейсів сервера

Для зв’язку з зовнішньою мережею до OVS-моста потрібно під’єднати фізичні інтерфейси сервера-носія. Гарною практикою є виділення одного фізичного інтерфейсу сервера, який не під’єднується до OVS-моста і слугує виключно для доступу до системи носія (батьківської). В результаті у разі можливих помилок з налаштуванням OVS не буде втрачено зв’язок з батьківською системою.

Під’єднання до OVS-моста фізичного інтерфейсу:

# ovs-vsctl add-port ovsbridge0 enp0s3
# ip link set enp0s3 up
# ovs-vsctl show
...
    Bridge "ovsbridge0"
        Port "ovsbridge0"
            Interface "ovsbridge0"
                type: internal
        Port "enp0s3"
            Interface "enp0s3"
...
# ip addr show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP qlen 1000
    link/ether 08:00:27:5e:db:ba brd ff:ff:ff:ff:ff:ff

Для збереження налаштувань під час перезавантажень сервера та перезапусків мережевого сервісу необхідно створити файл /etc/sysconfig/network-scripts/ifcfg-enp0s3 з наступним вмістом:

NAME=enp0s3
DEVICE=enp0s3
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=ovsbridge0
BOOTPROTO=none
HWADDR=08:00:27:5e:db:ba

Примітка:
 якщо ви знехтували порадою про окремий інтерфейс для керування носієм, або на сервері взагалі лише один фізичний інтерфейс, налаштування IP-адреси необхідно перенести з фізичного інтерфейсу на інтерфейс мосту:

# ip addr del 192.168.1.128/24 dev enp0s3
# ip addr add 192.168.1.128/24 dev ovsbridge0
# ip route add default via 192.168.1.1

Відповідно з файлу /etc/sysconfig/network-scripts/ifcfg-enp0s3 до файлу /etc/sysconfig/network-scripts/ifcfg-ovsbridge0 необхідно перенести наступні рядки (чи подібні):

IPADDR=192.168.1.128
NETMASK=255.255.255.0
GATEWAY=192.168.1.1

Зрозуміло, що останні дії виконуються з фізичної консолі носія, оскільки зв’язок з ним через мережу тимчасово буде втрачено.

Під’єднання до OVS інтерфейсів віртуальних машин

У якості посередника між OVS та інтерфейсами віртуальних машин використовуються віртуальні мережі. Для створення вітуальної мережі, пов’язаної з інтерфейсом ovsbridge0, необхідно підготувати, наприклад в своїй домашій теці, XML-файл з іменем, наприклад, mgmt.xml, з наступним вмістом:

<network>
  <name>mgmt</name>
  <forward mode='bridge'/>
  <bridge name='ovsbridge0' />
  <virtualport type='openvswitch'/>
</network>

Використовуючи зазначений XML-файл створюється віртуальна мережа mgmt:

# virsh net-define mgmt.xml
# virsh net-start mgmt
# virsh net-autostart mgmt
# virsh net-list
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 mgmt                 active     yes           yes

До створеної мережі може бути під’єднано інтерфейс віртуальної машини:

# virsh list --all
 Id    Name                           State
----------------------------------------------------
  -     vhost                           shut off

# virsh domiflist vhost
Interface  Type       Source     Model       MAC
-------------------------------------------------------

# virsh attach-interface vhost network mgmt --model virtio --config
Interface attached successfully

# virsh domiflist vhost
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    mgmt      virtio      52:54:00:7a:02:61

# virsh start vhost
Domain vhost started

# virsh domiflist vhost
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet0      bridge     mgmt       virtio      52:54:00:7a:02:61

# ip addr show vnet4
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UNKNOWN qlen 500
    link/ether fe:54:00:7a:02:61 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe7a:261/64 scope link 
       valid_lft forever preferred_lft forever

# ovs-vsctl show
...
    Bridge "ovsbridge0"
        Port "ovsbridge0"
            Interface "ovsbridge0"
                type: internal
...
        Port "vnet0"
            Interface "vnet0"
...

Примітка: інтерфейс було додано до віртуальної машини, яка знаходилася у вимкненому стані. Після старту віртуальний інтерфейс автоматично з’являється серед пристроїв цієї віртуальної машини.

Використання 802.1Q VLAN

Можливим є використання сервера-носія з віртуальними машинами у мережі, в якій налаштовано віртуальні локальні мережі (VLAN). Наприклад, може виникнути потреба під’єднання інтерфейсів різних віртуальних машин до різних VLAN. В цьому випадку фізичний інтерфейс носія під’єднується до транкового порту зовнішнього комутатора, через який передаються фрейми різних VLAN з відповідними тегами. Розглянемо, як під’єднати до VLAN інтерфейс віртуальної машини.

На OVS-мості створюється підпорядкований псевдо-міст (fake bridge), що пов’язується з потрібною VLAN (в даному випадку VLAN104):

# ovs-vsctl add-br ovsvlan104 ovsbridge0 104
# ip link set ovsvlan104 up
# ovs-vsctl show
    Bridge "ovsbridge0"
...
        Port "ovsvlan104"
            tag: 104
            Interface "ovsvlan104"
                type: internal
...
# ip addr show ovsvlan104
10: ovsvlan104: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 06:a2:0f:cf:0d:47 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4a2:fff:fecf:d47/64 scope link 
       valid_lft forever preferred_lft forever

Для збереження налаштувань під час перезавантажень сервера та перезапусків мережевого сервісу необхідно створити файл /etc/sysconfig/network-scripts/ifcfg-ovsvlan104 з наступним вмістом:

DEVICE=ovsvlan104
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
OVS_OPTIONS="ovsbridge0 104"

Для створення вітуальної мережі, пов’язаної з VLAN104, підготувати XML-файл vlan104.xml з наступним вмістом:

<network>
  <name>vlan104</name>
  <forward mode='bridge'/>
  <bridge name='ovsvlan104' />
  <virtualport type='openvswitch'/>
</network>

Створити віртуальну мережу vlan104:

# virsh net-define vlan104.xml
# virsh net-start vlan104
# virsh net-autostart vlan104
# virsh net-list
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 mgmt                 active     yes           yes
 vlan104              active     yes           yes

Для під’єднання до нової віртуальної мережі створимо новий інтерфейс віртуальної машини, яка вже знаходиться в активному стані.

# virsh list
 Id    Name                           State
----------------------------------------------------
  1     vhost                          running

# virsh attach-interface vhost network vlan104 --model virtio --live
Interface attached successfully

# virsh attach-interface vhost network vlan104 --model virtio --config
Interface attached successfully

# virsh domiflist vhost
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet0      bridge     mgmt       virtio      52:54:00:7a:02:61
vnet1      bridge     vlan104    virtio      52:54:00:c6:60:1c

# ovs-vsctl show
...
    Bridge "ovsbridge0"
...
        Port "ovsvlan104"
            tag: 104
            Interface "ovsvlan104"
                type: internal
        Port "vnet1"
            tag: 104
            Interface "vnet1"
...


Налаштування та використання нового інтерфейсу, який щойно з’явився в віртуальній машині vhost може здійснюватися відразу без перезавантаження машини.

Корисні поради

Під час відлагодження конфігурації мережі замість команди systemctl restart network, яка дає вкрай обмежену інформацію про результат виконання, зручно користуватися командою:

# SYSTEMCTL_SKIP_REDIRECT=1 service network restart
Shutting down interface enp0s3:                            [  OK  ]
Shutting down interface ovsbridge0:                        [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface enp0s3:                              [  OK  ]
Bringing up interface ovsbridge0:                          [  OK  ]

Джерела

вівторок, 27 січня 2015 р.

Популярно про переваги SDN

В своїй статті Greg Ferro визначив чотири основні переваги технології програмно визначених мереж (Software Defined Networking, SDN), завдяки яким ця технологія отримує чимдалі більшу популярність і поширення. Ось ці переваги:
  • побудову мереж на основі SDN можна почати відразу зараз без потреби заміни елементів наявної мережевої інфраструктури
  • SDN надає можливість почати з невеликого проекту і надалі поступово збільшувати масштаб впровадження цієї технології
  • впровадження SDN здійснюється на певній частині типового дата-центру, не заторкуючи інші частини мережі, отже вирішення питань підтримки операцій та безпеки не викликає ускладнень
  • розвиток мережі на основі SDN здійснюється як послідовність невеликих змін, отже ІТ-директори або керівники підприємств не повинні шукати джерела для бюджету на коштовні модифікації мережі
В статті також наведено прогнози щодо впровадження SDN в глобальних мережах, зокрема, на межі між мережами підприємств, каналів до провайдерів, з’єднаннях міх географічно рознесеними сегментами мережі підприємства.

Посилання:

вівторок, 20 січня 2015 р.

Brocade випускає контролер SDN базований на відкритому коді

20 січня компанія Brocade оголосила про випуск свого контролера SDN, який базується на продукті з відкритим кодом OpenDayLight. Новий контролер надає можливість сервіс-провайдерам та підприємствам безкоштовно отримати досвід використання SDN.

Ліцензія передбачає безкоштовне використання контролера протягом одного року з підтримкою до 5 мережевих вузлів. Ліцензія для комерційного використання коштує $100 за кожен мережевий вузол за рік. Протягом  однорічного випробувального терміну користувачі мають доступ до технічної підтримки 24х7.


Посилання:
Дивіться також:

понеділок, 8 грудня 2014 р.

Контролери SDN: хто що робить

Пропоную вашій увазі стисле резюме однойменної статті Мітча Вагнера.

Контролер є логічним центром керування мережі SDN, який керує комутаторами через свій "південний" інтерфейс і взаємодіє з застосуваннями через "північний" інтерфейс.

В чистому вигляді контролер SDN концентрує весь інтелект: комутатори є найпростішими пристроями, що здатні використовуватися відразу після придбання (commercial off-the-shelf, COTS), керування ними здійснює контролер.

Оператори, які вважають зазначений підхід занадто обмеженим, можуть рухатися в напрямку "накладених" або оверлейних (overlay) мереж, запропонованих Cisco Systems, VMWare та іншими виробниками. Оверлейні мережі є програмним прошарком поверх існуючих фізичних мереж. У якості комутаторів можуть використовуватися COTS пристрої, або більш просунуті з фірмовою функціональністю від виробників.

Найчастіше наразі контролери SDN можна зустріти у дата-центрах, втім, їх також використовують у глобальних мережах підприємств (wide area enterprise networks), вони отримують перспективи в глобальних мережах провайдерів послуг, оскільки забезпечують технологію операторського класу, та по мірі того, як визначаються типові сценарії (business cases) їх використання.

Згідно з теорією, SDN дозволяє створювати програмовані мережі, які є гнучкішими та дешевшими у використанні.

Одне з найважливіших питань під час впровадження SDN контролерів в дата-центрах та опраторських мережах є наскільки в дійсності вони здатні інтегруватися (interoperate) з іншими компонентами мережі від різних виробників. Одна з найголовніших обіцянок SDN була звільнення операторів від замкнення на певного постачальника.

Оператори бажають самостійно комплектувати мережі і здійснювати інтеграцію.

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

Далі наведено перелік відомих нам контролерів SDN -- як комерційних, так і з відкритим кодом.

Виробники Продукти Ліцензія Нотатки
Adara Networks Sky, Horizon комерційні розподілений контролер SDN, базований на протоколі OpenFlow, та "мета-контролер" для керування в мережах SDN з компонентами від різних виробників (multi-vendor) та різними потоколами (multi-protocol)
Big Switch Networks Big Network Controller комерційний контролер SDN, базований на протоколі OpenFlow
Brocade Communications Systems Vyatta Controller відкритий код контролер SDN, базований на специфікації OpenDaylight
Calient Technologies Optical Topology Management Controller відкритий код побудований на коді OpenDaylight
Ciena Agility Multilayer WAN Controller комерційний орієнтований на роботу в умовах непередбачуваних сплесків трафіку в глобальних мережах або від користувачів хмарних сервісів
Cisco Systems Application Policy Infrastructure Controller (APIC) комерційний орієнтований на роботу в архітектурі SDN з інфраструктурою, орієнтованою на застосування (Application Centric Infrastructure SDN architecture) Cisco
CloudGenix Software-Defined Enterprise WAN (SDEwan) комерційний знаходиться в стадії бета-версії
ConteXtream ContexNet комерційний складається з двох компонентів: ContexMap та ContexControl
Coriant Transcend SDN Solution комерційний містить Transport Controller, Packet Controller та SDN Network Orchestrator
CPlane Networks CPlane Networks Controller комерційний контролер для середовища OpenStack
Dell Active Fabric Controller комерційний контролер для середовища OpenStack та протоколу OpenFlow
Extreme Networks Extreme OneController комерційний базований на OpenDaylight
Hewlett-Packard (HP) HP Virtual Application Networks SDN Controller комерційний контролер для керування мережами з протоколом OpenFlow
Huawei Technologies Smart Network Controller (відомий також як Smart OpenFlow Controller) комерційний інтегрується з системою підтримки (orchestration) від Netmatrix, підтримує протоколи OpenFlow, PCE, Netconf та BGP
IBM Corp. Programmable Network Controller комерційний контролер для керування мережами з протоколом OpenFlow
Inocybe Technologies Infrastructure Controller комерційний контролер для SDN та хмарних середовищ на основі OpenDaylight та OpenStack
Juniper Networks NorthStar та OpenContrail комерційний контролери SDN власної розробки та придбаний
NEC America Inc. ProgrammableFlow SDN Controller комерційний перший комерційний контролер для OpenFlow, "контролер контролерів"
Nuage (дочірній проект Alcatel-Lucent) Virtual Services Controller комерційний контролер для керування платформою віртуалізованих послуг Nuage (Nuage's Virtualized Services Platform)
Pica8 RYU OpenFlow відкритий код контролер є компонентом стартового набору для SDN (SDN Starter Kit)
Plexxi Plexxi Control комерційний контролер для дата-центрів
VMware NSX Controller комерційний контролер вбудований в платформу VMWare і недоступний як самостійний продукт
Project Floodlight Floodlight Open SDN Controller відкритий код, ліцензія Apache створений компанією Big Switch Networks контролер для OpenFlow
OpenContrail OpenContrail Controller відкритий код спонсорований компанією Juniper Networks "логічно зосереджений та фізично розподілений" контролер для SDN, віртуальний маршрутизатор, центтр аналітики
NOXRepo NOX & POX відкритий код контролер для OpenFlow, призначений для створення застосувань з метою дослідження та навчання
OpenDaylight Project Helium відкритий код відкрита платформа для SDN та NFV
ON.Lab SDN Open Network Operating System (ONOS) відкритий код компоненти для SDN продуктів з відкритим кодом
Stanford University Beacon відкритий код крос-платформений модульний контролер OpenFlow на Java

Джерело:

середа, 1 жовтня 2014 р.

Друга версія OpenDaylight -- 'Helium'

Вийшла друга знакова версія (milestone) OpenDaylight -- контролера програмно визначених мереж (Software Defined Networking, SDN). Нова версія отримала назву 'Helium'.

Система OpenDaylight з'явилася як результат спільних зусиль декількох компаній-постачальників мережевих рішень зі створення відкритої платформи для SDN.

OpenDaylight 'Helium' реалізує контейнер Apache Karaf, краще інтегрований з середовищем OpenStack та з проектом інтеграції баз даних віртуальних комутаторів OpenVSwitch.Появлення OpenDaylight 'Helium' передує виходу нової версії OpenStack 'Juno', яку заплановано на жовтень 2014 р.

В новій версії підтримується функціональність груп безпеки (security groups) OpenStack, розподілені віртуальні маршрутизатори, балансування навантаження як послуга (load balancing as-a-service). Додано нові протоколи -- OpenFlow Table Type Patterns та PacketCable multimedia. Покращено підтримку кластерізації для відмовостійкості, функції безпеки та авторизації. Впроваджено нову інфраструктуру безпечного завантаження мереж (Secure Network Bootstrapping Infrastructure, SNBI), яка дозволяє користувачам визначати та завантажувати захищені набори контролерів та мережних пристроїв. Під SDN-інтерфейсом (SDNi) впроваджено крос-контролерну конфедерацію з використанням BGP.

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

Посилання:

четвер, 25 вересня 2014 р.

HP створює магазин продуктів для SDN

Відкриття магазину HP SDN App Store заплановано на 1 жовтня ц.р. В магазині будуть представлені продукти, оптимізовані для використання в першу чергу на платформі SDN, що просувається HP (включає SDN контролер, супутнє програмне забезпечення, підтримувані пристрої), втім можуть використовуватися і на інших платформах.

Продукти в HP SDN App Store можна виділити в такі категорії:
  • The HP Circle -- продукти, створені і випробувані виключно HP
  • The Premium Circle -- продукти від найбільших постачальників, відтестовані сумісно HP та її партнерами
  • The Partner Circle -- продукти, випробувані власнотужки партнерами HP, та переглянуті HP
  • The Community Circle -- продукти, що знаходяться у вільному доступі та підтримуються спільнотою, які демонструють доказ концепції (proof of concept) та мають відкритий вихідний код.
Вже відомо, що початково в HP SDN App Store будуть представлені два продукти HP -- Network Optimizer (оптимізація функціювання Microsoft Lync) та  Network Protector для захисту в умовах BYOD.Також будуть представлені шість продуктів від партнерів HP -- BlueCat DNS Director, Ecode evolve, F5 BIG DDoS Umbrella, GuardiCore Defense Suite, KEMP Adaptive Load Balancer Application, та Real Status Hyperglance.

Джерела:

середа, 24 вересня 2014 р.

Brocade оголосила підтримку SDN контролера OpenDayLight в маршрутизаторах Vyatta

Днями компанія Brocade повідомила про свій новий продукт -- SDN контролер Brocade Vyatta Controller, який базується на проекті з відкритим кодом OpenDayLight. Такий крок здійснюється з метою подальшого розвитку відкритої мережевої платформи. Стверджується, що в новому продукті будуть відсутні "фірмові" доповнення порівняно з OpenDayLight. Заявлено, що  контролер Brocade Vyatta Controller буде підтримуватися маршутизаторами Vyatta.

Посилання: