フェールオーバーに失敗

図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カ月後にサーバー機を入れ替えて対処した。

(井上 英明)