Continuando nel nostro excursus

Transcript

1

2 LVS: Linux Virtual Server Project Continuiamo l analisi del progetto LVS focalizzando l attenzione sulle tecniche di forwarding dal director verso i realserver. Continuando nel nostro excursus su LVS, la soluzione OpenSource per la realizzazione di cluster a bilanciamento di carico, è giunto il momento di entrare nel dettaglio di alcuni aspetti tecnici. In particolare, esamineremo le tecniche di forwarding dei pacchetti, ovvero le tecniche utilizzate dai bilanciatori di carico per smistare verso i server reali, il traffico di rete proveniente dai client. Tanto per riprendere il filo del discorso, riassumiamo brevemente quanto già trattato. Nel corso delle precedenti puntate abbiamo visto come i network load balancing e gli application load balancing cluster possono venir incontro a svariate esigenze: quella di disponibilità, nel senso di ridondanza e uptime di servizio; quella di scalabilità, nel senso di crescita prestazionale del sistema totale organizzabile in modo flessibile e dinamico, anche per far fronte a picchi computazionali per periodi di tempo limitati; quella di manutenibilità del servizio, in cui il fermo di una parte del sistema non inficia, se non in termini prestazionali, la funzionalità generale di esso. Avendo detto che cosa fa e a che cosa serve un cluster a bilanciamento di carico di rete, siamo poi passati a costruirne uno, minimale invero, tramite la soluzione LVS. Nella puntata scorsa, partendo da un architettura composta da tre sistemi in cluster LVS (un bilanciatore, o director, e due macchine di servizio, o realserver) più un client esterno, abbiamo definito un servizio TELNET bilanciato che figurava al client attraverso un unico Virtual IP Address (VIP). Il client, collegandosi a quell indirizzo, otteneva alternativamente la login prima di un realserver poi dell altro. Comunque, per chi si fosse perso le puntate precedenti, il riferimento principale da cui partire è il sito di progetto: Da lì potete scaricare tutta quanta la documentazione (a proposito, l ultimo monster HOWTO è stato rilasciato in settembre), il software ed avere una collezione di link utili per chi volesse continuare l esplorazione. E mentre sarete già impegnati a cliccare sul vostro browser saltando da un sito all altro, noi proseguiamo nel nostro cammino alla scoperta di LVS. Prima di proseguire facciamo un passo indietro... Ricapitolando le topiche di installazione e configurazione già trattate, l implementazione del director richiede una Linux box dotata di una o più schede di rete, ma senza che si rendano necessarie particolari configurazioni allo scopo di ottenere prestazioni soddisfacenti (per una dettagliata discussione sugli aspetti prestazionali, si veda l HOWTO). La macchina può montare qualsiasi Kernel, 2.2.x o 2.4.x (anche il 2.0.x, volendo), dove comunque il sorgente del pacchetto ipvs (che contiene tutto l insieme di codice necessario per approntare il cluster LVS) cambia in funzione della scelta. Il kernel deve essere quindi patchato con la versione del codice ipvs relativa, compilato e quindi reso disponibile per il boot. Esistono poi, per varie distribuzioni, kernel già predisposti ed in questo caso basta operare un cambiamento alla configurazione di boot del director. Il tarball dell ipvs contiene anche ipvsadm, l interfaccia utente a LVS. ipvsadm permette di compiere tutte le operazioni di configurazione dinamica dell LVS e di monitorare lo stato delle connessioni, attive ed inattive, in corso. Nella directory contrib del tarball c è uno script Perl, configure.pl, che permette la creazione di file rc.lvs, che lanciato prima sul director poi sui realserver, produce una completa configurazione dell LVS cluster. Ci sono alcune limitazioni per l uso del configure script, ma a scopo di test risulta essere di grande utilità. Il configure prende come argomento 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. 50 avanzato

