I container stanno guadagnando popolarità nel settore enterprise grazie ad alcuni vantaggi “operativi” offerti rispetto alle classiche soluzioni di virtualizzazione mediante hypervisor. Nel post di oggi confrontiamo le due tecnologie nell’esecuzione d’applicazioni Java, cercando di scoprire gli eventuali pro di una migrazione da una all’altra.
La virtualizzazione ha rappresentato indubbiamente un traguardo fondamentale nell’hosting di applicazioni Java grazie all’isolamento garantito dalla tecnologia ed alla maggiore efficienza nello sfruttamento dell’hardware. Le macchine virtuali (VM da ora in poi) necessitano tuttavia di un OS completo, TCP e stack di file di sistema per operare correttamente, impegnando una non trascurabile quantità di memoria (RAM) e potenza di calcolo della macchina host.
La maggioranza degli hypervisor non è poi in grado di modificare “al volo” le VM (e dove possibile è richiesta una serie di complessi passaggi), riducendo il quantitativo di RAM assegnato (un valore fisso): ciò comporta l’obbligo di destinare ad ogni VM anche un quantitativo di risorse extra da utilizzare in caso di necessità (scaling) ma che, se non impiegate, rimangono sostanzialmente in stand-by ed inutilizzate; la VM stessa, non essendo in grado di isolare al suo interno varie istanze, non permette di condividere le risorse “parcheggiate” con altre applicazioni.
Tipologia di container e gestione risorse
I container, condividendo con l’host OS il kernel ed altre risorse di sistema, riescono a superare alcune delle limitazioni tecniche delle VM incidendo molto meno sull’utilizzo della RAM e della CPU. Esistono due tipologie di container: gli application container ed i system container. I primi sono paragonabili a dei semplici processi mentre i secondi si comportano come dei veri e propri sistemi operativi completi, consentendo di avviare altri processi come openssh, syslogd etc. Quando si parla di migrazione di applicazione Java, è consigliabile utilizzare questi ultimi in modo da non dovere intervenire sull’applicazione.
Abbiamo detto nel primo paragrafo che le risorse delle VM sono “congelate” e non possono essere condivise. Con i container si va oltre tale limite e le risorse non utilizzate sono facilmente distribuite tra gli altri container e workload. L’elevato grado di isolamento della tecnologia permette di utilizzare diverse tipologie di applicazioni nello stesso nodo hardware, senza che l’una interferisca con l’altra: in media i container permettono di incrementare l’utilizzo delle risorse infrastrutturali da 3 a 10 volte.
Esecuzione di applicazioni Java nelle VM
Oracle WebLogic Server all’interno di una VM – i vari componenti
Vediamo cosa comporta eseguire un’applicazione Java nelle VM analizzando il setup di Oracle WebLogic Server. Per funzionare in una macchina virtuale, il noto application server necessita di almeno tre istanze, ciascuna dedicata ad uno dei seguenti componenti:
- Administration Server grazie al quale è possibile gestire le risorse del cluster;
- Node Manager, collegato al precedente ed impiegato per aggiungere o rimuovere istanze managed server;
- Managed Server che ospitano applicazioni web, servizi web ed altre risorse.
Cosa accade quando bisogna aumentare le risorse disponibili? Prima di tutto si provvede ad aggiungere ulteriori Managed Server fino a “saturare” la RAM della VM. Nel caso in cui occorrano ulteriori risorse, si rende allora necessario: occuparsi del provisioning di una nuova VM utilizzando un template WebLogic; avviare un Node Manager nella nuova VM collegandolo all’Administration Server; aggiungere infine nuovi Managed Server. Il processo può essere ripetuto più volte.
Esecuzione di applicazioni Java in un container
Oracle WebLogic Server all’interno di container – i vari componenti
Dopo aver preparato un’immagine container con WebLogic Server si passa al provisioning delle varie istanze all’interno del container: come mostra la figura, un’istanza sarà dedicata sempre all’Administration Server mentre le altre ai Managed Server. Rispetto al setup VM si nota l’assenza del Node Manager, un elemento che risulta ora superfluo perchè rimpiazzato dallo stesso Administration Server – grazie ad una piattaforma di orchestrazione container ed alcuni script è possibile aggiungere e rimuovere Managed Server direttamente da quest’ultimo.
Quando sono richieste maggiori risorse, è possibile ridimensionare “al volo” il container e senza riavviare la macchina. I Managed Server sono gestiti ora dall’Administration Server. La figura in alto mostra come la struttura del nostro cluster sia ora meno complessa rispetto a quella di una VM.
In conclusione
Le VM presentano diversi “contro” nell’esecuzione di applicazioni Java:
- maggiore incidenza sull’utilizzo della CPU e della RAM dell’host;
- la distribuzione delle risorse non è granulare, l’aggiunta di un singolo Managed Server può richiedere infatti il provisioning di una nuova VM;
- il ridimensionamento di una VM richiede il riavvio della macchina;
- il Node Manager, espressamente richiesto dalle VM, consuma risorse extra ed aggiunge maggiore complessità al setup;
- le istanze presenti nella VM possono entrare in conflitto tra loro influendo sulle prestazioni generali; lo stesso può accadere utilizzando differenti applicazioni all’interno di una VM;
- migrare da una piattaforma cloud all’altra è problematico (le VM di un provider non sono spesso compatibili con altre piattaforme, si parla in questo caso di vendor lock-in);
Gestire la migrazione da VM a container può essere molto complicato e non alla portata di tutti. Una volta superate le avversità iniziali, offrono tuttavia diversi vantaggi:
- minore incidenza sull’utilizzo delle risorse dell’host;
- scalabilità orizzontale semplificata grazie alla rimozione del Node Manager;
- scalabità verticale. Le risorse non utilizzate possono essere condivise facilmente, il ridimensionamento del container non richiede infine il riavvio della macchina;
- possibile utilizzare diverse tipologie di applicazioni migliorando di conseguenza l’utilizzo delle risorse infrastrutturali;
- migrazione da una piattaforma cloud all’altra relativamente più semplice rispetto alle VM;
- possibilità di velocizzare ulteriormente i vari processi grazie a numerosi strumenti DevOps.
