Jak nakonfigurovat převzetí služeb při selhání a vysokokapacitní síťové vazby v systému Linux

Tento tutoriál vysvětluje, jak nakonfigurovat síťové propojení na serveru Linux. Než začnu, dovolte mi vysvětlit, co je to network bonding a k čemu slouží. V prostředí Windows se propojení sítí nazývá network teaming. Jedná se o funkci, která pomáhá jakékoli serverové architektuře poskytovat vysokou dostupnost a převzetí služeb při selhání ve scénářích, kdy jeden z hlavních ethernetových kabelů nefunguje nebo je špatně nakonfigurován.

Obvykle je to osvědčený postup a funkce, která musí být implementována, když nastavujete server pro produkční účely. I když lze tuto funkci provést v konfiguraci prostředí Linux, musíte nejprve potvrdit u svého správce sítě, abyste zajistili, že přepínače, které jsou propojeny s vaším serverem, podporují propojení sítí. Existuje několik režimů propojení, které můžete implementovat v prostředí serveru. Níže je uveden seznam dostupných režimů a jejich funkce:

• Zůstatek-rr
  Tento režim poskytuje funkce pro vyrovnávání zátěže a odolnost proti chybám (failover) prostřednictvím zásad kruhového provozu. Znamená, že přenáší pakety v sekvenčním pořadí od prvního dostupného slave zařízení po poslední.
• Active-Backup
  Tento režim poskytuje funkce odolnosti proti chybám prostřednictvím zásad aktivního zálohování. To znamená, že jakmile je spojovací ethernet zapnutý, je aktivní pouze 1 ethernet slave. Druhý ethernetový slave se stane aktivním pouze tehdy, když aktuální aktivní slave selže být zapnutý. Pokud zvolíte tento režim, všimnete si, že spojovací MAC adresa je externě viditelná pouze na jednom síťovém adaptéru. Je to proto, aby nedošlo k záměně přepínače.
• Balance-xor
  Tento režim poskytuje vyvažování zátěže a odolnost proti chybám. Vysílá na základě zvolené zásady hash přenosu. Alternativní zásady přenosu lze vybrat pomocí možnosti xmit_hash_policy.
• Vysílání
  Tento režim poskytuje pouze odolnost proti chybám. Přenáší vše na všech podřízených ethernetových rozhraních.
• 802.3ad
  Tento režim poskytuje vyvažování zátěže a odolnost proti chybám. Vytvoří agregační skupinu, která sdílí stejnou rychlost a duplexní nastavení. Využívá všechna slave ethernetová rozhraní v aktivním agregátoru, je založen na specifikaci 802.3ad. Pro implementaci tohoto režimu musí ethtool podporovat základní ovladače pro načítání rychlosti a duplexního režimu každého slave. Přepínač musí také podporovat dynamickou agregaci odkazů. Normálně to vyžaduje zásah síťového inženýra pro podrobnou konfiguraci.
• Zůstatek-TLB
  Tento režim poskytuje funkce vyrovnávání zátěže, protože název TLB představuje vyrovnávání zátěže přenosu . Pro tento režim, pokud je konfigurace tlb_dynamic_lb =1, pak je odchozí provoz distribuován podle aktuálního zatížení každého slave zařízení. Pokud je konfigurace tlb_dynamic_lb =0, pak je vyvažování zátěže zakázáno, ale zátěž je distribuována pouze pomocí rozložení hasd. V tomto režimu musí ethtool podporovat základní ovladače pro načítání rychlosti každého slave.
• Zůstatek-ALB
  Tento režim poskytuje funkce vyrovnávání zátěže, protože název TLB představuje adaptivní vyvažování zátěže . Podobné jako balance-tlb, s tím rozdílem, že jak odesílací, tak i přijímací provoz jsou spojeny. Získává vyrovnávání zátěže dosažením vyjednávání ARP. Ovladač bondingu zachytí odpovědi ARP zaslané místním systémem na jejich cestě ven a přepíše zdrojovou hardwarovou adresu jedinečnou hardwarovou adresou jednoho z podřízených zařízení v bondingu. Pro tento režim musí ethtool podporovat základní ovladače pro načítání rychlosti každého slave.

1. Předběžná poznámka

Pro tento tutoriál používám Oracle Linux 6.4 v 32bitové verzi. Vezměte prosím na vědomí, že i když je konfigurace provedena pod Oracle Linux, kroky jsou použitelné také pro CentOS a Red Hat OS distro a také pro 64Bit systémy. Konečný výsledek našeho příkladu nastavení ukáže, že připojení vytvořené k našemu spojovacímu serveru zůstane připojeno, i když jsem zakázal 1 z ethernetových sítí. V tomto příkladu ukážu, jak použít síťové propojení pomocí režimu 1, což je zásada aktivního zálohování.

