Community network clouds are built with the Cloudy distribution developed in this project. Cloudy is a Linux distribution designed for building clouds in community networks.
The dimensions of community networks range from small ones with a handful of nodes to large deployments, like Guifi.net, with tens of thousands of nodes. In such big networks, each cloud server is integrated within a group of neighbour cloud servers. This aggregation that has a reduced number of servers, which are geographically close, is referred as micro cloud.
Cloud services are not necessarily bounded exclusively to their micro cloud premises. For instance, if two micro clouds are connected by the CN infrastructure, services running on both micro clouds can interact with each other and federate if needed. A distributed storage file system, for example, could be built with nodes from different micro clouds to improve redundancy. The only restriction imposed by belonging to a micro cloud is that the announcement and discovery service does not extend further to other clouds. This is done to keep the cloud performance and the Quality of Experience (QoE) inside satisfactory values; otherwise, cloud servers would potentially start interacting with very distant nodes (even hundreds of kilometres away), leading to poor performance and eventually disturbing the global CN operation. In the end, regardless of the partitions created by the micro clouds configuration, there is a cloud of services that operates agnostic about the underlying hardware or software managing the interconnection of the servers. This meta cloud can be deployed to fully extend the entire CN; the only limitation might be the performance restrictions imposed by the network in terms of bandwidth, latency and link quality, that will ultimately affect the user’s QoE perception.
All of the software included in our platform is open-source. Many of the components have been developed during the course of this project, and many are open-source software services that we have customized for the Cloudy distribution. FLOSS: Among the many available options for FLOSS operating systems, the distribution has been based on Debian GNU/Linux. Apart from being one of the most popular distributions and fulfilling all the technical requirements, it has been chosen because the Debian Social Contract safeguards and guarantees that the software will always be open and free. Moreover, the Cloudy distribution is generated using Debian's Live-build tool, which allows for great customisation and easy re-branding for Cloudy to be quickly adapted to other community network environments.
A Cloudy instance can be run directly on a bare metal machine or on a virtual machine providing almost the same services and capabilities. Whatever the instance runs on, connectivity with the community network is a must in order to fully exploit the potential of Cloudy.
The main block of a Cloudy instance comprehends the community network services. These services are the ones that benefit from or embrace the community cloud environment to operate or offer a richer quality of experience. Among them, virtualization is a special case. While other services focus on interaction and contents for the end user, provision of IaaS by means of virtual machines focuses on fostering the deployment of other services that run on top of this infrastructure.
Another special service inside a Cloudy instance is the search service. On the lower layer it provides the mechanisms and the infrastructure to other services to publish their information all over the community network. This is a valuable resource to orchestrate the community cloud itself as it allows room for self-discovery, management and federation of services and resources. On the user interaction layer, the search service allows the end user to discover the available cloud services in the network and decide which services provider choose according to certain metrics (e.g. network RTT to the services and number of hops). In general, this service can be used to publish any application running in Cloudy even if not cloud-related.
The Cloudy instance as a whole can be reached via a web interface or the command line. The web interface is designed to provide an easy and accessible interface to end users, to cover the basic service operation (installation, configuration and management) and usage (Figure 3). The command line is the traditional approach to the system management, giving all the available administration options to more advanced or experienced users.
The different services in Cloudy are integrated to the distribution as a set of plugins. Cloudy provides a set of common tools and mechanisms to interact with the user via the web interface and with the community network cloud via the command line.
The Cloudy web interface is divided in three layers following a model-view-controller (MVC) providing the convenient resources for every service that is integrated. At the lower level, there are tools and scripts that interact with the operating system in order to install or remove software packages (either Debian packages or external ones), read and modify configuration files and exchange information with other Cloudy instances in the CN cloud. The higher level of the web interface provides a set of back-end tools to standardize the way information is displayed to the user. This includes a framework to add the services to the web interface menus, to translate web pages consistently and to render pages with a common design. Even if every service is added independently as a plugin, the result is a coherent web interface where the look and feel is kept coherent and consistent.
Cloudy consists of a number of new services for Linux, designed to help build cloud-computing services for decentralized, community networks. Cloudy's main components can be considered a layered stack with services residing both inside the kernel and higher up and user-level (Figure 4). The software developed in Cloudy can be grouped into one of three levels: software relating to the construction and management of the Cloudy distribution, platform services to enable and facilitate application development, and some (software-as-a-service) applications to demonstrate the functionality of the Cloudy platform.
Conceptually, Cloudy is located between the underlying community infrastructure that provides network connectivity at the bottom and the user on top.
We provide in the Cloudy distribution a set of ready-to-install services, which community network users are expected to find useful and attractive, grouped as Search, Community, 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.
The management interface is a light website made with PHP combined with the Bootstrap framework. This way, non-technically skilled users can find themselves comfortable and familiar with it. The interface is designed as a whole-framed page with a horizontal bar on top. This bar contains the following drop-down menus to access the website functions (left to right):
* System: access basic system functions (password change, updates, logout…) * Languages: change the language of the web interface * Search: show the list of services discovered * Clommunity: manage the cloud services shipped in Cloudy * Guifi: manage the Guifi.net-related services shipped in Cloudy
Depending on the chosen search mechanism, search is done over the instances of the micro cloud or over all Cloudy instances.
The Clommunity service menu in the Cloudy GUI shows the applications which come already integrated in the Cloudy distribution. The user, however, is free to decide if he/she wants to activate them (Figure 8).
The Guifi.net services allow to install a set of community network management services (Figure 9). 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.
As a Linux distribution, Cloudy lies at the lowest layer of the stack, providing custom decentralized network services for service discovery and service announcement. Service discovery and announcement are crucial building blocks for enabling distributed services to be orchestrated to provide platform and application services. Cloudy has adapted the TincVPN service to provide Layer 2 connectivity between community boxes. The layer 2 connectivity is needed between cloud boxes, as they may reside on different administrative domains and even be located behind firewalls. Cloudy also includes a customized version of Avahi to provide decentralized service discovery at Layer 2, again needed to discover other services that will be used to provide higher-level services. Cloudy also includes a number of tools to ease the building and packaging of our Debian-based distribution, as well as a user-interface to discover and use platform services available in a community cloud.
At the platform level, we have tested and evaluated a secure, decentralized file-system, TahoeFS, and we have also built two platform services to support application development on Cloudy. The first platform service is a NAT-traversal service that provides a fully-decentralized service that enables network connectivity between nodes, even if one or both of the nodes reside behind a NAT gateway. The second service is a decentralized key-value store, with a data model that closely resembles the JPA model, familiar to many Java programmers.
A number of decentralized applications demonstrate the potential for the Cloudy platform. The most challenging application to build is the P2P GVod system that uses the community cloud to help improve quality-of-service and provide bootstrapping for the system. GVod uses the NAT-traversal service to enable connectivity between nodes residing behind NAT. In parallel, a fully decentralized search service, based on Apache Lucene. This is a generic search service, where application instances act as both clients and servers for the search service. That is, clients collectively manage the search index, as well as being the users of the search index. The index is stored, partitioned, at all participating nodes in the system and can be searched in parallel.
The different services in Cloudy are integrated to the distribution as a set of plugins. Cloudy provides a set of common tools and mechanisms to interact with the user via the web interface and with the CN cloud via the command line.
1. Distributed Storage and Service Discovery for Heterogeneous Community Network Clouds. Mennan Selimi, Felix Freitag, Roger Pueyo Centelles and Agusti Moll. 7th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2014), London, UK, December 8-11, 2014.
2. Deploying Clouds in the Guifi Community Network. Roger Baig, Jim Dowling, Pau Escrich, Felix Freitag, Roc Meseguer, Agusti Moll, Leandro Navarro, Ermanno Pietrosemoli, Roger Pueyo, Vladimir Vlassov, Marco Zennaro. IFIP/IEEE International Symposium on Network Management (IM 2015), Ottawa, Canada, May 11-15, 2015.
TO REVISE There is a cloud of services which is independent of the underlying hardware or software managing the installed software in the nodes. To unify efforts we are developing the Guifi-Communify-Distro part of the cloud service software. The gcodis distro (Guifi-Community-Distro) is installed in the client nodes. The client nodes can be bare hardware or virtual environments provided by managers as CONFINE, OpenStack or similar. The next image shows the global architecture. ====== Software Architecture ====== The CLOMMUNITY software architecture defines the set of software components that make up our community network cloud distribution. All of the software included in our platform is open-source. Many of the components have been developed during the course of this project, and many others are open-source software services that we have adapted for the project. The services currently included in the architecture are based on the requirements from D2.1, our research from WP3, our experiments on the software on the provided community-lab testbed, and our experience on using the software in production at Guifi.net. An earlier version of our software architecture is defined in Section 4 of D2.1, where we described both the user and administrator perspective on our software platform. The software developed for the CLOMMUNITY architecture can be grouped into one of three levels: * software relating to the construction and management of the cloud-computing platform * Unordered List Item-platform services to enable and facilitate application development, * some application services to demonstrate the functionality of the CLOMMUNITY platform. —- ===== Abstract ===== Based on the research of the software services requirements of the project, the provided Community-Lab testbed and the experience at Guifi.net, we can define a Distributed Software Architecture structured in layers. Which is being used right now in the build of the Community Software Distribution and the provided Services to the final user. We describe the point of view of Users and Administrators. ===== Introduction ===== The available elements in the initial stages of the project were the Community-Lab testbed and the Community Network. We had to build a cloud system providing and making available distributed cloud services to Community Networks. By that reason, we have had to abstract the elements in layers and build a Distributed Software Architecture. ===== Architectural elements ===== We distribute the software in layers, for example, some software provides network access and other software provides the final layer with an UI for the final user of the project. From a top-down approach we have the next Architectural elements: * User UI and Applications: provides to the final user with applications and user interfaces to interact in a transparent way with the underlying Community Services. * Community Services: The services provided by the project with the Community Software Distribution. The offered Community Services are: Location of Services, Distributed Storage, and Video Streaming. The Community Services are installed using the Community Software Distribution. Those services are used by the User UI and Applications. * Community Software Distribution: The software distribution which runs over the underlying layers, in this case inside the Containers/Virtual Machines. This provides a way to pack and distribute the the full list of services provided by the project. The Community Services of the project are installed from this layer. * Containers/Virtual Machines: The elements of this layer can be Containers, Virtual Machines or similar elements. They're created inside the Network Operative System and allows the Installation of the Community Software Distribution. * Network Operative System: This is the base Operative System which runs inside a Community Box. It allows to create Containers/Virtual Machines. * Community Box: It's connected to the Community Network and the Network Operative System is installed inside it. This layer of hardware joins the software layer with the network layer from the point of view of the project. * Community Network: This is the network infrastructure, in our case we use a Community Network. This layer allows the use of Community Boxes with a network infrastructure. The next Table and Figure show visually the elements of the initial Architecture. ^ Architectural element ^ Layer ^ | User UI and Applications | Software | | Community Services | ::: | | Community Software Distribution | ::: | | Containers/Virtual Machines | ::: | | Network Operative System | ::: | | Bare metal hardware | Hardware | | Community Network | Network | Table 1: Community Distributed Software Architecture. Figure 1: Community Distributed Software Architecture. For the Services inside the Software Architecture we take into account that all are designed to maintain the data privacy of the user [freedombox][PRISM]. A proposal about the implementation of the Software Architecture is at [avproclo] at the Figure “Community ecosystem with connections and devices”. ===== User perspective ===== From the user point of view, the system is seen as a cloud of services: * The user can create a node to join the project. The node contains the project's provided software. There are incentives to participate in the project. * Location of Services: The user can publish new services and locate running services. The user gets a list of published services in the cloud. * Distributed Storage: The user has a directory where to put data and the user can share that data with other users. The data is distributed using various storage servers. In a concrete use case, that directory is accessed by the user and the other users in different standard ways: HTTP, FTP, and FUSE (with this, the user can see a cloud directory as a local directory). ===== Administrator perspective ===== From the administrator, developer or the advanced user perspective: * There is a hardware or software Node. The Node has to be installed and maintained. * The hardware or software Node connects to a Community Network. * The access to the Community Network has to be managed following the Community Network directives and using the proper hardware. * The Node contains the Network Operative System with its tools which contains Containers/Virtual Machines. * The Containers/Virtual Machines have installed the Community Software Distribution. The Containers/Virtual Machines can be managed with the provided default tools for each kind of element: Container, Virtual Machines or others. * The Community Software Distribution manages the Services and User Interfaces offered by the project. The Software Distribution can be updated, upgraded and managed. ====== CONFINE Client-Server Architecture ====== The Client-Server architecture of the project is inherited from to the CONFINE project, where there is a client-server architecture. There is a node called Controller, which is the center of the network, and there are client nodes which connect to the Controller to get data and operate. The client nodes can be viewed and controlled from the Controller. From the point of view of a developer, we see a client-server architecture, we put server services or hub for services in the server side. From the point of view of a cloud user, she sees a cloud of services given by the Layer 2 network using Avahi. ====== Architecture example elements ====== We'd like to show some related elements to the architectural parts as an example. ^ Architectural element ^ Layer ^ Examples ^ | User UI and Applications | Software | CLI/Web interface, OwnCloud | | Community Services | ::: | Services as Tahoe or CATS | | Community Software Distribution | ::: | The distro. gcodis join/complements guifi.net guinux. Debian based | | Containers/Virtual Machines | ::: | LXC containers, KVM, OR bare hardware | | Network Operative System | ::: | CONFINE, OpenNebula, OpenStack OR real operating system| | Bare metal hardware | Hardware | PC, barebone, rack | | Community Network | Network | guifi.net network, and community networks around the world | Table 2: Community Distributed Software Architecture, with examples. Generally we add a layer of virtualization to allow easily to manage the systems with a network operative system or a real operative system, being the containers allocated in virtual environments or real hardware, this give us more flexibility to configure and run the distro on top of them. ====== References ====== - [avproclo] Jiménez, Javier; Escrich, Pau; Baig, Roger. “Avahi proposal for Clommunity and Guifi.net (Published and unpublished services)”. 2013. Fundació Privada per a la Xarxa Oberta, Lliure i Neutral Guifi.net. - [freedombox] FreedomBox Foundation (2013). http://freedomboxfoundation.org/. Web. 13 Jun 2013. - [PRISM] Wikipedia (2013). “PRISM (surveillance program)” http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29. Web. 13 Jun 2013.