3 un file contenente una descrizione di configurazione del cluster LVS e produce in output il succitato file rc.lvs, contenente l insieme di comandi ipvsadm e ipchains/iptables (per le regole di network filtering) ed i settaggi del proc filesystem necessari per l implementazione della configurazione descritta nel file. rc.lvs deve essere eseguito sia sul director che sui realserver, essendo in grado di capire dal nome dell host quale ruolo il sistema riveste all interno del cluster e quindi quale tipo di comandi applicare per la corretta configurazione. Nel file di configurazione è contenuta, fra l altro, la descrizione del comportamento del bilanciatore, sia per quanto riguarda la scelta del metodo di redirezione dei pacchetti che dell algoritmo di schedulazione con il quale i realserver vengono selezionati. Queste tematiche sono appunto l argomento di questa puntata. Dentro LVS: che cosa realmente fa il director Il director è una sorta di router molto semplice, dotato di speciali routing table dedicate alle funzioni dell LVS. Queste routing table sono utilizzate per reindirizzare i pacchetti ai realserver per quei servizi che sono stati sottoposti al controllo LVS. Il director prende decisioni a livello IP layer, semplicemente analizzando il flusso dei pacchetti fra client e realserver; di questi pacchetti vengono analizzate le sole informazioni IP contenute negli header. Per dare una connotazione più tecnica, potremmo dire che il director è assimilabile ad un Layer 4 switch. Riprendendo la definizione contenuta nella letteratura tecnica, un L4 switch determina il path di un pacchetto basandosi sulle informazioni contenute al livello 4 della strutturazione a 7 livelli del protocollo OSI. In pratica, nel contesto Internet, le informazioni a nostra disposizione consistono nell indirizzo IP, la porta ed il protocollo di rete utilizzato, TCP/IP o UDP/IP. Questo basta per effettuare un bilanciamento di carico essendo in grado, grazie all insieme di informazioni desunte, di gestire le caratterizzazione di connection affinity necessarie per la gestione di connessioni persistenti, e di cui parleremo nel seguito. Tuttavia questa definizione, all interno della stretta formalizzazione dello standard OSI, può non essere corretta. Infatti, lo strato IP, sul quale viene operato lo switching da parte del director, è a livello 3 (L3). Al di là di questi accademismi, che francamente possono solo solleticare una forma di rifiuto inconscio (almeno per me, che non ho mai capito in fin dei conti a che servisse la stratificazione OSI oltre che a far rompere il capo a qualche migliaio di poveri studenti), una cosa rimane certa: il director comunque opera limitandosi ad ispezionare le informazioni contenute negli header dei pacchetti, e non prende decisioni basandosi sull analisi del contenuto dei pacchetti. Ovvero, se il pacchetto contiene ad esempio un http cookie, il director non se ne accorge. Quindi il director non conosce alcunché delle applicazioni che hanno generato il flusso dei pacchetti, poichè non ne ispeziona il contenuto (che invece si trova a layer 7, tanto per gradire). Non essendo un L7 switch, non è capace di fornire session management o servizi basati sul contenuto del pacchetto. Tuttavia le capacità L7 possono risultare molto utili per diversi contesti applicativi, tant è che una linea di sviluppo in tal senso è stata aperta: si veda ad esempio KTCPVS, Kernel TCP Virtual Server, reperibile all indirizzo: /ktcpvs/ktcpvs.html che implementa un layer7 switch in Kernel space. Oppure, divertitevi a scartabellare fra le soluzioni commerciali e non elencate in: /Site_Management/Load_Balancing/ Comunque, l estrema semplicità come L4 switch del director è anche un suo punto di forza. Infatti, il director non rappresenta dal punto di vista prestazionale un collo di bottiglia, poichè il suo scarso uso di risorsa computazionale fa sì che, solitamente, le limitazioni sul numero di pacchetti reindirizzati dal director siano frutto non dell utilizzo intensivo di CPU, bensì delle limitazioni dell architettura hardware del PC (bus PCI, ad esempio) o del media di rete, mentre LVS non aggiunge latenza significativa o modifiche sostanziali ai valori di throughput nell operazione di forwarding dei pacchetti normalmente compiuta. Dentro LVS: metodi di forwarding dei pacchetti ai realserver Il director, nel suo lavoro di reindirizzatore del traffico entrante, usa tre metodi di forwarding, che comportano scelte differenziate per far fronte a differenti problematiche: LVS-NAT, basato su Network Address Translation (NAT), ovvero traduzione degli indirizzi di rete, dove il director è il nodo da cui passa tutto il traffico fra client e realserver (figura 1). LVS-DR, basato su Direct Routing, dove i realserver rispondono direttamente ai client senza passare dal director, ma per far questo devono condividere uno stesso spezzone di LAN con esso (figura 2). LVS-Tun, modifica di VS-DR basata sulle capacità di IP-Tunneling dei realserver, rispetto al suo predecessore permette ai realserver di risiedere anche su reti remote (in questo caso lo schema è del tutto analogo a quello di LVS-DR). Nel metodo LVS-NAT, il director rappresenta il punto in cui passano tutti i pacchetti nella comunicazione bidirezionale fra client e realserver. Questo metodo, che è basato sull implementazione del CISCO LocalDirector, prevede avanzato 51

