2014年12月14日(日) - 22:08 | カテゴリ:
Linux
今回は久々に本気の冗長構成を作ってみた。
事の発端はテストとして構築したProxy(Squid)が片肺運転だった為。
その為、自分でProxyを使っていても仮想環境の基盤側を弄る度にWebブラウザのProxyを外す必要があった。
しかし、んな事を毎回やるのも面倒臭くなり、
「だったら、自鯖1号2号で冗長Proxy作っちまえばいいか!!」と軽く考えたのは2ヶ月前(´・ω・｀)
という事で、2台以上で冗長化を視野にいれつつ、ついでに負荷分散の仕組みも入れて構築してみた。
※トポロジアイコンにINTEROP 2014の物を使わせて頂きました。
今回の構成は上図参照。綺麗な構成図だろ… これ自宅(寝室)なんだぜ…
L2SW(緑のアイコン)間はEthernetChannelを組んでおき、ルータ間はHSRPを使用。
肝となる負荷分散にはHAProxyを二台構成に、HAProxyの代表IPとしてPacemakerによるEIP振り分けを行った。
構築方法メモ
今回はメールシステムを組んだ時以来の難航作業だった(´・ω:;.:…
というのも、何処を探してもPacemaker+HeartBeatの構成は見つかるのだが、
具体的なPacemaker+Corosyncの構成が見つからなかった。
なんでCorosyncに拘ったのかと言うと、今回の構築ディストリがCentOS7であり、
yumで突っ込めるのがPacemaker+Corosyncだった為。
「yumでバイナリが用意されている = ソースから入れる事も可能」という安直な発想から突撃をしてみた。
その結果、1からドキュメントを読み直し、ソースをビルドし、ミドルウェアを連携させ、
コンフィグとinit(systemd)も自作するという果てしない道のりを歩んでしまった。
一番大変だったのは、Corosyncのビルド。はい。初っぱなから躓きました…
自分はソースビルドを行う時はprefix指定を行い、その中に全部突っ込むやり方をよくやるのだが、
Corosync+Pacemakerの場合は一部インストールディレクトリを変更してやる必要があった。
また、今回使うミドルウェア群はローレベルで読み込ませる必要もある為、
バイナリも"/usr/sbin"から拾える状態にする必要があったりと、
今までに自分の経験した事の無い構築手法をやる必要が出てきてしまった。
結果としては、prefix指定を行いながらも"/usr/sbin"からシンボリックリンクを張る方向で
なんとか落ち着かせる事ができ、バージョン管理(切り戻しなど)も行える構成に持って行けた。
………
冗長構成を組む際、本来ならインターリンクを使って本気で作ってやる必要があるのだが、
今回はNICが物理的に足りなかったり、単純な負荷分散装置としてProxy以外でも使いたかった為、
敢えて1物理鯖1NIC構成で構築を行った。結果として、これがまた面倒な事になった……(´・ω・｀)
Pacemakerでインターリンクを使わない場合、クラスタノードを探しだす処理にマルチキャストを使うのだが、
"ns-lab BB"の鯖では諸事情でマルチキャストを全遮断しているので、上記の構成が使えなかった。
その為、今回はユニキャストによる決め打ちでノードを探し出す設定に変更。
ユニキャストの設定方法は色々と見つかり、例を元にアレンジも加えつつコンフィグ作成を行ったのだが、
いざPacemakerとCorosyncを起動してもcrmshでノードが拾えないという始末。
駄目だった原因はcrmshより上位層である、
そもそものPacemaker+Corosync連携でミスっていたという悲劇。
この原因を突き止める為に3週間くらいかかってしまった。
………
そんなこんなでcrmshとpcsのどっちを使うか問題とか、
Pacemakerで割り当てたEIPにping送っても戻りが無くて、(´・ω・｀)としていたりとか、
色々と回り道をしつつも、なんとか冗長負荷分散Proxyを常用可能なレベルまで持っていく事が出来た。
冗長構成+負荷分散を一度でも構築した経験があれば、
NAT環境下でのサーバ冗長化も工夫次第で作れるし、色々と良い経験になった。
"ns-lab BB"配下は、シングル構成なシステムも何個かあるので、
これを気にシングル構成脱却を行っていきたい所。
« 続きを隠す
2014年12月06日(土) - 17:26 | カテゴリ:
Linux
プライベートクラウド：企業内部門やグループ会社などにクラウドサービスを提供する形態の事
↑の環境を「自宅サーバで構築したらどうなるのか」というのが今回のお題。
自宅でクラウド環境を構築するとなると、OpenStackを使った本格的な物から、
Hyper-Vを使ってWindowsクラスタリングみたいな事をする物まで様々な選択肢がある。
それこそ、企業でやるならVMwareを使ったり、必要な時だけ使えるAWSとかもあるが、今回は置いておく
その中でも、"自宅で構築する"という面でオススメなのが、
KVM+HAProxy+Pacemakerを使った、負荷分散型の仮想"なんちゃって"クラウド環境。
というのも、HAProxyを入れている事によって、比較的自由度の高いロードバランシングが可能な事と、
仮想環境の強みであるサーバのコピーによる増殖が可能だから。
そりゃ、金かけてVMwareとか入れられる人はそっちの方が断然良いのだが、
自宅でやっている程度なので、そこまでガチのシステムを組む金も無いわけで(´・ω・｀)
先の通り、サーバをコピーした場合でも、
上位に設置したHAProxyを使って分散とかも可能になるのが本構成の強み。
単純なhttpサーバなら、負荷がそこまで高くなる事は無いと思うのだが、
PHPとMySQLを元にブログとか公開してると、この読込み負荷が結構高かったりする。
ただ、MySQL自体を2+Xの構成にしてしまうとDBの同期が面倒だったり、
負荷分散型にするか、Active/Standby方式にするかと、新しい悩みが出てきしてしまうのが欠点。
その辺りは、レプリケーションを使えば良いのだが、それこそ面倒に…
………
他に自宅クラウド上の仮想サーバメリットと言えば、
仮想サーバ環境のその後を気にせず、システムを壊す事が可能という点。
これのメリットは自鯖屋にとっては凄く大きい。
なんせ、テストでシステムを壊してしまうというのは高頻度で発生するので(´；ω；｀)
その度に稼働中のインターネット公開用サーバを止める訳にもいかず。
wwwサーバならまだ良いが、mailとかDNSとかだったら問い合わせ元にも影響が出てしまうので。
………
と、いう事でMemoWikiの方にHAProxyとPacemakerを使って負荷分散する方法をメモしていたり。
今まではyum一発でやっていたのだが、今回訳あってソースから突っ込む必要があり、これがまた面倒くさい。
早めに書いて、何らかの物をメモしておかねば。
« 続きを隠す
2014年11月03日(月) - 21:40 | カテゴリ:
Linux
サブ自鯖とは言え、久々にやらかしてしまった(´・ω:;.:…
事の発端は"ns-lab BB"のサブ仮想サーバのホストOSをCentOS6.6にアップデートした事から。
サブ自鯖ではホストOS上でkvmを動かしていて、検証環境・DNS・監視サーバ・etcが乗っかっていたりする。
で、(仮想サーバ)台数が多く自作スクリプトを一元管理したいという思惑がある為、
ホストOS上にNFSを構築し、そのディレクトリをゲストOSで見る仕組みになっていた。
昨今ならiSCSIなのだろうが、NFSの方が管理が楽なので自分はNFSを使用中
本来なら、kvmホストOSではハイパーバイザーに徹するのが常なのだが、
自鯖民だと物理リソースの限界もあるわけで、主幹系のサービスだけはホストで動かすようにしている。
そうすれば、メイン/サブのどちらかが不調になっても、ゲストOSをコピーする事でサービスを継続可能なので…
で、今回はここの箇所に問題があった(らしい…)
ゲストOSからホストOS上のNFSにアクセスしていると、
ターミナル上にCPUとkernelのエラーが出だして、
10～60分程度放置するとホストOSがログも出さずにいきなり停止してしまった(´；ω；｀)
最初は、NFS周りのバグを疑ったのだが、どうやらkernelの方が原因らしく、
kernelを一つ前の物にロールバックしたら、元通りの安定稼働に入った。
ちなみに、サブ自鯖で使っていたバグ有り(?)kernelは"2.6.32-504.el6.x86_64"
色々調べてみると、極々少数の環境で発生しているらしく、コミュニティに報告がチラホラと…
この事をGentoo使いの友人S氏に聞いてみたら『多分、kernelのビルドオプションミスじゃね?』と言っていた。
恐るべし、Gentoo使いのkernel友達度。
真相まで調べるのは骨が折れるので調べていないのだが、
"迂闊にkernelのバージョンを上げるとドツボに嵌まる"という、自鯖屋にとっては良い経験でしたとさ(´・ω・｀)
