冗長構成システム（クラウド等）の耐故障性に対する検証技術...2014/09/24...

Copyright 2014 FUJITSU COMPUTER TECHNOLOGIES LIMITED

冗長構成システム（クラウド等）の耐故障性に対する検証技術

株式会社富士通コンピュータテクノロージーズＴＭＰ事業部検証ソリューション部表憲一

0

【高信頼化技術適用事例セミナー】

1290ka1


取組みの目的

耐故障性に対する検証の取組み

適用事例

さいごに

本日の内容

1

取組みの目的

Copyright 2014 FUJITSU COMPUTER TECHNOLOGIES LIMITED 2

情報システム

例えば…

インターネットバンキングシステム

営業支援システム、受注システム

部門内の掲示板・ファイル共有システム

クラウドサービス（SaaS, IaaS, …）


データセンター

Storage

Switch

Server

3


システムのモデル分類

求められる要求、例えば

サービス提供時間・・・一日24H、サービスは停止したくない

サービス停止が許容できる時間・・・5分以内かな

でも、ハードウェアの費用が抑えたい

高信頼性が求められるICTシステム

（IPA/SEC 非機能要求グレード説明資料より）

対象となるシステム

4

非機能要求グレード（IPA/SEC）

システム基盤に関する非機能要求を６項目に分類

お客様（ユーザ）とシステム構築ベンダーとの認識を合わせる


大項目要求例確認結果に基づき、実施する対策例

可用性・運用スケジュール・障害、災害時における稼働目標

・機器の冗長化やバックアップセンターの設置・復旧・回復方法及び体制の確立

性能・拡張性

・業務量および今後の増加見積もり・システム化対象業務の特性

・性能目標値を意識したサイジング・将来へ向けた機器・ネットワークなどのサイズと配置=キャパシティ・プランニング

運用・保守性

・運用中に求められるシステム稼働レベル・問題発生時の対応レベル

・監視手段およびバックアップ方式の確立・問題発生時の役割分担、体制、訓練、マニュアルの整備

移行性・新システムへの移行期間および方法・移行対象資産の種類および移行量

・移行スケジュール立案、移行ツール開発・移行体制の確立、移行リハーサルの実施

セキュリティ

・利用制限・不正アクセスの防止

・アクセス制限、データの秘匿・不正の追跡、監視、検知

システム環境・エコロジー

・耐震/免震、重量/空間、温度/湿度、騒音など、システム環境に関する事項・エコロジーに関する事項

・規格や電気設備に合った機器の選別・環境負荷を低減させる構成

5

高信頼性システム（クラウドシステムの例）


仮想サーバクラウド基盤

仮想システム

お客様

ハードウェア

Server

Storage

Switch

インフラ運用インフラ保守 (CE)

サービスポータル

提供サービス

仮想システム

ソフトウェア

クラウド基盤ＭＷ

仮想化ＯＳ

クラウドシステム

システム運用者

アプリケーション

外為等

外為等

外為等手順書

可用性

運用・保守性

性能・拡張性

6


高信頼性システムは、可用性を高める必要がある

