以下に、本願の開示するスイッチ装置及び情報処理システムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示するスイッチ装置及び情報処理システムが限定されるものではない。
図1は、実施例1に係る情報処理システムのブロック図である。情報処理システム100は、スイッチ装置1及び2、情報処理装置であるサーバ3、並びに、外部ネットワーク4を有する。情報処理システム100は、サーバ3と外部ネットワーク4とを接続する冗長化されたネットワーク構成を有する。冗長化されたネットワークのそれぞれに、スイッチ装置1とスイッチ装置2とが配置される。
スイッチ装置1とスイッチ装置2とは、同様の機能を有する装置である。ただし、図1では、図示の都合上、スイッチ装置2の通信ポート21及び22以外の構成及び機能を省略した。スイッチ装置1は、通常時にサーバ3と外部ネットワーク4との間の通信の中継を実行するアクティブ側スイッチである。一方、スイッチ装置2は、スイッチ装置1に接続するサーバ3の通信ポート31がリンクダウンした場合に、スイッチ装置1に代わってサーバ3と外部ネットワーク4との間の通信の中継を実行するスタンバイ側スイッチである。スイッチ装置1が、「第1スイッチ装置」の一例にあたる。また、スイッチ装置2が、「第2スイッチ装置」の一例にあたる。
スイッチ装置1は、通信ポート11及び12、メモリ13、CPU14、並びに、スイッチチップ15を有する。CPU14は、I2C(Inter Integrated Circuit)などの内部接続バス16によりメモリ13及びスイッチチップ15と接続される。また、スイッチチップ15は、通信ポート11及び12と接続される。ここで、本実施例では、スイッチ装置1が通信ポート11及び12という2つのポートを有する場合で説明したが、このポートの数に特に制限は無い。また、以下では、冗長構成をとるスイッチ装置1とスイッチ装置2の組において、一方に対して他方を冗長スイッチと呼ぶ場合がある。
通信ポート11は、外部ネットワーク4に繋がるネットワークポートである。通信ポート11は、外部ネットワーク4から受信した信号をスイッチチップ15へ出力する。また、通信ポート11は、スイッチチップ15から入力された信号を外部ネットワーク4へ送信する。
通信ポート12は、サーバ3に繋がるネットワークポートである。通信ポート12は、サーバ3から受信した信号をスイッチチップ15へ出力する。また、通信ポート12は、スイッチチップ15から入力された信号をサーバ3へ送信する。
メモリ13は、記憶媒体である。メモリ13は、ファームウェア設定ファイル131及び冗長スイッチ稼働情報132を有する。
ファームウェア設定ファイル131は、CPU14がソフトウェアを実行することで動作するファームウェア140の動作時の設定情報が登録されたファイルである。本実施例では、ファームウェア設定ファイル131は、少なくともキープアライブのタイムアウト時間の情報が登録される。
冗長スイッチ稼働情報132は、冗長スイッチであるスイッチ装置2の稼働状態の情報が格納される。冗長スイッチ稼働情報132には、CPU14によりスイッチ装置2の稼働状態の情報が書き込まれる。
CPU14は、ファームウェア140を起動し動作させる。このCPU14が、「制御部」の一例にあたる。ファームウェア140は、起動後にメインプロセス141を起動させる。
メインプロセス141は、ファームウェア140の起動後に起動する。そして、メインプロセス141は、ファームウェア設定ファイル131に登録された設定情報を読み込む。その後、メインプロセス141は、読み込んだ設定情報にしたがって、主機能プロセス142及びキープアライブ送信プロセス143を起動させる。
また、メインプロセス141は、例えば、外部ネットワーク4、通信ポート11及びスイッチチップ15を介してスイッチ装置2のメインプロセス141との間で通信を行い、相互に稼働状態の情報の送受信を行う。その後、メインプロセス141は、取得した冗長スイッチの稼働状態の情報を冗長スイッチ稼働情報132に登録する。
また、メインプロセス141は、読み込んだ設定情報からキープアライブのタイムアウト時間の情報を取得して、スイッチチップ15へ出力する。このメインプロセス141が、「管理部」の一例にあたる。
主機能プロセス142は、メインプロセス141により起動される。主機能プロセス142は、ソフトウェア的な処理を実行して、スイッチチップ15と協調して動作する。具体的には、主機能プロセス142は、スパニングツリープロトコルのBPDUパケット処理、マルチキャストのIGMPスヌーピング、リンクアグリゲーションのLACPパケット処理及びSNMPやSSHなどのスイッチ管理を制御する。例えば、主機能プロセス142は、図2に記載した受信フレーム200の宛先MAC(Media Access Control)アドレス以外の情報を用いて受信した信号の転送を制御する。
図2は、受信フレームのフォーマットの一例を表す図である。スイッチ装置1が受信する信号である受信フレーム200は、図2に示すように、プリアンブル、宛先MACアドレス、送信元MACアドレス、タイプ、データ及びFCS(Frame Check Sequence)を有する。例えば、主機能プロセス142は、受信フレーム200のフォーマットを有する信号からプリアンブル、宛先MACアドレス、送信MACアドレス及びタイプに格納された情報を取得する。そして、主機能プロセス142は、取得した情報を用いて信号の転送を制御する。
例えば、IGMPスヌーピングであれば、主機能プロセス142は、取得した情報から特定のグループへの転送であることを確認し、その特定のグループに対してスイッチチップ15に信号を送信させる。主機能プロセス142は、実行する各処理においてメモリ13を使用する場合がある。この主機能プロセス142が、「実行部」の一例にあたる。
キープアライブ送信プロセス143は、メインプロセス141により起動される。キープアライブ送信プロセス143は、CPU14が正常に動作中していることを表すキープアライブ信号を定期的にCPU異常監視処理部153へ出力する。キープアライブ送信プロセス143は、CPU14における異常発生などによりキープアライブ信号の送信を停止する。このキープアライブ送信プロセス143が、「通知部」の一例にあたる。そして、キープアライブ信号が、「生存通知」の一例にあたる。また、メインプロセス141、主機能プロセス142及びキープアライブ送信プロセス143が実行する処理が、「自装置の動作の統括制御」の一例にあたる。
スイッチチップ15は、MAC制御機構、スイッチングエンジン及びパケットバッファをチップ化した回路であり、LSI(Large Scale Integration)などで実現される。スイッチチップ15は、転送処理部151、設定記憶部152及びCPU異常監視処理部153を有する。
転送処理部151は、サーバ3から送出された信号の入力を通信ポート12から受ける。そして、転送処理部151は、取得した信号の図2に示す宛先MACアドレスを確認し、その宛先MACアドレスを有する機器に向けて通信ポート11を介して信号を外部ネットワーク4へ送信する。逆に、転送処理部151は、外部ネットワーク4から受信した信号の入力を通信ポート11から受ける。そして転送処理部151は、取得した信号の宛先MACアドレスを確認し、通信ポート12を介して信号をサーバ3へ送信する。さらに、転送処理部151は、主機能プロセス142からの指示を受けて、他の機器やサーバ3に対する信号の送信を制御する。
ここで、本実施例では、転送処理部151が宛先MACアドレスを用いてデータ転送を行い、主機能プロセス142は受信フレーム200の宛先MACアドレス以外の情報も用いて受信した信号の転送を制御する場合で説明した。ただし、この転送処理部151が転送に用いる情報は他の転送先アドレスを示す情報でもよく、例えば、IP(Internet Protocol)アドレスや装置アドレスであってもよい。
さらに、転送処理部151は、動作停止の指示をCPU異常監視処理部153から受ける。そして、転送処理部151は、CPU異常監視処理部153からの指示にしたがい、信号の転送処理の動作を停止する。
設定記憶部152は、スイッチチップ15が有する記憶領域である。設定記憶部152は、CPU異常監視処理部153から入力されたキープアライブのタイムアウト時間を格納して保持する。
CPU異常監視処理部153は、キープアライブのタイムアウト時間の入力をメインプロセス141から受ける。そして、CPU異常監視処理部153は、取得したキープアライブのタイムアウト時間を設定記憶部152へ出力して記憶させる。
また、CPU異常監視処理部153は、キープアライブ受信待ちタイマを有する。CPU異常監視処理部153は、キープアライブのタイムアウト時間の設定記憶部152への格納後に、自己が有するキープアライブ受信待ちタイマを開始する。その後、CPU異常監視処理部153は、キープアライブ送信プロセス143からキープアライブ信号を受信するまで、又は、キープアライブ受信待ちタイマが設定記憶部152に格納されたキープアライブのタイムアウト時間に達するまで待機する。
キープアライブ送信プロセス143からキープアライブ信号を受信した場合、CPU異常監視処理部153は、キープアライブ受信待ちタイマをリセットして、キープアライブ信号の受信を待つ状態に戻る。
これに対して、キープアライブ信号を受信しない状態でキープアライブ受信待ちタイマがキープアライブのタイムアウト時間に達した場合、CPU異常監視処理部153は、CPU14に異常が発生したと判定する。次に、CPU異常監視処理部153は、メモリ13に格納された冗長スイッチ稼働情報132を参照して、冗長スイッチであるスイッチ装置2が稼働しているか否かを判定する。
スイッチ装置2が稼働していない場合、CPU異常監視処理部153は、動作停止の指示は送らずに、転送処理部151の動作を継続させる。この場合、スイッチ装置2が動作していない状態で転送処理部151の動作を停止すると、サーバ3と外部ネットワーク4との間の通信が完全に停止する。そのような事態を避けるために、スイッチ装置1としてはCPU14を用いた信号転送の制御機能は使用困難な状態であるが、CPU異常監視処理部153は、少なくとも転送処理部151による宛先MACアドレスを用いた信号の転送を継続させる。
一方、スイッチ装置2が稼働中の場合、CPU異常監視処理部153は、転送処理部151に動作の停止を指示する。これにより、転送処理部151の動作が停止し、通信ポート12との間の信号の送受信が行われなくなる。これにより、サーバ3においてリンクダウンを強制的に発生させることができる。
サーバ3は、通信ポート31及び32、並びに、冗長制御部33を有する。通信ポート31は、スイッチ装置1の通信ポート12に接続される。また、通信ポート32は、スイッチ装置2の通信ポート22に接続される。
冗長制御部33は、例えば、サーバ3のCPUがチーミングソフトを実行することで実現される機能である。本実施例では、冗長制御部33は、通信ポート31をアクティブ側とし、通信ポート32をスタンバイ側とする。その後、冗長制御部33は、通信ポート31におけるリンクの確立状態を監視する。
冗長制御部33は、通信ポート31とスイッチ装置1との間の信号の送受信が停止した場合、通信ポート31のリンクダウンが発生したと判定する。そして、通信ポート31がリンクダウンすると、冗長制御部33は、通信ポート31の動作を停止し、通信ポート32をスタンバイ状態からアクティブ状態に変える。これにより、スイッチ装置2がアクティブとなり、サーバ3は、スイッチ装置2を介して外部ネットワーク4と通信を行う。
次に、図3A及び3Bを参照して、本実施例に係る情報処理システム100におけるCPU障害発生時の動作について説明する。図3A及び3Bは、実施例1に係る情報処理システムにおけるCPU障害発生時の動作のシーケンス図である。
ファームウェア140は、CPU14により起動される。そして、ファームウェア140が起動すると、メインプロセス141が起動する(ステップS101)。
次に、メインプロセス141は、メモリ13に格納されたファームウェア設定ファイル131を読み込む(ステップS102)。
次に、メインプロセス141は、ファームウェア設定ファイル131にしたがって各プロセスを起動させる(ステップS103)。
キープアライブ送信プロセス143は、メインプロセス141により起動される(ステップS104)。
次に、メインプロセス141は、スイッチ装置2との間で稼働状態を相互に確認する(ステップS105)。この時、スイッチ装置2も、同様に稼働状態の相互確認を実行する(ステップS106)。
次に、メインプロセス141は、メモリ13の冗長スイッチ稼働情報132にスイッチ装置2の稼働状態の情報を書き込む(ステップS107)。メモリ13の冗長スイッチ稼働情報132は、スイッチ装置2の稼働状態の情報を保持する(ステップS108)。
次に、メインプロセス141は、キープアライブのタイムアウト時間をスイッチチップ15のCPU異常監視処理部153に通知する(ステップS109)。
CPU異常監視処理部153は、キープアライブのタイムアウト時間をメインプロセス141から取得する。そして、CPU異常監視処理部153は、取得したキープアライブのタイムアウト時間を設定記憶部152に格納してキープアライブのタイムアウト時間を設定する(ステップS110)。
その後、CPU異常監視処理部153は、自己が有するキープアライブ受信待ちタイマを開始する(ステップS111)。
そして、CPU異常監視処理部153は、キープアライブ信号の受信待ち状態で待機する(ステップS112)。
キープアライブ送信プロセス143は、CPU14に異常が発生していなければキープアライブ信号をCPU異常監視処理部153へ送信する(ステップS113)。ただし、CPU14に異常が発生し、キープアライブ送信プロセス143がキープアライブ信号を送信することが困難な状態になる場合もある。
CPU異常監視処理部153は、キープアライブ信号をキープアライブ送信プロセス143から受信したか否かを判定する(ステップS114)。キープアライブ信号を受信した場合(ステップS114:肯定)、CPU異常監視処理部153は、ステップS111へ戻る。
これに対して、キープアライブ信号を受信しない場合(ステップS114:否定)、CPU異常監視処理部153は、キープアライブのタイムアウト時間が経過したか否かを判定する(ステップS115)。キープアライブのタイムアウト時間が経過していない場合(ステップS115:否定)、CPU異常監視処理部153は、ステップS112へ戻る。
一方、キープアライブのタイムアウト時間が経過した場合(ステップS115:肯定)、CPU異常監視処理部153は、CPU14で異常が発生したと判定する(ステップS116)。
次に、CPU異常監視処理部153は、冗長スイッチ稼働情報132からスイッチ装置2の稼働状態の情報を取得する(ステップS117)。
そして、CPU異常監視処理部153は、取得したスイッチ装置2の稼働状態の情報から、冗長スイッチであるスイッチ装置2が動作しているか否かを判定する(ステップS118)。
冗長スイッチが動作していない場合(ステップS118:否定)、CPU異常監視処理部153は、動作の停止を指示せずに、転送処理部151の信号転送処理の動作を継続させる(ステップS119)。
これに対して、冗長スイッチが動作している場合(ステップS118:肯定)、CPU異常監視処理部153は、動作の停止を転送処理部151に指示する(ステップS120)。
転送処理部151は、CPU異常監視処理部153からの指示を受けて、信号の転送処理の動作を停止する(ステップS121)。
転送処理部151の信号の転送処理の動作が停止することで、サーバ3の通信ポート31で、リンクダウンが発生する(ステップS122)。
冗長制御部33は、通信ポート31のリンクダウンを検出する(ステップS123)。
その後、冗長制御部33は、フェイルオーバー処理を実行する(ステップS124)。
通信ポート31は、冗長制御部33のフェイルオーバー処理により動作を停止する(ステップS125)。
通信ポート32は、冗長制御部33のフェイルオーバー処理により、スタンバイ状態からアクティブ状態へ変化する(ステップS126)。
通信ポート32がアクティブ状態に変化すると、スイッチ装置2は、アクティブ状態に遷移する(ステップS127)。
以上に説明したように、本実施例に係るスイッチ装置は、CPUに異常が発生した場合に、スイッチチップがCPUの異常発生を検出して転送処理の動作を停止する。これにより、サーバとCPUに異常が発生したスイッチ装置との間のリンクダウンを強制的に発生させることができる。転送処理の動作が停止するとサーバのチーミングソフトがリンクダウンを検出して、信号の転送処理を冗長スイッチが行うように信号の転送経路が切り替えられる。これにより、CPUに異常が発生した状態で、スイッチチップ単独の転送機能により一部の信号が転送される場合でも、迅速にスイッチの障害を検知することができ、ネットワークの信頼性を向上させることが可能となる。
また、例えば、チーミングソフトによる冗長構成を有する情報処理システムにおいて、CPUに異常が発生したがスイッチチップの転送機能の動作が継続する場合、一部のフレームは正常に転送されるが、通信ポートのリンクダウンは発生しない。この場合、チーミングソフトはアクティブな経路が使用困難になったことを検知しないため、経路の切り替えが発生しない。そのため、CPUを使用する機能は停止したままとなり、スイッチ装置は正常動作を行えず、ネットワークの信頼性が損なわれてしまう。
さらに、例えば、チーミングソフトには通信ポートのリンクダウンによる障害検知の他に、チーミングソフトから通信相手にpingを送信して、接続先からの応答の有無によりアクティブな経路の状態を確認する方式がある。しかし、CPU異常が発生してもスイッチの転送機能が動作していれば、スイッチチップによりpingの送受信は行われるため、pingにより経路状態の確認を行う方式であっても、アクティブな経路が使えなくなったことを検知することは困難である。
また、指定したリンクの障害に応じて他のリンクをダウンさせる従来技術を用いても、スイッチの転送機能が生きた状態でのCPUの障害発生の検知を行うことはないため、ネットワークの信頼性を向上させることは困難である。また、従系の制御装置でCPUの障害が発生した場合にリンクダウンを発生させる従来技術を用いても、スイッチ内部のCPUの障害の検知は行わないため経路の切り替えは行われず、ネットワークの信頼性を向上させることは困難である。また、プロセスの所定回数再起動後に装置を再起動させる従来技術や、共有メモリの情報を基に異常発生を判定する従来技術では、スイッチのCPUの障害による経路切り替えについては考慮されておらず、ネットワークの信頼性を向上させることは困難である。
これに対して、本実施例に係るスイッチ装置は、CPU異常が発生した場合に転送経路を強制的に切り替える。これにより、CPUに異常が発生し宛先MACアドレス以外の情報を加えた信号の転送処理が行えない状態で、冗長スイッチへの切り替えが発生せずに、宛先MACアドレスを用いた転送処理が継続することを回避できる。したがって、一部の機能が停止した状態のスイッチの使用を回避して、宛先MACアドレス以外の情報を加えた信号の転送処理を含むスイッチ装置の各機能を使用した通信を継続することができ、ネットワークの信頼性を向上させることができる。
図4は、実施例2に係る情報処理システムのブロック図である。本実施例に係る情報処理システム100は、各プロセスに異常が発生してもリセットを行い、正常状態に復帰可能であるかを確かめることが実施例1と異なる。以下の説明では、実施例1と同様の各部の機能については説明を省略する。
メモリ13は、図5に示すリセット回数記録テーブル133を有する。図5は、リセット回数記録テーブルの一例の図である。リセット回数記録テーブル133は、メインプロセス141以外のプロセス毎にリセット回数を登録可能なテーブルである。本実施例では、主機能プロセス142に含まれる詳細なプロセス毎にリセット回数が登録される場合を記載した。STPは、スパニングツリープロトコル(Spanning Tree Protocol)を実行するプロセスを表す。マルチキャストは、マルチキャストで通信を行うためのプロセスを表す。ただし、リセット回数記録テーブル133は、主機能プロセス142を1つの項目として取り扱ってもよい。本実施例では、主機能プロセス142に含まれる詳細な各プロセス及びキープアライブ送信プロセス143をまとめて監視プロセスと呼ぶ場合がある。
図4に戻って説明を続ける。メインプロセス141は、ファームウェア設定ファイル131から設定情報を取得する。ファームウェア設定ファイル131には、キープアライブのタイムアウト時間、ビーコンのタイムアウト時間及びプロセスリセットの最大回数として予め決められた所定回数が含まれる。さらに、ファームウェア設定ファイル131には、ファームウェア140によるメモリ13の使用量の閾値、各監視プロセスによるメモリ13の使用量の閾値が含まれる。
メインプロセス141は、ビーコン受信待ちタイマを起動させた監視プロセス毎に有する。メインプロセス141は、監視プロセスを起動後、各監視プロセスのビーコン受信待ちタイマを開始する。その後、メインプロセス141は、各監視プロセスからのビーコンの受信待ち状態で待機する。
各監視プロセスからビーコンを受信した場合、メインプロセス141は、ビーコンを受信した監視対象プロセスのビーコン受信待ちタイマをリセットして再開する。そして、メインプロセス141は、各監視プロセスからのビーコンの受信待ち状態に戻る。
これに対して、ビーコンの受信が行われずにビーコンのタイムアウト時間が経過した監視プロセスが存在する場合、メインプロセス141は、その監視プロセスに障害が発生したと判定する。そして、メインプロセス141は、メモリ13のリセット回数記録テーブル133を参照して、その監視プロセスのリセットが所定回数行われたか否かを判定する。その監視プロセスのリセット回数が所定回数未満の場合、メインプロセス141は、障害が発生したと判定した監視プロセスをリセットする。次に、メインプロセス141は、リセット回数記録テーブル133における障害が発生したと判定した監視プロセスのリセット回数を1つインクリメントする。その後、メインプロセス141は、リセットした監視プロセスのビーコン受信待ちタイマをリセットして再開する。そして、メインプロセス141は、各監視プロセスからのビーコンの受信待ち状態に戻る。
また、メインプロセス141は、ビーコンの受信待ち状態でファームウェア140及び各監視プロセスのメモリ使用量を定期的に取得する。ここで、ファームウェア140及び各監視プロセスのメモリ使用量は、ファームウェア140のOS(Operating System)が管理しており、メインプロセス141は、OSからそれらの情報を取得することができる。
ファームウェア140のメモリ使用量が予め決められたファームウェア140のメモリ使用量の閾値であるファームウェア閾値を超えている場合、メインプロセス141は、メモリ13が枯渇状態と判定する。メモリ13が枯渇した場合には処理を継続することが困難なため、メインプロセス141は、各監視プロセスを停止させる。
これに対して、ファームウェア140のメモリ13の使用量がファームウェア閾値を超えていない場合、メインプロセス141は、各監視プロセスのメモリ使用量がそれぞれのプロセスのメモリ使用量の閾値であるプロセス閾値を超えているか否かを判定する。このプロセス閾値が、「所定閾値」の一例にあたる。メモリ使用量がプロセス閾値を超えた監視プロセスが存在する場合、メインプロセス141は、メモリ13のリセット回数記録テーブル133を参照して、その監視プロセスのリセットが所定回数行われたか否かを判定する。ここで、本実施例で使用する使用量は、実際の量を示す実量であってもよいし、割合を示す使用率であってもよい。
その監視プロセスのリセット回数が所定回数未満の場合、メインプロセス141は、その監視プロセスをリセットする。次に、メインプロセス141は、リセット回数記録テーブル133における障害が発生したと判定した監視プロセスのリセット回数を1つインクリメントする。その後、メインプロセス141は、リセットした監視プロセスのビーコン受信待ちタイマをリセットして再開する。そして、メインプロセス141は、各監視プロセスからのビーコンの受信待ち状態に戻る。
これに対して、その監視プロセスのリセット回数が所定回数に達した場合、メインプロセス141は、全ての監視プロセスを停止する。これにより、キープアライブ送信プロセス143も停止する。
主機能プロセス142に属する各監視プロセスは、定期的にビーコンをメインプロセス141へ出力する。ただし、主機能プロセス142に属する監視プロセスのいずれかで障害が発生した場合には、その障害が発生した主機能プロセス142は、ビーコンの送信を行わない場合がある。主機能プロセス142に含まれる各プロセスのうちメインプロセス141からリセットの指示を受けた監視プロセスは、自己のリセットを行い再起動して、ビーコンを送信する状態に戻る。
また、リセットが所定回数を超えた場合、主機能プロセス142に属する各監視プロセスは、メインプロセス141から動作停止の制御を受ける。そして、主機能プロセス142に含まれる詳細な各プロセスは、自己の動作を停止する。
キープアライブ送信プロセス143は、定期的にビーコンをメインプロセス141へ出力する。ただし、障害が発生した場合には、キープアライブ送信プロセス143は、ビーコンの送信が困難となることがある。その後、キープアライブ送信プロセス143は、メインプロセス141からリセットの指示を受けて、自己のリセットを行い再起動して、ビーコンを送信する状態に戻る。
また、リセットが所定回数を超えた場合、キープアライブ送信プロセス143は、メインプロセス141から動作停止の制御を受ける。そして、キープアライブ送信プロセス143は、自己の動作を停止する。これにより、キープアライブ送信プロセス143は、キープアライブ信号のCPU異常監視処理部153への送信を停止する。
次に、図6A及び6Bを参照して、実施例に係る情報処理システム100におけるCPU障害発生時の動作の流れを説明する。図6A及び6Bは、実施例2に係る情報処理システムにおけるCPU障害発生時の動作のシーケンス図である。
ファームウェア140は、CPU14により起動される。そして、ファームウェア140が起動すると、メインプロセス141が起動する(ステップS201)。
次に、メインプロセス141は、メモリ13に格納されたファームウェア設定ファイル131を読み込む(ステップS202)。
次に、メインプロセス141は、ファームウェア設定ファイル131にしたがって各プロセスを起動させる(ステップS203)。
主機能プロセス142は、メインプロセス141により起動される(ステップS204)。キープアライブ送信プロセス143は、メインプロセス141により起動される(ステップS205)。
次に、メインプロセス141は、スイッチ装置2との間で稼働状態を相互に確認する(ステップS206)。この時、スイッチ装置2も、同様に稼働状態の相互確認を実行する(ステップS207)。
次に、メインプロセス141は、メモリ13の冗長スイッチ稼働情報132にスイッチ装置2の稼働状態の情報を書き込む(ステップS208)。メモリ13の冗長スイッチ稼働情報132は、スイッチ装置2の稼働状態の情報を保持する(ステップS209)。
次に、メインプロセス141は、キープアライブのタイムアウト時間をスイッチチップ15のCPU異常監視処理部153に通知する(ステップS210)。
CPU異常監視処理部153は、キープアライブのタイムアウト時間をメインプロセス141から取得する。そして、CPU異常監視処理部153は、取得したキープアライブのタイムアウト時間を設定記憶部152に格納してキープアライブのタイムアウト時間を設定する(ステップS211)。
メインプロセス141は、監視プロセス毎のビーコンの受信待ちタイマを開始する(ステップS212)。そして、メインプロセス141は、ビーコンの受信待ち状態で待機する(ステップS213)。
主機能プロセス142に含まれる各監視プロセスは、ビーコンをメインプロセス141へ送信する(ステップS214)。ただし、異常が発生した監視プロセスは、ビーコンが送信困難となる場合がある。
キープアライブ送信プロセス143は、ビーコンをメインプロセス141へ送信する(ステップS215)。ただし、異常が発生した場合には、キープアライブ送信プロセス143からのビーコン送信が困難となる場合がある。
CPU異常監視処理部153は、自己が有するキープアライブ受信待ちタイマを開始する(ステップS216)。
そして、CPU異常監視処理部153は、キープアライブ信号の受信待ち状態で待機する(ステップS217)。
キープアライブ送信プロセス143は、メインプロセス141により動作が停止されていなければキープアライブ信号をCPU異常監視処理部153へ送信する(ステップS218)。
メインプロセス141は、ファームウェア140及び各監視プロセスのメモリ使用量を取得する(ステップS219)。
次に、メインプロセス141は、ファームウェア140のメモリ使用量がファームウェア閾値以上か否かを判定する(ステップS220)。ファームウェア140のメモリ使用量がファームウェア閾値以上の場合(ステップS220:肯定)、メインプロセス141は、ステップS232へ進む。
これに対して、ファームウェア140のメモリ使用量がファームウェア閾値未満の場合(ステップS220:否定)、メインプロセス141は、各監視プロセスのメモリ13のメモリ使用量がそれぞれのプロセス閾値以上か否かを判定する(ステップS221)。
メモリ使用量がプロセス閾値以上である監視プロセスが存在する場合(ステップS221:肯定)、メインプロセス141は、ステップS225へ進む。
これに対して、メモリ使用量がプロセス閾値以上となる監視プロセスが存在しない場合(ステップS221:否定)、メインプロセス141は、全ての監視プロセスからビーコンを受信したか否かを判定する(ステップS222)。全ての監視プロセスからビーコンを受信した場合(ステップS222:肯定)、メインプロセス141は、ステップS212へ戻る。
これに対して、ビーコンを受信していない監視プロセスが存在する場合(ステップS222:否定)、メインプロセス141は、その監視プロセスのビーコンの受信待ちタイムアウト時間が経過したか否かを判定する(ステップS223)。ビーコンの受信待ちタイムアウト時間が経過していない場合(ステップS223:否定)、メインプロセス141は、ステップS213へ戻る。
これに対して、ビーコンの受信待ちタイムアウト時間が経過した場合(ステップS223:肯定)、メインプロセス141は、ビーコンを受信せずにビーコンの受信待ちタイムアウト時間が経過したプロセスに異常が発生したと判定する(ステップS224)。
次に、メインプロセス223は、メモリ13のリセット回数記録テーブル133を参照して、異常が発生した監視プロセス及びメモリ13の使用量が閾値を超えた各監視プロセスについてリセットが所定回数実行されたか否かを判定する(ステップS225)。
リセットが所定回数実行された監視プロセスが存在しない場合(ステップS225:否定)、メインプロセス223は、異常が発生した監視プロセス及びメモリ13の使用量が閾値を超えた各監視プロセスのリセット処理を実行する(ステップS226)。その後、メインプロセス141は、ステップS212へ戻る。
主機能プロセス142に属する各監視プロセスは、メインプロセス141からリセット指示を受信したか否かを判定する(ステップS227)。リセット指示を受信していない場合(ステップS227:否定)、主機能プロセス142に属する各監視プロセスは、ステップS233へ進む。
これに対して、リセット指示を受信した場合(ステップS227:肯定)、主機能プロセス142に属する各監視プロセスは、自己のリセットを実行する(ステップS228)。
また、キープアライブ送信プロセス143は、メインプロセス141からリセット指示を受信したか否かを判定する(ステップS229)。リセット指示を受信していない場合(ステップS229:否定)、キープアライブ送信プロセス143は、ステップS235へ進む。
これに対して、リセット指示を受信した場合(ステップS229:肯定)、キープアライブ送信プロセス143は、自己のリセットを実行する(ステップS230)。
一方、リセットが所定回数実行された監視プロセスが存在する場合(ステップS225:肯定)、メインプロセス223は、その監視プロセスが起動不可と判定する(ステップS231)。
メインプロセス223は、起動不可と判定したプロセスが存在する場合又はファームウェア140のメモリ13の使用量がファームウェア閾値以上であれば、監視プロセスを停止する(ステップS232)。
主機能プロセス142に属する各監視プロセスは、メインプロセス141から停止指示を受信したか否かを判定する(ステップS233)。停止指示を受信していない場合(ステップS233:否定)、主機能プロセス142に属する各監視プロセスは、ステップS214へ戻る。
これに対して、停止指示を受信した場合(ステップS233:肯定)、主機能プロセス142に属する各監視プロセスは、自己の動作を停止する(ステップS234)。
また、キープアライブ送信プロセス143は、メインプロセス141から停止指示を受信したか否かを判定する(ステップS235)。停止指示を受信していない場合(ステップS235:否定)、キープアライブ送信プロセス143は、ステップS215へ戻る。
これに対して、停止指示を受信した場合(ステップS235:肯定)、キープアライブ送信プロセス143は、自己の動作を停止する(ステップS236)。
その後、メインプロセス141は、自己の動作を停止する(ステップS237)。
以上の処理により、キープアライブ送信プロセス143は、キープアライブ信号の送信を停止する(ステップS238)。
CPU異常監視処理部153は、キープアライブ信号をキープアライブ送信プロセス143から受信したか否かを判定する(ステップS239)。キープアライブ信号を受信した場合(ステップS239:肯定)、CPU異常監視処理部153は、ステップS216へ戻る。
これに対して、キープアライブ信号を受信しない場合(ステップS239:否定)、CPU異常監視処理部153は、キープアライブのタイムアウト時間が経過したか否かを判定する(ステップS240)。キープアライブのタイムアウト時間が経過していない場合(ステップS240:否定)、CPU異常監視処理部153は、ステップS217へ戻る。
一方、キープアライブのタイムアウト時間が経過した場合(ステップS240:肯定)、CPU異常監視処理部153は、CPU14で異常が発生したと判定する(ステップS241)。
次に、CPU異常監視処理部153は、冗長スイッチ稼働情報132からスイッチ装置2の稼働状態の情報を取得する(ステップS242)。
そして、CPU異常監視処理部153は、取得したスイッチ装置2の稼働状態の情報から、冗長スイッチであるスイッチ装置2が動作しているか否かを判定する(ステップS243)。
冗長スイッチが動作していない場合(ステップS243:否定)、CPU異常監視処理部153は、動作の停止を指示せずに、転送処理部151の信号転送処理の動作を継続させる(ステップS244)。
これに対して、冗長スイッチが動作している場合(ステップS243:肯定)、CPU異常監視処理部153は、動作の停止を転送処理部151に指示する(ステップS245)。
転送処理部151は、CPU異常監視処理部153からの指示を受けて、信号の転送処理の動作を停止する(ステップS246)。
転送処理部151の新党の転送処理の動作が停止することで、サーバ3の通信ポート31で、リンクダウンが発生する(ステップS247)。
冗長制御部33は、通信ポート31のリンクダウンを検出する(ステップS248)。
その後、冗長制御部33は、フェイルオーバー処理を実行する(ステップS249)。
通信ポート31は、冗長制御部33のフェイルオーバー処理により動作を停止する(ステップS250)。
通信ポート32は、冗長制御部33のフェイルオーバー処理により、スタンバイ状態からアクティブ状態へ変化する(ステップS251)。
通信ポート32がアクティブ状態に変化すると、スイッチ装置2は、アクティブ状態に遷移する(ステップS252)。
以上に説明したように、本実施例に係るスイッチ装置は、ビーコンで管理プロセスの異常を検出し、異常が発生した管理プロセスのリセットを行って正常な状態に復帰するかを試す。また、各管理プロセスのメモリの使用量が多い場合にも、管理プロセスのリセットを行ってメモリの使用量が適切な使用量に収まるかを試行する。正常な状態に戻らない場合及びメモリの使用量が適切な量に収まらない場合、スイッチ装置は、CPUの異常発生を検出して転送処理の動作を停止する。また、ファームウェアによるメモリの使用量が大きい場合も、スイッチ装置は、転送処理の動作を停止する。転送処理の動作が停止するとチーミングソフトがリンクダウンを検出して、信号の転送処理を冗長スイッチが行うように信号の転送経路が切り替えられる。
このように、プロセスをリセットして正常な状態に復帰させる試みをすることで、復帰する可能性があるプロセスを助けて、切り替えを回避することができる。すなわち、プロセスに異常が発生した場合にも、正常な状態に復帰できれば、冗長構成を維持することができる。したがって、ネットワークの信頼性をより向上させることができる。また、メモリの状態を監視することで、メモリの枯渇による異常の発生も回避することができる。
ここで、本実施例では、プロセスのリセットに加えてメモリの異常の検知を行ったが、冗長性維持を目的とする場合、メモリの異常の検知は行わなくてもよい。また、メモリの異常の検知において、ファームウェアの使用状態と各管理プロセスの使用状態とを監視したが、いずれか一方を監視する構成であってもよい。