commit 0f61e88f197c8242508f781084d23a25c560b357
parent af573182ce764361fd3e57d073fc5411eeaa3fa7
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Wed, 15 Feb 2017 12:06:04 +0300
Sync p3.
Diffstat:
2 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/phd-diss-ru.org b/phd-diss-ru.org
@@ -2985,25 +2985,19 @@ TODO translate
Наконец, иерархия управляющих объектов позволяет обрабатывать сбои прозрачно для
программиста, определяя порядок действий из внутреннего состояния объекта.
-Проведенные эксперименты показывают, что параллельной программе необходимо
-иметь несколько последовательных этапов выполнения, чтобы сделать ее устойчивой
-к сбоям узлов. Несмотря на то что вероятность сбоя резервного узла меньше
-вероятности сбоя одного из подчиненных узлов, это не повод потерять все данные,
-когда выполнявшаяся несколько дней задача почти завершилась. В общем случае,
-чем больше последовательных этапов вычислений содержит программа, тем меньше
-времени потеряется в случае сбоя резервного узла, и, аналогично, чем больше
-параллельных частей содержит каждый этап, тем меньше времени потеряется при
-сбое главного или подчиненного узла. Другими словами, /чем больше
-количество узлов, на которое масштабируется программа, тем она более устойчива
-к сбою оборудования/.
-
-В проведенных экспериментах узел, на котором запускается программа, выбирается
-вручную, чтобы совместить иерархию объектов и иерархию узлов, однако, такой
-подход не применим в реальных системах. Разработанный фреймворк должен делать
-это автоматически и эффективно распределять нагрузку между подчиненными узлами
-в независимости от местоположения главного узла в иерархии: выделение одного и
-того же узла в качестве главного для запуска нескольких приложений уменьшает
-общую отказоустойчивость системы.
+Проведенные эксперименты показывают, что параллельной программе необходимо иметь
+несколько последовательных этапов выполнения, чтобы сделать ее устойчивой к
+сбоям узлов, иначе выход из строя резервного узла фактически вызывает
+восстановление исходного состояния программы. Несмотря на то что вероятность
+сбоя резервного узла меньше вероятности сбоя одного из подчиненных узлов, это не
+повод потерять все данные, когда выполнявшаяся продолжительное время программа
+почти завершилась. В общем случае, чем больше последовательных этапов вычислений
+содержит параллельная программа, тем меньше времени потеряется в случае сбоя
+резервного узла, и, аналогично, чем больше параллельных частей содержит каждый
+последовательный этап, тем меньше времени потеряется при сбое руководящего или
+подчиненного узла. Другими словами, /чем больше количество узлов, на которое
+масштабируется программа, тем она становится более устойчива к сбою узлов
+кластера/.
Хотя это неочевидно из экспериментов, Фабрика не только обеспечивает
отказоустойчивость, но и позволяет автоматически вводить новые узлы в кластер и
diff --git a/phd-diss.org b/phd-diss.org
@@ -2896,23 +2896,17 @@ can act as a backup one. Finally, kernels allow handling failures in a way that
is transparent to a programmer, deriving the order of actions from the internal
state of a kernel.
-The disadvantage of this approach is evident: there is no way of making existing
-middleware highly-available without rewriting their source code. Although, our
-programming framework is lightweight, it is not easy to map architecture of
-existing middleware systems to it: most systems are developed keeping in mind
-static assignment of server/client roles, which is not easy to make dynamic.
-Hopefully, our approach will simplify design of future middleware systems.
-
-The benchmark from the previous section shows that it is essential for a
-parallel application to have multiple sequential steps to make it resilient to
-cluster node failures. Although, the probability of a principal node failure is
+The experiments show that it is essential for a parallel programme to have
+multiple sequential steps to make it resilient to cluster node failures,
+otherwise failure of a backup node in fact triggers recovery of the initial
+state of the programme. Although, the probability of a principal node failure is
lower than the probability of a failure of any of the subordinate nodes, it does
-not justify loosing all the data when the programme run is near completion. In
-general, the more sequential steps one has in an HPC application the less is
-performance penalty in an event of principal node failure, and the more parallel
-parts each step has the less is performance penalty in case of a subordinate
-node failure. In other words, /the more scalable an application is the more
-resilient to node failures it becomes/.
+not justify loosing all the data when the long programme run is near completion.
+In general, the more sequential steps one has in a parallel programme the less
+time is lost in an event of a backup node failure, and the more parallel parts
+each sequential step has the less time is lost in case of a principal or
+subordinate node failure. In other words, /the more scalable a programme is the
+more resilient to cluster node failures it becomes/.
Although it may not be clear from the benchmarks, Factory does not only provide
tolerance to node failures: new nodes automatically join the cluster and
