Nella prima puntata di questa mini serie, partendo

Transcript

1

2

3 LVS Linux Virtual Server Project Dopo aver presentato il progetto LVS, in questa puntata vedremo come allestire un semplice laboratorio di test perchè la teoria non rimanga vana. Nella prima puntata di questa mini serie, partendo dalla presentazione del Linux Virtual Server Project (LVS), abbiamo trattato la tematica generale dei sistemi di cluster a bilanciamento di carico. Abbiamo accennato ai possibili campi di applicabilità, a che tipo di esigenze di servizio questa soluzione è in grado di rispondere e come, in generale, esistano diversi approcci alla problematica del bilanciamento, che spaziano dal più generale problema di bilanciamento del traffico IP a quello del più specialistico bilanciamento del traffico relativo ad un particolare protocollo (richiamando in questo modo uno stretto legame con la caratterizzazione in livelli dello stack ISO OSI). Quelle del bilanciamento di carico per particolari protocolli applicativi (soprattutto quelli legati al commercio elettronico) sono tematiche tuttora oggetto di studio, ricerca e sviluppo. Esse coinvolgono ambiti anche non puramente tecnici, più strettamente attinenti alla sociologia, alla psicologia e alle dinamiche di mercato. Ma, qualunque siano i possibili risultati e le linee di tendenza che nel futuro si manifesteranno, una cosa è certa il sistema operativo Linux e la comunità dell OpenSource sono già pronti a fornire soluzioni affidabili ed efficienti. Adesso occupiamoci più specificatamente di LVS. Come anticipato nello scorso numero, in questa puntata vedremo come allestire praticamente un laboratorio di test per LVS, ovvero un piccolo cluster a bilanciamento di carico con cui iniziare a sperimentare i meccanismi proposti da questo interessante progetto. Prendendo spunto dalla massima taoista un cane non viene considerato valente perché bravo ad abbaiare, un uomo non viene considerato eccellente perché bravo a parlare, cominciamo quindi a calare le carte in tavola, procedendo nell ottica prima faccio, poi imparo. Un ultima cosa, prima di addentrarci nei meandri tecnici al momento di scrivere questo articolo, è uscito un nuovo rilascio sia di ipvs (ver , 11 luglio 2002) che della documentazione; in particolare, l attuale mini-howto (v ), reperibile su http// /mini-howto/lvs-mini-howto.html di Joseph Mack è divenuto molto più esauriente e puntuale della precedente versione e contiene, fra l altro, una utile sezione finale (per ora con solo due esempi, ma che speriamo diventi più corposa nel futuro) che rappresenta una sorta di Come Lo Feci (citazione da Frankestein Junior) scritta dagli utilizzatori stessi. L unico problema dalle 16 originali è passato a 47 pagine e con continui rimandi alla documentazione principale (ovvero il monster HOWTO); è destino, la via della conoscenza passa da tortuosi sentieri, per lo più lastricati di carta (del tipo A4 per stampanti laser...)! LVS Plug n Play raccomandazioni iniziali L occorrente per allestire un ambiente di test è veramente poco. In pratica, si tratta di fare un po di lavoro da rigattiere e andare a fare pulizia nei magazzini... Per cominciare e per darvi modo di approfondire gradualmente le problematiche e, quindi, operare le scelte giuste per la configurazione definitiva in ambiente di produzione, è buona norma attenersi a delle regole generali, dettate più che altro dal buon senso. Regola nr. 1 determinazione delle minime necessità hardware Per una dimostrazione effettiva delle capacità di LVS servono tre sistemi, un client, il director ed un realserver; per evidenziare la scalabilità della soluzione la parte dei realserver può essere dotata di più sistemi 1 director una Linux-box, patched kernel 2.2.x or 2.4.x, con 1 o 2 NIC 10 o 100 Mbps Ethernet. Non preoccupatevi delle prestazioni un Pentium I 75MHz può spedire 50Mbps di pacchetti su una PCI 33 fastethernet 100 Mbps. 1 client qualsiasi sistema operativo, che sia in grado di montare (per i nostri scopi) un client telnet. Il client non deve essere un membro dell LVS. realserver per la scelta vedere regola nr.2. Devono essere dotati di almeno una interfaccia ma, in alcuni casi, può valer la pena aggiungere NIC (anche vecchie schede di rete ISA, intermedio 43

