Virtualizzazione parziale del livello Transport. ai fini della gestione della mobilità

Transcript

1 Virtualizzazione parziale del livello Transport ai fini della gestione della mobilità Relatore: Prof. Vittorio Ghini Università di Bologna - Scuola di Scienze Laurea Triennale in Informatica - II Sessione - A.A. 2013/ Dicembre 2014

2 Scenario Obiettivo Virtualizzazione parziale Architettura In questa presentazione verrà esposto un modo per utilizzare simultaneamente due generiche interfacce di rete, prendendo spunto dal modello Always Best Packet Switching (ABPS) e ricorrendo ai principi della virtualizzazione. Lo scopo principale è fornire un supporto alla mobilità senza apportare modifiche al software utilizzato e ai sistemi operativi di entrambi i lati della comunicazione.

3 Scenario Obiettivo Virtualizzazione parziale Architettura Scenario Un dispositivo mobile è connesso alla rete attraverso segnale wi-fi. Successivamente il dispositivo esce dal raggio d azione wi-fi e si riconnette alla rete tramite segnale UMTS. Il passaggio da segnale wi-fi a UMTS provoca la chiusura del canale di comunicazione.

4 Scenario Obiettivo Virtualizzazione parziale Architettura Obiettivo Controllare il traffico di rete di una o più applicazioni al fine di utilizzare l interfaccia di rete più conveniente, senza generare interruzioni o frammentazioni della comunicazione. Ad esempio, il traffico generato da un applicazione VoIP può essere indirizzato verso l interfaccia di rete disponibile al momento senza che l utente si accorga dello switch di interfaccia.

5 Scenario Obiettivo Virtualizzazione parziale Architettura Virtualizzazione parziale A differenza della Virtualizzazione totale, che simula completamente l hardware, la Virtualizzazione parziale è limitata solo ad alcune componenti hardware di un sistema: - estende le funzionalità del sistema Application sottostante; Partial Virtual Machine Host Operating System - rende possibile la coesistenza di applicazioni destinate a diverse piattaforme; - fornisce backward compatibility e Host Hardware portabilità; Tuttavia non permette l esecuzione di un intero sistema operativo ma solo gruppi di applicazioni.

6 Scenario Obiettivo Virtualizzazione parziale Architettura System Call Virtual Machine: UmView UmView, appartenente al progetto View-OS, è un esempio di System Call Virtual Machine modulare. In questo caso la virtualizzazione avviene tramite intercettazione delle system call sfruttando le funzionalità di ptrace(). Ogni modulo si occupa di intercettare una determinata famiglia di system call, ad esempio umnet gestisce le socket call. A sua volta, ogni modulo ha a disposizione dei sottomoduli, ognuno dei quali fornisce una diversa reimplementazione delle system call. Lo scopo è quello di personalizzare la visione che un processo ha delle risorse di sistema.

7 Scenario Obiettivo Virtualizzazione parziale Architettura Architettura generale user space umnet umview umnetdif monitor Applicazione socket call eth wlan ppp tun0 - applicazione avviata all interno di UmView; - sottomodulo umnetdif che reimplementa le system call di rete; - monitor che controlla lo stato delle interfacce fisiche e comunica con umnetdif; - interfaccia virtuale tun0 vista dall applicazione;

8 Scenario Obiettivo Virtualizzazione parziale Architettura Il sottomodulo umnetdif In questo progetto è stato creato un sottomodulo per UmView denominato umnetdif 1 che, in base allo stato delle interfacce fisiche (monitor), sceglie l interfaccia più adatta a trasmettere/ricevere pacchetti. L applicazione comunica esclusivamente attraverso l interfaccia virtuale di default tun0, mentre umnetdif si occupa di - reimplementare le system call di rete intercettate dal modulo umnet - smistare i pacchetti attraverso interfacce fisiche 1 umnet Double InterFace

