Siamo, infine, giunti alla conclusione

Transcript

1 LVS: Linux Virtual Server project Concludiamo la panoramica su LVS approfondendo la trattazione con una visione sugli strumenti di monitoraggio ed accennando a problematiche di sicurezza. Siamo, infine, giunti alla conclusione di questa miniserie sui cluster a bilanciamento di carico di rete, che in ambito Linux ha come riferimento il progetto Linux Virtual Server, progetto OpenSource che, partito nel 1999 da un idea di Wensong Zhang, ricercatore del National Laboratory for Parallel & Distributed Processing della Cina, è riuscito ad affermarsi come framework generale su cui sono state costruite molte altre soluzioni, commerciali e non. Con quest ultima puntata vorrei lasciarvi con la sensazione di completezza di soluzione. Concluderò quindi la panoramica di base dell offerta LVS andando a parlare degli strumenti amministrativi e di monitoraggio in user space; accennerò, inoltre, alle problematiche di sicurezza ed ai metodi di difesa da attacchi di tipo denial of service. Ma, alfine, quale miglior commiato del divagare su topiche relative alla predisposizione di un cluster cosiddetto ad alta disponibilità per l implementazione di servizi comuni, quali ad esempio web e ftp server? Trattasi di tematiche che possono fare la differenza in qualsiasi ambiente di qualsiasi tipo di qualsiasi realtà produttiva (e non) e che, di per sé, riconducono il sistema operativo Linux ad un ruolo trainante per il supporto infrastrutturale IT. Ovvero, tanto per essere espliciti: certe soluzioni che in ambiente proprietario costano svariate decine di migliaia di euro, in ambiente Linux funzionano, sono prestazionalmente concorrenziali ed, infine, sono GRATIS! Dall ultima volta che ci siamo sentiti su queste pagine, non ci sono stati rilasci nel codice (se non una versione per kernel 2.5), ma Joseph Mack, il curatore della documentazione, preso da sindrome documentativa acuta, ha rilasciato due versioni dell LVS-HOWTO e ben tre versioni dell LVS-mini-HOWTO tutte scaricabili dal sito di progetto: Val la pena darci un occhiata! Soprattutto per la (finalmente) maggior chiarezza espositiva per i problemi connessi alle non-arpable interfaces richieste dai metodi LVS-DR (direct routing) e LVS-Tun (IP tunelling) di cui abbiamo parlato sul numero scorso. Aggiungere un servizio L aggiunta di un nuovo servizio in un LVS cluster parte dal presupposto che la semantica client-server venga mantenuta. In generale, quindi, ipvs agirà in modo tale da far sì che: il client pensi di connettersi direttamente al server; il realserver pensi di essere stato contattato direttamente dal client. Questo, però, non è tutto. La modalità di funzionamento di un protocollo introduce altri concetti, quali ad esempio quello di servizio multiporta o di connessione persistente. Queste tematiche riguardano in particolare due fra i servizi più comuni, per l appunto l FTP e HTTP, ma sicuramente, servizi che utilizzano protocolli di comunicazione di tipo session oriented non sono scevri da queste problematiche. In generale, in ogni caso in cui la connessione ad un client debba essere assegnata allo stesso server sia per motivi funzionali che prestazionali, LVS deve trattare questa affinità di connessione in maniera particolare. Prendiamo il caso di FTP; questo è un esempio di richiesta funzionale per affinità di connessione. Il client stabilisce due connessioni con il server, una sulla porta 21 per lo scambio di informazioni di controllo e l altra sulla porta scelta per il trasferimento dei dati, solitamente la 20. Nel caso di FTP attivo, il client rende noto al server su quale porta è in ascolto ed il server utilizzerà la 20 come porta data. Il director potrebbe, quindi, esaminare il flusso dei pacchetti che arrivano dal client per ottenere la porta su cui il client è in ascolto, quindi creare una entrata nella hash table per la gestione della connessione dati in arrivo, ma nel caso dell FTP passivo, è il server a dire al client su quale porta si deve mettere in ascolto per ricevere il flusso dati. Nel caso dei metodi LVS Tunelling e di LVS Direct Routing il director interviene solo per metà della comunicazione, nella parte del collegamento client-server, per cui sarebbe impossibile per il director dedurre su quale porta avviene la comunicazione. Un altro esempio di affinità di connessione è dato dal protocollo SSL (Secure Socket Layer). Quando viene intrapresa avanzato 47

