What happens if the IP I get back is for a seed that happens to be down right then? And then that IP is cached locally by my resolver?
There is certainly a tempting conceptual simplicity to using DNS, I just don't think the reality is that simple nor is it for the trade in predictability, for me. IMO, this is better done either through automation to generate the configs (how I do it; I just update chef-server) or through a service like ZK (how I might do it in the future, in combination with automation). b On Sat, Apr 3, 2010 at 1:42 PM, banks <bankse...@gmail.com> wrote: > I can see the logic of having an internal DNS entry > 'seednodes.internaldomain.com', > this might only have 3 defined seed nodes out of 100, but the benefit is > single point configuration, no need to edit configs across 100 machines, > easily redefinable on the fly as needed... > > On Sat, Apr 3, 2010 at 1:13 PM, Benjamin Black <b...@b3k.us> wrote: >> >> Seems like a lot of complexity for a very small win (how often do you >> bootstrap new nodes? if you only need a handful of seeds, what's all >> that hard about listing them all on all nodes?). I prefer simple and >> predictable, and trying to do this with round robin DNS seems to be >> neither, to me. >> >> >> b >> >> On Sat, Apr 3, 2010 at 12:55 PM, gabriele renzi <rff....@gmail.com> wrote: >> > On Sat, Apr 3, 2010 at 6:40 PM, Avinash Lakshman >> > <avinash.laksh...@gmail.com> wrote: >> >> We use anywhere from 3-5 seeds for clusters that have over 150 nodes. >> >> That >> >> should suffice for larger sizes too since they are only for initial >> >> discovery. >> > >> > >> > would it make sense to just use a round robin dns on the available >> > nodes and use that as seed? >> > I do not have a clear understanding of the bootstrap mechanics but I >> > have the impression that seed nodes do not have any special role, am I >> > wrong? >> > > >
