commit 82f397807661795fe1abcee3ad99e3a6bcf3b1bd
parent 88ff88110d8d014c3929d665f6d9318093e54cbb
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Fri, 3 Nov 2017 11:31:24 +0300
Edit node discovery evaluation.
Diffstat:
| arma-thesis-ru.org | | | 151 | +++++++++++++++++++++++++++++++++++++++---------------------------------------- |
| arma-thesis.org | | | 57 | ++++++++++++++++++++++++++++----------------------------- |
2 files changed, 103 insertions(+), 105 deletions(-)
diff --git a/arma-thesis-ru.org b/arma-thesis-ru.org
@@ -3088,89 +3088,88 @@ digraph {
[[file:build/tree-hierarchy-11-ru.pdf]]
**** Результаты тестирования.
-Платформа, на которой осуществлялось тестирование, представляла собой несколько
-многоядерных узлов, поверх которых с помощью пространств имен Linux
-развертывался виртуальный кластер из заданного количества узлов. Похожий подход
-используется в\nbsp{}cite:lantz2010network,handigol2012reproducible,heller2013reproducible, где
-авторы воспроизводят разнообразные практические эксперименты на виртуальных
+Для тестирования производительности обнаружения узлов, на каждом физическом узле
+кластера запускалось несколько резидентных процессов, каждый из которых был
+приявязан к отдельному IP-адресу. Количество процессов на одно физическое ядро
+варьировалось от 2 до 16. Каждый процесс был привязан к определенному
+физическому ядру, чтобы уменьшить накладные расходы на миграцию процессов между
+ядрами. Алгоритм обхода древовидной иерархии имеет низкие требования к
+процессорному времени и пропускной способности сети, поэтому запуск нескольких
+процессов на одном физическом ядре целесообразно, в отличие от кодов
+высокопроизводительных приложений, в которых это часто ведет к низкой
+производительности. Конфигурация тестовой системы показана в
+табл.\nbsp{}[[tab-ant]].
+
+#+name: tab-ant
+#+caption: Конфигурация системы Ant.
+#+attr_latex: :booktabs t
+| Процессор | Intel Xeon E5440, 2,83ГГц |
+| Память | 4ГБ |
+| Жесткий диск | ST3250310NS, 7200об./мин. |
+| Количество узлов | 12 |
+| Количество ядер на узел | 8 |
+
+Похожий подход используется
+в\nbsp{}cite:lantz2010network,handigol2012reproducible,heller2013reproducible,
+где авторы воспроизводят разнообразные практические эксперименты на виртуальных
кластерах и сопоставляют результаты с физическими. Преимущество данного подхода
заключается в возможности проведения экспериментов на больших виртуальных
-кластерах, используя сравнительно небольшое количество физических узлов. Данный
-подход использовался для тестирования алгоритма обнаружения узлов кластера,
-потому что этот алгоритм обладает низкими требованиями к ресурсам системы
-(процессорному времени и пропускной способности сети).
-
-Производительность алгоритма была протестирована путем измерения времени
-необходимого для обнаружения всеми узлами кластера друг друга. Каждое изменение
-иерархии (с точки зрения каждого из узлов) записывалось в файл, и по прошествии
-30 секунд все процессы (каждый из которых моделирует один узел кластера) были
-вынужденно завершены. Пробные запуски показали, что одновременный запуск более
-100 виртуальных узлов искажал результаты, поэтому для этого эксперимента были
-использованы дополнительные физические узлы, на каждом из которых запускалось по
-100 виртуальных. Эксперимент показал, что обнаружение 100--400 узлами друг друга
-занимает в среднем 1,5 секунды, и это значение ненамного увеличивается с ростом
-количества узлов (см.\nbsp{}рис.\nbsp{}[[fig-bootstrap-local]]). Пример древовидной
-иерархии для 11 узлов с ветвлением равным 2 представлен на
-рис.\nbsp{}[[fig-tree-hierarchy-11]].
-
-#+name: fig-bootstrap-local
-#+caption: Зависимость времени объединения узлов в кластер от их количества.
-[[file:graphics/discovery.eps]]
-
-#+name: fig-tree-hierarchy-11
-#+begin_src dot :exports results :file build/tree-hierarchy-11-ru.pdf
-digraph {
-
- node [fontname="Old Standard",fontsize=14,margin="0.055,0.055",shape=box,style=rounded]
- graph [nodesep="0.30",ranksep="0.30",rankdir="BT"]
- edge [arrowsize=0.66]
-
- m1 [label="10.0.0.1"]
- m2 [label="10.0.0.2"]
- m3 [label="10.0.0.3"]
- m4 [label="10.0.0.4"]
- m5 [label="10.0.0.5"]
- m6 [label="10.0.0.6"]
- m7 [label="10.0.0.7"]
- m8 [label="10.0.0.8"]
- m9 [label="10.0.0.9"]
- m10 [label="10.0.0.10",fillcolor="#c0c0c0",style="filled,rounded"]
- m11 [label="10.0.0.11",shape=Mrecord]
-
- m2->m1
- m3->m1
- m4->m2
- m5->m2
- m6->m3
- m7->m3
- m8->m4
- m9->m4
- m10->m5
- m11->m5
-
- m5->m4->m6 [style="dashed,bold",color="#c00000",constraint=false]
- {rank=same; m6->m7 [style="dashed,bold",color="#c00000"]}
- m7->m2->m3->m1->m8->m9 [style="dashed,bold",color="#c00000",constraint=false]
-
-}
+кластерах, используя сравнительно небольшое количество физических узлов.
+Преимущество подхода, используемого в данной работе, в котором не применяются
+пространства имен Linux, заключается в том, что он более легковесный и большее
+количество резидентных процессов можно протестировать на одном и том же
+физическом кластере.
+
+Производительность обнаружения узлов была протестирована путем измерения
+времени, которое необходимо для того чтобы все узлы кластера нашли друг друга,
+т.е.\nbsp{}времени, которое необходимо для того чтобы древовидная иерархии узлов
+достигла устойчивого состояния. Каждое изменение иерархии, то, как его видит
+каждый узел, записывалось в файл журнала, и по прошествии заданного промежутка
+времени все резидентные процессы (каждый из которых моделирует узел кластера)
+принудительно завершались. Процессы запускались последовательно с задержкой в
+100мс., чтобы удостовериться, что главные узлы становятся доступны раньше
+подчиненных, а иерархия не меняется произвольным образом в результате разного
+времени запуска процессов. Эта искусственная задержка впоследствии была вычтена
+из результатов тестирования. Таким образом, результаты теста представляют собой
+время обнаружения узлов в "идеальном" кластере, к котором каждый резидентный
+процесс находит главного с первой попытки.
+
+Тест запускался несколько раз, варьируя количество резидентных процессов на
+физический узел. Эксперимент показал, что обнаружение 512 узлами (8 физических
+узлов по 64 процесса на узел) друг друга занимает не более двух секунд
+(рис.\nbsp{}[[fig-discovery-benchmark]]). Это значение менятся незначительно с
+увеличением количества физических узлов. Использование более 8 узлов по 64
+процесса на узел приводит к большой колебаниям времени обнаружения, ввиду того
+что большое количествао процессов одновременно устанавливает соединение с одним
+и тем же главным процессов (значение ветвления во всех тестах равнялось 10000),
+поэтому эти результаты были исключены.
+
+#+name: fig-discovery-benchmark
+#+header: :width 7 :height 5
+#+begin_src R :file build/discovery-benchmark-ru.pdf
+source(file.path("R", "discovery.R"))
+bscheduler.plot_discovery(
+ xlabel="Количество физических узлов",
+ ylabel="Время, сек.",
+ toplabel="ppn")
#+end_src
-#+caption: Древовидная иерархия для 11 узлов для ветвления равного 2.
-#+label: fig-tree-hierarchy-11
-#+RESULTS: fig-tree-hierarchy-11
-[[file:build/tree-hierarchy-11-ru.pdf]]
+#+caption: Время обнаружения всех резидентных процессов, запущенных на кластере, в зависимости от количества процессов. Пунктирная линия обозначает минимальное и макисмальное значение за все проведенные тесты, "ppn" --- количество резидентных процессов на узел.
+#+name: fig-discovery-benchmark
+#+RESULTS: fig-discovery-benchmark
+[[file:build/discovery-benchmark-ru.pdf]]
**** Обсуждение.
Поскольку узлу для выбора руководителя нужно соединиться с узлом, адрес которого
-известен заранее, то алгоритм обнаружения масштабируется на большое количество
-узлов. Соединение с другими узлами из ранжированного списка происходит только в
-том случае, если текущий узел-руководитель выходит из строя. Таким образом, если
-адреса узлов кластера расположены плотно в диапазоне адресов подсети, каждый
-узел устанавливает соединение только со своим руководителем, и неэффективного
-сканирования всей сети каждым узлом не происходит.
-
-Следующие ключевые особенности отличают наш подход от некоторых предложенных
-ранее
+известен заранее, то обнаружение узлов масштабируется на большое количество
+узлов. Соединение с другими узлами происходит только в том случае, если текущий
+узел-руководитель выходит из строя. Таким образом, если адреса узлов кластера
+расположены непрерывно в диапазоне адресов подсети, каждый узел устанавливает
+соединение только со своим руководителем, и неэффективного сканирования всей
+сети каждым узлом не происходит.
+
+Следующие ключевые особенности отличают предложенный подход от некоторых
+существующих
подходов\nbsp{}cite:brunekreef1996design,aguilera2001stable,romano2014design.
- *Многоуровневая иерархия.* Количество руководящих узлов в сети зависит от
значения ветвления. Если оно меньше количества IP-адресов в подсети, то в
diff --git a/arma-thesis.org b/arma-thesis.org
@@ -2911,14 +2911,13 @@ digraph {
**** Evaluation results.
To benchmark performance of node discovery, several daemon processes were
-launched on each physical cluster node, each listening on its own IP address.
-The number of processes per physical core varied from 2 to 16. Each process was
-bound to a particular physical core to reduce process migration overhead on the
-benchmark. Tree hierarchy traversal algorithm has low requirements for system
-resources (processor time and network throughput), so running multiple processes
-per physical core is feasible, in contrast to HPC codes, where oversubscribing
-generally leads to poor performance. Test platform configuration is shown in
-table\nbsp{}[[tab-ant]].
+launched on each physical cluster node, each bound to its own IP address. The
+number of processes per physical core varied from 2 to 16. Each process was
+bound to a particular physical core to reduce overhead of process migration
+between cores. Tree hierarchy traversal algorithm has low requirements for
+processor time and network throughput, so running multiple processes per
+physical core is feasible, in contrast to HPC codes, where it often leads to
+poor performance. Test platform configuration is shown in table\nbsp{}[[tab-ant]].
#+name: tab-ant
#+caption: Test platform configuration.
@@ -2934,32 +2933,31 @@ in\nbsp{}cite:lantz2010network,handigol2012reproducible,heller2013reproducible
where the authors reproduce various real-world experiments using virtual
clusters, based on Linux namespaces, and compare the results to physical ones.
The advantage of it is that the tests can be performed on a large virtual
-cluster using relatively small number of physical nodes. The advantage of our
-approach, which does not use Linux namespaces, is that it is more lightweight
-and larger number of daemon processes can be benchmarked on the same physical
-cluster.
+cluster using relatively small number of physical nodes. The advantage of the
+approach used in this work, which does not use Linux namespaces, is that it is
+more lightweight and larger number of daemon processes can be benchmarked on the
+same physical cluster.
Node discovery performance was evaluated by measuring time needed for all nodes
-of the cluster to discover each other, i.e. the time needed for the tree
+of the cluster to discover each other, i.e.\nbsp{}the time needed for the tree
hierarchy of nodes to reach stable state. Each change of the hierarchy, as seen
by each node, was written to a log file and after a set amount of time all
daemon processes (each of which models cluster node) were forcibly terminated.
-Each new daemon process was launched with a 100ms delay to ensure that principal
-nodes are always come online before subordinates and hierarchy does not change
-randomly as a result of different start time of each process. This artificial
-delay was subsequently subtracted from the results. So, benchmark results
-represent discovery time in an "ideal" cluster, in which every daemon always
-finds its principal on the first try.
-
-The benchmark was run varying the number of daemons per cluster node. The
-experiment showed that discovery of up to 512 (8 nodes with 64 processes per
-node) nodes each other takes no more than 2 seconds
+Daemon processes were launched sequentially with a 100ms delay to ensure that
+principal nodes are always come online before subordinates and hierarchy does
+not change randomly as a result of different start time of each process. This
+artificial delay was subsequently subtracted from the results. So, benchmark
+results represent discovery time in an "ideal" cluster, in which every daemon
+process always finds its principal on the first try.
+
+The benchmark was run multiple times varying the number of daemon processes per
+cluster node. The experiment showed that discovery of 512 nodes (8 physical
+nodes with 64 processes per node) each other takes no more than two seconds
(fig.\nbsp{}[[fig-discovery-benchmark]]). This value does not change significantly
with the increase in the number of physical nodes. Using more than 8 nodes with
64 processes per node causes large variation in discovery time due to a large
total number of processes connecting simultaneously to one master process (a
-fan-out value of 10000 was used for all tests), so these results were excluded
-from the benchmark.
+fan-out value of 10000 was used for all tests), so these results were excluded.
#+name: fig-discovery-benchmark
#+header: :width 7 :height 5
@@ -2968,7 +2966,7 @@ source(file.path("R", "discovery.R"))
bscheduler.plot_discovery(xlabel="No. of physical nodes",toplabel="ppn")
#+end_src
-#+caption: Time to discover all daemon processes running on the cluster depending on the number of daemon processes. Dashed lines represent minimum and maximum values.
+#+caption: Time to discover all daemon processes running on the cluster depending on the number of daemon processes. Dashed lines represent minimum and maximum values, "ppn" denotes the number of daemon processes per node.
#+name: fig-discovery-benchmark
#+RESULTS: fig-discovery-benchmark
[[file:build/discovery-benchmark.pdf]]
@@ -2981,9 +2979,9 @@ principal node fails. So, if cluster nodes occupy contiguous addresses in
network IP address range, each node connects only to its principal, and
inefficient scan of the whole network by each node does not occur.
-The following key features distinguish this approach with respect to some
-existing
-proposals\nbsp{}cite:brunekreef1996design,aguilera2001stable,romano2014design.
+The following key features distinguish the proposed approach with respect to
+some existing
+approaches\nbsp{}cite:brunekreef1996design,aguilera2001stable,romano2014design.
- *Multi-level hierarchy.* The number of principal nodes in a network depends on
the fan-out value. If it is lesser than the number of IP-addresses in the
network, then there are multiple principal nodes in the cluster. If it is
@@ -3047,6 +3045,7 @@ To summarise, node discovery algorithm is
time,
- fully event-based as it does not overload the network by periodically sending
state update messages.
+
*** Fail over algorithm
:PROPERTIES:
:CUSTOM_ID: sec-fail-over
