[Gluster-devel] RFC - "Connection Groups" concept

Joe Julian joe at julianfamily.org
Thu Jun 27 15:50:33 UTC 2013


On 06/27/2013 08:10 AM, Stephan von Krawczynski wrote:
> On Thu, 27 Jun 2013 07:47:18 -0700
> Joe Julian <joe at julianfamily.org> wrote:
>
>> I hear what you're saying, but I can't see that as a valid design to
>> provide future growth and to regain the flexibility that I believe you
>> enjoyed when we used to write vol files. The server needs to be
>> identified in an abstract way so the network and anything else can be
>> managed around its existence. A brick should belong to that server, not
>> to an ip address.
>>
>> Network re-configurations happen. Servers get renumbered.
>> [...]
> Now we do have a general disagreement on how a network topology should look
> like nowadays.
> You renumber server nodes? Why this? Wrong design?
> Servers provide services on virtual IPs nowadays, not on hardcoded true
> network layout driven ones.
> So there is no need to renumber anything anywhen. You may need to add/remove
> one/some virtual IPs every now and then, but for sure there should be no need
> to renumber backends to a big extent.
> Your clients may have varying IP ranges at the same or different times, but at
> the backend you do not want this, for plain security reasons to name one point.
> And if you design your network on clear view of what is internal (backend) and
> external (user/client) you give a damn on UUIDs, instead you want clear
> network barriers based on IP ranges and probably some transparent boxes in
> between them.
>
Regardless of what I do with my network, I hang out on IRC all day, 
every day, and see what real use is from multitudes of other users. 
There's often new engineers coming in to fix bad designs, there's 
unexpected growth that requires re-allocation of the limited ipv4 
resources a company has. There's inexperienced folks that, and you hit 
the nail on the head on that one, have built a system that they later 
realize was, indeed, a bad design.

All this is really rather an aside, though, to the design concepts that 
we're discussing and how best to build a structure that has the ability 
to be managed and grow features. Having a network interface be the 
parent object to a server is illogical.




More information about the Gluster-devel mailing list