Узлы кластера Infinispan видят только себя, а не другие экземпляры, работающие в узлах Kubernetes - PullRequest
Новая
       137

Узлы кластера Infinispan видят только себя, а не другие экземпляры, работающие в узлах Kubernetes

0 голосов
/ 11 февраля 2019

Я пытаюсь настроить кэш с бесконечным временем хранения в своем приложении, которое работает на нескольких узлах на google-cloud-platform с Kubernetes и Docker.

Каждый из этих кэшей должен делиться своими данными с другими цепочками узлов, чтобы ониу всех одинаковые данные.

Моя проблема в том, что конфигурация JGroups не работает так, как я хочу, и узлы не видят своих братьев и сестер.

Я пыталсянесколько конфигураций, но узлы всегда видят себя и не создают кластер с другими.

Я пробовал некоторые конфигурации из примеров GitHub, таких как https://github.com/jgroups-extras/jgroups-kubernetes или https://github.com/infinispan/infinispan-simple-tutorials

Вот мой jgroups.xml 

<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-4.0.xsd">

    <TCP bind_addr="${jgroups.tcp.address:127.0.0.1}"
         bind_port="${jgroups.tcp.port:7800}"
         enable_diagnostics="false"
         thread_naming_pattern="pl"
         send_buf_size="640k"
         sock_conn_timeout="300"
         bundler_type="no-bundler"
         logical_addr_cache_expiration="360000"

         thread_pool.min_threads="${jgroups.thread_pool.min_threads:0}"
         thread_pool.max_threads="${jgroups.thread_pool.max_threads:200}"
         thread_pool.keep_alive_time="60000"
    />
    <org.jgroups.protocols.kubernetes.KUBE_PING
        port_range="1"
        namespace="${KUBERNETES_NAMESPACE:myGoogleCloudPlatformNamespace}"
    />
    <MERGE3 min_interval="10000"
            max_interval="30000"
    />
    <FD_SOCK />
    <!-- Suspect node `timeout` to `timeout + timeout_check_interval` millis after the last heartbeat -->
    <FD_ALL timeout="10000"
            interval="2000"
            timeout_check_interval="1000"
    />
    <VERIFY_SUSPECT timeout="1000"/>
    <pbcast.NAKACK2 xmit_interval="100"
                    xmit_table_num_rows="50"
                    xmit_table_msgs_per_row="1024"
                    xmit_table_max_compaction_time="30000"
                    resend_last_seqno="true"
    />
    <UNICAST3 xmit_interval="100"
              xmit_table_num_rows="50"
              xmit_table_msgs_per_row="1024"
              xmit_table_max_compaction_time="30000"
    />
    <pbcast.STABLE stability_delay="500"
                   desired_avg_gossip="5000"
                   max_bytes="1M"
    />
    <pbcast.GMS print_local_addr="false"
                join_timeout="${jgroups.join_timeout:5000}"
    />
    <MFC max_credits="2m"
         min_threshold="0.40"
    />
    <FRAG3 frag_size="8000"/>
</config>

И как я инициализирую Infinispan Cache (Kotlin) 

import org.infinispan.configuration.cache.CacheMode
import org.infinispan.configuration.cache.ConfigurationBuilder
import org.infinispan.configuration.global.GlobalConfigurationBuilder
import org.infinispan.manager.DefaultCacheManager
import java.util.concurrent.TimeUnit

class MyCache<V : Any>(private val cacheName: String) {

    companion object {
        private var cacheManager = DefaultCacheManager(
            GlobalConfigurationBuilder()
                .transport().defaultTransport()
                .addProperty("configurationFile", "jgroups.xml")
                .build()
        )
    }

    private val backingCache = buildCache()

    private fun buildCache(): org.infinispan.Cache<CacheKey, V> {
        val cacheConfiguration = ConfigurationBuilder()
            .expiration().lifespan(8, TimeUnit.HOURS)
            .clustering().cacheMode(CacheMode.REPL_ASYNC)
            .build()
        cacheManager.defineConfiguration(this.cacheName, cacheConfiguration)
        log.info("Started cache with name $cacheName. Found cluster members are ${cacheManager.clusterMembers}")
        return cacheManager.getCache(this.cacheName)
    }
}

Вот что говорит логи 

INFO  o.i.r.t.jgroups.JGroupsTransport - ISPN000078: Starting JGroups channel ISPN
INFO  o.j.protocols.kubernetes.KUBE_PING - namespace myNamespace set; clustering enabled
INFO  org.infinispan.CLUSTER - ISPN000094: Received new cluster view for channel ISPN: [myNamespace-7d878d4c7b-cks6n-57621|0] (1) [myNamespace-7d878d4c7b-cks6n-57621]
INFO  o.i.r.t.jgroups.JGroupsTransport - ISPN000079: Channel ISPN local address is myNamespace-7d878d4c7b-cks6n-57621, physical addresses are [127.0.0.1:7800]

Iожидать, что при запуске новый узел найдет уже существующие и получит от них дату.

В настоящее время при запуске каждый узел видит только себя и ничего не передается

Ответы [ 2 ]

0 голосов
/ 13 февраля 2019

Кроме того, bind_addr установлен в 127.0.0.1.Это означает, что участники на разных хостах не смогут найти друг друга.Я предлагаю установить bind_addr, например, <TCP bind_addr="site_local".../>.

Подробнее см. [1].

[1] http://www.jgroups.org/manual4/index.html#Transport

0 голосов
/ 12 февраля 2019

Обычно первым делом, когда вам нужна помощь с JGroups / Infinispan, является настройка ведения журнала на уровне трассировки.

Проблема с KUBE_PING может заключаться в том, что модуль не работает под надлежащим счетом обслуживания, и поэтому он делаетне имеют токена авторизации для доступа к Kubernetes Master API.Вот почему в настоящее время предпочтительным способом является использование DNS_PING и регистрация безголовой службы .См. этот пример .

...