JP6278602B2 - 高可用性システム - Google Patents

Description

本発明は、マルチプロセッサを搭載した装置を用いて運用系と待機系の多重化システムを実現する高可用性システムに関する。

従来、高可用性を実現するため、ハードウェアを含めたシステム全体を多重化し、２重系システムの構築を行っていた。２重系システムのバックアップの系を電源停止させた状態で待機させるコールドスタンバイ、または起動させた状態で待機させるホットスタンバイで待機させ、障害発生時にバックアップの系へ処理をフェールオーバさせ、システムの運用を継続し、可用性を高める方法が提案されていた（例えば、特許文献１参照）。

また、可用性を高める方法として、システムを多重化してバックアップ機能を構成し、動作継続ができない障害が発生した場合は、バックアップに切換り、同等の動作、または機能や処理を縮退し動作し続けるといった方法が提案されていた（例えば、特許文献２参照）。

特開２００６−１７２３９０号公報 特開２０１１−０４３８９２号公報

しかしながら、組込み機器においてはプロセッサの処理性能の向上に伴い多様な機能が要求され、ソフトウェア規模が増大すると共に構造が複雑になりソフトウェア不具合によるシステムダウンが発生している。また、サードパーティアプリをインストールして使用するケースも増加し、予期しないソフトウェア要因の障害により、システムが継続して動作できない状況に陥る状況がある。そういった状況ではシステムの再起動が必要になり、ユーザーは再起動中、サービスを受けられないという問題があった。

更に、システムの再起動は障害発生時に限らず、ソフトウェアのアップデート時や、長時間電源断しないシステムでメモリリーク防止として用いられる計画的なシステム再起動時なども該当し、可用性を向上させる必要がある。

従来の高可用性システムのようにハードウェアを含めたシステム全体を多重化する方法を、組込み機器に適用するとサイズが大きくなる、部品点数が増える、コストが高くなるといった問題があり、従来手法をそのまま適用することができない。

また、系の切換えを行いバックアップ用の系で動作継続を行う場合、バックアップの系で障害が発生した際のバックアップ機能が無いという問題があった。バックアップの系を３重、４重のシステムにするという手法は提案されているが、上述した通り、組込み機器においては３重、４重のシステム多重化方法は適していない。

この発明は上記のような課題を解決するためになされたもので、システム全体を多重化できない問題と、バックアップの系へ切換った場合バックアップ機能がないという問題を解決し、低コストで多重化システムを実現することができ、ソフトウェア要因によるシステム再起動のダウンタイムを小さくし、高可用性を実現することのできる高可用性システムを得ることを目的とする。

この発明に係る高可用性システムは、複数の演算ＣＰＵを有するマルチコアプロセッサと、複数の演算ＣＰＵが共通して用いる周辺ハードウェアとを搭載した装置を用いた高可用性システムであって、複数の演算ＣＰＵを運用系と待機系に分割して多重系システムを構築すると共に、周辺ハードウェアは、運用系と待機系のそれぞれの起動情報を格納するための起動情報格納部を有し、運用系と待機系のそれぞれは、起動情報に従って運用系と待機系とを運用可能状態とする起動手段と、運用系の稼働状態の監視を行い、運用系の異常を検出する異常検出手段と、運用系の異常が検出された場合は、待機系を運用系として系切換を行うと共に、起動情報を系切換に対応して更新する系切換手段と、運用系から待機系に切換った場合に、待機系としての再起動を行う再起動手段とを備え、待機系は運用可能状態の後にスリープ状態に移行し、かつ、スリープ状態移行後、周期的に異常検出手段が起動し監視を行い、運用系の異常検出手段は、系内監視を行うことで、運用系の稼働状態の監視を行い、待機系の異常検出手段は、演算ＣＰＵ間の通信を利用した系間監視を行うことで、運用系の稼働状態の監視を行うものである。

この発明の高可用性システムは、運用系の異常が検出された場合は、待機系を運用系として系切換を行うと共に、運用系から待機系に切換った場合に、待機系としての再起動を行い、かつ、待機系は運用可能状態の後にスリープ状態に移行し、スリープ状態移行後、周期的に監視を行うようにしたので、低コストで多重化システムを実現でき、かつ、ソフトウェア要因によるシステム再起動のダウンタイムを小さくすることができる。

この発明の実施の形態１による高可用性システムを示す構成図である。 この発明の実施の形態１による高可用性システムの動作を示すフローチャート（その１）である。 この発明の実施の形態１による高可用性システムの動作を示すフローチャート（その２）である。 この発明の実施の形態１による高可用性システムの不揮発メモリの内部構成を示す説明図である。 この発明の実施の形態１による高可用性システムの系間監視のシーケンスを示す説明図である。 この発明の実施の形態１による高可用性システムの運用系で異常検出した場合のシーケンスを示す説明図である。 この発明の実施の形態１による高可用性システムの待機系で異常検出した場合のシーケンスを示す説明図である。 この発明の実施の形態１による高可用性システムの待機系で異常検出し、運用系から通知が無い場合のシーケンスを示す説明図である。 この発明の実施の形態１による高可用性システムのＩＯアクセススケジューリングを行うための優先度付きキューの一例を示す説明図である。 この発明の実施の形態１による高可用性システムのＩＯアクセス要求をキューに追加する方法を示すフローチャートである。 この発明の実施の形態１による高可用性システムのＩＯアクセス要求からスケジューリングを行う方法を示すフローチャートである。 この発明の実施の形態１による高可用性システムのＩＯデバイスへのアクセスを分割し実行する方法を示すフローチャートである。 この発明の実施の形態２による高可用性システムを示す構成図である。

