Правильная конфигурация для кластера высокой доступности ActiveMQ Artemis - PullRequest
0 голосов
/ 29 октября 2019

Я новичок в ActiveMQ Artemis и прошу сообщество проверить, правильно ли я настроил кластер HA-брокеров или, может быть, мне следует настроить их по-другому, так как я не нашел подробного руководства по моему делу. Все брокеры работают на одном компьютере.

Сценарий :

Существует главный узел на порту 61617 и два подчиненных узла (slave1, slave2)на портах 61618 и 61619. Если главный узел умирает, один из подчиненных становится активным (режим репликации).

Потребителю необходимо взаимодействовать с кластером как «черный ящик». Под этим я подразумеваю, что смена мастера (то есть, когда мастер умирает) не должна оказывать никакого влияния на потребителя (то есть на то, как он подключается к кластеру).

Что мне удалось сделать (как я понимаю дляв этом случае мы должны настроить только свойства кластера, акцептора и соединителя, поэтому я присоединяю только эту часть конфигурации посредников):

мастер-посредник:

<connectors>
    <connector name="artemis">tcp://localhost:61617</connector> 
</connectors>

<ha-policy>
    <replication>
        <master/>
    </replication>   
</ha-policy>

<acceptors>
    <acceptor name="artemis">tcp://localhost:61617</acceptor>
</acceptors>

<cluster-user>cluster</cluster-user>
<cluster-password>cluster</cluster-password>
<broadcast-groups>
    <broadcast-group name="bg-group1">
        <group-address>231.7.7.7</group-address>
        <group-port>9876</group-port>
        <broadcast-period>5000</broadcast-period>
        <connector-ref>artemis</connector-ref>
    </broadcast-group>
</broadcast-groups>
<discovery-groups>
    <discovery-group name="dg-group1">
        <group-address>231.7.7.7</group-address>
        <group-port>9876</group-port>
        <refresh-timeout>10000</refresh-timeout>
    </discovery-group>
</discovery-groups>
<cluster-connections>
    <cluster-connection name="my-cluster">
        <connector-ref>artemis</connector-ref>
        <message-load-balancing>ON_DEMAND</message-load-balancing>
        <max-hops>0</max-hops>
        <discovery-group-ref discovery-group-name="dg-group1"/>
    </cluster-connection>
</cluster-connections>

подчиненный 1 брокер кластерная конфигурация такая же, как у master (автоматическая настройка при создании узла через консоль --clustered)

<ha-policy>
    <replication>
        <slave/>
    </replication>
</ha-policy>

<connectors>
    <connector name="artemis">tcp://localhost:61618</connector>
    <connector name="netty-live-connector">tcp://localhost:61617</connector>
</connectors>

<acceptors>
    <acceptor name="artemis">tcp://localhost:61618 </acceptor>
</acceptors>

подчиненный 2 брокер conf кластера совпадает с master (автоконфигурация при создании узла через консоль --clustered)

<ha-policy>
    <replication>
        <slave/>
    </replication>
</ha-policy>

<connectors>
    <connector name="artemis">tcp://localhost:61619</connector>
    <connector name="netty-live-connector">tcp://localhost:61617</connector>
</connectors>

<acceptors>
    <acceptor name="artemis">tcp://localhost:61619</acceptor>
</acceptors>

JNDI-конфигурация у потребителя:

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.ConnectionFactory=(tcp://localhost:61617?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10,tcp://localhost:61618?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10,tcp://localhost:61619?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10)

Моя конфигурация работает,однако я не уверен, что это правильно.

Я также нашел похожий вопрос , в котором используются статические разъемы. Что они делают? Я не понимаю, как они работают. Или, может быть, это правильный способ конфигурации, который я ищу?

1 Ответ

0 голосов
/ 29 октября 2019

Первое, на что следует обратить внимание, это то, что использование одной пары прямой / резервной копии (или даже триплета прямой / резервной копии / резервного копирования) с сетевой репликацией опасно из-за риска «разделенного мозга». Я бы порекомендовал вам использовать либо 1 живую / резервную пару с общим хранилищем, либо 3 живые / резервную пару с репликацией (что позволит создать надлежащий кворум). Прочитайте документацию о разделенном мозге для получения более подробной информации.

Помимо риска разделения мозга, конфигурация брокера выглядит нормально. Большинство (если не все) подробности конфигурации описаны в документации кластеризация и HA . Существует также множество примеров, которые поставляются вместе с брокером, многие из которых относятся к кластеризации и HA.

Вы можете упростить URL-адрес фабрики соединений. В настоящее время у вас есть:

(tcp://localhost:61617?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10,tcp://localhost:61618?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10,tcp://localhost:61619?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10)

Однако вы можете использовать:

(tcp://localhost:61617,tcp://localhost:61618,tcp://localhost:61619)?ha=true&retryInterval=1000&retryIntervalMultiplier=1.0&reconnectAttempts=10

Статические соединители обычно используются в средах, которые не поддерживают многоадресную передачу UDP. Это позволяет вручную настраивать элементы кластера. Если вы находитесь в среде, которая поддерживает многоадресную передачу UDP, я рекомендую использовать конфигурацию групп обнаружения / широковещания, а не статическое обнаружение.

В общем, если все работает так, как вы хотите, это указывает на то, что ваша конфигурация в порядке.

...