Database Reference
In-Depth Information
The reservation of computational resources can be achieved on many su-
percomputers using advance reservation, now available in most commercial
and research schedulers. However, distributed applications often require guar-
anteed levels of bandwidth between compute resources. At the network level
there are switches and routers that support the bandwidth allocation over net-
work links, and/or the configuration of dedicated end-to-end lightpaths. These
low-level capabilities are su
cient to support the development of prototype
middleware solutions that satisfy the requirements of these applications.
However, the development of a booking system for network resources is not
a complete solution, as the user is still dealing with the complexity of coor-
dinating separate booking requests for multiple computational resources with
their network booking(s). Even if there is a single system available that can
reserve all the required compute resources, such as Moab, or GUR (which can
reserve heterogeneous compute resources), this does not address the need to
coordinate the scheduling of compute and network resources. A co-allocation
system that can deal with multiple types of resources is required.
4.6.1 HARC: The Highly Available Resource Co-Allocator
HARC, the Highly Available Resource Co-allocator,
38
,
60
is an open-source
software infrastructure for reserving resources for use by distributed applica-
tions. From the client's perspective, the multiple resources are reserved in a
single atomic step, so that all of the resources are obtained if possible; if not,
no resources are reserved. We call this all-or-nothing reservation of multiple
resources
co-allocation
or
co-scheduling
. Our definition is slightly more general
than that commonly found in the literature, in that we do not mandate that
all the reservations have the same start and end times. Rather, HARC allows
a different time window to be specified for each resource being reserved; the
case where all of these windows are the same is just a special case.
Here, we will briefly sketch the architecture of HARC, showing how the
co-allocation process works, and explaining how the system achieves its high
availability. We will then show how HARC can be used to co-schedule Com-
pute and Network resources, and also show how HARC can be extended to
cover more types of resources. Finally, some results of our experiences using
HARC to reserve network resources, as part of both special demonstrations
and on a more production-like basis, are presented.
4.6.2 Architecture
To provide the required atomic behavior, HARC treats the co-allocation
process as a
transaction
, and a
transaction commit
protocol is used to re-
serve the multiple resources. When designing HARC, we wanted to provide
a co-allocation
service
, but without introducing a single point-of-failure into
the architecture. For these reasons, HARC was designed around the
Paxos
Commit
protocol
34
by Gray and Lamport. Paxos Commit replaces the single