2. Fáze instalace

Pro tento proces není potřeba žádná instalace. Výchozí instalace serveru pro Linux obsahuje všechny požadované balíčky pro konfiguraci síťového propojení.

3. Konfigurační fáze

Než zahájíme konfiguraci, musíme se nejprve ujistit, že máme na našem serveru nakonfigurovaná alespoň 2 ethernetová rozhraní. Chcete-li to zkontrolovat, přejděte do složky konfigurace sítě a vypište dostupná ethernetová rozhraní. Níže jsou kroky:

cd /etc/sysconfig/network-scripts/
ls *ifcfg*eth*

Výsledek je:

ifcfg-eth0 ifcfg-eth1 

Všimněte si, že v současné době máme podle nastavení na našem serveru 2 ethernetová rozhraní, která jsou ETH0 a ETH1.

Nyní nakonfigurujme spojovací rozhraní nazvané BOND0. Toto rozhraní bude virtuální ethernetové rozhraní, které obsahuje fyzické ethernetové rozhraní ETH0 a ETH1. Níže jsou kroky:

vi ifcfg-bond0

ZAŘÍZENÍ=bond0
ONBOOT=ano
MASTER=ano
IPADDR=172.20.43.110
NETMASK=255.255.255.0
GATEWAY=172.20.43.1
BONDING_OPTS="mode=1 miimon=100"
TYPE=Ethernet 

Poté spusťte:

ls *ifcfg*bon*

Výsledek je:

ifcfg-bond0 

To je vše. Všimněte si prosím, že uvnitř rozhraní BOND0 jsem uvedl IP adresu. Tato IP adresa bude jedinou IP adresou připojenou k našemu serveru. Abychom mohli pokračovat v procesu, musíme upravit fyzické ethernetové rozhraní související s rozhraním BOND0. Níže jsou kroky:

vi ifcfg-eth0

DEVICE=eth0
TYPE=Ethernet
ONBOOT=ano
NM_CONTROLLED=ne
MASTER=bond0
SLAVE=ano 

vi ifcfg-eth1

DEVICE=eth1
TYPE=Ethernet
ONBOOT=ano
NM_CONTROLLED=ne
MASTER=bond0
SLAVE=ano 

Hotovo. Provedli jsme úpravu rozhraní ETH0 a ETH1. Všimněte si, že jsme odstranili IP adresu z obou rozhraní a přidali MASTER =bond0. To je nutné k ověření, že obě rozhraní budou virtuálními rozhraními, která jsou vyhrazena pro rozhraní ethernet BOND0.

Chcete-li pokračovat v konfiguraci. Vytvořme konfigurační soubor bonding s názvem bonding.conf v /etc/modprobe.d . Níže jsou kroky:

vi /etc/modprobe.d/bonding.conf

alias bond0 bonding
možnosti bond0 mode=1 miimon=100 

vazba modprobe 

Na základě výše uvedené konfigurace jsme nakonfigurovali spojovací modul pomocí rozhraní BOND0. Také jsme přiřadili konfiguraci propojení k použití režimu =1, což je zásada aktivního zálohování. Možnost miimon =100 představuje frekvenci monitorování pro náš spojovací server pro sledování stavu rozhraní v milisekundách. Jak je popsáno výše, tento režim poskytne funkce odolnosti proti chybám v konfiguraci sítě serveru.

Jakmile je vše nastaveno, restartujte síťovou službu, aby se načetla nová konfigurace. Níže jsou kroky:

restart servisní sítě

Vypnutí rozhraní eth0:[ OK ]
Vypnutí rozhraní eth1:[ OK ]
Vypnutí rozhraní zpětné smyčky:[ OK ]
Zobrazení rozhraní zpětné smyčky:[ OK ]
Vyvolání rozhraní bond0:[ OK ] 

Výborně, nyní jsme načetli novou konfiguraci, kterou jsme provedli výše. Všimnete si, že nové rozhraní s názvem BOND0 se zobrazí v seznamu sítí. Také si všimnete, že rozhraním ETH0 a ETH1 není přiřazena žádná IP adresa, pouze rozhraní BOND0 zobrazuje IP.

ifconfig

bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
inet addr:172.20.43.110 Bcast:172.20.43.255 Maska:255.255.255.0UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX pakety:1723 chyby:0 zahozené:0 přetečení:0 snímek:0
TX pakety:1110 chyb:0 zahozené:0 přetečení:0 dopravce:0
kolize:0 txqueuelen:0
RX bytes:147913 (144,4 KiB) TX bytes:108429 (105,8 KiB) 

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP VYSÍLÁNÍ RUNNING SLAVE MULTICAST MTU:1500 Metrika:1
RX pakety:1092 chyby:0 zahozené:0 přetečení :0 frame:0
TX pakety:1083 chyby:0 zahozené:0 přetečení:0 dopravce:0
kolize:0 txqueuelen:1000
RX bytes:103486 (101,0 KiB) TX bajtů:105439 (102,9 KiB) 

eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP VYSÍLÁNÍ RUNNING SLAVE MULTICAST MTU:1500 Metrika:1
RX pakety:632 chyb:0 zahozené:0 přetečení :0 frame:0
TX pakety:28 chyb:0 zahozené:0 přetečení:0 dopravce:0
kolize:0 txqueuelen:1000
RX bytes:44487 (43,4 KiB) TX bajtů:3288 (3,2 kB) 

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr:::1/128 Rozsah:Host
UP LOOPBACK RUNNING MTU:16436 Metric :1
RX pakety:208 chyby:0 zahozené:0 přetečení:0 rámec:0
TX pakety:208 chyby:0 zahozené:0 přetečení:0 dopravce:0
kolize:0 txqueuelen :0
RX bytes:18080 (17,6 KiB) TX bytes:18080 (17,6 KiB) 

Stav lepení můžete také zkontrolovat pomocí tohoto příkazu:

cat /proc/net/bonding/bond0

Ovladač pro připojení ethernetového kanálu:v3.6.0 (26. září 2009) 

Režim vazby:odolnost proti chybám (aktivní-záloha)
Primární slave:Žádný
Aktuálně aktivní slave:eth0
Stav MII:nahoru
Interval dotazování MII (ms):100
Zpoždění nahoru (ms):0
Zpoždění dolů (ms):0 

Rozhraní Slave:eth0
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:61:e4:88
ID podřízené fronty:0 

Rozhraní Slave:eth1
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:c8:46:40
ID podřízené fronty:0 

Všimněte si výše, že jsme úspěšně převedli rozhraní ETH0 a ETH1 do konfigurace propojení pomocí režimu aktivní zálohy. Nyní je také uvedeno, že server používá rozhraní ETH0, ETH1 bude jako záložní rozhraní.

4. Testovací fáze

Nyní je vše nakonfigurováno podle očekávání. Udělejme jednoduchý test, abychom se ujistili, že konfigurace, kterou jsme provedli, je správná. Pro tento test se přihlásíme k novému serveru (nebo linuxovému desktopu) a začneme testovat náš spojovací server, abychom zjistili, zda během testu nedochází k přerušovanému připojení. Níže jsou kroky:

přihlaste se jako:root
Heslo uživatele [e-mail chráněno]:
Poslední přihlášení:st. září 12:50:15 2016 od 172.20.43.80

ping 172.20.43.110

PING 172.20.43.110 (172.20.43.110) 56(84) bajtů dat.
64 bajtů z 172.20.43.110:icmp_seq=1 ttl=64 čas=0,408 ms2.
64 bajtů z 172.20.43.110:icmp_seq=3 ttl=64 čas=0,415 ms
64 bajtů z 14442.210.6 čas=0,427 ms
64 bajtů od 172.20.43.110:icmp_seq=5 ttl=64 čas=0,554 ms
64 bajtů od 172.20.43.110:icmp_seq<=6 ttl.=64 čas=6 ttl.443 64 bajtů z 172.20.43.110:icmp_seq=7 ttl=64 čas=0,663 ms
64 bajtů z 172.20.43.110:icmp_seq=8 ttl=64 čas=0,961 ms2 1 q.20. =9 ttl=64 čas=0,461 ms
64 bajtů od 172.20.43.110:icmp_seq=10 ttl=64 čas=0,544 ms
64 bajtů od 172.20.43.110=112 czttl=0.412 čas=0,412 ms
64 bajtů z 172.20.43.110:icmp_seq=12 ttl=64 čas=0,464 ms
64 bajtů z 172.20.43.110:icmp_seq=13 ttl=62 ms=0,4 

 Během této doby se vraťme na náš bonding server a vypněte ethernetové rozhraní ETH0. Níže jsou kroky:
 
ifconfig eth0
 
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP VYSÍLÁNÍ RUNNING SLAVE MULTICAST MTU:1500 Metrika:1
RX pakety:1092 chyby:0 zahozené:0 přetečení :0 frame:0
TX pakety:1083 chyby:0 zahozené:0 přetečení:0 dopravce:0
kolize:0 txqueuelen:1000
RX bytes:103486 (201,0 KiB) TX bajtů:105439 (122,9 kiB) 
 
ifdown eth0 
 

 Nyní jsme vypnuli služby pro síťové rozhraní ETH0. Pojďme zkontrolovat stav lepení. Níže jsou kroky:
 
cat /proc/net/bonding/bond0
 
Ovladač pro připojení ethernetového kanálu:v3.6.0 (26. září 2009) 
 
