念願のActive/ActiveのWebサーバ構成に変更してみた。今回の構成変更に伴い、Primary/Secondaryを表示するようにしてみた。Linux/Source/HAProxy構成変更後の構成図は↑の通り。赤がActiveConnection、緑がStandbyConnectionになっている。LoadBalancerはHAProxy、WebServerはApacheを利用。今回の構成変更で、フロントエンドをロードバランサーに付け替えた。WordPressとリバプロを組み合わせた構成は相性が悪く、ラウンドロビンで分散すると、管理画面ログイン等に問題が出る。いう事で、今回はSourceHashでパーシステンス維持を実装してみた。source]を設定した。LB同士の冗長化は、keepalivedでVRRPを喋らせ、3台の物理サーバ(上の仮想鯖)で1つのVRIDを形成してみた。仮想鯖基盤で使っているリソース監視制御でも使っている為、3台でリッチ過剰に使った。[Apache]リバプロ構成にした都合上、今度はIPアクセス制御とログ書き込みに影響が出たので、[mod_extract_forwarded]を追加する事で、リクエストを上書きして対処した。今回はモジュール追加方式を採用した。[MySQL]最初はNFS上にSQLも乗せようと思ったのだが、ディスクI/Oが足りず断念...古典的だが確実に動作する、Active/Standby方式のDB構成にしてみた。統合DBとして構築しようと思う。[NFS]「NFS構成で行く」と最終判断を下すまでに四苦八苦したのがディスク共有だった。最初はrsync/lsyncで頑張るか検討したのだが、稀にファイル同期が失敗し、ゴミファイルが出来上がってしまったので不採用。次に検討したのが、GlusterFSのレプリカ構成。́・ω:;.:...という事で、最終的に残ったNFSの共有マウントだが、よく使われる構成だけあって、安定かつ、それなりの速度が出たので採用した。柔軟な構成変更が出来るようになった。いうのも、今後はDigiLoogのIPv6対応、SSL完全対応などを目指している為。IPv6の場合はPHPに埋め込んでいる自作IPv4コードとかを変更しなくてはいけないのだが、この作業を出来る限り変更したくないので、フロントでIPv6対応すれば良いリバプロは魅力的だった。応答速度を速める為にCPU負荷を分散(LBへ移行)したかった。今回のDigiLoog構成変更は、2年前に実施したスマホ対応以来の大がかりな作業だった。導入の為に効果測定したGlusterFSの構築に苦労した。頑張ったかいもあって念願のActive/Active冗長化が達成出来たのは良かった。次の構成変更に備えようと思う。