ITインフラ技術の実験室ITインフラ技術の実験室Linuxを中心に、仮想化やネットワーク、Windowsまで、ITインフラ技術に関するノウハウを幅広く紹介します。Linuxでロードバランサを参考にさせて頂きながら、IPVSを使用してOpenblocks600をロードバランサにするための設定を記載していきます。IPVSとipvsadmについて取り上げますが、上記サイトにも詳しく説明がある通り、IPVSだけでは特定のリアルサーバが落ちた際にロードバランスの割り当てからはずすしたり、ロードバランサ自体を冗長化させたりはできませんので、別途keepalivedを導入する必要があります。一度に書いてしまうと長くなってしまいますので、上記サイトと同じく、1.IPVS(本記事)、2.keepalivedでリアルサーバの障害検出、3.keepalivedでロードバランサの冗長化、の流れで試していきたいと思います。IPVS及びipvsadmの導入IPVSのロードIPVSはカーネルモジュールとして提供されていますので、IPVSをサポートしたカーネルをビルドする必要がありますが、Openblocks600のカーネルはすでにIPVSをサポートしていました。カーネルモジュールをロードしてIPVSのバージョンを調べます。versionは1.2.1でした。ipvsadmのインストールipvsadmはIPVSを使用するためのコマンドラインツールで、仮想サーバやリアルサーバの設定を行ったり、設定・接続状況などが確認できます。アーカイブを取得する必要があります。ディスク領域が新たに消費されます。個のファイルとディレクトリがインストールされています。v1.2.0)ipvsadmはカーネルモジュールのIPVSとバージョンをそろえる必要がありますが、Openblocks600のdebian付属のipvsadmは1.2.0でカーネルモジュールのバージョンと差分が生じてしまいました。アーカイブを取得する必要があります。ディスク領域が解放されます。個のファイルとディレクトリがインストールされています。1.2.1をソースからビルドipvsadm1.2.1をダウンロードしてソースからビルドします。2エラーが出て失敗しました。類似事象を探してみたところ、海外のサイトに同じエラーが紹介されていました。コンパイラがカーネルソースを見つけられないためにエラーが発生しているようです。Openblocks600内にカーネルソースが見当たらなかったためkernelを落としてきてシンボリックリンクをはります。make今度はエラーが出なかったので、インストール作業を続けます。v1.2.1)ipvsadmのバージョンがめでたく1.2.1になりました。IPフォーワードの有効化ロードバランサの前に、特定のポートから別のポートへの転送機能をONにする必要があるため、IPフォーワード機能の有効化を行います。/proc/sys/net/ipv4/ip_forward0デフォルトではIPフォーワード機能は無効になっています。writtennet.ipv4.ip_forwardを1にします。1/etc/sysctl.confファイルを読み込みました。/proc/sys/net/ipv4/ip_forward1IPフォーワードが有効化されました。IPVSの動作試験ネットワーク構成について下図のようなネットワークを構築して実験します。左が物理的な接続を表し、右が論理的な接続を表しています。ラウンドロビン動作確認用のクライアントとしてはWindowsにインストールしたcURLを利用します。Openblocks600はBondingでL2SWと接続されているため、VIPを作成するセグメント(192.168.0.0/24)とリアルサーバを収容するセグメント(172.16.0.0/24)をvlanで分離します。VIP設定ユーザがWebアクセスする際に利用するVIPを手動で振ります。forever...IPアドレスが二つ振られていることを確認します。設定をリセットします。InActConn何も登録されていないことを確認します。rrVIPを追加します。ポート80、ラウンドロビン(rr)でリアルサーバにバランスさせます。-mリアルサーバのIPアドレスを追加します。パケット転送方式にはNAT(-m)を選択します。0登録されていることを確認します。※keepalivedを起動させる際には一度設定をクリアする必要があります。両リアルサーバのDocumentRootにホスト名だけ記載したhtmlファイルを用意して、リアルサーバ1にパス指定無しでhttpアクセスするとDellと返し、リアルサーバ2にアクセスするとHitachiと返却するように設定します。クライアントからcurlにてアクセスクライアントはサーバ台数もありWindowsにcURLを入れました。BLOGさんのサイトを参考にさせて頂きました。192.168.0.151Dellラウンドロビンしました。NAT動作確認Openblocksのbond0.2、DellとHitachiのeth0.10でtcpdumpをまわしながら、curlでVIPにアクセスします。kernel192.168.0.7(クライアント)と192.168.0.151(VIP)の間で通信が行われています。kernel192.168.0.7(クライアント)と172.16.0.2(リアルサーバ1)の間で通信が行われています。kernel192.168.0.7(クライアント)と172.16.0.3(リアルサーバ2)の間で通信が行われています。上記の結果から、クライアントからVIP宛の通信は、宛先をリアルサーバのIPに書き換えてIPフォーワードしていることが分かります。リアルサーバからクライアントへの戻り通信は、送信元をリアルサーバからVIPに書き換えていることが分かります。リアルサーバ障害時の動作リアルサーバ2(Hitachi)側のApacheを落として動作を確認します。stopリアルサーバ2を落とした後にクライアントからアクセスします。192.168.0.151Dell2回に1回、接続NGになってしまいます。リアルサーバの障害時は自動的に迂回するようにするためにはkeepalivedが必要ですが、weightをいじることで、手動で計画的にリアルサーバをラウンドロビンの対象からはずすことは可能です。一度リアルサーバ2のApacheプロセスを上げてから動作を確認してみます。8172.16.0.3のWeightが0になっていることを確認して、クライアントからcurlを実行します。192.168.0.151Dellアクセスが無事、リアルサーバ1に偏りました。元に戻して再度確認します。192.168.0.151Dellラウンドロビン動作に戻りました。IPVSを使用してOpenblocks600をロードバランサ化しましたが、このままでは障害中のリアルサーバにもアクセスを割り当ててしまいます。そこで次回の記事(keepalived(1.2.1)の導入)では、keepalivedを導入することでリアルサーバのサービス監視を行い、リアルサーバに障害が起きた際には自動的にロードバランス先からはずせるようにします。コメントをキャンセルメールアドレスが公開されることはありません。