Monthly Archives: 7月 2013

EucalyptusでLVS-KeepalivedなL4ロードバランサを作る話

お久しぶりです。
リプレーションのインフラ担当SE、utunです。

今回はEucalyptus上でロードバランサを作った話を適当に書いていこうと思います。
ちょっと今回は実用的な内容も盛り込んでいくよ!
Eucalyptusつってるけど、実際別に普通のサーバでも同じようにできるしね!

あ、ちなみに、うちのプライベートクラウド「SEC」が8月くらいに発売になる予定なんで、
それを買う人は読まなくても最初から使えるイメージ入ってますよ!

ちょっと宣伝もしたところで本題に戻ります。

ともあれ、自前のサーバで負荷分散するってーと、
手軽に立てられるロードバランサってことで、DNSラウンドロビンにする事が多いと思います。
しかし、

えー、マジDNSラウンドロビン!?

キモーイ

DNSラウンドロビンが許されるのは小学生までだよねー

キャハハハハハ

という声が聞こえてきたので、
仕方がないのでちゃんと作ってみる事にしました。

LVSとkeepalivedでのロードバランサ

まぁロードバランサっても色々ある訳で、
特に今回は「HTTP」が出来ればいいだけだったので、
apacheとかnginxとかでL7ロードバランサ作ってみるのもありっちゃありだったんですが、
プライベートクラウドって限られた資源内で、なるべく性能上げたかったんでL4でいきます。

高性能なサーバで作るならF5でも買えよ!

って思うしね。
まぁ今回の環境だと、クラウドコントローラの性能がボトルネックになるから
そもそも高価なアプライアンス買っても無意味だけどね!

とりあえず keepalived のインストール

まずはとりあえずepel使えるようにします。
もはや最近鉄板になっている・・・。
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
新しいのが出てたらそっち使って下さい。

あ、超今更だけどCentOS6です!
まぁサーバにUbuntuとか使ってる人なんて世界中に存在しないと思うけど
FreeBSDとかDebianの人はいるかもしれないからね!
個人的にUbuntuに恨みを持ってるとかって事は全然無いよ!
FreeBSD x ZFSとかちょっと憧れるよね。
皆はFreeBSD派?Indiana派?
僕はGlusterFS派です。

話が逸れましたね。
次にインストールですが、
yum -y install –enablerepo=epel ipvsadm keepalived
で終了です。
簡単だね!

keepalived関連設定

まぁやっかいなのは実はここからで、
ここからがうまくいかなくて断念した人も多いんじゃないかな。
僕も何が何だか覚えてないので、とりあえずこれ打てばおk。

sysctl -w net.ipv4.ip_forward=1 > /dev/null
sed -i ‘/net.ipv4.ip_forward/d’ /etc/sysctl.conf
echo “net.ipv4.ip_forward=1″ >> /etc/sysctl.conf
sysctl -w net.ipv4.conf.eth0.rp_filter=0 > /dev/null
sed -i ‘/net.ipv4.conf.eth0.rp_filter/d’ /etc/sysctl.conf
echo “net.ipv4.conf.eth0.rp_filter=0″ >> /etc/sysctl.conf
sysctl -w net.nf_conntrack_max=20000000 > /dev/null
sed -i ‘/net.nf_conntrack_max/d’ /etc/sysctl.conf
echo “net.nf_conntrack_max=20000000″ >> /etc/sysctl.conf
sysctl -w net.ipv6.conf.all.disable_ipv6=1 > /dev/null
sed -i ‘/net.ipv6.conf.all.disable_ipv6/d’ /etc/sysctl.conf
echo “net.ipv6.conf.all.disable_ipv6=1″ >> /etc/sysctl.conf
sysctl -w net.ipv6.conf.default.disable_ipv6=1 > /dev/null
sed -i ‘/net.ipv6.conf.default.disable_ipv6/d’ /etc/sysctl.conf
echo “net.ipv6.conf.default.disable_ipv6=1″ >> /etc/sysctl.conf

sed -i ‘/AddressFamily/d’ /etc/ssh/sshd_config
echo “AddressFamily inet” >> /etc/ssh/sshd_config
service sshd restart
ethtool -K eth0 tx off tso off gso off

shutdown -r now # 再起動時は諸々ご注意を…

