commit 55edf2a1d24c655fd27983d0c3cf25ef1e4f46e6
parent acb2cb56dea0b04c60b011ee8faae5d4e9a1f8a3
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Wed, 8 Nov 2017 12:37:56 +0300
Edit roles.
Diffstat:
2 files changed, 56 insertions(+), 59 deletions(-)
diff --git a/arma-thesis-ru.org b/arma-thesis-ru.org
@@ -3189,13 +3189,13 @@ IP-адреса: замена отображения IP-адресов на чт
**** Контрольные точки восстановления.
Сбои узлов распределенной системы можно разделить на два типа: сбой подчиненного
-узла и сбой руководящего узла. Для того чтобы запущенная на кластере задача
-могла пережить сбой подчиненного узла, планировщик задач периодически создает
-для нее контрольные точки восстановления и записывают их в надежное хранилище.
-Для того чтобы создать контрольную точку, планировщик временно останавливает все
+узла и сбой главного узла. Для того чтобы запущенная на кластере задача могла
+пережить сбой подчиненного узла, планировщик задач периодически создает для нее
+контрольные точки восстановления и записывают их в надежное хранилище. Для того
+чтобы создать контрольную точку, планировщик временно останавливает все
параллельные процессы задачи, копирует все страницы памяти и все структуры ядра
операционной системы, выделенные для этих процессов, на диск, и продолжает
-выполнение задачи. Для того чтобы пережить сбой руководящего узла, серверный
+выполнение задачи. Для того чтобы пережить сбой главного узла, резидентный
процесс планировщика задач непрерывно копирует свое внутреннее состояние на
резервный узел, который становится руководящим после сбоя.
@@ -3218,9 +3218,9 @@ IP-адреса: замена отображения IP-адресов на чт
отказоустойчивости на уровне библиотеки передачи сообщений кроме как путем
перезапуска всех параллельных процессов из контрольной точки восстановления.
-Однако, существует возможность продолжить выполнение задачи на меньшем
+В то же время, существует возможность продолжить выполнение задачи на меньшем
количестве узлов, чем было изначально выделено изначально, реализовав
-отказоустойчивость на уровне приложения. В этом случае роли руководителя и
+отказоустойчивость на уровне приложения. В этом случае роли главного и
подчиненного динамически распределяются между резидентными процессами
планировщика задач, работающими на каждом узле кластера, образуя древовидную
иерархию узлов кластера, а параллельная программа состоит из управляющих
@@ -3234,35 +3234,34 @@ IP-адреса: замена отображения IP-адресов на чт
высокопроизводительных вычислений, однако, большинство планировщиков
обеспечивают только отказоустойчивость подчиненных узлов. Такого рода сбои
обычно обрабатываются путем перезапуска затронутой задачи (из контрольной точки
-восстановления) или ее части на оставшихся узлах, а выход из строя руководящего
+восстановления) или ее части на оставшихся узлах, а выход из строя главного
узла считается либо маловероятным, либо слишком сложным для обработки и
настройки на целевой платформе. Системные администраторы обычно находят
-альтернативы отказоустойчивости на уровне приложения: они изолируют руководящий
+альтернативы отказоустойчивости на уровне приложения: они изолируют главный
процесс планировщика от остальных узлов кластера, размещая его на специально
выделенной машине, или, вместо этого, используют технологии виртуализации. Все
эти альтернативы усложняют конфигурацию и обслуживание, и, уменьшая вероятность
выхода из строя машины, приводящей к выходу из строя всей системы, увеличивают
вероятность ошибки оператора.
-С этой точки зрения более практичным реализовать отказоустойчивость руководящего
-узла на уровне приложения, но не существует общего зарекомендовавшего себя
-решения. Большинство реализаций слишком привязаны к конкретному приложению,
-чтобы стать повсеместно применяемыми. Автор считает, что это происходит из-за
-привычки людей думать о кластере, как о совокупности отдельных машин, каждая из
-которых может быть руководителем или подчиненным, вместо того чтобы думать о
-кластере, как о едином целом, в котором роли руководителя и подчиненного
-динамически распределяются между запущенными на разных узлах процессами.
-
-Понимание того, что кластер тоже является вычислительной машиной, позволяет
-реализовать промежуточное программное обеспечение, которое автоматически
-распределяет роли руководителя и подчиненного и общим способом обрабатывает сбои
-узлов. Это программное обеспечение предоставляет программный интерфейс и
-распределяет управляющие объекты между доступными на данный момент узлами.
-Используя этот интерфейс, можно написать программу, которая запускается на
-кластере, не зная точного количества работающих узлов. Это промежуточное
-программное обеспечение работает как кластерная операционная система в
-пользовательском пространстве, позволяющая писать и запускать распределенные
-приложения прозрачно.
+С этой точки зрения более практично реализовать отказоустойчивость главного узла
+на уровне приложения, однако, не существует универсального зарекомендовавшего
+себя решения. Большинство реализаций слишком привязаны к конкретному приложению,
+чтобы стать повсеместно применяемыми. Часто кластер представляется, как машина,
+в которой есть управляющий модуль (главный узел), отличный от всех остальных, и
+несколько одинаковых вычислительных модулей (подчиненных узлов). На практике же
+оказывается, что главный и подчиненные узлы физически одинаковы, и различаются
+лишь процессами планировщика пакетных задач, запущенными на них. Понимание того,
+что узлы кластера являются лишь вычислительными модулями, позволяет реализовать
+промежуточное программное обеспечение, которое автоматически распределяет роли
+главного и подчиненного узла и универсальным способом обрабатывает сбои узлов.
+Это программное обеспечение предоставляет программный интерфейс и распределяет
+управляющие объекты между доступными на данный момент узлами. Используя этот
+интерфейс, можно написать программу, которая запускается на кластере, не зная
+точного количества работающих узлов. Это промежуточное программное обеспечение
+работает как кластерная операционная система в пользовательском пространстве,
+позволяющая запускать распределенные приложения прозрачно на любом количестве
+узлов.
**** Симметричная архитектура.
Многие распределенные хранилища типа "ключ-значение" и параллельные файловые
diff --git a/arma-thesis.org b/arma-thesis.org
@@ -3085,15 +3085,15 @@ To summarise, node discovery algorithm is
**** 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
-the cluster to survive subordinate node failure, job scheduler periodically
-creates checkpoints and writes them to a stable storage. In order to create the
+slave node and failure of a master node. In order for a job running on the
+cluster to survive slave node failure, job scheduler periodically creates
+checkpoints and writes them to a stable storage. In order to create the
checkpoint, the scheduler temporarily suspends all parallel processes of the
job, copies all memory pages and all internal operating system kernel structures
allocated for these processes to disk, and resumes execution of the job. In
-order to survive principal node failure, job scheduler server process continuously
-copies its internal state to a backup node, which becomes the principal after
-the failure.
+order to survive master node failure, job scheduler daemon process continuously
+copies its internal state to a backup node, which becomes the master after the
+failure.
There are many works dedicated to improving performance of
checkpoints\nbsp{}cite:egwutuoha2013survey, and alternative approaches do not
@@ -3112,18 +3112,18 @@ number to be constant. So, there is no reliable way to provide fault tolerance
in message passing library other than restarting all parallel processes from a
checkpoint.
-There is, however, a possibility to continue execution of a job on lesser number
-of nodes than it was initially requested by implementing fault tolerance on
-application level. In this case principal and subordinate roles are dynamically
-distributed between job scheduler daemons running on each cluster node, forming
-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.
+At the same time, there is a possibility to continue execution of a job on
+lesser number of nodes than it was initially requested by implementing fault
+tolerance on application level. In this case master and slave roles are
+dynamically distributed between job scheduler daemons running on each cluster
+node, forming 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 is being
solved by big data and HPC job schedulers, however, most schedulers provide
-fault tolerance for subordinate nodes only. These types of failures are
+fault tolerance for slave 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
@@ -3134,23 +3134,21 @@ 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 and nodes are compute
-elements 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.
+From such point of view it seems more practical to implement master 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. Often a cluster is presented as a machine, which has a distinct
+control unit (master node) and a number of identical compute units (slave
+nodes). In practice, however, master and slave nodes are physically the same,
+and are distinguished only by batch job scheduler processes running on them.
+Realisation of the fact that cluster nodes are merely compute units allows to
+implement middleware that distributes master and slave 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 execute distributed applications transparently on any number of
+nodes.
**** Symmetric architecture.
Many distributed key-value stores and parallel file systems have symmetric