実施の形態１．
図１は、この発明の実施の形態１による高可用性システムのハードウェア構成及びソフトウェア構成を含む構成図である。
図１に示す高可用性システムは、２個のＣＰＵ１０１，２０１を備えたマルチコアプロセッサに多重系システムを構築する例である。システム系Ａ１００は、ＣＰＵ１０１、ＯＳ（オペレーティングシステム）１０２、ＣＰＵ間通信部１０３、アプリケーションプログラム１０４、異常検出処理部１０５、ＩＯアクセス制御部１０６から構成され、システム系Ｂ２００は、ＣＰＵ２０１、ＯＳ２０２、ＣＰＵ間通信部２０３、アプリケーションプログラム２０４、異常検出処理部２０５、ＩＯアクセス制御部２０６から構成されている。また、高可用性システムは、これらシステム系Ａ１００とシステム系Ｂ２００とが共通して用いるＩＯデバイス１、不揮発メモリ２、メモリ３、通信路４を備えている。

図示のように、高可用性システムでは、マルチコアプロセッサを複数の系に分割し、システム系Ａ１００とシステム系Ｂ２００を構成する。各系にはＣＰＵを１個ずつ割り当てる。ＣＰＵ１０１とＣＰＵ２０１は同一アーキテクチャを持ち、通信路４で接続され、ＣＰＵ間、或いは同じく通信路４に接続される周辺ハードウェアであるＩＯデバイス１、メモリ３、不揮発メモリ２と互いに情報を伝達できるように構成されている。

システム系Ａ１００とシステム系Ｂ２００に、同一または異なるＯＳ１０２とＯＳ２０２を搭載する。また、ＯＳ１０２，２０２上で動作するＣＰＵ間通信部１０３，２０３と、アプリケーションプログラム１０４，２０４と、異常検出処理部１０５，２０５と、ＩＯアクセス制御部１０６，２０６をそれぞれ搭載し２重系システムを構築し、系を通常動作する運用系とバックアップとして動作する待機系に割り当てる。ＩＯデバイス１へのアクセスはシステム系Ａ１００またはシステム系Ｂ２００のどちらか一方がアクセスすることとし、通常動作を行う運用系が入出力を行う。メモリ３は、論理的にシステム系Ａ１００用の系Ａ用メモリ３１と、システム系Ｂ２００用の系Ｂ用メモリ３２と、システム系Ａ１００とシステム系Ｂ２００とで共有する共有メモリ３３に分割する。

不揮発メモリ２には、運用系と待機系のそれぞれの起動情報を格納するための起動情報格納部が構成されている（これについては図４を用いて後述する）。また、これらの起動情報と、ＣＰＵ１０１，２０１、ＣＰＵ間通信部１０３，２０３、ＩＯアクセス制御部１０６，２０６によって、運用系と待機系とを運用可能状態とする起動手段が構成されている。さらに、ＣＰＵ間通信部１０３，２０３と異常検出処理部１０５，２０５とによって、運用系の稼働状態の監視を行い、運用系の異常を検出する異常検出手段と、運用系の異常が検出された場合は、待機系を運用系として系切換を行うと共に、起動情報を系切換に対応して更新する系切換手段と、運用系から待機系に切換った場合に、待機系としての再起動を行う再起動手段とが構成されている。

次に、実施の形態１の高可用性システムの動作について説明する。図２及び図３は高可用性システムにおけるシステム起動から終了までの処理を表したフローチャートであり、システム系Ａ１００、システム系Ｂ２００に共通のものである。
（１）２重系システムの起動
電源オンなど、システム起動トリガを検出すると、システム系Ａ１００のＣＰＵ１０１は不揮発メモリ２にアクセスし、系起動情報の取得を行う。図４は、不揮発メモリ２の構成例を示している。不揮発メモリ２内には系Ａ起動情報２１と系Ｂ起動情報２２が格納されている。システム系Ａ１００は系Ａ起動情報２１を取得し、系起動情報判定（ステップＳＴ１）を行い、運用系起動か待機系起動かを判定する。システム系Ａ１００の系起動情報が運用系起動である場合、システム系Ａ１００は、ＯＳロード（ステップＳＴ２）を行う。一方、システム系Ａ１００の系起動情報が待機系起動である場合、システム系Ａ１００は待機系として起動し、運用系として起動する系からの「待機系動作開始通知」受信待ち（ステップＳＴ１８）に遷移する。
以下は、システム系Ａ１００が運用系で起動し、システム系Ｂ２００が待機系で起動する例で説明する。

