Come configurare il failover e l'alta disponibilità del bonding di rete su Linux

Questo tutorial spiega come configurare il bonding di rete su un server Linux. Prima di iniziare, lasciatemi spiegare cos’è il bonding di rete e cosa fa. In un ambiente Windows, il bonding di rete è chiamato teaming di rete, questa è una funzionalità che aiuta qualsiasi architettura server a fornire alta disponibilità e failover in scenari in cui uno dei principali cavi ethernet ha un malfunzionamento o è mal configurato.

Normalmente, è una prassi migliore e una funzionalità indispensabile da implementare quando si configura un server per scopi di produzione. Anche se questa funzionalità può essere realizzata in una configurazione ambientale Linux, è necessario prima confermare con il proprio amministratore di rete per garantire che gli switch collegati al server supportino il bonding di rete. Ci sono diversi modi di bonding che possono essere implementati nel proprio ambiente server. Di seguito è riportato un elenco dei modi disponibili e cosa fanno:

• Balance-rr
  Questo modo fornisce bilanciamento del carico e tolleranza ai guasti (failover) tramite una politica round-robin. Significa che trasmette pacchetti in ordine sequenziale dal primo slave disponibile fino all’ultimo.
• Active-Backup
  Questo modo fornisce funzionalità di tolleranza ai guasti tramite una politica attiva-backup. Significa che una volta che il bonding ethernet è attivo, solo 1 degli slave ethernet è attivo. L’altro slave ethernet diventerà attivo solo se e solo se lo slave attivo corrente smette di funzionare. Se scegli questo modo, noterai che l’indirizzo MAC di bonding è visibile esternamente solo su un adattatore di rete. Questo per evitare di confondere lo switch.
• Balance-xor
  Questo modo fornisce bilanciamento del carico e tolleranza ai guasti. Trasmette in base alla politica di hash di trasmissione selezionata. Politiche di trasmissione alternative possono essere selezionate tramite l’opzione xmit_hash_policy.
• Broadcast
  Questo modo fornisce solo tolleranza ai guasti. Trasmette tutto su tutte le interfacce ethernet slave.
• 802.3ad
  Questo modo fornisce bilanciamento del carico e tolleranza ai guasti. Crea un gruppo di aggregazione che condivide la stessa velocità e impostazioni di duplex. Utilizza tutte le interfacce ethernet slave nell’aggregatore attivo, è basato sulla specifica 802.3ad. Per implementare questo modo, l’ethtool deve supportare i driver di base per recuperare la velocità e la modalità duplex di ciascuno slave. Anche lo switch deve supportare l’aggregazione di link dinamica. Normalmente, questo richiede l’intervento di un ingegnere di rete per una configurazione dettagliata.
• Balance-TLB
  Questo modo fornisce capacità di bilanciamento del carico poiché il nome TLB rappresenta bilanciamento del carico di trasmissione. Per questo modo, se la configurazione tlb_dynamic_lb = 1, allora il traffico in uscita è distribuito in base al carico attuale su ciascuno slave. Se la configurazione tlb_dynamic_lb = 0, il bilanciamento del carico è disabilitato, tuttavia il carico è distribuito solo utilizzando la distribuzione hasd. Per questo modo, l’ethtool deve supportare i driver di base per recuperare la velocità di ciascuno slave.
• Balance-ALB
  Questo modo fornisce capacità di bilanciamento del carico poiché il nome TLB rappresenta bilanciamento del carico adattivo. Simile a balance-tlb, eccetto che sia il traffico in uscita che quello in entrata sono uniti. Riceve bilanciamento del carico raggiungendo la negoziazione ARP. Il driver di bonding intercetta le risposte ARP inviate dal sistema locale mentre escono e sovrascrive l’indirizzo hardware sorgente con l’indirizzo hardware unico di uno degli slave nel bond. Per questo modo, l’ethtool deve supportare i driver di base per recuperare la velocità di ciascuno slave.

1. Nota preliminare

