17.0 Resource management

A primary motivation in Legion's design is flexibility and transparency: programs can be distributed and run on widely distributed resources without the user having to engage in complex, time-consuming negotiations with individual site administrators. However, in order to allow sites to protect their resources against unauthorized or malicious use, Legion provides tools to allow system administrators can maintain their local policies. Final authority over the use of a resource remains with each resource's administrators.

There are three objects for managing your Legion resources: the collection, the scheduler, and the enactor. There are a corresponding set of command-line tools to control the objects. A more detailed discussion of these objects is in section 8.0 of the Developer Manual, but in brief they carry out the following functions.

  • The collection collects and maintains information about its assigned resources. It constantly monitors its host and vault objects and knows which resources are in use and which are available for what kind of tasks.
  • The scheduler takes this information and produces lists of possible resources for specific tasks.
  • The enactor negotiates with those resources to reserve blocks of time and space.

Resource managers can use scheduling-related commands (below) to set up system, class, and instance level scheduling policies.

17.1 Scheduling-related commands

There are a several commands that can be used to set up an individual Legion's scheduling process and a class's or instance's host and vault placement policy. Please see page 45 in the Reference Manual for details of these commands' syntax and usage.

17.1.1 Configuring the scheduler

The legion_config_scheduler utility configures a basic Legion scheduler's helper objects. Use it to assign a particular collection and enactor to a basic Legion scheduler or vice versa. It can also be used to query which helper objects have been set for a basic Legion scheduler. The example below shows the LOID of the default scheduler object's enactor.

$ legion_config_scheduler /etc/DefaultScheduler
	-get_enactor 
Current enactor is: 1.36baeb09.66000000.01000000.00...
$

17.1.2 Setting a class's default scheduler

This legion_set_scheduler command sets a specific class's default scheduler. The class will then use its assigned scheduler object to determine which hosts and vaults should manage its instances (i.e., determine placements for the class's instances). The example below sets SchedulerFoo as the default scheduler object for ClassFoo.

$ legion_set_scheduler /class/ClassFoo SchedulerFoo

All of ClassFoo's instances will be placed with SchedulerFoo.

17.1.3 Setting scheduler policy

The legion_set_scheduler_policy command sets a class object's policy for using its default scheduler. There are two policy options, which determine whether or not the class uses its default scheduler if the scheduler object is not active. Depending on its type, a class may require a policy which does not use an inert scheduler. If not, classes should have a default placement available

17.1.4 Adding resources to a collection

There are three commands for controlling the collection object. Objects can be added with legion_join_collection. The example below adds HostFoo to the default collection, although any Legion object can be added to a collection.

$ legion_join_collection /etc/Collection /hosts/HostFoo

The legion_leave_collection command removes objects from the collection object.

The legion_query_collection prints a list of which objects are currently part of a given collection. The legion_query_collection command uses MESSIAHS Interface Language (MIL) query strings (see page 51 in the Reference Manual for query string examples and page 127 in the Developer Manual for relevant MIL interfaces). The example below returns the list of Linux host objects that are part of the default collection.

$ legion_query_collection /etc/Collection \
	'match(host_os_name,"Linux")'
2 hits:
1.36baeb09.07.01000000.000001fc0b54bbc102...
1.36baeb09.03.01000000.000001fc0f4b64b072...
$

17.1.5 Subcollections

A subcollection is a normal collection object that is polled by another collection object (called the parent collection). This arrangement allows for faster and more efficient resource information gathering, since you can have several subcollections monitoring small groups of resources. A parent collection can have more than one subcollection and a subcollection can have more than one parent as well as its own subcollections. A parent runs one or more MESSIAHS-type queries on a subcollection (see page 51 in the Reference Manual for query string examples).

To create a parent-subcollection arrangement, use the legion_add_sub_collection command. You must specify a parent and a subcollection (both collections must already exist). You can also specify a query to be started by the parent on the subcollection. If no query is specified, the default value of 'true' will be used. You can run this command multiple times to start multiple queries on a single subcollection.

You can use the collection_update_frequency_secs attribute to adjust how often a collection polls its resources. The default setting is 300 seconds. Use the legion_update_attributes command:

$ legion_update_attributes -c /etc/Collection \
  "collection_update_frequency_secs(600)"

This will set the default collection to update itself every 10 minutes.

There are two other subcollection commands:

  • legion_list_sub_collections, which displays your existing parent-subcollection relationships and queries
  • legion_remove_sub_collection, which can be used to stop specific queries or to end a parent-subcollection relationship.

Please see Scheduling support in the Reference Manual for more information about using these commands.

Directory of Legion 1.8 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source

legion@Virginia.edu
http://legion.virginia.edu/