Re: [Vrs-development] Scalability

[Eric Altendorf]

On Monday 22 July 2002 09:25, Chris Smith wrote:
> Okay, an example (just like the one Bill gave me... :o)  )
> All the members of this mailing list could set up a VRS, each of us
> running an LDS.  Thus we'd have a VRS consisting of (currently) 5
> or so LDS's. As new members join the list they may request
> participation in the VRS cluster.  Some admin or other would update
> the authentication tables (distributed by the RM across the VRS) to
> allow that user to join.  The user then start's up their LDS and
> subscribes to the VRS - they authenticate successfully and hookup.
> Thus the whole VRS membership is controlled and moderated.
> If one of the participants goes offline, then that doesn't matter
> because their resources are cloned and distributed across the other
> LDS's in the VRS. If someone want's to leave perminently, then
> that's fine too - the admin just removes their authentication
> details.

It's good to hear this, as it confirms my understanding of how things 
were to work.

So, returning to the scalability issue -- if the list of allowed LDS 
nodes in a VRS is generally fixed; ie, we have to update the 
authentication tables to allow a new host to join ... then why don't 
we at that time also update the number of domain "slots" GW is 
configured to use?

Maybe GW is configured for only 10 domains, but we want to add an 11th 
LDS node to the VRS.  So we add the 11th computer to the auth tables, 
and change the GW configuration use 11 slots...  This seems a lot 
easier than keeping a limited number of slots and swapping domains in 
and out using some other-host discovery mechanism.  And I honestly 
don't think it's a scalability problem to keep a complete list of all 
hosts, unless we're looking to build VRS's with tens of thousands of 
nodes and we want it to run on 386's with 16 megs of memory...

Eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi