CLUSTERIP ターゲットを使うと、単一の IP と MACアドレスにラウンドロビン方式で応答する単純なクラスターノード群を形成することができる。これは簡易型のクラスターで、クラスターを形成しているすべてのホストにひとつの バーチャルIP (Virtual IP = VIP) を与えておき、応答させたいマシンそれぞれで CLUSTERIP を施すというもの。 CLUSTERIP マッチには特別な ロードバランス (load balancing) ハードウェアや専業マシンは必要ない。クラスターを形成する複数のマシン自体だけで機能が成り立つ。これはクラスターを実現するあくまでも簡易的なひとつの方法であって、大規模なものや複雑な構成には不向きだ。また、ハートビート (heartbeat) を取り扱う機能も内蔵していないが、やろうと思えば簡単なスクリプトを用いて実装することも可能だろう。
クラスターのすべてのマシンは VIP に対して共通の マルチキャストMAC (Multicast MAC) アドレスを持ち、 CLUSTERIP ターゲットは特別なハッシュアルゴリズムを使ってコネクション毎にどのクラスターノードが応答すべきかを決定する。 マルチキャストMAC とは、最初の 24ビットに 01:00:5e を持った MACアドレスで、例えば 01:00:5e:00:00:20 といったものになる。 VIP はどんな IPアドレスでも構わないが、構成ノードすべてで同一でなければならない。
CLUSTERIP で気を付けなければならないのは、 SSH など幾つかのプロトコルは正常に通信できないことがあるという点だ。コネクション自体は正常に通るのだが、次回同じホストに再び接続しようとした時には、他の実マシン、つまり別の鍵セットをもつマシンに接続されてしまうかもしれない。すると当然、ssh クライアントは接続を拒絶するかエラーを表示する。ある種のプロトコルはこうした理由であまりウマくないことになる。これを避けるためには、保守・管理用としてそれぞれのマシンに別のアドレスも与えておくとよい。他の打開策としては、クラスターに属するマシンすべてで同一の SSHキー を使用する方法もある。 |
クラスター をロードバランスするには 3種類のハッシュモード (hashmodes) が利用できる。ひとつ目は 送信元IP (sourceip) のみのモード、ふたつ目は 送信元IP と 送信元ポート のモード (sourceip-sourceport)、そして 3つ目が 送信元IP, 送信元ポート, 宛先ポート のモード (sourceip-sourceport-destport) だ。 ひとつ目のモードは、コネクションの状態 (state) を記憶しておく必要のある場合に最適で、例えば、ショッピングカートを用いているためコネクションを維持しなければならない WEB サーバの場合に向いている。この方式では ロードバランシング は完全に均等というわけにはいかない (或るマシンが他よりも高い負荷を負うことがあるなど)。同じ 送信元IP から来たコネクションは同一のサーバへ振り向けられるからだ。 sourceip-sourceport ハッシュ方式は、ロードバランシング をより均等化したい場合で、サーバ毎のコネクション状態を維持しなくてもよい時に向いている。例えば、大量の情報を掲載するような WEBページで、検索エンジンは備えているとしても簡易的なものである場合がこれにあたるだろう。最後の ハッシュモード、 sourceip-sourceport-destport は、コネクション毎の状態を一切維持する必要のない複数のサービスを稼働させているホストに適しているだろう。 1台のホスト上で ntp と dns と www サービスをシンプルな構成で動かしている場合などだ。この場合、新たな送信先ポートへのコネクションはその度毎にネゴシエートされる -- いや、実際のところ、この場合には単なる ラウンドロビン システムとして働くわけで、各ホストはコネクションを刹那的にひとつまたひとつと受け入れるだけで、ネゴシエーションといったものは行われない。
CLUSTERIP によってクラスターを構成すると、 /proc/net/ipt_CLUSTERIP ディレクトリに VIP 毎にひとつのファイルが作成される。例えば VIP が 192.168.0.5 だったとすると、 cat /proc/net/ipt_CLUSTERIP/192.168.0.5 とコマンドすれば、このマシンが今どのノードを担当しているかが分かる。別のノード、例えばノード2 の担当もさせるには、echo "+2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5 でノードを加えてやればいい。削除は echo "-2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5 とやる。
Table 11-2. CLUSTERIPターゲットオプション
オプション | --new |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new ... |
説明 | このオプションは CLUSTERIP の新しいエントリを生成する。これは当該の VIP を扱う最初のルールで設定しなければならない。これによって新しいクラスターが作成されるわけだ。同一の CLUSTERIP に関係するルールが複数ある場合、2回目以降に VIP を参照する時には --new キーワードは省略しても構わない。 |
オプション | --hashmode |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 443 -j CLUSTERIP --new --hashmode sourceip ... |
説明 | --hashmode キーワードは、生成するハッシュの種類を指定する。 hashmode は以下の 3つのいずれかだ。
hashmodes については既にかなり詳しく述べた。簡単に述べると、sourceip は、比較的パフォーマンスが高く、コネクション間の状態を維持する簡潔な仕組みを持つ反面、実マシンの ロードバランシング という意味ではあまり優れていない。 sourceip-sourceport は速度の面でやや劣るハッシング方式で、コネクション相互の状態もあまり上手く管理できないが、 ロードバランシング としての特性では優れる。最後の sourceip-sourceport-destport はメモリを大量に消費する最も低速なハッシュを形成するが、その反面、ロードバランシング 特性では非常に優れている。 |
オプション | --clustermac |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 ... |
説明 | クラスターがコネクションを待ち受ける、クラスタの MAC アドレス。これが、すべてのホストがリッスンする共通の マルチキャストMAC となる。詳しくは前述の説明を参照していただきたい。 |
オプション | --total-nodes |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --total-nodes 2 ... |
説明 | --total-nodes キーワードは、リクエストに答えるべくクラスターに参加しているホストの数を指定する。詳しくは前述の説明を参照のこと。 |
オプション | --local-node |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --total-nodes 2 --local-node 1 |
説明 | クラスター内におけるそのマシンのナンバーを指定する。クラスターは ラウンドロビン で要求に答えるので、新たなコネクションがクラスターに結ばれると次のマシンが返答する。そしてまた今度は次のマシンが...という具合だ。 |
オプション | --hash-init |
例 | iptables -A INPUT -p tcp -d 192.168.0.5 --dport 80 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5e:00:00:20 --hash-init 1234 |
説明 | ハッシュの初期化に使用するランダムシードを指定する。 |
CLUSTERIP ターゲットは RFC 1812 - Requirements for IP Version 4 Routers RFC に反しており、それによって惹起されるトラブルには注意しなければならない。特に、同 RFC のセクション 3.3.2 に規定されている、「全てのルータは、マルチキャストMAC を使用していると主張するホストやルータを信用してはならない」という部分だ。 |
Linux カーネル 2.6 で機能する。実験的なものと位置づけられている。 |