Реплики Кассандры на одном узле Docker-Swarm - PullRequest
Новая
       28

Реплики Кассандры на одном узле Docker-Swarm

0 голосов
/ 02 июля 2019

У меня запущен один узел менеджера docker-swarm (18.09.6), и я играю с раскруткой кластера кассандры. Я использую следующее определение, и оно работает в том, что семя / ведущий и ведомый вращаются и сообщают / копируют свои изменения данных / схемы в порядке: 

services:
  cassandra-masters:
    image: cassandra:2.2
    environment:
      - MAX_HEAP_SIZE=128m
      - HEAP_NEWSIZE=32m
      - CASSANDRA_BROADCAST_ADDRESS=cassandra-masters
    deploy:
      mode: replicated
      replicas: 1
  cassandra-slaves:
    image: cassandra:2.2
    environment:
      - MAX_HEAP_SIZE=128m
      - HEAP_NEWSIZE=32m
      - CASSANDRA_SEEDS=cassandra-masters
      - CASSANDRA_BROADCAST_ADDRESS=cassandra-slaves
    deploy:
      mode: replicated
      replicas: 1
    depends_on:
      - cassandra-masters

Когда я изменяю количество реплик с 1 на 2, либо при развертывании стека, либо в масштабе после развертывания, создается второе задание для ведомого устройства-кассандры, но постоянно происходит сбой с ошибкой, указывающей, что он не может сплетничать с начальным узлом : 

INFO  10:51:03 Loading persisted ring state
INFO  10:51:03 Starting Messaging Service on /10.10.0.200:7000 (eth0
INFO  10:51:03 Handshaking version with cassandra-masters/10.10.0.142
Exception (java.lang.RuntimeException) encountered during startup: Unable to gossip with any seeds
java.lang.RuntimeException: Unable to gossip with any seeds
    at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1360)
    at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:521)
    at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:756)
    at org.apache.cassandra.service.StorageService.initServer(StorageService.java:676)
    at org.apache.cassandra.service.StorageService.initServer(StorageService.java:562)
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:310)
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:548)
    at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:657)
ERROR 10:51:34 Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
    at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1360) ~[apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:521) ~[apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:756) ~[apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.StorageService.initServer(StorageService.java:676) ~[apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.StorageService.initServer(StorageService.java:562) ~[apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:310) [apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:548) [apache-cassandra-2.2.14.jar:2.2.14]
    at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:657) [apache-cassandra-2.2.14.jar:2.2.14]

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

РЕДАКТИРОВАТЬ: Я раскрутил один и тот же стек на два узла роя, и я вижу то же поведение, то есть, когда я масштабируюсь до второй "подчиненной" задачи, она не удается с той же ошибка, поэтому проблема не заключается в попытке запустить две задачи на одном узле.

1 Ответ

0 голосов
/ 05 июля 2019

Я не дошел до сути, почему сплетни терпят неудачу, но в конечном итоге мы согласовали стратегию развертывания производства, в которой нам не требовалось автоматическое масштабирование, и вместо этого мы должны были планировать емкость, основываясь на поведении системы и ожидаемом трафике.Этот ответ также указывает на дополнительную нагрузку, которую автоматическое масштабирование может добавить к уже растянутой системе: AWS и автоматическое масштабирование Кассандра

...