...
ID | IEP-17 | ||||||||
Author | Denis Mekhanikov | ||||||||
Sponsor | Anton Vinogradov | ||||||||
Created | |||||||||
Status |
|
Table of Contents |
---|
...
Deployment starts with sending of a custom discovery event, that notifies all nodes in the cluster about the ongoing deployment. This message contains serialized service instance and its configuration. It is delivered to the coordinator node first, that calculates the service deployment assignments and adds this information to the message. During the following round-trip of this message, nodes save information about service deployment assignments to some local storage, and the ones, that were chosen to deploy the services, do it perform initialisation asynchronously in a dedicated thread pool.
Once the a node finishes the deployment procedure and Service#init()
method execution, it connects to the coordinator, using the communication SPI, and sends the deployment result to it, i.e. either acknowledgement about successful deployment, or a serialized exception.
...
...
When a new node connects to the existing cluster, all needed services are deployed and initialised on it by the time it is accepted to the topology.
This is what happens, when a new node joins the cluster:
...
There are three possible outcomes of IgniteServices#deploy* method execution:
Also deployment of each service instance should trigger a system event, containing information about the service and a node, where it took place. The same should be done for deployment failures.
But these events shouldn't be triggered for services, that are not considered deployed in the cluster yet. Events about initial deployments should be triggered only after the discovery message about successful deployment is sent.
When a new node comes, it receives information about existing service assignments in the data attached to an initial discovery messages. Information about ongoing deployments should also be included into the discovery data.
If a new node is included into assignments, then it should start the deployment procedure asynchronously.
If assignment recalculation is needed, then coordinator performs it and sends a reassignment message.
If a node comes during service deployment, and it is suitable for deployment, then the new node should start it. Coordinator should detect such node and wait for the result from it as well.
Not all discovery events or deployment failures require assignment recalculation.
Services, that have configuration like (maxPerCluster = 0, maxPerNode > 0) should lead to creation of only one assignment. It should look like (eachNode=N), or in some similar way.
When a new node comes to the topology, or initialization failure happens, assignment recalculation shouldn't be triggered for such services.
TODO: How should other nodes know, which nodes succeeded in service deployment, if assignment looks like (eachNode=N)? Should they listen to system events about service deployment?
Also information about already deployed services should be included into the discovery data. Otherwise a node, that just connected to the cluster, won't be able to tell, which nodes have which services.
IgniteServices#cancel() method triggers sending of a discovery message, containing information about services, that are being cancelled.
Each node should call Service#cancel() methods on its services and undeploy them. Also all ongoing deployments should be interrupted
...
.
It should be possible to update service implementation without downtime. Employment of Deployment SPI should solve this problem.
Service processor should subscribe to class deployments and restart corresponding services, when their classes change.
The basic usage scenario involves enabling UriDeploymentSpi and updating the JAR files, containing implementation classes. It will lead to existing services cancellation and reployment. It implies, that services should be ready to sudden cancellations. Documentation should contain explanation of this fact with examples.
To make redeployment with an updated class possible, service's properties and its class should be separated. ServiceConfiguration should contain the following properties:
It will also help the service processor distinguish between different services configurations, when only properties change.
ServiceConfiguration#service property should be removed.
Service classe should have an empty constructor, that will be used by deploying nodes.
A possible point of improvement here is to start redeployment with a random delay to avoid denial of service on the whole cluster.
These changes will break compatibility with previous versions of Apache Ignite completely.
Also there will be no way to preserve services between cluster restarts. Even though there is such possibility currently exists.
There are still some flaws in the current service grid design, that are not covered in this IEP.
...
Jira | ||||||
---|---|---|---|---|---|---|
|
Jira | ||||||
---|---|---|---|---|---|---|
|
| ||||||
Jira | ||||||
---|---|---|---|---|---|---|
|