うん。
訳分からんね。
まぁ、シスパラを適当に弄って、sshd設定適当に弄って、NICオフロード適当に弄ってるだけです。
調べれば出てくると思うけど、めんどくさければ別にそのまま打っていいですよ!

あと、keepalived自体の設定も適当に弄る。
ちなみに、keepalived.confはコメントアウトが「!」なので、「#」使ってると嵌るぜ!
てか嵌ったぜ・・・
vi /etc/keepalived/keepalived.conf
# ━━こっから━━━━━━━━━━━━━━━━━━━━━
global_defs {
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
router_id localhost_alert
}

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
<this server’s private ip address>
}
}
virtual_server_group web_servers {
<this server’s private ip address> 80
}

virtual_server group web_servers {
delay_loop   3
lvs_sched    lc
lvs_method   DR
protocol     TCP

! 宛先サーバを増やす場合は、以下を複数作成して下さい.
!  real_server <private ip address> 80 {
!    weight 1
!    inhibit_on_failure
!    HTTP_GET {
!      url {
!        path /health_check.html
!        status_code 200
!      }
!      connect_port 80
!      connect_timeout 3
!    }
!  }
real_server <private ip address> 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
}
# ━━ここまで━━━━━━━━━━━━━━━━━━━━━

<this server’s private ip address>、<private ip address>は適当に弄って下さい。

Webサーバ側の設定

もうここまで来たら終わったようなもんだね。
もうWebサーバ側とかは自由に作って下さい!

と言いたい所ですが、一点だけ重要な設定があるのでそこだけ。
iptables -t nat -F
iptables -t nat -A PREROUTING -d <LB server ip> -j REDIRECT
/etc/init.d/iptables save

これやっとかないと、Webサーバ側で

なんじゃこりゃぁあ!!!

ってジーパンデカばりに言われます。

ようは、宛先がロードバランサのパケットが飛んできて、
「はいはい。オレオレ詐欺おつ!」
つって無視されてしまうので、
この設定で、この人は信用していいんだよ!って言ってあげる設定です。

そんな感じで、みんなロードバランサっちゃって下さい!

※ 追記
設定内容をちゃんと見てくれた人は気づいてると思うけど、Webサーバ側にヘルスチェック用のファイルは置いて下さい!
「health_check.html」
別に中身はなんでも構わないんで、
echo “alive” > /var/www/html/health_check.html
とかでもいいですよ~

Elastic Load Balancer

ここまで書いといてなんですが、
EucalyptusにもELBが実装されます。
まぁユーカリプタサーの皆は当然知ってると思うけど。

Eucalyptus 3.3.0から実装されてて、コマンドも使えるようになってるよね。
なってるよね・・・・。
コマンドは・・・・・・・・_| ̄|○

うん。
まぁ動かなかったんだわ。
内部的にELB用と思われる仮想マシンが起動する処までは確認できたんだけど、
どうやっても追加したサーバがaliveな状態にならない。
なんかやり方が悪いのか・・・?
もうよくわからんし、GUIが実装されるであろう3.3.1か3.3.2まで待つことにしました。
3.3.1のロードマップにはAuto ScalingとCloudWatchのGUIしか書かれてなかった気がするけど、
ELBも来るよね・・・?

EBSバックアップな話

お久しぶりです。
リプレーションのインフラ担当SE、utunです。

今回はAmazon EC2、及びEucalyptusのEBSバックアップ手段について、適当な感じに書いていきます。

EBS バックアップ

うん。
みんなバックアップしたいよね。

AWSなら自動でS3にバックアップされてっしー
俺別にミスとかしねーからバックアップとかいらねっしー
っつかバックアップ(笑)とかイレブンナインの堅牢性があればいらねっしー

と思っているそこの貴方!

そうじゃないんだ。
そうじゃないんだよ!
重要なのは、

バックアップイメージを他環境で使える

ってとこなんだ。

とか言ってるけど、現状うちではEucalyptusでしかテストしてないから、
AWSでやる人は自己責任でお願いするぜ!

EBS バックアップ方法

そんな訳で、移行できる事を前提にバックアップをするわけだけど、
他環境で使いたいってことは、当然S3保存じゃだめだよね。

EucalyptusでのEBSバックアップ

