Thanks for sharing your plan, which is very similar to our plan #B
I'd like to make some discussions for more details.
> For service that are clustered in a master-slave organization,
In this case, there would be an limitation of switching the master
server when the original master is down. Is it right? or do you have
any 'recovery' mechanism to be implemented?
If master fails and it is not recovered by vcap, we should provide
notifications and recovery operation feature in vmc.
# a command like 'vmc cluster-service instance1 instance2 instance3 --
master instance0' might be required..
> But for services in which (for example) all nodes are peers, this seed/child protocol
In this case, applications should be able to receive notifications not
to use the dead nodes when some of instances are down... The current
service configuration mechanism (using env vars) would be an potential
issues for this implementation.
> After provisioning is complete, the nodes can interact with each
> other in whatever way they way.
I agree with this idea but applications would like to control when the
provisioned nodes join the cluster because there would be a
performance issue in production services.
On 6月20日, 午前3:24, Nicholas Kushmerick <
nichol...@rbcon.com> wrote:
> We are actually in the design phase of doing this as well. In the
> medium/long term we certainly don't want to duplicate effort, but in the
> short term it would be great for multiple approaches to help us reach
> consensus on the best approach. Here's an overview of our plan:
>
> - A Cloud Foundry Service Gateway would be configured to provision a
> service instance across N Service Nodes
> - N is just a parameter, as far as the gateway is concerned it can be
> any value, though only some values might make sense for specific services
> - for review, the provisioning process today (ie, N=1) works like this:
> - Gateway selects one Node using a simple load balancing algorithm
> - Gateway forwards provisioning request to the selected Node
> - Node receives the request and performs whatever operations are
> appropriate for the service (eg for a database: CREATE DATABASE
> foo; CREATE
> USER bar; etc)
> - Gateway receives back from Node the instances credentials (host,
> port, username, password, etc -- whatever makes sense for the service)
> - The proposed protocol for supporting N > 1 is as follows:
> - Gateway selects N best Nodes according to the same load-balancing
> algorithm
> - Gateway forwards provisioning request to one 'seed' Node, chosen
> arbitrarily from the selected nodes
> - 'Seed' Node receives the request and performs whatever operations
> are appropriate
> - Gateway receives back from 'seed' node the instance's credentials
> - Gateway forwards provisioning request to the other N-1 "child"
> Nodes, along with the credentials for the 'seed' node
> - Child nodes perform whatever operations are appropriate, including
> remembering/registering/etc the seed node
> - Gateway receives back from the child nodes the instance credentials.
> - Gateway bundles all N sets of credentials together to supply to the