Workspace as a Service: an Online Working Environment for Private Cloud

Transcription

1 2017 IEEE Symposium on Service-Oriente System Engineering Workspace as a Service: an Online Working Environment for Private Clou Bo An 1, Xuong Shan 1, Zhicheng Cui 1, Chun Cao 2, Donggang Cao 1 1 Institute of Software, School of Electronics Engineering an Computer Science, Peking University, Beijing, China 2 Department of Computer Science an Technology, Nanjing University, Nanjing, China {anbo, shx, czcpku, caog}@pku.eu.cn, caochun@nju.eu.cn Abstract With the rapi evelopment of clou computing, more an more organizations are builing their own private clou an proviing IaaS services to their internal users. However, current IaaS usually only gives users low-level resources such as virtual machines (VMs) an storages. Users have to manually setup necessary software stacks on one or even more VMs to meet their nees. This setup process is often complex an ifficult for inexperience users, who most of the time o not care about the unerlying infrastructure, but only eman a working environment to o their jobs. In this paper, we introuce a new service moel calle WaaS (Workspace as a Service), which provies users with an online workspace having the customize software stacks, configurations an computing resources reaily available. Users can irectly o their various jobs in their clou workspaces via a browser. WaaS has been implemente in an open source project Docklet. The esign, real use cases an evaluations are presente. Keywors-clou computing; workspace; WaaS; Resourceefficiency; I. INTRODUCTION Clou computing has become very popular in recent years, bringing forth several clou software platforms (such as OpenStack [13], ClouStack [14], Clou Founry [15]). Base on those platforms, many organizations an eucational epartments have built their own private clous upon existing infrastructure for benefits like resource sharing, reliability, isolation an security [1]. While private clou coul help organizations an eucational epartments significantly reuce their IT expense, there are still some limitations. Most of the abovementione platforms are focusing on IaaS level. However, IaaS clou platform usually only provies user with lowlevel resources such as virtual machines (VMs) an storages. Users have to manually set up the system environment in the virtual machines for their jobs. Some PaaS clou platforms such as Google App Engine, Clou Founry, provie users with built-in services such as atabase, memory cache an specific mileware (e.g., java runtime, python runtime, etc.) for software evelopment an eployment. Usually PaaS clou platform is esigne to support web application. The software stacks of PaaS clou platform are typically very limite, which can t be customize easily to meet ifferent users specific requirements. Here is a real case. We have a small atacenter with more than ten high-performance computers to support programming courses, conuct experiments, an host our official websites in Software Engineering Institute (SEI) of Peking University. Our atacenter is locate in an intranet with a few public IP aresses an limite physical resources. Currently we use an IaaS platform for resource sharing. Each user can apply for virtual machines for various purposes. Such approach brings a lot of issues to both users an aministrator. For instance, one of our teachers is offering a course on ata analysis. Each stuent nees his own Spark [2] cluster for program ebugging, ata processing an visualize the results with other tools. The aministrator can only offer virtual machines to stuents an configure VPN tools for remote access. Therefore, all stuents have to set up their Spark clusters manually. An they have to process ata via the comman line interface (CLI) using SSH, visualize the processe ata to picture files, ownloa the results into their own computer an check them. It is time-consuming an error-prone. At the en of each semester, the aministrator is require to recycle virtual machines for future use. In fact, what users nee inee in such situation is not low-level resources like virtual machines, but a high-level workspace having customize software stacks, configurations an computing resources reaily available. In this workspace, users can o their jobs irectly, incluing online programming, ebugging, eploying, visualizing the result, etc. As shown in Fig. 1, a workspace provies an easy-to-use browser-base user interface (BUI) for users to o their jobs with their resources an services in the atacenter, just like the GUI provie by esktop operating system. For the real case aforementione, stuents can use Spark Cluster, visualize results online with a browser conveniently. Such a workspace shoul be provie as a service to Stream Processing Workspace Software Stack Resource HTML5/HTTPS Big ata Workspace Software Stack Resource Private Clou Fig. 1 User's Perspective of a Workspace /17 $ IEEE DOI /SOSE

