hpcs-17-subord

git clone https://git.igankevich.com/hpcs-17-subord.git
Log | Files | Refs

commit c126fac8e8d4b6149eda08857f7ad509ceb4a9a3
parent 8ea6f52bfe681623f4d77e8e2d8fedbf4c42a599
Author: Ivan Gankevich <igankevich@ya.ru>
Date:   Sat, 18 Mar 2017 12:19:08 +0300

Fix minor typesetting errors.

Diffstat:
src/body.tex | 15++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/body.tex b/src/body.tex @@ -120,12 +120,13 @@ hierarchy, there are two variants of this failure: then principal is gone and then any subordinate is gone. Subordinate itself is not a valuable part of execution, it is a simple worker. Our scheduler not stored any subordinate states, but only principle state. Thus, to restore execution, scheduler finds -last valid principle state and simply recreate ~\ref{fig:sc12} failed subordinate on most -appropriate daemon. When principle is gone ~\ref{fig:sc1} we need to restore it only once and -only on one node. To archive this limitation, each subordinate will try to find -any available daemon from its addresses list in reverse order. If such daemon -exists and available, finding process will stop, as current subordinate kernel -will assume that the kernel found will take principal restoration process. +last valid principle state and simply recreate~\ref{fig:sc12} failed +subordinate on most appropriate daemon. When principle is gone~\ref{fig:sc1} we +need to restore it only once and only on one node. To archive this limitation, +each subordinate will try to find any available daemon from its addresses list +in reverse order. If such daemon exists and available, finding process will +stop, as current subordinate kernel will assume that the kernel found will take +principal restoration process. \begin{figure} \centering @@ -172,7 +173,7 @@ in memory and will not stop execution of whole task if some part of it was placed on failed node. But occasionally, all nodes of cluster may fail at same time. That case is describe in third scenario. The main difference of this case is a log usage. Log is stored on trusted storage and contains kernel states at a -beginning of execution and each <<updated>> state. By term <<updated>> state we +beginning of execution and each ``updated'' state. By term ``updated'' state we define principal state after subordinates \Method{react} calls. Files of execution log is individual for each daemon, but have replicas on selected number of nodes to provide hardware redundancy. Scheduler at startup have empty