commit 75727788504043eb284fec68c6b6cb2e05a3a5b6
parent b2ede660e2b5a56a16ecad23c6ec10f779d13a4b
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Fri, 17 Feb 2017 12:11:02 +0300
Sync p2.
Diffstat:
2 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2707,25 +2707,24 @@ digraph {
процесс планировщика задач непрерывно копирует свое внутреннее состояние на
резервный узел, который становится руководящим после сбоя.
-Оптимизации работы контрольных точек восстановления посвящено большое
-количество работ\nbsp{}cite:egwutuoha2013survey, а альтернативным подходам
-уделяется меньше внимания. Обычно высокопроизводительные приложения используют
-передачу сообщений для обмена данными между параллельными процессами и хранят
-свое текущее состояние в глобальной памяти, поэтому не существует способа
-перезапустить завершившийся процесс, не записав образ всей выделенной для него
-памяти на диск. Обычно общее число процессов фиксировано и задается
-планировщиком, и в случае отказа перезапускаются сразу все процессы. Существуют
-некоторые обходные решения, которые позволяют перезапустить только часть
-процессов\nbsp{}cite:meyer2012radic, восстановив их на других узлах, однако это
-может привести к перегрузке, если на этих узлах уже запущены другие задачи.
-Теоретически, перезапуск процесса необязателен если задача может быть
-продолжена на меньшем количестве узлов, но библиотека передачи сообщений не
-позволяет изменять количество параллельных процессов во время работы программы,
-и большинство программ все равно предполагают, что это значение является
-константой, и используют его для распределения нагрузки между узлами. Таким
-образом, не существует простого способа обеспечения отказоустойчивости на
-уровне библиотеки передачи сообщений кроме как путем перезапуска всех
-параллельных процессов из контрольной точки восстановления.
+Оптимизации работы контрольных точек восстановления посвящено большое количество
+работ\nbsp{}cite:egwutuoha2013survey, а альтернативным подходам уделяется меньше
+внимания. Обычно высокопроизводительные приложения используют передачу сообщений
+для обмена данными между параллельными процессами и хранят свое текущее
+состояние в глобальной памяти, поэтому не существует способа перезапустить
+завершившийся процесс, не записав образ всей выделенной для него памяти на диск.
+Обычно общее число процессов фиксировано и задается планировщиком, и в случае
+отказа перезапускаются сразу все процессы. Существуют некоторые обходные
+решения, которые позволяют перезапустить только часть
+процессов\nbsp{}cite:meyer2012radic, восстановив их из контрольной точки на
+выживших узлах, однако это может привести к перегрузке, если на этих узлах уже
+запущены другие задачи. Теоретически, перезапуск процесса необязателен если
+задача может быть продолжена на выживших узлах, но библиотека передачи сообщений
+не позволяет изменять количество параллельных процессов во время работы
+программы, и большинство программ все равно предполагают, что это значение
+является константой. Таким образом, не существует надежного способа обеспечения
+отказоустойчивости на уровне библиотеки передачи сообщений кроме как путем
+перезапуска всех параллельных процессов из контрольной точки восстановления.
В то же время, существует возможность продолжить выполнение задачи на меньшем
количестве узлов, чем было изначально выделено под нее планировщиком. В этом
diff --git a/phd-diss.org b/phd-diss.org
@@ -2536,6 +2536,23 @@ order to survive principal node failure, job scheduler server process continuous
copies its internal state to a backup node, which becomes the principal after
the failure.
+There are many works dedicated to improving performance of
+checkpoints\nbsp{}cite:egwutuoha2013survey, and alternative approaches do not
+receive much attention. Usually HPC applications use message passing for
+parallel processes communication and store their state in global memory space,
+hence there is no way one can restart a failed process from its current state
+without writing the whole memory image to disk. Usually the total number of
+processes is fixed by the job scheduler, and all parallel processes restart upon
+a failure. There is ongoing effort to make it possible to restart only the
+failed process\nbsp{}cite:meyer2012radic by restoring them from a checkpoint on
+the surviving nodes, but this may lead to overload if there are other processes
+on these nodes. Theoretically, process restart is not needed, if the job can
+proceed on the surviving nodes, however, message passing library does not allow
+to change the number of processes at runtime, and most programmes assume this
+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.
+
**** 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,
