Capitolo 8. Networking
Col tempo lo stack di rete di Red Hat Enterprise Linux è stato aggiornato con numerose funzioni di ottimizzazione automatizzate. Per la maggior parte dei carichi di lavoro le impostazioni di rete auto-configurate forniscono una prestazione ottimale.
In molti casi le problematiche relative alle prestazioni sono causate da un funzionamento non corretto dell'hardware o per un errore dell'infrastruttura. Questi casi non vengono affrontati nel documento poichè le soluzioni e le problematiche discusse in questo capitolo, sono utili per l'ottimizzazione di sistemi con un funzionamento corretto.
Il Networking è un sistema molto delicato che contiene diverse sezioni con connessioni molto sensibili. Ecco perchè la community della open source e Red Hat investono gran parte del loro lavoro per ottimizzare automaticamente le prestazioni della rete. Per questo motivo dati i carichi di lavoro potreste non aver bisogno di riconfigurare il networking per migliorare le prestazioni.
8.1. Miglioramenti delle prestazioni di rete
Red Hat Enterprise Linux 6.1 apporta i seguenti miglioramenti delle prestazioni di rete:
Receive Packet Steering (RPS)
RPS abilita una coda
rx del NIC singola in modo da avere il proprio carico di lavoro softirq distribuito tra diverse CPU. Questa impostazione aiuta a prevenire la congestione del traffico di rete sulla coda dell'hardware NIC singola.
Per abilitare RPS specificare i nomi di destinazione delle CPU in
/sys/class/net/ethX/queues/rx-N/rps_cpus, sostituendo ethX con il nome del dispositivo corrispondente al NIC (per esempio eth1, eth2) e rx-N con la coda di ricezione del NIC specificato. Ciò permetterà alle CPU specificate nel file di processare i dati dalla coda rx-N su ethX. Quando specificate le CPU prendete in considerazione il cache affinity della coda [4].
Receive Flow Steering
RFS è una estensione di RPS e permette all'amministratore di configurare una tabella hash popolata automaticamente quando le applicazioni ricevono i dati e vengono interrogate dallo stack di rete. Così facendo verranno determinate le applicazioni che ricevono ogni sezione di dati della rete (in base alle informazioni della rete source:destination).
Utilizzando queste informazioni lo stack di rete sarà in grado di programmare la CPU ottimale per la ricezione di ogni pacchetto. Per configurare RFS usare i seguenti parametri:
/proc/sys/net/core/rps_sock_flow_entries- Usato per controllare il numero massimo di socket/flussi che il kernel è in grado di dirigere verso la CPU specificata. Questo rappresenta un limite condiviso da tutto il sistema.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt- Usato per controllare il numero massimo di socket/flussi che il kernel è in grado di dirigere verso la coda di ricezione specificata (
rx-N) su di un NIC (ethX). Da notare che la somma di tutti i valori per-coda per questo parametro su tutti i NIC, deve essere uguale o minore a quello di/proc/sys/net/core/rps_sock_flow_entries.
Diversamente da RPS, RFS permette sia alla coda di ricezione che all'applicazione di condividere la stessa CPU durante la processazione del flusso di pacchetti. Questa impostazione in alcuni casi migliora le prestazioni. Tuttavia questi miglioramenti dipendono da fattori tipo gerarchia della cache, carico dell'applicazione ecc.
Supporto getsockopt per TCP thin-stream
Thin-stream è un termine usato per indicare i protocolli di trasporto dove le applicazioni inviano dati ad una velocità così bassa che i meccanismi di ritrasmissione del protocollo non risultano completamente saturi. Le applicazioni che utilizzano protocolli thin-stream eseguono un trasporto usando protocolli affidabili come TCP; in molti casi queste applicazioni forniscono servizi di tipo time-sensitive (per esempio stock trading, giochi online, sistemi di controllo).
Per servizi "time-sensitive" la perdita dei pacchetti può essere devastante per la qualità del servizio. Per prevenirla è stata migliorata la chiamata
getsockopt che ora supporta due opzioni aggiuntive:
- TCP_THIN_DUPACK
- Per thin stream, questo valore booleano abilita l'attivazione dinamica delle ritrasmissioni dopo un dupACK.
- TCP_THIN_LINEAR_TIMEOUTS
- Per thin stream, questo valore booleano abilita l'attivazione dinamica dei timeout lineari.
Entrambe le opzioni sono attivate dall'applicazione. Per maggiori informazioni consultare
file:///usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt. Per maggiori informazioni sui thin-stream consultare file:///usr/share/doc/kernel-doc-version/Documentation/networking/tcp-thin.txt.
Supporto Transparent Proxy (TProxy)
Il kernel supporta ora i socket UDP e IPv4 TCP assegnati non-localmente per il supporto del transparent proxy. Per poterlo abilitare configurare iptables in modo adeguato. Sarà necessario altresì abilitare e configurare correttamente la politica di instradamento.
Per maggiori informazioni sui transparent proxy consultare
file:///usr/share/doc/kernel-doc-version/Documentation/networking/tproxy.txt.
[4]
Prendere in considerazione il cache affinity tra una CPU ed un NIC significa configurarli in modo da condividere la stessa cache L2. Per maggiori informazioni consultare Sezione 8.3, «Panoramica sulla ricezione dei pacchetti».