2 una connessione SSL (porta 443 per secure Web o 465 per secure Mail, ad esempio), viene creata una chiave SSL che identifica il client per ogni successiva connessione al server (nell arco di tempo di vita della chiave). Il meccanismo di persistenza LVS rende, quindi, possibile ad un client di connettersi allo stesso realserver per successive connessioni TCP. I casi in cui questo meccanismo deve essere utilizzato sono così riassumibili: necessità di mantenere uno stato della connessione sul server, ad esempio per lo scambio di chiavi HTTPS; richiesta di un servizio multiporta, come nel caso di FTP attivo e passivo o HTTP/SSL; richieste di connessione che arrivano tramite proxy che presentano differenti IP per il client per differenti connessioni TCP/IP dallo stesso client. Lo standard per il trattamento della persistant (o sticky) connection prevede un timeout della connessione (expiration time) circa 6 volte più lungo del normale default, che è di 1 minuto. Questo chiaramente comporta una prevedibile crescita della dimensione dell hash table delle connessioni di 6 volte maggiore che in presenza di connessioni non-sticky. Questo esercizio di dimensionamento dell hash table in funzione dei servizi supportati, risulta essenziale nell approntare un ambiente di produzione che debba affrontare elevatissimi numeri di connessioni. Il tuning dei valori di expiration della persistenza è un esercizio che può coinvolgere diversi fattori; si pensi ad un servizio di E-Commerce in cui il gestore vuol dare la possibilità al suo cliente, una volta autenticata la sua carta di credito, di girare liberamente fra i vari scaffali virtuali, prendersi una pausa di riflessione ed un caffè e, magari dopo una mezz oretta, decidersi a dare l ok per l acquisto del suo carrello... le problematiche prospettate travalicano la discussione L interfaccia grafica creata da VA Linux per amministrare un director LVS. Permette di gestire tutti gli aspetti principali di un cluster LVS con pochi colpi di mouse. tecnica, rientrando in quelle tematiche di cui sempre più sentiamo parlare in convegni e congressi ad alto livello e per le quali si aprono sempre più cattedre universitarie! Tanto per rinfrescare le idee, LVS si pone come soluzione di IP load balancing, ovvero come Layer 3/4 switch (si fa riferimento alla suddivisione in livelli dello stack ISO/OSI); quindi, per alcuni potrebbe sembrare inadeguato (o troppo semplicistico) per fornire una soluzione di bilanciatore a livello applicativo. Diciamo, quindi, che se avete bisogno di un application layer load balancer, le alternative sono: settare dei valori di persistenza sufficientemente elevati o lasciar perdere LVS e comprarsene uno (scelta peraltro estremamente costosa). A noi basti dire che la gestione delle suddette (ed altre) caratteristiche di servizio è realizzata a caldo in ipvs tramite la sua interfaccia ipvsadm. Per rendersi conto delle sue potenzialità, basta dare una occhiata al numero di opzioni della versione attuale: veramente impressionante! Vediamo come sia possibile adesso attivare un servizio FTP nel nostro ambiente di test LVS/DR, definendo le caratteristiche di persistenza LVS di cui abbiamo parlato in precedenza. Supponiamo che il servizio debba essere conosciuto all esterno con l indirizzo di rete ftpvip; sul director avremo allora la seguente sequenza di comandi: director# ipvsadm -A -t ftpvip:ftp -p 600 director# ipvsadm -a -t ftpvip:ftp -r g director# ipvsadm -a -t ftpvip:ftp -r g dove l aggiunta del servizio sul director (ipvsadm -A), identificato dalla coppia di valori <ipaddress:port> = ftpvip:ftp, è accompagnato dalla configurazione delle caratteristiche di persistenza con un timeout definito in 10 minuti (-p 600), mentre l aggiunta dei realserver (comando ipvsadm -a), oltre al RIP (l indirizzo privato del realserver) specifica che l algoritmo di schedulazione scelto è DR (-g). Il servizio aggiunto, a questo punto, diventa immediatamente disponibile. Volendo evitare di utilizzare la gestione a linea di comando, si può ricorrere ad una GUI tipo quella messa a punto da VA Linux (vedi figura 1). Val la pena notare che servizi, persistenti e non, possono coesistere all interno dello stesso cluster LVS e che, utilizzando il comando # ipvsadm -A -t <VIP> -p senza specificare la porta associata al VIP 1 48 avanzato

