8 Enhanced Network Support for Scalable Computing Clouds |
137 |
by relying on information models responsible for capturing structures and relationships of the involved entities. Access to the optical transport network control plane may be realized through an optical user-network interface (O-UNI) standardized by the Optical Internetworking Forum (OIF) [8]. The optical network services can be made available to the upper middleware layers through an O-UNI compliant programmatic interface library interfacing the client-side middleware services with the underlying edge routers. Every interface function can be in turn mapped to a set of UNI primitives for network resource setting. Each network resource or node has to be described by a set of XML interface elements, and the main interface methods should allow the management and monitoring of the available LSPs and relative traffic and performance parameters. Thus, every connection created will be characterized by the virtual channel or LSP (identified by the addresses engaged) that in turn is characterized by a set of attributes (service class, bandwidth available and utilized). In detail, the proposed abstractions, supporting the connectivity services, concern:
•The creation of a virtual point–to-point or multipoint network that transparently allows the connection between its endpoints with specific performance attributes (bandwidth, latency, and protection)
•The deletion/release function that allows an existing virtual network to be deleted and its resource released for further usage
•The modification of a virtual point-to-point or multipoint network by adding or removing some participants or changing its service-level requirements
8.5 Proof of Concept Implementation
and Performance Analysis
We proved the main concepts beyond the presented model and analyzed its performance by using a very simple cloud prototype testbed, implemented on the existing Federico II University high-performance network and scientific computing infrastructure. In particular, the infrastructure-layer services have been implemented on top of the distributed grid infrastructure that unifies all the main computing and storage resources belonging to the SCoPE (Italian acronym for high Performance, Cooperative and distributed System for scientific Elaboration) project. Such grid infrastructure is based on the gLite [9] middleware and spans several data centers geographically distributed in the Naples urban area. Its connectivity is supported by a metropolitan optical fiber network that offers high-performance communication facilities to all the involved research sites.
8.5.1 The Prototype Details
The architecture of the cloud prototype matches the three-layer paradigm presented in the previous sections (see Fig. 8.2).
138 |
F. Pamieri and S. Pardi |
Application
Platform
Infrastructure
Fig. 8.2 The prototype architecture
The main technological choices underlying our prototype implementation are:
•gLite at the infrastructure layer. Such solution realizes a resource-virtualization facility based on the traditional gLite core and collective services, specifically conceived for e-science applications. gLite provides computing and storage facilities through a web services based interface by using the CREAM and SRM protocols, and implements data-movement services, resource brokering, workload management, and accounting. The gLite middleware can be integrated with other infrastructure management facilities, such as VM-based runtime environments (i.e. OpenNebula [10]) and map-and-reduce [11] services (i.e. Hadoop [12]). For our testbed, we extended the gLite middleware by introducing the support of some basic network control services and interfaces.
•The platform layer is implemented by using the eyeOS [13], a Cloud Operating System. EyeOS offers Web 2.0 like tools, available through a flexible and powerful Web Desktop interface for the creation of new cloud applications, simply by using a meta-language based on PHP/AJAX. EyeOS manages user profiles and interacts with the underlying infrastructure layer.
•Finally, the application interface has been implemented through a portlet container that guarantees the seamless integration of different technologies and exposes the cloud prototype user interface, monitoring facilities, and Wiki pages. The product of choice is LifeRay, an open-source solution based on a Service Oriented Architecture (SOA) that supports Single Sign-On (SSO) for simplifying user authentication and authorization tasks.
The above-mentioned software stack guaranteed the abstraction and virtualization services needed at each layer of the cloud architecture, and offered simple and effective mechanisms for creating new applications and making them available to the final users throughout the cloud infrastructure.
8.5.1.1 The Underlying Network Infrastructure
The physical transport infrastructure, on which our prototype is based (see Fig. 8.3), is approximately 50-km long, consists of 156 single-mode fibers connecting, in a
8 Enhanced Network Support for Scalable Computing Clouds |
139 |
Fig. 8.3 The prototype network
multi-ring shape with multiple differentiated ways, four ring-to-ring interchange and service aggregation centers strategically placed on the metro area, which realizes the main transport and access distribution infrastructure. The backbone is built on a fully meshed core realized between four high-performance Cisco routers (a 12410 GSR and three 7606 OSRs), each acting as an access aggregation point (POP) in the metropolitan area. On the multi-ring backbone, we deployed an MPLS-based control plane architecture capable of establishing, managing, and tearing down bandwidth and QoS-guaranteed end-to-end connections.
8.5.1.2 The Prototype Cloud Network Control Logic and its Services
The network control logic has been implemented within our prototype testbed, by integrating a set of Perl scripts realizing some simple interface services at the gLite middleware layer, with the eyeOS interface. Such simple kernel of network services interacts with other cloud services/applications at different levels of the cloud stack, and enables location-independent data transfer and replication, together with bandwidth on demand and virtual-switch implementation through the user-interface facilities. The basic functions provided are reserving, releasing, and querying or modifying the status of end-to-end virtual circuits between different sites of the underlying distributed computing infrastructure. They have been made available through a web-service interface, in which every basic operation is characterized by a set of user-layer attributes (i.e. service class, bandwidth, and traffic-flow identifier) that in turn is implemented at the control-plane layer by a couple of unidirectional traffic-engineered LSP tunnels, together with some flow-specific routing policies. Every basic service function is in turn mapped to a set of Cisco CLI commands for network resource configuration, submitted to the network elements within the MPLS core using the Net::Telnet::Cisco standard Perl interface. Each invocation of specific function triggers the execution of a Perl script using a dedicated CLI session for the duration of its execution. When triggering the creation of pseudowire connections between the nodes, the requiring application needs to supply detailed information about all the physical nodes and ports involved to the network control logic. These data can be obtained on each node through the Cisco CDP protocol using a simple Perl interface agent (based on the Net::CDP standard class/module).