2 users as neee. In this paper, we introuce WaaS (Workspace as a Service), which provies users with flexible an easy-of-use online workspace to run their jobs as well as taking the efficiency of resource sharing into consieration. We have implemente a system calle Docklet 1 to provie users WaaS an have eploye it in our university 2. We also conuct some experiments to evaluate our system. Currently the system is efficient, easy-of-use an really meet most nees of our aily work. The rest of the paper is organize as follows. Section II motivates the concept of WaaS an its key technologies. Section III escribes the Docklet system which supports WaaS moel. Some examples an evaluations are given in Section IV to show the efficiency an easy-of-use of Docklet system. Section V conclues the paper. II. WORKSPACE AS A SERVICE WaaS is ifferent from the low-level services offere by IaaS. It provies a high-level workspace having customize software stacks, configurations an computing resources reaily available. In this clou workspace, users can o their jobs through BUI irectly. An compare with PaaS, WaaS allows users to efine the software stacks they nee with a software efine mechanism, which is quite extensible an flexible. A. Workspace an Virtual Cluster A system moel of workspace is shown in Fig. 2. A workspace is a virtual working environment supporte by a virtual cluster. It has all that users nee reaily available, incluing customize software stacks, configurations, computing resources an ata an so on. Besies these, each workspace also implements a BUI so that users can o their jobs through a browser irectly. To be specific, a workspace consists of two layers: application layer an resource layer. The application layer allows users to efine their workspace, incluing computing resources neee, the network topology, customize software stacks, configurations, ata, etc., using given interface. The resource layer abstracts various physical Application Layer Resource Layer Workspace BUI Software Stack Data Virtual Cluster Physical Cluster Fig. 2 System moel of a Workspace Workspace BUI Software Stack Data Virtual Cluster resources as software-efine resource pools an packs such resources as virtual clusters, on which the application layer can buil a workspace for users jobs. Meanwhile, the resource layer not only guarantees the isolation between users workspace but also takes into consieration the utilization of physical resources. Virtual cluster is the unit for resource management. It is compose of several virtual noes an a private network. Noes in ifferent virtual clusters are well-isolate. That is to say, noes in one virtual cluster can t affect noes in other virtual clusters. Virtual cluster also enables auto-scaling at runtime with just a single operation in the browser an is self-healing by automatically recovering from failures. Actually, WaaS provies users more than a virtual cluster [3]. In application layer, users coul efine their software stacks, an then system will construct the workspace upon the virtual cluster, which has goo flexibility. Base on the resource layer, the application layer coul focus on users requirements making no interaction with physical resources but software-efine virtual cluster. B. Key Technologies towars WaaS Virtualization an software efinition technology are the key technologies towar WaaS. A lot of technologies emerge in virtualization area promote the generation of software efinition, which makes improvement in constructing evices by feasible software protocol instea of fixe harware topology [4][5]. Firstly, virtualization is use to abstract physical resources as software-efine resource pools. Currently there are two main virtualization approaches, hypervisorbase an container-base virtualization [6]. Those two approaches come with ifferent traeoffs an have various goals to achieve. Hypervisors-base virtualization consists of a virtual machine monitor (VMM) on top of a host OS that controls the resource allocation to the guest operating system. Each VM has its own operating system that executes completely isolate from the others. Such hypervisor-base solutions, like KVM [16], VMware vsphere [17], allow user to run any x86 operating system on VMM. A lightweight alternative to the hypervisors is the container-base virtualization, also known as Operating System Level virtualization. Instea of virtualizing harware, containers are base on share operating systems which are much more lightweight an efficient than hypervisors [7]. Container-base virtualization has a weaker isolation compare to hypervisor-base virtualization, but from the users point of view, each container looks exactly like a stan-alone OS. Although the hypervisor-base virtualization has been aopte wiely in clou computing environment for elastic resource provisioning, it always has a non-trivial cost as well as low utilization of resources. For our WaaS, container-base virtualization is use for its low overhea with high performance, since our service is mainly provie in a truste private clou. 20

