# Migrating from Kafka to Raft

**注: このドキュメントは、チャネルコンフィギュレーション更新トランザクションに関する高度な専門知識を前提としています。
移行プロセスには複数のチャネルコンフィギュレーション更新トランザクションが含まれるため、チャネル更新プロセスを詳細に説明したチュートリアル[Add an Organization to a Channel](channel_update_tutorial.html) に習熟しない限り、KafkaからRaftへの移行を試みないようにしてください**。

Kafkaベースのオーダリングサービスから[Raftベース](./orderer/ordering_service.html#Raft)のオーダリングサービスへ移行したいユーザーのために、v1.4.2以降のノードでは、ネットワーク内の各チャネルで一連のコンフィギュレーション更新トランザクションを通じて、移行を行うことができます。

このチュートリアルでは、各コマンドの詳細を示すのではなく、このプロセスをハイレベルで説明し、必要に応じて具体的な詳細を示します。

## Assumptions and considerations

移行を試みる前に、以下の点に注意してください。

1. このプロセスは、KafkaからRaftへの移行にのみ使用されます。
他のOrdererコンセンサスタイプ間の移行は、現時点でサポートされていません。

2. 移行は一方通行です。
オーダリングサービスがRaftに移行され、トランザクションのコミットを開始すると、Kafkaに戻ることはできません。

3. オーダリングノードの停止と再起動が必要なので、移行中のダウンタイムを許容する必要があります。

4. 移行の失敗から回復するためには、このドキュメントで後ほど説明するように、移行開始の時点でバックアップを取る必要があります。
バックアップを取らずに移行に失敗した場合、以前の状態を回復することはできません。

5. 全てのチャネルを同じメンテナンス期間中に移行する必要があります。
一部のチャネルだけを移行して運用を再開することはできません。

6. 移行プロセスの終了時に、全てのチャネルはRaftノードの同じ同意者セットを持つことになります。
これは、オーダリングサービスのシステムチャネルに存在する同意者セットと同じものです。
これにより、移行が成功したかどうかを診断できます。

7. 移行は、デプロイされたオーダリングノードの既存の台帳を利用して、その場で行われます。
Ordererの追加と削除は移行後に行う必要があります。

## High level migration flow

移行は5つのフェーズで実行されます。

1. システムがメンテナンスモードになり、アプリケーションのトランザクションが拒否され、
オーダリングサービスの管理者のみがチャネル設定を変更できます。
2. システムを停止し、移行中のエラー発生に備えて、バックアップを取得します。
3. システムを起動し、各チャネルのコンセンサスタイプとメタデータを変更します。
4. システムを再起動し、Raftコンセンサスで動かします。
各チャネルは定足数を正常に達成したことをチェックします。
5. システムがメンテナンスモードから抜けて、通常の機能が再開されます。

## Preparing to migrate

移行を試みる前に、いくつかのステップを踏む必要があります。

* Raftのデプロイを設計し、どのオーダリングサービスノードをRaftの同意者として残すかを決定します。
クラスタに少なくとも3つのオーダリングノードをデプロイする必要がありますが、
少なくとも5つのノードの同意者セットをデプロイすると、1つのノードが停止した場合でも高可用性を維持できます。
3つのノード構成では、何らかの理由(たとえば、メンテナンス期間中)で1つのノードが停止した時点で高可用性が失われることに注意してください。
* Raftの `Metadata` 設定を構築するための素材を準備します。
**注: すべてのチャネルは同じRaft `Metadata` 設定を受け取る必要があります**。
これらのフィールドの詳細については、[Raft configuration guide](raft_configuration.html) を参照してください。
注: Raftコンセンサスプロトコルで新しいオーダリングネットワークをブートストラップし、その設定からコンセンサスメタデータセクションをコピーして変更するのが最も簡単かもしれません。
いずれにせよ、以下のものが(オーダリングノードごとに)必要です。
  - `hostname`
  - `port`
  - `server certificate`
  - `client certificate`
* システム内の全チャネル(システムおよびアプリケーション)のリストを作ります。
設定の更新に署名するための正しい資格情報を持っていることを確認します。
例えば、関連するオーダリングサービスの管理者アイデンティティなどです。
* 全てのオーダリングサービスノードが同じバージョンのFabricを実行していること、そのバージョンがv1.4.2以上であることを確認します。
* 全てのピアがFabric v1.4.2以上を実行していることを確認します。
全チャネルに、移行を可能にするチャネルケーパビリティが設定されていることを確認します。
  - Orderer capability `V1_4_2` (または、それ以上)
  - Channel capability `V1_4_2` (または、それ以上)

### Entry to maintenance mode

オーダリングサービスをメンテナンスモードに設定する前に、ネットワークのピアとクライアントを停止することを推奨します。
ピアやクライアントを稼働させたままにしておくことは安全ですが、オーダリングサービスはそれらの要求をすべて拒否するため、ログが無害なのに誤解を招くような失敗で埋め尽くされます。

[Add an Organization to a Channel](channel_update_tutorial.html) チュートリアルの手順に従って、 **システムチャネルから始めて、各チャネル** の設定を取得、変換、制限します。
このステップで変更する必要があるのは、チャネル設定の `/Channel/Orderer/ConsensusType` フィールドだけです。
チャネル設定のJSON表現では、 `.channel_group.groups.Orderer.values.ConsensusType` となります。

`ConsensusType` は、 `Type` 、 `Metadata` 、 `State` という3つの値で表されます。

  * `Type` は `kafka` または `etcdraft` (Raft)です。
  この値はメンテナンスモードの間にだけ変更できます。
  * `Metadata` は `Type` がkafkaの場合、空白です。
    `ConsensusType` が `etcdraft` の場合、正当なRaftメタデータを設定する必要があります。
    詳しくは下記を参照してください。
  * `State` は、チャネルがトランザクションを処理しているときは `STATE_NORMAL` であり、
    移行中は `STATE_MAINTENANCE` です。

チャネル設定のアップデートで最初のステップは、 `State` を `STATE_NORMAL` から `STATE_MAINTENANCE` に変更するだけです。
`Type` と `Metadata` フィールドは、まだ変更しないでください。
`Type` は現在 `kafka` であることに注意してください。

メンテナンスモードでは、通常のトランザクション、移行とは関係のない設定の更新、新しいブロックを取得するためのピアからの `Deliver` リクエストは拒否されます。
これは、移行中にピアのバックアップと、必要であればリストアの両方が必要になるのを防ぐために行われます。
ピアは、移行が正常に完了すると更新を受け取ります。
要するに、次のステップであるオーダリングサービスのバックアップポイントをピアの台帳より先に保持し、必要に応じてロールバックできるようにしたいのです。
一方で、オーダリングノードの管理者は `Deliver` リクエストを発行できます(移行プロセスを継続するために、この操作が必要です)。

**確認** それぞれのオーダリングサービスノードが、各チャネルでメンテナンスモードに入ったことを確認します。
確認方法は、最後のコンフィグレーションブロックを取得して、各チャネルの `Type` 、 `Metadata` 、 `State` がそれぞれ `kafka` 、空白(Kafka にはメタデータがないことを思い出してください)、 `STATE_MAINTENANCE` であることを確認することです。

チャネルが正常に更新されると、オーダリングサービスはバックアップの準備が整います。

#### Backup files and shut down servers

全てのオーダリングノード、Kafkaサーバー、Zookeeperサーバーをシャットダウンします。
**最初にオーダリングサービスノードをシャットダウンする** ことが重要です。
次に、Kafka サービスがログをディスクに書き出すのを待ってから(これは通常約30秒かかりますが、システムによってはそれ以上かかる場合があります)、Kafkaサーバーをシャットダウンする必要があります。
KafkaブローカーをOrdererと同時にシャットダウンすると、Ordererのファイルシステムの状態がKafkaブローカーよりも新しくなり、ネットワークが起動しなくなる可能性があります。

これらのサーバーのファイルシステムのバックアップを作成します。
その後、Kafkaサービス、次にオーダリングサービスノードという順番で再起動します。

### Switch to Raft in maintenance mode

移行プロセスの次のステップは、各チャネルの設定を更新することです。
この更新では、`Type` を `etcdraft` (Raft 用) に切り替え、`State` を `STATE_MAINTENANCE` に維持し、`Metadata` 設定を記入します。
`Metadata` の設定は、全チャネルで揃えることを強く推奨します。
もし、異なるノードで異なる同意者セットを立ち上げたい場合、システムを `etcdraft` モードで再起動した後に `Metadata` 設定を再設定できます。
同一のメタデータオブジェクト、つまり同一の同意者セットを供給することは、ノードが再起動したとき、システムチャネルが充足数を満たしてメンテナンスモードを抜けることができれば、他のチャネルも同じことができる可能性が高いことを意味します。
各チャネルに異なる同意者セットを供給すると、あるチャネルはクラスタの形成に成功し、別のチャネルは失敗する可能性があります。

次に、各チャネルのコンフィグレーションをプルして検査することで、各オーダリングサービスノードが `ConsensusType` のコンフィグレーションの更新をコミットしたことを確認します。

注: 各チャネルにおいて、 `ConsensusType` を変更するトランザクションは、(次のステップで)ノードを再起動する前の最後のコンフィグレーショントランザクションである必要があります。
このステップの後に他のコンフィギュレーショントランザクションが発生した場合、ノードの再起動時にクラッシュするか、未定義の動作になる可能性が高くなります。

#### Restart and validate leader

注: メンテナンスモードの終了は、**必ず** 再起動の **後** に行ってください。

各チャネルで `ConsensusType` の更新が完了したら、すべてのオーダリングサービスノードを停止し、すべての KafkaブローカーとZookeeperを停止して、オーダリングサービスノードだけを再起動します。
このとき、Raftノードとして再起動し、チャネルごとにクラスタを構成し、チャネルごとにリーダーを選出する必要があります。

**注**: Raftベースのオーダリングサービスは、オーダリングノード間の認証にクライアントとサーバのTLS証明書を使用するため、再起動の前に**追加の設定**が必要です。
詳細は [Section: Local Configuration](raft_configuration.html#local-configuration) を参照して下さい。

再起動が完了したら、ノードのログを見て、各チャネルでリーダーが選出されたことを **確認** してください(何を確認すべきかは、下記を参照してください)。
これにより、プロセスが正常に完了したことを確認できます。

リーダーが選出されると、各チャネルのログに以下のように表示されます。

```
"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
```

この例では、 `testchannel1` チャネルのクラスタでリーダーが選出されたこと(リーダーは `node 1` です)を `node 2` がレポートしています。

### Switch out of maintenance mode

各チャネルのコンフィギュレーションアップデートを再度行い(コンフィギュレーションアップデートの送信先は、今までと同じオーダリングノード)、 `State` を `STATE_MAINTENANCE` から `STATE_NORMAL` へと切り替えます。
いつも通り、システムチャネルから開始します。
システムチャネルで成功すれば、全チャネルで移行が成功しているでしょう。
検証のために、オーダリングノードからシステムチャネルの最後のコンフィグレーションブロックを取得し、`State` が `STATE_NORMAL` になっていることを確認します。
完全を期すために、それぞれのオーダリングノードでこれを検証します。

このプロセスが完了すると、オーダリングサービスは全チャネルの全てのトランザクションを受け付けることができます。
推奨したようにピアとアプリケーションを停止した場合は、再起動できます。

## Abort and rollback

**メンテナンスモードを終了する前に** 移行作業中の問題が発生した場合、以下のロールバック手順を実行するだけです。

1. オーダリングノードとKafkaサービス(サーバーとZookeeperアンサンブル)をシャットダウンします。
2. これらのサーバーのファイルシステムを、 `ConsensusType` を変更する前のメンテナンスモード時のバックアップにロールバックします。
3. サーバーを再起動し、メンテナンスモードでKafkaを起動します。
4. コンセンサスメカニズムとしてKafkaを使用し続けるために、メンテナンスモードを終了するコンフィグレーション更新を送信します。または、バックアップ時点から処理を再開し、Raftの充足数の形成を妨げたエラーを修正し、修正したRaftの `Metadata` 設定で移行を再試行します。

移行が失敗した可能性があることを示す状態がいくつかあります。

1. 一部のノードがクラッシュまたはシャットダウンしています。
2. ログにチャネルごとのリーダー選出が成功したという記録がありません。
3. システムチャネルで `STATE_NORMAL` モードに切り替えることに失敗します。

<!--- Licensed under Creative Commons Attribution 4.0 International License
https://creativecommons.org/licenses/by/4.0/) -->