ふたつの川うるおう日記
2006-07-02 (Sun)
_ [Seasar][Project][Admin] Seasarのサーバにあった冗長性のある最適な環境
Seasarのサーバにあった最適な環境を考えてみます。まず現在提供しているサービスを挙げます。
- プロジェクトサイト閲覧
- SVNリポジトリ閲覧
- SVNリポジトリコミット
- SVNリポジトリブラウザ
- イベントサイト閲覧
- イベントサイト編集
- Wiki閲覧
- Wiki編集
- トラッキング閲覧
- トラッキング編集
- 検索エンジン
- メーリングリストアーカイブ
- メーリングリスト配信
- Mavenリポジトリ閲覧
- Mavenリポジトリデプロイ(SCP接続)
- メンバー用ページ
このうち書き込み処理が発生して、かつ頭の良いロードバランサじゃなくてDNSラウンドロビンのような簡易バランサにおいて、アプリケーションレベル(メモリ上)でのロックが必要になりそうなのは、次のサービスだと思われます。
- SVNリポジトリコミット
- Subversion + WebDAVのロックの仕方によっては大丈夫っぽい
- メーリングリスト配信
- メールサーバ自体のクラスタリングは問題ないが、メーリングソフトが謎
- Mavenリポジトリデプロイ(SCP接続)
- 問題ないけど、ホストが変わって新しいサーバ公開鍵だと承認のYes/Noが最初の1回出る可能性がある。サーバ公開鍵を同じのにしちゃうという手もあり。
上記だけ別ホストにすれば、残りはクラスタ化しても問題なさそう。そんなわけで、次のような構成にすると良さそうです。
- 概要
- SANでデータ一括管理
- ファイルシステムをGFSにして、複数サーバで同時に読み書き実現
- GFSはGoogleも改造して一部で使ってる分散ファイルシステム。
- リモートでの復旧を考慮して実サービスはXen上に展開
- ハード構成
- ストレージアレイ * 1
- SANスイッチ * 1
- 物理サーバ * 3
- Xenゲストサーバ構成
- xen01 (GFS + SAN)
- フロントサーバ1
- 書き込み用サーバ1
- xen02 (GFS + SAN)
- フロントサーバ2
- 書き込み用サーバ2 (xen01が死んだ時用の予備)
- GFSロックサーバ1
- xen03 (非 GFS + SAN)
- データバックアップサーバ
- xen01 (GFS + SAN)
この構成であれば、普段はフロントサーバ1, 2をDNSラウンドロビンで回し、書き込み用はどちらかの書き込み用サーバにアクセスさせておいて、障害が起きたらDNSラウンドロビンを止めるのと書き込み用サーバのアクセス先をもう1台に変えれば良い。もしくはフロントサーバの前にPoundだけが走るXenゲストサーバを走らせれば、障害時に自動的に読み込み用サーバへのアクセスを制御してくれる。もしくはもっと大規模にいくならUltraMonkey?。さらに負荷が高まったら単純にフロントサーバ足せば分散できる環境です。
ただ、この構成の場合の問題点もあります。
- SAN構成が高い
- ストレージ
- SANスイッチ
- ファイバチャネル
- iSCSIなら安いがパフォーマンス落ちる
- GFS + SAN構成をするのに同一ネットワーク内でないとツライ
- 同一ネットワークでのGFSのパフォーマンスは通常のext3などのファイルシステムの80%程度らしい
- どこかのデータセンタに一極集中してしまう
- SAN構成部分に冗長性がない
- やろうと思えばできるけどさらにお値段アップ
- データバックアップサーバをどこか別の回線が早いとこに置けば、緊急時はそっちで読み込み用サービス可
そんでもって、ほんとにここまでの環境が必要かどうかだけど、たぶん将来必要になるかと。問題はこのリソースを提供してくれるとこがあるかどうか(;´ー`)。また、SeasarじゃなくてもYukaraで必要なんじゃないかなと。
この構成案は今ある技術で考えたもので、実際に試してないので穴や罠があるかもしれないです。また、これ以外にもGoogle、SourceForge、Slashdot、はてな、mixiなどいろんな方法で分散環境を昔から構築されているのでどうやってるのか興味深いです。たまに講演とかニュースでちょこっと話題になることがあるけど、ほんのちょっと話してるだけなので聞きたいことがいろいろ。。
そんなことより、Seasarサーバの復活はやはり月曜になりそうです。コミッタの皆様、もうしばらくお待ちくださいm(_ _)m。こういった障害時のこと考えると、Xen上かいつでも現地対応できる環境は必要そうです。
[追記] DB関係考えてなかった。そこはまた別にレプリケーションの仕組み用意ってことで。
[追記] GFSにDB(PostgreSQL or MySQL)載せたらどうなんだろって調べてたら、GFSについて(eyes blogさん)という良い記事がありました。これによると2台でGFSは危険っぽいかも。
2006-07-03 (Mon)
_ [Seasar][Server][Admin] 復活
復活した模様です。OOM Killerがヒットしてくれました。。
Jul 3 03:34:43 app02 kernel: Out of Memory: Killed process 4115 (httpd).
動作確認中...完了。
不具合等ありましたらご連絡ください。ご迷惑をお掛けいたしました。
_ [Seasar][Server][Admin] rdiff-backup
サーバが死んでる間、rsyncが困ったさんなんだろうと思い、別のバックアップツールを探してました。それでrdiff-backupを使ってみようと思います。試しに手元のサーバで試してみたところrsyncより全体の処理速度は遅いものの実行中に一定ファイルごとに処理しているのかメモリの使用量が増減し、実行完了後にちゃんとメモリ領域が実行前と同じぐらいに戻ります。rsyncは一気に減り続ける&なぜか実行後元に戻らない・・・ -> メモリ不足 -> 死亡。。しかも、rdiff-backupは差分バックアップや、ファイル所有者情報、ACLまで一般ユーザでのリモート接続先にバックアップしてくれます。ただ、問題が1つあって、ファイル転送中にバックアップ元のファイルが更新されると転送終了後の検証でエラーとなり、せっかく転送したファイルを削除しちゃいます。MLを眺めてみたところ、作者さんのポリシーでこれはこれで正しい動作としていて同じ問題を抱えた人が結構いました(;´Д`)。これだとApacheのログファイルとか明らかに転送に時間掛かって、尚且つ、更新が頻繁なファイルは永遠にバックアップ取られなくて困る(ログローテートされたのは取れる)ので、転送後のファイルチェックを飛ばすパッチ(超ひどいパッチ)を当てて逃げました。ついでにRPMも作って置いてあります。
というわけで、今日の夜、Seasarサーバに投入します。rsyncはファイル数が膨大だとダメダメっぽいです。ついでにrsyncをバックエンドで使ってるたくさんの差分バックアップツールも危険だと思います。
2006-07-07 (Fri)
_ [大学] 検証タスク
- LDAP Syncでスレイブに複数設定できるか
- Active Directoryの認証にOpenLDAPをIdentity Intregration Serverで統合できるか
- OpenLDAPのNTHash、LMHashをActive Directoryに移植できるか
- Rembo Technology製品がSymantec Ghostの代わりになるか
- CAI製品が使えるかどうか
- GFSの構築予行練習
- LinuxでソフトウェアiSCSI + GFSでうまく動くか
後輩の皆さん分担よろしく。
_ [Server][Admin] サン、2007年半ばまでにSolaris 10をXen対応に
SolarisもXenで動いちゃうようになるなんて素敵だ。
さらに、「現在稼働しているSolaris 10システムの約30%がコンテナを利用しており、そのうち3分の1はSPARCを、3分の2はx86ハードウェアを用いているという。」にもっとびっくり。コンテナ利用する時だけの話だけど、もうx86版が主流になってたんだね・・・。
でも大学的には、SolarisというOSより、SPARCアーキテクチャが研究に重要な場面があるので、今後もうちの大学にはSPARCマシンが残りそう。
_ [Client][Admin] Client-Side Caching Command-Line Options バージョン 1.1 コマンド ライン ツール
1.0はダウンロードできるものの /DELETE オプションが使える1.1はサポートに電話する必要があって、貰うのに有償サポートになるらしい。というわけで、MSDNのインシデント初めて使いました(;´ー`)。
[追記] 後輩がC++で組んでくれたので不要になりました(素晴らしい!)。また必要になるかもしれないので、CSCCMDは貰うだけ貰っておこう。
2006-07-11 (Tue)
_ [雑記] 2Advanced Studiosリニューアル
何年かぶりにリニューアルされてるーー。しかも日本語対応してるーー。IMJと提携したからそこが日本語対応したのかな。ローディング長いけどカコイイ。
2006-07-17 (Mon)
_ [Server][Admin] Apacheのインデックス表示
カスタマイズ楽しい。
Options +Indexes +Includes IndexOptions +FoldersFirst +SuppressHTMLPreamble IndexIgnore custom.css HeaderName /HEADER.shtml ReadmeName /README.shtml
- [追記] SeasarのMevenリポジトリの例
2006-07-20 (Thu)
_ [Server] OpenLDAP 2.x/2.3 の LDAP Sync
OpenLDAP 2.xで導入しました。slurpdと一長一短なところもありますが、LDAP Syncの方が便利です。
slurpdは、マスタ側にスレイブ側の接続先設定があるので、マスタに更新が掛かると、マスタがスレイブに差分をpushします。ただし、このときスレイブの現在状態は関与しないので、同期が崩れていると更新に失敗し、以降も同期が取れてない状態になる欠点がありました。
そこでLDAP Syncです。LDAP Syncは、OpenLDAP 2.2以降で使えます。LDAP Syncではコンシューマ(スレイブ)側にプロバイダ(マスタ)側の接続先設定を持っています。
refreshOnly モードでの同期の場合、コンシューマ側がプロバイダ側にinterval値ごとに差分を取得(pull)して同期します。コンシューマ側からの挙動なので同期が崩れる可能性はslurpdに比べてだいぶ減ります。また、コンシューマとプロバイダで同じツリー構造である必要もありません。指定した部分のみの同期などもできます。ただ、interval値ごとに差分を取得するので、これだと今度は同期されるまでのタイムラグが出来てしまう問題があります。
そこでrefreshAndPersistモードを使うと、コンシューマはプロバイダ側にセッションを張ったままにして、プロバイダは更新が掛かると、セッションの維持されたコンシューマに直ちに差分をpushしてくれます。
ただ、これにも罠がありました。プロバイダ側を再起動したり、ネットワークが途切れたりしてコンシューマ側からのセッションが切れた場合、プロバイダ側はコンシューマ側の情報を持っていないので、差分をpush出来なくなるみたいです。てなわけで、最小時間で同期されてないと困る場合はrefreshAndPersistモードであっても、interval値を小さめの値で設定しておいて、このような場合であってもすぐにセッションが再接続されるようにしておかないとダメなようです。
slupdの場合、マスタが差分のみをスレイブにpushするので、スレイブを構築する際、マスタ側のldapのデータフォルダを丸ごとスレイブにコピーする必要がありますが、LDAP Syncの場合、コンシューマ側は空の状態でslapdを起動するだけで、マスタ側にすべてのエントリを取得しに行ってくれるので新規構築や復旧が楽です。また、上記で述べたように、コンシューマサーバが落ちてる時間帯があっても同期が崩れないので、保守性や耐性を考えてもLDAP Syncの方が便利だと思いました。
上記は大雑把に書いているので嘘が入ってるかもしれないのです(´ー`;;;)。詳しい挙動はドキュメントをどうぞ。
2006-07-21 (Fri)
_ [Server][Admin][Seasar] ViewVC
ViewCVSがViewVCに名前変わって(たぶん1.0.0から?)、1.0.1がリリースされてました。
とあるとこのサーバでViewVCが動かないヘルプで見てみて動かしたんですが、動作がかなり軽快でした。SeasarのサーバでWebSVNが負荷で停止させたのでViewVCに移行してみようかなと思います。ViewVCが軽快な理由は、SWIG経由でリポジトリにアクセスしているから + mod_pythonで動かしているからだと思います。WebSVNは内部でsvnとsvnlookコマンドを毎回呼び出すので、APCなどのキャッシュ使っても意味がなく、かなり無駄があり、遅くて負荷が掛かるんだと思います。
ただ、ViewVCデフォルトの見た目があんまカッコよくないんだよね(´ー`;;)。
時系列でのログ表示がないっぽい。




_ masataka_k [日曜お昼までは姫路に居るけど、夕方から大阪にいるよん。]
_ jfut [奇遇でしたね、お誘いいただいたのに会えなくて残念でした。]