Režim vazby:odolnost proti chybám (aktivní-záloha)
Primární slave:Žádný
Aktuálně aktivní slave:eth1
Stav MII:nahoru
Interval dotazování MII (ms):100
Zpoždění nahoru (ms):0
Zpoždění dolů (ms):0 
 
Rozhraní Slave:eth1
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:c8:46:40
ID podřízené fronty:0 
 

 Všimnete si, že nyní rozhraní ETH0 již neexistuje ve stavu bondingu. Během této doby se vraťme na předchozí testovací server a zkontrolujeme nepřetržitý ping na náš spojovací server. 
 
64 bajtů od 172.20.43.110:icmp_seq=22 ttl=64 čas=0,408 ms
64 bajtů od 172.20.43.110:icmp_seq=23 ttl=64 bytes od 0,402>1 ms. 43.110:icmp_seq=24 ttl=64 čas=0,437 ms
64 bajtů od 172.20.43.110:icmp_seq=25 ttl=64 čas=0,504 ms
64 bajtů od 1432,21ic čas=0,401 ms
64 bajtů od 172.20.43.110:icmp_seq=27 ttl=64 čas=0,454 ms
64 bajtů od 172.20.43.110:icmp_seq=48 /2 tsl=6 64 bajtů z 172.20.43.110:icmp_seq=29 ttl=64 čas=0,434 ms
64 bajtů z 172.20.43.110:icmp_seq=30 ttl=64 čas=0,411>7 ms2 =31 ttl=64 čas=0,554 ms
64 bajtů od 172.20.43.110:icmp_seq=32 ttl=64 čas=0,452 ms
64 bajtů od 172.20.43.110=460.43.110=340.43.110. ms
64 bajtů od 172.20.43.110:icmp_seq=34 ttl=64 time=0,491 ms 
 

 
 

 Skvělé, nyní uvidíte, že i když jsme vypnuli rozhraní ETH0, stále jsme schopni pingnout a přistupovat k našemu spojovacímu serveru. Nyní uděláme ještě 1 test. Znovu zapněte rozhraní ETH0 a vypněte rozhraní ETH1. 
 
ifup eth0
cat /proc/net/bonding/bond0
 
Ovladač pro připojení ethernetového kanálu:v3.6.0 (26. září 2009) 
 
Režim vazby:odolnost proti chybám (aktivní-záloha)
Primární slave:Žádný
Aktuálně aktivní slave:eth1
Stav MII:nahoru
Interval dotazování MII (ms):100
Zpoždění nahoru (ms):0
Zpoždění dolů (ms):0 
 
Rozhraní Slave:eth1
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:c8:46:40
ID podřízené fronty:0 
 
Rozhraní Slave:eth0
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:61:e4:88
ID podřízené fronty:0 
 

 Protože rozhraní ETH0 již bylo aktivní, vypněte rozhraní ETH1. 
 
ifdown eth1
 
cat /proc/net/bonding/bond0
 
Ovladač pro připojení ethernetového kanálu:v3.6.0 (26. září 2009) 
 
Režim vazby:odolnost proti chybám (aktivní-záloha)
Primární slave:Žádný
Aktuálně aktivní slave:eth0
Stav MII:nahoru
Interval dotazování MII (ms):100
Zpoždění nahoru (ms):0
Zpoždění dolů (ms):0 
 
Rozhraní Slave:eth0
Stav MII:nahoru
Rychlost:1000 Mbps
Duplex:plný
Počet selhání spojení:0
Stálá HW adresa:08:00 :27:61:e4:88
ID podřízené fronty:0 
 

 
Nyní se vraťme na testovací server a zkontrolujme, co se stane na nepřetržitém pingu odeslaném na náš spojovací server 
 
64 bajtů od 172.20.43.110:icmp_seq=84 ttl=64 čas=0,437 ms
64 bajtů od 172.20.43.110:icmp_seq=85 ttl=64 časů=0,504>104 ms. 43.110:icmp_seq=86 ttl=64 čas=0,401 ms
64 bajtů od 172.20.43.110:icmp_seq=87 ttl=64 čas=0,454 ms
64 bajtů od 1432,2q čas=0,432 ms
64 bajtů od 172.20.43.110:icmp_seq=89 ttl=64 čas=0,434 ms
64 bajtů od 172.20.43.110:icmp_seq64 bajtů z 172.20.43.110:icmp_seq=92 ttl=64 čas=0,487 ms2 =93 ttl=64 čas=0,551 ms
64 bajtů od 172.20.43.110:icmp_seq=94 ttl=64 čas=0,523 ms
64 bajtů od 172.20.43.110=469 icmp_seq=0. ms 
 

 
Palec nahoru! Úspěšně jsme nakonfigurovali a ověřili, že náš spojovací server zvládá uspokojit scénář obnovy po havárii v podmínkách selhání sítě.