Community network clouds as a case for the IEEE Intercloud standardization

Community Network Clouds as a Case for the IEEE Intercloud Standardization Roger Baig∗, Felix Freitag†, Agusti Moll∗, Leandro Navarro†, Roger Pueyo∗, Vladimir Vlassov¶ ∗Fundaci´ o Privada per la Xarxa Lliure, Oberta i Neural Guifi.net. Mas l’Esperana, 08503 Gurb, Catalonia {roger.baig, agusti.moll, roger.pueyo}@guifi.net †Department of Computer Architecture. Universitat Polit` ecnica de Catalunya. Barcelona, Spain {felix, leandro}@ac.upc.edu ¶KTH Royal Institute of Technology. Stockholm, Sweden. {vladv}@kth.se Abstract—The IEEE P2302 Intercloud WG conducts work since 2011 on the project Standard for Intercloud Interoperability and Federation with the goal to define a standard architecture and building components for large-scale interoperability of independent cloud providers. While the standardization process has achieved fine-grained definitions of several Intercloud components, a deployment of the Intercloud to demonstrate the architectural feasibility is not yet operational. In this paper, we describe a deployed community network cloud and we show how it matches in several aspects the vision of the Intercloud. Similar to the Intercloud, the community network cloud consists of many small cloud providers which for interoperability use a set of common services. In this sense, the community network cloud is a real use case for elements that the Intercloud standardization WG envisions, and can feed back to and even become part of the Intercloud. In fact, a study on SME provided commercial services in the community network cloud indicates the importance for SMEs to reach the success of the Intercloud standardization initiative. Index Terms—community networks; cloud computing; I. INTRODUCTION Community networks, also known as bottom-up-broadband networks, consist of a communication infrastructure in which local communities of citizens build, operate and own open IP- based networks. Community networks often originated as a solution for providing Internet access to the population of areas which were unattended by commercial telecom operators. Hundreds of community networks operate across the globe, in rural and urban, rich and poor areas. Internet access is the main service sought by the users of community networks. A community cloud is a cloud deployment model in which a cloud infrastructure is built and provisioned for use by a specific community of consumers with shared concerns, goals and interests, and is owned and managed by the community or by a third party or a combination of both [1]. Each community cloud is specialized for providing particular features, the ones which are needed by its community. The difference between one community cloud and another is that certain features, e.g. performance, security, ease of usage of the cloud, are emphasized. Commercial community cloud solutions are a reality nowadays in several application areas such as in the financial, governmental and health sector, fullilling their community-specific requirements [2] [3]. Within community networks, the possibilities of cloud computing have just started to be unveiled [4]. The community cloud we present in this paper is a real deployment which materializes the vision of a cloud for community networks, hosted on community-owned computing and communication resources providing services of local interest [5]. The deployed community cloud in the community network matches in several components the vision of the IEEE p2302 Intercloud WG [6]. Similar to the Intercloud [7], the community network cloud consists of many small cloud providers which for interoperability use a set of common services. In this sense, we can consider the community network cloud as a real deployed use case at small scale for what the Intercloud standardization WG targets at. Therefore, the experience that we reported in this paper aims to feed back to the Intercloud standardization effort and as a real system, the community network cloud can even become part of the Intercloud testbed [8] as autonomous cloud provider. Similarly, the community network clouds can learn from the Intercloud architecture and adapt their implementation to the upcoming standard. The contributions of this experience paper are the followings: 1) The technical choices that we adopted in the development of the community cloud for community networks. 2) Identification of Intercloud elements in the deployed community network cloud. 3) The relevance of the Intercloud standardization for the success of SME based cloud service provision in community network clouds. The structure of this paper is as follows: In section 2 we review how the concept of the Intercloud can be found in the environment and conditions of community networks. Section 3 describes how the community network cloud is materialized in a real deployment. We compare in section 4 the architectural similarities between the Intercloud and the community network cloud. In section 5 we discuss results of the community cloud system and the relevance of the Intercloud standardization for its success. We conclude the paper in section 6. © 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI 10.1109/CSCN.2015.7390456 II. THE INTERCLOUD CONCEPT IN COMMUNITY NETWORK CLOUDS In this section we review the requirements for clouds in community networks and unveil similarities with the Intercloud scenario. As a community cloud, the system we present needs to address the conditions of this particular user community and satisfy its requirements. Topology of community network clouds and hardware aspects: A community wireless network distinguishes between super nodes, also called backbone nodes, and client nodes. A super nodes in a community network is typically assigned an IP address range, whose addresses are public within the community network1. In the community network cloud, cloud resources are attached to super nodes in order to obtain a public IP address which allows them to easily offer public services. The super node therefore as a component resembles the Intercloud Gateway, which interacts with other cloud providers, in our case, other super nodes. Since super nodes owners are independent of each other, the community cloud operates on heterogeneous hardware, i.e. different cloud resources can be attached to a super node. This case is similar what is envisioned by the Intercloud. While all cloud providers operate throught the Intercloud Gateway, the infrastructure of each cloud provider is independent and can be different. Social aspects of community network clouds: In community networks, personal and social relationships play an important role in the infrastructure deployment. The deployment of new resources needs the collaboration among independent persons. Participants of can be consumers and producers of the cloud resources. In the Intercloud, the interaction among cloud service providers will be complemented by SLAs through commercial agreements, in order to enable advanced and performant services, similar to the social relationships needed to enable community network clouds. In addition, the Intercloud also foreseees that its participants have both the role of consumers and producers. Ownership of nodes in community network clouds: When a new member connects to the community cloud, it contributes with the hardware required to connect to other nodes. In such case the new node of the community cloud belongs to the member who is its sole owner. Similarly, the IEEE Intercloud forsees a large number of cloud service providers, which are independent of each other in terms of their ownership. We can see in Figure 1 how the community cloud fits into the community network. Cloud resources of different kind (heterogenous hardware) and from independent owners are attached to some super nodes. These cloud resources are part of the community cloud. Furthermore, depending on the topology of the community network and its social structure, several local community clouds will appear, which manage 1We refer to routable IP addresses within the community network which are not behind a NAT. locally the cloud resources belonging to a certain zone defined geographically or by its social networks. Such local clouds we call microclouds. The independent cloud providers of the Intercloud are reflected in the community network cloud in terms of the large number of microclouds. Fig. 1. Microclouds in a community network clouds. III. DEPLOYED COMMUNITY CLOUD We describe in this section the cloud infrastructure that we have deployed in the Guifi community network2. It is a real system and we explain how this deployment materializes the concept of the community cloud presented in section II. A. Community Network Guifi.net is our target community network where we deployed the cloud infrastructures. Among the community networks mentioned in the introduction section, Guifi can be considered the largest one worldwide with more than 25000 nodes. Figure 2 shows the wireless links and nodes of the Guifi.net in the area around Barcelona. Fig. 2. Guifi.net nodes and links in the area around Barcelona. 2http://guifi.net/ B. Hardware In order to correspond to the conditions of community networks, we deployed heterogeneous hardware to form the cloud infrastructure. A few nodes are high-end rack-based servers (PowerEdge R420 rack server), some cloud nodes are Dell OptiPlex 7010 desktops. These nodes support virtualization by hardware. In addition, however, we deployed cloud nodes that represents the case of low-end cloud resources such as home gateways, that users may provide to the cloud. Such kind of devices have been deployed through Community- Lab3[9][4] and mainly consist of small Jetway device (no support for KVM, only containers) Towards the lower end devices, we deployed some Alix boards and Intel Galileo boards for evaluation purposes. The current status of the cloud deployment can be seen in the Clommunity project’s Wiki4. C. Cloud Management Platform For the management of the community cloud infrastucture we mainly used Proxmox5and OpenStack6as CMP. The reason for using Proxmox is that within the community network, there was already some positive usage experience, and the installation and operation of Proxmox is relatively easy compared to other CMPs. OpenStack on the other hand, is popular as a powerful customizable cloud platform, supported by a large user community, though not within community networks. Figure 3, shows the Proxmox administrator interface of a cluster of five of our Proxmox cloud nodes deployed in different locations of Guifi.net. Fig. 3. Guifi cloud Proxmox VE cluster. 3http://community-lab.net/ 4http://wiki.clommunity-project.eu/testbed:start 5http://www.proxmox.com/ 6hhttp://www.openstack.org/ D. Containers and Virtual Machines Cloud management platforms (CMPs) provide Infrastructure-as-a-Service (IaaS) in terms of virtual machines (VMs) and virtual networks. In our community cloud, the VMs in the higher-end cloud nodes are KVM and are managed by OpenStack and Proxmox CMPs. In the lower-end cloud nodes Linux containers are used and manged through Community-Lab7[9] [4]. Smokeping is used for monitoring of the basic parameters of the cloud hardware with publicly available view8. E. Software Distribution We have developed a community cloud GNU/Linux distribution, codenamed Cloudy, aimed and designed for building clouds in community networks. This distribution contains the platform and application services of the community cloud model. Cloudy9is the core of our cloud system, because it unifies the different tools and services of the cloud system in a Debian-based Linux distribution. Each community network user that contributes infrastructure to the cloud is encouraged to install the Cloudy distribution. In Figure 4 the installation screen of the Cloudy distribution is shown. Cloudy installs like a standard Debian distribution. It is given as a standalone version to install on real hardware or in virtual machines, and as LXC container. Fig. 4. Installing the Cloudy distribution. Cloudy aims to be deployed on the cloud resources that form the microcloud in the community network, as illustrated in Figure 5. Each cloudy instance has a Web-based GUI, see Figure 6, for the cloud node administrator to install and configure in an easy and comfortable way cloud application services and community network services. F. Services We provide in the Cloudy distribution a set of ready-to- install services, which community network users are expected 7http://community-lab.net/ 8http://monitor.clommunity-project.eu/smokeping 9http://repo.clommunity-project.eu/ Fig. 5. Cloudy distribution deployed in microclouds. Fig. 6. Cloudy login screen used by cloud node owner. to find useful and attractive, grouped as Search, Clommunity, and Guifi.net. The Search service allows the user to find Cloudy instances in the community cloud, and discover services deployed in these Cloudy instances. Different search options are available (Figure 7). Depending on the chosen search mechanism, search is done over the instances of the microcloud or over all Cloudy instances. Figure 8 shows services in other Cloudy instances discovered by the search service. Fig. 7. Discover instances and services in the community cloud. The Clommunity service menu in the Cloudy GUI shows the applications which come already integrated in the cloud distribution (although the user is free to decide if he/she wants to activate them), see Figure 9. In the current version of Cloudy, Tahoe-LAFS as a service that allows building secure Fig. 8. Cloudy instances discovered by the Search service. storage is already integrated. For video streaming, we currently study different options of Peer-to-Peer based platforms. Fig. 9. Application services offered by Cloudy. The Guifi.net services allow to install a set of community network management services (Figure 10). These services include a proxy service based on Squid, usually used to enable Internet access from within the community network, a SNMP service for network monitoring, and a DNS service for name resolution within the community network. Fig. 10. Community network management services offered by Cloudy. G. UI and applications In Figure 11 the user interface of the ownCloud application is shown. OwnCloud offers some functionalities which are similar to Dropbox, a commercial cloud-based storage solution, but ownCloud is open source. We have started experimenting with integrating ownCloud in Cloudy since ownCloud is popular within community network users. IV. ARCHITECTURAL COMPARISON BETWEEN THE INTERCLOUD AND COMMUNITY NETWORK CLOUDS We review in this section the architectural layers of the community network cloud and identify the Intercloud similarities. Fig. 11. Owncloud user interface. A. Deployment environment In the community cloud the cloud infrastructure is deployed in the community network. The Intercloud specification does not indicate the internals of each autonomous cloud provider, but interoperation will be over the Internet. Principally, the community network cloud could be seen as an autonomous cloud provider in the Intercloud. B. Cloud hardware Given the heterogeneity of providers in the community clouds, the cloud hardware can range from high-end servers to low-end resource-constraint home gateways. The Intercloud does not specify specific requirements on the hardware used by each provider and heterogeneity is expected as well. SLAs, however, define what performance is offered by each provider. C. Cloud Management Platform The Cloud Management Platform contains the software needed to manage the cloud platform. It coordinates the underlaying hardware layer with the software distribution layer using standard Linux tools and manages the containers and virtual machines layer. Examples of cloud management platforms that have been used in the community network cloud are OpenStack10, OpenNebula 11, and Proxmox12. In the Intercloud, CMPs are as well at the choice of the service provider, since they operate behind the Intercloud Gateway. Heterogeneity of the CMPs is therefore expected, similar to the community network cloud. The CMP, however, will need to interface with the Intercloud Gateway. D. Infrastructure Service The elements of this layer are containers or virtual machines (VMs) provided by the infrastructure service. They are created by the cloud management platform. The virtual machines are the environment where the software distribution is installed. In the community network cloud, both containers and VMs are operational. Containers are chosen for low-capacity devices without hardware virtualization support and KVM is chosen for more powerful devices. 10https://www.openstack.org 11http://opennebula.org/ 12http://http://www.proxmox.com/ The Intercloud does not impose the usage of specific hypervisors, but diversity is foreseen, including both containers and VMs. For this, several types of infrastructure resources can be specified in the Intercloud semantic resource descriptions. E. Software Distribution The software distribution in the community network cloud is the Cloudy distribution. It runs on the underlying infrastructure and hardware layers, i.e. it runs in the containers or virtual machines. Using a software distribution provides a way to pack and distribute a common set of cloud platform services. It a certain sense, Cloudy is a way to ”standardize” a basic set of services needed for the interoperability of community cloud resources, since each user is expected to install Cloudy on its community cloud resource. Differently, the approach of the Intercloud initiative is to define the interoperability though common APIs, leaving the chosen implementation to each cloud provider. F. Platform Services Cloud-based services are provided by a software distribution which is hosted on the cloud infrastructure. Service discovery and distributed storage are examples of these services in the community network cloud. Similarly, the Intercloud proposes several services to enable resource discovery, both to register services statically in the Intercloud Roots and for dynamic service trading in Intercloud exchanges. In addition, the Intercloud offers semantic resource description and discovery. G. Software Services and User Interface End users of the community cloud are provided with applications and user interfaces to interact in a transparent way with the underlying community services. Similarly, for end users accessing SaaS in the Intercloud, the underlaying services and infrastructure will be transparent. V. DISCUSSION After presenting in the previous section the technical choices and architectural correspondences between community network clouds and the Intercloud, we discuss in this section take-up and opportunities for the community network clouds in relation to the IEEE Intercloud standardization. A. Assessment of usage and engagement We indicate the current usage of the community network cloud in terms of instances deployed and services provided. The values of the metrics are obtained through a publicly available Cloudy instance13. Since the Guifi community cloud is in production, values may vary. The usage and performance are indicted in Table I. It can be seen that there are 37 instances in the Serf cloud, 22 contributed by Clommunity project and 15 contributed other parties like volunteers, schools, companies etc. The guifi-proxy3 is the most popular guifi.net service and syncthing the most popular of the additional services. 13http://84.88.85.42 User: guest, Password: guest Indicator Amount Hosts No. of Clommunity hosts 22 No. of third-party contributed hosts 15 Cloudy distro No. of Cloudy instances 37 Services No. of dnsservice 5 No. of owp 4 No. of peerstreamer 5 No. of guifi-proxy3 7 No. of serf 37 No. of snpservice 5 No. of syncthing 7 No. of tahoe-lafs 3 TABLE I CLOUDY DISTRIBUTION INDICATORS. We conducted some experiments on the performance of applications deployed in our cloud. The results are detailed in [10] and showed satisfactory performance, suggesting their usefulness for end users. B. The Intercloud as essential part of SME commercial Services in Community Network Clouds SMEs have started to explore commercial services to operate upon community network clouds. As an example we mention the study of a commercial backup service extending Cloudy’s Syncthing running in personalized LXC to ensure privacy. The storage capacity already available in the community cloud could be used as starting point, which reduces the cost of initial hardware investment for the SME. Different to other environments, the community network cloud offers SMEs to create other unique services which leverage community member contribution, such as access to sensors at user premises for innovative IoT applications. Access to economy- of-scale generic services, however, will be essential for specific services in the community cloud to be scalable. Interfacing with the Intercloud will thus be an essential requirement for community network cloud services of SMEs to succeed. If we anticipate the trend of the service provision landscape going towards the edge, e.g. to satisfy through SMEs the requirements of evermore communities to appear by tailored cloud service, the features of the Intercloud standard leading to interoperability will become even more important, since cloud service provision of SME will leverage the interaction among several cloud providers. VI. CONCLUSION This paper presented a cloud deployed in a community network for providing services and applications to its users. This cloud was implemented as a community cloud to fit to the specific needs and conditions of this user community. Several similarites were identified in a comparison of this deployed community cloud with the Intercloud architecture standarization driven by the IEEE working group, especially in the proposed architectural components such as with the Intercloud Gateways, Intercloud Exchanges and Intercloud Roots. This community network cloud is thus a practical use case for which the Intercloud architecture already applies. In particular, the described community cloud use case strongly supports the Intercloud vision of a federation of cloud providers in a P2P fashion. This paper remarks the importance of the IEEE Intercloud standarization initiative success for the SMEs offering cloud services to the users of the community network cloud. The value of the Intercloud for specialized SMEs is made clear since these SMEs will achieve added value through tailored community cloud services, and the generic cloud resources they operate upon will need to be sought over cloud providers in the Intercloud. The presented community network cloud is expected to become one of the autonomous cloud providers foreseen in the Intercloud vision. In the Intercloud ecosystem the community network cloud provider will be a consumer of generic cloud sources from other Intercloud providers, and be provider of specific cloud services which other Intercloud providers will be able to aggregate for building next generation cloud services. ACKNOWLEDGMENT This work was supported by the European Framework Programme 7 FIRE Initiative projects CONFINE (FP7-288535), CLOMMUNITY (FP7-317879), and by the Spanish government under contract TIN2013-47245-C2-1-R. REFERENCES [1] “The NIST Definition of Cloud Computing”. National Institute of Science and Technology, U.S. department of commerce.” [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-145/ SP800-145.pdf [2] “NYSE Technologies Introduces the Worlds First Capital Markets Community Platform.” [Online]. Available: http://www1.nyse.com/ press/1306838249812.html [3] “Optum Introduces Health Care Cloud Environment that Enables Secure Collaboration, Enhances Patient Care and Speeds Innovation.” [Online]. Available: http://www.unitedhealthgroup.com/newsroom/articles/news/ optum/2012/0214cloud.aspx?sc lang=en [4] M. Selimi, J. Florit, D. Vega, R. Meseguer, E. Lopez, A. M. Khan, and et al., “Cloud-based extension for community-lab,” in 22nd International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS14). [5] J. Jimenez, R. Baig, P. Escrich, A. M. Khan, F. Freitag, L. Navarro, E. Pietrosemoli, M. Zennaro, A. H. Payberah, and V. Vlassov, in 4th Global Information Infrastructure and Networking Symposium (GIIS 2013). [6] “IEEE Project P2302 - Standard for Intercloud Interoperability and Federation (SIIF), 2015.” [Online]. Available: https://standards.ieee.org/ develop/project/2302.html [7] R. Buyya, R. Ranjan, and R. N. Calheiros, “Intercloud: Utility-oriented federation of cloud computing environments for scaling of application services,” in Algorithms and Architectures for Parallel Processing. LNCS, 2010, pp. 20–31. [8] “IEEE Cloud Computing Intercloud Testbed, 2015.” [Online]. Available: http://www.intercloudtestbed.org/ [9] B. Braem and et al., “A case for research with and on community networks,” ACM SIGCOMM Computer Communication Review, vol. 43, no. 3, pp. 68–73, Jul. 2013. [10] M. Selimi, F. Freitag, R. Pueyo, and A. Moll, “Distributed storage and service discovery for heterogeneous community network clouds,” in 7th IEEE/ACM International Conference on Utility and Cloud Computing (UCC 2014).