3 (o specificando come porta la 0), tutti i servizi definiti sui realserver vengono trattati con connessioni persistenti. Successivamente, sarà sempre possibile aggiungere un servizio senza specificare l opzione -p (persistence), utilizzando, quindi, entrambe le tipologie di connessione previste. Molto utili risultano anche gli utilizzi di ipvsadm come strumento di monitoraggio. Per degli esempi pratici, potete fare riferimento al riquadro 1. Infine, il salvataggio ed il ripristino delle configurazioni sul director sono garantiti da due altre utility, ipvsadm-save ed ipvsadm-restore. Strategie di difesa contro attacchi DoS Le tematiche di sicurezza di cui essenzialmente ci interesseremo riguardano eventuali attacchi DoS al director. Ogni connessione comporta la creazione di una entry di circa 128bit; una aggressione al director mediante attacco Denial of Service può, quindi, portare all esaurimento della memoria e conseguente potenziale crash del director stesso (eventualità scongiurata con le ultime Riquadro 1: monitoring di LVS Possiamo ottenere un listato delle connessioni col comando: # ipvsadm -L -c -n IPVS connection entries release di LVS). Per far fronte all annoso problema dei Denial of Service sono state implementate tre strategie di difesa: drop_entry: che elimina casualmente alcune entry della connection hash table per recuperare memoria; procedura attivabile ogni secondo, scandisce fino ad un 1/32 dell intera tabella ed elimina quei record che sono in uno stato SYN-RECV o SYN-ACK per TCP e, parzialmente, quelli in uno stato ESTABLISHED per UDP, stategia che dovrebbe essere indicata per attacchi denial of service di tipo syn-flooding: questa strategia può essere controllata dai valori della sysctl variable /proc/sys/net/ipv4/vs/drop_entry. La soglia per determinare se il sistema ha abbastanza memoria disponibile, è data dal valore (in memory page) presente nel file /proc/sys/net/ipv4/vs/amemthresh drop_packet: questa strategia elimina 1/rate pacchetti prima di redistribuirli ai realserver. La variabile rate è determinata dalla formula: amemthresh (amemthresh - available_memory) pro expire state source virtual destination TCP 01:51 FIN_WAIT : : :80 TCP 01:51 FIN_WAIT : : :80 TCP 01:51 FIN_WAIT : : :80 TCP 01:52 FIN_WAIT : : :80 TCP 01:53 FIN_WAIT : : :80 Ecco, invece, come ottenere una statistica del traffico per servizio: # ipvsadm -L --stats IP Virtual Server version (size=4096) Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes -> RemoteAddress:Port TCP :http > ccs04.sssup.it:http > ccs03.sssup.it:http ad è controllato dal valore della /proc/sys/net/ipv4/vs/drop_packet Esiste anche un always drop mode, nel qual caso il valore di rate è controllato dalla variabile /proc/sys/net/ipv4/vs/am_droprate secure_tcp: utilizza un tabella di transizione di stati per ogni connessione, stabilendo dei timeout per ogni stato; l utilizzo di questa strategia è controllata da /proc/sys/net/ipv4/vs/secure_tcp ed i timeout possono essere settati sempre nella stessa /proc directory nelle variabili timeout_*. Gli autori, per il metodo LVS-NAT, consigliano di settare timeout_synrecv a 10 (secondi). Soluzioni HA e monitoraggio Il software LVS di per sé non fornisce soluzioni di alta disponibilità, ma in realtà si presta molto bene ad essere integrato con soluzioni software esterne per il raggiungimento di piena disponibilità di servizio, prevedendo il rimpiazzo automatico, in caso di crash, di server o director. Questo non è sufficiente per parlare di alta disponibilità, che è comunque una problematica che non può essere analizzata a prescindere dal tipo di servizio posto sotto alta disponibilità. Ovvero, l alta disponibilità di un servizio NFS ha caratteristiche diverse da quelle previste per un servizio HTTP o per un Database. Ancora più semplicisticamente, l alta disponibilità non può prescindere da una serie di meccanismi a livello di file system distribuito che consentano una corretta implementazione di controllo dell accesso condiviso a stesse porzioni di disco; ovvero, possiamo parlare di alta disponibilità per un certo servizio quando si può contare su meccanismi a basso livello che consentano di utilizzare, in modo coerente, porzioni condivise di filesystem da parte di una molteplicità di sistemi, garantendo meccanismi di avanzato 49

4 2 I meccanismi di ridondanza applicabili sono molteplici. Quelli più comunemente usati, rispetto alla tipologia di crash, sono i seguenti: Uno schema che rappresenta un cluster LVS configurato per l alta affidabilità. Il director primario (master) viene monitorato dal director di backup che entra in gioco nel caso in cui il master venga a mancare. I realserver sono, a loro volta, controllati dal director che si assicura che siano disponibili e li elimina dal pool di realserver dedicati ad un determinato servizio, qualora non siano raggiungibili o non rispondano alle richieste per quel protocollo. Un esempio di monitoraggio del server LVS con ipvsadmin; con il grafico è semplice notare i picchi di utilizzo del cluster LVS. 3 Director crash: risolvibile avendo a disposizione uno o più director ridondati, sia secondo uno schema attivo/standby che, in alcuni casi, secondo uno schema attivo/attivo e facendo ricorso a strumenti di monitoraggio derivanti da studi e progetti riconducibili a tre filoni: Linux HA Project quale base di sviluppo dei codici fondamentali di heartbeating, si veda e monitoraggio, UltraMonkey che utilizza heartbeat per il monitoraggio dei director e tecniche di IP address Takeover per il ripristino in caso di crash del master director, ed infine keepalived un framework per il controllo dello stato dei director, secondo uno schema che prevede la presenza in simultanea su più director di varie istanze di gruppi di servizi virtuali, sincronizzati tramite un meccanismo di elezione dei bilanciatori che utilizza il protocollo VRRPv2, descritto in RFC2338 ( Virtual Router Redundancy Protocol ). lock e di arbitrazione di accesso, di caching e di sincronizzazione di esse ed eventualmente meccanismi di forzato spengimento di quei sistemi che possono risultare in uno stato inconsistente. Comunque, dal punto di vista delle componenti del cluster LVS, si possono verificare due tipi di fallimenti: quello relativo ad un director e quello relativo ad un realserver. Da un punto di vista di criticità, quasi certamente il primo assume ben altro peso, in quanto solitamente, partendo da una configurazione standard LVS, esiste un solo director sul quale è stato definito un servizio virtuale associato ad un VIP; se questo cade, quindi, l intero servizio viene a mancare, anche se la totalità del pool di realserver relativi potenzialmente sono in grado di continuare ad offrire servizio. Inversamente, il fallimento di uno dei realserver di un pool di N, porta ad una percentuale di fallimento di connessioni pari, nel caso di algoritmo di schedulazione round-robin lineare, a 1/N. Quindi, bassa criticità e la possibilità comunque di poter sempre intervenire a livello di director per togliere a caldo quel sistema dal pool di servizio. Realserver crash: utilizzando uno strumento di monitoraggio come mon, ldirector o, in generale, dei cosiddetti healtchecker agents, il director monitorizza i servizi posti sui realserver. Nel caso in cui il servizio su un sistema diventi indisponibile, quel server è rimosso dal pool di realserver associati al servizio virtuale, mediante utilizzo di ipvsadm. In caso di crash del director principale, pur essendo possibile trasferire automaticamente il controllo al secondario, le informazioni sulle sessioni IP attualmente 50 avanzato

5 in corso andrebbero perse. Il problema è spinoso ed è stato affrontato e risolto tramite la progettazione di un demone che serve ad effettuare la sincronizzazione dei vari director. Il demone è attivabile tramite il comando # ipvsadm --start-daemon=master --mcast-interface=eth0 sul load balancer primario e, analogamente, sarà possibile attivarlo # ipvsadm --start-daemon=backup --mcast-interface=eth0 anche su quello di backup; i due demoni, attivati dentro il kernel, usano pacchetti in ip-multicast per scambiarsi i messaggi di sincronizzazione delle code di forwarding. Sebbene non sia nostro scopo addentrarci sulle configurazioni HA, i componenti di configurazione e di integrazione citati integrano in buona parte alcune delle componenti standard di base per il monitoraggio e l heartbeat. Lo stesso script configure.pl descritto in precedenza produce un file (mon.cf) di configurazione residente sul director; questo viene utilizzato da MON, il modulo di monitoraggio scritto in Perl rilasciato con licenza GPL reperibile sul sito che consente il monitoraggio dei servizi configurati mediante chiamate ai protocolli applicativi o, quantomeno, verificando la connettibilità dei realserver; in caso di risposta negativa per uno dei servizi monitorati, altri strumenti provvedono a togliere il realserver interessato dal pool di macchine associato al servizio (in figura 2 lo schema del funzionameonto di un cluster in alta affidabilità che utilizza mon e LVS). Oltre al già citato ipvsadm, altri tool di monitoraggio sono disponibili (si veda ad esempio figura 3), anche se non strettamente correlati al problema del failover; sono per la maggior parte strumenti realizzati utilizzando meccanismi standard quali ad esempio SNMP; a tal proposito si vedano le MIBs sviluppate da Romeo Benzoni e disponibili all indirizzo: /lvs-snmp/ucd-snmp-lvs-module tar.bz2 Conclusioni In tutti gli ambiti di clustering, le potenzialità di Linux stanno ormai vincendo tutte le più radicate resistenze. Muovendosi intorno ad un gruppo ristretto di progetti OpenSource cardine, quali openmosix ed OpenSSI per soluzioni general purpose cluster, Linux HA Project e Kimberlite per cluster HA, Beowulf per cluster scientifici, LVS per il cluster di servizi a bilanciamento di carico, Linux sta sconvolgendo un mercato fino a non molto tempo fa appannaggio delle grandi case costruttrici, che presentavano soluzioni a costi irraggiungibili ai più. In questa serie di articoli abbiamo visitato tutte le caratteristiche fondamentali del progetto LVS, dalla scalabilità, con la grande flessibilità che consente altresì di far fronte a picchi computazionali difformi nel tempo senza ricorrere ad investimenti sovradimensionati, alla manutenibilità, che principalmente grazie al ricorso di indirizzi alias consente di spegnere espostare i servizi da un sistema all altro ed, infine, proprio con queste ultime pagine, alle caratteristiche di disponibilità e ridondanza. Ho a tal proposito citato alcune soluzioni di integrazione che offrono, sempre nel panorama del software di pubblico dominio, pacchetti di configurazione di cluster ridondati (UltraMonkey e KeepAlived fra tutti). LVS è un progetto con innegabili qualità, comprese quella della leggerezza, della flessibilità, della robustezza, della configurabilità, dell integrabilità e, non ultima, la grande qualità di essere gratuito! Viene allora spontaneo chiedersi: beh, e allora perchè non è ancora così diffuso? Ahimè signori, i motivi sono ben altri che quelli di natura tecnica. Dal punto di vista del produttore, si possono riassumere forse nella frase è l hardware il vero business!. Dal punto di vista del cliente, forse la risposta più significativa potrebbe essere bello sì, ma... qual è il numero verde dell assistenza?. LVS è il classico esempio di soluzione che attende. Attende che il Linux business diventi qualcosa di più che una campagna di marketing; attende che l industria si metta a pensare con un vero spirito imprenditoriale; attende che i responsabili l IT Management cerchino di modificare i loro pregiudizi; attende che il tecnico si faccia catturare dallo spirito collaborativo della soluzione aperta, dai brevissimi tempi di risposta ai problemi, nemmeno paragonabili a quelli delle soluzioni proprietarie, dall eccitazione frebbrile che prende chi si sente parte integrante dello sviluppo di una soluzione, dalla consapevolezza di avere a disposizione un codice sorgente che rappresenta sempre la più completa forma di documentazione, sul proprio software, disponibile. Quindi la soluzione LVS, ma non solo essa, attende. Ma voi? Quanto avete ancora intenzione di attendere? 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. avanzato 51