4 che i pacchetti in entrata siano intercettati dal director e che vengano da esso riscritti con l introduzione dell indirizzo di destinazione di uno dei realserver e quindi ad esso rinviati. Le repliche del realserver sono mandate al director, che nuovamente riscrive il pacchetto introducendo l indirizzo sorgente del VIP. I vantaggi di VS- NAT sono essenzialmente due: ogni realserver può ospitare qualsiasi tipo di sistema operativo con stack TCP/IP funzionante; è richiesto un solo IP address per il director, mentre tutta la parte dei realserver può essere posta in rete privata. L unico svantaggio derivante da questo metodo è che il director è di fatto il gateway per tutti i realserver. Questo potenzialmente limita il numero dei realserver utilizzabili, poichè tutti i pacchetti di richiesta e risposta devono essere riscritti dal load balancer. Pur non essendo facilmente identificabile un numero limite, è possibile che con circa 20 nodi di servizio il director diventi un collo di bottiglia. Il metodo LVS-DR è basato sul NetDispatcher dell IBM. NetDispatcher, utilizzato come web-farm front side, permette di virtualizzare l intero set di web server come unico web site agli occhi dei client. Questa soluzione è stata utilizzata ad esempio per l implementazione del sito web delle Olimpiadi di Atlanta e Sydney (con dietro, però, architettura di classe supercomputer) In questo schema (figura 2), il director ed i realserver devono condividere uno stesso pezzo di rete, anche switched. Inoltre, i realserver devono poter rispondere direttamente ai client, quindi le risposte non devono passare attraverso il director. Infine, solo il director deve essere in grado di rispondere ad un client arp request relativo al VIP (ovvero alle tipiche richieste Who has VIP, tell Client deve arrivare a quest ultimo la sola risposta del director); tutti i realserver devono avere definito il proprio VIP su interfacce configurate in modo da non produrre risposte arp. In questo modo, il solo MAC address associato al VIP fornito ai client sarà quello dell interfaccia del director, ed in questo modo è realmente mantenuta la consistenza del protocollare di connessione client-server. I vantaggi di questo metodo sono da ricercare nelle prestazioni e nella scalabilità. Ogni realserver risponde direttamente al client, utilizzando potenzialmete route distinte per ogni server. Rispetto al metodo NAT, il bilanciatore di carico può quindi supportare un elevato numero di nodi server (fino a circa un centinaio, si presume) senza degrado delle prestazioni generali. Gli svantaggi possono essere diversi: prima di tutto, la necessità di configurare il VIP sui server su non-arping device; in secondo luogo, la necessità di far condividere uno stesso spezzone di LAN al director e ai server. Infine, il vincolo che i pacchetti di risposta dal realserver non debbano passare per il director può essere un problema ove il director stesso svolga anche funzioni di firewall. L ultimo metodo LVS-Tun, è una rivisitazione dell LVS-DR, che attraverso tecniche di IP-tunneling, permette di ottenere una distribuzione WAN dei realserver. Ovvero, il director ed i server possono essere su reti distinte (si pensi ad esempio ad un insieme di ftp mirror distribuiti in nazioni diverse). Il tipo di tunneling adottato è IP su IP (IPIP tunneling), e l incapsulamento del datagram di richiesta da parte del client 52 avanzato

