commit ea9234489a817e7a727ae0c4dd6f9ed8f298c5d9
parent 4acf802a3c5b0ecf87e2606990fc9fc82dede7f2
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Thu, 16 Feb 2017 18:26:15 +0300
Sync dynamic role distribution.
Diffstat:
2 files changed, 62 insertions(+), 26 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2659,6 +2659,42 @@ digraph {
[[file:build/tree-hierarchy-11-ru.pdf]]
*** Алгоритм восстановления после сбоев
+**** Динамическое распределение ролей.
+Отказоуйстовчисть параллельной программы\nbsp{}--- это одна из проблем, которая
+должна решаться планировщиком задач обработки больших данных или
+высокопроизводительных вычислений, однако, большинство планировщиков
+обеспечивают только отказоустойчивость подчиненных узлов. Такого рода сбои
+обычно обрабатываются путем перезапуска затронутой задачи (из контрольной точки
+восстановления) или ее части на оставшихся узлах, а выход из строя руководящего
+узла считается либо маловероятным, либо слишком сложным для обработки и
+настройки на целевой платформе. Системные администраторы обычно находят
+альтернативы отказоустойчивости на уровне приложения: они изолируют руководящий
+процесс планировщика от остальных узлов кластера, размещая его на специально
+выделенной машине, или, вместо этого, используют технологии виртуализации. Все
+эти альтернативы усложняют конфигурацию и обслуживание, и, уменьшая вероятность
+выхода из строя машины, приводящей к выходу из строя всей системы, увеличивают
+вероятность ошибки оператора.
+
+С этой точки зрения более практичным реализовать отказойстойчивость руководящего
+узла на уровне приложения, но не существует общего зарекомендовавшего себя
+решения. Большинство реализаций слишком привязаны к конкретному приложению,
+чтобы стать повсеместно применяемыми. Автор считает, что это происходит из-за
+привычки людей думать о кластере, как о совокупности отдельных машин, каждая из
+которых может быть руководителем или подчиненным, вместо того чтобы думать о
+кластере, как о едином целом, в котором роли руководителя и подчиненного
+динамически распределяются между запущенными на разных узлах процессами.
+
+Понимание того, что кластер тоже является вычислительной машиной, позволяет
+реализовать промежуточное программное обеспечение, которое автоматически
+распределяет роли руководителя и подчиненного и общим спопобом обрабатывает сбои
+узлов. Это программное обеспечение предоставляет программный интерфейс и
+распределяет управляющие объекты между доступными на данный момент узлами.
+Используя этот интерфейс, можно написать программу, которая запускается на
+кластерe, не зная точного количества работающих узлов. Это промежуточное
+программное обеспечение работает как кластерная операционная система в
+пользовательском пространстве, позволяющая писать и запускать распределенные
+приложения прозрачно.
+
**** Введение.
Отказы узлов распределенной системы можно разделить на три типа: отказ
подчиненного узла, отказ главного узла и отказ одновременно всех узлов
@@ -3073,7 +3109,7 @@ Emacs, предоставляющего вычислительное окруж
Исследования были проведены на вычислительных ресурсах ресурсного центра
"Вычислительный центр СПбГУ" (\mbox{T-EDGE96} \mbox{HPC-0011828-001}) в рамках
-грантов РФФИ (проекты \nbsp{}\mbox{16-07-01111}, \mbox{16-07-00886},
+грантов РФФИ (проекты\nbsp{}\mbox{16-07-01111}, \mbox{16-07-00886},
\mbox{16-07-01113}).
* Список сокращений и условных обозначений
diff --git a/phd-diss.org b/phd-diss.org
@@ -2493,36 +2493,36 @@ digraph {
[[file:build/tree-hierarchy-11.pdf]]
*** Fail over algorithm
-**** Introduction.
-Fault tolerance of a parallel programme is one of the top concerns in
-development of big data and HPC job schedulers, however, most schedulers provide
+**** Dynamic role distribution.
+Fault tolerance of a parallel programme is one of the problems which should by
+solved by big data and HPC job schedulers, however, most schedulers provide
fault tolerance for subordinate nodes only. These types of failures are
-routinely mitigated by restarting the failed job (from a checkpoint) or its part
-on healthy nodes, and failure of a principal node is often considered either
-improbable, or too complicated to handle and configure on the target platform.
-System administrators often find alternatives to application level fault
-tolerance: they isolate principal node from the rest of the cluster by placing
-it on a dedicated machine, or use virtualisation technologies instead. All these
-alternatives complexify configuration and maintenance, and by decreasing
-probability of a machine failure resulting in a whole system failure, they
-increase probability of a human error.
+routinely handled by restarting the affected job (from a checkpoint) or its part
+on the remaining nodes, and failure of a principal node is often considered
+either improbable, or too complicated to handle and configure on the target
+platform. System administrators often find alternatives to application level
+fault tolerance: they isolate principal process of the scheduler from the rest
+of the cluster nodes by placing it on a dedicated machine, or use virtualisation
+technologies instead. All these alternatives complexify configuration and
+maintenance, and by decreasing probability of a machine failure resulting in a
+whole system failure, they increase probability of a human error.
From such point of view it seems more practical to implement principal node
-fault tolerance at application level, however, there is no generic
-implementation. Most implementations are too tied to a particular application to
-become universally acceptable. We believe that this happens due to people's
+fault tolerance at application level, but there is no proven generic solution.
+Most implementations are too tied to a particular application to become
+universally applicable. The author believes that this happens due to people's
habit to think of a cluster as a collection of individual machines each of which
can be either principal or subordinate, rather than to think of a cluster as a
-whole with principal and subordinate roles being dynamically assigned to a
-particular physical machine.
-
-This evolution in thinking allows to implement middleware that manages principal
-and subordinate roles automatically and handles node failures in a generic way.
-This software provides an API to distribute kernels on the pool of available
-nodes and between them. Using this API one can write an application that runs on
-a cluster without knowing the exact number of online nodes. The middleware works
-as a cluster operating system overlay allowing to write distributed
-applications.
+whole with principal and subordinate roles being dynamically distributed between
+processes running on different nodes.
+
+Realisation of the fact that a cluster is also a computer allows to implement
+middleware that distributes principal and subordinate roles automatically and
+handles node failures in a generic way. This software provides an API to
+distribute kernels between currently available nodes. Using this API one can
+write a programme that runs on a cluster without knowing the exact number of
+working nodes. The middleware works as a cluster operating system in user space,
+allowing to write and execute distributed applications transparently.
**** Related work.
Dynamic role assignment is an emerging trend in design of distributed systems\nbsp{}cite:ostrovsky2015couchbase,divya2013elasticsearch,boyer2012glusterfs,anderson2010couchdb,lakshman2010cassandra,
