OpenVZのVE上に構築したOpenVZ WEB Panel(owp)を1.7アップグレードしようとしたら、
名前解決出来ないためにwatchdogが起動出来ない → owp 死亡のスパイラルに嵌まった。
VE作成過程は忘れたけど、結局は
/etc/nsswitch.conf
が空ファイルだったことが原因だった。
上記ファイル中に、下記記述を追加して解決した。
....中略....
hosts: files dns
....以下、略。
あまりに単純な原因だったお陰か、
ググっても簡単には解決に継らなかった。
owpの評価は別の機会に。
2010/12/27
2010/12/05
ReverseProxyでまじめにWEBサイト引越し(2)
まず、httpd環境を準備する。
rpafモジュールを追加する。
http://stderr.net/apache/rpaf/
からソースを取得してビルドする。
Apache 1.3
Apache 2.0 以降
設定ファイル( /etc/httpd/conf.d/rpaf.conf )を作成する。
[設定例]
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1
当初はvarnishとか組み合わせてPoCしたかったけど、サービスINまでの時間がなかったので、
旧サイト(Apache) ReverseProxy -> 新サイト( Apache )
としてDNS切り替えまでのタイムラグを凌いだ。
Apache 2.0以降は標準でproxyモジュールが導入されるため、設定ファイルに以下を追記するだけで対応出来た。
rpafモジュールを追加する。
http://stderr.net/apache/rpaf/
からソースを取得してビルドする。
wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
tar xf mod_rpaf-6.0.tar.gz && cd mod_rpaf-6.0Apache 1.3
sed -i 's/$(shell which apxs)\/usr\/sbin\/apxs/' Makefile && make rpaf && make installApache 2.0 以降
sed -i 's/$(shell which apxs2)\/usr\/sbin\/apxs/' Makefile && make rpaf-2.0 && make install-2.0設定ファイル( /etc/httpd/conf.d/rpaf.conf )を作成する。
[設定例]
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1
当初はvarnishとか組み合わせてPoCしたかったけど、サービスINまでの時間がなかったので、
旧サイト(Apache) ReverseProxy -> 新サイト( Apache )
としてDNS切り替えまでのタイムラグを凌いだ。
Apache 2.0以降は標準でproxyモジュールが導入されるため、設定ファイルに以下を追記するだけで対応出来た。
[設定例]
ProxyRequests Off
ProxyPass / http://*.*.*.*/ ( 新サイトのグローバルIP )
ProxyPassReverse / http://*.*.*.*/ ( 新サイトのグローバルIP )
2010/11/14
ReverseProxyでまじめにWEBサイト引越し(1)
WEBサイトを引越しする際、DNSのAレコード切り替え中に旧サイトを参照されると困る。
(MXとSPFは別の機会にする)
特に新旧サイトでCMSが違うとか根本的に変更されていて、指定時間に公開する予定の場合、
DNSに依存するとマズイ。
対応としては、
DBとかインフラが問題になると面倒。
grep一発で切り替え可能であれば、まずまずな方法。
とはいえ、特殊な仕組みを追加する必要もなくてお手軽。
でも...旧サイトと各種OSコンポーネントのバージョンが同じでないと新サイトのインフラがカオス化する恐れ有り。
Java/PHP等でセッションに依存するロジックがあるとやれば出来るけど、色々と大変。
案2は、新サイトと旧サイトが物理的に分離されている為、コンポーネント衝突やインフラ差異による問題はほぼない。
でも...ReverseProxyの為に別途機能追加が必要、かつhttpd graceful的な切り替えが出来ない場合がある。
諸般の都合で案2を試す。
構成的には、
Poundはキャッシュが使えない、でもvarnishはSSLを扱えない。
Pound外してhttpdに直接送ってもいいけど、両Proxyを使ってディザスタリカバリーを見据え、
DNSRR(ラウンドロビン)でアクティブサーバーが生きている内にウォームスタンバイ用サーバーに来たら、アクティブサーバーを引っ張ってる構成の検証するために採用した。
DRBD的な構成が出来れば簡単だろうけど、VPSとかレンタルサーバーではまず出来ないので。
スプリット・ブレインはとりあえず無視しして、まずはPoC。
(MXとSPFは別の機会にする)
特に新旧サイトでCMSが違うとか根本的に変更されていて、指定時間に公開する予定の場合、
DNSに依存するとマズイ。
対応としては、
- 新サイトは、httpd.confでDirectoryディレクティブでギリギリまで旧サイトを運用する。
定時になったら、httpd graceful で新サイトに切り替える。
- 新サイトは、ギリギリまでReverseProxyで旧サイトを引っ張ってくる。
定時になったら、Proxy設定を外す。
DBとかインフラが問題になると面倒。
grep一発で切り替え可能であれば、まずまずな方法。
とはいえ、特殊な仕組みを追加する必要もなくてお手軽。
でも...旧サイトと各種OSコンポーネントのバージョンが同じでないと新サイトのインフラがカオス化する恐れ有り。
Java/PHP等でセッションに依存するロジックがあるとやれば出来るけど、色々と大変。
案2は、新サイトと旧サイトが物理的に分離されている為、コンポーネント衝突やインフラ差異による問題はほぼない。
でも...ReverseProxyの為に別途機能追加が必要、かつhttpd graceful的な切り替えが出来ない場合がある。
諸般の都合で案2を試す。
構成的には、
- HTTP -> varnish -> httpd
- HTTPS -> Pound -> httpd
Poundはキャッシュが使えない、でもvarnishはSSLを扱えない。
Pound外してhttpdに直接送ってもいいけど、両Proxyを使ってディザスタリカバリーを見据え、
DNSRR(ラウンドロビン)でアクティブサーバーが生きている内にウォームスタンバイ用サーバーに来たら、アクティブサーバーを引っ張ってる構成の検証するために採用した。
DRBD的な構成が出来れば簡単だろうけど、VPSとかレンタルサーバーではまず出来ないので。
スプリット・ブレインはとりあえず無視しして、まずはPoC。
登録:
投稿 (Atom)