アスキービジネス

ホーム > アスキービジネス > エンタープライズ

連載コラム

コラム

知らないでは許されない
ITILでシステムの効率化を目指そう

2005年8月18日  協力●東芝ソリューション

第4回
「クラスタにさえしておけば大丈夫?」~可用性管理を考える~(2/3)



ステップ1 可用性を設計する

 可用性を設計する際には、業務を実現する上でなにが重要な機能かをまず明確にします。ITILではVital Business Function(VBF:重要ビジネス機能)と呼びますが、たとえばインターネットショッピングであれば、お客様から注文を受け付ける部分がもっとも重要で、過去の注文履歴の検索や「本日のおすすめ!」の表示は必須というわけではありません。この場合、VBFは「注文受付」になります。このようにビジネスの観点から機能の優先順位を明確にしておくことは、その後の方針を決める上で重要です。

 次に、システムの脆弱性の分析を行ないます。脆弱性は障害が起きた場合に代替パスがなく、サービスを止めてしまう「SPOF(Single Point Of Failure、単一障害点と呼びます)」を調べます。また、SPOFで障害が起きた場合、業務にどのくらいのインパクトがあるかを前述のVBFと照らし合わせることにより、システムの中でリスクの高い箇所を特定することができます。

 事例のケースではVBFは注文受付であり、注文受付系のサーバやネットワークが障害を起こすと、大きなビジネスインパクトが出てしまいます。サーバはサービスを提供するもっとも重要なコンポーネントですから、クラスタ構成にして対障害弾力性を引き上げることで、SPOFを排除しています。もちろん、サーバの構成要素であるメモリやディスクに壊れにくい部品を使う(=信頼性)、故障した場合に修理が容易な筐体を選ぶ(=保守性)、あるいはOSのパッチをこまめに当て、最新の状態に保つ(=セキュリティ)、なども可用性を高める上で重要になります。

 さらに可用性設計では、個々のコンポーネントの信頼性や保守性だけでなく、障害を監視するシステム管理等との連携についても考慮する必要があります。事例ではクラスタを導入していたために、1回目のサーバ障害時にはサービスの中断は起きませんでした。ですが、システム管理ツールによる障害管理がきちんとできていないと、サーバ障害の事象を見落としてしまう可能性があります。事例ではまさにその障害ログを見落としてしまい、そのまま片方のサーバで運用を続けてしまったわけです。その結果、障害があったサーバを修理しなかったために、2回目の障害ではシステムが止まってしまったという現象に陥りました。クラスタの導入ももちろん重要ですが、同時に根本原因となるサーバ障害の検出や、障害要因の分析を行なうための監視システムの整備も重要になるわけです。

「ステップ2 復旧を設計する」へ続く

戻る次へ

「ITILでシステムの効率化を目指そう」トップへ「ITILでシステムの効率化を目指そう」トップへ

アスキービジネスのおすすめ
登録は無料!今すぐ登録する方はこちらから 利用者登録がお済みの方はこちらからログインできます
最新ニュース

| ASCII.jp | デジもの | Mac/iPod | 自作PC | 科学技術 | ゲーム・ホビー | 話題 | 情報システム | ビジネス |

| 価格比較 | Microsoft | キャリア | SaaS・ASP | VPN | SHARP | Panaspot | 富士通 | 住まい情報局 |

| EPSON DIRECT | Wireless Gate | アキバ | ムービーフラッシュ | SpeedGun | デジタル用語辞典 | Blogmag | アスキー365 |

サイトポリシー | プライバシーポリシー | 運営会社 | お問い合わせ