невозможно получить бесконечность для формирования кластера внутри домена Keycloak / WF - PullRequest
Новая
       91

невозможно получить бесконечность для формирования кластера внутри домена Keycloak / WF

0 голосов
/ 23 марта 2020

Я настроил кластерный домен Keycloak6.0.1 / WildFly16, состоящий из 5 виртуальных машин. Домен на самом деле работает нормально, но вдруг я обнаружил, что не могу использовать Keycloak без липких сессий на балансировщике. Затем потребовалось некоторое время, чтобы осознать, что это связано с тем, что бесконечно длительные кэши не синхронизируются и не работают удаленные вызовы. Сначала это было из-за того, что транспорт JGroups не работал, но теперь у меня он работает без сбоев (на самом деле я пробовал различные конфигурации: многоадресная рассылка udp из порта udp / 55200, TCP-пинг на 7600 как с устаревшей, так и с современной конфигурацией), но все же мой keycloak ВМ не видят друг друга. В настоящее время я запускаю устаревшую конфигурацию TCP ping, поскольку с помощью tcpdump и iptables log легче понять, что происходит в ней, и вот мои конфиги и соответствующие записи журнала:

раздел протокола обнаружения: 

<subsystem xmlns="urn:jboss:domain:jgroups:6.0" default-stack="tcp">
            <channels default="ee">
                <channel name="ee" stack="tcp" cluster="ejb"/>
            </channels>
            [...]
            <stack name="tcp">
                    <transport type="TCP" socket-binding="jgroups-tcp"/>
                    <protocol type="TCPPING">
                        <property name="initial_hosts">xxx.xxx.xxx.175[7600],xxx.xxx.xxx.176[7600],xxx.xxx.xxx.177[7600],xxx.xxx.xxx.178[7600],xxx.xxx.xxx.179[7600]</property>
                        <property name="port_range">0</property>
                    </protocol>
                    <protocol type="MERGE3"/>
                    <protocol type="FD_SOCK"/>
                    <protocol type="FD_ALL"/>
                    <protocol type="VERIFY_SUSPECT"/>
                    <protocol type="pbcast.NAKACK2"/>
                    <protocol type="UNICAST3"/>
                    <protocol type="pbcast.STABLE"/>
                    <protocol type="pbcast.GMS"/>
                    <protocol type="MFC"/>
                    <protocol type="FRAG3"/>
                </stack>
Секция

интерфейсы и привязки сокетов: 

<interfaces>
    <interface name="management"/>
    <interface name="public">
        <nic name="eth0"/>
    </interface>
    <interface name="private">
        <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
    </interface>
</interfaces>
<socket-binding-groups>
    <socket-binding-group name="ha-sockets" default-interface="public">
        <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="jgroups-mping" interface="public" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" interface="public" port="7600"/>
        <socket-binding name="jgroups-udp" interface="public" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="modcluster" multicast-address="${jboss.modcluster.multicast.address:224.0.1.105}" multicast-port="23364"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
        [...]

Однако я вижу, что каждый узел видит себя только в журналах: 

