構成変更後の構成図は↑の通り。
赤がActiveConnection、緑がStandbyConnectionになっている。
LoadBalancerはHAProxy、WebServerはApacheを利用。
………
◆ ReverseProxy [HAProxy]
今まではApacheが直にコネクションを捌いていたのだが、
今回の構成変更で、フロントエンドをロードバランサーに付け替えた。
だが、WordPressとリバプロを組み合わせた構成は相性が悪く、
ラウンドロビンで分散すると、管理画面ログイン等に問題が出る。
という事で、今回はSourceHashでパーシステンス維持を実装してみた。
この辺りの実装はHAProxyに頼り、[balance source]を設定した。
LB同士の冗長化は、keepalivedでVRRPを喋らせ、
3台の物理サーバ(上の仮想鯖)で1つのVRIDを形成してみた。
過剰な気もするが、今回のReverse-Proxy、自宅から外へ出る為のHTTP-Proxy、
仮想鯖基盤で使っているリソース監視制御でも使っている為、
3台でリッチ過剰に使った。
………
◆ WebServer [Apache]
リバプロ構成にした都合上、今度はIPアクセス制御とログ書き込みに影響が出たので、
[mod_extract_forwarded]を追加する事で、リクエストを上書きして対処した。
ログだけの場合は、ログ書き込みのフォーマット自体を変更する手段もあるのだが、
先の通りアクセス制御も書き換えるのは面倒くさかったので、
今回はモジュール追加方式を採用した。
………
◆ Database [MySQL]
最初はNFS上にSQLも乗せようと思ったのだが、ディスクI/Oが足りず断念…
古典的だが確実に動作する、Active/Standby方式のDB構成にしてみた。
本来はクラスタ化するべきなのだが、メンテナンスの為に両サーバを落とした際や、
サーバ間通信が切れた場合のスプリットブレイン対応がキツそうだったので諦めた (´・ω・｀)
DBをクラスタ化する時は、他の自鯖でも使っているMySQL/MariaDBを全て統合する時に、
統合DBとして構築しようと思う。
………
◆ Disk [NFS]
「NFS構成で行く」と最終判断を下すまでに四苦八苦したのがディスク共有だった。
最初はrsync/lsyncで頑張るか検討したのだが、稀にファイル同期が失敗し、
ゴミファイルが出来上がってしまったので不採用。
次に検討したのが、GlusterFSのレプリカ構成。
こちらはサーバのCPUとメモリが非力でGlusterFSのレプリカ処理が追い付かず、
今回の用途では使い物にならなかった (´・ω:;.:…
という事で、最終的に残ったNFSの共有マウントだが、
よく使われる構成だけあって、安定かつ、それなりの速度が出たので採用した。
………
今回の構成変更をしたことで、今後はWebサーバ側を弄らなくても、
柔軟な構成変更が出来るようになった。
というのも、今後はDigiLoogのIPv6対応、SSL完全対応などを目指している為。
IPv6の場合はPHPに埋め込んでいる自作IPv4コードとかを変更しなくてはいけないのだが、
この作業を出来る限り変更したくないので、フロントでIPv6対応すれば良いリバプロは魅力的だった。
というよりIPv6コーディング技術が自分に無いから出来ない (´；ω；｀)
SSLの場合はソース書き換えが必要なのだが、
WebアクセスをWebServerで終端すると、CPU負荷がかなり掛かるので、
少しでも応答速度を速める為にCPU負荷を分散(LBへ移行)したかった。
今回のDigiLoog構成変更は、2年前に実施したスマホ対応以来の大がかりな作業だった。
近頃はPHPを読んで居なかったので『コレ… ダレガカイタンダ…』と思いつつソース読んだり、
導入の為に効果測定したGlusterFSの構築に苦労した。
だが、頑張ったかいもあって念願のActive/Active冗長化が達成出来たのは良かった。
これでWeb自鯖の直弄りは一段落するので、次はIPv6化とSSL化どちらを先にやるか考えながら、
次の構成変更に備えようと思う。
« 続きを隠す