9 Architettura di umnetdif Reimplementazione delle System Call Gestione degli eventi asincroni: Event Subscribe Architettura di umnetdif umnetdif SockHT PTh MMTh umnetdif Utils Poll Utils op system libc hashtab Socket API poll() KEY: uses A B - MMTh: thread principale per reimplementazione system call e comunicazione con monitor; - PTh: thread secondario per gestione degli eventi asincroni; - SockHT: hash table per gestione socket descriptor virtuali;

10 Architettura di umnetdif Reimplementazione delle System Call Gestione degli eventi asincroni: Event Subscribe Reimplementazione delle System Call Nel Module Main Thread (MMTh) avviene la reimplementazione che si svolge in tre fasi: 1. fase iniziale: - dichiarazione variabili e allocazione strutture; - recupero da SockHT del file descriptor virtuale associato a quello fornito dal processo chiamante; 2. fase centrale: la system call viene chiamata una volta per ogni interfaccia disponibile in base alle informazioni fornite da monitor; 3. fase finale: analisi e restituzione del risultato al chiamante secondo alcune politiche prestabilite (eventualmente modificabili).

11 Architettura di umnetdif Reimplementazione delle System Call Gestione degli eventi asincroni: Event Subscribe proc umview umnet umnetdif syscall(fd,...) umnet_syscall(fd,...) type umnetdif_syscall(int generic_fd,...) { /*fase iniziale*/ real_fd[] = get_real_sock(generic_fd); } /*fase centrale*/ for(i=0;i<2;i++) { rv[i] = syscall(real_fd[i],...); } /*fase finale*/ ret = policy(rv[0],rv[1]); return ret;

12 Architettura di umnetdif Reimplementazione delle System Call Gestione degli eventi asincroni: Event Subscribe Gestione degli eventi asincroni: Event Subscribe UmView è un processo single-thread, quindi una chiamata a system call bloccante porta al blocco totale della macchina virtuale finché non si verifica l evento atteso (es: dati pronti per essere letti). Per questo motivo è stato necessario creare un secondo thread, Poll Thread (PTh), il cui scopo è quello di: - monitorare in background i file descriptor dei socket aperti; - gestire le richieste da parte di umview per monitorare determinati file descriptor; - inviare una notifica ad umview nel momento in cui si verifica l evento atteso.

13 di connessione di concorrenza di connessione Connessione in uscita - Processo client in umview instaura una connessione con un processo server esterno usando l interfaccia virtuale; - Il sottomodulo crea due connessioni verso il server, una per ogni interfaccia fisica; Connessione in entrata - Processo server in umview resta in attesa di una connessione da un processo client esterno usando l interfaccia virtuale; - Il sottomodulo accetta due connessioni dal client, una per ogni interfaccia fisica; Risultato: il processo vede solo la connessione virtuale. Quindi il sottomodulo permette di gestire due connessioni simultanee esponendo solo quella virtuale, raggiungendo l obiettivo prefissato.

14 di connessione di concorrenza di concorrenza Si usa un processo client composto da due thread per studiare il comportamento di chiamate bloccanti concorrenti. connect() simultanee - i due thread, sequenzialmente 2, tentano di instaurare una connessione ognuno verso un host differente (host1, host2); - una regola per iptables rende irraggiungibile host1; - Risultato: finché non scade il timeout di connessione per thread1 non è possibile connettere thread2. A differenza dei precedenti, il test ha purtroppo messo in evidenza un limite di umview, infatti più chiamate concorrenti a connect() vengono serializzate. Questo problema non si presenta nel caso di altre chiamate bloccanti come read()/recv*(). 2 a distanza di 0.1 sec l uno dall altro

15 Sviluppi futuri Sviluppi futuri - Risoluzione dei problemi riscontrati in fase di testing; - Integrazione di umnetdif con monitor; - Creazione effettiva di una interfaccia virtuale tun0; - Rendere il sottomodulo scalabile sul numero di interfacce fisiche; - Estendere supporto ad altre Address Family e supporto per IPv6; - Porting del sottomodulo su piattaforma Android;

16 Sviluppi futuri The End