フェールオーバーに失敗

図3●RAC採用でフェールオーバーの時間を短縮 旧システムは，クラスタリング・ソフト「Microsoft Cluster Server （MSCS）」を利用した，Active/Standby型のクラスタ構成。しかし，フェールオーバーに要する時間が5分と長かった。新システムでは，スケールアウトによる性能向上を重視してRAC（Real Application Clusters）を導入。フェールオーバー時間も短縮できた

図4●ワームの影響でシステムが不安定に 2003年11月，予測系システムのAPサーバーに，同年6月に発生したワームが侵入していたことが分かった。ワームが発する大量のトラフィックの影響からか，DBサーバーへの書き込み処理が失敗していた。しかし，ネットワークの不具合と見誤っていたため，ワームの発見が遅れた

　RACの採用には，可用性を向上させる目的もあった。旧DBサーバーではクラスタリング・ソフト「Microsoft Cluster Server」を利用して，Active/Standby型のクラスタを構成していた。しかし，フェールオーバーに要する時間が5分と長く，「2002年4月にはフェールオーバーに失敗し，Standby側のOracleが起動しないことがあった」（ヒスコムの渡辺氏，図3[拡大表示]）。

　RACの導入に当たって，富士通は2ノードのRACで十分としたが，さらに耐障害性を高めるために1ノードを増やし，3ノードでRACを構成した。「フェールオーバーも何度か経験したが，RACでは瞬時に切り替わっている」（同氏）と，狙い通りの効果を上げている。NetfinityからPRIMEPOWERへのリプレースは，2003年6月に実施。初稼働から2年で基幹システムから退いた1億円のNetfinityは，別システムに転用している。

ワームの被害を見誤る

　予測系システムの統合が進む2003年11月，APサーバーにワームが侵入していたことが分かった（図4[拡大表示]）。そのワームは，Windows NT系OSに感染を広げる「BAT.Mumu.A.Worm」。大量のトラフィックを吐き出すため，ネットワークの負荷が高まる。

　通信系システムは，ワームが発する大量のトラフィックの影響か，ネットワーク経由でDBサーバーにデータを書き込む処理がしばしば失敗した。

　ワーム侵入の兆候は清水氏のクライアントPCにも出ていた。「サーバーにつながらず，OSをフォーマットしても通信が途切れる。2回もPCを買い替えたが状況は改善されなかった」。清水氏は「ウイルスではないのか」と疑い，渡辺氏らに問い合わせた。

　ところが，こうした状況をヒスコムはネットワークの不具合と見誤った。「まさかウイルスとは思わなかった」（渡辺氏）ことがワームの発見を遅らせた。そもそも，クライアントPCのウイルス対策は施していたが，「サーバーのウイルス対策という基本的なことが漏れていた」（清水氏）。ワームは発見後にAPサーバーから駆除したが，レジストリの値を変更する作業に誤りがあったせいか，その後もソケット通信が失敗する現象が続いた。1カ月後にサーバー機を入れ替えて対処した。