OpenNaaS-based Networking Solution for DC Automated Management

Transcription

1 OpenNaaS-based Networking Solution for DC Automated Management José Ignacio Aznar 1, Erik Ruiter 2, Joan Antoni García-Espín 1, Freek Dijkstra 2 1 Distributed Applications and Networks Area (DANA), i2cat Foundation, Barcelona, Spain 2 SURFsara, Amsterdam, The Netherlands {jose.aznar, joan.antoni.garcia}@i2cat.net, {erik.ruiter, Freek.Dijkstra}@surfsara.nl Abstract The main target of the proposed solution has been to develop and implement a vendor independent overlay platform on datacenter network infrastructures to simplify the administration of operational functions of SURFsara and achieve a solution easy to deploy, easy to configure and easy to manage, with MUST BE requirements and limited manpower resources. The solution proposes an OpenNaaS management framework powered implementation to provide data center administrators with a vendor independent overlay platform, which allows administration of the most crucial operational functions, and allows fixed administration permissions to users requesting for infrastructure resources. OpenNaaS platform constitutes an enabler for innovation opportunities for the cloud ecosystem and the European software industry. OpenNaaS is currently being proposed as service management tool to provide with a unified way to configure networking resources and ease the administrative networking load across the different network segments end to end. Keywords Cloud Networking; DC Network Management, Virtualization, OpenNaaS, Operational DC, Testbed I. INTRODUCTION National Research and Education Networks (NREN) connect to networks of academic and educational institutions, including University campus networks, academic hospitals, academic Data Centers (DCs), and remote instrumentation. Scientists typically want to transfer data from their data sources (e.g. from an academic hospital or remote instrumentation) to their storage or compute resources at an academic DC, and from there to a visualization or other cloud infrastructure. The providers of these infrastructures have to carry out various networking tasks to accommodate the needs of these scientists, like implementing VLANs, adding or removing routes, configuring access ports, applying routing filters, etc. The demands from scientists can be served by either generic solutions or specific per-project solutions. In addition, the solutions can be static in nature, or dynamic. The regular Internet is an example of a generic, static solution. Per-project solutions typically involve dedicated connections and can be either static (a connection specifically for a project) or dynamic (the scientists or the application software configures a path prior to sending traffic). SURFsara deploys a recent example of generic dynamic solution since 2010: a dynamic path is automatically configured when data traffic between different life-science grid clusters reaches a certain threshold. The many different data transfer workflows imply many different network solutions inside academic DCs, either terminated at a core router, providing another BGP peering relation or connected to a dynamically configured private network between the cloud nodes of a certain user. With the growth in number of solutions, the need to deploy automated service solutions and tools has grown. A complicating factor is that Cloud Infrastructure providers usually operate multi-vendor network environments (since some vendors support different requirements in their devices and the network requirements for each solution may widely differ). Due to the fact that there is no unified way of configuring all devices, network engineers require specific knowledge on each of them. In the end, a lot of time is spent on operational tasks, which could also be spent otherwise. The effort of this work addresses this specific limitation, directly issued from an Infrastructure Provider SURFsara in the context of Géant3+ project, lacking of a solution to efficiently address the networking resource provisioning problem and provide networked cloud resources with minimal management effort. SURFsara is the Dutch national academic data center. To this end, we propose the implementation and deployment of the OpenNaaS [1] software management platform, leveraging virtualization technologies applied on top of network and DC infrastructures to enable the administration of the most crucial operational functions. Our solution also provides with an overlay GUI of the physical network infrastructure to enable, SURFsara in particular and Cloud infrastructure providers in general, with the means to effectively configure networking Cloud resources. The overlay is vendor agnostic, and works on top of OpenNaaS. This constitutes a key advantage since it allows configuring different vendor equipment in a homogenized way. Besides, OpenNaaS platform allows delegating specific resource configuration/management features to users that traditionally have been restricted to DC infrastructure managers. This OpenNaaS-based solution has been deployed in a preproduction environment on SURFsara facilities to demonstrate the utility of integrating such management platform, easing the networking operations in DCs based on OpenNaaS technology. The remainder of this paper is organized as follows. Section II describes the state of art in terms of solutions for networking /14/$ IEEE 185