運用系で起動するシステム系Ａ１００は、ＯＳロード処理（ステップＳＴ２）で、ＯＳ１０２を系Ａ用メモリ３１にロードする。次に、系Ａ用メモリ３１に展開したＯＳ１０２のＯＳ初期化（ステップＳＴ３）を行い、システムが動き出すまでに必要とされる初期化処理を行う。システム系Ａ１００はＳ／Ｗの初期化（ステップＳＴ４）でＣＰＵ間通信部１０３、アプリケーションプログラム１０４、異常検出処理部１０５、ＩＯアクセス制御部１０６の初期化処理を行う。運用系で起動するシステム系Ａ１００はＩＯアクセス制御部１０６の制御情報をアクセス許可に更新する。

運用系起動するシステム系Ａ１００はＩＯデバイス１へアクセスし、ＩＯデバイス初期化（ステップＳＴ５）を行い、通常動作（ステップＳＴ６）を開始し、アプリケーションプログラム１０４を実行する。通常動作中はシステム系Ａ１００の異常検出処理部１０５でシステム系Ａ１００内のアプリケーションプログラム１０４の状態を監視（ステップＳＴ１２）する。また、ＣＰＵ１０１は、システム系Ｂ２００のＯＳ２０２が系Ｂ用メモリ３２へロード完了しているかを判定（ステップＳＴ７）し、展開されていない場合は、待機系のＯＳのロード処理（ステップＳＴ８）を行う。このとき、ＩＯアクセス制御部１０６内のＩＯアクセススケジューリング部１０７は、運用系として動作しているシステム系Ａ１００のＩＯデバイス１へのアクセス状況を監視し、システム系Ｂ２００のＯＳ２０２をロードするために行うＩＯデバイス１へのアクセスが、通常動作を行っているシステム系Ａ１００への動作に影響が小さくなるようにスケジューリングを行う。すなわち、待機系の起動処理を行う際、運用系の通常動作を優先して行う。なお、スケジューリングの詳細については後述する。

システム系Ａ１００のＣＰＵ１０１は、システム系Ｂ２００のＯＳ２０２のロードが完了すると、システム系Ｂ２００に制御信号を発生させ、「待機系動作開始通知」を通知（ステップＳＴ９）する。
なお、運用系であるシステム系Ａ１００が待機系であるシステム系Ｂ２００のＯＳ２０２を展開するタイミングはシステム系Ａ１００が通常動作（ステップＳＴ６）状態に限らず、システム系Ａ１００のＯＳ１０２をロードするＯＳロード（ステップＳＴ２）において、システム系Ｂ２００のＯＳ２０２のロードを同時に行い「待機系動作開始通知」を行ってもよい。運用系であるシステム系Ａ１００の処理負荷が低いタイミングに行うことが望ましく、運用系の処理遅延やレイテンシの低下を小さくすることができる。

待機系で起動するシステム系Ｂ２００は、システム系Ａ１００からの「待機系動作開始通知」を受信後、システム系Ａ１００と同様に、ＯＳ初期化（ステップＳＴ１９）でメモリ３に展開したＯＳの初期化と、Ｓ／Ｗ初期化（ステップＳＴ２０）を行い、ＣＰＵ間通信部２０３、アプリケーションプログラム２０４、異常検出処理部２０５、ＩＯアクセス制御部２０６の初期化処理を行う。待機系で起動するシステム系Ｂ２００は、ＩＯアクセス制御部２０６の制御情報をアクセス不可に更新する。

待機系で動作するシステム系Ｂ２００は待機状態に入り、ＣＰＵ２０１の状態をＳＬＥＥＰ状態（ステップＳＴ２４）に遷移させ、低消費電力モードにすることで低消費電力化を行う。システム系Ｂ２００は、システム系Ａ１００からの割り込みやＣＰＵ間通信によるイベント通知、または自身の周期タイマによってスリープ状態から復帰し系Ａ２００の稼働状態の監視を行う。すなわち、待機系は運用可能状態の後にスリープ状態となり、かつ、スリープ状態後、周期的に異常検出手段が起動し監視を行う。

（２）異常の検出方法
システム系Ａ１００の異常検出処理部１０５、システム系Ｂ２００の異常検出処理部２０５は、それぞれ自身の系内の再起動が必要なソフトウェア要因による異常を検出する機能を有する。以下に具体的な検出方法を記載する。
・例外などＣＰＵ１０１，２０１のエラー検出情報を取得する。
・チェックサムを利用したメモリ内容の監視を行い、メモリ破壊、データの書き込み失敗の検出を行う。
・アプリケーションプログラム１０４，２０４で周期的に動作する処理が一定周期以内に動作しているか監視し、処理遅延の検出を行う。
・系Ａ用メモリ３１，系Ｂ用メモリ３２の特定の領域に確認用データを格納し、その領域が期待しない値に書き換わらないか監視する。メモリ破壊、スタックオーバフローの検出を行う。
・ＯＳ１０２，２０２のスケジューリング情報を参照し、スケジューリングのキュー操作から一定時間以上同一キューがＲＵＮ状態になっていないか、周期動作する処理が周期的にＲＵＮ状態に遷移しているかを監視する。

