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

Question

У нас есть (не будет слишком долго, если у вас есть силы), достаточно большой кластер из примерно 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 --> 

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

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

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

Answer 1

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

No.

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

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

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