Migrazione consapevole dello stato nell'applicazione mobile Edge

Stateful vs. statelKubernetes è architettato come una collezione di microservizi per governare il ciclo di vita dei container che attiva la migrazione stateless grazie alla sua caratteristica di orchestratore di container. Tuttavia, alcuni microservizi possono fare molto affidamento sullo stato interno; di conseguenza, la migrazione stateless porta all'interruzione del servizio. Di conseguenza, studiamo la migrazione stateful come tecnica per supportare la mobilità dei microservizi salvando lo stato e riducendo al minimo le interruzioni del servizio. Poiché la migrazione stateful è un processo complicato, poiché ha un impatto sullo stato del contesto della CPU e sulla connessione TCP, proponiamo un approccio alternativo che combina la migrazione stateless con una tecnica di diffusione dello stato. Impieghiamo la migrazione stateless per i microservizi, ma manteniamo lo stato attraverso la distribuzione di esso tra le istanze multiple dei nodi di edge computing. Per raggiungere questo obiettivo di distribuzione dello stato, esaminiamo varie tecniche basate su un livello garantito di coerenza e proponiamo una valutazione delle prestazioni. In questo caso, valutiamo le prestazioni di etcd come soluzione popolare per soddisfare la distribuzione dello stato in tutto il cluster fornendo un livello di coerenza forte e poi lo confrontiamo con OrbitDB come tecnica per garantire un livello di coerenza più debole. Pertanto, presentiamo tre architetture: Centralizzata, Reattiva e Proattiva per implementare la nostra proposta di migrazione stateless con conservazione dello stato. Abbiamo poi implementato uno scenario di test realistico per evidenziare i loro compromessi in termini di prestazioni. Nell'approccio Centralizzato, sebbene l'etcd sia centrale in un host senza bisogno di migrare, esiste un singolo punto di guasto. In Reactive, l'etcd rimane all'interno dello stesso host del microservizio, il che è ideale per il consumo di risorse, ma i tempi di migrazione sono più lunghi. Infine, in Proactive, abbiamo molti nodi con allocazione di CPU perché avere istanze etcd in ogni nodo è necessario senza dover migrare lo stato che garantisce una migrazione rapida, ma abbiamo un elevato overhead di consenso. In conclusione, sulla base dei nostri risultati, è chiaro che questa soluzione è fattibile, facile da realizzare, efficace e semplice da implementare utilizzando solo le funzionalità fornite da kubernetes. Alla fine, abbiamo misurato la durata dell'interruzione del servizio causata dalla migrazione; per esempio, negli approcci Centralizzato e Proattivo, questa durata è molto bassa rispetto a quello Reattivo. Sebbene la nostra soluzione sia semplice da ottenere, c'è un impatto sul throughput del microservizio a causa dello stato distribuito; dobbiamo considerare condizioni di rete realistiche e l'overhead introdotto dall'algoritmo di consenso per garantire la distribuzione dello stato.ess migration for stateful mobile applications.