Configurazione delle VNF

Come detto in precedenza, OSM permette di automatizzare la configurazione e riconfigurazione delle VNF. Per fare ci`o utilizza due strumenti software principali, entrambi sviluppati da Canonical: cloud-init e Juju. Il primo si occupa delle configurazioni eseguite nella fase di day 0 il secondo di quelle eseguite nelle fasi di day 1 e day 2.

Cloud-init

Le immagini Cloud sono modelli di sistemi operativi e tutte le istanze che condividono la stessa immagine sono identiche. Cloud-init permette di ini- zializzare ciascuna istanza con delle informazioni peculiari che consentono, ad esempio, di configurare le interfacce di rete e i dispositivi di archivia- zione, abilitare l’accesso mediante SSH tramite password o tramite chiavi ed eventualmente generare queste ultime. Sebbene cloud-init fosse pensa- to inizialmente per funzionare con Ubuntu, attualmente `e disponibile per la maggior parte dei principali sistemi operativi Linux e FreeBSD.

Juju

Juju `e un Operator Lifecycle Manager, OLM. Gli operators sono un approccio di automazione reso popolare in Kubernetes; un container operator si occupa di gestire gli altri container che compongono il sistema. Questo pattern pre- vede, quindi, di utilizzare software di pi`u alto livello per controllare software di pi`u basso livello; in questo modo, lavorando ad un livello di astrazione pi`u alto, la gestione del sistema in esecuzione risulta pi`u semplice.

Oltre ai servizi di base per la gestione del ciclo di vita degli operator: installazione, aggiornamento, configurazione e rimozione, Juju fornisce ser- vizi di integrazione che permettono di combinarli in maniera dichiarativa e automatizzata. Juju porta il pattern operator di Kubernetes su Windows e Linux, permettendo la gestione di app in ambienti non containerizzati.

Il software di un operator insieme ai metadati dell’applicazione che con- trolla e degli ambienti su cui pu`o essere utilizzato costituisce un pacchetto denominato charm. Nel caso in cui un charm venga messo in esecuzione su

Kubernetes verr`a installato su un container, mentre negli ambienti tradizio- nali, come server bare metal o un’istanza su Cloud pubblico, verr`a installato sulla macchina in una directory particolare.

L’ecosistema Juju `e particolarmente grande e ricco di concetti; di seguito verranno introdotti quelli principali.

Cloud Identifica una risorsa che fornisce delle istanze su cui `e possibile eseguire delle application units. Ci`o include Cloud pubblici come Amazon Web Services, Google Compute Engine e Microsoft Azure, nonch´e Cloud privati basati su OpenStack. Juju pu`o utilizzare anche ambienti che di per s´e non sono Cloud, ma che pu`o trattare come tali, `e il caso LXD2. Nei paragrafi successivi, il concetto di Cloud far`a riferimento a questa nozione.

Controller E l’istanza Cloud iniziale e rappresenta un nodo centrale di` gestione che ha il compito di mantenere lo stato di tutti i modelli, applicazioni e macchine in esecuzione sul Cloud scelto e di interagire con il Juju client (CLI). Il controller `e diverso a seconda della piattaforma Cloud scelta. Modello Un modello `e uno spazio di lavoro che permette di astrarre dal- l’infrastruttura sottostante e di pensare ad ogni componente di quest’ultima come una singola entit`a. Applicazioni, spazio di archiviazione, risorse di re- te, eccetera sono contenuti in modelli Juju. Sostanzialmente, un modello incapsula un numero indefinito di macchine su cui `e possibile, in maniera trasparente, eseguire pi`u applicazioni [3.4]. Ogni modello `e gestito da un singolo controller e ci`o permette al client di avere un unico punto di contatto con l’intero sistema. Il controller stesso esegue all’interno di un modello di cui `e l’unica istanza, eccezion fatta per il caso in cui sia abilitata l’alta dispo- nibilit`a del controller ; in questo caso, pi`u controller eseguiranno all’interno dello stesso modello.