システム系Ａ１００の異常検出処理部１０５、システム系Ｂ２００の異常検出処理部２０５は他系の稼働状態を監視し、他系で再起動が必要なソフトウェア要因による異常を検出する機能を有する。以下に具体的な検出手段を記載する。

図５は運用系と待機系間で稼働状態の監視を行う例を示した図である。
通信路４を介したＣＰＵ１０１とＣＰＵ２０１間でＣＰＵ間通信部１０３，２０３と共有メモリ３３を利用し、システム系Ａ１００は周期的に共有メモリ３３の稼働情報を更新する（ステップＳＴ４０１）。ＣＰＵ間通信部１０３，２０３でシステム系Ｂ２００へ稼働情報更新通知を送出する（ステップＳＴ４０２）。システム系Ｂ２００ではシステム系Ａ１００からのＣＰＵ間通信を受信し、共有メモリ３３の稼働内容が期待する値に更新されているか確認する（ステップＳＴ４０５）ことでシステム系Ａ１００が正常動作を行っているかを監視する。また、システム系Ｂ２００も同様に、周期的に共有メモリ３３の稼働情報を更新（ステップＳＴ４０６）し、ＣＰＵ間通信でシステム系Ａ１００に稼働情報更新通知（ステップＳＴ４０３）を送出する。システム系Ｂ２００から稼働情報更新通知（ステップＳＴ４０３）を受信したシステム系Ａ１００では共有メモリ３３の稼働内容が期待する値に更新されているか確認（ステップＳＴ４０４）することでシステム系Ｂ２００が正常動作を行っているか監視する。共有メモリ３３の内容が期待する値に更新されていない場合や周期的に稼働情報更新通知が通知されない場合、監視対象の系が異常な状態であると判断する。

（３）系の切換え
・異常検出による系の切換え
［システム系Ａ１００の異常検出処理部１０５による異常検出］
図６は運用系で異常検出した場合のシーケンスの例を示す図である。運用系であるシステム系Ａ１００の異常検出処理部１０５で動作継続不可能な異常を検出（ステップＳＴ１２）した場合、通信路４を介したＣＰＵ１０１とＣＰＵ２０１間の通信にＣＰＵ間通信部１０３，２０３を使用し「系切換通知」をシステム系Ｂ２００へ送出する（ステップＳＴ１３）。システム系Ａ１００は、不揮発メモリ２に格納されているシステム系Ａ１００の系起動情報を「待機系起動」に更新（ステップＳＴ１４）し、ＩＯアクセス制御部１０６の制御情報をアクセス不可に更新し、再起動する。システム系Ａ１００は再起動後、システム系Ａ１００の系起動情報判定（ステップＳＴ１）を行い、待機系起動し、待機状態へ遷移する。

システム系Ｂ２００は、待機中にＣＰＵ間通信で「系切換通知」（ステップＳＴ２１）を受信し、不揮発メモリ２に格納されているシステム系Ｂ２００の系起動情報を「運用系起動」に更新（ステップＳＴ１７）し、ＩＯアクセス制御部２０６の制御情報をアクセス許可に更新して運用系に切換り、ＩＯデバイス初期化（ステップＳＴ５）を行い、通常動作（ステップＳＴ６）を開始し、アプリケーションプログラム２０４を実行する。

［システム系Ｂ２００の異常検出処理部２０５による異常検出］
図７は待機系で異常検出した場合のシーケンスの例を示す図である。待機系であるシステム系Ｂ２００の異常検出処理部２０５でシステム系Ａ１００の動作継続不可能な異常を検出（ステップＳＴ２３）した場合、通信路４を介し、ＣＰＵ間通信部１０３，２０３を使用し、システム系Ｂ２００からシステム系Ａ１００へ「系切換要求」を通知（ステップＳＴ２５）し、異常検出による系の切換えを要求する。
システム系Ａ１００では「系切換要求」を受信（ステップＳＴ１１）すると、ＣＰＵ間通信部１０３，２０３を使用して「系切換通知」をシステム系Ｂ２００へ通知し、システム系Ａ１００の異常検出処理部１０５で異常検出した時と同様に、システム系Ａ１００の系起動情報更新（ステップＳＴ１４）を行い、ＩＯアクセス制御部１０６の制御情報をアクセス不可に更新し、再起動後、待機系として起動する。
システム系Ｂ２００で「系切換通知」受信後は、システム系Ａ１００の異常検出処理部１０５で異常検出時した場合と同じ処理を行う。

