Steve Bohac, Openshift Container Storage Product Marketing di Red Hat, offre utili suggerimenti per identificare la corretta piattaforma storage per i container. Ci confrontiamo con molte realtà che hanno adottato o stanno adottando pratiche DevOps. Per la maggior parte, affrontare i disagi significa non solo disporre di nuove applicazioni, ma ottimizzare (o cambiare!) attuali processi e sistemi. Si passa a culture team-based, lavorando con incrementi minori e automatizzando gli ambienti per cercare di aumentare la velocità di sviluppo e implementazione del software.
Avere un approccio comune allo storage che sia “self-service” e che permetta agli sviluppatori di fare il provisioning e gestire lo storage per le loro applicazioni vuol dire che i team sono sottoposti a minori limitazioni nello sviluppo e delivery delle stesse. Per il team operation, una piattaforma coerente per sviluppo, test e messa in produzione rappresenta un vantaggio significativo. E il self-service per gli sviluppatori significa che i team operation possono riservare meno tempo al provisioning di servizi e dedicarne di più ad attività a valore a vantaggio del business. Quindi, lo storage persistente per i container rimane un tema caldo. Mentre i container sono ottimi per archiviare l’applicazione e la sua logica, non offrono una soluzione integrata per conservare i dati della stessa lungo l’intero ciclo di vita del container.
Perché le tradizionali soluzioni storage non sono adatte ai container? Un container può operare per giorni, ore, minuti o addirittura secondi, a seconda di come l’applicazione è stata architettata. E possibile ‘buttare’ i container, ma non i dati. Lo storage effimero (o locale) non è ottimale perché le applicazioni stateful hanno bisogno che i dati dei container siano disponibili ben oltre la vita del container. Richiedono inoltre che lo storage sottostante offra tutte le funzionalità enterprise disponibili (scalabilità, supporto multiprotocollo, mirroring, stretched cluster, ecc) alle applicazioni implementate, ad esempio, in ambienti virtuali. Si tratta di una considerazione importante dato che in molti ambienti i container host girano sulle macchine virtuali (VM) – bisogna quindi essere in grado di offrire le funzionalità di storage persistente necessarie alla virtualizzazione, così come quelle richieste dai container.
Un approccio è quello di avvalersi di appliance storage tradizionali che supportano le applicazioni legacy. Un’inclinazione e presunzione naturale, ma… errata. Le appliance storage tradizionali si basano su architetture obsolete e non sono state pensate per il mondo delle applicazioni container. Oltre a non offrire la portabilità necessaria alle app nell’attuale ambiente hybrid cloud. Alcuni di questi storage vendor offrono software aggiuntivo per i container che può essere impiegato come cuscinetto tra queste appliance storage e l’orchestrazione dei container, ma si tratta di un approccio minato dalle limitazioni delle appliance storage stesse e significa inoltre che lo storage per i container viene fornito separatamente (team diversi, UI diverse, strumenti, ecc) dallo strato di orchestrazione del container.
E lo storage software-defined per i container? E’ la soluzione migliore! O meglio, gli storage container che contengono software storage in grado di co-risiedere con i compute container e distribuire lo storage dagli host dotati di storage locale o diretto ai compute container. Questi storage container vengono implementati con lo stesso strato di orchestrazione utilizzato dagli sviluppatori, proprio come i compute container. In questo scenario, i servizi storage vengono forniti impiegando software storage containerizzato per riunire ed esporre in modo semplice e immediato lo storage da local host o direct attached storage alle applicazioni containerizzate.
Perché le tradizionali soluzioni storage non sono adatte ai container?
