第6章 多数のサイトに論理サービスを 1 つデプロイしてフェイルオーバーさせる手順
Service Interconnect を使用する一般的なシナリオは、1 つのサイトに障害が発生した場合に、他のサイトがそれ以降の要求をシームレスに処理することを目的として、2 つのサイトにサーバープロセスをデプロイすることです。このシナリオでは、プライマリーサーバーが利用可能な間はプライマリーサーバーがすべての要求に応答し、プライマリーサーバーが利用できない場合にのみトラフィックがセカンダリーサーバーに送信されます。この手順では 2 台のサーバーを説明しますが、この手法は多数のサーバーでも機能します。
前提条件
- リンクされていないサイトが 2 つ以上ある。
- Service Interconnect とそのネットワークモデルに関する基本的な理解。
手順
-
skupper initを使用してサイトを作成します。 - サーバーをさまざまなサイトにデプロイします。
最初のサイトでトークンを生成します。
$ skupper token create token.yaml
このファイルには、キーとそれを作成したサイトの場所が含まれています。
注記このファイルへのアクセスは、サービスネットワークへのアクセスを提供します。適切に保護してください。
接続元のクラスターでトークンを使用します。
最初のサイトへのリンクを作成するには以下を実行します。
$ skupper link create token.yaml --cost 99999
コストを高く設定すると、通常の状況ではトラフィックがこのサイトに送られなくなります。ただし、他に利用できるサーバーがない場合、すべてのトラフィックはこのサイトに送信されます。
両方のサイトのサービスネットワークにあるサーバーを公開します。
サービスを作成します。
$ skupper service create <name> <port>
ここでは、以下のようになります。
-
<name>- 作成するサービスの名前。 -
<port>- サービスが使用するポート。
デフォルトでは、このサービスは両方のサイトに表示されますが、このサービスへのリクエストを処理できるサーバーはありません。
注記デフォルトでは、1 つのサイトでサービスを作成すると、そのサービスはすべてのサイトで利用できるようになります。ただし、
enable-service-syncがfalseに設定されている場合は、両方のサイトでサービスを作成する必要があります。-
両方のサイトでサービスをサーバーにバインドします。
$ skupper service bind <service-name> <target-type> <target-name>
ここでは、以下のようになります。
-
<service-name>- サービスネットワーク上のサービスの名前。 -
<target-type>は、公開するオブジェクト (deployment、statefulset、pods、またはservice) です。 -
<target-name>- クラスターサービスの名前。
以下に例を示します。
$ skupper service bind hello-world-backend deployment hello-world-backend
-
- コンソールを使用してトラフィックフローをチェックしたり、ツールを使用してサービスを監視したりできます。クライアントはどちらのサイトにも接続でき、そのサイト上のサーバーはサーバーが利用できなくなるまで要求を処理します。それ以降のリクエストは他のサイトのサーバーによって処理されます。
元のサイトのサーバーが利用可能になると、それ以降のすべてのリクエストが処理されます。ただし、セカンダリーサーバーまたはバックアップサーバーへの既存の TCP 接続は、それらの TCP 接続が閉じられるまで維持されます。