図８は待機系で異常検出し、運用系から通知が無い場合のシーケンスの例を示す図である。
待機系であるシステム系Ｂ２００の異常検出処理部２０５で、システム系Ａ１００の動作継続不可能な異常を検出（ステップＳＴ７０１）し、システム系Ａ１００へ「系切換要求」を送信（ステップＳＴ２５）後、図示しないタイマを設定し、タイマカウントダウン（ステップＳＴ７０２）を行う。タイムアウト検出するまでにシステム系Ａ１００から系切換通知を受信すれば図７で示したように動作する。一方、システム系Ａ１００から系切換通知が無く、タイマのタイムアウトを検出（ステップＳＴ７０３）した場合、システム系Ａ１００は応答できる状態にないと判断し、システム系Ｂ２００が自発的に系の切換えを行う。このときシステム系Ｂ２００は、システム系Ｂ２００の系起動情報を運用系起動に更新（ステップＳＴ１７）すると共に、システム系Ａ１００の系起動情報を待機系起動に更新（ステップＳＴ７０４）し、また、ＩＯアクセス制御部２０６の制御情報をアクセス許可に更新し、システム系Ａ１００を再起動させ、システム系Ｂ２００を運用系に切換える。

・異常検出以外による系の切換え
システムのソフトウェアのアップデートによる、システムの再起動時やメモリリークなどを防止するために周期的にシステムを再起動する場合においても異常検出時と同様にＣＰＵ間通信部１０３，２０３を使用し「系切換通知」を待機系起動している系へ通知し、待機系へ切換えを行う。

（４）系の再起動
システム系Ｂ２００が運用系へ切換った後、使用済のシステム系Ａ１００は再起動し、システム系Ａ１００の系起動情報判定（ステップＳＴ１）を行い、待機系として起動する。システム系Ｂ２００は通常動作（ステップＳＴ６）を開始後、待機系であるシステム系Ａ１００のＯＳ展開完了状態を判定（ステップＳＴ７）し、未完了である場合、システム系Ｂ２００がシステム系Ａ１００のＯＳ１０２を系Ａ用メモリ３１へロード（ステップＳＴ８）する。ＩＯデバイス１へのアクセスは２重系システムの起動で記載した方法と同様に、運用系であるシステム系Ｂ２００の動作に影響が小さくなるようにスケジューリングしアクセスを行う。展開完了後、待機系であるシステム系Ａ１００に待機系動作開始通知（ステップＳＴ９）を通知し、待機系としてのシステム系Ａ１００の動作を開始する。
なお、システム系Ａ１００が系Ａ用メモリ３１へＯＳ１０２をロードする方法も可能である。また、図５で示したように、システム系Ｂ２００が待機系で異常であった場合、待機系として再起動を行うようにしてもよい。

（５）ＩＯアクセススケジューリング
システム起動時、または系切換り後、運用系が待機系のＯＳをロードする際、通常動作を行っている運用系動作への影響が小さくなるようにＩＯへのアクセスをスケジューリングする。例えば待機系で使用するために連続した時間ＩＯへアクセスする必要がある場合、処理を分割し、周期的にＩＯアクセスを中断させ、ＩＯアクセススケジューリングを実施することで運用系からのＩＯデバイス１へのアクセスを可能にし、運用系の動作が待機系の処理により長時間待ち状態になることを防止する。また、運用系が使用するＩＯデバイス１へのアクセスと待機系が使用するＩＯデバイス１へのアクセス処理が同時に発生した場合は、運用系のＩＯアクセスを優先するスケジューリングを行い、運用系の動作への影響を小さくする。
以下、ＩＯアクセススケジューリング部１０７，２０７で行うスケジューリングの方法について説明する。

図９は運用系、待機系の各系からのＩＯアクセスの要求を管理しスケジューリングを行うために使用する優先度付きキューの例を示している。運用系リクエストキュー８０１と待機系リクエストキュー８０２を使用し、運用系で使用するＩＯアクセス要求は運用系リクエストキュー８０１へ、待機系で使用するＩＯアクセス要求は待機系リクエストキュー８０２へノードを追加する。従って、運用系が待機系のＯＳを展開するために行うＩＯアクセスの要求は待機系リクエストキュー８０２へ接続する。キューの優先順位は、運用系リクエストキュー８０１を待機系リクエストキュー８０２よりも高く設定する。図９では待機系リクエストキュー８０２にＩＯアクセス要求１（８０５）、運用系リクエストキュー８０１にＩＯアクセス要求２（８０３）、ＩＯアクセス要求３（８０４）が接続されている例である。

図１０は各系からのＩＯアクセス要求をリクエストキューへノードの追加する方法を示している。ＩＯデバイス１へのアクセス要求が発生すると、運用系で使用するＩＯアクセスかどうかを判定（ステップＳＴ９０１）する。運用系で使用する場合、運用系リクエストキュー８０１終端にノードを追加（ステップＳＴ９０４）し、要求を管理する。運用系で使用するものでない場合、待機系で使用するＩＯアクセスかどうか判定（ステップＳＴ９０２）する。待機系で使用するＩＯアクセスである場合、待機系リクエストキュー８０２終端にノードを追加（ステップＳＴ９０３）し、ＩＯアクセス要求を管理する。運用系、待機系どちらでも使用しない場合、要求はいずれのキューにも追加しない。

