Миграция с Kafka на Raft¶
Важно: этот документ подразумевает хорошее владение конфигурационными транзакциями. Не совершайте миграцию, если вы еще не ознакомились с туториалом Добавление организации в канал.
Для проведения миграции версия узлов должна быть 1.4.2 или выше.
До проведения миграции, учтите следущее:
- Этот процесс работает только при миграции с Kafka на Raft, другие типы консенсуса пока не поддерживаются.
- Миграция односторонняя. Как только Raft-узлы начнут сохранять транзакции, обратно к Kafka не вернуться.
- Ордеринг-узлы придется перезапустить.
- Восстановление после неудачной миграции возможно, только если был сделан бекап (как его сделать, описано ниже).
- Должны быть обновлены все каналы сети. Миграция только подмножества каналов не возможна.
- В конце миграции, каждый канал (включая системный) будет иметь одинаковый набор consenter“ов Raft-узлов. Это один из признаков успешной миграции.
- Миграция использует существующие реестры и узлы. Исключние или добавление ордерер-узлов должно быть проведено после миграции.
Краткое описание процесса миграции¶
Миграция проводится в 5 шагов:
- Система начинает работу в режиме тех. обслуживания, все транзакции приложений отклоняются и только администраторы ордеринг-службы могут делать изменения конфигурации.
- Система останавливается и создается бекап.
- Система запускается, тип консенсуса и метаданные всех каналов были изменены.
- Система перезапускается и теперь работает с Raft-консенсусом. Каждый канал проверяется на достижение консенсуса.
- Система начинает работу в нормальном режиме.
Подготовка к миграции¶
До начала миграции, сделайте следующее:
- Составьте план развертывания Raft. Выберите, какие узлы продолжат работу после миграции как Raft consenters. Вы должны развернуть зотя бы три узла в кластере, но лучше разверните 5 или больше; так, кластер не потеряет работоспособность при остановке узла.
- Соберите материал для создания конфигурации Raft
Metadata
. Важно: все каналы должны получить одну и ту же конфигурациюMetadata
. Обратитесь к Инструкции по настройке Raft за подробной информацией. Возможно, вам будет проще сначала запустить сеть с протоколом Raft, а потом изменить и скопировать секцию consensus metadata конфигурации сети. В любом случае, для каждого узла вам потребуются:hostname
port
server certificate
client certificate
- Составьте список всех каналов сети. Проверьте, что вы имеете право подписывать конфигурационные транзакции.
- Убедитесь, что все ордеринг-узлы имеют одну и ту же версию Fabric, и что она 1.4.2 или выше.
- Убедитесь, что все пиры имеют версию 1.4.2 и выше. Проверьте, что все каналы имеют
подходящую channel capability:
- Orderer capability
V1_4_2
(или выше). - Channel capability
V1_4_2
(или выше).
- Orderer capability
Вхождение в режим тех. обслуживания¶
До того, как вы ввели сеть в решим тех. обслуживания, рекомендуется выключить всех пиров и клиентов. В принципе можно и не выключать, так как ордеринг-служба отклонит всех их запросы, но их логи засорятся сообщениями об ошибках.
Следуйте туториалу Добавление организации в канал,
чтобы изменить конфигурацию каждого канала, начиная с системного.
Единственное поле, которое потребуется изменить на этом шаге, это
/Channel/Orderer/ConsensusType
.
В JSON-представлении конфигурации канала, это
.channel_group.groups.Orderer.values.ConsensusType
.
ConsensusType
состоит из трех значений: Type
, Metadata
, and
State
, where:
Type
- либоkafka
, либоetcdraft
(Raft). Это значение может быть изменено только в режиме тех. обслуживания.Metadata
пустое, еслиType
это kafka, но должно быть заполнено корректными метаданными Raft, еслиConsensusType
этоetcdraft
. Про них речь пойдет позже.State
- либоSTATE_NORMAL
, когда канал обрабатывает транзакции, илиSTATE_MAINTENANCE
(во время миграции).
Первый шаг - изменить State
с STATE_NORMAL
на STATE_MAINTENANCE
. Пока что не изменяйте Type
или Metadata
.
На этом шаге Type
должен быть kafka
.
В режиме тех. обслуживания обычные транзакции, конфигурационные обновления, не связанные с миграцией,
Deliver
-запросы от пиров для получения блоков - все отклоняются (за исключением того, что администраторы
могут создавать Deliver
-запросы, это необходимо в процессе миграции).
Это сделано для того, чтобы не нужно было создавать бекап (и при необходимости восстанавливать с него) пиров,
так как они начнут получать обновления только после миграции.
Проверьте, что каждый ордеринг-узел вошел в режим тех.обслуживания на каждом канале, для
этого извлеките последний конфигурационный блок и проверьте, что Type
, State
каждого канала - это kafka
STATE_MAINTENANCE
, а
поле Metadata
пустое.
Создание бекапа и остановка серверов¶
Сначала остановите все ордеринг-узлы, Kafka- и Zookeeper-серверы. Затем, после того, как вы разрешите Kafka-службе сохранить ее логи на диск (это обычно занимает порядка 30 секунд), Kafka-серверы должны выключится. Если вы сейчас остановите еще и Kafka-брокеров, это может привести к тому, что ордереры имеют состояние в файловой системе новее, чем Kafka-брокеры, что может не дать потом запустить сеть.
Создайте бекапы файловой системы этих серверов. Перезагрузите Kafka-службу и потом ордеринг-узлы.
Переход к Raft¶
Следущий шаг - еще одно обновление конфигурации каждого канала. В этом обновлении,
поменяйте Type
на etcdraft
, но сохраните State
как STATE_MAINTENANCE
и заполните поле
Metadata
. Крайне рекомендуется иметь одинаковую Metadata
во всех каналах. Если вы хотите
иметь разные consenter sets с разными узлами, вы сможете перенастроить Metadata
после запуска сети в режиме
etcdraft
. Одинаковая Metadata
означает, что если системный канал пришел к консенсусу и может выйти из режима тех.обслуживания,
все остальные каналы смогут тоже.
Проверьте, что каждый ордеринг-узел сохранил новый ConsensusType
, проверив конфигурацию каждого канала.
Обратите внимание: Для каждого канала, транзакция, изменяющая ConsensusType
должна быть последней конфигурационной транзакцией
перед тем, как вы перезагрузите узлы на следующем шагу. В противном случае, скорее всего, узлы упадут при перезагрузке.
Перезагрузка и проверка лидера¶
Обратите внимание: выходить из режима тех.обслуживания необходимо после перезагрузки.
Остановите все ордеринг-узлы, Kafka-брокеры и Zookeepers, а потом запустите только ордеринг-узлы. Они должны запустится как Raft-узлы, сформировать кластер на каждый канал и выбрать лидера в каждом канале.
Внимание: Так как Raft использует TLS, необходмима дополнительняа настройка перед тем, как возможно будет запустить узлы - подробная информация.
После этого, проверьте в логах, что на каждом канале был выбран лидер. Это подтвердит, что процесс был завершен успешно.
Когда лидер выбран, логи покажут:
"Raft leader changed: 0 -> node-number channel=channel-name
node=node-number "
Пример:
2019-05-26 10:07:44.075 UTC [orderer.consensus.etcdraft] serveRequest ->
INFO 047 Raft leader changed: 0 -> 1 channel=testchannel1 node=2
В этом примере node 2
сообщает, что был выбран лидер (лидер -
node 1
) кластером канал testchannel1
.
Выход из режима тех.обслуживания¶
Выполните еще одно обновление конфигурации на каждом канале (посылайте обновления
тому же узлу, которому посылали раньше), изменяющее State
с STATE_MAINTENANCE
на STATE_NORMAL
.
Как обычно, начните с системного канала. Если обновление прошло успешно на нем, на всех остальных
должно тоже. Проверьте на каждом узле, что в последнем конфигурационном блоке
State
теперь STATE_NORMAL
.
Теперь ордеринг-служба готова принимать транзакции на всех каналах. Если вы остановили пиры и приложения (как рекомендовалось), вы можете сейчас запустить их.
Откат¶
Если во время миграции до выхода из режима тех.обслуживания возникает проблема, просто выполните процедуру отката:
- Остановите ордеринг-узлы и Kafka-службу (ансамбль серверов и Zookeeper).
- Откатите файловую систему этих серверов с помощью бекапа, сделанного в режиме тех.обслуживания до обновления
ConsensusType
. - Перезапустите эти серверы, ордеринг-службы запустятся с Kafka в режиме тех.обслуживания.
- Обновите конфигурацию, чтобы выйти из режима тех.обслуживания и продолжить использовать Kafka в качестве механизма консенсуса, или продолжите выполнять инструкцию и решите проблемы.
Тревожные звоночки:
- Некоторые узлы падают или самопроизвольно останавливаются.
- В логах канала нет записи о выборе лидера.
- Не получается вернуться к
STATE_NORMAL
.