つかEBSでのバックアップとか、「/var/lib/eucalyptus/volumes/」取りゃいいだけだべJK
とか思っているかもしれない。
まぁ、あなたがpsqlで「volumes」「volume_tokens」「volume_exports」を整合性取れる形で手動で編集できるなら、
別にそれでもいいかもね。
でもぶっちゃけ面倒だぜ?
ってことで、そういう泥臭い事はしない。
んじゃどうするかってーと、こんな感じだ。

1、適当なインスタンスを一つ立ち上げる。
2、インスタンス上の「/root/.ssh/authorized_keys」の「ssh-rsa」より前を削除する。
3、バックアップしたいEBSをそれにアタッチする。
4、以下のコマンドでローカルにバックアップ
# ssh -i key.priv root@ “gzip – < /dev/vdb” | zcat > backup.img

実にスマートだね。
正直WebUIからボタン一発でできてほしいけど、
まぁ別にそこまで手間じゃないので、これでもいいかなって感じ。

AWSでのEBSバックアップ

ここは完全に僕の妄想なので、たぶんこれでいけんじゃね?って話。
バックアップまではできるのを確認してるけど、リストアがうまくいくかは未知数だ。

1、適当なインスタンスを一つ立ち上げる。
2、インスタンス上の「/root/.ssh/authorized_keys」の「ssh-rsa」より前を削除する。
3、sshd_confで認証をwithout-passwordにする。
4、バックアップしたいEBSをそれにアタッチする。
5、以下のコマンドでローカルにバックアップ (※ DLに若干お金かかるんで注意(10円くらい?))
# ssh -i key.priv root@ “gzip – < /dev/xvdf” | zcat > backup.img

こっちも大して変わんないな。
AWSはやってて思ったけど、パーティションがなんか特殊。
cat /proc/partitions
してみたらわかるけど、見た目上パーティション切ってない(?)風なんだ。
まぁ、amazonさんの深遠な考えがあるのだろう。

EBS リストア方法

なんか力尽きてきたんでざっくり行くぜ!

EucalyptusでのEBSリストア

1、適当なインスタンスを一つ立ち上げる。
2、インスタンス上の「/root/.ssh/authorized_keys」の「ssh-rsa」より前を削除する。
3、リストアしたいボリュームと同じ容量のボリュームを作る。
4、ボリュームをインスタンスに適当にアタッチ。
5、適当に以下のコマンドを打つ。
# gzip – < backup.img | ssh -i key.priv root@ “zcat > /dev/vdb”

AWSでのEBSリストア

何回も言うけど、ここは完全に僕の妄想なんで、もしやってみた人がいたら結果を書き込んでくれるとうれしい!

1、適当なインスタンスを一つ立ち上げる。
2、インスタンス上の「/root/.ssh/authorized_keys」の「ssh-rsa」より前を削除する。
3、sshd_confで認証をwithout-passwordにする。
4、リストアしたいボリュームと同じ容量のボリュームを作る。
5、ボリュームをインスタンスに適当にアタッチ。
6、適当に以下のコマンドを打つ。
# gzip – < backup.img | ssh -i key.priv root@ “zcat > /dev/xvdf”

そんな感じだ!
簡単だね!
Eucalyptusとか、ぶっちゃけここだけバックアップしとけば後は壊れてもなんとかなるし、
正直バックアップはEBSだけでいいと思うんだよねー。
まぁ丸ごとバックアップするときは、「/var/lib/eucalyptus/db」もとっちゃえばpostgreDBも一緒に取れて楽っちゃ楽かもだけどね。

蛇足

特に今回は面白い事も無いなー。
ちなみに、この前伊豆大島行ってきたんで、ついでにその爽やかな景色だけでも上げときます。

izuohshima

携帯・スマフォアプリの通信な話

初めまして、リプレーションのDB屋もどきのような何かです。
仕事やプライベートで日々感じている事を淡々と書いていこうかと思います。

今回は仕事で現在携わっている携帯やスマフォにおける通信の話をします。

「通信に失敗しました。」
スマフォアプリやゲームを電車でやっていると見る言葉です。
「なんだよ、サーバー強化しろよ!」と思う時もあるでしょう。
ただ通信エラーって内部的には色々存在するのです。
※私の知識の範囲ですので、間違っていたら平にご容赦を・・

