やっと動きました。。。
MovableTypeが動かなくて、かなり手こずりました。
事の発端はUbuntu Serverを12.04LTSから14.04LTSにアップグレードしたことですが。
Apacheが2.4に上がってたり、
Perlが5.18に上がってたり、
PHPが5.5に上がってたりして、
MovableType5が動かなくなってしまいました。
はい。
仕方無いのでMovableTypeを6に上げて、
Apache直して、MovableTypeのphp/extlib/smarty/libs/Smarty_Compiler.class.phpも
/* replace special blocks by "{php}" */ /* 修正後 */ $source_content = preg_replace_callback($search, create_function ('$matches', "return '" . $this->_quote_replace($this->left_delimiter) . 'php' . "' . str_repeat(\"\n\", substr_count('\$matches[1]', \"\n\")) .'" . $this->_quote_replace($this->right_delimiter) . "';") , $source_content);
/* 修正前
$source_content = preg_replace($search.'e', "'"
. $this->_quote_replace($this->left_delimiter) . 'php'
. "' . str_repeat(\"\n\", substr_count('\\0', \"\n\")) .'"
. $this->_quote_replace($this->right_delimiter)
. "'"
, $source_content);
*/
という感じで直して、、、やっと動いたところです。
MovableTypeはバージョンアップする度に全てのテンプレートを一度リセットしないと、どこかに綻びが出てしまうのが悩ましいところですね。いっそのこと全部データベースに持ってくれて、アップデートしても影響無いようになっていると嬉しいのですが。
# まだまだ、あっちこっち死んでる気がするけど。
これまで(UbuntuでProxyサーバロードバランス(1)、UbuntuでProxyサーバロードバランス(2))構築したとおり、Ubuntu Server 12.04LTSを使ってロードバランサーを構築し、Proxyサーバの負荷分散、障害検知と自動での切り離し、組み込みを動作させるところまで構築しました。
残った問題である、ロードバランサーがダウンしたときに結局システムが止まってしまうという問題に対処するため、ロードバランサーをクラスタ構成してみようと思います。
クラスタ構成と言っても色々ありますが、今回はkeepalivedのVRRPをそのまま使ってロードバランサーをActive / Standby型のクラスタにしてしまいます。
単純にロードバランサー2を追加します。そしてProxyサーバの仮想IPアドレス(192.168.100.10)をVRRPによるフローティングアドレスにしてしまいます。
PROXYサーバをLinuxのLVS(ipvsadm)を使って冗長構成にする事を考えました。
LVSは既に使っている(RedHat Enterprise LinuxでWebサーバロードバランス)のですが、ここではWebサーバのバランシングではなく、Proxyサーバのバランシングを行います。
また、前回の検証時はRedHat Enterprise Linux ES3を使って検証を行っていましたが、今回はUbuntu Server 12.04LTSを使います。ipvsadmがディストリビューションに含まれているため、それにあわせてファイルの配置が変更になります。検証機も実機ではなくESXi上に立てることにします。
今回も目的はProxyサーバの耐障害性の向上で、負荷分散を目的とはしていませんが、構築の順序としては負荷分散機能(ipvsadm)→耐障害機能(keepalived)となります。
※Proxyサーバの仮想IPアドレスは192.168.100.10にする
論理的にはロードバランサーがクライアントからの要求をすべて受けて、2台のProxyサーバに振り分ける構成になるため、図のようにロードバランサーの配下にProxyサーバ2台がぶら下がる構成になります。
物理的には同一セグメントでフラットに接続されている構成になります。
ロードバランサーの構成をNATにしてしまうと、ProxyサーバのアクセスログにクライアントのIPアドレスではなく、ロードバランサーのIPアドレスが記録されてしまう弊害がおきるため、構成はDSRにします。この構成の大きなメリットが2つあり、1つ目がソースIPアドレス(クライアントのIPアドレス)がそのままサーバに伝わることと、戻りパケットの処理にロードバランサーが介在しないことで、ロードバランサー自身の負荷が少なくなる事です。 デメリットはリアルサーバ側に若干細工が必要になることですが、今回はPROXYサーバも自前のため、デメリットになりません。
Proxyサーバの待ち受けポートは8080を使用しています。
自宅サーバ(ATOM - Intel D510MO)にUbuntu Server の64ビット版をインストールして運用させてたのですが(
自宅サーバ リプレース)、ESXiが5.0になって蟹を認識するようになったとのことで当初の計画通り仮想化(ESXi)する事にしました。
当初の計画としてはD510MOにESXi4.0をインストールして、それまでSolaris10の仮想化(コンテナ)で動作させていた仮想サーバ群をそのまま移行する事を考えていたのですが、D510MOに搭載しているNIC(蟹さん)がESXiで動作しない・・・無理矢理、蟹のドライバ(oem.tgz)を入れて動かすという荒技もあるようですがNICが安定動作しないという情報もあって頓挫・・・という事情もあって、Ubuntu Serverの64ビット版で全部のサービスを一気に動かすという無理な移行をしました。
動作させているサーバというと、
・内部DNSサーバ×3台(自宅内でVlan毎に別のDNSドメインにしているため)
・外部DNSサーバ×2台
・メールスプールサーバ(ごく普通のメールサーバです)
・メールリレーサーバ(Clamsmtpdでメールのウイルスチェックをさせています)
・Proxyサーバ(Havpでウイルスチェックさせています)
・ブログサーバ(・・・このブログです。唯一重いサーバです。)
と、元々仮想化していたサーバ群なので、負荷的には全然軽いサーバばかりです。
仮想化していたサーバを1台に無理矢理集約していたのでDNSサーバが面倒な構成になっていて、外部と内部向けのDNSが共存していることと、内部向けに個別のDNSドメインが存在しているからViewを使ってしまうとスレーブサーバのゾーン転送が難しくなることから、サーバ内に個別のBINDを立ち上げて運用させていました。そして、どうしてもNICが2枚は必要だったのでIntelのPCI NIC(82541PI)を増設していました。