4 al costo di qualche Euro) che semplifichino lo schema di configurazione. Regola nr. 2 scelta del tipo di forwarding Come vedremo in seguito, vi sono diversi approcci alla tecnica seguita dal director per la redirezione ai server dei pacchetti provenienti dai client. Molto brevemente, le tecniche sono LVS-DR (Direct Routing) è il default, consente alto throughput e può essere implementata sulla maggior parte dei sistemi operativi; LVS-NAT (Network Address Translation) più basso throughput e maggior latenza, richiede tuttavia che sui realserver sia presente solo una implementazione dello stack TCP/IP (quindi, potenzialmente, anche una semplice stampante di rete). È consigliabile partire da questa configurazione per approntare l ambiente di test, per evitare di dover trattare il problema delle risposte arp delle interfacce che ospitano i VIP; LVS-TUN (IP Tunneling) richiede che i realserver siano in grado di operare IP-IP Tunneling, ma può essere utilizzato quando i realserver sono su rete diversa da quella del director, con le stesse prestazioni del metodo LVS-DR. La scelta del metodo di forwarding influenza la scelta dei realserver (a livello di sistema operativo ospite); mentre per LVS-NAT non ci sono limitazioni e per LVS-TUN si può al momento scegliere solo server Linux, per LVS-DR la scelta è dettata da come il sistema è in grado di gestire la cosiddetta problematica della risposta arp, che tratteremo nel seguito. Nel nostro esempio useremo il metodo LVS-DR, che ci consente di elaborare una spiegazione più generale su come lavora LVS in un contesto che, presumibilmente, potrà essere lo stesso utilizzato in ambito di produzione. Al momento non vogliamo approfondire; una spiegazione ed un confronto sui metodi di forwarding arriveranno nel seguito. Regola nr. 3 partire da una configurazione semplice Questo in sostanza vuol dire Usare una configurazione di servizio composta da un protocollo semplice, ovvero che utilizzi una sola porta, che non utilizzi schema di persistenza sulla connessione (tipo HTTP cookie o ssl), che utilizzi codifica ASCII in chiaro e che abbia client per ogni sistema operativo. Ovvero, utilizzate telnet per le vostre prove! Verificare che il servizio scelto sia attivo sui realserver prima di attivare LVS. Se non è così, risolvete i problemi a monte. Attivate il telnetd, che di default si porrà in ascolto su tutte le interfacce e controllate che il vostro TCP wrapper consenta il collegamento almeno dal client scelto. Ricordatevi di chiudere il servizio una volta terminati i test! Usare una configurazione di rete minimale, ma chiara. Ovvero, il director ed i realserver devono condividere uno spezzone di rete, anche switched, per implementare il metodo LVS-DR. In una configurazione di test, il default gateway dei realserver può essere definito puntare direttamente al client, rendendo quindi inutile la presenza di router (come d altronde sarebbe lecito attendersi in un ambiente di test). Tuttavia, può valer la pena dotare sia il director che i realserver di interfacce aggiuntive oltre a quelle strettamente necessarie, sia per gestire il flusso di pacchetti in modo separato, sia per implementare sui realserver una non-arp interface, semplicemente mantenendo una interfaccia attiva, ma non connessa alla rete, sui cui attivare i servizi LVS. Su questo, non vi preoccupate, torneremo... Fatevi degli schemi, dei diagrammi, ed attenetevi ad essi. Questo sarà molto utile per cambiare la configurazione senza dover risalire faticosamente al corretto numero IP dell interfaccia assegnata ad un servizio sotto LVS. Poiché, vi assicuro, l appetito vien mangiando, vi troverete ben presto a file di configurazione pieni di commenti relativi ad innumerevoli tentativi di configurazione di servizi fra i più disparati. LVS Plug n Play installazione e configurazione La configurazione di un cluster LVS consiste essenzialmente delle seguenti tre fasi dotarsi di un Linux kernel patchato e configurato per A) LVS (sul director ed, eventualmente, sui realserver). Le patch per il kernel 2.2.x sono considerate a livello di produzione, così come quelle che riguardano il kernel (ver 1.0.x di ipvs). Tuttavia, la maturità del codice per il kernel 2.4.x è tale da non scoraggiarne l utilizzo come director anche con kernel 2.4 minori delle release 18 (con versione 0.9.x di ipvs). Le patch sono reperibili alla URL http// e sono organizzate come diff file per i sorgenti del kernel, ad esempio linux ipvs patch o come tarball legato alla versione del modulo, tipo ipvs tar.gz; che, al suo interno, contiene tutto quanto necessario per procedere. Una volta modificati i sorgenti, il kernel deve essere ricompilato con l abilitazione del supporto NetFilter (disabilitando il supporto di compatibilità con ipchains) e Virtual Server (figura 1). Utilizzando delle Linux-box come realserver, la scelta del metodo LVS-DR, così come per il metodo LVS-TUN, può comportare la necessità di aggiungere la cosiddetta hidden patch che permette di risolvere il problema della non-arp interface (vedi di seguito e 44 intermedio