2 resource management in Cloud environments. Section III describes the OpenNaaS-based system solution, the components and the main benefits and impact especially for Cloud infrastructure providers. Section IV presents the test-bed scenario where the solution has been deployed and demonstration performance. Section V concludes the paper and depicts next steps to enhance networking resources management while incorporating new features. II. RELATED WORK A. Network Virtualization and Resource Models Over the last years, specific dedicated efforts have been made towards network equipment virtualization and Resource Models for representation of network resources in Cloud computing infrastructures: DMTF's Common Information Model (CIM) [2] is a network device information model commonly used in enterprise settings. It is described using the Unified Modeling Language (UML) and it attempts to capture descriptions of computer systems, networks and other related diagnostic information. YANG [3] is a modular language representing data structures in an XML format. A YANG module defines a hierarchy of data that can be used for NETCONF-based operations, including configuration, state data, RPCs, and notifications. The Topology and Orchestration Specification for Cloud Applications (TOSCA) [4], is an OASIS standard that describes the topology of a cloud application along with their dependent network infrastructures, services and artifacts inside a single service template. It has been accepted by NFV MANO WG for consideration as a probable candidate for describing NFV descriptors. Nevertheless, it is still in its early stage. The list of standards and models for network resource virtualization and abstraction is enormous. One key feature of OpenNaaS consists of the fact that it does not impose any standard for resource modeling thus each resource type can use a different one (e.g., DMTF CIM for router resource, INDL [5] for network resource model etc.). B. Network Resource Management Platforms Several recent initiatives are currently addressing networking resources provisioning and management aspects as well as resource virtualization techniques in order to enable more dynamic and automated deployment of DC hosted applications on top of them. FP7-GEYSERS approach [6] project, which has proposed architecture capable of provisioning Optical Network and IT resources for end-to-end service delivery based on virtualization and partitioning mechanisms. The test-bed implemented for demonstration purposes was specific to optical network technologies. The FP7-HARNESS project [7] is developing a new generation of cloud computing platform that integrates heterogeneous hardware and network technologies into DC platforms, increasing performance, but with a major focus on reducing energy consumption, and lowering cost profiles for important and high-value cloud applications such as real-time business analytics. The current adoption of Software Defined Network (SDN) technologies within DCs is bringing importance to the networking aspects of intra and inter-cloud environment, especially in Cloud federation environments. This is the case of FP7 T-NOVA [8] project, which aims at implementing an orchestration platform for the provisioning, configuration, monitoring, and optimization of Network Functions-as-a- Service over virtualized Network/IT infrastructures. T-NOVA leverages cloud management architectures for the elastic provision and (re-) allocation of IT resources assigned to the hosting of Network Functions. Also, the FP7 UNIFY [9] aims to unify the view of the network infrastructure and DC resources, leveraging software defined networking approach and virtualization of network functions. The project focuses on enablers of this unified production environment and aims to develop an automated, dynamic service creation platform, leveraging a fine-granular service chaining architecture. While referring to commercial solution platforms, Nuage Networks [10] provides software defined networking solutions for datacenter networks. Their Virtualized Services Platform consists of three products: Services Controller, Services Directory and Routing & Switching functions. They offer a virtualization environment for a datacenter network, but these software-based products are not open source and experienced difficulties on using and expanding an implementation based on these products in the future. Another relevant example is the Tail-f Network Control System [11], which provides a single interface to manage all network devices, application and services. As well as Nuage Networks product, it is designed to be a generic SDN. Previous DC composition approaches use schemes provide high-level services composition, but fail while providing more complex service solutions, which demand specific features and strict requirements in terms of network resources management, and orchestration. This prevents them from enabling more dynamic and automated deployment of distributed complex applications. OpenNaaS software platform facilitates the evolution of current cloud computing services into fully orchestrated execution environment services, offering to infrastructure providers the possibility to configure and manage networking Cloud resources and functions in a much more flexible and time-saving manner, giving the user more autonomy and flexibility too. III. DESCRIPTION OF THE OPENNAAS-BASED SOLUTION The main objective of the proposed work consists of enabling with a solution for the provisioning and management of networking DC resources in an automated and homogenized way. This makes easier to infrastructure providers to configure network resources according to specific application s requirements and include the basic control and management tools for providing Cloud capabilities support. Besides, the proposed solution enables to increase innovation opportunities for service providers, evidenced through the easy management of advanced cloud infrastructures and services. Additionally, we aim to provide IaaS providers with a network service abstraction, so that they can abstract the network service to the upper applications layer. This fact is important since it hides complexity and internal network configuration information and also enables to service providers to dynamically reallocate tenants resources to improve the network performance. 186

