Legion: A Worldwide Virtual Computer
Home General Documentation Software Testbeds Et Cetera Map/Search
  Legion Objectives and Constraints

There are ten design objectives listed here, and three constraints. They were laid out before any Legion code was written and have been carefully considered at each stage.

Objectives

  • Site autonomy
    Legion is not a monolithic system, but is composed of resources owned and controlled by a variety of organizations. Since these organizations require control over their own resources, Legion can not dictate how much of a particular resource can be used, when it can be used, or who can use it.

  • Extensible core
    We cannot predict all of the needs of current and future users. We must build Legion with extensible and replaceable components that permit Legion to evolve over time and allow users to construct their own mechanisms and policies.

  • Scalable architecture
    Legion cannot rely on a centralized structure. If the system is to eventually encompass millions of hosts, it must use a scalable architecture.

  • Easy-to-use, seamless, computational environment
    We must mask the complexity of the hardware environment and the communications synchronization of parallel processing. Users should not be aware of machine boundaries. Compilers, in cooperation with run-time facilities, should manage the environment.

  • High-performance via parallelism
    We must support easy-to-use parallel processing by means of large degrees of parallelism (this includes task and data parallelism and their arbitrary combinations).

  • Single, persistent, name space
    One of the most significant obstacles to wide-area parallel processing is the lack of a single name space for file and data access. Existing multiple disjoint name spaces makes writing applications for multiple sites very difficult. Legion therefore uses a single, persistent, name space.

  • Security for users and resource owners
    We cannot replace existing host operating systems (see below), but we can ensure that existing mechanisms are not weakened by Legion. Legion does not define a security policy or requires a "trusted" Legion, but offers mechanisms for users to manage their own security needs.

  • Management and exploitation of resource heterogeneity
    Legion must support interoperability between heterogeneous hardware and software components, as well as exploit architectural strengths as possible when making scheduling decisions and policy.

  • Multiple language support and interoperability
    Legion applications will be written in a variety of languages, and heterogeneous source language application components must be integrated. We must also support legacy codes.

  • Fault tolerance
    At any given moment in a large system, several hosts, communication links, and disks will fail. Legion must be able to handle their failures and dynamic reconfiguration.

Constraints

  • We cannot replace host operating systems
    Organizations cannot allow their operating systems to be replaced. That would require rewriting applications and retraining users, as well as raising compatibility problems with other machines in the organization.

  • We cannot legislate changes to the interconnection network
    We must assume that network resources and protocols currently in use will not change. While this means accommodating operating system heterogeneity, we must accept the available resources.

  • We cannot require the Legion run as "root"
    To protect their resources, most users will want to run Legion with the fewest possible privileges.

Link Description
Overview A general look at Legion
Objectives and constraints Legion's design objectives and restrictions
Applications Adapting and running Legion applications
Architecture Legion system architecture
High-performance computing Using Legion to get high-performance computing
Scheduling Scheduling and resource management
Security Legion's security philosophy and model


 

[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

This work partially supported by DOE grant DE-FG02-96ER25290, Logicon (for the DoD HPCMOD/PET program) DAHC 94-96-C-0008, DOE D459000-16-3C, DARPA (GA) SC H607305A, NSF-NGS EIA-9974968, NSF-NPACI ASC-96-10920, and a grant from NASA-IPG.

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