5 puntata successiva). L utilizzo di questa patch è obbligatorio per i kernel 2.4.x. Nei kernel 2.2.x, con x<=12, nuovamente la patch si rende necessaria; Nei kernel 2.2.x, con x>12, la hidden patch era già inclusa; Nei kernel 2.0.x, per quel che può servire, la patch non è necessaria. Per sistemi Unix-like non Linux, nella documentazione e negli script di configurazione di ipvs sono riportati la maggior parte dei sistemi operativi Unix commerciali (unitamente a FreeBSD). Per sistemi MS WinNT/2000 è possibile ricorrere al MS-Loopback adapter come soluzione tecnica di interfaccia virtuale che non risponde alle interrogazioni arp, ma questi sistemi non vengono gestiti dagli scripts di configurazione di ipvs. Il metodo di reindirizzamento LVS-NAT, invece, non presenta alcun tipo di problema di configurazione, non dovendo trattare il problema della risposta arp sui realserver. compilazione ed installazione, sul director, del pacchetto B) ipvsadm. La userland administrative interface di LVS, che permette di amministrare da user space la configurazione del modulo ipvs del kernel, è l unico (potente) strumento che userete nella configurazione e nella gestione del director. È buona norma installare la stessa versione di ipvsadm e di kernel patch. Il modulo ipvs contiene nel suo albero il codice per ipvsadm e può essere compilato dopo aver apportato le patch al kernel. configurazione dell ambiente di prova; in questo caso è C) utile ricorrere allo script configure-lvs-x.x.x.pl, attualmente alla versione e che permette di produrre dei file di inizializzazione per i membri dell LVS cluster. Noi assumeremo di utilizzare questo strumento, reperibile (separatamente dal pacchetto ipvs) all URL http// 1 Altrimenti è possibile procedere a mano, creando dei piccoli script ad hoc. Nel mini-howto potrete trovarne gli esempi. Ecco qua di seguito i tre passi da seguire. Passo 1 lavorare sul kernel Riassumendo, volendo compilare l attuale versione di ipvs (1.0.4) su un kernel attuale (2.4.18), sia per la parte director che realserver, potete divenire root e seguire (non pedissequamente) i passi di seguito riportati 1) create una directory di lavoro # export DIR=/tmp/work # mkdir $DIR 2) scaricate un kernel e il modulo ipvs # cd $DIR # wget http// linux tar.gz # wget http// kernel-2.4/ipvs tar.gz 3) create un vanilla kernel tree ed aggiustate i vari link (più o meno, a secondo delle distro) # cd /usr/src # tar zxvf $DIR/linux tar.gz # rm -f linux-2.4 # ln -s linux linux-2.4 # ln -s linux linux 4) Scompattate il modulo ipvs # cd $DIR # tar zxvf ipvs tar.gz otterrete una directory ipvs il cui contenuto è il seguente (le directory sono evidenziate in rosa e in grassetto) # cd ipvs # ls ChangeLog ipvs linux_net_makefile.diff contrib linux_ip_fw_compat_c.diff linux_net_netsyms_c.diff CREDITS linux_kernel_ksyms_c.diff README doc linux_net_ipv4_config_in.diff 5) per costruire IPVS con il kernel, eseguite # export IPVSDIR=$DIR/ipvs # cd /usr/src/linux # cat $IPVSDIR/linux_kernel_ksyms_c.diff patch -p1 # cat $IPVSDIR/linux_net_netsyms_c.diff patch -p1 # cat $IPVSDIR/linux_net_Makefile.diff patch -p1 # cat $IPVSDIR/linux_net_ipv4_Config_in.diff patch -p1 # cat $IPVSDIR/linux_ip_fw_compat_c.diff patch -p1 # cp -rp $IPVSDIR/ipvs net/ipv4 # mv net/ipv4/ipvs/linux_net_ipv4_ipvs_makefile net/ipv4/ipvs/makefile quindi, nel caso vogliate utilizzare lo stesso kernel sui realserver, applicare la hidden patch, presente nella directory $IPVSDIR/contrib/patches intermedio 45

