More Related Content
What's hot
What's hot (20)
Similar to Dynamic module deployment in a fog computing platform
Similar to Dynamic module deployment in a fog computing platform (20)
Recently uploaded
Recently uploaded (20)
Dynamic module deployment in a fog computing platform
- 1. Dynamic Module Deployment in a Fog Computing Platform Hua-Jun Hong, Pei-Hsuan Tsai, and Cheng-Hsin Hsu Department of Computer Science, National Tsing Hua University, Taiwan
- 2. Motivation ▸Internet of Things (IoT) grows rapidly ▸Produce incredible amount of data • Overload the data centers and congest the networks seriously 2
- 3. Limitations of Current Solution 3 Analyze and Compute Data in Data center Huge Amount of Overload Networks and Data Center
- 4. Better (Our) Solution ▸Pre-processing the data before transmitting them over the Internet • Reduce the network traffic • Reduce the load of data centers 4REPORT
- 5. ▸Fog computing leverages devices in data centers, edge networks, and end devices simultaneously ▸Centralized controller Master End devices, edge networks, data centers Minions Fog Computing Overview 5 Data Centers Edge Networks End Devices
- 6. ▸Many kinds of resources • Computations, communications, storage, and sensors ▸Utilize wasted resources ▸Reduce network traffic ▸Short response time ▸Low cost ▸Low carbon foot print ▸… Advantages: Fog >> Cloud 6
- 7. Challenges ▸Different requests need different modules • Need dynamic deployment mechanism ▸Limited resources of the minions • Split applications into smaller modules for requests • Collaborate and connect the minions to finish a request ▸Huge amount of requests • An optimal algorithm to serve more requests 7
- 8. ▸Real-time plate recognition ▸Path estimation • Turn right! ▸Dynamically deploy the car tracking modules! Car Tracking Usage Scenario 8 Images Real-time Computation! Dynamic Deployment! Split the complex application into smaller modules! Path Estimation!
- 9. ▸Virtualized modules are easier to be • Dynamically placed on the minions • Migrated among the minions ▸Traditional virtual machine v.s. container • Xen, KVM • LXC, Docker Dynamic Deployment Mechanism 9
- 10. ▸Traditional Virtual Machine • Need large storage space and more computing power ▸Container: light-weight VM • Need less storage space and less computing power Traditional VM v.s Container 10 Virtual Machine Container Size GB MB Startup Minute Second
- 11. ▸OpenStack • Used to manage virtual machines in data centers ▸SaltStack • Remote execution tool and configuration management system ▸Kubernetes • Automating deployment, scaling, and management of containerized applications Open-source Platforms 11
- 12. ▸Each minion hosts several containers, can be assembled into pod ▸A service is a group of pods that are running on the cluster Kubernetes Architecture 12 Minion 1 Minion 2
- 13. ▸Push virtualized modules to minions quickly ▸Replace modules directly when algorithm is updated Kubernetes-based Fog Computing Platform 13
- 14. Module Deployment Problem Formulation 14 Decision variable: whether module m is deployed on minion d module m is only deployed on a minion resource constraints determines if a module has been deployed Objective function: maximizes the number of satisfied requests
- 15. O ( + + )|R|( ) Module Deployment Algorithm 15(|R|log(|R| ) |D|log(|D|) |D||M| = max {O (|R| log(|R| )),O (|R| |D| (log(|D| )+|M| ))}
- 16. ▸Implement three modules • Image collector • Face detector • Crowdedness monitor Module Implementation 16 Master Minions
- 17. ▸Master: i5 CPU PC installed with Kubernetes ▸Minions: Raspberry Pis ▸Network Emulator: Wonder Shaper[1] • WiFi (300 Mbps): stream data among the minions • 4G (150 Mbps): pushing container images to the minions ▸Master executes the module deployment algorithm • MDA algorithm • Optimal algorithm (OPT) using CPLEX[2] for comparisons Experiment Setup 17[1] http://lartc.org/wondershaper/ [2] http://www-03.ibm.com/software/products/en/ibmilogcpleoptistud/
- 18. ▸Running face detection with/without container • Virtually zero overhead Container Overhead 18
- 19. ▸Serve 20 requests only needs 9 seconds Fast Deployment Time of the Implemented Testbed 19
- 20. ▸Largest gap of satisfied requests between the MDA and OPT algorithm is only 2% Near-Optimality of the MDA Algorithm 20 2%
- 21. ▸20 Requests and 5 Minions • OPT: 80 seconds • MDA < 1 second ▸We conduct another experiment • MDA algorithm computes 1000 requests with 500 minions < 2 seconds The MDA Algorithm Computes in Real Time 21
- 22. ▸Using ifconfig to measure the network traffics Amount of Network Traffics 22 Image collector Face detector Crowdedness monitor 49.04Mpbs 2.67Mpbs 0.5Mpbs REPORT 49.04Mpbs
- 23. ▸We implemented a fog computing platform for dynamically deploying modules on fog minions • Formulate the problem and propose an efficient Module Deployment Algorithm (MDA) • Build a real testbed to evaluate our algorithms and the dynamics of the fog computing platform Conclusion 23
- 24. Q&A
Editor's Notes
- Hello everyone , I am Pei Hsuan Tsai from National Thing Hua university, the topic I am going to present is about fog computing
- The motivation of this paper is because the internet of things grows rapidly in recent years, you can see IOT every where such like smart home, smart factory or smart city Here is a research result from Gartner, the line chart is below, it says that the number of IOT devices will increase to 20 billions in 2020 So, We can imagine that the incredible amount of data which produced by IOT devices will Overload the data centers and congest the networks really seriously
- Just like this, we have IOT devices everywhere now, So the data center has to analyze and compute huge amount of data, since IOT devices send all the data here, Hence, the networks and the data center will be overloaded
- To solve this problem, we have a solution We propose an better approach, which pre-process the data produced by IOT devices before transmitting them over the Internet For example, assume we have several raspberry pis as IOT devices, and one of them captures an image, if we send this image directly to the data center, then the size of data will be around 5MG, but if we pre-processing the image in local to get the result first, such like the number of people or the plate of car in this picture, then the size of data will reduce to around 10 Byte According that, we can see the pre-processing idea will reduce the network traffic and the load of data centers significantly
- And to achieve the concept of pre-process, we implement the Fog computing platform (記得按動畫) The fog computing extend the devices from colud to the end devices, it leverages devices in data centers , edge networks, such as router, WiFi AP, and end devices, such as laptop and desktop. In this paper, we call the devices as minions and the minions are managed by a centralized controller called master. 你會拉回去 然後說 the minions could be in datacenter, edge networkd, and end devices, such as laptop and desktop… 然後再講 we use raspberry pi to implement the testbed, is because pis is easier to attach the sensors, and the resource of pi is less, more like the normal iot devices
- Compare to the cloud, fog computing has several advantages. In the fog, we have many kinds of resources. We can utilize the wasted resources for lower cost. For example, when you are listening my presentation, the resource of your laptop is idling, and we can use those resources to do somthing meaningful in the fog computing Fog computing also has many andvantages like Reduce network traffic, Short response time, Low cost, Low carbon foot print And so on
- Fog computing is very powerful and has many advantages To implement the fog computing platform effificiently, we have to solve many challenges, and we pick three import one here first is Different requests need different modules, and we Cannot stick a module on one minion forever so we need a dynamic deployment mechanism second one is the resources of the minionsnare Limited, we should Split requests into smaller modules then Collaborate the minions among one another to finish a request and the last challenge is that amount of requests is Huge, thus, an optimal algorithm to server more requests is required
- Let me use an car tracking usage scenario to explain those Challenges today we would like to track a thies car. This is a complex application and cannot be achieved using a single minion in real-time. Hence, we split the application into multiple smaller modules and collaborate among multiple minions to achieve it in almost real-time. ’’’’’’’’’’’ First, left minion captures the images, and because this minions doesn’t have enough resource to recognize the plate so Collaborate with others to finish the job And it also can estimatie the path of thiefs car,After the thief turns right. Left minion may not see the car anymore, so master need to dynamically deploy the image collector module to the bottom minion to continue the tracking ‘’’’’’’’’’’’ This example tells us that dynamic deployment, spliting applications, and module deployment decesions are important in our fog computing platform.
- For the first challenge We need a Dynamic Deployment Mechanism to dynamically deploy our module on minions So we use the Virtualized modules because it will be easier to Dynamically placed them and migrates them among the minions Just like we can easily start a virtual machine and move or delete it whenever we want and there are two different types of Virtualized technology: Traditional virtual machine and container I am going to introduce them and compare the pros and cons
- the Traditional Virtual Machine, they all Need entire guest operating systems, necessary binaries, and libraries so it consume large storage space and computing power unlike that, container is sort of a Light-Weight VM, it Only requires mandatory services they need and share the same kernel with host, thus it consume less storage space and computing power, it also have the advantage that it can be set-up in a really short time Here is a table compare the size and the startup between Traditional virtual machine and container , you can see the container can start in real time, and only cost a few capacity, so it more suitable for our platform
- To manage the containers efficiently, we leverage the existing open-source platforms. Here, we survey three of them. In this paper, we choose the state-of-art paltform -- kubernetes as our based platform.
- Let me introduce the Architecture of Kubernetes briefly In kubernetes, the minions are connected to the master and controlled by it Each minion can host several containers, and the containers will be assembled into pod Then , the service is a group of pods that are running on the cluster In other word, we can manage many containers on many minions to server our requests by kubernetes
- so, how can we use this Kubernetes-based Fog Computing Platform to server the users requests? This figure shows our data flow in this figure user can send some requests through the UI and our module deployment algorithm calculates the best deployment way then tell the kubernetes to deploy those modules to minions as you can see, some times module will Collaborate and connect with each other to finish a request therefore, we will get the result And what is the module deployment algorithm?
- So far, we have a platform to manage the minions, and then we have to make decisions on deploying the modules. Here, we carefully formulate the module deployment problem. The Objective function of this formulation is to maximizes the number of satisfied requests And the Decision variable, if xdm equal one then it means module m is deployed on minion d The yrm is the intermediate variable in Objective function is to determines if module m for requesr r has been deployed This equation means minion should have enough resource to put the module And the last equation means module m will only be deployed on a device
- and there is the sudocode which achieves the problem formulation I just mentioned First. We decides the order of requests. Let the request which has less modules to be deployed first. time complexity is r log r Then The for-loop iterates through all sorted requests which cost r time complexity In this loop we decides the order and choosing the feasible devices to equally deploy the modules, which cost d log d complexity. After that we checks the violation of the resource constraint in every minions of every modules and it cost DM time complexity So the final time complexity is like this, is polynomial time!
- After I explain all the challenges we have and how we conquer them, Let us see the real work of platform, this is an Implementation We split an Crowdedness application into three modules: Image collector,Face detector,Crowdedness monitor Image collector module will capture the image and send it to Face detector module to detect how may head in the picture, then Face detector module will send the number to Crowdedness monitor module, which is a web site for monitor the history record of the people number in the room
- And the following is the experiment setup we use i5 CPU PC which installed with Kubernetes as the master Serveral Raspberry Pis as Minions for the Network Emulator we use Wonder Shaper to constrain the bandwidth and use the Optimal algorithm to compare with our MDA algorithm
- Ok, here comes the result, this is the analyze to compare the efficiency between bare machines and containers we Running face detection module with or without container to measuring the Container Overhead, and found Almost zero overhead: resource usage and processing time are almost the same
- Because of the serveral advantages of containers we can set up the modules in real time, it only needs 9 seconds to Serve 20 requests
- and here shows the optimality of our MDA it shows the largest gap of satisfied requests between the our MDA and OPT algorithm is only 2%. ???????????????
- But OPT algorithm takes 80 seconds to solve 20 requests, while the MDA algorithm computes it in real time (< 1 second). Which means our Algorithm can cost less time and resources but finsh the job as good as OPT algorithm We also conduct another experiment Which reveal that MDA algorithm can compute 1000 requests with 500 devices in 2 seconds
- Let me use this experiment result to summarize my presentation. So, we have three modules and our MDA algorithm will decide how to depoly them on minions. If we use traditional way, we send the whole image to the datacenter, which consume large amount of network traffics. If we use our fog computing approach, we pre-process the image among the minions and finally send the small report to the datacenter, which reduce large amount of network traffics.
- so there is the conclusion of our paper We implemented a fog computing platform for dynamically deploying modules on fog minions we Formulate the problem and propose an efficient Module Deployment Algorithm (MDA) we also Build a real testbed to evaluate our algorithms and the dynamics of the fog computing platform
- 你會拉回去 然後說 the minions could be in datacenter, edge networkd, and end devices, such as laptop and desktop… 然後再講 we use raspberry pi to implement the testbed, is because pis is easier to attach the sensors, and the resource of pi is less, more like the normal iot devices