<div dir="ltr">"expected-redundancy=3" ?<div><br></div><div>I don't have amazing ideas here, mostly because we need services that are really being used with lots of units. If you only have 3 units of a service, then it really doesn't matter. I think having a decent first step of this, and then we can drive the rest from concrete use cases. (I'm trying to deploy 100 units of X, and I really want it spread over only 3 AZ's.) I personally don't know what people want, and I can only theorize from use cases that may not actually be borne out in reality.</div>
<div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 6:00 AM, Andrew Wilkins <span dir="ltr"><<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Fri, Jun 13, 2014 at 10:45 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapil.thangavelu@canonical.com" target="_blank">kapil.thangavelu@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Jun 13, 2014 at 12:23 AM, Andrew Wilkins <span dir="ltr"><<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>Explicit AZs</div><div>=========</div><div><br></div><div>When bootstrapping or adding a machine, you can specify the availability zone explicitly as a placement directive. e.g.<br></div><div><br></div><div> juju bootstrap --to zone=us-east-1b</div>
<div> juju add-machine zone=us-east-1c<br></div><div><br></div></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div><div><div>Automatic AZ spread</div><div>================</div></div><div><br></div><div>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.</div>
<div><br></div><div>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".</div>
<div><br></div><div>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.</div>
<div><br></div></div></blockquote><div><br></div></div></div><div><div><br>Awesome, that's a pretty nice and simple abstraction.</div><div><br></div><div>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.</div>
</div></div></div></div></blockquote><div><br></div></div><div>Thanks for the heads up. That sounds like we'd want a network constraint that filters the usable AZs. Shouldn't be too difficult.</div><div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>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.</div>
</div></div></div></div></blockquote><div><br></div></div><div>Fair point. We may need to add some kind of constraint to set the maximum spread. This may also be useful as a means of pinning an entire service to an AZ. Something like:</div>
<div> juju deploy myservice --to zone=us-east-1b --constraints max-spread=0</div><div>(not really sure how to model the spread; % perhaps isn't all that useful, and a number of zones doesn't make much sense for the abstraction)</div>
</div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>