Node and cluster life-cycle in ignite-3

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Node and cluster life-cycle in ignite-3

Sergey Chugunov
 Hello Igniters,

I would like to start a discussion on evolving IEP-73 [1]. Now it covers a
narrow topic about components dependencies but it makes sense to cover in
the IEP a broader question: how different components should be initialized
to support different modes of an individual node or a whole cluster.

There is an idea to borrow the notion of run-levels from Unix-like systems,
and I suggest the following design to implement it.

   1. To start and function at a specific run-level node needs to start and
   initialize components in a proper order. During initialization components
   may need to notify each other about reaching a particular run-level so
   other components are able to execute their actions. Orchestrating of this
   process should be a responsibility of a new component.

   2. Orchestration component doesn't manage the initialization process
   directly but uses another abstraction called scenario. Examples of
   run-levels in the context of Ignite 2.x may be Maintenance Mode,
   INACTIVE-READONLY-ACTIVE states of a cluster, and each level is reached
   when a corresponding scenario has executed.

   So the responsibility of the orchestrator will be managing scenarios and
   providing them with infrastructure of spreading notification events between
   components. All low-level details and knowledge of existing components and
   their dependencies are encapsulated inside scenarios.

   3. Scenarios allow nesting, e.g. a scenario for INACTIVE cluster state
   can be "upgraded" to READONLY state by executing diff between INACTIVE and
   READONLY scenarios.


I see several advantages of this design compared to existing model in
Ignite 2.x (mostly implemented in IgniteKernal and based on two main
methods: start and onKernalStart):

   1. More flexible model allows implementing more diverse run-levels for
   different needs (already mentioned Maintenance Mode, cluster state modes
   like ACTIVE-INACTIVE and smart strategies for cache warmup on node start).

   2. Knowledge of components and their dependencies is encapsulated inside
   scenarios which makes it easier to create new scenarios.


Open questions:

   1. As I see right now it is hard to standardize initialization events
   components notify each other with.

   2. It is not clear if run-levels should be organized into one rigid
   hierarchy (when the first run-level should always precede the second and so
   on) or they should be more independent.


What do you think?

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-73%3A+Node+startup
Reply | Threaded
Open this post in threaded view
|

Re: Node and cluster life-cycle in ignite-3

Valentin Kulichenko
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Node and cluster life-cycle in ignite-3

Alexei Scherbakov
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Node and cluster life-cycle in ignite-3

Alexei Scherbakov
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Node and cluster life-cycle in ignite-3

Alexander Lapin
In reply to this post by Alexei Scherbakov
CONTENTS DELETED
The author has deleted this message.