5 viene operato dal director, con indirizzo destinazione il real IP address del server scelto. Il server, ricevuto il pacchetto, recupera il datagram originario e quindi l indirizzo del client, a cui risponderà direttamente. I vantaggi del metodo sono quelli dell LVS-DR, con l aggiunta del rilascio del vincolo di condivisione di un interfaccia sulla stessa LAN per il director ed i realserver. Gli svantaggi possono essere così riassunti: ogni realserver deve supportare l IPIP tunneling (e quali altri sistemi operativi oltre Linux lo consentono?); i router di ogni realserver devono essere programmati per far passare le richieste provenienti dal director e contenenti nel campo sorgente il VIP; normalmente queste richieste vengono bloccate dai router come conseguenza di regole anti-spoofing; l IP tuneling comporta un sovraccarico sia sul director che sui server. In tabella 1 riportiamo un confronto fra i vari metodi elencati, rispetto a caretteristiche salienti sul lato server, quali particolari richieste per il sistema operativo ospite, vincoli topologici di rete, numero di server supportati ed infine network gateway richiesto per fornire la risposta ai client. A completamento, cerchiamo di tabella 1 capire più in dettaglio come il metodo LVS-DR, ovvero quello scelto per la nostra installazione di test, gestisca il packet forwarding da director a realserver. Riconsideriamo la nostra configurazione di prova come riportato in tabella 2. Con LVS-DR, la richiesta sulla porta 23 (telnet) del VIP ( ) sul director sarà reindirizzata alla porta 23 del VIP sul realserver; il director per far questo manderà un arp request per ottenere l indirizzo MAC del realserver scelto, diciamo , ed ottenuto il MAC gli manderà un pacchetto link-layer (senza associare la porta, quindi) contenente un IP datagram con indirizzo sorgente (CIP:12345), destinazione (VIP:23) e dati. Il realserver riceve l IP datagram, guarda nelle sue routing table, riconosce il VIP come indirizzo locale e quindi lo tratta, mandando la replica al client (CIP:12345) attraverso il proprio default gateway. In questo processo è cruciale l utilizzo di non-arping device. Infatti questo permette ai realserver di avere nelle proprie routing table una entry locale per il VIP senza che le altre macchine possano vederla, ossia le altre macchine non hanno risposta alle arp request per il VIP. Il trattamento del cosiddetto arp problem nel metodo LVS-DR/TUN può avere diverse soluzioni e, nel caso di realserver basato su Linux 2.4.x richiede LVS-NAT LVS-DRouting LVS-Tunneling Server OS qualsiasi non-arp device IPIP tunneling Server Network privata LAN LAN/WAN Numero Server basso (10-20) alto (> 100) alto (> 100) Server Gateway director proprio router proprio router tabella 2: Regole di forwarding director# ipvsadm IP Virtual Server version (size=4096) Prot LocalAddress: Port Scheduler Flags -> RemoteAddress: Port Forward Weight ActiveConn InActConn TCP : telnet rr -> : telnet Route > : telnet Route l introduzione di una patch, la hidden patch, che permette appunto di impedire l arp-reply sulle interfacce scelte e la cui installazione è stata trattata nel numero precedente. Invito comunque gli interessati a leggersi la documentazione per scoprire quante altre interessanti soluzioni alternative possono essere considerate. Dentro LVS: Director IP Load Balancing Il director è implementato per mantenere in kernel space sia la componente di schedulazione dei servizi virtualizzati che la componente di controllo. L amministrazione della configurazione del load balancer viene effettuata tramite il package ipvsadm, operante in user space (figura 3). Il director mantiene in memoria sia la Tabella di Regole (VS Rules Table) determinata dalla configurazione dell LVS, sia la Connection Hash Table, ovvero la tabella delle connessioni effettuate dai clients ai servizi bilanciati. Ogni entry in questa tabella occupa 128 byte di memoria per ogni connessione TCP o UDP ed ogni connessione ha associata un hash key composta dalla tripla: <protocollo,indirizzo - client,porta> È inoltre prevista la manipolazione delle richieste ICMP, trattamento che esula comunque dalla discussione, ma necessario per l implementazione delle politiche di monitoraggio e fault tolerance. Il dimensionamento delle voci presenti nella Connection Hash Table limita comunque la possibilità di crescita incontrollata dell occupazione di memoria, anche in presenza di numerose stale connection e di situazioni di attacco Denial of Service (tipo SYN/FIN flood), anche grazie alla presenza di alcuni algoritmi per la ripulitura di voci relative a stale connection. La Tabella delle Regole di forwarding (tabella 2) deriva dai settaggi operati mediante l interfaccia ipvsadm. Con ipvsadm, vengono associati ad ogni avanzato 53