3 A. Physical Resources Primarily the datacenter management solution works with physical network equipment. SURFsara operates a lab environment, which hosts physical network resources, which are used to test the DC related possibilities of OpenNaaS. A number of vendors of network switches and routers are available to be used in this lab, like Juniper, Cisco, Dell and Arista. Besides, the setup also allows the use of virtualized network equipment. Some examples of virtualized resources are Juniper virtualized routers, Arista veos or OpenVSwitch switches, running on a virtual machine. An additional machine is used to host an OpenNaaS instance, which communicates to the resources using management connections, connecting to the control planes of the network equipment. The OpenNaaS machine also hosts a webserver, which is used for the overlay GUI. The virtualized environment shows that it is possible to host this solution on a cloud environment. Fig.1 shows the SURFsara configured testbed. Fig. 1. SURFsara data center management testbed. B. OpenNaaS Platform OpenNaaS is the outcome of the cooperation between several stakeholders and was born with the goal of creating a robust and extensible European Open Source management platform for provisioning network resources. It allows the deployment and automated configuration of dynamic network infrastructures and defines vendor-independent interfaces to access services provided by these resources. This is enabled based on the virtualization and abstraction of underlying network technologies. OpenNaaS offers a versatile toolset for the deployment of network oriented services. The software is released with a dual L-GPL/ASF licensing schema that ensures that the platform remains open and consistent, while commercial derivatives can be built on top. This open schema allows trust to be built on the platform, as stakeholders can rely on the continuity, transparency and adaptability of the platform. 1) OpenNaaS overall architecture: OpenNaaS tool is divided in three layers, as it can be seen in Fig. 2: The Platform, the NaaS layer and the Network intelligence. The platform is the core of the system; it provides the application context and defines its technological framework, including communication channels to access OpenNaaS. In this layer, common components based on the NaaS abstraction are defined. Controllers for such components are also provided. This platform serves as the basis for the NaaS (Network as a Service) layer. The NaaS layer reuses platform defined components to expose user manageable resources. This layer offers support for concrete resource types, functionalities (called capabilities) and device types. Resources and capabilities are exposed to the user, abstracted from implementation details and from hardware specifications. Hence, this layer acts as a Hardware Abstraction Layer. Applications willing to manage the network may be built on top of the abstraction provided by the NaaS layer. These applications compose the Network Intelligence layer, as it is here where managing policies may be defined and actions based on them applied to the network using OpenNaaS. Normally, these applications are not shipped with the OpenNaaS distribution, but independently from it. 2) OpenNaaS: Resources and Capabilities: OpenNaaS allows the creation of a virtual representation of a physical resource (e.g. network, router, switch, optical device or computing server), based on an abstract model of that which is often achieved by partitioning (aka slicing) and/or aggregation. Thus, the OpenNaaS framework is characterized by the resources, which present manageable. A Resource can be (among other things) a switch, a router, a link, a logical router or an entire network; each resource is composed of one or more capabilities. A capability is an interface to a given resource functionality (e.g. OSPF configuration in router resource). By modeling underlying the network in terms of resources and capabilities, OpenNaaS is capable to abstract such network to get information from it and trigger configuration actions, on top of it. 3) OpenNaaS proposed solution More specifically, in this work it has been developed a service to provide a vendor independent overlay on SURFsara DC network infrastructure and enable to carry out switch network resources operational tasks more efficiently by (i) simplifying the operation model and (ii) delegating tasks to users demanding such resources. The operational model simplification is achieved based on the OpenNaaS switch resource model that comprises several capabilities that enable administrators to simplify the operations while configuring it. Resources can be extended on demand by adding new and reusable capabilities, which are presented as configuration options to the DC administrators. Thus, the resources can hold a number of configuration options by simply plugging in the OpenNaaS additional capabilities in form of software bundles. Such flexible design enables to add and remove configuration options to the switch resource. OpenNaaS platform abstracts the vendor specific parameters and provides a simplified configuration menu to the DC admin. With regards tasks and rights delegation, the resource configuration options are available by means of atomic capabilities. OpenNaaS platform enables to split the resources 187