6 # cat $IPVSDIR/contrib/patches/hidden diff patch -p1 infine, compilate il nuovo kernel con tutte le opzioni già discusse # make clean; make mrproper # make menuconfig (configurare le opzioni relative al virtual server) # make modules # make modules_install # make bzimage # make install (oppure copia arch/i386/boot/bzimage e modifica {lilo o grub}.conf) # reboot Ora, il kernel così ottenuto può essere portato su altri sistemi Linux (sempre che completo di moduli e driver necessari a supportare le diverse configurazioni), in modo semplice e veloce. Prima si tutto impacchettatelo # cd /usr/src # tar zcf linux ipvs.tgz linux e ora copiatelo sul nodo B # scp linux ipvs.tgz B/usr/src quindi, come root@b, fate # cd /usr/src # tar zxvf linux ipvs.tgz # cd linux # make modules-install # make install (oppure copia arch/i386/boot/bzimage e modifica {lilo o grub}.conf) # reboot Passo 2 ipvsadm in userland Avendo predisposto il kernel, possiamo quindi compilare il tool ipvsadm. In sostanza, basta portarsi nel punto giusto dell ipvs tree Prot LocalAddressPort Scheduler Flags -> RemoteAddressPort Forward Weight ActiveConn InActConn Passo 3 configurare il cluster LVS La configurazione dell ambiente di prova seguirà lo schema mostrato in figura 2. Essenzialmente, abbiamo scelto di utilizzare una configurazione hardware minimale, in cui il director ed i realserver sono dotati di un unica NIC. In questa configurazione siamo dotati di una sola rete (privata), e i server usano come default gateway lo stesso client che compie le richieste. Questa soluzione, non certo proponibile per un ambiente di produzione, permette tuttavia di mettere in piedi un ambiente di test senza doversi preoccupare della presenza di router. L approccio scelto è quello di utilizzare una tecnica di dispatching delle richieste nota come Direct Routing (DR); pur rimandando al prossimo numero gli approfondimenti sulle tecniche di reindirizzamento dei pacchetti da parte del director, vediamo in cosa consiste il VIP, Virtual IP Address del servizio, è condiviso sia dal load balancer che dai realserver. Per il load balancer questo comporta che vi sia un interfaccia configurata (anche) con l indirizzo del VIP e che viene usata per accettare le richieste dal client; il director dovrà indirizzare direttamente i pacchetti ricevuti al realserver scelto e quindi necessita di una interfaccia configurata con un indirizzo appartenente alla LAN condivisa. Per i realserver c è invece la necessità di definire il VIP su un interfaccia che sia in grado di non rispondere alle ARP request, ovvero alla richiesta di identificazione sulla rete del possessore dell indirizzo VIP. Infatti il client, a fronte di una interrogazione arp who has VIP, tell client, deve ricevere il MAC address dell interfaccia del director (vedi schema di figura 3). Questo, sebbene possa essere risolto in vari modi sulla maggior 2 # cd $IPVSDIR/ipvs e dare il comando # make -C ipvsadm install che provocherà l installazione (in /sbin) di ipvsadm, ipvsadm-save e ipvsadm-restore, nonché delle relative man page. Per testare il software, basta eseguire ipvsadm, che compierà il check sul kernel; nel caso che il kernel non abbia il supporto ipvs o che versione di ipvsadm e di kernel ipvs layer differiscano, il comando restituirà un messaggio di errore. Altrimenti dovrebbe visualizzare qualcosa del tipo 3 # ipvsadm 46 intermedio