1.「サーバーに届かなかった」エラーが帰ってきた
 端末から電波を発信できなかった、もしくは発信したがサーバーに届かなかった時に発生します。

 地下に居る時や、金属に囲まれている状況(電車とかエレベーター等)だとおきやすいですね。
 この場合は正直端末のキャリアさんに頑張ってもらうしかない場合が多いです。

 またサーバが落ちている時にも発生します。
 これは開発・運営側からすると本当にごめんなさいな状態です。
 多分中の人は必死にやっているはずなので・・・。

2.サーバーからエラーが帰ってきた
 サーバーに届いたが、何かしらのエラーが発生した時に発生します。

 個人的には論理エラーと呼んでいるのですが、所謂起きるべくして起きたエラーです。
 例:
  ・存在しないアイテムを使おうとした
   これはアプリに問題がある場合が多いです

  ・アイテムを買おうとしたが、お金が足りなかった
   通常では「お金が足りません」等を表示させるのが一般的です。
   こういうのも個人的には論理エラーとして扱っています

  ・認証に失敗した
   あまり表に出る機会は少ないのですが、大抵のアプリは裏で色々やっています。
   主にセキュリティ的な面で起きることが多いと思います。

3.通信が一定時間帰ってこなかった
 通信が一定時間のうちに帰ってこなかった、良く言うタイムアウト時に発生します。

 タイムアウトのエラーは非常に面倒なエラーで、これだけで1つ掛けるくらいの内容ですので
 また後日にしたいと思います。

EucalyptusとGlusterFSな話

お久しぶりです。
リプレーションのインフラ担当SE、utunです。

今回はEucalyptus構築の失敗談なんかをつらつら書いていこうと思います。

Eucalyptus と GlusterFS

さて、題名の通りなのですが、EucalyptusとGlusterFSです。

これ、連携出来たらすごいと思いません?
プライベートクラウドを構築したことのある人はきっと皆思ってることがあると思うんです。

ノードサーバのHDDもったいなくね?

ってね。
でも実際使いようがないんですよ。

Eucalyptusの場合は、ephemeralなマシン作れば、っつかinstance store使えば多少ノードのHDDも使いようはあります。
でも、正直時代はEBSですよね。
AWSも第二世代タイプは全部bfEBS前提だし、そもそも

instance storeって何?おいしいの?

って感じですよ。
今でも使ってる人いるんですかね・・・?
もちろんswapはephemeralなんでしょうけども。

個人的には、
本気でAWSのサーバ構築するならinstance store使うべきなんじゃね?
って思ってるんですが、まぁでも実際、キツキツのスケジュールの中では開発がおっつかないでしょうな・・・。

ちょっと話逸れましたが、そんな訳でノードサーバのHDDはとりあえずくっついてるだけの状態な訳です。
そこで出てくるのが、

GlusterFS

な訳ですよ。

分散ファイルストレージ。
うん、実に素晴らしい響きだ。

このGlusterFS、3系からはかなり実用的な内容になっていて、
Redhat Storageなんかにも採用されてるかなりガチな分散ストレージソフトなんですが、
完全なオープンソースです。

これを適当なサーバ4台で、RAID1的な感じで試してみたところ、
物理HDDには及ばないものの、十分実用的なレスポンスが出ておりました。
ということで、

EucalyptusのノードのHDDをこれで纏めちまえ!

って事になった訳です。
当然の流れですね。
何が当然なのかわかりませんが。

そんな感じで、EucalyptusのノードのHDDを適当にGlusterFSってしまうテストが開始しました。

Eucalyptus と GlusterFS その結果は・・・

・bfEBSイメージでの性能
⇒ IOPS : 2
・instance storeイメージでの性能
⇒ IOPS : 3

・・・・。
なんも言えね。

え?
フロッピーでももうちょいまともなんじゃないの!?
いや、フロッピーのIOPSとか計った事ないけども!

うん。
まぁ起動はします。
Webサーバとかは全然動きますよ。
メモリ上で動く分には関係ないしね。

DB?
あぁドラゴンボールね。
僕も小学校の頃はよく見てたなぁ。

結論

EucalyptusとGlusterFSを同時に使用すると、
動悸、息切れ、めまい等の症状が現れる事があり、
深刻な場合は虚脱感により仕事に手が付けられなくなる事があります。

これらの症状が見られる場合は速やかに医師の診断を受けるか、
GlusterFSを停止してください。

蛇足

うちの会社の近くに「葬想空間スペースアデュー」ってのがあるんですが、
そこの前を通りがかったらすごいフェアやってました。

終活フェア

 

spaceadue