On Sat, Jun 14, 2014 at 12:16 PM, John Meinel <j...@arbash-meinel.com> wrote:
> I think this is interesting, but there are a few bits of fallout we need > to consider. > > 1) Just today I failed to bootstrap trunk with: > 2014-06-14 04:11:47 ERROR juju.provider.common bootstrap.go:119 bootstrap > failed: cannot start bootstrap instance: cannot run instances: The > requested Availability Zone is currently constrained and we are no longer > accepting new customer requests for t1/m1/c1/m2/m3 instance types. Please > retry your request by not specifying an Availability Zone or choosing > us-east-1c, us-east-1d, us-east-1e. (Unsupported) > Ugh, thanks for letting me know. We query AWS for the state of the availability zones and only attempt to use the ones marked "available". It'd be nice if they said they were constrained. Not sure how to fix this right now, but probably will need to detect the error and fall back to another AZ. > My guess is that we used to not specify the AZ, so Amazon would just > shuffle us off to whatever AZ wasn't overloaded. Now that we are picking > one, it has a higher chance to fail. > > 2) If you have 2 services, you likely would rather them on the same AZ > rather than spread across different AZ because of the different cost of > network bandwidth. How do we manage multiple services? Do we just use a > strictly deterministic ordering? (always sort the AZ names, round robin > starting with the first one?) > It's non-deterministic. Pseudo-random choice of the least populous AZs for the distribution group. As for cost: this is why we have the placement directives. We default to spreading, but enable users to control placement if necessary. I'm a bit concerned because of (1) that we'll again "deterministically > fail". :) > > John > =:-> > > > On Fri, Jun 13, 2014 at 6:45 PM, Kapil Thangavelu < > kapil.thangav...@canonical.com> wrote: > >> >> >> >> On Fri, Jun 13, 2014 at 12:23 AM, Andrew Wilkins < >> andrew.wilk...@canonical.com> wrote: >> >>> Hi all, >>> >>> I'm pleased to say that availability zone support for AWS and OpenStack >>> has now landed on trunk, and will be available in 1.19.4. I'll write a blog >>> post and maybe even some docs about it, but for now here's a brief >>> description how you can use this feature. >>> >>> FYI: not all OpenStacks are created equal. Yours may not support >>> availability zones. HP's revamped HP Cloud offering does offer several >>> availability zones in the US West region. >>> >>> Explicit AZs >>> ========= >>> >>> When bootstrapping or adding a machine, you can specify the availability >>> zone explicitly as a placement directive. e.g. >>> >>> juju bootstrap --to zone=us-east-1b >>> juju add-machine zone=us-east-1c >>> >>> >> >>> Automatic AZ spread >>> ================ >>> >>> TL;DR: "juju deploy -n 10 <service>" will automatically and uniformly >>> distribute the units to instances spread across the AZs within the region. >>> Assuming the charm and service being charmed is well written, then you >>> should be able to rest assured that IaaS downtime will not affect your >>> application. >>> >>> When adding machines without an AZ explicitly specified, or when adding >>> units to a service, the ec2 and openstack providers will now automatically >>> spread instances across all available AZs in the region. The spread is >>> based on density of instance "distribution groups". >>> >>> State servers compose a distribution group: when doing "juju >>> ensure-availability", state servers will be spread across AZs. Each >>> deployed service (e.g. mysql, redis, whatever) composes a separate >>> distribution group; the AZ spread of one service does not affect the AZ >>> spread of another service. >>> >>> >> >> Awesome, that's a pretty nice and simple abstraction. >> >> Two caveats to be aware of, This potentially can cause an issue with our >> ongoing work for vpc support as subnets are bound to azs, but i may have >> azs without subnets in them. Also there are diminishing returns on azs, ie. >> most people don't use more than three for an app, even though they may have >> up to 5 available to them in a region. maximal az usage actually increases >> app likelihood of dealing with az outage or network partition. As noted >> privately, some services will still want explicit placement instead of >> implicit. >> >> -k >> >> >> >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