7 parte dei moderni sistemi operativi, può essere una potenziale fonte di problemi. I requisiti richiesti per procedere col nostro ambiente di test sono essenzialmente due Il director ed i realserver devono condividere uno stesso segmento di LAN (anche attraverso Hub o Switch); I realserver devono poter definire una non-arp alias interface. La scelta che in generale può essere utilizzata è quella di definire un alias IP sulla loopback interface. La maggior parte dei sistemi Unix permettono inoltre di utilizzare l opzione -arp all interno del comando ifconfig di configurazione delle interfacce. In presenza di Unix riottosi una, già citata, soluzione semplice (anche se poco elegante, in verità) è quella di aggiungere fisicamente una interfaccia al sistema e di tenerla sconnessa dalla rete (questa soluzione non funziona per Linux 2.4.x). Altre soluzioni, esteticamente più eleganti (ma più complicate e probabilmente meno performanti), prevedono l utilizzo di meccanismi di transparent proxy oppure, nel caso di realserver Linux, l utilizzo della già citata hidden patch. In presenza di kernel già contenenti il modulo ipvs (come nel caso ad esempio di RedHat 7.2 e 7.3), la hidden può essere aggiunta nel seguente modo (supponendo di aver scaricato l intero ipvs tarball in $IPVSDIR) cd /usr/src/linux patch -p1 <$IPVSDIR/contrib/patches/hidden-2.4.X-1.diff seguito da ricompilazione del kernel. Per nascondere le interfacce alle arp request, devono essere aggiunte le seguenti righe in qualche punto degli scripts di attivazione della vostra rete (per esempio /etc/rc.local, oppure in /etc/sysconfig/... benedetta standardizzazione!!!) # attivazione del meccanismo hidden echo 1 > /proc/sys/net/ipv4/conf/all/hidden # attivazione di hidden su lo0 (ifconfig lo8 -arp) echo 1 > /proc/sys/net/ipv4/conf/lo/hidden Le tematiche che riguardano le possibili soluzioni ed i problemi connessi alla non-arp interface possono risultare un po ostiche, ma non devono essere necessariamente trattate a questo livello. Il problema è aggirabile con varie tecniche precedentemente menzionate e, comunque, legato alla tipologia di forwarding scelta, LVS-DR. Se volete usare realserver Linux e non volete occuparvi dell arp reply, vi consigliamo di utilizzare kernel o successivi nel vostro laboratorio di test, in modo da evitare del tutto il problema, dato che i kernel forniti dalle distribuzioni standard includono già al loro interno la hidden patch. Altrimenti potete utilizzare una tipologia LVS- NAT, ben descritta nell LVS-mini-HOWTO. Il pacchetto configure-lvs_x.x.x.tar.gz (dove attualmente x.x.x corrisponde alla versione 0.9.2) contiene un utile script che, leggendo da un file di configurazione che descrive il cluster LVS ed i servizi in esso attivati, permette di produrre dei files rc.lvs_* da utilizzare, sia sul director che sui realserver, per configurare ed inizializzare ogni membro del cluster. Una volta scompattato, il contenuto della directory configure-lvs_0.9.2 appare come # ls configure configure-lvs pl lvs_dr.conf.one_nic_one_network lvs_dr.conf.one_nic_two_network lvs_dr.conf.two_nic_two_network lvs_dr.conf.two_nic_two_network.director_tp lvs_dr.conf.two_nic_two_network.director_tp.director_s_server_gw lvs_dr.conf.two_nic_two_network.forward_shared lvs_dr.conf.two_nic_two_network.realserver_tp lvs_nat.conf.one_nic_one_network lvs_nat.conf.one_nic_two_network lvs_nat.conf.two_nic_two_network lvs_tun.conf.one_nic_one_network lvs_tun.conf.two_nic_two_network mon/ rc.system_map README.configure README.rc.system_map All interno vi sono molti file di configurazione di esempio, suddivisi per metodo di forwarding e per topologia. Fra questi troverete quello che fa al caso vostro e da cui poter partire senza troppi sforzi; nel nostro caso è lvs_dr.conf.one_nic_one_network. L unico sforzo che dovremmo fare è quello di cambiare indirizzi... Quindi (figura 2), dovremo specificare i seguenti indirizzi Client IP (CIP) Director Inside IP (DIP) Virtual IP (VIP) Realserver1 IP (RIP1) Realserver2 IP (RIP2) Il file di configurazione, lvs-dr.conf, dovrebbe essere del tipo di quella riportata nel riquadro. Quindi, dalla directory principale, dare il comando #./configure lvs_dr.conf che produrrà, fra gli altri, il file rc.lvs_dr e mon_dr.cf (utilizzato questo ultimo per la configurazione del sistema di monitoraggio, basato su mon, e che viene utilizzato per le configurazioni). Come già accennato, lo script file rc-lvs_dr, eseguito sia sul director che sui server, consente di configurare il VIP, di aggiungere sul director i servizi tramite ipvsadm e di configurare le regole di Netfilter appropriate. È necessario ricordarsi di far eseguire rc.lvs_dr prima sul director e, successivamente, sui realserver. intermedio 47

