What is Orca?

Orca (Open Resource Control Architecture) is a framework for distributed lease-based sharing of a resource substrate comprising a collection of components owned/controlled by one or more resource providers. In this context, the term resource means any network-accessible substrate component, such as, physical machine, virtual machine system, storage capacity, network bandwidth, etc. Orca provides the means to control the access to and management of distributed collections of resources. The system is intended to manage networked utilities, such as computational grids, network testbeds, or hosting services. It provides the means to manage virtualizable resources to balance isolation and sharing, monitor and control resource status, match resource supply and demand, and adapt applications and services to the dynamics of a shared environment.

An Orca system is a collection of actors that interact using the leasing protocols. Logically, each actor is a server with private internal state that persists in a database. Each provider site or domain is represented by an authority actor. Each guest environment that consumes resources is represented by an actor called a service manager . Other actors represent brokering intermediaries (also known as clearinghouses).

We build Orca actors in Java using the Shirako leasing toolkit. Each actor is a Java-based server running within a JVM container . Multiple actors may share the same container. There is more about containers below.

What does it mean to use Orca? A typical user will interact with a shared facility through a Web portal to acquire resources (e.g., virtual machines) and launch application environments. This documentation is mostly for people who want to build and deploy their own actors. The target audience includes developers of the system itself, operators who want to set up an Orca facility to manage shared clusters and other resources, and developers of guest environments that lease resources from one or more Orca sites/domains.

Fair warning

Orca has lots of moving parts that can be connected and configured in different ways. You can add your own parts, build a facility from pre-existing parts, or connect into an existing facility or network of facilities. Fair warning: Orca is still a work in progress. Configuration is complex and can be tricky. Some of the parts are missing or don't fit together as expected. Documentation is spotty. Orca uses a lot of other open-source tools that are themselves moving targets. These tools must be installed properly on the systems you are using. As with all complex systems you may discover dependencies that are fragile and unexpected. (If so, please let us know.)

Deploying actors

Most of this documentation is geared to users who want to install one or more actors in one or more containers.

• If you want to run a provider site, then you need to deploy an authority actor, give it control of some inventory , e.g., a server cluster, and connect it to one or more brokers.
• If you want to run a guest on an Orca system, then you need to deploy a service manager actor and connect it to one or more brokers and authority servers representing resource providers.
• If you want to experiment with resource arbitration policies, or coordinate resource allocation for multiple sites, then you need to deploy a broker actor.
• If you want to work with a self-contained Orca system that is entirely under your control then you will deploy all three types of actors.

Shirako handles most of the details of creating new actors: all you need to provide is one or more policy (controller) modules for each of your actors, which you can write yourself or configure off-the-shelf. The Orca release includes some other useful pieces, including support for per-container database servers, tools for actor configuration, and a Velocity-based web portal that can run within a container or attach to other containers, and exports a Web interface to control actors in the container.

Building and installing the source release

To create and install Orca actors, you must build the sources from the Orca repository. We do not yet support binary installation. The rest of these instructions presume that you have a version of the source release checked out in $ORCA_HOME.

The Orca Installation Guide describes the steps to build the project.

Throughout the documentation, the root directory of the Orca source release is referred to as $ORCA_HOME.

Launching a container

We often use the terms Orca container and Orca instance interchangeably and/or use "Orca" as a shorthand for an Orca container. E.g., when we say "run Orca" we really mean "to launch an Orca container", the "Orca admin" is really the admin of an Orca container (different containers may have different admins), and so on.

Containers may be launched in any of several ways: from the command line, or within a Web application server such as Tomcat, or within a development environment such as Eclipse. Install/configure is slightly different in each case.

Please consult the Container Configuration Guide for detailed information about setting up a container.

The Container Configuration Guide will take you through the following:

The Orca Configuration Tools are used configure keys etc. for actors and containers to interact, and also to enable an authority to operate on the components that it controls.

The Orca Command-line Guide describes how to configure and execute an Orca container from command-line scripts.

The Orca Web Portal Guide describes how to configure and execute an Orca container as a web application with a Web portal interface.

Running a provider

Your container may include an authority actor to manage a resource provider site/domain. For example, if you are exporting a cluster or some other resources to users and guest applications, you must configure your authority actor about the resource inventory (substrate components) that it controls and the things that it can do with them.

Testing a container XML configuration file

It is often necessary to verify the correctness of a container XML configuration file . For example, such verification can save time when trying to deploy Orca as a web application. It is recommended that you verify your configuration files prior to using them for experimentation or execution.

To verify a Container XML Configuration File you can use the run project (make sure that you have performed all necessary configuration):

 cd $ORCA_HOME/run
 ant test.configuration -Dconfig=<path to XML configuration file>

Note : The above command will test your XML configuration file while pulling all other configuration information from the run project. If you would like to test also the other configuration files, you can find more information on this page.

How to generate a GUID?

Orca uses GUIDs extensively. For example, resource leases, leased resources, and physical machines have a GUID. The system generates GUIDs automatically as needed, but sometimes, you may need to create GUID manually. The run project provides a means to generate a GUID. To generate a GUID type the following in your terminal:

 cd $ORCA_HOME/run
 ant guid

The above command will generate a GUID. The output will look something like this:

aydan@java:/shirako/code/trunk/run$ ant guid
Buildfile: build.xml

guid:
     [java] 583c10bfdbd326ba:-65280cc7:115b5baf15c:-8000

BUILD SUCCESSFUL
Total time: 3 seconds

You can then copy the GUID (583c10bfdbd326ba:-65280cc7:115b5baf15c:-8000 ) and use it as needed.