図１１は、図９の優先度付キューに追加した各系からのＩＯアクセス要求からスケジューリングを行う方法を示した図である。先ず、運用系リクエストキュー８０１にノードが存在するか確認（ステップＳＴ１００１）する。ノードが存在する場合、運用系リクエストキュー先頭ノードを取得（ステップＳＴ１００５）する。運用系リクエストキュー８０１にノードが存在しない場合、待機系リクエストキュー８０２にノードが存在するか確認（ステップＳＴ１００２）する。ノードが存在する場合、待機系リクエストキュー先頭ノードを取得（ステップＳＴ１００３）する。取得したノードをスケジューリング情報に反映（ステップＳＴ１００４）し、次にＩＯデバイス１へアクセスする要求とする。運用系リクエストキュー８０１、待機系リクエストキュー８０２共にノードが存在しない場合は、ＩＯへのアクセス要求が無いため、スケジューリング情報への反映は行わない。

図１２はＩＯデバイス１へのアクセス時間を分割し実行する方法を示した図である。待機系で使用するＩＯアクセスにおいて、一定時間以上アクセスするものを分割しＩＯアクセスを行う。図１１で決定したスケジューリング情報から、先ず、待機系で使用するＩＯアクセスであるか判定（ステップＳＴ１１０１）する。待機系で使用するＩＯアクセスである場合、アクセスするデータ量が閾値を超えているか判定（ステップＳＴ１１０２）する。運用系で使用するＩＯアクセスである場合は処理を終了する。アクセスするデータ量の閾値はアクセスするＩＯデバイス１の特性、システムの負荷状態から決定する。閾値を超えている場合、閾値以内のデータを処理し、閾値を超えているデータへのアクセス要求を待機系リクエストキュー８０２の先頭ノードへ設定（ステップＳＴ１１０３）する。アクセスするデータ量が閾値以内である場合は分割処理を行わずアクセスを行う。
（６）２重系システムの終了
運用系として動作しているシステム系Ｂ２００が通常動作中にシステムシャットダウンを検出（ステップＳＴ１０）した場合、ＣＰＵ間通信を使用し、待機系であるシステム系Ａ１００へシャットダウン通知を通知（ステップＳＴ１５）する。その後、システム系Ｂ２００はシステムシャットダウン（ステップＳＴ１６）を行う。
システム系Ａ１００はシャットダウン通知を受信（ステップＳＴ２２）すると、システム系Ｂ２００と同様に、システムのシャットダウン（ステップＳＴ１６）を行い、処理を終了する。

なお、上記例ではＣＰＵ数が２個のマルチプロセッサの例を説明したが、ＣＰＵ数はこの値に限定されるものではなく、４個以上のＣＰＵを備えたマルチプロセッサであってもよい。すなわち、実施の形態１の高可用性システムは、ＣＰＵ数が２個以上のマルチコアプロセッサにおいてＣＰＵ数を均等に分割して２重系を構築するものである。また、上記の説明では、ＯＳ１０２，２０２が搭載されたシステムで実施例を説明したが、ＯＳ１０２，２０２を搭載しないシステムにおいても適用が可能である。

以上のように、実施の形態１では、マルチコアプロセッサを備えた計算機システム内に２重系システムを構築し、任意のタイミングで系を切換えて動作することで、以下の効果を有する。

［ダウンタイム時間の短縮］
系切換えが必要な要因が発生し、待機系に切換り通常動作が開始するまでに必要な時間は系切換え時間とＩＯデバイス初期化時間のみであり、システムのダウンタイムを大幅に短縮する効果が得られる。また、運用系と待機系が循環動作可能な構成であるため、切換えが必要になった系を再起動し待機系として再利用することで、常にバックアップの系が備わった状態を構築でき、前述のダウンタイム短縮の効果を繰り返し得ることができるため、システム全体として可用性を向上させる効果が得られる。

［サイズ、部品点数、コストを維持］
ハードウェアを多重化することなく、既存のマルチコア技術を使用し多重系システムを実現しているため、システムのサイズや、部品点数への影響は無く、コストへの影響もない。そのため、マルチコアプロセッサを搭載した既存システムへの導入や、また近年組込み機器において用いられることが多いＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）やＳｉＰ（Ｓｙｓｔｅｍ Ｉｎ Ｐａｃｋａｇｅ）を使用したシステムにもハードウェアを変更することなく導入が可能であるという効果がある。

また、障害監視専用のハードウェアを追加することなく、異常検出処理部１０５，２０５を多重系システム内に構築し、系内監視と系間監視を行うことによりＯＳ１０２，２０２の状態を含めたソフトウェアの稼働状態を監視することができ、既存のマルチコア技術を用いて、障害の早期検出と検出範囲を拡大ができる効果がある。

さらに、多重化しないＩＯデバイス１へのアクセスをスケジューリングし、運用系と待機系で優先度をつけてアクセスすることで、ＩＯデバイスアクセス競合による待ち時間を短くでき、運用系の動作への影響を小さくできる効果がある。これにより組込み機器のように限られたスペック環境においても、多重系システムを適用できる。