Figura 3.4: Modelli Juju [22]

Macchina Una macchina Juju `e un’istanza Cloud che tipicamente ospita una singola application unit o un controller; per differenziare i due casi, le macchine che ospitano le application unit verranno definite regolari. In [3.5] `e mostratata una macchina regolare su cui `e eseguito un charm e un container LXD che esegue un charm. Nella figura `e possibile notare che una macchina regolare esegue due tipi di agente. Un agente Juju `e un software che pu`o lavorare a livello macchina, agente macchina, o a livello di application unit, agente unit`a. Il primo, crea e controlla i container e gli agenti unit`a che sono in esecuzione sulla macchina, questi ultimi, sono responsabili delle attivit`a relative al charm. In generale, tutti gli agenti tengono traccia dei cambiamenti di stato, rispondono a questi e trasmettono le informazioni in merito al controller. Lo stato di un modello viene creato dalla comunicazione tra un controller e tutti gli agenti in esecuzione su quel modello.

Applicazione e application unit Un’applicazione si compone di una o pi`u unit`a che rappresentano del codice in esecuzione. Diverse unit`a eseguono su macchine diverse condividendo lo stesso charm, le stesse relazioni e la stessa configurazione fornita dall’utente. Ad esempio, `e possibile lanciare un servizio su tre unit`a, in tre macchine distinte, in modo da implementare un set di repliche e garantire tolleranza ai guasti. Tra le varie unit`a che compongono un’applicazione ve n’`e una che funge da leader, ed `e la fonte autorevole in merito allo stato e alla configurazione della macchina. Ogni applicazione possiede un solo leader.

Azioni Le azioni sono script che vengono attivati tramite il client ed ese- guiti su un’unit`a. Sono descritte all’interno dei singoli charm attraverso un file actions.yaml. Ogni azione pu`o, opzionalmente, prendere in input uno o pi`u parametri.

End-point, interfacce e relazione Un end-point `e un punto di collega- mento esposto da un’applicazione per il collegamento con un’altra. `E definito da tre propriet`a: nome, ruolo e interfaccia. Un’interfaccia `e il protocollo di comunicazione utilizzato in una relazione tra le applicazioni. Gli end-point di due applicazioni aventi ruolo compatibile e la stessa interfaccia, possono essere collegati formando una relazione.

Juju in OSM Come detto pi`u volte in precedenza, Juju `e utilizzato in OSM per la configurazione dinamica in fase day 1 e day 2. OSM supporta una versione limitata di charm: proxy charms e native charms. La differenza tra i due `e che, nel primo caso il controller e i charms sono in esecuzione sulla stessa macchina, mentre nel secondo i charms eseguono sulle macchine che ospitano la VNF [3.6]. I native charms sono stati introdotti recentemente e sono ad uno stato di sviluppo primordiale, per questo motivo non verranno approfonditi ulteriormente.

Figura 3.6: Differenza tra proxy charms e native charms [43]

L’uso dei proxy charm prevede che le configurazioni da eseguire sulle VNF vengano mappate in azioni Juju che verranno poi eseguite dal charm stesso. La configurazione della VNF pu`o avvenire in diversi modi, ad esempio via SSH o tramite API REST. Il charm implementa un pattern reattivo che gli permette, non solo di rispondere all’invocazione di certe azioni, ma anche a eventi come il cambio di una configurazione; in questo modo `e possibile riconfigurare a caldo una VNF. Pi`u dettagliatamente, un proxy charm si compone di diversi layer ognuno dei quali implementa una certa funzionalit`a: • layer:basic. Importa il framework reattivo e contiene il codice di base

necessario per il funzionamento degli altri livelli.

• layer:vnfproxy. Importa le funzioni richieste per eseguire azioni nella VNF tramite SSH.

• layer:restapi. Importa le funzioni richieste per eseguire azioni nella VNF tramite API REST.

• layer:netconf. Importa le funzioni richieste per eseguire azioni nella VNF tramite Netconf.