Archivi categoria: Senza categoria

TCP Offload: conviene davvero abilitarlo?

Di recente, dopo svariati test effettuati in laboratorio, si è deciso di aggiornare i driver delle schede di rete installate su 2 macchine Windows Server 2003 R2 (in failover cluster) , passando dai driver Broadcom a quelli Intel (cosa molto più sensata dato che il produttore delle NIC è, per l’appunto, Intel).

intelVa detto che tale scelta è stata dettata anche dal fatto che con il software di gestione del teaming  messo a disposizione da Broadcom, l’unica modalità selezionabile era il load balancing, ovvero la possibilità di transmettere/ricevere il traffico di rete “un po’ da una scheda ed un po’ dall’altra”. Fin qui nulla di male, se non fosse per il fatto che,  in caso di fault di uno dei due switch o di una delle due schede del teaming, prima che il sistema riuscisse a riconvergere sull’unica NIC ancora funzionante, si è assistito ad un tempo di disservizio randomico, che poteva variare da qualche secondo a qualche minuto. Premesso che, a mio avviso, tale comportamento era strettamente legato alla durata della cache ARP dei sistemi coinvolti, una situazione del genere non era comunque tollerabile, soprattutto per dei sistemi di importanza critica e cruciale.

A differenza di quanto assistito per il software Broadcom, grazie al software Intel, configurando le schede in modalità switch failover, si è riusciti a ridurre notevolmente i tempi di riconvergenza, portandoli a circa un secondo (ed un solo pacchetto ICMP in request timeout). Tutto molto bello, a parte il fatto che dopo aver aggiornato i driver, il sistema ha iniziato a ricevere (ed inviare) i dati troppo lentamente.

Dopo aver analizzato innumerevoli tracciati Wireshark ed aver spulciato tutta la documentazione possibile ed immaginabile, sono arrivato alla conclusione che la causa della suddetta problematica era il TCP Offload (abilitato di default).

Cos’è il TCP Offload

Il TCP Offload è stato introdotto per ridurre l’overhead (leggasi carico aggiuntivo) dei server durante la gestione del traffico di rete (il quale è aumentato in modo esponenziale rispetto alle reti TCP/IP di un trentennio addietro). Nella fattispecie, grazie alla suddetta “feature”, il traffico viene gestito direttamente dall’hardware della NIC (senza quindi passare per la CPU). Per essere più precisi, vige la regola che per ogni byte di traffico di rete gestito dal server corrisponda un carico sulla CPU pari ad un HZ, quindi si può certamente intuire quanto il TCP offload possa portare (in alcuni casi) dei benefici a livello computazionale e prestazionale.

Solitamente tale configurazione è dunque migliorativa, salvo alcune eccezioni. Ad esempio, spesso accade che il TCP offload forgi dei segmenti TCP di dimensione superiore a 64 byte, i quali vengono incapsulati (layer 2) in frame di dimensione superiore ai 1500 byte (che rappresenta la MTU di default delle reti Ethernet e quindi quella supportata nativamente dalla stragrande maggioranza dei dispositivi di rete).

Cosa succede in questo caso? Ebbene, se gli switch non sono configurati a dovere, essi scarteranno (in modo trasparente, salvo previa connessione alla CLI se si tratta di dispositivi managed) i pacchetti con MTU > 1500 byte, riducendo drasticamente il throughput dei server.

In definitiva, nel caso in cui riscontraste una lentezza anomala in TX/RX da parte delle vostre macchine, vi consiglio, come primo step, di disabilitare tale opzione.

Alla prossima.

Centos 6: realizzare un Web cluster Active/Standby con keepalived

La ridondanza in ambito sistemistico è sinonimo di affidabilità. In questo post spiegherò come creare un Web cluster (Apache) Active/Standby su CentOS 6 utilizzando keepalived. keepalivedSchema di rete

Entrambi i nodi sono connessi in LAN, utilizzando un IP della classe 192.168.1.0/24 (eth0),  rispettivamente 192.168.1.3 per il nodo master e 192.168.1.4 per il nodo slave, mentre keepalived sta in ascolto su un due interfacce di rete configurate in bonding (bond0, formata da eth1 ed eth2).  L’IP virtuale del cluster è 192.168.1.2.

Installazione e configurazione di keepalived

Per prima cosa installiamo il suddetto demone su entrambi i server mediante yum:

[root@node1 ~]# yum install keepalived
[root@node2 ~]# yum install keepalived