3 Seconly, software efinition is also use in WaaS to provie users a workspace. Specifically, software efinition is applie for users to efine their workspace with options such as unerlying infrastructure, software stacks, configurations, etc., which are sufficient to efine an buil a workspace for special nees. Software-efine network (SDN) [8] is use to manage an configure network for workspaces. SDN makes it possible for system to etermine network services through abstraction of lower-level facility, incluing ynamic, scalable computing an the path of network packets. As escribe above, virtualization an software efinition technology are the key technologies towars our system. It works with low overhea, high efficiency, high operability an high flexibility, enables users to escribe an construct a workspace, an makes workspace as a service. III. DESIGN AND IMPLEMENTATION OF WAAS We have esigne an implemente an open source prototype system name Docklet to support WaaS. In this section, we show the escription of Docklet s target environment an esign goals, then we iscuss the Docklet architecture, an finally we give the etails of our implementation. A. Target Environment an Design goals Docklet is esigne for organizations with a meium- or small-scale ata center, which is use mainly by truste organizations users. It aims to provie researchers or employees a workspace upon private clou with many programming frameworks pre-installe. Users just nee a browser to evelop, test an run their programs. Docklet also provies users with a mechanism to efine all require resources for the workspace accoring to their emans, incluing customize software stacks, configurations, computing resources an ata, an so on. More specifically, the goals of Docklet are shown as follow: Elastic an extensible: Docklet is elastic an extensible. Users can scale in an scale out their virtual clusters at runtime with just a single operation in the browsers. They can also install software neee as operating a real cluster. Customize environments: Docklet is typically share among many users, which may have ifferent requirements in terms of software packages an configurations. Iniviual users can pre-efine their own workspace accoring to their emans without knowing the etails of unerlying infrastructure. An Docklet will provie a clou workspace base on their requirements automatically. Fast an efficient: Docklet uses container-base virtualization with avantages like builing one workspace in secons, high utilization of resources, running over thousans of containers in a single physical host, etc. With such a virtualization technology, the workspaces of ifferent users will work together in the private clou, an the performance of computing, memory throughput, isk I/O an network transmission is guarantee. Cluster Controller Clou Controller Cluster Controller Ease of Use: Docklet is easy-to-use. It coul be an ieal environment for application evelopment an test, running ata analysis jobs, exercising platform for programming courses, etc. Users can o their jobs in their workspace through a browser an they on t have to repeat the complex an teious configurations for software stacks, such as subnetwork connection, ata sharing, an the allocation of openssh keys for authorization, software installation an configuration, etc. Docklet can automatically finish all software installations an configurations. Meanwhile, Users is able to o their jobs with their resources an services in the atacenter through BUI. B. System Architecture The architecture of the Docklet is flexible an moular with a hierarchical esign as shown in Fig. 3. There are three high-level components in this hierarchical system, each with its own Rest API. The s are esigne to virtualize the physical computing resource as containers an monitor the status of containers an physical noes. The Cluster Controllers are responsible for making appropriate resource management among the noes in orer to provie Clou Controller with virtual clusters as well as manage the virtual network an the storage. The Clou Controller controls the construction of users workspace an provies users a BUI to evelop, test, an run their applications. In such hierarchical esign, cluster can be ae or remove ynamically in response to real-time resource emans. In the future, we also inten to support cross-atacenter resource management. A closer inspection of these three main system components in the Docklet system is shown in Fig. 4. 1) We chose container-base virtualization to virtualize the physical computing resource for its low overhea with high performance, as our service is mainly provie in a truste private clou. A executes on every machine in our system. It manages container behaviors such as start, stop an reboot an is responsible for monitoring the status of containers an physical noes. The monitor in Noe Controller keeps track of the resource usage incluing computing, memory throughput, isk I/O an network Fig. 3 The Hierarchical Design of Docklet 21