8 Una volta eseguiti, il file rc.lvs_dr deve essere posto tra i file di inizializzazione del sistema, per essere rieseguito al boot. A questo punto, sul director possiamo vedere la configurazione finale # ipvsadm Prot LocalAddressPort Scheduler Flags -> RemoteAddressPort Forward Weight ActiveConn InActConn TCP telnet rr -> telnet Route > telnet Route Adesso possiamo provare dal client a collegarci al servizio definito, tramite client# telnet ottenendo il login prompt della prima macchina. Una invocazione sul director dell ipvsadm adesso produrrà # ipvsadm Prot LocalAddressPort Scheduler Flags -> RemoteAddressPort Forward Weight ActiveCon InActConn TCP telnet rr -> telnet Route > telnet Route La risposta con il prompt di login avverrà in un tempo variabile che può dipendere da molti fattori (presenza di ritardi dovuti a tcpwrapper, moduli pam di autenticazione ecc.); questo ritardo potrà essere anche di qualche minuto. Ripetendo il telnet e facendo girare nuovamente ipvsadm dovreste, adesso, essere in grado di vedere la connessione sull altro server # ipvsadm Prot LocalAddressPort Scheduler Flags -> RemoteAddressPort Forward Weight ActiveConn InActConn TCP telnet rr -> telnet Route > telnet Route Complimenti! Avete testato il vostro primo cluster LVS. La scelta del servizio (telnet) non è casuale; poiché il telnet daemon parte in ascolto su tutte le intefacce presenti sul sistema, non richiede alcuno sforzo configurativo aggiuntivo. Volendo configurare un servizio tipo httpd, ad esempio, avremmo dovuto modificare il file di configurazione del demone sui realserver per dirgli di partire sull interfaccia VIP (ossia sull interfaccia virtuale in cui il client crede che il servizio sia definito). Se volete osare oltre, niente paura il mini-howto potrà guidarvi nei passi successivi. Qualche dettaglio ancora... A conclusione di questa sessione di LVS Plug n Play è forse il caso di entrare un po più nel merito delle cose. Niente di trascendentale, per carità, ma quanto basta per togliersi di dosso questo alone di tecnomagia e comiciare ad riutilizzare la materia grigia dopo i bagordi vacanzieri e le insolazioni forzate. È interessante, ad esempio, osservare alcuni dei passi compiuti durante l esecuzione dello script rc.lvs_dr. Riportiamo alcuni dei passi iniziali della configurazione del director nel nostro ambiente di test #./configure lvs_dr.conf module ip_tables already loaded setting default policy to ACCEPT for LVS clearing iptables/ipchain rules devices Cancellate le precedenti regole di filtering, vengono aggiustate le regole di forwarding (off) e redirect (on)... set_director_ip_forwarding on vs-dr director (1 on, 0 off). set ip_forward OFF for vs-dr director (1 on, 0 off). proc/sys/net/ipv4/ip_forward 0 director is not gw for realserver leave icmp redirects on. setting icmp redirects (1 on, 0 off) /proc/sys/net/ipv4/conf/all/send_redirects 1 /proc/sys/net/ipv4/conf/default/send_redirects 1 /proc/sys/net/ipv4/conf/eth1/send_redirects 1 lvs_dr.conf LVSCONF_FORMAT=1.0 LVS_TYPE=VS_DR INITIAL_STATE=on CLEAR_IPVS_TABLES=yes #VIP line format - device[alias] IP netmask broadcast VIP=eth #DIP line format - device[alias] IP network netmask broadcast DIP=eth # SERVICE line format - proto port scheduler IP[,weight] [IP[,weight]] # Definiamo un servizio TELNET, protocollo TCP (t), porta 23 (telnet) con # algoritmo di schedulazione Round-Robin (rr) sugli indirizzi rip1 e # rip2, senza differenziare il peso fra i due sistemi (no weight) SERVICE=t telnet rr # SERVER_DEVICE configurazione RealServers Device SERVER_VIP_DEVICE=lo8 SERVER_NET_DEVICE=eth0 # SERVER_GW serve a specificare il gateway che viene utilizzato dai # RealServers per indirizzare i pacchetti di risposta al mondo esterno. # Per lo standard nelle configurazioni LVS-DR, questo NON puo essere # il director. Per un ambiente di produzione, il default gateway NON # sarà l client, ma l eventuale router a fronte del director. SERVER_GW= # CIP come Default Gateway 48 intermedio

