Hi Bill,
Thank you for your response! Somehow I totally missed it until just now.
In response to your question:
I would choose unstated option "3" - In the context of AZ-E and AZ-F, is it
not possible to aim for a "least loaded" scheduling approach when
considering an affinity/requirement/preference? I currently use this
algorithm for how we automate the creation of actual EC2 instances in AWS,
to ensure that we've got a good spread of capacity, and those "creates" are
done independently of each other, re-sampling the currently layout each
time. Please forgive my ignorance if there's a nuance I've missed w/r/t
Aurora.
Assuming we had two slots left in a "least-loaded" scheduling scenario, one
in each AZ-{E,F}, I *think* I would choose "1" because I agree with the
intent around availability. However, in that world, I think these options
are reasonably similar in practice and each has its own downside. I would
also be happy with "2" if that was the easier-to-implement or support
version. It's easy to communicate about: "you said we have to have all the
instances in the same AZ, but there isn't capacity to achieve that".
Thanks again,
Brian
On Mon, Apr 4, 2016 at 1:55 PM, Bill Farner <[email protected]> wrote:
> There is no support for affinity-based scheduling today, but it has come
> up several times and i'm open to the idea.
>
> Without great care, this type of constraint could become difficult to
> reason about and implement in a way that does not suffer from pathological
> cases. Today, scheduling is entirely with hard constraints (as opposed to
> preferences), and tasks are scheduled independently**. The upside is this
> allows us to ignore the NP-hard side of scheduling and create a relatively
> deterministic system.
>
> Consider a cluster with 2 AZs, where one AZ is nearly full (AZ-F), and one
> is empty (AZ-E). You schedule a 2-instance job requiring AZ affinity. The
> scheduler may select a resource in AZ-F for the first instance, defining a
> placement requirement for the second instance. However, AZ-F is now
> completely full, and the second instance cannot be scheduled. The obvious
> improvement is to consider all instances of the job when scheduling any of
> them, but the same pathological case exists.
>
> A question for you, to explore your use case - In the above scenario,
> which is preferable:
> 1) the scheduler gives up on affinity and places the 2nd instance in
> AZ-E, or
> 2.) the second instance remains in pending indefinitely
>
> The mantra of Aurora's design so far would favor (1), as we always err on
> the side of availability. This would effectively create a scheduling
> preference (rather than requirement), however.
>
>
> *** for the sake of user fencing, this is not entirely true. but for
> scheduling decisions it is*
>
> On Sun, Apr 3, 2016 at 8:52 PM, Brian Hatfield <[email protected]>
> wrote:
>
>> Hi,
>>
>> I am aware of constraints like 'host': 'limit:2', but I was wondering if
>> there was a constraint where I could say "I want everyone to have the same
>> X".
>>
>> My use-case is AWS: I want all of a job to only be scheduled within a
>> single availability zone, but I don't care which one - wherever the job can
>> be scheduled is fine. The specific purpose is to save on cross-az network
>> data transfer costs.
>>
>> The best workaround I can think of is manually specifying which AZ to
>> schedule a job in, but that has all sorts of drawbacks, mostly that it's
>> the scheduler's job to do this :-)
>>
>> Am I missing a nuance of the constraint system that would allow for this?
>>
>> Thank you!
>> Brian
>>
>>
>>
>