2020-03-20 15:19:31,099 INFO  [org.jgr.pro.pbc.GMS] (ServerService Thread Pool -- 50) sso-app02.domain.tld: no members discovered after 3013 ms: creating cluster as first member
2020-03-20 15:19:31,540 INFO  [org.inf.fac.GlobalComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Infinity Minus ONE +2' 9.4.8.Final
2020-03-20 15:19:31,738 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,738 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,740 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,738 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-4) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,743 INFO  [org.inf.CLUSTER] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,743 INFO  [org.inf.CLUSTER] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,740 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-2) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,744 INFO  [org.inf.CLUSTER] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,744 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel ejb
2020-03-20 15:19:31,745 INFO  [org.inf.CLUSTER] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,746 INFO  [org.inf.CLUSTER] (MSC service thread 1-4) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,749 INFO  [org.inf.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [sso-app02.domain.tld|0] (1) [sso-app02.domain.tld]
2020-03-20 15:19:31,755 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:31,755 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-2) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:31,756 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-1) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:31,759 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:31,759 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-4) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:31,766 INFO  [org.inf.rem.tra.jgr.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is sso-app02.domain.tld, physical addresses are [0.0.0.0:7600]
2020-03-20 15:19:32,140 INFO  [org.jbo.as.clu.infinispan] (ServerService Thread Pool -- 58) WFLYCLINF0002: Started work cache from keycloak container

Я понимаю, что это довольно нормально при инициализации , но я видел в справочных журналах, что тогда наступает этап с фактическим открытием, но это никогда не происходит для меня. Я сделал захват tcpdump и могу узнать, что все узлы на самом деле обмениваются сообщениями на транспорте JGroups: 

16:01:07.005246 IP xxx.xxx.xxx.177.40777 > xxx.xxx.xxx.175.7600: Flags [P.], seq 9688:9812, ack 1, win 7300, options [nop,nop,TS val 891162487 ecr 892277147], length 124
16:01:07.005285 IP xxx.xxx.xxx.177.60549 > xxx.xxx.xxx.178.7600: Flags [P.], seq 9688:9812, ack 1, win 7300, options [nop,nop,TS val 891162487 ecr 891031881], length 124
16:01:07.005301 IP xxx.xxx.xxx.177.47940 > xxx.xxx.xxx.179.7600: Flags [P.], seq 9688:9812, ack 1, win 7300, options [nop,nop,TS val 891162487 ecr 891214170], length 124
16:01:07.005315 IP xxx.xxx.xxx.177.37887 > xxx.xxx.xxx.176.7600: Flags [P.], seq 9688:9812, ack 1, win 7300, options [nop,nop,TS val 891162487 ecr 891217862], length 124
16:01:07.005552 IP xxx.xxx.xxx.176.7600 > xxx.xxx.xxx.177.37887: Flags [.], ack 9812, win 227, options [nop,nop,TS val 891248288 ecr 891162487], length 0
16:01:07.005578 IP xxx.xxx.xxx.179.7600 > xxx.xxx.xxx.177.47940: Flags [.], ack 9812, win 227, options [nop,nop,TS val 891244595 ecr 891162487], length 0
16:01:07.005596 IP xxx.xxx.xxx.178.7600 > xxx.xxx.xxx.177.60549: Flags [.], ack 9812, win 227, options [nop,nop,TS val 891062307 ecr 891162487], length 0
16:01:07.005712 IP xxx.xxx.xxx.175.7600 > xxx.xxx.xxx.177.40777: Flags [.], ack 9812, win 227, options [nop,nop,TS val 892307573 ecr 891162487], length 0
16:01:07.421758 IP xxx.xxx.xxx.176.60201 > xxx.xxx.xxx.177.7600: Flags [S], seq 3488371276, win 29200, options [mss 1460,sackOK,TS val 891248704 ecr 0,nop,wscale 2], length 0
16:01:07.421819 IP xxx.xxx.xxx.177.7600 > xxx.xxx.xxx.176.60201: Flags [S.], seq 2995824506, ack 3488371277, win 28960, options [mss 1460,sackOK,TS val 891162904 ecr 891248704,nop,wscale 7], length 0
16:01:07.422012 IP xxx.xxx.xxx.176.60201 > xxx.xxx.xxx.177.7600: Flags [.], ack 1, win 7300, options [nop,nop,TS val 891248704 ecr 891162904], length 0
16:01:07.422103 IP xxx.xxx.xxx.176.60201 > xxx.xxx.xxx.177.7600: Flags [P.], seq 1:16, ack 1, win 7300, options [nop,nop,TS val 891248704 ecr 891162904], length 15
16:01:07.422117 IP xxx.xxx.xxx.177.7600 > xxx.xxx.xxx.176.60201: Flags [.], ack 16, win 227, options [nop,nop,TS val 891162904 ecr 891248704], length 0
16:01:07.422294 IP xxx.xxx.xxx.177.7600 > xxx.xxx.xxx.176.60201: Flags [F.], seq 1, ack 16, win 227, options [nop,nop,TS val 891162904 ecr 891248704], length 0
16:01:07.422334 IP xxx.xxx.xxx.176.60201 > xxx.xxx.xxx.177.7600: Flags [P.], seq 16:140, ack 1, win 7300, options [nop,nop,TS val 891248704 ecr 891162904], length 124
16:01:07.422363 IP xxx.xxx.xxx.177.7600 > xxx.xxx.xxx.176.60201: Flags [R], seq 2995824507, win 0, length 0
16:01:07.422475 IP xxx.xxx.xxx.176.60201 > xxx.xxx.xxx.177.7600: Flags [.], ack 2, win 7300, options [nop,nop,TS val 891248705 ecr 891162904], length 0
16:01:07.422488 IP xxx.xxx.xxx.177.7600 > xxx.xxx.xxx.176.60201: Flags [R], seq 2995824508, win 0, length 0

При рассмотрении их в wireshark я вижу, что каждая последовательность содержит имя узла. Я также установил клавишу -Djboss.node.name=[...], если это может быть причиной (на самом деле это не помогло). Я также добавил TRACE уровень отладки к средствам infinispan, но все еще не могу заставить кэши сформировать кластер.

Буду рад услышать любую идею о том, что мне не хватает.

...