Устойчивость большого кластера Hazelcast

58
8

У нас есть (не будет слишком долго, если у вас есть силы) достаточно большой кластер из примерно 600 узлов, все они под тем же "именем группы", а лишь небольшая часть (около десятка) когда-либо превращали его в список интерфейсов TCP/IP, определенных в файле hazelcast.xml

Здесь наша конфигурация

<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.1.xsd"
xmlns="http://www.hazelcast.com/schema/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<group>
<name>BlappityBlah</name>
<password>blahBlaha</password>
</group>
<management-center enabled="false"/>
<network>
<port auto-increment="true">6401</port>
<outbound-ports>
<!--
Allowed port range when connecting to other nodes.
0 or * means use system provided port.
-->
<ports>0</ports>
</outbound-ports>
<join>
<multicast enabled="false">
<multicast-group>224.2.2.3</multicast-group>
<multicast-port>54327</multicast-port>
</multicast>
<tcp-ip enabled="true">
<interface>10.50.3.101-102,10.50.3.104-105,10.50.3.108-112,10.60.2.20,10.60.3.103,10.60.4.106-107</inter
face>
</tcp-ip>
<aws enabled="false">
<access-key>my-access-key</access-key>
<secret-key>my-secret-key</secret-key>
<!--optional, default is us-east-1 -->

Остальные связаны только с именем "Group Name", которое определяет кластер, по моему пониманию. Мы не используем многоадресную рассылку в нашей конфигурации. Первичное применение нашего кластера осуществляется в распределенной блокировке. В последнее время мы замечаем произвольные тайм-ауты и падение связи между узлами, повторное разделение и зависание. Через некоторое время все зависает. Раньше мы заканчивали перезагрузку узлов, теперь мы используем консоль Hazelcast TestApp для очистки карты блокировок. Я могу поручиться за то, что код, который блокирует и разблокирует, достаточно водонепроницаем. Мое наблюдение. Раньше у нас не было таких проблем, пока мы не обновили Hazelcast до 3.1.5 и не масштабировали наши узлы с 30 нечетных до сих пор 500+, из которых большинство узлов являются JVM, часто до десятка на тот же физический узел. Это не произошло в одночасье, это было постепенным.

a) Значит ли тот факт, что большинство наших узлов не фигурируют в файле hazelcast.xml, влияют на их стабильность как членов кластера?

б) Кто-нибудь видел проблемы с масштабированием, это ошибка Hazelcast, или мы делаем что-то ужасно неправильно, в то время как у всех вас есть мяч с Hazelcast?

спросил(а) 2016-01-12T22:46:00+03:00 4 года, 8 месяцев назад
1
Решение
70

a) Значит ли тот факт, что большинство наших узлов не фигурируют в файле hazelcast.xml, влияют на их стабильность как членов кластера?

Нет.

б) Кто-нибудь видел проблемы с масштабированием, это ошибка Hazelcast, или мы делаем что-то ужасно неправильно, в то время как у всех вас есть мяч с Hazelcast?

Повторное разбиение случайных кластеров увеличивается с добавлением узлов. Т.е. если вероятность сбоя единственного узла составляет, например, 0,01% в день, то с 600 узлами ваш шанс увидеть ежедневный отказ узла (= перераспределение) составляет почти 6%. При шансе 0.001% -ного сбоя на узел в день вы все равно будете на 1% вероятнее всего в кластере.

Другими словами, вы - кластер, вероятно, больше, чем желательно, независимо от реализации.

ответил(а) 2016-01-13T22:05:00+03:00 4 года, 8 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема