U.S. patent application number 14/053745 was filed with the patent office on 2015-04-16 for method and apparatus for providing allocating resources.
This patent application is currently assigned to Alcatel-Lucent USA-Inc.. The applicant listed for this patent is Alcatel-Lucent USA-Inc.. Invention is credited to Fang Hao, Muralidharan Kodialam, Tirunell V. Lakshman, Sarit Mukherjee.
Application Number | 20150106820 14/053745 |
Document ID | / |
Family ID | 51866318 |
Filed Date | 2015-04-16 |
United States Patent
Application |
20150106820 |
Kind Code |
A1 |
Lakshman; Tirunell V. ; et
al. |
April 16, 2015 |
METHOD AND APPARATUS FOR PROVIDING ALLOCATING RESOURCES
Abstract
Various embodiments provide a method and apparatus for
allocating resources to processes by using statistical allocation
based on the determined maximum average resource demand at any time
across all applications (" .mu."), and the determined maximum
resource demand at any time by any application ("C"). In
particular, resource allocation includes an auto-scaling scheme
based on .mu. and C.
Inventors: |
Lakshman; Tirunell V.;
(Morganville, NJ) ; Hao; Fang; (Morganville,
NJ) ; Kodialam; Muralidharan; (Marlboro, NJ) ;
Mukherjee; Sarit; (Morganville, NJ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Alcatel-Lucent USA-Inc. |
Murray Hill |
NJ |
US |
|
|
Assignee: |
Alcatel-Lucent USA-Inc.
Murray Hill
NJ
|
Family ID: |
51866318 |
Appl. No.: |
14/053745 |
Filed: |
October 15, 2013 |
Current U.S.
Class: |
718/104 |
Current CPC
Class: |
G06F 9/5083 20130101;
G06F 9/5011 20130101; G06F 9/5077 20130101; G06F 11/3433 20130101;
G06F 2201/81 20130101; G06F 9/505 20130101; G06F 9/5072
20130101 |
Class at
Publication: |
718/104 |
International
Class: |
G06F 9/50 20060101
G06F009/50 |
Claims
1. An apparatus for providing resource allocation, the apparatus
comprising: a data storage; and a processor communicatively
connected to the data storage, the processor being configured to:
determine a worst case average requirement; determine a maximum
resource requirement; and determine a resource allocation scheme
for a set of allocation steps based on the worst case average
requirement and the maximum resource requirement.
2. The apparatus of claim 1, wherein the processor is further
configured to: determine a number of allocation steps; wherein the
set of allocation steps includes the determined number of
allocation steps.
3. The apparatus of claim 1, wherein the processor is further
configured to: collect a set of historical data; wherein the worst
case average requirement and the maximum resource requirement are
based on at least a portion of the set of historical data.
4. The apparatus of claim 3, wherein the processor is further
configured to: trigger determination of the resource allocation
scheme based on a trigger event.
5. The apparatus of claim 4, wherein the trigger event is based on
resource utilization.
6. The apparatus of claim 1, wherein the worst case average
requirement=max.sub.t.mu.(t); where .mu.(t) is the average amount
of resources requested by an application at time t.
7. The apparatus of claim 6, wherein the maximum resource
requirement=max.sub.i,th.sub.i(t); where h.sub.i(t) is the
historical resource requirement for each application I at time
t.
8. The apparatus of claim 1, wherein the resource allocation scheme
is based on a Markov inequality.
9. The apparatus of claim 8, wherein the Markov inequality includes
an objective to minimize an expected amount of resource
allocation.
10. The apparatus of claim 1, wherein the resource allocation
scheme is based on an adversarial approach.
11. The apparatus of claim 10, wherein the adversarial approach
includes an adversary's objective to pick a density distribution
that maximizes the expected amount of resources allocated to an
application.
12. A method for providing resource allocation, the method
comprising: at a processor communicatively connected to a data
storage, determining a worst case average requirement; determining,
by the processor in cooperation with the data storage, a maximum
resource requirement; and determining, by the processor in
cooperation with the data storage, a resource allocation scheme for
a set of allocation steps based on the worst case average
requirement and the maximum resource requirement.
13. The method of claim 12, wherein the method further comprises:
determining, by the processor in cooperation with the data storage,
a number of allocation steps; wherein the set of allocation steps
includes the determined number of allocation steps.
14. The method of claim 12, wherein the method further comprises:
collecting, by the processor in cooperation with the data storage,
a set of historical data; wherein the worst case average
requirement and the maximum resource requirement are based on at
least a portion of the set of historical data.
15. The method of claim 14, wherein the method further comprises:
triggering, by the processor in cooperation with the data storage,
determination of the resource allocation scheme based on a trigger
event.
16. The method of claim 15, wherein the trigger event is based on
resource utilization.
17. The method of claim 12, wherein the worst case average
requirement=max.sub.t.mu.(t); where .mu.(t) is the average amount
of resources requested by an application at time t.
18. The method of claim 12, wherein the maximum resource
requirement=max.sub.i,th.sub.i(t); where h.sub.i(t) is the
historical resource requirement for each application i at time
t.
19. The method of claim 12, wherein the resource allocation scheme
is based on a Markov inequality.
20. The method of claim 12, wherein the resource allocation scheme
is based on an adversarial approach.
21. A non-transitory computer-readable storage medium storing
instructions which, when executed by a computer, cause the computer
to perform a method, the method comprising: determining a worst
case average requirement; determining a maximum resource
requirement; and determining a resource allocation scheme for a set
of allocation steps based on the worst case average requirement and
the maximum resource requirement.
Description
TECHNICAL FIELD
[0001] The invention relates generally to methods and apparatus for
allocating resources.
BACKGROUND
[0002] This section introduces aspects that may be helpful in
facilitating a better understanding of the inventions. Accordingly,
the statements of this section are to be read in this light and are
not to be understood as admissions about what is in the prior art
or what is not in the prior art.
[0003] In some known resource allocation schemes, resource
allocation is done at predefined points. For example, resource
allocation may be done per-application or globally for all
applications running on a provider's cloud by stating the scaling
points in advance in a configuration file.
SUMMARY OF ILLUSTRATIVE EMBODIMENTS
[0004] Some simplifications may be made in the following summary,
which is intended to highlight and introduce some aspects of the
various exemplary embodiments, but such simplifications are not
intended to limit the scope of the inventions. Detailed
descriptions of a preferred exemplary embodiment adequate to allow
those of ordinary skill in the art to make and use the inventive
concepts will follow in later sections
[0005] Various embodiments provide a method and apparatus for
allocating resources to applications (e.g., application processes)
by using statistical allocation based on the determined maximum
average resource demand at any time across all applications ("
.mu.") and the determined maximum resource demand at any time by
any application ("C"). In particular, resource allocation includes
an auto-scaling scheme based on .mu. and C.
[0006] In a first embodiment, an apparatus is provided for
providing resource allocation. The apparatus includes a data
storage and a processor communicatively connected to the data
storage. The processor is programmed to: determine a worst case
average requirement; determine a maximum resource requirement; and
determine a resource allocation scheme for a set of allocation
steps based on the worst case average requirement and the maximum
resource requirement.
[0007] In a second embodiment, a method is provided for providing
resource allocation. The method includes: determining a worst case
average requirement; determining, by the processor in cooperation
with the data storage, a maximum resource requirement; and
determining, by the processor in cooperation with the data storage,
a resource allocation scheme for a set of allocation steps based on
the worst case average requirement and the maximum resource
requirement.
[0008] In a third embodiment, a non-transitory computer-readable
storage medium is provided for storing instructions which, when
executed by a computer, cause the computer to perform a method. The
method includes: determining a worst case average requirement;
determining a maximum resource requirement; and determining a
resource allocation scheme for a set of allocation steps based on
the worst case average requirement and the maximum resource
requirement.
[0009] In some of the above embodiments, the processor is further
programmed to determine a number of allocation steps. Where the set
of allocation steps includes the determined number of allocation
steps.
[0010] In some of the above embodiments, the processor is further
programmed to collect a set of historical data. Where the worst
case average requirement and the maximum resource requirement are
based on at least a portion of the set of historical data.
[0011] In some of the above embodiments, the processor is further
programmed to trigger determination of the resource allocation
scheme based on a trigger event.
[0012] In some of the above embodiments, the method further
includes determining a number of allocation steps. Where the set of
allocation steps includes the determined number of allocation
steps.
[0013] In some of the above embodiments, the method further
includes collecting a set of historical data. Where the worst case
average requirement and the maximum resource requirement are based
on at least a portion of the set of historical data.
[0014] In some of the above embodiments, the method further
includes triggering determination of the resource allocation scheme
based on a trigger event.
[0015] In some of the above embodiments, the trigger event is based
on resource utilization.
[0016] In some of the above embodiments, the worst case average
requirement=max.sub.t.mu.(t); where .mu.(t) is the average amount
of resources requested by an application at time t.
[0017] In some of the above embodiments, the maximum resource
requirement=max.sub.i,th.sub.i(t); where h.sub.i(t) is the
historical resource requirement for each application I at time
t.
[0018] In some of the above embodiments, the resource allocation
scheme is based on a Markov inequality.
[0019] In some of the above embodiments, the Markov inequality
includes an objective to minimize an expected amount of resource
allocation.
[0020] In some of the above embodiments, the resource allocation
scheme is based on an adversarial approach.
[0021] In some of the above embodiments, the adversarial approach
includes an adversary's objective to pick a density distribution
that maximizes the expected amount of resources allocated to an
application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Various embodiments are illustrated in the accompanying
drawings, in which:
[0023] FIG. 1 illustrates a network that includes an embodiment of
a system 100 for providing resource allocation;
[0024] FIG. 2 depicts a flow chart illustrating an embodiment of a
method 200 for a controller (e.g., controller 130 of FIG. 1) to
allocate resources from multiple virtual machines (e.g., virtual
machines 160 of FIG. 1);
[0025] FIG. 3 depicts a flow chart illustrating an embodiment of a
method 300 for a controller (e.g., controller 130 of FIG. 1) to
perform a k-step allocation scheme that allocates resources from
multiple virtual machines (e.g., virtual machines 160 of FIG. 1) as
illustrated in step 260 of FIG. 2; and
[0026] FIG. 4 schematically illustrates an embodiment of various
apparatus 400 such as controller 130 of FIG. 1.
[0027] To facilitate understanding, identical reference numerals
have been used to designate elements having substantially the same
or similar structure or substantially the same or similar
function.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0028] The description and drawings merely illustrate the
principles of the invention. It will thus be appreciated that those
skilled in the art will be able to devise various arrangements
that, although not explicitly described or shown herein, embody the
principles of the invention and are included within its scope.
Furthermore, all examples recited herein are principally intended
expressly to be only for pedagogical purposes to aid the reader in
understanding the principles of the invention and the concepts
contributed by the inventor(s) to furthering the art, and are to be
construed as being without limitation to such specifically recited
examples and conditions. Additionally, the term, "or," as used
herein, refers to a non-exclusive or, unless otherwise indicated
(e.g., "or else" or "or in the alternative"). Also, the various
embodiments described herein are not necessarily mutually
exclusive, as some embodiments can be combined with one or more
other embodiments to form new embodiments.
[0029] Various embodiments provide a method and apparatus for
allocating resources to applications (e.g., application processes)
by using statistical allocation based on the determined maximum
average resource demand at any time across all applications ("
.mu.") and the determined maximum resource demand at any time by
any application ("C"). In particular, resource allocation includes
an auto-scaling scheme based on .mu. and C.
[0030] Advantageously, statistical allocation may be more robust to
changes in user behavior and may provide resource auto-scaling that
balances the number of resource allocations with application
resource consumption.
[0031] FIG. 1 illustrates a cloud network that includes an
embodiment of a system 100 for providing resource allocation. The
system 100 includes one or more clients 120-1-120-n (collectively,
clients 120) accessing one or more application instances (not shown
for clarity) residing in one or more virtual machines VM 160-1-1-VM
160-N-Y (virtual machines 160) in one or more data centers
150-1-150-n (collectively, data centers 150) over a communication
path. The communication path includes an appropriate one of client
communication channels 125-1-125-n (collectively, client
communication channels 125), network 140, and one of data center
communication channels 155-1-155-n (collectively, data center
communication channels 155). Virtual machines providing resources
to the application instances are allocated in one or more of data
centers 150 by a controller 130 communicating with the data centers
150 via a controller communication channel 135, the network 140 and
an appropriate one of data center communication channels 155.
[0032] Clients 120 may include any type of communication device(s)
capable of sending or receiving information over network 140 via
one or more of client communication channels 125. For example, a
communication device may be a thin client, a smart phone (e.g.,
client 120-n), a personal or laptop computer (e.g., client 120-1),
server, network device, tablet, television set-top box, media
player or the like. Communication devices may rely on other
resources within exemplary system to perform a portion of tasks,
such as processing or storage, or may be capable of independently
performing tasks. It should be appreciated that while two clients
are illustrated here, system 100 may include fewer or more clients.
Moreover, the number of clients at any one time may be dynamic as
clients may be added or subtracted from the system at various times
during operation.
[0033] The communication channels 125, 135 and 155 support
communicating over one or more communication channels such as:
wireless communications (e.g., LTE, GSM, CDMA, Bluetooth); WLAN
communications (e.g., WiFi); packet network communications (e.g.,
IP); broadband communications (e.g., DOCSIS and DSL); storage
communications (e.g., Fibre Channel, iSCSI) and the like. It should
be appreciated that though depicted as a single connection,
communication channels 125, 135 and 155 may be any number or
combinations of communication channels.
[0034] Controller 130 may be any apparatus capable of allocating
resources by using statistical allocation based on the determined
maximum average resource demand at any time across all applications
(" .mu."), and the determined maximum resource demand at any time
by any application ("C"). For example, by allocating new
application instances on virtual machines 160 in data centers 150
or re-assigning application instances to virtual machines 160. In
particular, controller 130 includes an auto-scaling scheme that
allocates application instances based on .mu. and C. It should be
appreciated that while only one controller is illustrated here,
system 100 may include more controllers. It should be further
appreciated that while depicted separately, one or more of data
centers 150 may include controller 130. Furthermore, though
depicted as communicating with data centers 150 via network 140,
controller 130 may communicate with data centers 150 through any
suitable communication network or may reside in the same
communication network as one or more of data centers 150.
[0035] The network 140 includes any number of access and edge nodes
and network devices and any number and configuration of links.
Moreover, it should be appreciated that network 140 may include any
combination and any number of wireless, or wire line networks
including: LTE, GSM, CDMA, Local Area Network(s) (LAN), Wireless
Local Area Network(s) (WLAN), Wide Area Network (WAN), Metropolitan
Area Network (MAN), or the like.
[0036] The data centers 150 include one or more virtual machines
160. Each of virtual machines 160 may include any types or
configuration of resources and service any type or number or
application instances. Resources may be any suitable device
utilized by a virtual machine to process requests from clients 120.
For example, resources may be: servers, processor cores, memory
devices, storage devices, networking devices or the like. In some
embodiments, data centers 150 may be geographically distributed. It
should be appreciated that while two data centers are illustrated
here, system 100 may include fewer or more data centers.
[0037] In some embodiments, controller 130 allocates resources
based on the current resource requirement of an application.
[0038] FIG. 2 depicts a flow chart illustrating an embodiment of a
method 200 for a controller (e.g., controller 130 of FIG. 1) to
allocate resources from multiple virtual machines (e.g., virtual
machines 160 of FIG. 1). The method starts at step 205 and
includes: collecting historical data (step 220); triggering an
allocation scheme determination (step 240); determining a k-step
allocation scheme (step 260); and ending at step 295.
[0039] In the method 200, the step 220 includes collecting
historical data. In particular, historical data includes
statistical information regarding resource requirements required to
determine .mu. and C. In some embodiments, the historical
requirement curves for each application are collected.
[0040] In the method 200, the step 240 includes triggering an
allocation scheme determination. An allocation scheme determination
may be triggered by any suitable trigger event such as: 1) at
predetermined intervals; 2) based on an external trigger such as an
alarm or failure event; 3) based on resource utilization; or 4)
based on collected historical data.
[0041] In the method 200, the step 260 includes determining a
k-step allocation scheme based on .mu. and C. In particular,
applications are given resources in discrete increments or steps
characterized by two parameters k, .DELTA. and each of the k
resource step sizes .DELTA..sub.j are determined based on .mu. and
C. Where k specifies the number of steps and the vector .DELTA.
denotes the individual step sizes. The step allocation scheme may
be represented as S(k, .DELTA.); where .DELTA.=(.DELTA..sub.1,
.DELTA..sub.2, . . . , .DELTA..sub.k) are the step sizes. As an
example, an application i may be allocated
a.sub.i(t)=.SIGMA..sub.j=1.sup.w.DELTA..sub.j resources. Where
a.sub.i(t) is the amount of resources allocated to user "i" at time
t and w is the number of allocation steps. As an example of
resource allocation, if an application requests resources greater
than .DELTA..sub.1, then the user is allocated an additional
.DELTA..sub.2 amount of resources. In some embodiments, for some
i<k, when the application's resource requirements increases
above a threshold such as .SIGMA..sub.j=1.sup.i-1.DELTA..sub.j,
then the application is allocated an additional A amount of
resources. Similarly, when an application's resource requirements
falls below a threshold such as .SIGMA..sub.j=1.sup.i.DELTA..sub.j
or .SIGMA..sub.j=1.sup.i.DELTA..sub.j-Buffer.sub.Threshold,
.DELTA..sub.i amount of resources may be freed. Where
Buffer.sub.Threshold provides a buffer to attempt to minimize
fluctuation between allocation and de-allocation of resources when
the resource requirements fluctuate close to a resource requirement
border such as .DELTA..sub.i.
[0042] Advantageously, a k-step allocation scheme allows a provider
to specify the number of allocation steps in order to strike a
balance between resource wastage from over allocation and excessive
reallocation overhead resulting from excessive readjustments.
[0043] In some embodiments of the method, the average of amount of
resources requested by an application at time t is give as
p ( t ) = i h i ( t ) N ( t ) = .mu. ( t ) . ##EQU00001##
Where l is the amount of requested resources; p.sub.l(t) is the
probability that a user requests units of resources at time t; N(t)
is the number of active users at time time; h.sub.i(t) is the
historical resource requirement for each application i at time t
and .mu.(t) is the average amount of resources requested by a user
at time t. In some embodiments, .mu.=max.sub.t.mu.(t), which
denotes the worst case average requirement for any time t. In some
embodiments, C=max.sub.i,th.sub.i(t), which denotes the maximum
requirement for any application at any point in time.
[0044] In some embodiments of the step 240, the allocation scheme
trigger is based on resource utilization. In some of these
embodiments, as resource utilization or projected resource
utilization (e.g., due to projected resources to be allocated or
unavailable as a result of switchover from another failed data
center) exceeds a threshold capacity, the number of steps "k" may
be increased to improve resource utilization. In some embodiments,
the resource allocation scheme may be selected based on the current
or projected resource utilization.
[0045] In some embodiments of the step 240, the allocation scheme
trigger is based on an external event. In some of these
embodiments, the external event is a determination that a resource
failure has occurred. A resource failure may be based on any
suitable event such as: (1) failure of resources in a data center
(e.g., one or more of data centers 150); (2) failure of network
components such as network links; or (3) a failure that will
require allocation of additional resources within one of the data
centers such as a failure of one or more data centers or networks
remote to the data centers.
[0046] In some embodiments of the step 240, the allocation scheme
trigger is based on the ratio of the maximum request made by any
application to the worst case mean request (i.e., the peak to mean
ratio or ".rho."). In some embodiments,
.rho. = C .mu. _ . ##EQU00002##
[0047] In some of embodiments of the step 260, the number of steps
"k" is based on ".rho.". For example, the value of "k" may be set
to a higher value if ".rho." exceeds a threshold. Advantageously,
as ".SIGMA." increases, the efficiency of the allocation scheme
decreases, thus, by increasing the number of steps "k", efficiency
may be improved for higher peak to mean ratios ".rho.".
[0048] In some embodiments, a controller (e.g., controller 130 of
FIG. 1) performs step 220. In some of these embodiments, the
controller determines .mu. and C and performs step 260 based on
this determination.
[0049] In some embodiments, a measurement apparatus separate from
the controller (e.g., controller 130 of FIG. 1) performs step 220.
In some of these embodiments, the controller receives the collected
historical data from measurement apparatus and then determines .mu.
and C and performs step 260 based on the received historical data.
In some other embodiments, the measurement apparatus or another
apparatus determines .mu. or C and the controller receives the
determined .mu. and C and optionally the historical data from the
measurement apparatus or another intermediary apparatus and
performs step 260 based on at least a portion of the received
information.
[0050] FIG. 3 depicts a flow chart illustrating an embodiment of a
method 300 for a controller (e.g., controller 130 of FIG. 1) to
perform a k-step allocation scheme that allocates resources from
multiple virtual machines (e.g., virtual machines 160 of FIG. 1) as
illustrated in step 260 of FIG. 2. The method starts at step 305
and includes: determining a worst case average requirement " .mu.";
(step 320); determining a maximum resource requirement "C" (step
340); determining a number of allocation steps "k" (step 360);
determining resource allocation for each of a "k" number of
allocation steps based on .mu. and C (step 380); and ending at step
395.
[0051] In the method 300, the step 320 includes determining a worst
case average requirement " .mu. " as described herein.
[0052] In the method 300, the step 340 includes determining a
maximum resource requirement "C" as described herein.
[0053] It should be appreciated that the apparatus performing the
method may determine .mu. or C by deriving one or both of .mu. or C
from historical or other data or may determine .mu. or C by
receiving one or both of .mu. or C from another apparatus such as
the measurement apparatus described herein.
[0054] In the method 300, the step 360 includes determining a
number of allocation steps "k". The number of allocations steps "k"
may be determined in any suitable manner such as: (1) set by a
provider or user; (2) determined based on system status such as
resource utilization; (3) or the like.
[0055] In the method 300, the step 380 includes determining
resource allocation for each of the k allocation steps based on
.mu. and C.
[0056] In some embodiment of the step 340, the sum of all of the
resource steps is equal to C. For example,
.SIGMA..sub.j=1.sup.k.DELTA..sub.j=C. In some other embodiments, to
account for growth, the sum of all of the resource steps is equal
to C multiplied by a growth factor (e.g., 10%) or is equal to C
plus a growth threshold (e.g., a threshold value of a resource such
as 1 GB of bandwidth or disk space). For example,
.SIGMA..sub.j=1.sup.k.DELTA..sub.j=C*Growth.sub.factor.
[0057] In some embodiments of the step 360, the value of k is based
on the amount of available resources. In some of these embodiments,
the number of resource allocation steps k is increased when the
amount of available resources falls below a threshold level.
Advantageously, by increasing the number of allocation steps k,
allocation is more efficient, thereby improving resource
utilization.
[0058] In some embodiments of the step 360, the number of resource
allocation steps k is increased in response to an external event
such as a failure trigger signaling that a portion of the available
resources will be required for failure recovery.
[0059] In some embodiments of the step 380, the value of one or
more of the allocation steps are disparate.
[0060] In some embodiments of the step 380, the resource allocation
is based on first moment information. In some of these embodiments,
the first moment information is based on a Markov inequality where
the Markov inequality is used to upper bound the probability that a
particular resource allocation step is exceeded. In some of these
embodiments, the value of each of the reallocation steps is
determined based on equation [E.1].
.DELTA. j = { .mu. _ ( C .mu. _ ) 1 k _ , if j = 1 .mu. _ ( C .mu.
_ ) j k _ ( C .mu. _ - 1 ) , if j = 2 , 3 , , k [ Eq . 1 ]
##EQU00003##
[0061] In some embodiments of the step 380, the k-step allocation
scheme is based on an adversarial approach where the adversarial
approach approximates the resource increments such that the
expected amount of resource is minimized for the worst case
distribution that has mean .mu. and maximum C. In some embodiments,
the value of each of the reallocation steps is determined based on
equation [E.2].
.DELTA. j = { .mu. _ k - 1 ( ( k - 1 ) C .mu. _ ) 1 k _ , if j = 1
.mu. _ k - 1 ( ( k - 1 ) C .mu. _ ) j k _ - ( ( k - 1 ) C .mu. _ )
j - 1 k _ , if j = 2 , 3 , , k [ Eq . 2 ] ##EQU00004##
[0062] In some embodiments of the step 380, one or more of
.DELTA..sub.j are subdivided into l sub-steps. In some of these
embodiments, .DELTA..sub.1 is subdivided into l sub-steps. In some
of these embodiments, the subdivision of .DELTA..sub.1 is based on
[Eq. 1] or [Eq. 2] where k is replaced by l, C is replaced by
.DELTA..sub.1, and .mu. is replaced by .mu.(t, .DELTA..sub.1).
[0063] In some embodiments of the step 380, the resource allocation
is further based on a class of density functions represented by D(
.mu., C). Where .PHI. denotes a density function with C
probabilities, .phi..sub.1, .phi..sub.2, . . . .phi..sub.C where
.phi..sub.j represents the probability that the random variable
takes on value j and where .PHI. .di-elect cons. D( .mu., C)
if:
.SIGMA..sub.j=1.sup.Cj.phi..sub.j.ltoreq. .mu.;
.SIGMA..sub.j=1.sup.C.phi..sub.j=1; and
.phi..sub.j.gtoreq.0.A-inverted.j.
[0064] In some embodiments of the step 380, the Markov inequality
objective is to choose .DELTA..sub.j values in order to minimize
the expected amount of resource allocation (i.e., E(A)). In some of
these embodiments, E(A)=.SIGMA..sub.j=1.sup.kp.sub.jc.sub.j; where
p.sub.j=.SIGMA..sub.l=c.sub.j-1.sub.+1.sup.C.sup.j.phi..sub.l and
is defined as the probability that the jth block of resources was
allocated to the application.
[0065] In some embodiments of the step 380, the adversary's
objective is to pick a distribution .phi. .di-elect cons. D( .mu.,
C) that maximizes the expected amount of resources allocated to the
application.
[0066] Although primarily depicted and described in a particular
sequence, it should be appreciated that the steps shown in methods
200 and 300 may be performed in any suitable sequence. Moreover,
the steps identified by one step may also be performed in one or
more other steps in the sequence or common actions of more than one
step may be performed only once.
[0067] It should be appreciated that steps of various
above-described methods can be performed by programmed computers.
Herein, some embodiments are also intended to cover program storage
devices, e.g., data storage media, which are machine or computer
readable and encode machine-executable or computer-executable
programs of instructions, wherein said instructions perform some or
all of the steps of said above-described methods. The program
storage devices may be, e.g., digital memories, magnetic storage
media such as a magnetic disks and magnetic tapes, hard drives, or
optically readable data storage media. The embodiments are also
intended to cover computers programmed to perform said steps of the
above-described methods.
[0068] FIG. 4 schematically illustrates an embodiment of an
apparatus 400 such as controller 130 of FIG. 1. The apparatus 400
includes a processor 410, a data storage 411, and an I/O interface
430.
[0069] The processor 410 controls the operation of the apparatus
400. The processor 410 cooperates with the data storage 411.
[0070] The data storage 411 stores programs 420 executable by the
processor 410. Data storage 411 may also optionally store program
data such as historical data, k, .mu., C or the like as
appropriate.
[0071] The processor-executable programs 420 may include an I/O
interface program 421, a historical data collection program 423, a
trigger determination program 425 or an allocation scheme program
427. Processor 410 cooperates with processor-executable programs
420.
[0072] The I/O interface 430 cooperates with processor 410 and I/O
interface program 421 to support communications over controller
communication channel 135 of FIG. 1 as described above.
[0073] The historical data collection program 423 performs step 220
of FIG. 2 as described above.
[0074] The trigger determination program 425 performs step 240 of
FIG. 2 as described above.
[0075] The allocation scheme program 427 performs the steps of
method(s) 300 of FIG. 3 or 260 of FIG. 2 as described above.
[0076] In some embodiments, the processor 410 may include resources
such as processors/CPU cores, the I/O interface 430 may include any
suitable network interfaces, or the data storage 411 may include
memory or storage devices. Moreover the apparatus 400 may be any
suitable physical hardware configuration such as: one or more
server(s), blades consisting of components such as processor,
memory, network interfaces or storage devices. In some of these
embodiments, the apparatus 400 may include cloud network resources
that are remote from each other.
[0077] In some embodiments, the apparatus 400 may be virtual
machine. In some of these embodiments, the virtual machine may
include components from different machines or be geographically
dispersed. For example, the data storage 411 and the processor 410
may be in two different physical machines.
[0078] When processor-executable programs 420 are implemented on a
processor 410, the program code segments combine with the processor
to provide a unique device that operates analogously to specific
logic circuits.
[0079] Although depicted and described herein with respect to
embodiments in which, for example, programs and logic are stored
within the data storage and the memory is communicatively connected
to the processor, it should be appreciated that such information
may be stored in any other suitable manner (e.g., using any
suitable number of memories, storages or databases); using any
suitable arrangement of memories, storages or databases
communicatively connected to any suitable arrangement of devices;
storing information in any suitable combination of memory(s),
storage(s) or internal or external database(s); or using any
suitable number of accessible external memories, storages or
databases. As such, the term data storage referred to herein is
meant to encompass all suitable combinations of memory(s),
storage(s), and database(s).
[0080] The description and drawings merely illustrate the
principles of the invention. It will thus be appreciated that those
skilled in the art will be able to devise various arrangements
that, although not explicitly described or shown herein, embody the
principles of the invention and are included within its spirit and
scope. Furthermore, all examples recited herein are principally
intended expressly to be only for pedagogical purposes to aid the
reader in understanding the principles of the invention and the
concepts contributed by the inventor(s) to furthering the art, and
are to be construed as being without limitation to such
specifically recited examples and conditions. Moreover, all
statements herein reciting principles, aspects, and embodiments of
the invention, as well as specific examples thereof, are intended
to encompass equivalents thereof.
[0081] The functions of the various elements shown in the FIGs.,
including any functional blocks labeled as "processors", may be
provided through the use of dedicated hardware as well as hardware
capable of executing software in association with appropriate
software. When provided by a processor, the functions may be
provided by a single dedicated processor, by a single shared
processor, or by a plurality of individual processors, some of
which may be shared. Moreover, explicit use of the term "processor"
or "controller" should not be construed to refer exclusively to
hardware capable of executing software, and may implicitly include,
without limitation, digital signal processor (DSP) hardware,
network processor, application specific integrated circuit (ASIC),
field programmable gate array (FPGA), read only memory (ROM) for
storing software, random access memory (RAM), and non volatile
storage. Other hardware, conventional or custom, may also be
included. Similarly, any switches shown in the FIGS. are conceptual
only. Their function may be carried out through the operation of
program logic, through dedicated logic, through the interaction of
program control and dedicated logic, or even manually, the
particular technique being selectable by the implementer as more
specifically understood from the context.
[0082] It should be appreciated that any block diagrams herein
represent conceptual views of illustrative circuitry embodying the
principles of the invention. Similarly, it should be appreciated
that any flow charts, flow diagrams, state transition diagrams,
pseudo code, and the like represent various processes which may be
substantially represented in computer readable medium and so
executed by a computer or processor, whether or not such computer
or processor is explicitly shown.
* * * * *