Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

3.2. LVS tramite un instradamento diretto

As mentioned in Sezione 1.4.2, «Instradamento diretto», direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
Struttura della rete
In una impostazione per il routing LVS diretto, il router LVS avrà bisogno di ricevere le richieste in entrata e direzionarle al real server corretto per una loro processazione. I real server a loro volta dovranno instradare direttamente le risposte al client. Ciò significa che se il client è su internet ed invia il pacchetto ad un real server attraverso il router LVS, il real server dovrà essere in grado di contattare direttamente il client attraverso internet. È possibile eseguire tale processo attraverso la configurazione del gateway per il real server, in modo da passare i pacchetti ad internet. Ogni real server nel pool dei server, può avere un proprio gateway separato (e ogni gateway può avere un proprio collegamento ad internet), permettendo una portata e scalabilità massima. Tuttavia per impostazioni LVS tipiche i real server possono comunicare attraverso un gateway (e quindi un collegamento di rete).

Importante

Non è consigliato utilizzare il router come gateway per i real server, in quanto è possibile creare una impostazione più complessa e non necessaria, insieme ad un carico di rete sul router LVS, i quali daranno luogo a limitazioni presenti nel NAT routing.
Hardware
I requisiti hardware di un sistema LVS che utilizza un instradamento diretto sono simili ad altre topologie LVS. Mentre il router LVS necessita di eseguire Red Hat Enterprise Linux per processare le richieste in entrata ed eseguire il bilanciamento del carico per i real server, i real server non hanno bisogno di essere machine Linux per funzionare correttamente. I router LVS necessitano ciascuno di uno o due NIC (se è presente un router di backup). Potrete utilizzare due NIC per facilitare la configurazione e per separare in modo netto il traffico — le richieste in ingresso vengono gestite da un solo NIC, ed i pacchetti indirizzati ai real server gestiti dal secondo.
Poichè i real server bypassano il router LVS ed inviano i pacchetti in uscita direttamente ad un client, sarà necessario un gateway per Internet. Per una massima disponibilità e prestazione, ogni real server può essere collegato alla rete portante alla quale il client è collegato (come ad esempio Internet o intranet).
Software
There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using LVS via direct routing. Refer to Sezione 3.2.1, «Instradamento diretto e arptables_jf» or Sezione 3.2.2, «Instradamento diretto e iptables» for more information.

3.2.1. Instradamento diretto e arptables_jf

In order to configure direct routing using arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
Utilizzando il metodo arptables_jf le applicazioni potrebbero legarsi ad ogni VIP o porta, serviti dal real server. Per esempio, il metodo arptables_jf permette a istanze multiple di Apache HTTP Server di essere eseguite esplicitamente su VIP diversi del sistema. L'utilizzo di arptables_jf comporta vantaggi significativi in termini di prestazione rispetto all'opzione iptables.
Tuttavia utilizzando il metodo arptables_jf i VIP non potranno essere configurati per avviarsi al boot, utilizzando i tool di configurazione del sistema di Red Hat Enterprise Linux.
Per configurare ogni real server in modo da ignorare le richieste ARP per ogni indirizzo IP virtuale, seguite le fasi di seguito riportate:
  1. Create le entry della tabella ARP per ogni indirizzo IP virtuale su ogni real server (il real_ip è l'IP usato dal director per comunicare con il real server; spesso è l'IP bound per eth0):
    arptables -A IN -d <virtual_ip> -j DROP
    arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    
    Ciò permetterà ai real server di ignorare tutte le richieste ARP per gli indirizzi IP virtuali, modificando qualsiasi risposta ARP in uscita che potrebbe contenere l'IP virtuale se non modificata, contenendo invece l'IP reale del server. L'unico nodo che dovrebbe rispondere alle richieste ARP per qualsiasi VIP, risulta essere il nodo LVS attivo.
  2. Una volta completato questo processo su ogni real server, salvate le entry per la tabella ARP digitando i seguenti comandi su ogni real server:
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    Il comando chkconfig causerà il ricaricamento della configurazione di arptables al momento dell'avvio da parte del sistema — prima dell'avvio della rete.
  3. Configurate l'indirizzo IP virtuale su tutti i real server utilizzando ifconfig per creare un alias IP. Per esempio:
    # ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
    Oppure utilizzando la utilità iproute2 ip, per esempio:
    # ip addr add 192.168.76.24 dev eth0
    Come precedentemente riportato, gli indirizzi IP virtuali non possono essere configurati in modo da aviarsi al boot utilizzando i tool di configurazione del sistema di Red Hat. Una soluzione a questo problema potrebbe essere quella di posizionare i suddetti comandi in /etc/rc.d/rc.local.
  4. Configure Piranha for Direct Routing. Refer to Capitolo 4, Configurazione dei router LVS con Piranha Configuration Tool for more information.