PR

図2●安価なサーバーで冗長化と拡張性を重視した構成に
既存システムでは,1つのUNIXサーバーに複数の機能をまとめて配置する構成を採っていた。新システムでは,IAサーバーを用いて(一部UNIXサーバー),機能をサーバーごとに分割し,スケールアウトしやすい構成にした。信頼性向上とともに,コスト・ダウンを図った
写真1●同プロジェクトを担当した,ぷららネットワークスの主要メンバー
ネットワーク管理部 リーダー 安達伸哉氏(左),技術開発部 リーダー 千葉正彦氏(右)

すべてのノードを冗長化

 サーバーのダウンは頻繁に発生したものの,システムは一度も止まらなかった。UNIXサーバーと比べて安価なIAサーバーであることを生かし,冗長性と拡張性が高い構成を採っていたからだ(図2[拡大表示])。信頼性を維持しながら,トータル・コストも安くする,という一石二鳥を狙ったものである。

 既存システムでは,SolarisなどUNIXサーバー1台に,メール配送,メール蓄積,ユーザー管理の機能を集約していた。それを複数台設置してシステムを構成する形だった。

 新システムでは,各機能をそれぞれサーバーごとに分散して配置する。これによりメール配送(MTA:Mail Transfer Agent)のサーバーは負荷分散装置を用いて処理を振り分けることで,冗長化と拡張性の両方を同時に実現できた。

 一方,メール蓄積(スプール)の機能は,メール配送のように負荷分散装置で冗長化はできない。冗長化のためにはクラスタリングが必要になる。メール配送と違い,共有ディスクにユーザーのデータを書き込むため,メールのユーザーごとに利用するサーバーを固定しなければならないからだ。

 スプール・サーバーにおける拡張性は,クラスタ化したサーバー群を複数用意して実現する。LDAP(Lightweight Directory Access Protocol)で管理するユーザー情報を使って,各ユーザーを各サーバーに割り当てている。

 同様にLDAPサーバーもクラスタリング構成を採った。さらに,ディスクもSAN(Storage Area Network)構成で冗長化している。システムすべてのノードとネットワークにおいて,冗長化を図っている。

経路の複雑化で問題発生

 ただ,ノードやネットワークが複雑になると,これまで経験したことのない思わぬ問題も発生する。問題は,バックアップ・システムの検証時に見つかった。バックアップ・データの転送速度が想定の1/10以下になってしまった。

 意外な事象だった。単一スプール・サーバー分のバックアップであれば問題なかったが,複数スプール・サーバーのバックアップで問題が起きた。「単一サーバー分では起こらなかったので,かなり慌てた」(鴨志田氏)。

 複雑な構成が問題の裏側にあった。SAN構成はFC(Fibre Channel)スイッチの経路を2重化し,各サーバーから共有ディスクへの経路も,2台のFCスイッチどちらでも通れる形になっている。複数サーバー分のバックアップの場合,この経路がバックアップ中に頻繁に切り替わり,そのオーバーヘッドが全体のパフォーマンスを大きく低下させていた。

 切り替わりの原因として,SAN構成の設定が考えられた。各スプール・サーバーが使えるRAIDのディスク・ボリュームは固定されており,他のサーバーが使うボリュームは見えない。しかし共有ディスクからテープ装置にバックアップを実行する際は,バックアップ・サーバーからすべてのディスク・ボリュームをアクセス可能な設定にしていた。この設定のギャップにより,切り替わりが発生しているとにらんだ。結果として,各スプール・サーバー側でSAN内のデータ経路も固定するように設定を工夫し,パフォーマンスの問題を解決した。

Linuxの適用範囲は広がった

 様々な問題点に直面しながらも,「Linuxの採用はコスト・パフォーマンスが高い。思ったよりも安定している」(千葉氏)という評価だ。ただ,Linux一辺倒にはならない。今回もウイルス・チェック用のサーバーには,UNIXサーバーを利用した。「ウイルス・チェックは新システムの重要なサービス。サポートを最優先に考慮した」(千葉氏)。まず,ウイルス・チェックのベンダーを日本市場でのサポートの充実度で選択した。そのベンダーの開発実績からUNIX版が安定していると判断し,UNIX版を採用することに決めた。

 今後のシステム構築においても,これまで通りUNIXとLinuxを適材適所で選択していく。ただ今回の内容から「Linuxの適用範囲がこれまでより広がった」(千葉氏)と見ている。

(森側 真一=morigawa@nikkeibp.co.jp)