Open棟梁 wiki
...工事中...
目次 †
概要 †
高可用性システムを構築する場合、システム設計者は
という3つの重要な要素を理解し、それらに注意を払う必要がある。
信頼性とは
- 狭義では、｢信じて頼れる性質｣ということで、簡単にいうと｢品物が､使用期間中､故障しないで稼働する性質｣＝｢故障しない性質｣ということになる｡
- 広義では､修理再使用を考え｢故障した時の修復のしやすさ｣である保守性・可用性なども併せて考える必要がある｡
#ref(): File not found: "BroadSenseReliability.png" at page "高信頼性設計のポイント"
- コンポーネント（ハードウェア・ソフトウェア）の「信頼性」を向上させる
⇒「可用性」が向上する。
- システムの「保守性」を向上させる
⇒「信頼性」を補い「可用性」が向上する。
- システムや、コンポーネントを「冗長化」する
⇒ 信頼性・保守性」を補い「可用性」が向上する。
信頼性（Reliability） †
システムの各コンポーネントの「信頼性」が高ければ高いほど、総合的な「可用性」は向上する。
- ここでいう「信頼性」とは、長期的な連続運転期間においてハードウェアやソフトウェアに障害が発生しないという意味である。
- しかし、一般的に、
- 完全な「信頼性」の実現は不可能であり、
- また「信頼性」の高い、ハードウェア・ソフトウェアコンポーネントの適用は、システムのコストを押し上げる。
- このため、ほかの手段、すなわち「冗長性」と「保守性」によって「信頼性」を補強する必要がある。
保守性（Serviceability） †
- 一般的に、完全な「信頼性」の実現は不可能であり、障害対応が必要になる。
- また、条件の変化に応じてアプリケーションの使用期間中にシステムの保守が必要となる。
バックアップ・リストア †
問題が発生した場合、システムの復旧を早めるため、管理者が遠隔操作できる保守ツールの存在は重要になる。
また、保守ツールでの対応以外では、
- データをテープからリストアする。
- システムをゼロから構築し直す。
といった対応が、唯一の解決策の場合もある。
これらを迅速に行う手順が整備されていないと、基幹サービスが長期間利用できなくなる可能性がある。
パッチの適用とロールバック †
コンポーネントの使用期間中に、パッチの適用や、ドライバのアップグレードが必要になる事がある。
その作業後、サーバの再起動が不要で、後で問題が発生してもコンポーネントを以前の正常な状態に迅速にロールバックできれば、「可用性」は高まる。
稼働中の監視 †
あるコンポーネントに障害が発生したり機能が低下したりした場合、たとえ冗長システムであっても、
それがサポートするサービスの「可用性」に影響を及ぼさずに障害を検出して修理する必要がある。
稼動監視により、「障害の検出」、「障害の前兆の検出による障害の防止」が可能になる。
冗長性（Redundancy） †
「冗長性」は前述の「信頼性」」・「保守性」を補い、
高可用性を実現する上で重要な役割を果たす。
この「冗長性」は、
- ハードウェアの二重化から、
- サーバ・ファームといったハードウェア・ソフトウェア全体の二重化まで、
さまざまなレベルで実現できる。
ハードウェアの冗長性 †
- フォールト・トレラント（耐障害性）という用語は、冗長な「信頼性の低い」コンポーネントを用いて実現した高可用性の説明に使われる。
- 例えばRAIDは、ストレージ・デバイスに障害が発生した場合でもストレージ・デバイス・レベルでフォールト・トレラントを実現し、「信頼性」を補う。
また、保守の観点からは、ドライバのローリング・アップグレードを可能にすることで、「保守性」を補うことができる。
ソフトウェアの冗長性 †
- １つのハードウェアないしOS、ソフトウェアの障害がシステムを停止させないように配慮した設計が必要である。
- しかし、アプリケーション・サービスは、コードに欠陥を持つかもしれず、クラッシュの可能性がある。
- このため、ソフトウェアの「冗長性」はクラスタ、サーバ・ファームで実現する。
冗長性の追加 †
実現可能な「冗長性」の追加（冗長化・冗長構成）について説明する。
アプリケーションやOSで高可用性を実現するに当たり、システム設計者は、
以下の4種類の異なるアプローチを用いて「冗長性」を追加できる。
- 分散サービス
- プライマリ・ノード、セカンダリ・ノードの両方のサービス・アプリケーションがクライアントにサービスを提供することで、サービスを冗長化する方式。
- 各ノードに更新があった場合、必要なデータは、他のノードにレプリケーションされる。
- サーバ・ファーム
複数の物理サーバ（サーバ・ファーム）に、共通の仮想IPアドレスと仮想MACアドレスを持つ仮想サーバ（クラスタ）を構成する事で、サービスの「負荷分散・拡張性」・「冗長性・可用性」の向上を図る。
- クラスタ・サービス
- 複数の物理サーバ（サーバ・ファーム）に、共通の仮想IPアドレスと仮想MACアドレスを持つ仮想サーバ（クラスタ）を構成し、
SAN上の「共有ディスク（クォーラム・ボリューム）」・「共有ディスク（データ・ボリューム）」に接続することで、
ステータス情報、アプリケーションデータをネットワーク経由で共有した状態で、サービスの「冗長性・可用性」の向上を図る。
- 「アクティブ－パッシブ」の構成
フェイル・オーバーが発生しない限り、同じアプリケーションの使用する「共有ディスク（データ・ボリューム）」にアクセスできる
「アクティブ」な「物理サーバ」は１台だけであり、他のサーバは「パッシブ」である。従ってクラスタは本質的には「負荷分散・拡張性」を提供しない。
- 「アクティブ－アクティブ」の構成
同じアプリケーションの他のインスタンスや、別のアプリケーションに対して可能。
分散サービス †
分散サービスでは、システム・サービスや他のアプリケーションが複数のサーバで分散して稼働するように設計・実装することで、ソフトウェアの機能を利用して「冗長性」とフォールト・トレランスを実現可能である。
分散サービスの例としては、
- Active Directory（AD）
- ドメイン・ネーム・サービス（DNS）
- Windows分散ファイル・システム（DFS）と
ファイル・レプリケーション・サービス（FRS）の組み合わせ。
などがある。
以下の図に、ADのサイト上にあるドメイン・コントローラ（DC）のサイト内のレプリケーション、サイトリンクを経由したサイト間のレプリケーションの概要図を示す。
#ref(): File not found: "ActiveDirectoryReplication.png" at page "高信頼性設計のポイント"
また、DNSでは「ゾーン転送」と言うレプリケーション機能を持っている。
この分散方式は共有データのアップデート頻度が比較的低い場合に最もうまく機能し、
サーバが帯域幅の限られたWANで接続されたサイトにある場合でも通常うまく機能する。
１つのDCが故障した場合も、「冗長性」によるフォールト・トレランスを実現可能である。
フォールト・トレラント・サーバ（FTサーバ） †
フォールト・トレラント・サーバ（FTサーバ）は「CPUとメモリ」、「I/O」をそれぞれ二重化（もしくは多重化）、
相互に同期しながら並行して同じ処理を実行することで、ハードウェアを冗長化し、
ハードウェア障害が発生しても無停止で稼働し続ける高信頼性のサーバ・システムである。
- FTサーバはその上で稼働するアプリケーションから単一のサーバに見える。
- また、ハードウェアやOSに問題を検出すると、フェイル・オーバーはほぼ瞬時に実行される。
- ハードウェアやOSの観点からすると、FTサーバは最高水準の「可用性」を実現し、
通常はその上で稼働するアプリケーションを停止せずにアップグレードとメンテナンスが実行できる。
#ref(): File not found: "FTServer.png" at page "高信頼性設計のポイント"
FTサーバは、ハードウェアの冗長化を提供し、アプリケーション自体の障害に対する特別な保護は提供しない。FTサーバは一般に、通常のサーバよりはるかに高価である。
その他 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