4 Rest API Workspace Orchestrator Virtual Cluster Scheuler Rest API Virtual Cluster Manager Rest API Container-base Virtualization transmission etc., which are then propagate to the Cluster Controller. Furthermore, also takes charge of the execution of image creation, migration an estroy as Cluster Controller emans. 2) Cluster Controller A Cluster Controller executes on one single machine per cluster. Its main components an functionalities are shown as follow: a) Virtual Cluster Manager The Virtual Cluster Manager introuces a software efinition approach to buil virtual clusters. Users can specify the configurations of cluster, an Docklet woul buil the virtual cluster automatically. Moreover, containers can be easily migrate among noes in Docklet. When a LXC Host ocklet-br/ovs eth LXC Clou Controller Cluster Controller Image Scheule Network Manager GRE Container Scheuler Distribute Storage Manager Virtual Switch Host GRE ocklet-br/ovs gw gw Linux Network eth Fig. 5 Docklet network on multi-hosts BUI User Manager Image Monitor Host eth LXC ocklet-br/ovs System DB Fig. 4 The closer inspection of the main system components of Docklet virtual cluster is to be create, the Virtual Cluster Manager will check whether this user has enough resource quotas to support this virtual cluster, then the virtual cluster will be built accoring to a scheuling plan. b) Image Manager The Image Manager implements a mechanism to wrap user s workspace into an image. An image is aime to escribe the user-efine environment on private clou, which can be conveniently share by users. A user is able to submit an image to construct a specific workspace automatically. The image is actually a compresse file that inclues information ata, such as metaata for construction, management an monitor, an scripts for creation, recovery an estroy [9]. To be more specific, script is supporte for users to customize every container of virtual cluster. A script is an executable batch file copie into every noe of virtual cluster to be execute at appropriate time, incluing event hanlers for creation, recovery an estroy. On-Create scripts is triggere insie a container once it is launche, an On- Destroy scripts is triggere before a container is to be estroye. On-Recovery scripts is responsible for hanling abnormal breakown an turning it into normal running status, which is useful for some applications to o journal recovery or irty file cleaning. c) Network Manager The network manager implements a transparent an virtualize network for each virtual cluster. It is mainly base on Open vswitch [10], an open-source implementation of OpenFlow [11] technology. The network structure of Docklet is shown in Fig. 5. We built GRE tunnels between physical hosts to connect containers together without extra network evices. When a virtual cluster is to be create in Docklet, a network will be built, an containers will be generate uner this network. Public an private SSH keys will also be generate an copie to each container to achieve logging without passwor among them. ) Distribute Storage Manager As for storage, the istribute storage manager provies a large, istribute storage pool for users. Every user has its quotas an the user s storage will be automatically mounte into virtual clusters so that user can manage his ata conveniently. e) Container Scheuler The Container Scheuler is responsible for resource management in the cluster. It gathers physical noe information from the s in a cluster an generate suitable scheuling plans. 3) Clou Controller 22

5 Fig. 6 The Workflow of Docklet The Clou Controller is the entry-point of our system for en-users an aministrators. It consists of a workspace orchestrator, which controls the constructions of users workspace upon virtual cluster an a BUI for users o their jobs through a browser. It also recors the status of all workspaces, physical noes an users. The workspace orchestrator hanles requests an ecies whether the workspace shoul be eploye an where it shoul be locate in consieration of the status of clusters. Once it ecies to construct a workspace, it passes the message to Virtual Cluster Manager in Cluster Controller to start the container of the specifie image, then virtual network for this virtual cluster will be constructe, communications between containers in a cluster will be guarantee by the Network Manager. Finally, the Workspace Orchestrator is responsible for the installation an configuration of users customize software stacks. C. Details of Docklet Implementation We have implemente Docklet in Python, which make the system platform inepenent. At the bottom layer, we use Linux Container (LXC) [18] to virtualize physical computing resource. As for user s storage, Docklet uses an inepenent NFS [12] cluster built by GlusterFS [19]. Each user will have his or her own storage share in the NFS cluster. The user s storage will be automatically mounte into his workspace so that user can manage their ata conveniently. Since Root-FS of every container are base on Union-FS [20] like Docker [21] oes, consisting of multiple Rea-Only Layers an single Rea-Write Layer, we also apply volume quota limitation to Rea-Write Layer for security consieration. ETCD [22], a istribute, consistent key-value store, is use to monitor the status of physical machines. Critical ata in system are store in the Key/Value atabase provie by ETCD. In aition, Open vswitch, an open-source implementation of OpenFlow technology, is use to provie transparent an virtualize sub-network among noes in same workspace but locate on ifferent machines. Finally, we moifie open-source Jupyter [23] to implement a userfrienly interface so that user can eit an run their job via a web browser. Fig. 6 shows the workflow of our system taking WorCount task as an example which inclues the following steps: (1) Users login the system via web portal; (2) Configure the workspace, for example, a 3-noe cluster with 23