9 Viene controllata, adesso, l esistenza del VIP e se non lo trova lo configura sulla interfaccia scelta (eth08) not found on any network devices, good adding ethernet device and routing for VIP listing ifconfig info for VIP eth08 Link encapethernet HWaddr DB427 inet addr Bcast Mask UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 Interrupt9 Base address0xb800 checking VIP is reachable from self (director) PING ( ) from (84) bytes of data. 64 bytes from icmp_seq=0 ttl=255 time=136 usec ping statistics - 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.136/0.136/0.136/0.000 ms listing routing info for VIP UH eth0 Il VIP è stato configurato, quindi, si può passare a configurare i servizi LVS; viene qui valutato se il servizio deve essere definito con la caratteristica di connessione persistente (che affronteremo negli approfondimenti del prossimo numero) e gli vengono assegnati quei parametri presenti nel file di configurazione; nel nostro caso, il file di configurazione riportava la riga SERVICE=t telnet rr , in base alla quale viene assegnato al servizio l algoritmo di schedulazione rr (round-robin) clearing ipvsadm table installing LVS services with ipvsadm initialising persistence for to N persistence for N non-persistent service on telnet checking realserver reachable from director -... director starting in ON state checking realserver reachable from director -... director starting in ON state displaying ipvsadm settings Prot LocalAddressPort Scheduler Flags -> RemoteAddressPort Forward Weight ActiveConn InActConn TCP telnet rr -> telnet Route > telnet Route Check e riconfigurazione dei gateway (se avete bisogno che il director esca verso il mondo esterno con un default gateway, configuratelo!)... checking for valid server_gw for vs-dr LVS. director_vip_device=eth08, server_gw= default gw for the vs-dr servers is NOT on director, good DIRECTOR_GW not set, good. DIRECTOR_GW= installing default gw for vs-dr deleting current default gw x.x.x.x not installing a default gw for LVS_TYPE vs-dr DIRECTOR_GW= Ripristino di eventuali regole di netfilter masquerading handled by LVS code. Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination not adding filter rules. ntpd not running, won t be restarted E con questo ci fermiamo. Non possiamo far altro che rimandare il lettore alla documentazione contenuta nell LVS-HOWTO per quello che riguarda le innumerevoli questioni su ogni possibile variazione topologica rispetto allo schema da noi adottato. Nel prossimo numero, ci introdurremo nelle tecniche di IP load balancing e forwarding presenti nella soluzione LVS. Cercheremo di approfondire varie tematiche, mostrando i vari algoritmi di schedulazione disponibili, affrontando il tema delle connessioni persistenti e mostrando come utilizzare ipvsadm per aggiungere e modificare i servizi bilanciati. Accenneremo alle tecniche di difesa disponibili contro attacchi di tipo Denial of Service e alle soluzioni architetturali adottabili per approntare un servizio in alta disponibilità. Questo non esaurirà certo le tematiche che ruotano intorno a LVS ma, di sicuro, esaurirà lo spazio concessoci dall editore! Alla prossima. note sull autore Italo Lisi - i.lisi@oltrelinux.com Laureato in Informatica all Università di Pisa, ha una esperienza circa quindicennale quale sistemista in ambito Unix. Ha lavorato su sistemi a parallelismo massivo e su architetture a cluster sia orientati al calcolo scientifico che alla realizzazione di servizi di rete. Membro auditore della Linux Standard Base (LSB), ha affrontato fin dal 1995 le tematiche di sviluppo di cluster basati su Linux; nell ambito di diverse associazioni tecnologiche, ha collaborato, per le problematiche computazionali, con progetti di ricerca in diversi settori, dall astrofisica alla fisica delle alte energie. Ha rivestito per 10 anni il ruolo di Responsabile tecnico per il Calcolo Scientifico presso il CED della Scuola Normale Superiore di Pisa. Attualmente è Responsabile del Centro Servizi Informatici presso la Scuola Superiore Sant Anna di Pisa. intermedio 49