evaluation of docker as edge computing platform
TRANSCRIPT
Advanced Computing LabAugust 2015
Bukhary Ikhwan Ismail [email protected] Mostajeran Goortani [email protected]
Mohd Bazli Ab Karim [email protected] Ming Tat [email protected]
Sharipah Setapa [email protected] Jing Yuan [email protected]
Dr. Ong Hong Hoe [email protected]
Evaluation of Docker as Edge Computing Platform
This Paper
ProblemCurrently, no suitable Edge Computing platform
Paper Objective1. Identify Requirements for Edge Computing
platform2. Evaluate Docker
Content1. Introduction2. Edge Computing3. Docker4. Requirements, Evaluation & Gap5. Conclusion
Introduction• What is Edge Computing?
– Deemphasizing - Centralized and to become decentralized.– Opportunity - Leveraging resources that is closer to user. – Handles/balancing - Data & Processing.
• Other terms – Fog Computing, Virtual Cloudlet, Mobile Cloud etc. – Overlapping objective – “closer to the user”.
Introduction
Why Edge? Not just cloud?- User QoE bad- General problem - response
time, latency, bandwidth
How EC solve?- One hop away.- De-emphasize on centralized–
Pushing/balancing data or service.
EC values?- New service category, business
model.- LBS, IoT , data caching, big data,
sensors mon
Cloud vs. Edge – the opportunity
Requirements Cloud EdgeGeo-distribution Centralized Distributed
Distance client and server Multiple hops One hopLatency High Low
Delay Jitter High Very lowLocation awareness No Yes
Support mobility Limited SupportedLocation of service Within the Internet At the edge
* Taken from CISCO Blog.
“IoT, from Cloud to Fog Computing,” 2015. [Online]. Available: http://blogs.cisco.com/perspectives/iot-from-cloud-to-fog-computing. [Accessed: 26-Jun-2015].
• What it is?– Containerization technology– Application level virtualization– LXD, LXC, OS virtualization
• Benefits– Small footprint– Lightweight– Portability
• Original Objective– PaaS, Application deployment, Sandboxing
• .
Docker
Docker - Versus
HYPERVISOR CONTAINER
Virtualizing server- allowing multiple OS
Virtualizing OS - allowing multiple workloads
Good Less
High – dedicated/assigned resources
Lower - sharing certain portions of the host kernel and OS
Stable – production ready. Not new - *Oracle, HP and IBM have been using containers
Objective
Isolation
Overhead
Status
Fundamental requirements of Docker1. Service Deployment & Termination - Basic needs
– Compute power multiple form factor – Geo-distributed– Fast & easy to manage – low footprint.
2. Resource & service Management– Resource discovery service– Uncontrolled environment.– Heterogeneous – Resource come & go
3. Fault Tolerance – for infra & services– FT for infra– FT facilities for service
4. Caching - Data & App– Service (to improve application response time)– Infrastructure ( to improve deployment time)
REQ 1:Service Deployment & Termination
Requirement Evaluation Gap
compute power - Support multiple form factor. - Low compute footprint. Occupies 10 – 15% of host
resources.- Coexist in user devices - minimal.
Android, some initiative.
Geo-distributed - Able to manage resources. - Clustering available e.g. Swarm.
- Hierarchical management of Edge sites
Easy to Managee.g. - Fast
Deployment- easy to install,
configure, deploy.
Service Deployment - Service registry a.k.a. (marketplace)- Small image & no boot time - Fast deployment.
Resource management- Docker available to most Linux distros- Highly Portable- Small image – store deltas.- Clean teardown – does not affect host. - Multi-tenant environment – ok.
Service Deployment- Service discovery across
edges.
Resource management- Resource discovery across
edges.- Windows based Docker is not
supported.
REQ 2:Resource & Service Management
Requirement Evaluation Gap
Resource discovery service
Swarm support multiple resource discovery services. No discovery across multiple edge sites
Uncontrolled environment.
- Ownership, trust- How to enable cross-
organizational resource sharing.
Resource come & go
- Swarm support discovery- Detects failing or leaving devices
- service and data should be balance.
- launch new service even with minimal expected performance.
- New Resource available – to increase user’s QoE gradually by scaling existing service.
REQ 3:Fault Tolerance
Requirement Evaluation Gap
Fault tolerance on infra
- Support multiple zones – failovers, DR .
FT facilities for service. Support 99.999% minimal
- Loosely coupled - single-app per-container basis.- CRIU – check-pointing on containers For application
that does not support state-less transactions.- Offline migration – to import export container.
- redeploy affected service (s) at different host or location e.g. another edge.
REQ 4:Caching
Requirement Evaluation Gap
Service - improve application response time
- Using Flockers - a shared space between containers volume.
- Replication of data via replicating volume
Which data to cache
Infrastructure - improve deployment time
- Caching app in host, local registry Which app to cache
Conclusion
• Docker – fast deployment.– Small footprint– Multi-tenant
• Good platform to start with
• Lots of Gap - opportunity for research
16