...
ID | IEP-17 | ||||||||
Author | Denis Mekhanikov | ||||||||
Sponsor | Anton Vinogradov | ||||||||
Created | |||||||||
Status |
|
Table of Contents |
---|
...
Currently when service implementation or configuration changes, you can't make existing instances be redeployed without manual undeployment. GridServiceProcessor
has access to the serialized representation of services only, so it can't tell, if anything have changed since previous deployment.
This section contains a description of the proposed service deployment protocol.
...
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.
...
There are three possible outcomes of IgniteServices#deploy* method execution:
It should be possible to update service implementation or configuration without downtime. Introduction of a service version should solve this problem.
ServiceConfiguration
class should contain integer version
parameter, that will increase monotonically between deployments.
When a node is processing a service deployment request, it performs deployment only if it doesn't have a deployed service of the same or a newer version.
Service version update implies classes redeployment. So, user is responsible for configuring a proper DeploymentSpi to be able to replace service classes at runtime. Service processor should unregister and re-register a service class, when version update happens.
...
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 such possibility currently exists.
There are still some flaws in the current service grid design, that are not covered in this IEP.
Suppose, we have one server node, and we deploy several cluster-singleton services on it.
If you add more nodes to it, then service instances won't be moved to them, so the only node will be serving all the requests. This situation should be solved by proper service rebalancing.
Changes, described in current IEP don't interfere with service rebalancing in any way, so we can do it as a separate task after the proposed changes are implemented.
In previous design services could be persisted to disk along with other data in system caches.
Since the utility cache will become abandoned after the proposed changes, there will be no way to preserve deployed services between cluster restarts.
If we deside to keep this feature, then we should implement storing the service configurations. Also a way to configure this behaviour should be developed.
Service grid redesign: http://apache-ignite-developers.2346864.n4.nabble.com/Service-grid-redesign-td28521.html
...
Jira | ||||||
---|---|---|---|---|---|---|
|
Jira | ||||||
---|---|---|---|---|---|---|
|
Jira | ||||||
---|---|---|---|---|---|---|
|
| ||||||
Jira | ||||||
---|---|---|---|---|---|---|
|