Serfを試してみました。

投稿者: 技術スタッフ
非集中型のクラスタ管理ツールのSerfを触ってみました。クラスタ管理というと何かいろいろ大変そうなイメージですが、Serfを利用すると簡単にサーバの死活監視や情報の収集が可能になります。

Serfについて

Serfの本家サイト:https://www.serfdom.io/

Serf is a decentralized solution for cluster membership, failure detection,and orchestration. Lightweght and highly available.

本家のサイトのトップページに書かれているようにserfは軽量で高可用性の非集中型のクラスタ管理ツールです。
  • インストールは簡単。
    •  serfの静的バイナリを各サーバにコピーするだけOK。
  • マスターサーバのような全体を管理しているノードはない
    • 全てのノードで実行されているserfは平等。
  • ゴシッププロトコルを利用したノード間のメッセージングツール
    • ノード間でお互いに通信して情報を全体に伝播させる。
  • 各ノードで実行されているserf agent が情報のやりとりをする。
    • クラスタ内のノードの増減についてのイベント
    • クラスタ内のノードの生死についてのイベント
    • ユーザ独自のイベントを通知することも可能
  • イベントをトリガにして任意の処理(スクリプト)を実行できる。
    • これによっていろいろ応用が効くようになる。

    例えば、クラスタ内のノードの死活監視やノードが追加/停止したときに自動でロードバランサの設定(バランス先)を変更するなどの使い方が考えられます。
    また複数のアプリケーションを組み合わせて利用する場合に全体の統制をとるのに利用できます。元々そのような管理の仕組みのないアプリケーションの組み合わせでも全体を統制するような仕組みを構築できます。

      インストール

      公式サイトに(静的)バイナリで配布されているのでそれをダウンロードしてきて展開し適当なパスにコピーすればOKです。今回は/usr/local/binに置く事にしました。

      # wget https://releases.hashicorp.com/serf/0.6.4/serf_0.6.4_linux_amd64.zip
      # unzip  0.6.4_linux_amd64.zip
      # cp serf /usr/local/bin

      Serfではこの基本的にserfコマンドのみを利用し、serf <コマンド名> [ 引数 ...]という形式で複数の機能を実行します。

      実行方法

      今回はVagrant+Virtualboxの仮想環境で検証していますが、実マシンはもちろんコンテナ環境でも問題ないです。とりあえず、debian01,debian02という名前の2つの仮想サーバを立ち上げます。サーバのアドレスは次のようになっています。
      debian01 : 192.168.0.101
      debian02 : 192.168.0.102
      debian03 : 192.168.0.103　(後ほど出てきます)
      まだ以下のログでサーバ毎の時間がずれていますが気にしないでください(すみません)

      まずそれぞれの仮想サーバでserf agentを実行します。コマンドはそのまま実行するとforegroundでの実行になります。今回はログをそのまま表示するためにforegroundで実行していますが、実際に利用する場合はbackgroundでの実行になると思います。

      debian01上で

      root@debian01:# serf agent -node=debian01 -bind=192.168.0.101
      ==> Starting Serf agent...
      ==> Starting Serf agent RPC...
      ==> Serf agent running!
               Node name: 'debian01'
               Bind addr: '192.168.0.101:7946'
                RPC addr: '127.0.0.1:7373'
               Encrypted: false
                Snapshot: false
                 Profile: lan

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

          2015/12/02 10:15:41 [INFO] agent: Serf agent starting
          2015/12/02 10:15:41 [INFO] serf: EventMemberJoin: debian01 192.168.0.101
          2015/12/02 10:15:42 [INFO] agent: Received event: member-join

      同様なことをdebian02上でも実行します。

       

      ノードのクラスタへの参加

      agentを実行した段階ではまだお互いに"自分のクラスタ"に属しているだけの状態です。それぞれのサーバでメンバーを確認してみると自分自身しかいません。

      root@debian01:~# serf members
      debian01  192.168.0.101:7946  alive

      root@debian02:~# serf members
      debian02  192.168.0.102:7946  alive

      どちらかのノードをもう片方のクラスタに参加させることにより同じクラスタに属して通信が可能な状態になります。debian02をdebian01のクラスタに参加させてみます。このことはdebian01をdebian02のクラスタに参加させることと同じです。debian02には自分のクラスタにdebian01が参加したというイベントが通知されます。

      root@debian02:~# serf join 192.168.0.101
      Successfully joined cluster by contacting 1 nodes.
      root@debian02:~# serf members
      debian02  192.168.0.102:7946  alive 
      debian01  192.168.0.101:7946  alive

      debian01上で確認してみてもdebian02が参加していることがわかります。

      root@debian01:~# serf members
      debian01  192.168.0.101:7946  alive 
      debian02  192.168.0.102:7946  alive

      またそれぞれのノードにノードが追加されたことが通知されています。
      debian01側

      2015/12/02 10:43:49 [INFO] serf: EventMemberJoin: debian02 192.168.0.102
      2015/12/02 10:43:50 [INFO] agent: Received event: member-join

      debian02側

      2015/12/02 10:39:16 [INFO] serf: EventMemberJoin: debian01 192.168.0.101
      2015/12/02 10:39:16 [INFO] agent: joined: 1 nodes
      2015/12/02 10:39:17 [INFO] agent: Received event: member-join
      さらにクラスタにノードを追加する場合にはノードのいずれかのメンバのクラスタに追加すればOKです。例えば3番目のノードdebian03立ち上げてをdebian02のクラスタに参加させてみましょう。次のようにserf agentの起動時にノードを指定して同時にjoinすることも可能です。

      debian03上で

      root@debian03:~# serf agent --node=debian03 --bind=192.168.0.103 --join=192.168.0.102
      ==> Starting Serf agent...
      ==> Starting Serf agent RPC...
      ==> Serf agent running!
               Node name: 'debian03'
               Bind addr: '192.168.0.103:7946'
                RPC addr: '127.0.0.1:7373'
               Encrypted: false
                Snapshot: false
                 Profile: lan
      ==> Joining cluster...(replay: false)
          Join completed. Synced with 1 initial agents

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

          2015/12/02 10:50:11 [INFO] agent: Serf agent starting
          2015/12/02 10:50:11 [INFO] serf: EventMemberJoin: debian03 192.168.0.103
          2015/12/02 10:50:11 [INFO] agent: joining: [192.168.0.102] replay: false
          2015/12/02 10:50:11 [INFO] serf: EventMemberJoin: debian01 192.168.0.101
          2015/12/02 10:50:11 [INFO] serf: EventMemberJoin: debian02 192.168.0.102
          2015/12/02 10:50:11 [INFO] agent: joined: 1 nodes
          2015/12/02 10:50:12 [INFO] agent: Received event: member-join

      debian03はdebian01とdebian02が追加されたというイベントを受け取ります。またdebian03が追加されたというイベントはdebian02だけでなく、debian01にも伝播して通知され、３台のノードが同じクラスタに参加している状態になります。

      root@debian01:~# serf members
      debian01  192.168.33.101:7946  alive 
      debian02  192.168.33.102:7946  alive 
      debian03  192.168.33.103:7946  alive

      debian01のログ

      2015/12/02 10:55:33 [INFO] serf: EventMemberJoin: debian03 192.168.0.103
      2015/12/02 10:55:34 [INFO] agent: Received event: member-join

      ノードのクラスタからの離脱

      ノードをクラスタから離脱させるためにはそのノードのagentを停止させればOKです。正常終了した場合と、異常終了した場合とではこのときに他のサーバに通知されるイベントが異なります。

      正常終了

      正常終了するには以下方法があります。
      • serf leaveコマンドを実行
      • SIGINTあるいはCtrl-Cでserf agentプロセスを終了させる。
      正常終了させた場合は終了したという通知がそのagentから発せられクラスタの各ノードに伝播します。ここではdebian03で(フォアグランドで実行していた)agentをCtrl-Cで終了させてみます。

      debian03でCtrl-C

      ^C==> Caught signal: interrupt
      ==> Gracefully shutting down agent...
          2015/12/02 10:58:49 [INFO] agent: requesting graceful leave from Serf
          2015/12/02 10:58:49 [INFO] serf: EventMemberLeave: debian03 192.168.0.103
          2015/12/02 10:58:49 [INFO] agent: requesting serf shutdown
          2015/12/02 10:58:49 [INFO] agent: shutdown complete

      　debian01,debian02にはそれぞれmember-leaveのイベントが通知されているのが分かります。
      debian01
      2015/12/02 11:04:51 [INFO] serf: EventMemberLeave: debian03 192.168.0.103
      2015/12/02 11:04:52 [INFO] agent: Received event: member-leave

      debian02
      2015/12/02 10:58:49 [INFO] serf: EventMemberLeave: debian03 192.168.0.103
      2015/12/02 10:58:50 [INFO] agent: Received event: member-leave

      この場合、メンバーの確認すると 正常終了したサーバはleftと表示されます。

      root@debian01:~# serf members
      debian01  192.168.33.101:7946  alive 
      debian02  192.168.33.102:7946  alive 
      debian03  192.168.33.103:7946  left

       

      異常終了

      SIGTERMでプロセスを停止した場合やサーバの電源OFFなど、強制的にagentが停止された場合は他のノードがそのことを感知してイベントとして通知されます。debian03のagentをSIGTERM(9)で停止してみます。

      root@debian03:~# ps -ef | grep -i serf
      root      3607  3592  0 19:48 pts/0    00:00:00 serf agent -node=debian03 -bind=192.168.33.103 -join=192.168.0.102
      root@debian03:~# kill -9 3607
      この場合は他のメンバーがdebian03がアクセス不可になっていることを検出する形になります。
      debian01

      2015/12/02 11:19:28 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:19:30 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:19:31 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:19:33 [INFO] memberlist: Marking debian03 as failed, suspect timeout reached
      2015/12/02 11:19:33 [INFO] serf: EventMemberFailed: debian03 192.168.0.103
      2015/12/02 11:19:34 [INFO] agent: Received event: member-failed
      2015/12/02 11:19:42 [INFO] serf: attempting reconnect to debian03 192.168.0.103:7946
      2015/12/02 11:21:12 [INFO] serf: attempting reconnect to debian03 192.168.0.103:7946
      ...
      ...

      debian02
      2015/12/02 11:12:24 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:12:27 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:12:28 [INFO] memberlist: Suspect debian03 has failed, no acks received
      2015/12/02 11:12:29 [INFO] serf: EventMemberFailed: debian03 192.168.0.103
      2015/12/02 11:12:30 [INFO] agent: Received event: member-failed
      2015/12/02 11:14:05 [INFO] serf: attempting reconnect to debian03 192.168.0.103:7946
      .....


      debian01,debian02にはmember-failedのイベントが通知されているのが分かります。またイベントを受け取ったあとも一定間隔でdebian03へのアクセスを試み続けます。

      この場合にクラスタのメンバをチェックするとfailedと表示されます。

      root@debian01:~# serf members
      debian02  192.168.0.102:7946  alive  
      debian03  192.168.0.103:7946  failed 
      debian01  192.168.0.101:7946  alive

      まとめ

      serfの起動と停止をためしてみました。今回はサーバの死活だけでしたがserfを利用するとサーバの状態を把握したり、イベントを受けて任意のスクリプトを実行したりすることができます。クラスタの管理自体も非集中型でシンプルなものになっておりそれぞれのサーバにserfのバイナリをコピーするだけで構成することが可能です。

    コメント

    1. galvenlabell2022年11月7日 22:59

      MBit Casino is a favorite amongst crypto followers, due to their large choice of games and massive welcome bundle that spreads over your first several of} deposits. Don’t miss out on this nice free spins provide, click right here signal up|to enroll} and get your 50 free spins on Gemini Joker whenever you make your first deposit of $50 or extra earlier than it’s too late. Of course, if, by chance, this provide expires by the time you get to assert it — Super Slots at all times runs a weekly free spins promotion you'll be able to|you probably can} take advantage of|benefit from|reap the 정카지노 advantages of}.

      返信削除

    コメントを投稿

    このブログの人気の投稿

    SATA12台でのRAID構成可能な1Uサーバ

    投稿者: 技術スタッフ
    イメージ
    最近のサーバでは1Uサイズでも2.5インチのドライブを10台から12台搭載できます。しかし搭載しているRAIDカードが8ポートまで対応の製品のためにRAIDカードに接続可能なディスクは最大8台までという制限があり、残りのドライブは通常のSATAポート等に接続しなくてはならないという製品がほとんどでした。 EZ1D-Scalable-SATA12  そこでせっかく12台搭載できるのだから12台でRAIDを構成したいというご要望にお応えして こちら( EZ1D-Scalable-SATA12 ) の製品をご用意しました。 サーバに搭載可能な2.5インチドライブ12台全てを利用してRAIDアレイを構成することができます。デュアルソケット対応でアプリケーションの処理性能も充分、12台で構成されたRAIDの性能をフルに発揮することが可能です。 12台でRAIDを構成することにより8台での構成の場合と比較してより柔軟にRAIDを構築することができるようになります。また8台の構成では現実的でなかった特殊なアレイ構成も可能となります。 12台のドライブによる大容量ストレージ 2台のホットスペアを備えたRAID6  用途に応じた複数のRAIDアレイを1つのサーバ上に構築 RAID50やRAID60といった特殊なアレイの構成 ありそうでなかった12台対応RAID搭載1Uサーバ。ぜひご検討ください。 製品の紹介ページ EZ1D-Scalable-SATA12 主な仕様 CPU 対応CPU 第2世代インテル® Xeon® スケーラブル・プロセッサー 搭載CPU数 2 メモリ 最大容量 1.5TB(1536GB) スロット数 24 タイプ ECC対応 2666MHz DDR4 SDRAM ネットワーク デュアルポート 1Gbpsイーサネット デュアルポート 10Gbpsイーサネット RAIDコントローラ SATA12ポート対応 RAIDコントローラ RAID 0,1,5,6,10,50,60対応 キャッシュメモリプロテクションモジュール搭載 ドライブベイ 12 ホットスワップ対応 2.5インチ SATA/SAS ドライブベイ
    続きを読む

    最新Intel® Xeon® CPUのメリット

    投稿者: 技術スタッフ
    データセンタ等で使われるラックマウントサーバには、サーバ向けのプロセッサであるIntel® Xeon®プロセッサが良く利用されています。 サーバ用のXeonプロセッサは一般的にそれほど馴染みのある製品ではなく、デスクトップ向けのIntel® Core™プロセッサとは何が違うのか、同じXeonでも種類があるがどう違うのか、どの製品が最新のものなのかなどいろいろわかりにくいことが多いと思います。 そこで今回これらの疑問に答えるために、Intel XeonとCoreシリーズプロセッサの違いや、Xeonブランド内での各プロセッサの位置づけについて簡単にまとめてみました。サーバ選びの参考にしてみてください。 XeonとCoreの違い Intel XeonはIntel社製のサーバ向けのプロセッサのブランド名です。 デスクトップ向けのCoreシリーズのプロセッサとの違いはおおよその傾向として次のようになります。 Xeon プロセッサ コア数が多い クロック数よりコア数重視 CPUのキャッシュの容量が大きめ メモリをたくさん搭載できる(最大1TB~4TB) ECCメモリが使える 常時稼働のための信頼性機能搭載 その他、サーバ/ワークステーション向けの機能を搭載 Core プロセッサ コア数は少なめ コア数よりもクロック数重視 メモリはそこそこ搭載できる(最大128GB程度) ECCメモリは使えない 最近はパソコン向けのCoreプロセッサでもゲーミングPC向けなどにサーバ向けに近い性能の製品がリリースされています。しかし、テラバイト容量のメモリのサポートやECCメモリのサポートなどはサーバ向けのXeonに限定されているようです。 Xeonの種類 Xeonには2CPU以上の構成が可能で大容量メモリを搭載可能なハイエンドサーバ向けの高性能製品『Xeon Scalable Processor』と1CPU専用で性能がやや抑えめの普及価格帯の製品『Xeon-E プロセッサ』がラインナップされています。 Xeon Scalable Processor ハイエンド向けの高性能製品 2CPU以上の構成が可能(最大8CPU) コア数が多い(最大28コア56スレッド)。 大容量メモリを搭載可
    続きを読む

    Dockerを使ってみました。

    投稿者: 技術スタッフ
    Dockerを使って見ました。 ちょっとまえにもさわったことがあるのですが、最近流行りのDockerをつかってみました。Dockerとはコンテナタイプの仮想環境に独自の機能を組み合わせて使いやすく便利にしたもののようです。 　コンテナタイプ kvmといったいわゆる仮想マシンのようにまるごと物理マシンをエミュレーションした環境を用意するのではく、ネットワークやプロセスIDなどのみが独立した環境(コンテナ)を用意してその中でプロセスを実行するタイプの仮想環境です。仮想マシンと比較すると圧倒的に軽い(ホストに対する負荷が低い)のが特徴みたいです。 最近またバージョンがあがってDockerの最新版は0.10のようです。 Dorkerに必要なもの カーネル Linuxでコンテナ機能を利用するためにはカーネルが以下の機能をサポートしている必要があります。 Namespace(名前空間) Cgroups Namespace ネットワークやプロセスID、ユーザIDなどについてそれらが独立した環境を用意するカーネルの機能です。 Cgroups プロセスにが利用できるリソース(CPUの数やメモリの量)を制限するカーネルの機能です。 　それぞれかなり前のバージョンから一部はサポートされていましたが、Dockerを使うためには必要なすべて機能がそろった3.8以降のカーネルが必要です。   もちろん、カーネルコンフィグで機能が有効になっている必要があります。 以下の2つはちょっと前までは必要だったのですが、最新バージョンでは必要でなくなったものです。 Aufsファイルシステム Dokerはコンテナのイメージ(ディレクトリツリー)を格納するのにaufsを利用していましたが、aufsは標準カーネルにマージされていないので、利用するためにはパッチをカーネルにあてる必要がありました。そのためDockerはディストリビューションの標準カーネルでは動かないケースがあり、パッケージとしても提供されていないディストリビューションもあったようです。 ubuntuなどはaufsパッチの当たっているカーネルを採用していて、パッケージとしてもDockerが提供されていました。 最近(といってもちょっと前ですが)aufsが必須ではなくなり、デ
    続きを読む