<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 11:43 AM, Justin Clift <span dir="ltr"><<a href="mailto:jclift@redhat.com" target="_blank">jclift@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 27/06/2013, at 6:53 PM, Anand Avati wrote:<br>
> Using UUIDs as the identifier for all internal management communication is a good idea. The CLI commands could still use hosts or IPs, but that should be translated to UUIDs as an alias as superficially as possible (ideally in the CLI itself, glusterd only communicates by UUID). The translation of UUID to host IPs should really be dynamic/discovery based. Each host must present all its IPs to all its peers.<br>
<br>
</div>Seriously bad idea (after thinking about it). :)<br>
<br>
In corporate environments, the "backup network" which most places have<br>
for their servers is *only* for backup traffic. Applications on the<br>
server (such as Gluster) get their own dedicated nics and switches.</blockquote><div><br></div><div style>Backup networks can be flagged as private on a per server level (and just not get exposed) if you want the network isolation to happen at the application level (rather than at the network / routing level).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Volgen and protocol/client must be enhanced to accept multiple IPs for each brick and auto select the right/routed address at runtime (or accept a preferred interface as input).<br>
<br>
</div>Have you looked at the connection group stuff? I think that would be<br>
a more flexible approach for most corporate/enterprise level environments.<br>
<br>
That being said, an auto selection mechanism might really be the way to<br>
go for cloud scale stuff (unsure). :)</blockquote><div><br></div><div style>(replying the rest in that thread..)</div><div style><br></div><div style>Avati</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
> We should even start identifying bricks by UUID and self-discovered (independent of host and backend mount-point). This way if an EBS volume is detached and attached to a different node at a different backend mount, configuration must get auto reconfigured (either completely using udev, or with partial/limited input from admin). Converting to UUID would be partial if bricks are not pulled in to the scheme.<br>
<br>
</div>Hmmm, interesting thought. Prob want SSL certificates in use for this,<br>
but that wouldn't be a blocker.<br>
<br>
Not see-ing this approach as being easily code-able in the near future<br>
though? More a longer term thing?<br>
<div class="im HOEnZb"><br>
Regards and best wishes,<br>
<br>
Justin Clift<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Open Source and Standards @ Red Hat<br>
<br>
<a href="http://twitter.com/realjustinclift" target="_blank">twitter.com/realjustinclift</a><br>
<br>
</div></div></blockquote></div><br></div></div>