пʼятниця, 1 квітня 2016 р.

Налаштування зв'язки інтерфейсів EtherChannel за допомогою OpenVSwitch

Попередня публікація на тему використання OpenVSwitch: OpenVSwitch в системі CentOS7: базові налаштування

Вступ

Зв'язка (bundle) інтерфейсів EtherChannel являє собою сумісне використання Ethernet інтерфейсів з метою отримання нового віртуального інтерфейсу, який має наступні ознаки:

а) пропускна здатність, що приблизно дорівнює сумі інтерфейсів, що надходять зо зв'язки,
б) стійкість до відмови окремих інтерфейсів зв'язки.

Для динамічного конфігурування інтерфейсу EtherChannel пристрої, з'єднані через інтерфейси зв'язки, взаємодіють за протоколом Link Aggregation Control Protocol (LACP).

Задача

Розглянемо налаштування інтерфейсу EtherChannel в системі, в якій встановлено віртуальний комутатор OpenVSwitch. Для прикладу уявимо систему CentOS Linux з двома інтерфейсами GigabitEthernet -- ge0, ge1, та двома інтерфейсами 10GigabitEthernet -- te0, te1:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: te0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000
    link/ether 14:18:77:30:64:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1618:77ff:fe30:64fe/64 scope link
       valid_lft forever preferred_lft forever
3: te1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000
    link/ether 14:18:77:30:65:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1618:77ff:fe30:6500/64 scope link
       valid_lft forever preferred_lft forever
4: ge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 14:18:77:30:65:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global ge0
       valid_lft forever preferred_lft forever
    inet6 fe80::1618:77ff:fe30:6502/64 scope link
       valid_lft forever preferred_lft forever
5: ge1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 14:18:77:30:65:04 brd ff:ff:ff:ff:ff:ff

Дану систему планується використовувати як носій для віртуальних машин (ВМ). Інтерфейс ge0 використовуватиметься виключно для керування носієм. Інтерфейс ge1 залишається резервним, його можна використовувати, наприклад, для аналізу трафіку на портах комутатора за технологією віддзеркалювання портів (port mirroring). Інтерфейси te0 та te1 використовуватимуться для передачі трафіку ВМ. Для отримання великої пропускної здатності та відмовостійкості інтерфейсів (оптичні з'єзнання 10GigabitEthernet характеризуються нижчою механічною надійністю ніж мідні з'єднання GigabitEthernet) інтерфейси te0 та te1 об'єднуються у зв'язку EtherChannel.

Налаштування EtherChannel

Для використання OpenVSwitch створюється базовий міст ovsbridge0, що, фактично, є віртуальним аналогом звичайного комутатора:

# ovs-vsctl --may-exist add-br ovsbridge0
# ip link set ovsbridge0 up
# ip addr show ovsbridge0
7: 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

Створюємо віртуальний інтерфейс EtherChannel -- bond0, з яким пов'язуємо фізичні інтерфейси te0 та te1:

ovs-vsctl --may-exist add-bond ovsbridge0 bond0 te0 te1

Слід зазначити, що інтерфейс bond0 не з'являється поруч з іншими інтерфейсами, які можна побачити, наприклад, за допомогою команди "ip addr show". З інтерфейсом bond0 оперує OpenVSwitch:

# ovs-vsctl show
8f777f14-8698-4e0e-b48c-38aed81a1a76
    Bridge "ovsbridge0"
        Port "bond0"
            Interface "te0"
            Interface "te1"

На EtherChannel інтерфейсі налаштовується протокол LACP та метод балансування трафіку типу TCP:

# ovs-vsctl set port bond0 bond_mode=balance-tcp \
    other-config={bond-detect-mode=miimon bond-miimon-interval=100} \
    lacp=active

Взагалі, OpenVSwitch підтримує три можливі типи балансування трафіку через з'єднання EtherChannel:

  • balance−slb -- балансування по MAC-адресах і номерах VLAN джерела (source) з періодичним коригуванням розподілу потоків (flows) між фізичними з'єднаннями на випадок зміни характеру трафіку
  • active−backup -- передача всіх потоків через основне (active) фізичних з'єднань та у випадку виходу цього з'єднання з ладу перенесення потоків на резервне (backup) з'єднання
  • balance−tcp -- балансування по інформації з L2, L3 та L4 протоколів, зокрема, по MAC- та IP-адресах та номеру порту TCP призначення (destination)

Метод balance−slb використовується за замовченням. Метод active−backup єдиний дозоляє під'єднувати фізичні інтерфейси, що пов'язані в EtherChannel, до різних комутаторів. Метод balance−tcp вимагає підтримки LACP відповідно стандарту IEEE 802.3ad на комутаторі, з яким створюється з'єднання EtherChannel.

Примітка: я не знайшов чіткої розшифровки скорочення SLB. Найбільш вірогідною мені здається "Switch-assisted Load Balancing".

Як було зазначено раніше, окрім збільшення пропускної здатності технологія EtherChannel дозволяє забезпечити відмовостійкість на випадок виходу з ладу окремих фізичних з'єднань. Налаштування відмовостійкості здійснюється наступними основними параметрами:

  • other_config : bond-detect-mode -- спосіб визначення відмови фізичного з'єднання, можливі значення:
    • carrier -- покладання на наявність сигнал з частотою носія (carrier) в інтерфейсі, використовується за замовченням
    • miimon -- опитування модуля інтерфейсу незалежного від середовища, Media Independent Interface (MII)
  • other_config : bond-miimon-interval -- інтервал в мілісекундах між успішними опитуваннями інтерфейсу MII; умісний лише у випадку використання способу визначення відмови фізичного з'єднання miimon