4 configuration settings ownership. This feature entails that DC administrator may delegate fixed configuration options to the users which are requesting IaaS-based services, while they keep most critical ones only available to them for administration purposes. Fig. 2. OpenNaaS architecture and implemented resources for DC administration solution. OpenNaaS Web Portal Switch C. Overlay GUI The Overlay GUI is based on PhP scripts running on a web server, making use of widely used web techniques. The GUI communicates with the OpenNaaS platform through a REST interface. Information is exchanged using an XML format. The source code of the GUI is compact in size and makes use of widely used web development techniques like CSS, AJAX and jquery to facilitate the required functionality of the GUI elements. The GUI provides access to the most commonly used functions for managing network infrastructure, and makes use of the OpenNaaS core components like the resource manager and the queuing system. The GUI aims to provide a generalized view, where GUI elements are being reused for various functions. For instance it uses a generalized pop-up box which is used to allow user input when changing the settings of capabilities. Also the tables used in the GUI all have the same functionality, with regards to sorting, searching and paged display of data. The GUI can be used to view and change configurations of the resources, which are managed through OpenNaaS. This can be done through different methods. One example is by selecting a single device and changing its individual configuration. But also changing parameters by using a more global perspective is possible. For instance, a new VLAN can be created and be assigned to multiple switches at once, or a group of ports on different switches could be assigned to a single VLAN, in a single action. IV. IMPLEMENTATION AND DEMONSTRATION PERFORMANCE A. Requirements for the Demonstrator Using OpenNaaS as a management solution for operating datacenter network equipment imposes a lot of additional requirements and nice-to-have for the OpenNaaS platform. Some of the must-have options are discussed here. 1) Abstraction of L2 / L3 protocols An important feature of OpenNaaS is that it aims to build an abstraction layer around network resources. This means that these resources can be managed in a more generalized way. This should also be the case for layer 2 and layer 3 protocols that are used by routers and switches. A good example can be the abstraction of VLANs. For each network resource, OpenNaaS should know what VLANs are configured and to which ports they are assigned, and which methods of VLAN tagging are used. When this information is abstracted for the entire managed topology, it can allow sanity checks on the VLAN configuration (for instance to see if allowed VLANs are matching on two sides of a trunk connection) or even automatic configuration of VLAN tagging across different switches. Other examples of protocols that could be abstracted are OSPF or spanning tree. 2) Topology awareness: It is important that the network topology is known to the OpenNaaS platform to be able to provide a clear picture of the network to the user. This feature is also required to have as part of the abstraction of certain network protocols. For instance it is only possible to manage a VLAN domain, if it is known which interfaces on different switches are connected to each other and are forming trunks. The same applies to managing an OSPF topology, for which it is required to know which interfaces are adjacent to each other. This requirement can be achieved by using the LLDP Link Layer Discovery Protocol, which allows network equipment to exchange information about their shared interfaces? This information can be used to build the topology. 3) Multi-vendor support: Any datacenter will have different types of network equipment from different vendors. An example of a heterogeneous network environment is SURFsara, which uses at least seven different vendors of access switches. This means that a datacenter management solution should also be flexible in dealing with this multiple vendors. Currently the demonstrator for datacenter management only supports Juniper switches using the Junos operating system, and makes use of the Router resource in OpenNaaS. 4) User authorization: 188

