「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
高可用性システムを構築する場合、システム設計者は
という3つの重要な要素を理解し、それらに注意を払う必要がある。
信頼性とは
- 狭義では、｢信じて頼れる性質｣ということで、簡単にいうと｢品物が､使用期間中､故障しないで稼働する性質｣＝｢故障しない性質｣ということになる｡
- 広義では､修理再使用を考え｢故障した時の修復のしやすさ｣である保守性・可用性なども併せて考える必要がある｡
- コンポーネント（ハードウェア・ソフトウェア）の「信頼性」を向上させる
⇒「可用性」が向上する。
- システムの「保守性」を向上させる
⇒「信頼性」を補い「可用性」が向上する。
- システムや、コンポーネントを「冗長化」する
⇒ 信頼性・保守性」を補い「可用性」が向上する。
信頼性（Reliability） †
システムの各コンポーネントの「信頼性」が高ければ高いほど、総合的な「可用性」は向上する。
- ここでいう「信頼性」とは、長期的な連続運転期間においてハードウェアやソフトウェアに障害が発生しないという意味である。
- しかし、一般的に、
- 完全な「信頼性」の実現は不可能であり、
- また「信頼性」の高い、ハードウェア・ソフトウェアコンポーネントの適用は、システムのコストを押し上げる。
- このため、ほかの手段、すなわち「冗長性」と「保守性」によって「信頼性」を補強する必要がある。
保守性（Serviceability） †
- 一般的に、完全な「信頼性」の実現は不可能であり、障害対応が必要になる。
- また、条件の変化に応じてアプリケーションの使用期間中にシステムの保守が必要となる。
バックアップ・リストア †
問題が発生した場合、システムの復旧を早めるため、管理者が遠隔操作できる保守ツールの存在は重要になる。
また、保守ツールでの対応以外では、
- データをテープからリストアする。
- システムをゼロから構築し直す。
といった対応が、唯一の解決策の場合もある。
これらを迅速に行う手順が整備されていないと、基幹サービスが長期間利用できなくなる可能性がある。
パッチの適用とロールバック †
コンポーネントの使用期間中に、パッチの適用や、ドライバのアップグレードが必要になる事がある。
その作業後、サーバの再起動が不要で、後で問題が発生してもコンポーネントを以前の正常な状態に迅速にロールバックできれば、「可用性」は高まる。
稼働中の監視 †
あるコンポーネントに障害が発生したり機能が低下したりした場合、たとえ冗長システムであっても、
それがサポートするサービスの「可用性」に影響を及ぼさずに障害を検出して修理する必要がある。
稼動監視により、「障害の検出」、「障害の前兆の検出による障害の防止」が可能になる。
冗長性（Redundancy） †
「冗長性」は前述の「信頼性」」・「保守性」を補い、
高可用性を実現する上で重要な役割を果たす。
この「冗長性」は、
- ハードウェアの二重化から、
- サーバ・ファームといったハードウェア・ソフトウェア全体の二重化まで、
さまざまなレベルで実現できる。
ハードウェアの冗長性 †
- フォールト・トレラント（耐障害性）という用語は、冗長な「信頼性の低い」コンポーネントを用いて実現した高可用性の説明に使われる。
- 例えばRAIDは、ストレージ・デバイスに障害が発生した場合でもストレージ・デバイス・レベルでフォールト・トレラントを実現し、「信頼性」を補う。
また、保守の観点からは、ドライバのローリング・アップグレードを可能にすることで、「保守性」を補うことができる。
ソフトウェアの冗長性 †
- １つのハードウェアないしOS、ソフトウェアの障害がシステムを停止させないように配慮した設計が必要である。
- しかし、アプリケーション・サービスは、コードに欠陥を持つかもしれず、クラッシュの可能性がある。
- このため、ソフトウェアの「冗長性」はクラスタ、サーバ・ファームで実現する。
冗長性の追加 †
実現可能な「冗長性」の追加（冗長化・冗長構成）について説明する。
アプリケーションやOSで高可用性を実現するに当たり、システム設計者は、
以下の4種類の異なるアプローチを用いて「冗長性」を追加できる。
- 分散サービス
- プライマリ・ノード、セカンダリ・ノードの両方のサービス・アプリケーションがクライアントにサービスを提供することで、サービスを冗長化する方式。
- 各ノードに更新があった場合、必要なデータは、他のノードにレプリケーションされる。
- サーバ・ファーム
複数の物理サーバ（サーバ・ファーム）に、共通の仮想IPアドレスと仮想MACアドレスを持つ仮想サーバ（クラスタ）を構成する事で、サービスの「負荷分散・拡張性」・「冗長性・可用性」の向上を図る。
- クラスタ・サービス
- 複数の物理サーバ（サーバ・ファーム）に、共通の仮想IPアドレスと仮想MACアドレスを持つ仮想サーバ（クラスタ）を構成し、
SAN上の「共有ディスク（クォーラム・ボリューム）」・「共有ディスク（データ・ボリューム）」に接続することで、
ステータス情報、アプリケーションデータをネットワーク経由で共有した状態で、サービスの「冗長性・可用性」の向上を図る。
- 「アクティブ－パッシブ」の構成
フェイル・オーバーが発生しない限り、同じアプリケーションの使用する「共有ディスク（データ・ボリューム）」にアクセスできる
「アクティブ」な「物理サーバ」は１台だけであり、他のサーバは「パッシブ」である。従ってクラスタは本質的には「負荷分散・拡張性」を提供しない。
- 「アクティブ－アクティブ」の構成
同じアプリケーションの他のインスタンスや、別のアプリケーションに対して可能。
分散サービス †
分散サービスでは、システム・サービスや他のアプリケーションが複数のサーバで分散して稼働するように設計・実装することで、ソフトウェアの機能を利用して「冗長性」とフォールト・トレランスを実現可能である。
分散サービスの例としては、
- Active Directory（AD）
- ドメイン・ネーム・サービス（DNS）
- Windows分散ファイル・システム（DFS）と
ファイル・レプリケーション・サービス（FRS）の組み合わせ。
などがある。
以下の図に、ADのサイト上にあるドメイン・コントローラ（DC）のサイト内のレプリケーション、サイトリンクを経由したサイト間のレプリケーションの概要図を示す。
また、DNSでは「ゾーン転送」と言うレプリケーション機能を持っている。
この分散方式は共有データのアップデート頻度が比較的低い場合に最もうまく機能し、
サーバが帯域幅の限られたWANで接続されたサイトにある場合でも通常うまく機能する。
１つのDCが故障した場合も、「冗長性」によるフォールト・トレランスを実現可能である。
フォールト・トレラント・サーバ（FTサーバ） †
フォールト・トレラント・サーバ（FTサーバ）は「CPUとメモリ」、「I/O」をそれぞれ二重化（もしくは多重化）、
相互に同期しながら並行して同じ処理を実行することで、ハードウェアを冗長化し、
ハードウェア障害が発生しても無停止で稼働し続ける高信頼性のサーバ・システムである。
- FTサーバはその上で稼働するアプリケーションから単一のサーバに見える。
- また、ハードウェアやOSに問題を検出すると、フェイル・オーバーはほぼ瞬時に実行される。
- ハードウェアやOSの観点からすると、FTサーバは最高水準の「可用性」を実現し、
通常はその上で稼働するアプリケーションを停止せずにアップグレードとメンテナンスが実行できる。
FTサーバは、ハードウェアの冗長化を提供し、アプリケーション自体の障害に対する特別な保護は提供しない。FTサーバは一般に、通常のサーバよりはるかに高価である。
クラスタ †
サーバ・ファーム †
複数のサーバで同じアプリケーションのコピーを稼働させる方式である。
- DNSサーバとハードウェア・ソフトウェア負荷分散デバイス、ソフトウェア負荷分散テクノロジなどを使用して、受信したクライアントのリクエストをファーム内のサーバに分散させる。
- サーバ・ファームの主要目的は、「負荷分散・拡張性」の提供である。
- しかし、負荷分散システムがアプリケーションやOSのインスタンス、またはハードウェアの障害を検出し、
負荷分散システムがリクエストをファーム内のほかの正常なサーバに割り当てることができれば、「冗長性・可用性」の向上にもつながる。
- ファーム方式
- サーバ・ステートレス
各クライアントからの接続が比較的短時間で、サーバが「状態」データ（eコマースのショッピング・カートの内容など）の保管や、
トランザクショナル・データ（購入に関連するデータなど）の保管を必要としない、サーバ・ステートレスなアプリケーションで最もうまく機能する。
- サーバ・ステートフル
サーバ・ステートフルなアプリケーションであっても、状態をファームから独立したサーバ（ステートサーバ、DBサーバ）に格納・永続化できるなら、
ファーム上のアプリケーションに障害が発生した場合、ユーザはリクエストをリトライでき、負荷分散システムによって別のサーバにルーティングされても、問題なく動作する。
クラスタ・サービス †
クラスタ纏め表 †
| # | 比較項目 | NLB | MSCS WSFC |
| 1 | アプリケーション | TCP ベースや UDP ベースのサーバ・アプリケーション | フェイル・オーバーとフェイル・バックを行うステートフルなサーバ・アプリケーション |
| 2 | 前提ハードウェア | MAC書き換え可能なNICのみ。
チーム用のネットワーク アダプタを使用する場合は、Windows カタログに表示されるネットワーク アダプタを選択する。 | 共有ディスクなど、MSCS WSFC対応のハードウェア |
| 3 | 適用対象サーバ | ・Webサーバ
・ISAサーバ
・仮想プライベート・ネットワーク
・Windows Mediaサーバ
・Mobile Informationサーバ
・ターミナル・サービス | ・MS SQL Server
・MS Exchange Server
・ファイル・サーバ
・プリント・サーバ
・メッセージ・キュー
|
| 4 | ステートフルかステートレス | ステートレス | ステートフル |
構成例 †
３層アプリケーションの高可用性アーキテクチャ †
- フロントエンドのサーバ・ファームがビジネス・ロジックを処理し、Webブラウザのユーザ・インターフェイス（HTML）を生成する。
- 一方、バックエンドのクラスタ・サービスはSQL Server上のデータ層をホストする。
- 各層には異なる高可用性テクノロジが適している。
クライアント †
- クライアント・リクエストは、NLB（あるいは負荷分散ハードウェア）を用いてフロントエンド・サーバ内に分散される。
- Webブラウザ
- Webブラウザはステートレスであり、各トランザクションは異なるフロントエンド・サーバへの接続を伴うことが可能で、特定のフロントエンド・サーバに依存することはない。
- スマート・クライアント
- Webサービスを使用する３層スマート・クライアント・アプリケーションにも適応可能である。
- ただしアプリケーションが状態情報を中間層サーバに格納せず、特定のサーバへの連続接続に依存していないことが条件となる。
フロントエンド・サーバ(P・B層) †
- フロントエンド・サーバもサーバ・ステートレスで、データ層にすべての状態情報を格納する。
- フロントエンド・サーバに障害が発生した場合やメンテナンスのためにサービスを中断する必要がある場合、クライアント・リクエストは自動的に別のフロントエンド・サーバへと再送される。
バックエンド・サーバ(D層) †
FTサーバとMSCS †
- 複数のFTサーバを組み合わせてクラスタ化することで、
- より「信頼性」の高い高可用性システムをを構築することができる。
- ハードウェアまたはソフトウェアのどちらに問題が発生した場合でも、サービスを提供できる。
FTサーバ †
- 1台のサーバ内でハードウェアを多重化しているのに対し、MSCSは複数のサーバでグループを構成し、一部のサーバの障害発生時に別のノードのサーバにフェイル・オーバーや負荷分散をする。
- ハードウェア障害発生時にそのまま処理を継続できるが、ソフトウェア障害時にはアプリケーションもしくはシステムの再起動が必要となる。
MSCS †
フェイル・オーバー時にサービスが一時中断するが、ソフトウェア障害発生時にもフェイル・オーバーできる。
その他 †
用語 †
フォールト・トレランス †
- 飛行機のエンジン : 2機以上のエンジン
- 自動車のタイヤ : ランフラットタイヤ
など。
ITで言うところの、
- ネットワーク・ポート
- LBFO（Load Balancing and Fail Over）
- ディスク
- マルチパスI/O
- RAID1（ミラーリング）
- RAID5（パリティ）
- ,etc.
フェイル・オーバー †
フェイルオーバーは
- システムを冗長化する技術の1つであり、
- フォールト・トレランスを実現するための技術の1つ。
フェイル・セーフ †
障害が発生した場合に、二次被害を防止する観点から、
「いかに”安全に”停止させるか」を目的とした設計のこと。
フェイル・ソフト †
機能低下を許しても、システムを完全には停止させずに
機能を維持した状態で処理を続行（縮退運転）する設計のこと。
参考 †
Tags: :設計のポイント, :信頼性
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
