commit b0713f9e698d5d81403ae1a2f75db789df4eef26
parent dd63ae3c290cbfef33ce97d9fcecb5aead38c00f
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Wed, 15 Feb 2017 12:23:14 +0300
Sync p5.
Diffstat:
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2999,19 +2999,25 @@ TODO translate
масштабируется программа, тем она становится более устойчива к сбою узлов
кластера/.
-Хотя это неочевидно из экспериментов, Фабрика не только обеспечивает
+Хотя это не было показано в экспериментах, Фабрика не только обеспечивает
устойчивость к выходу из строя узлов кластера, но и позволяет автоматически
вводить новые узлы в кластер и распределять на них часть управляющих объектов из
уже запущенных программ. В контексте фреймворка этот процесс тривиален,
поскольку не требует перезапуска незавершившихся управляющих объектов и
копирования их состояния, и не изучался экспериментально в данной работе.
-Теоретически отказоустойчивость, основанная на иерархии может быть реализована
-поверх библиотеки передачи сообщений без потери общности. Хотя использование
-незагруженных узлов заместо вышедших из строя в рамках такой библиотеки
-представляет определенную сложность, поскольку количество узлов, на которых
-запущена программа фиксировано, но выделение достаточно большого количества
-узлов для программы будет достаточно для обеспечения отказоустойчивости.
+Теоретически, отказоустойчивость, основанная на иерархии узлов и управляющих
+объектов, может быть реализована поверх библиотеки передачи сообщений без потери
+общности. Хотя использование незагруженных узлов заместо вышедших из строя в
+рамках такой библиотеки представляет определенную сложность, поскольку
+количество узлов, на которых запущена программа, в таких библиотеках
+фиксировано, однако, выделение достаточно большого количества узлов для
+программы будет достаточно для обеспечения ее отказоустойчивости. В то же время,
+реализация отказоустойчивости, основанной на иерархии, внутри самой библиотеки
+передачи сообщений не практично, поскольку это потребует сохранения текущего
+состояния параллельной программы, объем которого эквивалентен всей занимаемой ей
+памятью на каждом узле кластера, что, в свою очередь, не позволит сделать такой
+подход эффективнее контрольных точек восстановления.
Слабым местом описанных методов является период времени, начиная с отказа
главного узла и заканчивая обнаружением сбоя подчиненным узлом. Если до момента
diff --git a/phd-diss.org b/phd-diss.org
@@ -2915,15 +2915,16 @@ programmes. This is trivial process as it does not involve restarting failed
kernels or copying their state, so it has not been studied experimentally in
this work.
-Theoretically, hierarchy-based fault-tolerance can be implemented on top of the
-message-passing library without loss of generality. Although it would be
-complicated to reuse free nodes instead of failed ones, as the number of nodes
-is often fixed in such libraries, allocating reasonably large number of nodes
-for the application would be enough to make it fault-tolerant. However,
-implementing hierarchy-based fault-tolerance "below" message-passing library
-does not seem beneficial, because it would require saving the state of a
-parallel application which equals to the total amount of memory it occupies on
-each host, which would not make it more efficient than checkpoints.
+Theoretically, fault tolerance based on a hierarchy of nodes and kernels can be
+implemented on top of the message-passing library without loss of generality.
+Although it would be complicated to reuse free nodes instead of failed ones in
+the framework of this library, as the number of nodes is often fixed in such
+libraries, allocating reasonably large number of nodes for the programme would
+be enough to make it fault-tolerant. At the same time, implementing
+hierarchy-based fault tolerance inside message-passing library itself is not
+practical, because it would require saving the state of a parallel programme
+which equals to the total amount of memory it occupies on each cluster node,
+which in turn would not make it more efficient than checkpoints.
The weak point of the proposed technology is the length of the period of time
starting from a failure of principal node up to the moment when the failure is
