#high-availability #activemq-artemis
#высокая доступность #activemq-artemis
Вопрос:
Я хочу создать систему ActiveMQ Artemis, которая может взаимодействовать с другим межрегиональным сервером и одновременно выполнять балансировку нагрузки и высокую доступность.
Таким образом, у меня есть две виртуальные машины (172.16.212.32 и 172.16.212.33). Каждая виртуальная машина имеет два сервера репликации для обеспечения высокой доступности, и я настроил федерацию на каждом сервере для достижения балансировки нагрузки. Я знаю, что федерация может установить параметр ha, но я думаю, что сервер репликации будет выполнять лучший эффект отработки отказа локально.
Ниже приведена настройка.
Мастер (172.16.212.20) в виртуальной машине (172.16.212.32) :
<connectors>
<connector name="netty-connector">tcp://172.16.212.20:61616</connector>
<connector name="master-connector33">tcp://172.16.212.22:61616</connector>
<connector name="slave-connector33">tcp://172.16.212.23:61616</connector>
</connectors>
<broadcast-groups>
<broadcast-group name="bg-group32">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<broadcast-period>5000</broadcast-period>
<connector-ref>netty-connector</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="dg-group32">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<cluster-user>root</cluster-user>
<cluster-password>syscom#1</cluster-password>
<cluster-connections>
<cluster-connection name="cluster32">
<connector-ref>netty-connector</connector-ref>
<message-load-balancing>ON_DEMAND</message-load-balancing>
<max-hops>1</max-hops>
<discovery-group-ref discovery-group-name="dg-group32"/>
</cluster-connection>
</cluster-connections>
<ha-policy>
<replication>
<master>
<check-for-live-server>true</check-for-live-server>
</master>
</replication>
</ha-policy>
<federations>
<federation name="master-federation32">
<upstream name="master-upstream33">
<circuit-breaker-timeout>1000</circuit-breaker-timeout>
<static-connectors>
<connector-ref>master-connector33</connector-ref>
</static-connectors>
<policy ref="policySetA"/>
</upstream>
<upstream name="slave-upstream33">
<circuit-breaker-timeout>1000</circuit-breaker-timeout>
<static-connectors>
<connector-ref>slave-connector33</connector-ref>
</static-connectors>
<policy ref="policySetA"/>
</upstream>
<policy-set name="policySetA">
<policy ref="queue-federation" />
</policy-set>
<queue-policy name="queue-federation" >
<include queue-match="#" address-match="#" />
</queue-policy>
</federation>
</federations>
Подчиненный (172.16.212.21) в виртуальной машине (172.16.212.32):
<connectors>
<connector name="netty-connector">tcp://172.16.212.21:61616</connector>
<connector name="master-connector33">tcp://172.16.212.22:61616</connector>
<connector name="slave-connector33">tcp://172.16.212.23:61616</connector>
</connectors>
<broadcast-groups>
<broadcast-group name="bg-group32">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<broadcast-period>5000</broadcast-period>
<connector-ref>netty-connector</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="dg-group32">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<cluster-user>root</cluster-user>
<cluster-password>syscom#1</cluster-password>
<cluster-connections>
<cluster-connection name="cluster32">
<connector-ref>netty-connector</connector-ref>
<message-load-balancing>ON_DEMAND</message-load-balancing>
<max-hops>1</max-hops>
<discovery-group-ref discovery-group-name="dg-group32"/>
</cluster-connection>
</cluster-connections>
<ha-policy>
<replication>
<slave>
<allow-failback>true</allow-failback>
</slave>
</replication>
</ha-policy>
<federations>
<federation name="slave-federation32">
<upstream name="master-upstream33" priority-adjustment="0">
<circuit-breaker-timeout>1000</circuit-breaker-timeout>
<static-connectors>
<connector-ref>master-connector33</connector-ref>
</static-connectors>
<policy ref="policySetA"/>
</upstream>
<upstream name="slave-upstream33" priority-adjustment="0">
<circuit-breaker-timeout>1000</circuit-breaker-timeout>
<static-connectors>
<connector-ref>slave-connector33</connector-ref>
</static-connectors>
<policy ref="policySetA"/>
</upstream>
<policy-set name="policySetA">
<policy ref="queue-federation" />
</policy-set>
<queue-policy name="queue-federation" >
<include queue-match="#" address-match="#" />
</queue-policy>
</federation>
</federations>
172.16.212.22 и 172.16.212.23 являются ведущим и подчиненным серверами в виртуальной машине 172.16.212.33.
После такой настройки главный сервер на разных виртуальных машинах может взаимодействовать друг с другом, а подчиненные серверы объявляют об успешном резервном копировании. Но балансировка нагрузки не работает.
Не работает ли идея федерации плюс политика репликации ha? Я был бы признателен, если у вас есть какие-либо советы для меня.
Комментарии:
1. Если вы хотите балансировку нагрузки HA , почему бы просто не использовать кластер? Федерация действительно предназначена для брокеров (или наборов брокеров), которые обслуживают уникальные приложения, но все же нуждаются в некотором уровне интеграции друг с другом для обмена сообщениями здесь и там. Вы настроили федерацию для каждого адреса, что больше похоже на то, что вы просто хотите использовать кластеризацию. Устранение федерации и просто кластеризация существенно упростили бы вашу конфигурацию.
2. Хотя в этом случае неясно, будет ли система использоваться в контейнерах Kubernetes, у меня могут быть производители в одном сегменте сети, а потребители в другом сегменте сети. Я думаю, что сервер кластера обнаружил, что он использует многоадресную рассылку UDP, поэтому он не может перемещать сообщения по глобальной сети между регионами. С другой стороны, кластер с более чем двумя серверами не будет отказывать, и репликация ha не сможет достичь балансировки нагрузки.
3. Если вы используете Kubernetes (или любую облачную среду, в которой не работает многоадресная рассылка UDP) и хотите настроить кластер ActiveMQ Artemis, вы можете использовать нашу интеграцию JGroups с протоколом обнаружения KUBE_PING от JGroup. После обнаружения посредников между узлами формируются обычные мосты ядра (с использованием TCP). Эти мосты позволяют передавать сообщения и другие метаданные кластера между узлами для таких целей, как балансировка нагрузки.
4. Чтобы было понятно, кластер может быть сформирован из пар HA. Таким образом, вы получаете преимущества как балансировки нагрузки, так и отказа.
5. Итак, в среде Kubernetes вы рекомендуете использовать JGroup вместо федерации? Что может произойти с текущей архитектурой federation ha?