Container: come funziona la migrazione in tempo reale

Container

Migrazione in tempo reale – fonte Jelastic

Il portale InfoQ ha ospitato recentemente un interessante post di Ruslan Synytsky (CEO Jelastic) dedicato ai container ed alla migrazione in tempo reale (live migration): il contributo cerca di spiegare nell’ordine di cosa si tratti, quali problemi risolva, come funzioni ed in quali casi di utilizzo sia possibile utilizzarla. Vediamo meglio di cosa si è parlato.

La migrazione in tempo reale consente di spostare una o più applicazioni tra varie macchine fisiche / ambienti cloud senza alcuna interruzione di servizio (downtime). Questo significa che la connettività di rete, la memoria ed il file system del container che si appoggiano all’hardware bare metal sottostante (si parla quindi di un ambiente in qui la virtualizzazione avviene via hardware e non software) raggiungeranno la nuova destinazione mantenendo inalterata la routine lavorativa. Tale approccio consente di risolvere tre principali problematiche:

  • eventuali downtime causati da operazioni di manutenzione o dall’aggiornamento dell’hardware. Gli amministratori di sistema devono solitamente trasferire ogni utente da un nodo hardware all’altro, procedura che difficilmente può essere portata a termine senza downtime;
  • ripartizione errata dei carichi di lavoro tra cluster. Nel caso in cui un nodo debba fare fronte ad una mole eccessiva di lavoro, il ribilanciamento può richiedere l’implementazione di determinati application pattern, restringendo le tipologie di workload ospitabili nel cluster;
  • problematiche varie legate alle piattaforme cloud. Sul mercato sono presenti diversi provider le cui rispettive piattaforme possono essere soggette nel medio-lungo termine a cambiamenti vari (policy, prezzi) o downtime / degrado delle prestazioni. Ne consegue che il cambio di piattaforma è una situazione tutt’altro che rara. La migrazione di un’applicazione da un cloud all’altro puà essere molto complicata.

Come funziona

Per spiegare meglio come avvenga la procedura di migrazione, Ruslan Synytsky presenta il seguente schema:

Container

Migrazione in tempo reale dei container – schema (fonte: Jelastic)

Come mostra l’immagine, ad inizio procedura l’applicazione si trova nel nodo di origine (source node, dove il container è situato in fase di pre migrazione); il trasferimento prevede innanzitutto il congelamento del container nel source node con il blocco di memoria, processi, file di sistema e connessione di rete ed il recupero dello stato del container. Solo a questo punto viene effettuata la copia nel nodo di destinazione (destination node) ed il riavvio del container congelato (unfreeze). Nel nodo di origine viene effettuata infine una veloce operazione di pulizia.

Synytsky sottolinea che l’operazione è di per sè abbastanza lineare: “recuperi lo stato [del container], ne effettui una copia ed infine il ripristino”. La tabella mostra però che tra il source node ed i destination node intercorre un periodo di congelamento (frozen time), in vista del quale bisogna opportunamente preparare le applicazioni – alcune potrebbero incontrare difficoltà una volta scongelate e riavviate, rivelandosi quindi inadatte ad affrontare tale procedura.

Una volta spiegato a grande linee come funziona la procedura, il lettore viene introdotto alle due possibili modalità di migrazione utilizzabili: pre-copy memory e post-copy memory. La prima viene riassunta dalla seguente immagine:

Cantainer

Migrazione pre-copy memory – Fonte Jelastic

La piattaforma attiva il monitoraggio (memory track) della memoria presente nel container e ne avvia il trasferimento in parallelo verso il nodo di destinazione. Una volta che la differenza tra la memoria trasferita e quella presente nel nodo di origine è minimale, vengono eseguiti i consueti passaggi (congelamento, recupero e ripristino dello stato, scongelamento, pulizia del nodo di origine).

Container

Migrazione post-copy memory – Fonte Jelastic

La seconda procedura, come suggerisce il nome, effettua immediatamente la copia ed il ripristino di una parte dello stato completando successivamente il lavoro in background.

Casi di utilizzo

Quando è consigliabile utilizzare la migrazione in tempo reale? Synytsky indica quattro casi di utilizzo:

  • operazioni di manutenzione dell’hardware. La migrazione consente di evitare l’interruzione del servizio;
  • bilanciamento del carico di lavoro. I container possono essere spostati su altri nodi hardware. Il tutto è anche configurabile automaticamente mediante specifici algoritmi e trigger;
  • alta disponibilità all’interno di zone hardware e data center. Un provider può predisporre più zone hardware all’interno di uno o più data center. Un elevato livello di disponibilità è così fruibile dal cliente che effettua la migrazione da un nodo hardware (magari sovraccarico) all’altro;
  • cambio di piattaforma cloud. La migrazione agevola il passaggio del cliente ad un’altra piattaforma cloud perchè consente di evitare procedure di riconfigurazione e redeploy.

Problematiche della migrazione in tempo reale

A fronte dei benefici elencati, anche la migrazione in tempo reale può riservare alcuni imprevisti e “colli di bottiglia”:

  • degrado delle performance durante il periodo di congelamento. Per determinate tipologie di applicazioni la fase di congelamento rappresenta un momento critico con conseguente decadimento delle performance. In base a quanto detto, non si consiglia la migrazione in tempo reale di applicazioni monolitiche e che richiedono un  elevato quantitativo di risorse.
  • In ambito Big Data e per casi di utilizzo in cui i dati sono aggiornati frequentemente (fast changing data), le latenze di rete ed il volume dei dati potrebbero ostacolare o anche bloccare la migrazione da una piattaforma all’altra.
  • Per applicazione che utilizzano API o servizi nativi di una determinata piattaforma cloud, la migrazione verso un’altro cloud potrebbe rivelarsi non attuabile.