1

私たちは (権力が自分のやり方を持っているなら、あまり長くは真実ではありません) 約 600 ノードのかなり大きなクラスターを持ち、それらはすべて同じ「グループ名」の下にありますが、それらのほんの一部 (約ダース) は、hazelcast.xml で定義された TCP/IP インターフェイスのリストにそれを作成しました。

これが私たちの構成です

<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 であり、多くの場合、同じノード上で最大 12 のノードです。物理ノード。これはしませんでした

a) ほとんどのノードが hazelcast.xml に記載されていないという事実は、クラスターのメンバーとしての安定性に影響しますか?

b) スケーリングの問題を見た人はいますか? これは Hazelcast のバグですか? それとも、他の人が Hazelcast でボールを持っている間に何かひどく間違ったことをしているのですか?

4

1 に答える 1