Per questo tutorial, sto usando Oracle Linux 6.4 nella versione a 32 bit. Si prega di notare che anche se la configurazione è effettuata sotto Oracle Linux, i passaggi sono applicabili anche a CentOS e Red Hat OS distro e a sistemi a 64 bit. Il risultato finale della nostra configurazione di esempio mostrerà che la connessione effettuata al nostro server di bonding rimarrà connessa anche se ho disabilitato 1 delle reti ethernet. In questo esempio, mostrerò come applicare il bonding di rete utilizzando il modo 1 che è la politica attiva-backup.

2. Fase di installazione

Per questo processo, non è necessaria alcuna installazione. Un’installazione Linux predefinita di un server include tutti i pacchetti richiesti per una configurazione di bonding di rete.

3. Fase di configurazione

Prima di iniziare la configurazione, dobbiamo prima assicurarci di avere almeno 2 interfacce ethernet configurate nel nostro server. Per controllare questo, vai alla cartella di configurazione di rete e elenca le interfacce ethernet disponibili. Di seguito sono riportati i passaggi:

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

Il risultato è:

ifcfg-eth0 ifcfg-eth1 

Nota che attualmente abbiamo 2 interfacce ethernet configurate nel nostro server che sono ETH0 e ETH1.

Ora configuriamo un’interfaccia di bonding chiamata BOND0. Questa interfaccia sarà un’interfaccia ethernet virtuale che contiene le interfacce ethernet fisiche di ETH0 e ETH1. Di seguito sono riportati i passaggi:

vi ifcfg-bond0

DEVICE=bond0  
ONBOOT=yes  
MASTER=yes  
IPADDR=172.20.43.110  
NETMASK=255.255.255.0  
GATEWAY=172.20.43.1  
BONDING_OPTS="mode=1 miimon=100"  
TYPE=Ethernet 

Poi esegui:

ls *ifcfg*bon*

Il risultato è:

ifcfg-bond0 

Questo è tutto. Si prega di notare che all’interno dell’interfaccia BOND0, ho incluso un indirizzo IP. Questo indirizzo IP sarà l’unico indirizzo IP connesso al nostro server. Per procedere nel processo, dobbiamo modificare l’interfaccia ethernet fisica relativa all’interfaccia BOND0. Di seguito sono riportati i passaggi:

vi ifcfg-eth0

DEVICE=eth0  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

vi ifcfg-eth1

DEVICE=eth1  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

Fatto. Abbiamo effettuato la modifica delle interfacce ETH0 e ETH1. Nota che abbiamo rimosso l’indirizzo IP all’interno di entrambe le interfacce e aggiunto MASTER = bond0. Questo è necessario per convalidare che entrambe le interfacce saranno interfacce virtuali dedicate all’interfaccia ethernet BOND0.

Per procedere con la configurazione. Creiamo un file di configurazione di bonding chiamato bonding.conf sotto /etc/modprobe.d. Di seguito sono riportati i passaggi:

vi /etc/modprobe.d/bonding.conf

alias bond0 bonding  
options bond0 mode=1 miimon=100 

modprobe bonding 

In base alla configurazione sopra, abbiamo configurato un modulo di bonding utilizzando l’interfaccia BOND0. Abbiamo anche assegnato la configurazione di bonding per utilizzare il modo = 1 che è la politica attiva-backup. L’opzione miimon = 100 rappresenta la frequenza di monitoraggio per il nostro server di bonding per monitorare lo stato dell’interfaccia in millisecondi. Come descritto sopra, questo modo fornirà funzionalità di tolleranza ai guasti nella configurazione di rete del server.

Poiché tutto è configurato, riavviamo il servizio di rete per caricare la nuova configurazione. Di seguito sono riportati i passaggi:

service network restart

Shutting down interface eth0: [ OK ]  
Shutting down interface eth1: [ OK ]  
Shutting down loopback interface: [ OK ]  
Bringing up loopback interface: [ OK ]  
Bringing up interface bond0: [ OK ] 

Eccellente, ora abbiamo caricato la nuova configurazione che abbiamo effettuato sopra. Noterai che la nuova interfaccia chiamata BOND0 sarà mostrata nell’elenco di rete. Noterai anche che non ci sono indirizzi IP assegnati alle interfacce ETH0 e ETH1, solo l’interfaccia BOND0 mostra l’IP.

ifconfig

bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0  
inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link  
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1  
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0  
collisions: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 BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) 

eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:632 errors:0 dropped:0 overruns:0 frame:0  
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB) 

lo Link encap:Local Loopback  
inet addr:127.0.0.1 Mask:255.0.0.0  
inet6 addr: ::1/128 Scope:Host  
UP LOOPBACK RUNNING MTU:16436 Metric:1  
RX packets:208 errors:0 dropped:0 overruns:0 frame:0  
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB) 

Puoi anche controllare lo stato del bonding tramite questo comando:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26 settembre 2009) 

Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth0  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 

Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0 

Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0 

Nota che sopra abbiamo convertito con successo le interfacce ETH0 e ETH1 in una configurazione di bonding utilizzando la modalità attiva-backup. È stato anche dichiarato ora che il server sta utilizzando l’interfaccia ETH0, ETH1 sarà come interfaccia di backup.

4. Fase di test

Ora che tutto è configurato come previsto. Facciamo un semplice test per assicurarci che la configurazione che abbiamo effettuato sia corretta. Per questo test, ci collegheremo a un nuovo server (o desktop Linux) e inizieremo a pingare il nostro server di bonding per vedere se si verifica una connessione intermittente durante il test. Di seguito sono riportati i passaggi:

login as: root  
[email protected]'s password:  
Last login: Wed Sep 14 12:50:15 2016 from 172.20.43.80

ping 172.20.43.110

PING 172.20.43.110 (172.20.43.110) 56(84) bytes of data.  
64 bytes from 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms  
64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms  
64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms  
64 bytes from 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms  
64 bytes from 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms  
64 bytes from 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms  
64 bytes from 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms  
64 bytes from 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms  
64 bytes from 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms  
64 bytes from 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms  
64 bytes from 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms  
64 bytes from 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms 

Durante questo tempo, torniamo al nostro server di bonding e spegniamo l’interfaccia ethernet ETH0. Di seguito sono riportati i passaggi:

ifconfig eth0

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) 

ifdown eth0 

Ora abbiamo spento i servizi per l’interfaccia di rete ETH0. Controlliamo lo stato del bonding. Di seguito sono riportati i passaggi:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26 settembre 2009) 

Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth1  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 

Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0 

Noterai che ora l’interfaccia ETH0 non esiste più nello stato di bonding. Durante questo tempo, torniamo al server di test precedente e controlliamo il ping continuo al nostro server di bonding.

64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms  
64 bytes from 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms  
64 bytes from 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms  
64 bytes from 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms  
64 bytes from 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms  
64 bytes from 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms  
64 bytes from 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms  
64 bytes from 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms  
64 bytes from 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms  
64 bytes from 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms  
64 bytes from 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms 

Ottimo, ora vedrai che anche se abbiamo spento l’interfaccia ETH0, siamo ancora in grado di pingare e accedere al nostro server di bonding. Ora facciamo un altro test. Riaccendiamo l’interfaccia ETH0 e spegniamo l’interfaccia ETH1.

ifup eth0  
cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26 settembre 2009) 

Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth1  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 

Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0 

Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0 

Poiché l’interfaccia ETH0 era già attiva, spegniamo l’interfaccia ETH1.

ifdown eth1

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26 settembre 2009) 

Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth0  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 

Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0 

Ora torniamo al server di test e controlliamo cosa succede al ping continuo effettuato al nostro server di bonding

64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms  
64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms  
64 bytes from 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms  
64 bytes from 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms  
64 bytes from 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms  
64 bytes from 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms  
64 bytes from 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms  
64 bytes from 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms  
64 bytes from 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms  
64 bytes from 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms  
64 bytes from 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms  
64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms 

Ottimo! Abbiamo configurato con successo e dimostrato che il nostro server di bonding riesce a gestire lo scenario di recupero da disastri in una condizione di failover di rete.