Порты брандмауэра Infinispan jgroups

При использовании JGroups с таким компонентом, как Infinispan, какие порты мне нужно открыть в брандмауэре??

Мой файл конфигурации JGroups:

    <config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.4.xsd">
<UDP
         mcast_addr="${test.jgroups.udp.mcast_addr:239.255.0.1}"
         mcast_port="${test.jgroups.udp.mcast_port:46655}"
         bind_addr="${test.jgroups.udp.bind_addr:match-interface:eth0}"
         bind_port="${test.jgroups.bind.port:46656}"
         port_range="${test.jgroups.bind.port.range:20}"
         tos="8"
         ucast_recv_buf_size="25M"
         ucast_send_buf_size="1M"
         mcast_recv_buf_size="25M"
         mcast_send_buf_size="1M"

         loopback="true"
         max_bundle_size="64k"
         ip_ttl="${test.jgroups.udp.ip_ttl:2}"
         enable_diagnostics="false"
         bundler_type="old"

         thread_naming_pattern="pl"

         thread_pool.enabled="true"
         thread_pool.min_threads="3"
         thread_pool.max_threads="10"
         thread_pool.keep_alive_time="60000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="Discard"
         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="2"
         oob_thread_pool.max_threads="4"
         oob_thread_pool.keep_alive_time="60000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="Discard"

         internal_thread_pool.enabled="true"
         internal_thread_pool.min_threads="1"
         internal_thread_pool.max_threads="4"
         internal_thread_pool.keep_alive_time="60000"
         internal_thread_pool.queue_enabled="true"
         internal_thread_pool.queue_max_size="10000"
         internal_thread_pool.rejection_policy="Discard"
         />

    <PING timeout="3000" num_initial_members="3"/>
    <MERGE2 max_interval="30000" min_interval="10000"/>
    <FD_SOCK bind_addr="${test.jgroups.udp.bind_addr:match-interface:eth0}" start_port="${test.jgroups.fd.sock.start.port:9780}" port_range="${test.jgroups.fd.sock.port.range:10}" />
    <FD_ALL timeout="15000" interval="3000" />
    <VERIFY_SUSPECT timeout="1500" bind_addr="${test.jgroups.udp.bind_addr:match-interface:eth0}"/>

    <pbcast.NAKACK2
        xmit_interval="1000"
        xmit_table_num_rows="100"
        xmit_table_msgs_per_row="10000"
        xmit_table_max_compaction_time="10000"
        max_msg_batch_size="100"/>
    <UNICAST3
        xmit_interval="500"
        xmit_table_num_rows="20"
        xmit_table_msgs_per_row="10000"
        xmit_table_max_compaction_time="10000"
        max_msg_batch_size="100"
        conn_expiry_timeout="0"/>

   <pbcast.STABLE stability_delay="500" desired_avg_gossip="5000" max_bytes="1m"/>
   <pbcast.GMS print_local_addr="false" join_timeout="3000" view_bundling="true"/>
   <tom.TOA/> <!-- the TOA is only needed for total order transactions-->

   <UFC max_credits="2m" min_threshold="0.40"/>
   <MFC max_credits="2m" min_threshold="0.40"/>
   <FRAG2 frag_size="30k"  />
   <RSVP timeout="60000" resend_interval="500" ack_on_delivery="false" />
</config>

Теперь у меня есть следующие порты, открытые в брандмауэре (Chain INPUT (policy ACCEPT))

ACCEPT     udp  --  anywhere             anywhere            multiport dports 46655:46676 /* 205 ipv4 */ state NEW

ACCEPT     tcp  --  anywhere             anywhere            multiport dports 9780:9790 /* 204 ipv4 */ state NEW

Но все же после запуска встроенного кеша infinispan в течение нескольких минут я получаю

2014-11-05 18:21:38.025 DEBUG org.jgroups.protocols.FD_ALL - haven't received a heartbeat from <hostname>-47289 for 15960 ms, adding it to suspect list

он отлично работает, если я отключу iptables заранее спасибо


person Waqas Ikram    schedule 05.11.2014    source источник


Ответы (4)


Как вы настроили правила iptables? Я использовал (на Fedora 18)

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT  -p udp --dport 46655:46676  -j ACCEPT
iptables -A OUTPUT -p udp --dport 46655:46676  -j ACCEPT
iptables -A INPUT  -p tcp --dport 9780:9790    -j ACCEPT
iptables -A OUTPUT -p tcp --dport 9780:9790    -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP

Это работает для меня, между двумя хостами.

person Bela Ban    schedule 06.11.2014
comment
спасибо за ваш ответ, у меня открыты те же порты, которые вы указали выше, и они были открыты все время, но они все еще не работают. В моей среде у меня есть два блейда на одном шасси с IP-связью (настроен режим 1), когда интерфейс eth0 активен на обоих блейдах, тогда все работает отлично. Когда eth0 активен на одном лезвии, а eth1 активен на другом, создается кластер, и через некоторое время он начинает выдавать исключение, не получая пульса, и ни один процесс не покидает кластер даже в течение длительного периода времени (часы). - person Waqas Ikram; 06.11.2014

В моей среде у меня есть два блейда на одном шасси с IP-связью (настроен режим 1), когда интерфейс eth0 активен на обоих блейдах, тогда все работает отлично. Когда eth0 активен на одном блэйде, а eth1 активен на другом, создается кластер, и через некоторое время он начинает выдавать исключение «не получил пульс», и ни один процесс не покидает кластер даже в течение длительного периода времени (часы).

Эта ошибка в JGroups может быть связана с вашей проблемой: Не получать пульсация в конфигурации Nic Teaming после переключения NIC

Временное решение: переключение на TCP.

Смотрите также:

person Federico Sierra    schedule 06.11.2014

Что еще за режим 1? Отказоустойчивость я предполагаю? Не балансирует нагрузку? Возможно, вам нужно использовать iptables -i INTF, где INTF — это eth0 или eth1? Я не эксперт в iptables, но, возможно, вам нужно определить логическое имя, например. iptables -i бонд0 ? Я предлагаю использовать wireshark, чтобы увидеть, какие пакеты получены, и/или включить отладку DROP в iptables на обоих устройствах.

person Bela Ban    schedule 06.11.2014
comment
Режим 1 = отказоустойчивость. Обнаружено, что мы блокируем пакеты IGMP. Обновлен брандмауэр, чтобы разрешить IGMP. Кстати, с помощью RHEL. Однако мы по-прежнему видим сообщения пульса от FD_ALL, как описано выше, но теперь только во время загрузки. Время в сообщении продолжает увеличиваться каждые 2 секунды, но узел не покидает кластер. Во всяком случае, мы не получаем сообщения о том, что он покидает кластер. Следует ли удалить его из кластера, если для узла в течение нескольких минут отображаются сообщения пульса на основе приведенной выше конфигурации? Когда узел перезапускается, он не может присоединиться к кластеру. Он образует отдельный кластер только с самим собой. - person Waqas Ikram; 13.11.2014

Это происходило из-за того, что коммутатор отбрасывал UDP-пакеты из-за ограничений, установленных на коммутаторе для UDP-пакетов...

person Waqas Ikram    schedule 17.11.2014