5 When administrating a data center network, it should be clear that not every user is allowed to perform all possible actions that are available in the OpenNaaS platform. It should be possible to assign a subset of the available resources and a subset of the available capabilities to certain users. For instance, it might be a good idea to allow certain users to configure interfaces and assign VLAN tagging on certain access switches, but not allow any actions on aggregation switches or routers. It should then be possible to create a profile using these criteria and assign it to one or more user accounts. This applies to all available resource types and individual capabilities that they posses. A. Implemented capabilities The current implementation of the demonstrator has a number of pages and functions available. The main window of the GUI provides a menu structure on the left side, and HTML tables on the main area. The contents and functions of the menu items are described here: 1) Show Resources Menu: This page provides an overview of all resources managed by OpenNaaS. From this overview it can be accessed the individual resources and explore their capabilities. It shows the resource name, type and a list of capabilities. This overview will enables to start, stop or delete a single resource, or by ticking checkboxes you can perform these functions on a group of resources. Several sub-menus have been also implemented: Resource Chassis sub-menu: this is the most informative and functional page. By selecting a device in the Show Resources Menu, it provides an overview of all interfaces in a resource, and some details of the interfaces it self. If there are any aggregated interfaces present, these will be clickable so that you can see some details about the aggregate, for instance to see the interfaces that make up the LACP bundle. The page allows you to change the state of a single or a group of interfaces, lets you edit the description of the interface, and lets you add any IPv4 or IPv6 addresses, in case it are routed ports. When changing these fields a pop-up screen will show, which will allow you to enter the new value. When this is done, the action will be generated and be placed in the queue. Above the interface list, you will then also see an indication that the queue for this resource contains some actions. Resource Queue sub-menu: this shows the current queue for the selected resource. It allows managing the actions found in the queue. Single or groups of actions can be deleted, and the queue can be executed. Resource info sub-menu: Currently this page is only for informational purposes. It shows details about the Resource protocol context. These are variables, which OpenNaaS requires to communicate with the resource. It is sourced from OpenNaaS resource manager module. 2) Show Queue Menu: This page shows an overview of all the individual actions, for all resources, which are currently queued to be executed. Each action is listed, showing the concerned resource, and an ID to show the order of execution. Individual or groups of actions can be executed or removed using this page. 3) Show VLANs Menu: It shows an overview of all VLANs which are found in the OpenNaaS platform. It also shows on which resources these VLANs are configured. Any IP related information to the VLANs is also listed here. In a newer version of the GUI, this page will allow you to create VLANs and assign them to groups of switches. Fig. 3 shows a screenshot of the GUI that enables to set some of the described configuration options. Main menus are listed on the left. More specifically it shows how an interface description of a switch resource is modified within the Resource Chassis sub-menu. The switch vendor specific configuration options are hidden to the administrator who sets up the description in a vendor-agnostic way. Fig. 3. Screenshot of the GUI to configure options on switch 2. The figure shows the operation to modify the description of ge-0/0/6.0 interface. 189