Для включення протоколу LACP на з'єднання EtherChannel використову'ється параметр lacp -- режим функціювання EtherChannel згідно LACP. Можливі значення параметру:
    • active -- ініціювання та підтримка LACP взаємодії
    • passive -- підтримка LACP взаємодії, якщо її ініціює пристрій-партнер
    • off -- вимкнення LACP взаємодії

Примітка: окрім зазначених параметрів для тонкого налаштування EtherChannel та протоколу LACP можуть бути використана низка додаткових параметрів.

Створений інтерфейс EtherChannel переводимо в режим VLAN транку (trunk) та додаємо список VLAN, які дозволено передавати:

ovs-vsctl set port bond0 vlan_mode=trunk trunks=10,20,30

Для перегляду стану сформованого з'єднання EtherChannel використовуємо наступні команди:

ovs-vsctl list port bond0
_uuid               : 50620062-c457-4c70-b3c7-66de0d27fb0c
bond_active_slave   : "14:18:77:30:65:00"
bond_downdelay      : 0
bond_fake_iface     : false
bond_mode           : balance-tcp
bond_updelay        : 0
external_ids        : {}
fake_bridge         : false
interfaces          : [741f5d85-bafc-4add-b3bc-580f90f27b2e, 78d25b6b-7a42-4b76-be60-04aed46b8555]
lacp                : active
mac                 : []
name                : "bond0"
other_config        : {bond-detect-mode=miimon, bond-miimon-interval="100"}
qos                 : []
rstp_statistics     : {}
rstp_status         : {}
statistics          : {}
status              : {}
tag                 : []
trunks              : [10, 20, 30]
vlan_mode           : trunk

# ovs-appctl bond/show
---- bond0 ----
bond_mode: balance-tcp
bond may use recirculation: yes, Recirc-ID : 2
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 9565 ms
lacp_status: negotiated
active slave mac: 14:18:77:30:65:00(te1)

slave te0: enabled
        may_enable: true

slave te1: enabled
        active slave
        may_enable: true

# ovs-appctl lacp/show
---- bond0 ----
        status: active negotiated
        sys_id: 14:18:77:30:64:fe
        sys_priority: 65534
        aggregation key: 1
        lacp_time: slow

slave: te0: current attached
        port_id: 2
        port_priority: 65535
        may_enable: true

        actor sys_id: 14:18:77:30:64:fe
        actor sys_priority: 65534
        actor port_id: 2
        actor port_priority: 65535
        actor key: 1
        actor state: activity aggregation synchronized collecting distributing

        partner sys_id: f8:b1:56:83:8a:81
        partner sys_priority: 1
        partner port_id: 49
        partner port_priority: 1
        partner key: 210
        partner state: activity aggregation synchronized collecting distributing

slave: te1: current attached
        port_id: 1
        port_priority: 65535
        may_enable: true

        actor sys_id: 14:18:77:30:64:fe
        actor sys_priority: 65534
        actor port_id: 1
        actor port_priority: 65535
        actor key: 1
        actor state: activity aggregation synchronized collecting distributing

        partner sys_id: f8:b1:56:83:8a:81
        partner sys_priority: 1
        partner port_id: 50
        partner port_priority: 1
        partner key: 210
        partner state: activity aggregation synchronized collecting distributing

Альтернативним способом налаштування EtherChannel на OpenVSwitch є створення файлу конфигурації інтерфейсу bond0 -- /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
NAME=bond0
ONBOOT=yes
DEVICETYPE=OVS
TYPE=OVSBond
OVS_BRIDGE=ovsbridge0
BOOTPROTO=none
BOND_IFACES="te0 te1"
TRUNKS="trunks=10,20,30"
OVS_OPTIONS="bond_mode=balance-tcp"
OVS_OPTIONS+=" other-config:bond-detect-mode=miimon"
OVS_OPTIONS+=" other-config:bond-miimon-interval=100"
OVS_OPTIONS+=" lacp=active vlan_mode=trunk $TRUNKS"

Конфігурація інтерфейсів з боку комутатора, до якого під'єднано інтерфейси, які об'єднано в EtherChannel, може виглядати таким чином (комутатор серії Dell Networking N1500):

interface Te1/0/1 
channel-group 1 mode active
description "CR ETH2"
switchport mode trunk
exit              
!                 
interface Te1/0/2 
channel-group 1 mode active
description "CR ETH3"
exit              
!                 
interface port-channel 1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
exit

Зазначимо, що простіше було б на обох транкових інтерфейсах -- port-channel 1 з боку комутатора та bond0 з боку сервера, дозволити передачу фреймів всіх можливих VLAN -- з 1 по 4096. Проте, так робити не слід, оскільки це невиправдано подовжує широкомовні сегменти, якими є VLAN. Детальніше про те, чому не слід спрощувати конфігурації шляхом дозволу всіх VLAN, можна почитати в прекрасній статті Івана Пепельняка VLANS AND FAILURE DOMAINS REVISITED.

Джерела

Немає коментарів:

Дописати коментар