Changes between Version 55 and Version 56 of orca-introduction

Show
Ignore:
Timestamp:
05/10/11 18:03:28 (8 years ago)
Author:
vjo (IP: 152.3.145.66)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • orca-introduction

    v55 v56  
    44== Overview ==  
    55 
    6 Orca is a software framework and open-source platform for managing a programmatically controllable shared substrate, which may contain any combination of servers, storage, networks, or other components. This class of systems is often called cloud computing or utility computing. 
     6ORCA is a software framework and open-source platform for managing a programmatically controllable shared substrate, which may contain any combination of servers, storage, networks, or other components. This class of systems is often called cloud computing or utility computing. 
    77 
    8 The Orca software is deployed as a control framework for a prototype GENI facility. We see GENI as an ambitious futuristic vision of cloud networks as a platform for research in network science and engineering. 
     8The ORCA software is deployed as a control framework for a prototype GENI facility. We see GENI as an ambitious futuristic vision of cloud networks as a platform for research in network science and engineering. 
    99 
    10 An Orca deployment is a dynamic collection of interacting control servers (''actors'') that work together to provision and configure resources for each guest according to the policies of the participants. The actors represent various stakeholders in the shared infrastructure: substrate providers, resource consumers (e.g., GENI experimenters), and brokering intermediaries that coordinate and federate substrate providers and offer their resources to a set of consumers. 
     10An ORCA deployment is a dynamic collection of interacting control servers (''actors'') that work together to provision and configure resources for each guest according to the policies of the participants. The actors represent various stakeholders in the shared infrastructure: substrate providers, resource consumers (e.g., GENI experimenters), and brokering intermediaries that coordinate and federate substrate providers and offer their resources to a set of consumers. 
    1111 
    12 Orca is based on the foundational abstraction of resource leasing. A lease is a contract involving a resource consumer, a resource provider, and one more brokering intermediaries. Each actor may manage large numbers of independent leases involving different participants. 
     12ORCA is based on the foundational abstraction of resource leasing. A lease is a contract involving a resource consumer, a resource provider, and one more brokering intermediaries. Each actor may manage large numbers of independent leases involving different participants. 
    1313 
    1414This document is meant to present a brief overview of ORCA architecture, principles and operation. For more information please refer to the ''Further Reading'' section below. 
     
    2828 * Authority or Aggregate Manager (AM). An authority actor controls access to some subset of the substrate components. It corresponds directly to the aggregate manager (AM) in GENI. Typically, an authority controls some set of infrastructure resources in a particular site, autonomous system, transit domain, administrative domain, or component aggregate comprising a set of servers, storage units, network elements, or other components under common ownership and control. Terminology note: the term ''site'' or ''site authority'' (e.g., a cluster site or hosting center) is often used to refer to a substrate authority/AM, as a result of our roots in virtual cloud computing. For network substrates we are using the term ''domain authority'' more often when it is appropriate. 
    2929 
    30  * Slice/Service Manager (SM) or Slice Controller. This actor is responsible for creating, configuring, and adapting one or more slices. It runs on behalf of the slice owners to build each slice to meet the needs of a guest that inhabits the slice. Terminology note. This actor was originally called a Service Manager in SHARP (and in the Shirako code) because the guest was presumed to be a service. As GENI has developed, we have adopted the term Slice Manager (SM) because the actor’s role is to control the slice, rather than the guest itself, and because in GENI the guest is an experiment rather than a service. A Slice Controller is a plugin module to an SM actor, with a control policy for slices managed by that SM. 
     30 * Slice/Service Manager (SM) or Slice Controller. This actor is responsible for creating, configuring, and adapting one or more slices. It runs on behalf of the slice owners to build each slice to meet the needs of a guest that inhabits the slice. Terminology note: this actor was originally called a Service Manager in SHARP (and in the Shirako code) because the guest was presumed to be a service. As GENI has developed, we have adopted the term Slice Manager (SM) because the actor’s role is to control the slice, rather than the guest itself, and because in GENI the guest is an experiment rather than a service. A Slice Controller is a plugin module to an SM actor, with a control policy for slices managed by that SM. 
    3131 
    32  * Broker. A broker mediates resource discovery and arbitration by controlling the scheduling of resources at one or more substrate providers over time. It may be viewed as a service that runs within a GENI clearinghouse. A key principle in Orca is that the broker can have specific allocation power delegated to it by one or more substrate authorities, i.e., the substrate providers “promise” to abide by allocation decisions made by the broker with respect to their delegated substrate. This power enables the broker to arbitrate resources and coordinate allocation across multiple substrate providers, as a basis for federation and scheduling of complex slices across multiple substrate aggregates. Brokers exercise this power by issuing tickets that are redeemable for leases. 
     32 * Broker. A broker mediates resource discovery and arbitration by controlling the scheduling of resources at one or more substrate providers over time. It may be viewed as a service that runs within a GENI clearinghouse. A key principle in ORCA is that the broker can have specific allocation power delegated to it by one or more substrate authorities, i.e., the substrate providers “promise” to abide by allocation decisions made by the broker with respect to their delegated substrate. This power enables the broker to arbitrate resources and coordinate allocation across multiple substrate providers, as a basis for federation and scheduling of complex slices across multiple substrate aggregates. Brokers exercise this power by issuing tickets that are redeemable for leases. 
    3333 
    3434[[Image(orca-arch.png, 600px)]] 
     
    5959== Implementation == 
    6060 
    61 ORCA is implemented as a webapp intended to run inside a Tomcat Java servlet engine. A webapp is packaged as a [http://en.wikipedia.org/wiki/WAR_file_format_(Sun) webapp WAR file]. Internally the webapp implements a ''container'' in which one or more ORCA actors run. Actors can communicate with other actors across multiple containers. Actors digitally sign their communications using self-signed certificates (using certificates issued by a commercial CA is also possible). SSL is not used. We believe that state-changing commands or actions must be signed so that actions are non-repudiable and actors can be made accountable for their actions. SSL alone is not sufficient for this purpose. Given that we are concerned with message integrity and authenticity, and not privacy, SSL is not necessary either.  
     61ORCA is implemented as a webapp intended to run inside a Tomcat Java servlet engine. A webapp is packaged as a [http://en.wikipedia.org/wiki/WAR_file_format_(Sun) webapp WAR file]. Internally the webapp implements a ''container'' in which one or more ORCA actors run. Actors can communicate with other actors across multiple containers. Actors digitally sign their communications using self-signed certificates (although using certificates issued by a commercial CA is also possible). SSL is not used. We believe that state-changing commands or actions must be signed so that actions are non-repudiable and actors can be made accountable for their actions. SSL alone is not sufficient for this purpose. Given that we are concerned with message integrity and authenticity, rather than privacy, SSL is not necessary.  
    6262 
    6363ORCA currently uses a slightly modified version of Tomcat 5.5 [source:/software/tomcat.tar.gz available here]. Off-the-shelf Tomcat or other servlet engines (like Jetty) will not work.  
     
    6565Most of the ORCA code is written in Java, although substrate handlers (parts of code responsible for creating and destroying slivers of different kinds) are implemented as a combination of Ant scripts, Java tasks and bash scripts. ORCA user tools that speak to its GENI and ProtoGENI AM API-compliant controller are written in Python. 
    6666 
    67 The code is organized as a series of [http://en.wikipedia.org/wiki/Apache_Maven Maven] projects under a common tree and can be compiled and built using only a few steps, assuming software prerequisites are met. At this time a [wiki:orca-binary-release pre-packaged distribution] is also available. A new user can either download the binary WAR file or the download the source release of the code (we strongly recommend using the latest available stable release), compile it, create configuration files and build and deploy the (built or downloaded) WAR file into the Tomcat servlet engine. 
     67The code is organized as a series of [http://en.wikipedia.org/wiki/Apache_Maven Maven] projects under a common tree and can be compiled and built using only a few steps, assuming software prerequisites are met. At this time a [wiki:orca-binary-release pre-packaged distribution] is also available. A new user can either download the binary WAR file or the download and compile the source release of the code (we strongly recommend using the latest available stable release), create configuration files and deploy the (downloaded or built) WAR file into the Tomcat servlet engine. 
    6868 
    6969Currently ORCA supports a number of different substrate types: [wiki:NEuca-overview Eucalyptus private cloud clusters (with NEuca extensions)], NLR Sherpa dynamic VLAN service, [https://ben.renci.org BEN multi-layered optical network] and a number of testbeds.  
     
    8383A [source:orca/trunk/webapp/actor_configs/config.xml default actor configuration XML file] is included with the binary distribution of the webbapp and the source code. This file starts a single-container emulation of three basic ORCA actors - an authority, a broker and a service manager. Emulation refers to the fact that ORCA does not operate on real substrate and only goes through the motions of managing reservations. An alternative configuration XML file can be created and placed outside of ORCA, in which case the default file will be ignored. Also, if you are rebuilding ORCA from source, you can package it with your own version of the actor configuration XML file into the WAR file.  
    8484 
    85 A relatively new feature of ORCA is an [http://geni.renci.org:11080/registry/actors.jsp ORCA actor registry] - a separate component that is run as a service for all ORCA users. If desired actors in any container can register with this registry and thus automatically become visible to all other publicly available actors. This feature allows for a much simpler configuration process, especially the actor topology part. In many cases using the ORCA Actor Registry makes the actor topology definition in the actor configuration XML file unnecessary. 
     85A relatively new feature of ORCA is an [http://geni.renci.org:11080/registry/actors.jsp ORCA actor registry] - a separate component that is run as a service for all ORCA users. If desired, actors in any container can register with this registry and thus automatically become visible to all other publicly available actors. This feature allows for a much simpler configuration process, especially the actor topology part. In many cases using the ORCA Actor Registry makes the actor topology definition in the actor configuration XML file unnecessary. 
    8686 
    8787== Operation ==  
    8888 
    89 A deployed ORCA container can be accessed through a browser-friendly portal. In the current implementation, this Web portal provides a common GUI interface to all of the actors in a single container. A container owner can manage all the actors in her container through the web portal. This includes creating resource delegations from authorities, claiming resources from brokers and creating resource reservations from service managers. A standard ORCA distributions includes an XMLRPC controller compliant with [wiki:orca-xmlrpc-controller GENI AM and ProtoGENI AM APIs] that can be accessed via XMLRPC tools. This controller can be started when a container that has the service manager actor is deployed. Other controllers exist and are possible to create with any desirable interface (GUI or command-line).  
     89A deployed ORCA container can be accessed through a browser-friendly portal. In the current implementation, this Web portal provides a common GUI interface to all of the actors in a single container. A container owner can manage all the actors in her container through the web portal. This includes creating resource delegations from authorities, claiming resources from brokers and creating resource reservations from service managers. A standard ORCA distribution includes an XMLRPC controller compliant with [wiki:orca-xmlrpc-controller GENI AM and ProtoGENI AM APIs] that can be accessed via XMLRPC tools. This controller can be started when a container that has the service manager actor is deployed. Other controllers exist and are possible to create with any desirable interface (GUI or command-line).  
    9090 
    91 ORCA includes advanced recovery features that allow individual containers to shut down and come back up while the actors in the retain their state. Recovery can be turned on or off when a container is restarted depending on the need. 
     91ORCA includes advanced recovery features that allow individual containers to shut down and come back up while the actors within retain their state. Recovery can be turned on or off when a container is restarted, depending on the need. 
    9292 
    9393== Further reading ==