6 B. Scenario- under the hood The demonstration scenario set-up is shown in Fig. 4: 1. SURFsara operates a Lab environment used to test the DC related possibilities of OpenNaaS. The Lab hosts physical network resources and virtualized equipment. 2. A VM hosts an OpenNaaS instance, which communicates to the resources using management connections, connecting to the control planes of network equipment. The OpenNaaS VM also hosts a webserver running PHP scripts, which is used for the overlay GUI. 3. The GUI provides access to the most commonly used functions for managing network infrastructure, and makes use of the OpenNaaS core components like the resource manager and the queuing system. Fig. 4. Developed scenario at SURFsara facilities. The scenario involves a cloud administrator, which needs to accomplish several tasks, without actual support from a network engineer. Aside from physically connecting the server node to a network switch, the administrator performs the network provisioning of the server node. The following tasks can then be accomplished by using the overlay GUI: 1. Administratively enable the switch ports 2. Configure the connected switch ports to operate in a LACP bundle for better resiliency. 3. Assign appropriate 802.1q tagging to the link aggregate, to have the server connected to the correct VLAN. 4. Where necessary adjust L3 routing and security policies to allow access to the services running on the node The administrator has no specific knowledge of the different vendors of network infrastructure equipment, which are used in the datacenter, but does have general understanding of the involved layer 2 and 3 protocols. V. CONCLUSIONS AND NEXT STEPS The presented solution overcomes today s limitations on datacenter networks control and management by building a NaaS application as a result of the collaboration between SURFsara and i2cat in the GÉANT3+ project. From a business perspective, our solution chases two clearly identified benefits: (i) Reduce the administrative load of network staff by delegating small operational tasks to the system administrators and (ii) acquire administrative freedom and increased insight into the network to potentially lead an OPEX reduction, since fewer resources are required to manage the network. From a technical point of view, this solution also pursues to make easier DC administration tasks while operating their infrastructures. Having networking resources as a first-class resource within the Cloud, enables to Infrastructure providers to configure and manage the networking aspects of the Cloud environment and provides them with an automated and flexible configuration mechanism to overcome current networking resource limitations and provide a more flexible performance than previous static network provisioning service approaches. In addition, network service abstraction enables to hide the upper applications layer and users, the complexity of the underlying topology framework. This feature implies a better understanding of network infrastructure and more freedom to connect server equipment on the access layer. Therefore, OpenNaaS platform constitutes an enabler for innovation opportunities a great number of small and medium, yet highly skilled and innovative, firms, allowing them to tap into a vast pool of advanced cloud-based functionalities to empower the next generation of their applications in a cost-effective and efficient manner. We plan to enhance the set-up while adding new capabilities and resources to the solution and will increase the number of configuration options. Pilot implementation pre-production deployment is also scheduled for the mid-term. ACKNOWLEDGMENT The work presented in this paper is supported by the EU funded GEANT3+ project and has been prepared with the support of Dr. Freek Dijkstra, from SURFsara. REFERENCES [1] [2] Common Information Model (CIM) Infrastructure Specification, DMTF Standard DSP0004, 2012 [3] M. Bjorklund YANG, A data modeling language for NETCONF, IETF RFC 620, [4] OASIS Committee Specification, "TOSCA version ," http: //docs.oasis-open.org/tosca/tosca/v1.0/csd03/tosca-v1.0-csd03.html [5] Mattijs Ghijsen et al, Towards an Infrastructure Description Language for Modeling Computing Infrastructures, In The 10th IEEE International Symposium on Parallel and Distributed Processing, 2012 [6] Escalona, E., et al., GEYSERS: A novel architecture for virtualization and co-provisioning of dynamic optical networks and IT services in Future Network and Mobile Summit, [7] J. G. F. Coutinho, et al., HARNESS Project: Managing Heterogeneous Compute Resources for a Cloud Platform. In Proc. the 10th International Symposium on Applied Reconfigurable Computing (ARC), April, 2014 [8] [9] A. Császár, et al., Unifying Cloud and Carrier Network - EU FP7 Project UNIFY, Workshop on Distributed Cloud Computing (DCC 2013), December 2013 [10] [11] 190