GMOクラウドPublicによるサーバ構築日記
2013年1月21日月曜日
ロードバランサーその9(完結)
さて一度は諦めた自前ロードバランサーであったが、簡単なツールを利用することでロードバランサ機能の実現に成功した。
備忘録としてここに記す。
以下、仮想サーバを立ち上げ
linux.68newspaper.jp
linux2.68newspaper.jp
lb.68newspaper.jp
ロードバランサとして利用する「lb.68newspaper.jp」にテラタームでアクセスし、以下のコマンド実施。
「Pound」というロードバランサーのツールをインストールしている。
yum -y install wget
wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
yum --enablerepo=epel -y install Pound
以下、設定ファイルをコピーしている(念のためのバックアップ)
cd /etc
cp pound.cfg pound_bk.cfg
そして以下、設定ファイルの編集
vi /etc/pound.cfg
まずデフォルトで書いてあるのを、全部消してしまう。
バサっと。
そして以下の内容を記述。
------------------------------------------------
ListenHTTP
Address (ロードバランサーのIPアドレス)
Port 8080
Service
HeadRequire "Host: .*lb.68newspaper.jp"
BackEnd
Address (WEBサーバ1のIPアドレス)
Port 80
End
BackEnd
Address (WEBサーバ2のIPアドレス)
Port 80
End
End
End
------------------------------------------------
ファイヤーウォール機能をストップしてしまう。
ロードバランサは8080ポートを利用していて、ちょっと設定とか面倒くさそうなため。
ばっさり完全ストップ。
service iptables stop
以下、振り分け先のWEBサーバのドキュメントルートにindex.htmlを用意。
echo "<body>linux.68newspaper.jp</body>" > /var/www/html/index.html
echo "<body>linux2.68newspaper.jp</body>" > /var/www/html/index.html
そしてPoundをスタート。
service pound start
そして必要なら自動起動の設定ON
chkconfig pound on
そして以下のURLでアクセス。
http://lb.68newspaper.jp:8080/
ほいっ!!!
更新するたんびに、表示が切り替わっています!
できた・・・
あとロードバランサーのportを80にしたりとか、iptablesをちゃんと機能させるとかは、別途対応が必要だけど、そんなに難しくはないと思われますので割愛いたします。
というわけで、ロードバランサー機能を自前で用意するという目的を果たしたため、
この記事のシリーズは完結とさせていただきます。
2013年1月20日日曜日
ロードバランサーその8
さて、自前でロードバランサーを構築しようと思ったのだけど、どうもロードバランサー用のサーバにはIPアドレスが二つ必要なようだ。
GMOクラウドPublicの仮想サーバを利用した場合、IPアドレス二つを一つのサーバにつけてもらうことは、サービスとしてやっていないような気がしている。
自前でVMなどを利用して仮想サーバを立ち上げる分には一つのサーバでIPアドレスを二つ持つ何かしらの方法があるのかも知れないが、
今回のGMOクラウドPublic上での仮想サーバに関しては、私の浅い知識で考えた場合、
方法が見つからなかった。
そのため、「GMOクラウドPublicで提供しているロードバランサーを使う」という選択しか思い浮かばない。
まあとりあえず、GMOクラウドの提供しているロードバランサーでサーバの振り分けが出来たことは確認済みなので、この記事はここまでで完結としたいと思う。
思った以上に難しいものであった。
まあ機会があったら、自前ロードバランサの構築には、あたらめて取り組もうかと思う。
ロードバランサーその7
さて、前回「keepalived」のインストールに成功したので、今度はその設定をしようと思う。
設定ファイルは以下のもののようだ。
/etc/keepalived/keepalived.conf
その内容は以下のようにする。
virtual_server_group example {
ロードバランサのIPアドレス 80
}
virtual_server group example {
lvs_sched rr
lvs_method NAT
protocol TCP
virtualhost balancer.68newspaper.jp
real_server WEBサーバ1のIPアドレス 80 {
weight 1
HTTP_GET {
url {
path /health.html
status_code 200
}
connect_port 80
connect_timeout 5
}
}
real_server WEBサーバ2のIPアドレス 80 {
weight 1
HTTP_GET {
url {
path /health.html
status_code 200
}
connect_port 80
connect_timeout 5
}
}
}
さて、上記のように記述して、keepalivedを起動させてみた。
が、全然うまくいかない。
「接続できませんでした」になってしまう。
さてさて、なぜだろう。
ネットで調べるとこんなん書いているのだが、どういう意味やろなー
--------------------------------------------
ロードバランサー側の設定
eth0からeth1に受け流す。
# echo "1" > /proc/sys/net/ipv4/ip_forward ←これ重要
# route add -net 192.168.31.0 gw 192.168.31.1 metric 1 netmask 255.255.255.0 eth1
--------------------------------------------
クライアント側の設定
192.168.31.0/24へのルーティングを設定します。
# route add -net 192.168.31.0 gw 192.168.10.1 metric 1 netmask 255.255.255.0 eth1
--------------------------------------------
わかりませんなー。
書籍に書いてある情報、あまりに不足していた。
以下のファイルの内容を見てみると今は「0」になっている。
/proc/sys/net/ipv4/ip_forward
これを「1」にすることで、できる、みたいなことを書いてあるような気がする。
では以下をやってみる。
echo "1" > /proc/sys/net/ipv4/ip_forward
するとip_forwardの内容が「1」になった。
で、アクセスしてみても、ダメ。
keepalivedをリスタートしてみたけどダメ。
ちょっと設定ファイルをコピーしていじってみたいと思う。
コピーの仕方はこんな感じらしい。
cp [オプション] コピー元ファイル名 コピー先ファイル名
ではこんな感じでコピーをしよう。
cp keepalived.conf keepalived_bk.conf
あと、このコマンドは設定を反映させるらしい。
sysctl -p
あれれ、ip_forwardが、「0」に戻っているよ。
確認するコマンドは以下らしい。
ipvsadm -Ln
うん、あとはip_fowardの問題だけかもしれない。
これをいじるのかも知れない。
/etc/sysctl.conf
だめだなー。
ちょっと当分できそうにないためこの記事はクローズ。
ロードバランサーその6
さてロードバランサーの方がうまくいかなかった件であるが、
とりあえずサポートの人の言う通りロードバランサの再構築というものをしたら、
うまく動くようになった。
グーグルクロームではキャッシュ機能のためだろう、一方へのアクセスに偏ってしまうが、
IE9で確認してみたら、ほぼ交互にアクセスされているようだった。
だからこれで終わりっとしても良いのだけど、せっかくなので、自前ロードバランサーの構築もしてみたいと思う。
自前ロードバランサーのホスト名は以下の通りだ。
balancer.68newspaper.jp
手もとの書籍で調べたところによると、それほど難しくないようだ。
というより、本屋に出かけて、本屋で家にある本を読んだのだけど。
ウェブの情報と手もとの書籍の情報で、構築はわりとたやすくいけるのではないかと楽観している。
あんまりよく分からないのだけど、とりあえず以下の二つをインストールしてみる。
yum -y install ipvsadm
yum -y install keepalived
ま、とにかくはテラタームで「balancer.68newspaper.jp」にアクセスしないことには始まらない。
というわけでログインした。
ではインストールをしてみる。
ipvsadmはうまくインストールできたのだけど、「keepalived」はインストールできなかった。
No package keepalived available.
Error: Nothing to do
とか言われてしまった。
EPEL リポジトリを使えるようにしなければいけらないらしい。
そのために以下のようなコマンドを実行してみようと思う。ファイルをダウンロードしてくるコマンドのようだ。
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
-bash: wget: command not foundと言われてしまった。
ではwgetとかいうのをインストールしてみる。
yum -y install wget
無事インストールできたようだ。
またkeepalivedのインストールを試みてみよう。
yum -y install keepalived
やっぱダメだった。
では以下のようにダウンロードを試みる(EPEL リポジトリを使えるようにするために)
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
以下のようなものをダウンロードできた。
rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
じゃあ、なんかよー分からんが以下のコマンドを実行してみる。インストールのコマンドかなんかだろう。
rpm -ivh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
すぐに処理は終わった。
さて、次はどうなる?
うむ。EPELリポジトリではなくrpmforgeリポジトリが使えるようになった状態のようだ。
EPELじゃないとなー。だめなのではないかい?
URLはこれなのではないかと思う。
http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
ではこいつをダウンロードしてみたいと思う。
ダウンロードファイル置き場として以下に移動する。
cd /usr/local/src
あ、あとリポジトリ関連のファイルの置き場は以下のようだ。
/etc/yum.repos.d
では以下のようなことをしてみる。
wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
一瞬でダウンロードできたようだ。
centosは実に素早い。linuxは。
では以下のようにしてみよう。
rpm -ivh epel-release-6-8.noarch.rpm
うん。これをすると以下のファイルが出来上がった。
/etc/yum.repos.d/epel.repo
それでこんなようにすればkeepalivedがインストールできるかも。
yum -y --enablerepo=epel install keepalived
うむ!!!
インストールに成功した。
ロードバランスの実現が近づいた。
次回に続きます。
ロードバランサーその5
さて、ロードバランサで片一方の仮想サーバにアクセスできない件だが、
GMOクラウドPublicのサポートの人から以下のような回答を貰った。
「ロードバランサーの再構築をお試しいただき、状況が改善されるか
ご確認をいただけますでしょうか。」
再構築をする場合以下ような危険があるそうだ。
「※「バランサーの再構築」を実行されますと配下の仮想サーバーでも
「ネットワークの再構築」が自動的に実施されますため、タスク処理が
正常に終了しなかった場合等に現在稼働中の仮想サーバーに対しても
影響や不具合が発生する可能性がございます。
そのため、「バランサーの再構築」を実施される場合は、事前に
ロードバランサー配下の仮想サーバーのバックアップを取得された上で
実施いただくことをおすすめいたします。
」
そしてバックアップのやり方が書かれたリンクを教えてもらった。
っていうか、リンク先に書いてある通りになっていない。
「バックアップを取る」なんてボタンはどこにも出てきませんよー
いい加減だなー。GMOけっこう。
あと、バックアップって結構時間かかることもあるようだ。
「なお、誠に恐縮ではございますが、クラウドコンソールからの
バックアップ取得は、容量やタスクの混雑状況により、完了までに
数時間を要する場合もございますのでご了承ください。」
ま、バックアップの件はとりあえず良しとする。
ではロードバランサの再構築を試してみたいと思う。
ま、自前でロードバランサーを実装した方が、色々と自由度は高そうだし勉強にもなりそうだってメリットはあるのだけどね。
でもできれば、まだそこらへんへの取り組みは保留にしておきたい。
他にも色々と作業があるため。
GMOクラウドPublicが用意しているロードバランサーが使えそうだったら、それですましてしまいたいのである。
ロードバランサの再構築も結構時間がかかりそうな気配である。
ちと気長に待つことにする。
いつまでたってもピクリとも動かない。
やはりちとGMOクラウドPublicの提供するロードバランサーは利用しない方が得策かもしれない。
そもそもオートスケールの方もあるのだけど、この分だとちょっと品質面に不安がのこる。
ここはしょうがないからロードバランサを自前で用意するスタイルに切り替えた方が良いかもしれない。
普通に仮想サーバを立ち上げる分には、まあ時々ロックされてしまうことはあるようだけど、
まあそれはそれで、サポートに連絡すればロック解除してくれるのだから、
まあ特に問題はないだろう。
ロードバランスやオートスケールはちと心配。
とかなんとか書いているうちに少しだけロードバランサの再構築の進捗に動きがあった。
ま、いったんこの記事もクローズ。
ロードバランサーその4
昨日はGMOクラウドPublicがロックを起こしたため日没後からの時間は丸々ムダになるという事態が発生してしまった。
「タスク処理のキャンセルをいたしますとロック状態となってしまう事がございます。」とのこと。
ではキャンセルはできなくしたほうがいいのではないかと言いたい。
まったく昨日はイライラ全開の思いをさせていただいた。
ありがとう良い薬です。
「ロック状態は仮想サーバーの操作は連続して行うと発生する事があります。
仮想サーバーを連続して操作なされないようご注意ください。
仮想サーバーの操作状況は「仮想サーバーのアクティビティログ」から確認が可能です。
「状態」がCompleteになったことを確認してから次の操作に移ってください。
仮想サーバーの操作が完了するまでには、テンプレートの種類や利用状況などにより
異なりますが数分~数十分の時間を要することがあります。
操作は十分な余裕を持って行ってください。」
ということらしい。
要注意である。
そして私は衝動的にすべての仮想サーバをバサッと削除した。
ロードバランサーは仮想サーバのタイプを揃えないといけないらしく、
他にもそのような不都合があるかも知れないので、今後は仮想サーバのタイプを統一しようかと思っている。
Xen
こちらを使うことにする。
そしてまた気を取り直して、仮想サーバを立ち上げたいと思う。
以下の二つと、ロードバランサを立ち上げる。
linux.68newspaper.jp
linux2.68newspaper.jp
lb.68newspaper.jp
なんともロードバランサーでのアクセスは微妙に挙動が安定していない。
画像リンク切れが気になる。
ロードバランサーはこちら。
lb.68newspaper.jp
速度面で設定できるのは「ポートスピード」だけのようだ。
では以下の二つの仮想サーバのWEBサーバのドキュメントルートにindex.htmlを置いてみようと思う。
linux.68newspaper.jp
linux2.68newspaper.jp
そして正しく振り分けができていることを確認できれば、ロードバランサーに関してはとりあえず完了で良いだろう。
ちなみにWEBサーバのドキュメントルートは以下である。
/var/www/html
うーん、ちょっとロードバランサだけど、全然使い物になっていない。
全然振り分けうまくいかない。
linux.68newspaper.jpへの振り分けはうまくいくのだけど、linux2.68newspaper.jpへの振り分けがダメなようだ。
「接続できませんでした」になってしまう。
これは用意されたロードバランサを利用するよりも自前でロードバランサを作った方が良いかもしれない。
とりあえずサポートに連絡だけしておこうと思う。
なんか送ったメールがゴミ箱に入ってるよ。
心配になるような現象やめてくれんかな。
これは、自前でロードバランサを作るということになった場合は、結構ロードバランサシリーズの記事は長くなりそうだ。
とりあえず自前ロードバランサ用に以下のサーバを立ち上げた。
balancer.68newspaper.jp
2013年1月19日土曜日
ロードバランサーその3
さて、ではロードバランサ、実際にちゃんと行われるのか試してみたいと思う。
でも、ほんっと失敗した!
全部Xenで作っとくべきだった。
同じタイプのものじゃないとロードバランサーできないみたい。
きっつー。
メインで使おうと思ってつくったのKVMだよ。
高いんだよ、KVMはCPUの占有率が100パーセント固定だから。
くっそー。
また一から作り直すしかしょうがない。
動作はKVMの方が早いみたいだけど、Xenの方がいいだろうな。節約したいから。
くっそー。
で、ロードバランサお試し用にXenの仮想サーバをもう一個作りました。
でも、おっせーなー構築。
いつまでかかってんだろうね、しかし。
いじめか?
で、とりあえず、WEBサーバのドキュメントルートにindex.htmlを置きましょう。
追加した二つのサーバに。
そしてロードバランサのIPアドレスでアクセスし、交互に振り分けが行われたら、
ま、オッケーでいいんちゃうかな。
いや、ほんと。
で、今やってみたんだけど、やっぱロードバランサーのIPアドレスでアクセスしたら、以下のように表示された。
linux2.studywind.info
これはlinux2.studywind.infoのWEBサーバのドキュメントルートに作成したindex.htmlの内容である。
ま、問題なさそうだ。
あとはそう、クラウドのタイプが一緒じゃないとロードバランサ使えませんよってのを、しっかり肝に銘じておかねばならない。
さすがにKVMで作ったメインのサーバ結構色々やったから、また一から作るのは、きっついよ、ほんと。
メールサーバの設定とかDNSサーバ構築とかしているのに。
冗談じゃありませんって話ですよ、ほんと。
考えたら今はまだ無料期間中なんだからバンバン高性能な仮想サーバ作っても良かったよ。
貧乏根性出し過ぎた。
CPU利用率を1パーセントにしたためだろうか、いや、もしかしたら今、メンテナンス中とかかも知れん。
こんな、おっせーのは異常だよなー
・・・
あんまり遅すぎたので、処理キャンセルした。
しかし処理は終わらず。
いったん、この記事もクローズします。
もうだいたい、やり方は分かりました。
登録:
投稿 (Atom)