6 Spark installe; (3) Start the workspace; (4) Go into the workspace an open a comman line interface; (5) Run the job via the web terminal provie by Jupyter; (6) Visualize the processe ata an immeiately check the results through browser. In this way, we have finishe an easy WorCount task on Spark Cluster with the support of Docklet. As we can see, the whole process is accomplishe on the web browser conveniently. In aition, users can uploa or ownloa their programs an ata files to/from workspace through Jupyter an they can also install any preferre tools to accomplish their jobs in workspace. IV. Fig. 7 Computing Performance using SysBench EXPERIMENT AND EVALUATION A. Experiment environment We evelope an built Docklet on two physical server machines, which has 2 processors of Intel(R) Xeon(R) CPU E GHz (with 6 cores each), 15M of L3 cache, 377 GiB of RAM an an Ethernet interface (Intel(R) Fig. 8 Memory Throughput using STREAN PRO/1000 Network Connection) with 1,000Mbps network banwith. We ran ifferent benchmarks in Docklet an compare the spee of computing, isk I/O an network I/O, measure in megabytes per secon (MB/s) with physical implementation. In orer to evaluate the easy-of-use an practical applicability of our system, we conucte a semistructure interview with 20 stuents in SEI lab. B. Computing Performance We selecte the SysBench [24] benchmark to evaluate the computing performance on a single machine noe. SysBench is a moular an cross-platform benchmark tool for evaluating OS parameters by verifying prime numbers. We ran SysBench benchmark three times on a single container an a physical machine where the container is built, an the average results are use to compare the computing performance between our container an the real physical machine. As shown in Fig. 7, the result of container is near to native computing performance, for there is no statistically Write Re-write 2000 /s) B 1500 (M e sp 1000 rite w 500 isk D FIle size(gb) physical conatiner 2000 /s) B (M 1500 e sp 1000 rite -w 500 re isk D FIle size(gb) physical conatiner 4500 /s) 4000 B3500 (M 3000 e 2500 sp 2000 a 1500 re 1000 isk D Rea FIle size(gb) physical conatiner 4500 /s) 4000 B (M e 2500 sp 2000 a ṟe 1500 re 1000 isk 500 D 0 Re-rea FIle size(gb) physical conatiner Fig. 9 Disk I/O using IOzone 24

7 significant ifference between the results. Due to there is only one processor use, we believe that the results of a single CPU-intensive benchmark will not be affecte by ifferent CPU scheulers. C. Memory Performance The memory performance on a single noe was evaluate with STREAM [25], a simple synthetic benchmark program that measures sustainable memory banwith (in MB/s) by running four type of vector operations (Copy, Scale, A an Tria). Furthermore, to avoi memory reuse, we use atasets larger than currently available cache memory in our test, which also ecrease the waiting time for cache miss. We ran STREAM three times as well, an calculate the average memory rate as the memory banwith of container an physical machine. The comparison of memory performance is shown in Fig. 8. As can be seen, our container an native physical machine present similar memory banwith (the orinate starts not from 0), no matter which operation was taken. For the most ifferent vector operation, A, container is only approximately 3 percent slower than physical machine. D. Disk I/O Performance We use IOzone [26] benchmark to evaluate the isk I/O performance. IOzone tests file I/O for a variety of file operations like Write, Re-Write, Rea an Re-Rea. For our system, Docklet limits the memory of one container to at most 4GB, so we ran the benchmark 10 times with file size of 1GB, 2GB, 3GB, an 4GB an 4KB of recor size, an took the average of 10 groups of results as the isk I/O performance. A closer inspection in isk I/O performance shown in Fig. 9 revels that there is an acceptable ifference, approximately 20 percent on Write operation an 10-15% percent on other operations, between containers an physical machines. Since we use AUFS [27] as our file system, which is a multi-layer file system, leaing to slower I/O operations than native file system. We will keep research on our file system to improve the isk I/O performance. E. Network Efficiency To avoi the ifference cause by harware, all of our statistical results are on the basis of common traitional switches an routers with no avance harware installe in our Docklet system. We use Open VSwitch(OVS, v2.4.0) GRE Tunnel, calle ovs-brige, to establish the network brige of each containers, an the MTU value of all OVS evices are set to We evaluate the network by using NetPIPE [28] (Network Protocol Inepenent Performance Evaluator) benchmark, which is a tool for measurement of network performance uner a variety of conitions without epenency of protocols. It can make simple tests such as ping-pong, sening an receiving messages of increasing size between two processes through network. The size of message is chosen at regular intervals in orer to perform a complete test of the system with slight perturbations. To provie accurate time measurements, each point involves a lot of ping-pong tests. For small message (<64 bytes), NetPIPE calculates the latency by iviing the RTT (roun trip time) in half. To be more specific, we mae ata transmission between two containers built on two physical machine through our virtual network, as well as mae the same test between two physical machine through native switch an router. We teste over 100 times with various message size an compare container an physical machine network banwith (MB/s) an latency (MS). As shown in Fig. 10, for each point on the abscissa, there are two more points with only a litter ifference of the message size, leaing to the curve consists of many groups which has three points similar to each other. Fig. 10 shows the comparison of network banwith, container obtaine a great behavior with a very small ifference compare to the native physical network system. This is because OVS reuces the latency by using software-efine network protocol an our experiment network topology is simple. An we will make further stuy on a more complicate network topology in the future to verify our network efficiency. F. Performance Overhea in Spark Application Fig. 10 Network Transmission using NetPIPE 25

8 This section presents an analysis of the performance overhea in Docklet system for Spark applications. For that, we conucte experiments using Spark on a virtual cluster of workspace an a physical cluster. Each has 2 noes an each noe is configure to use 4 cores an 8GiB RAM for spark tasks. We run WorCount, a typical Spark program, on the ata of 1GB up to 40GB to show the ifference between physical clusters an Docklet s container-base clusters. Fig. 11 shows the result for this experiment. In all cases, Docklet s container-base cluster obtaine execution times very close to the physical cluster, keeping the performance overhea no more than 10%. G. Qualitative evaluation In orer to evaluate the easy-of-use an practical applicability of our system, we conucte a semi-structure interview with 20 stuents in SEI lab. Before the interviews, we showe a emo of using Docklet, an the participant interact with Docklet to accomplish a ata processing task. In aition, we explicitly aske the following questions: Q1. Do you think it is teious an error-prone to configure ifferent workspace for various work? Q2. Usefulness of Docklet. Coul Docklet meet your nees for aily work? Q3. Easy-of-use an frienliness of Docklet. Do you think it is easy to use Docklet? Q4. Application of Docklet. Woul you use the tool for aily work? An why? Participants answere each question using a score on a four-point Likert scale: 1=absolutely no, 2=no, 3=yes, 4=absolutely yes. Overall, we gathere very positive qualitative feebacks about Docklet. All of the stuents we interviewe with think it is really teious an error-prone to configure workspace for various work. 75 percent of 20 stuents give a score of 3 for Q1. Others give a score of 4. For Q2, only 2 stuents give a score of 2. Because they nee to use specialize harware such as GPU to o their jobs which is not supporte by Docklet currently. For Q3, 60 percent of 20 stuents give a score 3. Others give a score of 4. They think Docklet coul free them from teious configures of software. Meanwhile, they coul o their jobs using frienly web-base GUI via browsers anytime an anywhere. For Q4, interviewers give a relatively conservative answer. None gives a score of 4. However, all of 20 stuents give a score 3. They are really intereste in Docklet an want a try. They just concern about stability. Such qualitative feebacks give us so much confience in our system, an will also rive us to improve Docklet with stability an other features. For all experiments mentione above, our Docklet is efficient an easy-of-use. It provies convenient user experience with outstaning performance of computing, memory throughput an network transmission an an acceptable isk I/O rate. Also, when running a real big ata application, Docket has a near-to-native performance with low overhea. V. CONCLUSION AND FUTURE WORK This paper introuces the concept of WaaS moel for general purpose an a simple implementation of Docklet system. WaaS provies users a workspace having customize software stacks, configurations an computing resources reaily available. Each workspace has an easy-touse browser-base user interface (BUI) for users to o their jobs through a browser, just like the GUI provie by esktop operating system. Our Docklet system can provie users WaaS. It is an ieal environment for application evelopment an test, exercising platform for programming courses, etc. The final evaluation results show that Docklet is easy-of-use an work with low overhea, high efficiency, high operability an high flexibility. In future research, we inten to investigate several key issues incluing efficient aggregation of cross atacenter resources, loa-balancing optimization for fine-grain noes on each machine, fast construction of users working environment as well as container performance improvement. ACKNOWLEDGEMENT This work is supporte by the National Science an Technology Major Project uner Grant No.2016YFB ; the National Natural Science Founation of China uner Grant No , ; the Science Fun for Creative Research Groups of China uner Grant, No REFERENCES Fig. 11 Spark Application Experiment [1] Armbrust M, Fox A, Griffith R, et al. Above the clous: a berkeley view of clou computing[j] [2] Zaharia M, Chowhury M, Franklin M J, et al. Spark: Cluster Computing with Working Sets[J]. 2010: [3] Cui W, Zhan H, Li B, et al. Cluster as a Service: A Container Base Cluster Sharing Approach with Multi-user Support[C]//2016 IEEE Symposium on Service-Oriente System Engineering (SOSE). IEEE, 2016: [4] Bari M F, Boutaba R, Esteves R, et al. Data center network virtualization: A survey[j]. IEEE Communications Surveys & Tutorials, 2013, 15(2):

9 [5] Chiueh S N T, Brook S. A survey on virtualization technologies[j]. RPE Report, 2005: [6] Eer M. Hypervisor-vs. Container-base Virtualization[J]. Future Internet (FI) an Innovative Internet Technologies an Mobile Communications (IITM), 2016, 1. [7] Felter W, Ferreira A, Rajamony R, et al. An upate performance comparison of virtual machines an linux containers[c]//performance Analysis of Systems an Software (ISPASS), 2015 IEEE International Symposium On. IEEE, 2015: [8] Founation O N. Software-Define Networking: The New Norm for Networks[J] [9] Sun D W, Chang G R, Gao S, et al. Moeling a ynamic ata replication strategy to increase system availability in clou computing enviironments[j]. Journal of computer science an technology, 2012, 27(2): [10] Pfaff B, Pettit J, Koponen T, et al. The esign an implementation of Open vswitch[j]. ;login:: the magazine of USENIX & SAGE, 2015, 40:págs [11] Hu F, Hao Q, Bao K. A survey on software-efine network an openflow: from concept to implementation[j]. IEEE Communications Surveys & Tutorials, 2014, 16(4): [12] Sanberg R, Golgberg D, Kleiman S, et al. Design an implementation of the Sun network filesystem[c]// Innovations in Internetworking. Artech House, Inc. 1988: [13] OpenStack. [14] ClouStack. [15] Clou Founry. [16] KVM. [17] VMware vsphere. [18] LXC. [19] GlusterFS. [20] Union-FS. [21] Docker. [22] ETCD. [23] Jupyter. [24] SysBench. [25] STREAM. [26] IOzone. [27] AUFS. [28] NetPIPE. 27