Отключение от заказов в приложении Hyperledger Fabric - PullRequest
0 голосов
/ 08 октября 2018

У нас есть приложение Hyperledger.Основное приложение размещено на виртуальных машинах AWS, а DR - на виртуальных машинах Azure.Недавно группа Microsoft обнаружила, что одна из виртуальных машин DR стала недоступной, а доступность была восстановлена ​​примерно через 8 минут.Согласно Microsoft «Это неожиданное событие было вызвано действием автоматического восстановления, инициированным Azure. Действие автоматического восстановления было вызвано аппаратной проблемой на физическом узле, где размещалась виртуальная машина. Как и планировалось, ваша виртуальная машина была автоматически перемещена вдругой и здоровый физический узел, чтобы избежать дальнейшего воздействия ".Виртуальная машина Zookeeper также была повторно развернута в тот же момент

. На следующий день после того, как произошло это событие, мы начали замечать, что заказчик отключается и сразу же включается через несколько секунд.Такое отключение / подключение происходит регулярно после перерыва в 12 часов и 10 минут.

Мы заметили две вещи

В журнале мы получаем

 - [orderer/consensus/kafka] startThread -> CRIT 24df#033[0m [channel:
   testchainid] Cannot set up channel consumer = kafka server: The
   requested offset is outside the range of offsets maintained by the
   server for the given topic/partition.
 - panic: [channel: testchainid] Cannot set up channel consumer = kafka
   server: The requested offset is outside the range of offsets
   maintained by the server for the given topic/partition.
 - goroutine 52 [running]:
 - github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4202748a0,
   0x108dede, 0x31, 0xc420327540, 0x2, 0x2)
 - /w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194
   +0x134
 - github.com/hyperledger/fabric/orderer/consensus/kafka.startThread(0xc42022cdc0)
 - /w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/orderer/consensus/kafka/chain.go:261
   +0xb33
 - created by
   github.com/hyperledger/fabric/orderer/consensus/kafka.(*chainImpl).Start
 - /w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/orderer/consensus/kafka/chain.go:126
   +0x3f

Еще одна вещь, которую мы заметили, заключается в том, что в журналах до события сбоя виртуальной машины было 3брокеры кафки, но мы можем видеть только 2 брокеров кафки в журналах после этого события.

Кто-нибудь может мне помочь в этом?Как решить эту проблему?

Дополнительная информация - Мы просмотрели журналы Kafka за день, после которого виртуальная машина была повторно развернута, и мы заметили следующее

org.apache.kafka.common.network.InvalidReceiveException: Invalid receive (size = 1195725856 larger than 104857600)
at org.apache.kafka.common.network.NetworkReceive.readFromReadableChannel(NetworkReceive.java:132)
at org.apache.kafka.common.network.NetworkReceive.readFrom(NetworkReceive.java:93)
at org.apache.kafka.common.network.KafkaChannel.receive(KafkaChannel.java:231)
at org.apache.kafka.common.network.KafkaChannel.read(KafkaChannel.java:192)
at org.apache.kafka.common.network.Selector.attemptRead(Selector.java:528)
at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:469)
at org.apache.kafka.common.network.Selector.poll(Selector.java:398)
at kafka.network.Processor.poll(SocketServer.scala:535)
at kafka.network.Processor.run(SocketServer.scala:452)
at java.lang.Thread.run(Thread.java:748)

1 Ответ

0 голосов
/ 16 октября 2018

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

...