以上説明したように、実施の形態１の高可用性システムによれば、複数の演算ＣＰＵを有するマルチコアプロセッサと、複数の演算ＣＰＵが共通して用いる周辺ハードウェアとを搭載した装置を用いた高可用性システムであって、複数の演算ＣＰＵを運用系と待機系に分割して多重系システムを構築すると共に、周辺ハードウェアは、運用系と待機系のそれぞれの起動情報を格納するための起動情報格納部を有し、運用系と待機系のそれぞれは、起動情報に従って運用系と待機系とを運用可能状態とする起動手段と、運用系の稼働状態の監視を行い、運用系の異常を検出する異常検出手段と、運用系の異常が検出された場合は、待機系を運用系として系切換を行うと共に、起動情報を系切換に対応して更新する系切換手段と、運用系から待機系に切換った場合に、待機系としての再起動を行う再起動手段とを備え、待機系は運用可能状態の後にスリープ状態に移行し、かつ、スリープ状態移行後、周期的に異常検出手段が起動し監視を行うようにしたので、低コストで多重化システムを実現でき、かつ、ソフトウェア要因によるシステム再起動のダウンタイムを小さくすることができる。

また、実施の形態１の高可用性システムによれば、系切換手段は、異常が検出された場合以外に、所定の系切換要求に基づいて系切換を行うようにしたので、例えば、システムのソフトウェアのアップデートによるシステムの再起動時や、メモリリークなどを防止するために周期的にシステムを再起動する場合においても異常検出時と同様に系切換を行うことができる。

また、実施の形態１の高可用性システムによれば、運用系の起動手段は、待機系の起動処理を行う際、運用系の通常動作を優先して行うようにしたので、待機系の起動処理による運用系の影響を小さくすることができる。

また、実施の形態１の高可用性システムによれば、待機系の起動手段は、待機系の起動処理を行う際、運用系の通常動作を優先して行うようにしたので、待機系の起動処理による運用系の影響を小さくすることができる。

実施の形態２．
図１３はこの発明の実施の形態２における高可用性システムのハードウェア構成およびソフトウェア構成を含む構成図である。図１３は、４個のＣＰＵ１０１ａ〜１０１ｃ，２０１を搭載するシステムを例に、システム系Ａ１００ａに３個のＣＰＵ１０１ａ〜１０１ｃ、システム系Ｂ２００ａに１個のＣＰＵ２０１を割り当てた構成の例を表わしている。

すなわち、実施の形態２は、運用系と待機系とでＣＰＵ１０１ａ〜１０１ｃ，２０１の分割比率を不均一として、ＣＰＵの分割比率が高い系を運用系とし、運用系の異常による系切換が発生した場合は再起動を行って、その再起動完了後、再度ＣＰＵの分割比率の高い系を運用系とする系切換を行うようにしたものである。

図１３において、基本的な構成については、ＣＰＵの分割比率以外は実施の形態１と同様であるため、対応する部分には同一符号または添字（ａ）を付与する。ＣＰＵの分割比率が不均一であるため、アプリケーションプログラム１０４ａ，２０４ａの比率が異なる以外は実施の形態１の構成と同様である。

次に、実施の形態２の高可用性システムの動作について説明する。
２重系システムの起動方法、障害の検出方法、系の切換方法、系の再起動、ＩＯアクセススケジューリング方法、２重系システムの終了については実施の形態１と同様であるため、ここでの説明は省略する。

系の分割方法が不均等であり、システム系Ａ１００ａとシステム系Ｂ２００ａはＣＰＵ個数が異なるため、処理能力が異なる。そのため、システム系Ａ１００ａとシステム系Ｂ２００ａとで動作させるアプリケーションプログラム１０４ａ，２０４ａに制限をかけて動作させる。例えば、ＣＰＵが３個のシステム系Ａ１００ａでは、アプリケーションプログラム１０４ａは全アプリケーションを動作させる。ＣＰＵが１個のシステム系Ｂ２００ａでは、アプリケーションプログラム２０４ａはシステムを動作させるために必要最低限のアプリケーションのみ動作させる。システム系Ａ１００ａで動作継続が不可能な障害発生時や系切換えが必要な状況において、システム系Ｂ２００ａでシステムに必要な最低限のアプリケーション２０４ａを動作させつつ、システム系Ａ１００ａを再起動させる。システム系Ａ１００ａが再起動完了後、システム系Ａ１００ａへ再度処理を切換え、全アプリケーションを動作させる。

なお、上記例ではＣＰＵ数を３：１としたが、この値に限定されるものではなく、ＣＰＵ数が３個以上のマルチコアプロセッサにおいてＣＰＵ数を不均等に分割して２重系を構築するものであればどのような分割であってもよい。また、上記例では、ＯＳ１０２，２０２が搭載されたシステムで実施の形態を説明したが、ＯＳ１０２，２０２を搭載しないシステムにおいても適用が可能である。

以上説明したように、実施の形態２の高可用性システムによれば、運用系と待機系とで複数のＣＰＵの分割比率を不均一として、ＣＰＵの分割比率が高い系を運用系とし、運用系の異常による系切換が発生した場合は再起動を行い、再起動完了後、再度ＣＰＵの分割比率の高い系を運用系とする系切換を行うようにしたので、待機系となる系ではＯＳと最低限のアプリケーションが動作可能なリソースを確保すればよく、完全２重化の構成に比べ、より小さなリソースで多重系システムを構築することができる。

