commit e611959f3c1ae72ec4ca696d6f6959a31de90d12
parent 6e522e32694d4ce0aa05df8df269f504480d0f71
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Fri, 17 Feb 2017 12:57:44 +0300
Reorder the sections.
Diffstat:
| phd-diss-ru.org | | | 72 | ++++++++++++++++++++++++++++++++++++------------------------------------ |
| phd-diss.org | | | 62 | +++++++++++++++++++++++++++++++------------------------------- |
2 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2659,42 +2659,6 @@ digraph {
[[file:build/tree-hierarchy-11-ru.pdf]]
*** Алгоритм восстановления после сбоев
-**** Динамическое распределение ролей.
-Отказоуйстовчисть параллельной программы\nbsp{}--- это одна из проблем, которая
-должна решаться планировщиком задач обработки больших данных или
-высокопроизводительных вычислений, однако, большинство планировщиков
-обеспечивают только отказоустойчивость подчиненных узлов. Такого рода сбои
-обычно обрабатываются путем перезапуска затронутой задачи (из контрольной точки
-восстановления) или ее части на оставшихся узлах, а выход из строя руководящего
-узла считается либо маловероятным, либо слишком сложным для обработки и
-настройки на целевой платформе. Системные администраторы обычно находят
-альтернативы отказоустойчивости на уровне приложения: они изолируют руководящий
-процесс планировщика от остальных узлов кластера, размещая его на специально
-выделенной машине, или, вместо этого, используют технологии виртуализации. Все
-эти альтернативы усложняют конфигурацию и обслуживание, и, уменьшая вероятность
-выхода из строя машины, приводящей к выходу из строя всей системы, увеличивают
-вероятность ошибки оператора.
-
-С этой точки зрения более практичным реализовать отказойстойчивость руководящего
-узла на уровне приложения, но не существует общего зарекомендовавшего себя
-решения. Большинство реализаций слишком привязаны к конкретному приложению,
-чтобы стать повсеместно применяемыми. Автор считает, что это происходит из-за
-привычки людей думать о кластере, как о совокупности отдельных машин, каждая из
-которых может быть руководителем или подчиненным, вместо того чтобы думать о
-кластере, как о едином целом, в котором роли руководителя и подчиненного
-динамически распределяются между запущенными на разных узлах процессами.
-
-Понимание того, что кластер тоже является вычислительной машиной, позволяет
-реализовать промежуточное программное обеспечение, которое автоматически
-распределяет роли руководителя и подчиненного и общим спопобом обрабатывает сбои
-узлов. Это программное обеспечение предоставляет программный интерфейс и
-распределяет управляющие объекты между доступными на данный момент узлами.
-Используя этот интерфейс, можно написать программу, которая запускается на
-кластерe, не зная точного количества работающих узлов. Это промежуточное
-программное обеспечение работает как кластерная операционная система в
-пользовательском пространстве, позволяющая писать и запускать распределенные
-приложения прозрачно.
-
**** Контрольные точки восстановления.
Сбои узлов распределенной системы можно разделить на два типа: сбой подчиненного
узла и сбой руководящего узла. Для того чтобы запущенная на кластере задача
@@ -2735,6 +2699,42 @@ digraph {
иерархию узлов для динамического распределения нагрузки и свою собственную
иерархию для перезапуска управляющих объектов в случае сбоя узла.
+**** Динамическое распределение ролей.
+Отказоуйстовчисть параллельной программы\nbsp{}--- это одна из проблем, которая
+должна решаться планировщиком задач обработки больших данных или
+высокопроизводительных вычислений, однако, большинство планировщиков
+обеспечивают только отказоустойчивость подчиненных узлов. Такого рода сбои
+обычно обрабатываются путем перезапуска затронутой задачи (из контрольной точки
+восстановления) или ее части на оставшихся узлах, а выход из строя руководящего
+узла считается либо маловероятным, либо слишком сложным для обработки и
+настройки на целевой платформе. Системные администраторы обычно находят
+альтернативы отказоустойчивости на уровне приложения: они изолируют руководящий
+процесс планировщика от остальных узлов кластера, размещая его на специально
+выделенной машине, или, вместо этого, используют технологии виртуализации. Все
+эти альтернативы усложняют конфигурацию и обслуживание, и, уменьшая вероятность
+выхода из строя машины, приводящей к выходу из строя всей системы, увеличивают
+вероятность ошибки оператора.
+
+С этой точки зрения более практичным реализовать отказойстойчивость руководящего
+узла на уровне приложения, но не существует общего зарекомендовавшего себя
+решения. Большинство реализаций слишком привязаны к конкретному приложению,
+чтобы стать повсеместно применяемыми. Автор считает, что это происходит из-за
+привычки людей думать о кластере, как о совокупности отдельных машин, каждая из
+которых может быть руководителем или подчиненным, вместо того чтобы думать о
+кластере, как о едином целом, в котором роли руководителя и подчиненного
+динамически распределяются между запущенными на разных узлах процессами.
+
+Понимание того, что кластер тоже является вычислительной машиной, позволяет
+реализовать промежуточное программное обеспечение, которое автоматически
+распределяет роли руководителя и подчиненного и общим спопобом обрабатывает сбои
+узлов. Это программное обеспечение предоставляет программный интерфейс и
+распределяет управляющие объекты между доступными на данный момент узлами.
+Используя этот интерфейс, можно написать программу, которая запускается на
+кластерe, не зная точного количества работающих узлов. Это промежуточное
+программное обеспечение работает как кластерная операционная система в
+пользовательском пространстве, позволяющая писать и запускать распределенные
+приложения прозрачно.
+
**** Иерархия управляющих объектов.
Для распределения нагрузки узлы кластера объединяются в древовидную иерархию
(см.\nbsp{}раздел [[#sec:node-discovery]]), и нагрузка распределяется между
diff --git a/phd-diss.org b/phd-diss.org
@@ -2493,37 +2493,6 @@ digraph {
[[file:build/tree-hierarchy-11.pdf]]
*** Fail over algorithm
-**** 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 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, 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 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.
-
**** Checkpoints.
Node failures in a distributed system are divided into two types: failure of a
subordinate node and failure of a principal node. In order for a job running on
@@ -2561,6 +2530,37 @@ a tree hierarchy of cluster nodes, and parallel programme consists of kernels
which use node hierarchy to dynamically distribute the load and use their own
hierarchy to restart kernels upon node failure.
+**** 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 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, 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 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,
however, it is still not used in big data and HPC job schedulers. For example,