6 servizio da bilanciare (quindi ad una porta o ad un gruppo di porte) il metodo di forwarding, gli indirizzi dei realserver che supportano il servizio e, infine, il metodo di schedulazione con il quale effettuare il bilanciamento del carico. Gli algoritmi di schedulazione per il bilanciamento del carico implementati correntemente sono: Glossario dei termini utilizzati Round Robin (rr): le nuove connessioni sono assegnate ai realserver in modo ciclico, uno per volta. Ad esempio, con tre realserve denominati A, B e C l algoritmo rr fornirà la sequenza: ABCABC... Questo tipo di algoritmo risulta il migliore quando tutti i server hanno identica configurazione. Dopo avervi abbandonato a voi stessi nello scorso numero, eccoci di nuovo con le pillole di saggezza, le nughe di sapienza, le fiammelle di luce che vi condurranno sulla via dell elevazione iniziatica. Ormai giunti sulla soglia dell essere insigniti del Cavalierato del Bilanciato, Affidabile e Disponibile Gran Sistema Distribuito, il Gran Maestro si rivolge a voi con preziosi suggerimenti interpretativi del linguaggio cripto simbolico di cui trasudano queste pagine. ARP (Address Resolution Protocol): è un protocollo utilizzato per risolvere gli indirizzi IP nell indirizzo fisico del dispositivo di rete MAC (Media Access Control); MAC (Media Access Control) address: un indirizzo di rete a livello link, che è usato per comunicare con altri adattatori di rete all interno della stessa sottorete. Ogni adattatore di rete ha associato un proprio MAC address, del tipo 00:01:A7:07:09:DE; Connection affinity: laddove la sessione del protocollo applicativo è caratterizzata da elementi che tuttavia sono determinati mediante diverse connessioni fra client e server; esempi tipici di protocolli con affinità di connessione sono FTP passivo (ove la porta data è determinata sul lato server e quindi comunicata al client) e HTTP/SSL (dove l autenticazione del client dipende dalla durata della chiave SSL scambiata con il server nella fase di presentazione, o handshake, iniziale); Persistence connection: una configurazione per il bilanciatore di carico (director) nel cluster LVS, che permette di dirigere richieste multiple che derivino da uno stesso client sempre allo stesso server del cluster. Viene utilizzato per supportare all interno di un LVS cluster quei protocolli applicativi che utilizzano connection affinity, ovvero laddove ci sia bisogno di mantenere uno stato duraturo delle caratteristiche di sessione.; HTTP cookie: un pacchetto d informazione spedita da un server HTTP ad un browser Web e quindi spedito dal browser a quel server ad ogni successiva connessione. Il cookie può contenere informazione arbitraria, utilizzata dal server per mantenere uno stato della sessione nonostante la mancanza di stato delle transazioni HTTP. Tipicamente utilizzati per autenticare gli utenti senza richiedere in continuazione le credenziali ad ogni accesso al sito, sono di fondamentale importanza nelle applicazioni di e-commerce per implemetare ad esempio il carrello della spesa o per le personalizzazioni derivanti dalla determinazione degli usi abituali dell utente, mediante tracciamento degli accessi a quel sito; Datagram: una quantità di dati indipendente che contiene informazioni sufficienti per essere instradata dal computer sorgente a quello di destinazione; director: nella nomenclatura LVS, è il sistema Linux destinato al compito di bilanciamento del traffico (richieste di servizi su TCP/IP o su UDP/IP) in entrata, smistandolo verso un insieme di server (realserver) che ospitano il servizio richiesto. Il director è l unico sistema del cluster LVS in grado di rispondere alle richieste arp per il VIP; Real server: sono sistemi dotati di stack TCP/IP e sui quali è possibile attivare un servizio di rete definito nella configurazione del LVS cluster. In alcuni casi i realserver devono sottostare ad alcuni vincoli riguardo alla scelta del sistema operativo ospite (come nel caso delle caratteristiche di IPIP tunneling per il metodo VS-Tun o le non arp interface del metodo VS-DR), ma in generale possono essere sistemi di qualsiasi tipo; VIP (Virtual IP Address): un indirizzo IP che è condiviso fra diversi nodi di un LVS cluster, ed usato dai client come indirizzo per un servizio. Un LVS cluster può ospitare molti VIP, ognuno dei quali è associato ad un servizio di rete ed è legato ad un sottoinsieme di realserver. Weighted Round Robin (wrr): come il precedente, ma ad ogni realserver viene associato un peso per modificare la sequenzialità della scelta. Ad esempio, assegnando i pesi 3,2 e 1 rispettivamente ai realserver A,B e C, la sequenza potrebbe essere: ABCABA... Il wrr scheduling algorithm è particolarmente utile quando i realserver differiscono dal punto di vista prestazionale, oppure quando un realserver offre più di un servizio. Least Connected (lc): le nuove connessioni sono indirizzate al server con minor numero di connessioni. Pur non coincidendo con un real load balancing, questo algoritmo è un buon passo in questa direzione. Weighted Least Connected (wlc): variante del precedente con l introduzione di pesi. Altri algoritmi di schedulazione come ad esempio DH (Destination Hash, progettato per webcache) o SH (Source Hash, utilizzato per la gestione di firewall multipli). Lo sviluppo di teniche di schedulazione è senz altro destinata a crescere, proporzionalmente alla diffusione ed all uso di LVS come strumento di servizio, ma la vera sfida è passare da un load balancing sul numero e tipo di connessione ad un load balancing basato effettivamente sull applicazione, ovvero uno schedulatore dinamico in grado di prendere decisioni del tipo per la presente richiesta di connessione al servizio Web, qual è la macchina con minor carico in questo istante all interno del pool di realserver?. In questo senso, la sfida continua. E noi ci risentiremo sul prossimo numero, con approfondimenti su temi very hot, quali configurazioni in alta disponibilità, tecniche di difesa da attacchi DoS e strumenti per il monitoraggio di utilizzo del servizio bilanciato, oltre a miscellanea varia. 54 avanzato