こんばんは、cloudpack の @dz_ こと大平かづみです。

Prologue - はじめに

前回「Check! Serf - インストールについて」に引き続き、Serf のドキュメントを読み進めます。

ここで読み解いた内容は、こちら「Serf はじめての運用ツール〜インストールとエージェント起動」にまとめています。
併せてご覧いただけると嬉しいです。

Serf: エージェントの起動

Serfエージェントの起動について、「Run the Agent」を読みます。

Run the Serf Agent
After Serf is installed, the agent must be run. The agent is a lightweight process that runs until told to quit and maintains cluster membership and communication. The agent must be run for every node that will be part of the cluster.

"Serfはインストールされると、エージェントを利用することができます。エージェントは軽量なプロセスで、終了を言い渡されるまでは稼働し続け、クラスタのメンバシップとコミュニケーションを管理します。このエージェントは、クラスタに属するすべてのノードで稼働しているはずです。"

It is possible to run multiple agents, and thus participate in multiple Serf clusters. For example, you may want to run a separate Serf cluster to maintain web server membership info for a load balancer from another Serf cluster that manages membership of Memcached nodes, but perhaps the web servers need to be part of the Memcached cluster too so they can be notified when Memcached nodes come online or go offline. Other examples include a Serf cluster within a datacenter, and a seperate cluster used for cross WAN gossip which has more relaxed timing.

"複数のエージェントを稼働させることも可能で、さらに複数のSerfクラスタに参加することも可能です。たとえば、Memcachedノードのメンバーシップを管理するSerfクラスタとは別に、ロードバランサーで利用するためにwebサーバ用のメンバーシップ情報を管理するSerfクラスタを起動したいとします。しかし、場合によってはwebサーバはMemcachedクラスタの一部であり、それでそれらはMemcachedノードがオンラインになったりオフラインになったことを通知することができる必要があります。他の例では、データセンター内のSerfクラスタや、より緩やかなタイミングを扱う(?) cross WAN gossip を使う分離されたクラスタがあります。"

エージェントの開始

Starting the Agent
For simplicity, we'll run a single Serf agent right now:

"わかりやすくするため、単一のSerfエージェントをさっと起動してみましょう:"

$ serf agent
==> Starting Serf agent...
==> Serf agent running!
    Node name: 'foobar'
    Bind addr: '0.0.0.0:7946'
     RPC addr: '127.0.0.1:7373'

==> Log data will now stream in as it occurs:

2013/10/21 18:57:15 [INFO] Serf agent starting
2013/10/21 18:57:15 [INFO] serf: EventMemberJoin: mitchellh.local 10.0.1.60
2013/10/21 18:57:15 [INFO] Serf agent started
2013/10/21 18:57:15 [INFO] agent: Received event: member-join

As you can see, the Serf agent has started and has output some log data. From the log data, you can see that a member has joined the cluster. This member is yourself.

"見てわかるように、Serfエージェントはいくつかのデータを出力します。このログデータからわかることは、メンバーがクラスタに参加したことがわかります。そのメンバーは自身です。"

クラスタのメンバー

Cluster Members
If you run serf members in another terminal, you can see the members of the Serf cluster. You should only see one member (yourself). We'll cover joining clusters in the next section.

"他のターミナルで serf members を実行すると、Serfくらすたのメンバー一覧を見ることができます。この段階では、1メンバーだけが見えるはずです。(あなたが稼働させているエージェント自身です)。クラスタへの参加については次のセクションで扱います。"

$ serf members
mitchellh.local    10.0.1.60    alive

This command, along with many others, communicates with a running Serf agent via an internal RPC protocol. When starting the Serf agent, you may have noticed that it tells you the "RPC addr". This is the address that commands such as serf members use to communicate with the agent.

"他と同じように、このコマンドは内部のRPCプロトコルを通じて、稼働中のSerfエージェントと通信します。Serfエージェントを開始すると、あなたは 'RPC addr' を伝える通知を受け取ります。これは serf members のようなコマンドがエージェントと通信するために使うアドレスです。"

By default, RPC listens only on loopback, so it is inaccessible outside of your machine for security reasons.

"デフォルトでは、RPCは loopback 上でのみ受け付けているので、セキュリティ上の理由であなたのマシンの外にはアクセスできません。"

If you're running multiple Serf agents, you'll have to specify an -rpc-addr to both the agent and any commands so that it doesn't collide with other agents.

"もし複数のSerfエージェントを稼働するなら、エージェントと各コマンド両方に -rpc-addr を指定しなければなりません。これによりほかのエージェントと衝突することがなくなります。"

エージェントの停止

Stopping the Agent
You can use Ctrl-C (the interrupt signal) to gracefully halt the agent. After interrupting the agent, you should see it leave the cluster gracefully and shut down.

"エージェントを正常に終了するには、Ctrl-C (割り込みシグナル) を使うことができます。エージェントに割り込みを発行すると、正常にクラスタから離脱しシャットダウンするのがわかるでしょう。"

By gracefully leaving, Serf notifies other cluster members that the node left. If you had forcibly killed the agent process, other members of the cluster would have detected that the node failed. This can be a crucial difference depending on what your use case of Serf is. Serf will automatically try to reconnect to failed nodes, which allows it to recover from certain network conditions, while left node s are no longer contacted.

正常に離脱することで、Serfはクラスタのほかのメンバーにノードが 抜ける ことを通知します。もし強制的にエージェントのプロセスを終了すると、クラスタのほかのメンバーはそのノードが 障害を起こした と検知します。これはSerfのユースケースに依存した重要な違いです。Serfは障害を起こしたノードに対して自動的に再接続を試み、ネットワーク状況から復帰してくるのを許します。これに対して、自ら離脱したノードに関してはそれ以上コンタクトをとりません。

Epilogue -　おわりに

一部、訳が怪しいです… 精進せねば…！

続けて「Join a Cluster」を読んでいきますよー！

Qiita での Serf 関連記事はこちらです。

Serf まとめ、Amazon Lambda について、こちらで記事書いているのでもしご興味あればどうぞ！

Check! Serf - エージェントの実行と終了