可用性（availability）出展：ISO/IEC 25010 (JIS X25010）

『使用することを要求されたとき，システム，製品又は構成要素が運用操作可能及びアクセス可能な度合い。

（ISO/IEC 24765）

注記外面的には，可用性は，システム，製品又は構成要素が作動状態でいる間の合計時間の割合で総合評価することができる。それゆえ，可用性は，（故障の頻度を左右する）成熟度，障害許容性（耐故障性）及び（各故障後の停止時間を左右する）回復性との組合せである。』

障害許容性（耐故障性）（fault tolerance）

『ハードウェア又はソフトウェア障害にもかかわらず，システム，製品又は構成要素が意図したように運用操作できる度合い。』

実現する方法が「冗長構成システム」

高信頼性を高めるためには

7

運用系待機系


可用性を高めるためには

ハードウェアは壊れるもの ⇒ 故障に備え、対策を打つ

可用性を高めるための冗長構成システム

耐故障性 - 自動フェイルオーバー

fail-over データ保全性

- 冗長化ディスク構成 - 筐体間ミラーリング

冗長化

…

冗長化

…

冗長化

…

冗長化

…

mirroring

ハード・ソフト・構成／設定の組み合わせにて実現

ハードウェア

OS・ミドルウェア

業務アプリケーション

fail-over

業務業務

CPU故障

再起動

業務アプリケーション

監視サーバ

ハードウェア

OS・ミドルウェア

8

システム二重化

サーバ故障：自動（数分）

スイッチ故障：自動（数分）

ストレージ故障：自動（数分）

機器の費用：高

クラスタ二重化

サーバ故障：自動（数分）

スイッチ故障：手動（数十分）

ストレージ故障：手動（数時間）

機器の費用：中

冗長構成システムの例


Server #1 Server #2

Switch

Storage

Switch #1

Storage #1

Server #1 Server #2

Switch #2

Storage #2

9


単一障害点（SPOF : Single Point of Failure）

該当箇所に故障が発生した場合、システム停止となってしまうコンポーネント。

冗長化は、機器購入のコスト増のほか、システムの複雑化や機器の故障発生回数の増大、検証・運用のリスクなどが増加する側面がある。

SPOFを許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目となる。

高信頼性システムでの注意点

非機能要求グレードでの合意形成が必要

SPOF

Router

Server

アプリケーショ

ン

10


報道された障害（IPA：SEC journal より）

ハード機器障害の他、構築（設定・結線）誤りや保守作業（手順）誤りなど非機能要求に関わる障害が定常的に発生している

情報システムの障害状況

0

5

10

15

20

25

30

前半後半前半後半前半後半前半後半

2010 2011 2012 2013

その他

保守作業（手順）

構築ミス

ハード機器障害

ソフトウェア障害

11


各プロセスでの問題の作りこみ要因と問題検出漏れ

非機能要求に関する障害の原因

№ 開発プロセス／検証プロセス

作り込み要因検出漏れ要因

1 要件定義／運用テスト

・復旧手順書の作成不備・実システムでの確認不足・確認手段の不足

2 システム設計／検証・受入テスト

・冗長構成・監視箇所の考慮不足・異常時の動作仕様が入手困難・ハード/OS/MW設定値の考慮不足

・確認観点の不足・確認手段の不足

3 環境構築／構築確認

・物理結線ミス・監視設定ミス・OS/MW/仮想Net設定ミス

・人手による確認の限界・自動チェックが困難

（ヒアリング結果等からの弊社独自まとめ）

12

非機能要求グレードの課題

システム開発のＶ字モデル


要件定義

システム設計

環境構築構築確認

検証・受入テスト

運用テスト

非機能要求に対する妥当性確認の手法確立

検証

検証

要件の妥当性確認

非機能要求グレードを活用し、要件を定義

異常系を中心としたテストをする必要あり

13

耐故障性の検証の取組み


妥当性確認の視点


ハードウェア障害（＝耐故障性）からの視点で検証

15

耐故障性を検証するための取組み

1. 検証項目の抽出

非機能要求グレード項目をベースに網羅性を確保

運用者、利用者からの視点を考慮

運用手順書等の人が介入する部分も含めて確認

2. 検証実施の流れ

運用計画を含めた、時間軸での検証

3. ツールの整備

耐故障性の確認に必要なハードウェア故障の実現

検証の実施難易度の低減



非機能要求グレードから検証すべき項目を抽出

運用者や利用者からの視点で考慮すべきポイントを検討

〔取組み１〕検証項目の抽出（１／２）

№ 大項目中項目指標検証で考慮すべきポイント

1 可用性継続性稼働率・RTO等結果から稼働率の確認

2 サービス切替時間・サービス復旧時間（運用者）・業務停止時間（利用者）・業務継続の要求度（単一/二重故障の観点）

3 業務継続の要求度・単一/二重故障発生時の影響範囲

4 目標復旧時間(RTO) ・障害ポイント別のRTO

5 耐障害性冗長化（機器/コンポネント/経路）

・冗長化部分の動作・非冗長部分の故障時影響

6 回復性復旧作業・作業者、復旧手順の確認

17


〔取組み１〕検証項目の抽出（２／２）

№ 大項目中項目指標検証で考慮すべきポイント

7 性能・拡張性

業務処理量

同時アクセス数・故障状態でのアクセス限界数（業務影響、運用回避手段）

8 性能目標値

縮退時レスポンス順守率

・故障状態での性能影響（業務への影響）

9 運用・保守性

運用監視監視情報・監視レベルの妥当性（死活/エラー/性能）

10 監視間隔・障害検知までの時間（運用者が把握できるか）

11 運用環境マニュアル準備レベル

・運用、復旧手順の確認

18

ハードウェアの故障を起因とした流れで検証する

Server

Storage

Network

◆疑似故障発生ツール・サーバーの故障・ストレージの故障・ネットワークの故障

故障印加

結果確認

◆故障の検知・運用監視ツールで

あらゆる故障が正しく

検知できること。

・故障検知までの時間が

設計通りであること。

◆故障の回避・冗長化構成が動作し

故障が正しく回避

できること。

・お客様業務への影響が

設計通り。(業務継続性)

◆故障の検知から回避・回復、エスカレーションなどの運用計画の妥当性を客観的に評価

◆故障の回復・手順書に従い、運用者

が正しくシステムを

回復できること。

・規定時間以内に正しく

回復できる。(時間規定)

◆エスカレーション・ルール通りのパスで

かつ、規定時間以内に

正し報告ができること。

・お客様への報告事象は

規定通りであること。

監視ツールの設定の妥当性冗長化構成の妥当性運用（回復）の妥当性エスカレーションの妥当性

〔取組み２〕検証実施の流れ


時間軸での検証の重要性

稼働率・・・可用性の指標

障害ポイント別に、目標復旧時間(RTO)を検証することにより、稼働率の予測が可能となり、また、リスクも把握できるようになる。


サービス経過時間(24H) 稼働時間停止時間

8H 2H 1H 10H 3H

平均故障間隔 (MTBF)

停止回数

総稼働時間＝

稼働率＝ MTBF+MTTR

MTBF ×100 ＝

2

8+10+3 ＝ 10.5 ＝

平均修復時間 (MTTR)

停止回数

総修復(停止)時間＝

2

2+1 ＝ 1.5 ＝

×100 ＝ 87.5% 10.5+1.5

10.5

稼働率停止時間（１年間）

99.9% 9時間

99.99% 1時間

99.999% 5分

20


ツールへの要件

物理的な構成変更は不要

•ソフトウェアによる実現

専門スキルの排除

•スキルが必要な試験治具等を使用せず

•機器（サーバ、ストレージ、ネットワーク）の専門スキルを不要に

疑似的な故障の実現

•冗長構成の縮退・切替え機能が動作する疑似的な故障を実現

⇒検証に必要な故障ポイントの検討が重要

〔取組み３〕ツールの整備

21

ストレージの故障

Storage#1の故障により#2へ切替え

検証の必要な故障ポイントの検討（１／２）

FC経路異常

Strage#1の経路(SWポート故障)により#2へ切替え


Server

Storage

FC-SW

ミラーリング

#1

#2

データの流れ

Server

FC-SW

ミラーリング

#1

#2

データの流れ

Server

Storage

FC-SW

ミラーリング

#1

#2

データの流れ

Server

FC-SW

ミラーリング

#1

#2

データの流れ故障

Storage Storage

22


システム構成（概略図）

検証すべき構成ポイント

検証の必要な故障ポイントの検討（２／２）

Router

運用側

待機側

Server

Network

Storage

運用側

待機側

FC-SW

装置冗長構成異常状態

1 Server 運用・待機

・サーバ内異常

・Server – Router 間経路異常

・Server – Storage間経路異常

2 Storage 運用・待機・ストレージ異常

・Storage – Server 間経路異常

3 Router シングル・ルーター異常

・Router – Server 間経路異常

絞り込み疑似故障

・サーバ異常 CPU故障

・Storage – Server間経路異常ポート故障

・Router – Server間経路異常ポート故障

23

適用事例



IaaSシステムでのシステム検証

ハードウェアソフトウェア

装置

Server Storage Switch

システムを構成するハードウェア、ソフトウェアに運用監視の設定を実施

監視設定の内容を確認

運用

開始構築

設定

確認検証

監視

設定

適用事例

＋

システム検証／受入テスト（一部）

分類評価内容

構成確認インフラ構築の正当性

監視機能メッセージ/リソース監視

可用性業務継続性、耐障害性

運用・保守性

運用監視、保守（リカバリ）手順

25


重要障害の検出事例

システム検証で実践

CPU故障時のフェイルオーバー

fail-over

利用者 VM

利用者 VM

CPU故障

Server A Server B 切替

利用者

再起動

ツール

サーバ故障フェイル

オーバー

VM

再起動

原因サーバのSNMP Trap設定漏れ故障を通知するSNMP Trapが管理サーバに到達しないとフェイルオーバー発動しないため。

監視設定の内容を確認

設定確認検証

ハードウェア、ソフトウェアに運用監視の設定を実施

監視設定

fail-over

利用者 VM

フェイルオーバー

VM 再起動

No!

重要障害フェイルオーバー失敗！

ここでSNMP 設定も確認しているが・・・

利用者に影響を及ぼす重要障害を検出

管理サーバ

26

さいごに



今回の取組み効果システム稼働前の不安が解消

対策を講じることにより、運用品質は向上

検証するために重要なこと網羅的な検証項目の設計・・・『非機能要求グレード』

良否判定の明確化（期待値設計）・・・運用者/利用者視点、手順書

検証に必要なものの準備・・・ツール

ツール化による付帯効果耐故障性検証の自動化が可能に

•検証期間短縮、省力化

•ソフトウェア改版時等の開発での影響度確認（DevOps）

さいごに

28

冗長構成システム（クラウド等）の 耐故障性に対する検証技術...2014/09/24...

Documents

冗長構成システム（クラウド等）の耐故障性に対する検証技術...2014/09/24...