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

У нас есть (не будет так надолго, если власть имущие добьются своего) достаточно большой кластер из примерно 600 узлов, все они под одним и тем же «именем группы», в то время как только часть из них (около dozen) когда-либо попали в список интерфейсов 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, на их стабильность как членов кластера?

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


cluster-computing hazelcast distributed locks stability
person SriniMurthy    schedule 12.01.2016    source источник
comment
Почему вам нужен кластер на 600 узлов? Простой 10-узловой кластер с кучей 15 Гбайт должен быть в состоянии удерживать очень большое количество блокировок.   -  person pveentjer    schedule 13.01.2016
comment
И почему у вас есть до дюжины HZ JVM на одном физическом узле?   -  person pveentjer    schedule 13.01.2016
comment
У меня никогда не было возможности увидеть этот вопрос, но такова природа нашего кластера: через каждый из этих узлов выполняются интенсивные математические вычисления, добрый десяток из них размещен на одном компьютере, каждый из которых может иметь до 300 ГБ ОЗУ и разделены на дюжину, чтобы обрабатывать различные аспекты нашего рабочего процесса. Можем ли мы сделать это с помощью Hadoop сейчас? Может быть, но динозавры продолжают жить   -  person SriniMurthy    schedule 22.09.2016

Ответы (1)


arrow_upward
2
arrow_downward

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

No.

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

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

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

person nilskp    schedule 13.01.2016
comment
Еще одно замечание: если вы запустите такой большой кластер, вам придется изменить счетчик разделов, который по умолчанию равен 271 (свойство hazelcast.partition.count). См. Документацию о том, как это сделать: docs.hazelcast. org / docs / 3.5 / manual / html-single / - person noctarius; 14.01.2016
comment
Спасибо, noctarius и nilskp. Я буду обновлять свои выводы, когда эти изменения конфигурации окажут какое-либо влияние на мой кластер. - person SriniMurthy; 14.01.2016