実施の形態３．
実施の形態３における図面上の構成は図１と同様であるため、図１を用いて説明する。図１の構成において、運用系として動作しているシステム系Ａ１００で系切換えが必要な事象が発生した場合、待機系として動作しているシステム系Ｂ２００へ切換え、ＩＯデバイス１の初期化を行う。この時、システム系Ａ１００で発生した系切換えが必要になった要因をＣＰＵ間通信と共有メモリ３３を使用してシステム系Ｂ２００へ通知する。システム系Ｂ２００では系切換えの要因に応じて初期化が必要なＩＯデバイス１の初期化（図２におけるステップＳＴ５）のみ行い、系切換えの要因と関連なく、正常に動作していたＩＯデバイス１は切換ったシステム系Ｂ２００で引き継いで動作を行う。即ち、実施の形態３の系切換手段は、系の切換要因に従い、初期化を行う必要のない周辺ハードウェアは切換前の状態を継続して使用し、その周辺ハードウェアは初期化を行わない。

以上説明したように、実施の形態３の高可用性システムによれば、系切換手段は、系の切換要因に従い、初期化を行う必要のない周辺ハードウェアは切換前の状態を継続して使用し、その周辺ハードウェアを初期化の対象から除くようにしたので、系切換えの要因の影響を受けないＩＯデバイス情報は引き継いで使用することで、必要なＩＯデバイスの初期化のみ実施すればよく、初期化時間の短縮が可能になり、切換った系の起動時間を短縮することができる。

なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。

１ ＩＯデバイス、２ 不揮発メモリ、３ メモリ、３１ 系Ａ用メモリ、３２ 系Ｂ用メモリ、３３ 共有メモリ、４ 通信路、１００，１００ａ システム系Ａ、１０１，１０１ａ，１０１ｂ，１０１ｃ，２０１ ＣＰＵ、１０２，２０２ ＯＳ、１０３，２０３ ＣＰＵ間通信部、１０４，１０４ａ，２０４，２０４ａ アプリケーションプログラム、１０５，２０５ 異常検出処理部、１０６，２０６ ＩＯアクセス制御部、１０７，２０７ ＩＯアクセススケジューリング部。

Claims (6)

1. 複数の演算ＣＰＵを有するマルチコアプロセッサと、前記複数の演算ＣＰＵが共通して用いる周辺ハードウェアとを搭載した装置を用いた高可用性システムであって、
   前記複数の演算ＣＰＵを運用系と待機系に分割して多重系システムを構築すると共に、前記周辺ハードウェアは、前記運用系と前記待機系のそれぞれの起動情報を格納するための起動情報格納部を有し、
   前記運用系と前記待機系のそれぞれは、
   前記起動情報に従って前記運用系と前記待機系とを運用可能状態とする起動手段と、
   前記運用系の稼働状態の監視を行い、当該運用系の異常を検出する異常検出手段と、
   前記運用系の異常が検出された場合は、前記待機系を前記運用系として系切換を行うと共に、前記起動情報を当該系切換に対応して更新する系切換手段と、
   前記運用系から前記待機系に切換った場合に、前記待機系としての再起動を行う再起動手段とを備え、
   前記待機系は運用可能状態の後にスリープ状態に移行し、かつ、当該スリープ状態移行後、周期的に前記異常検出手段が起動し監視を行い、
   前記運用系の前記異常検出手段は、系内監視を行うことで、前記運用系の稼働状態の監視を行い、
   前記待機系の前記異常検出手段は、前記演算ＣＰＵ間の通信を利用した系間監視を行うことで、前記運用系の稼働状態の監視を行う
   ことを特徴とする高可用性システム。
2. 前記系切換手段は、前記異常が検出された場合以外に、所定の系切換要求に基づいて系切換を行うことを特徴とする請求項１記載の高可用性システム。
3. 前記運用系の前記起動手段は、前記待機系の起動処理を行う際、前記運用系の通常動作を優先することを特徴とする請求項１または請求項２記載の高可用性システム。
4. 前記待機系の前記起動手段は、当該待機系の起動処理を行う際、前記運用系の通常動作を優先することを特徴とする請求項１から請求項３のうちのいずれか１項記載の高可用性システム。
5. 前記運用系と前記待機系とで前記複数のＣＰＵの分割比率を不均一として、ＣＰＵの分割比率が高い系を前記運用系とし、当該運用系の異常による系切換が発生した場合は前記再起動を行い、当該再起動完了後、再度前記ＣＰＵの分割比率の高い系を運用系とする系切換を行うことを特徴とする請求項１から請求項４のうちのいずれか１項記載の高可用性システム。
6. 前記系切換手段は、系の切換要因に従い、初期化を行う必要のない周辺ハードウェアは切換前の状態を継続して使用し、当該周辺ハードウェアを初期化の対象から除くことを特徴とする請求項１から請求項５のうちのいずれか１項記載の高可用性システム。

Images