Ad installazione completata possiamo procedere con la sua configurazione, editando il file /etc/keepalived/keepalived.conf, il cui contenuto, per il nodo 1, dovrà essere il seguente:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node1@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_script chk_httpd {
   script "killall -0 httpd"      # verify the pid existance
   interval 2                     # check every 2 seconds
   weight 2                       # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 101                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2               # the virtual IP
   }
   track_script {
       chk_httpd
   }
}

mentre per il nodo 2 la configurazione è questa:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node2@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_scrip chk_httpd {
   scrip "killall -0 httpd"               # verify the pid existance
   interval 2                             # check every 2 seconds
   weight 2                               # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 100                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2                # the virtual IP
   }
   track_scrip {
       chk_httpd
   }
}

Si può facilmente notare come la priorità del nodo master (nodo 1) sia superiore a quella del nodo slave (priorità assegnata mediante la direttiva priority).

Affinchè il servizio Apache rimanga in ascolto su entrambi i nodi anche quando l’IP virtuale del cluster (192.168.1.2) non è fisicamente allocato sulla macchina, è necessario fare un po’ di kernel tuning, lanciando il seguente comando:

[root@node1 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
[root@node2 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

e successivamente editando il file /etc/sysctl.conf per rendere la suddetta direttiva permanente, ovvero anche dopo eventuali riavvii delle macchine, inserendo quanto segue:

net.ipv4.ip_nonlocal_bind = 1

Prove di funzionamento

Basta stoppare il servizio httpd sul nodo master:

[root@node1 ~]# service httpd stop

e successivamente verificare che l’IP virtuale del cluster sia “migrato” sul nodo slave, lanciando su quest’ultimo il comando:

[root@node2 ~]# ip addr | grep 192.168.1.2

A questo punto ritiriamo su httpd sul nodo master:

[root@node1 ~]# service httpd start

e lanciamo

[root@node1 ~]# ip addr | grep 192.168.1.2

per verificare che l’IP virtuale sia “ritornato” sulla macchina principale.

Alla prossima.

Sincronizzazione dei contenuti Web tramite rsync

Supponiamo che vi siano in produzione N frontend Web dietro bilanciatore e che quindi, ad ogni release, si renda necessario caricare i contenuti su ciascuno di essi (rendendo la vita difficile agli sviluppatori).

Ho deciso quindi di automatizzare tale procedura mediante l’uso di rsync. In soldoni, i contenuti Web verranno caricati manualmente su un unico frontend (che fungerà da server) mentre le altre macchine fungeranno da client (ovvero aggiorneranno i loro contenuti ogni X minuti consultando direttamente la macchina server).

rsyncConfigurazione della macchina server

Tale attività si articola in due fasi: la prima consiste nell’installazione e nella corretta configurazione del demone xinetd (evoluzione del celeberrimo inetd), mentre la seconda riguarda solo ed esclusivamente rsync.

Procediamo dunque con l’installazione di xinetd:

[root@front1 ~]# yum install xinetd

ed impostiamo l’avvio automatico del demone in questione per i diversi runlevel:

[root@front1 ~]# chkconfig --levels 2345 xinetd on

Posizioniamoci nella dir /etc/xinetd.d ed apriamo in scrittura il file rsync, sostituendo la direttiva:

disable = yes

con

disable = no

In definitiva, il suddetto file, dovrà avere il seguente contenuto:

service rsync
{
        disable = no
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID
}

Passiamo ora al secondo step relativo alla configurazione della macchina server, ovvero la creazione del file rsyncd.conf nella directory /etc:

[root@front1 ~]# touch /etc/rsyncd.conf

All’interno del suddetto file creeremo dei moduli ad-hoc contenenti tutte le direttive necessarie per la sincronizzazione dei contenuti tra server e client, ad esempio:

log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
[images]
   path = /var/www/html/images
   uid = root
   gid = root
   read only = no
   list = yes
   host allow = 10.12.66.0/24

Salviamo il file ed avviamo xinetd:

[root@front1 ~]# service xinetd start

Configurazione delle macchine client

Tale configurazione consiste esclusivamente nella creazione di una entry crontab del tipo:

*      *   * * *     root          rsync -avr root@10.12.66.1::images /var/www/html/images/

ovvero ogni minuto viene contattato il server (10.12.66.1, modulo images che punta a /var/www/html/images/) e viene sincronizzato il contenuto della dir del client /var/www/html/images/.

Fine del post, alla prossima.

sendmailanalyzer: visualizzare le statistiche associate al nostro server antispam

Fin’ora abbiamo visto come realizzare un server antispam in grado di bloccare circa il 99% delle email indesiderate.

Occorre precisare, però, che per rendersi conto della reale portata del problema, è necessario visualizzare (magari attraverso dei grafici ad hoc) tutte le informazioni e le statistiche associate al funzionamento del nostro sistema antispam.

Un valido tool in grado di fornirci le suddette funzioni prende il nome di sendmailanalyzer. Esso ci mette a disposizione una GUI abbastanza user-friendly, contenente tutte le informazioni utili per il monitoraggio del traffico sui nostri server di posta (spam, virus, tentativi di inoltro a domini non consentiti, ecc.).

salogoIn questo modo, riusciremo anche ad identificare facilmente eventuali falsi positivi, riducendo al minimo i disservizi dovuti al respingimento di email lecite (che però, ad esempio, provengono da indirizzi IP non dotati di PTR).

Vediamo adesso come installare l’applicativo in questione. Per prima cosa scarichiamo la tarball mediante wget:

[root@antispam ~]# wget http://sourceforge.net/projects/sa-report/files/latest/download

scompattiamo il pacchetto:

[root@antispam ~]# tar xzf sendmailanalyzer-9.0.tar.gz

e posizioniamoci nella direcotory di riferimento:

[root@antispam ~]# cd sendmailanalyzer-9.0

Prima di lanciare l’installazione vera e propria, però, occorre dotare il nostro sistema di alcuni moduli perl necessari per il funzionamento del suddetto tool. L’installazione può essere effettuata semplicemente utilizzando CPAN:

[root@antispam sendmailanalyzer-9.0]# perl -MCPAN -e 'install GD::Graph::bars3d'

A questo punto prepariamo il makefile:

[root@antispam sendmailanalyzer-9.0]# perl Makefile.PL

ed eseguiamo l’installazione vera e propria:

[root@antispam sendmailanalyzer-9.0]# make && make install

Ad applicativo installato, copiamo il demone di avvio sendmailanalyzer dalla directory /root/sendmailanalyzer-9.0/start_scripts a /etc/init.d e rendiamolo eseguibile:

[root@antispam sendmailanalyzer-9.0]# cp root/sendmailanalyzer-9.0/start_scripts/sendmailanalyzer /etc/init.d

[root@antispam sendmailanalyzer-9.0]# chmod +x /etc/init.d/sendmailanalyzer

Ora occorre configurare l’interfaccia Web. Per prima cosa modifichiamo il file /etc/httpd/conf/httpd.conf aggiungendo le seguenti direttive:

Alias /sareport /usr/local/sendmailanalyzer/www

<Directory /usr/local/sendmailanalyzer/www>
        Options ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex sa_report.cgi
        Order deny,allow
        Allow from all
        AuthName "SendmailAnalyzer Access"
        AuthType Basic
        AuthUserFile /usr/local/sendmailanalyzer/passwd
        Require valid-user
</Directory>

In tal modo abbiamo forzato l’autentica HTTP per tutti coloro che vogliono accedere all’interfaccia in questione. Adesso creiamo il file contenente la coppia username/password (quest’ultima sottoforma di digest) attraverso il comando:

[root@antispam sendmailanalyzer-9.0]# cd /usr/local/sendmailanalyzer
[root@antispam sendmailanalyzer-9.0]# htpasswd -c passwd vostroutente

Ricarichiamo la configurazione di httpd in modo da rendere effettive le modifiche:

[root@antispam sendmailanalyzer-9.0] service httpd reload

Creiamo adesso un cronjob in grado di svuotare la cache di sendmailanalyzer dopo la rotazione del file maillog associato al nostro server di posta:

0 1 * * * root /usr/local/sendmailanalyzer/sa_cache > /dev/null 2>&1

e modifichiamo il file /etc/logrotate.d/syslog (nella sezione postrotate per /var/log/spooler) in modo da riavviare automaticamente sendmailanalyzer dopo la rotazione del file di log:

/etc/init.d/sendmailanalyzer restart >/dev/null 2>&1 || true

Infine, avviamo il demone sendmailanalyzer:

[root@antispam sendmailanalyzer-9.0] service sendmailanalyzer start

ed abilitamo l’avvio automatico dello stesso dopo eventuali reboot del server:

[root@antispam sendmailanalyzer-9.0] chkconfig --levels 2345 sendmailanalyzer on

Ora la GUI sarà visualizzabile alla seguente URL:

http://vostroip/sareport

Alla prossima.