(57)【特許請求の範囲】
【請求項１】
通常動作において稼動する第１サーバと、
待機用の第２サーバと、を備え、
前記第１サーバは、
リソース使用率を取得し、前記リソース使用率が予め設定した閾値以上であるリソース使用率上昇状態を検出する第１リソース監視部と、
端末から受信する呼を処理し、前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数以上である場合には、前記第２サーバを待機状態から稼動状態へ切り替えさせるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示する第１呼処理部と、を備え、
前記第２サーバは、
前記端末から受信する呼を処理する第２呼処理部を備え、
前記第１リソース監視部は、
リソースの状態を監視し、前記リソース使用率を取得するリソース監視処理部と、
前記閾値として、第１閾値と、前記第１閾値より低い値の第２閾値とを保持し、前記リソース監視処理部が取得した前記リソース使用率が、前記第１閾値以上である場合に、前記リソース使用率上昇状態に設定し、前記リソース使用率上昇状態に設定した後、前記リソース使用率が前記第２閾値より低くなると、前記リソース使用率上昇状態を解除するリソースフラグ部と、を備え、
前記第１呼処理部は、前記受信呼数が前記最大処理呼数以上であると、前記第１リソース監視部に、前記リソース使用率上昇状態を検出する処理実施を指示するサーバ装置。
【請求項２】
前記第１呼処理部は、前記第２サーバの稼動中に前記リソース使用率上昇状態が解除されたことを検出すると、前記第２サーバを稼動状態から待機状態に切り替えさせることを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記第１及び第２サーバは、ＶｏＩＰサーバであることを特徴とする請求項１又は２に記載のサーバ装置。
【請求項４】
通常動作を実施する第１サーバと、待機用の第２サーバと、を備えるサーバ装置が実行する呼損低減方法であって、
前記第１サーバは、
端末から呼を受信し、
受信した呼数が予め設定した最大処理呼数を超えると、リソースの状態を管理・監視し、
前記リソース状態が予め設定した閾値を超えるリソース使用率上昇状態を検出し、
前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数を超える場合には、前記第２サーバを稼動させるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示し、
前記第２サーバは、
前記端末から呼を受信して処理し、
前記第１サーバは、
前記リソースの状態を監視し、前記リソース使用率を取得し、
前記閾値として、第１閾値と、前記第１閾値より低い値の第２閾値とを保持し、前記リソース使用率が、前記第１閾値以上である場合に、前記リソース使用率上昇状態に設定するリソースフラグをｕｐし、前記リソース使用率上昇状態に設定した後、前記リソース使用率が前記第２閾値より低くなると、前記リソースフラグをｄｏｗｎして前記リソース使用率上昇状態を解除する、呼損低減方法。
【請求項５】
通常動作において稼動する第１サーバと、待機用の第２サーバとを有するサーバ装置と、端末とを備える通信システムであって、
前記第１サーバは、
リソース使用率を取得し、前記リソース使用率が予め設定した閾値以上であるリソース使用率上昇状態を検出する第１リソース監視部と、
前記端末から受信する呼を処理し、前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数以上である場合には、前記第２サーバを待機状態から稼動状態へ切り替えさせるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示する第１呼処理部と、を備え、
前記第２サーバは、
前記端末から受信する呼を処理する第２呼処理部を備え、
前記端末は、前記第１サーバからの指示を受けると、呼を前記第２サーバへ送信し、
前記第１リソース監視部は、
リソースの状態を監視し、前記リソース使用率を取得するリソース監視処理部と、
前記閾値として、第１閾値と、前記第１閾値より低い値の第２閾値とを保持し、前記リソース監視処理部が取得した前記リソース使用率が、前記第１閾値以上である場合に、前記リソース使用率上昇状態に設定し、前記リソース使用率上昇状態に設定した後、前記リソース使用率が前記第２閾値より低くなると、前記リソース使用率上昇状態を解除するリソースフラグ部と、を備え、
前記第１呼処理部は、前記受信呼数が前記最大処理呼数以上であると、前記第１リソース監視部に、前記リソース使用率上昇状態を検出する処理実施を指示する通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置が端末から受信する呼の損失を低減する技術に関する。
【背景技術】
【０００２】
従来から、サーバ（サーバ装置）では、急激な呼の発生によりトラフィックが急上昇するため、サーバ側で呼の規制がかかる。このような場合、サーバは処理能力以上の呼を受信したことになる。そのため、大量の呼損を発生させることで、サーバが輻輳状態になることを防いでいた。
また、サーバは冗長構成を組んでおり、通常の運用時に稼動するＡＣＴ系（実行系）サーバに加え、ＳＢＹ系（待機系）サーバを備える。運用時のＳＢＹ系は障害発生時の切り替えサーバとして動作している。そのため、トラフィックが急上昇した際も処理を行うのはＡＣＴ系サーバのみで、ＳＢＹ系サーバが活用されることはなかった。
【０００３】
例えば、特許文献１には、一の系に障害が生じた場合に他の系が処理を代行し、且つ、ある系が高負荷状態に移行した場合に待機している系も処理を担う呼処理システムが開示されている。
また、特許文献２には、デュプレックスシステムを採用した冗長構成パケット交換装置において、待機系を実行系に切り替える技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−２５８７９１号公報
【特許文献１】特開平０４−１６２８５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
例えば、ＶｏＩＰ（Voice over Internet Protocol）の通信システムにおいて、サーバ装置では、第一に、トラフィックが急に上昇した際、ＶｏＩＰサーバが輻輳しないようにするため、受信呼を規制してしまうという問題がある。第二に、同一のハードウェア、ソフトウェア、処理能力を備えたＶｏＩＰサーバがあるにも関わらず、ＳＢＹ系のＶｏＩＰサーバの能力を使用することできないという問題がある。
【０００６】
第一の問題点について、図２を使って説明する。
サーバ装置１０は、ＶｏＩＰサーバ１０Ａ、ＶｏＩＰサーバ１０Ｂから構成され、ＩＰ端末５０Ａ、５０Ｂを収容している。１０ＡはＡＣＴ系、１０ＢはＳＢＹ系で稼動している。
例えば、図２において、ＩＰ端末５０ＡからＶｏＩＰサーバ１０Ａへの着信を許容範囲内の呼とし、１０Ａは最大受信数分の呼を受信したとする。その後、ＩＰ端末５０Ｂから許容範囲を超えた呼の着信があると、ＶｏＩＰサーバ１０Ａは受信可能呼数を超えるため、５０Ｂからの呼を呼損として扱っていた。このように、ＶｏＩＰサーバ１０Ａが輻輳を防ぎ、受信可能数を超えたＩＰ端末からの呼を拒否していたため、急激なトラフィック上昇時に大量の受信呼の規制が発生してしまうという問題があった。
第二の問題点について説明する。ＳＢＹ系ＶｏＩＰサーバは障害発生時の切り替え用サーバとして待機しているため、ＡＣＴ系稼動時はその処理能力が利用されることはない。ＡＣＴ系と一緒に稼動されることがないため、大量の受信呼が発生した場合、処理されることなく呼損を発生させていた。
【０００７】
特許文献１では、実行系と待機系のいずれかに呼を振り分けるかを、使用率に基づいて判定している。また、特許文献２においても、パケットの大きいものを選定して待機系に処理を実行させている。これらの関連技術では、呼を待機系に振り分ける前に、判定処理が実行されるため、呼損の量を低減するにはより迅速な対応が望まれていた。
【０００８】
本発明の実施形態の一態様は、サーバ装置で処理能力を超えた後に呼を受信した場合、処理能力を上げて呼損の量を低減する技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るサーバ装置の一態様は、通常動作において稼動する第１サーバと、待機用の第２サーバと、を備え、前記第１サーバは、リソース使用率を取得し、前記リソース使用率が予め設定した閾値以上であるリソース使用率上昇状態を検出する第１リソース監視部と、端末から受信する呼を処理し、前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数以上である場合には、前記第２サーバを待機状態から稼動状態へ切り替えさせるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示する第１呼処理部と、を備え、前記第２サーバは、前記端末から受信する呼を処理する第２呼処理部を備える。
【００１０】
また、本発明に係る呼損低減方法の一態様は、通常動作を実施する第１サーバと、待機用の第２サーバと、を備えるサーバ装置が実行する呼損低減方法であって、前記第１サーバは、端末から呼を受信し、受信した呼数が予め設定した最大処理呼数を超えると、リソースの状態を管理・監視し、前記リソース状態が予め設定した閾値を超えるリソース使用率上昇状態を検出し、前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数を超える場合には、前記第２サーバを稼動させるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示し、前記第２サーバは、前記端末から呼を受信して処理する。
【００１１】
さらに、本発明に係る通信システムの一態様は、通常動作において稼動する第１サーバと、待機用の第２サーバとを有するサーバ装置と、端末とを備える通信システムであって、前記第１サーバは、リソース使用率を取得し、前記リソース使用率が予め設定した閾値以上であるリソース使用率上昇状態を検出する第１リソース監視部と、前記端末から受信する呼を処理し、前記リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数以上である場合には、前記第２サーバを待機状態から稼動状態へ切り替えさせるとともに、前記端末に対して前記第２サーバへ呼を送信するように指示する第１呼処理部と、を備え、前記第２サーバは、前記端末から受信する呼を処理する第２呼処理部を備え、前記端末は、前記第１サーバからの指示を受けると、呼を前記第２サーバへ送信する。
【発明の効果】
【００１２】
本発明の実施形態の一態様によれば、サーバ装置で処理能力を超えた後に呼を受信した場合、処理能力を上げて呼損の量を低減することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態１に係るサーバ装置を用いるシステム構成例を示す図である。
【図２】通常の稼動状態において、実行系ＶｏＩＰサーバが処理能力を超えて呼を受信した時の処理例を示す図である。
【図３】待機系ＶｏＩＰサーバを稼動状態にした時の処理例を説明する図である。
【図４】待機系ＶｏＩＰサーバを稼動状態にした後に処理能力以上の呼を受信した時の動作例を示す図である。
【図５】待機系ＶｏＩＰサーバを稼動状態から待機状態へ切り替えた後の動作例を説明する図である。
【図６Ａ】実施形態１のサーバ装置の構成例を示すブロック図である。
【図６Ｂ】実施形態１のＶｏＩＰサーバの構成例を示すブロック図である。
【図７】リソース使用率の変化の一例を示す図である。
【図８】待機系ＶｏＩＰサーバを稼動状態に切り替える動作例（両系稼動機能）を示すフローチャートである。
【図９】リソースフラグを設定する動作例（リソースフラグ機能）を示すフローチャートである。
【図１０】実施形態１の効果を説明する図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態について、図面を参照しながら説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。各図面において同一の構成または機能を有する構成要素および相当部分には、同一の符号を付し、その説明は省略する。
【００１５】
実施形態１．
本発明の一態様では、一定以上のトラフィックを受信した場合、ＡＣＴ系（実行系）及びＳＢＹ系(待機系)のサーバからなるクラスタ構成で運用中のサーバを両系ＡＣＴ系の状態にする仕組みを導入する。これによって、突発的に発生するトラフィック急上昇による呼損をできるだけ回避する。
まず、本発明の実施形態１の概要説明のため、図１乃至図５を参照して説明する。図１は実施形態１のサーバ装置のクラスタ構成と、サーバ装置を搭載するシステム構成例を示したものである。図２はサーバ装置の通常時の動作である。図３から図５はクラスタ構成が両系ＡＣＴ系になることによって、処理能力を向上させる流れを示したものである。図１から図５の構成は同じである。
【００１６】
図１を参照して、本発明の実施形態１のサーバ装置及びサーバ装置を用いるシステム構成を説明する。図１に示す通信システム（ＶｏＩＰ通信システム）は、サーバ装置（ＶｏＩＰサーバ）１０と、ＩＰ端末５０Ａ、５０Ｂと、ＩＰネットワーク６０とを備える構成例を示す。ＩＰ端末５０Ａ、５０Ｂは一例を示したものであり、２以上のＩＰ端末を備えていてもよい。
サーバ装置１０は、ＡＣＴ系ＶｏＩＰサーバ１０ＡとＳＢＹ系ＶｏＩＰサーバ１０Ｂとで構成される。サーバ装置１０はＩＰ端末５０Ａ、５０Ｂを収容している。また、サーバ装置１０は、ＩＰネットワーク６０と接続し、ＩＰネットワーク６０を介してＩＰ端末５０Ａ、５０Ｂから呼を受信する構成例を示している。
ＶｏＩＰサーバ１０Ａ、１０Ｂについて、図１から図５では、リソース使用率を示している。加えて、ＶｏＩＰサーバ１０Ａ、１０Ｂは、リソース使用率の閾値（リソース使用閾値）が予め設定され、設定された閾値を保持する。リソース使用率と設定した閾値との比較によって、両系稼動をさせるための判断を実施する。
さらに、ＶｏＩＰサーバ１０Ａ、１０Ｂは、ＩＰ端末５０Ａ、５０Ｂから受信した呼数（受信呼数）と、各サーバにおいて処理可能な呼数（最大処理呼数）とを保持する。最大処理呼数は、予め設定された値であり、最大受信呼数ともいう。図１では、受信呼／最大として、受信呼数と最大処理個数とを示している。
【００１７】
図２はクラスタ構成の通常の稼動状態で、ＶｏＩＰサーバ１０Ａが処理能力を超えて呼を受信した時のサーバ装置１０の動作を示したものである。図２でＡＣＴ系ＶｏＩＰサーバ１０Ａが最大受信呼を超えて、処理能力超えた呼を受信しようとしているとする。また、ＩＰ端末５０Ａからの呼を処理能力内の呼、ＩＰ端末５０Ｂからの呼を、処理能力を超えた呼とする。ＩＰ端末５０ＡはＶｏＩＰサーバ１０Ａに呼を発信し、ＶｏＩＰサーバ１０Ａは呼処理を実施する。しかし、その後のＩＰ端末５０Ｂからの呼は最大数を超えているため処理することができない。このように通常の稼動状態では、ＡＣＴ系ＶｏＩＰサーバ１０Ａが処理能力を超えた呼を受信した場合、受信呼を呼損にしている。ここで、「通常の稼動状態」とは、一方のＶｏＩＰサーバが稼動状態であり、他方のＶｏＩＰサーバが待機状態である場合、ここでは、ＳＢＹ系ＶｏＩＰサーバ１０Ｂが待機状態である場合をいう。
【００１８】
図３、図４、図５を参照して本実施形態を適用した場合の処理について説明する。
図３において、ＳＢＹ系ＶｏＩＰサーバ１０ＢをＡＣＴ系に切り替えた時の処理について説明する。両系稼動する際は、リソース使用率を確認してから、両系稼動機能の判断を実施する。監視対象とするリソースは、ソフトウェアやハードウェアを動作させるのに必要なＣＰＵ（Central Processing Unit）、メモリ、ハードディスク等とする。これらのリソースの使用率を算出してリソース使用率を取得する。リソース使用率の算出方法については、サーバ装置１０の管理者によって決める設計事項であるため、ここでは説明を省略する。
【００１９】
まず、ＶｏＩＰサーバ１０Ａでは、リソース監視にてリソース使用率が急上昇したことを確認する。リソース使用率の急上昇の判定はリソースフラグのｕｐ／ｄｏｗｎ（初期値ｄｏｗｎ）で確認する。例えば、リソースフラグは、ｕｐすると、"１"を保持し、ｄｏｗｎすると、"０"（ゼロ）を保持するように設定される。設定したリソース使用率の閾値とリソース使用率とを比較して、リソース使用率が閾値以上であればフラグをｕｐに設定し、閾値より低ければフラグをｄｏｗｎしたままとする。このフラグのｕｐ／ｄｏｗｎをトリガーにＶｏＩＰサーバを両系稼動の判定処理を次に実施する。両系稼動判定は、受信呼数と最大処理呼数とを比較して、受信呼数が最大処理呼数より多ければ、ＶｏＩＰサーバ１０ＢをＡＣＴ系にするよう信号送信する。信号受信後ＶｏＩＰサーバ１０ＢはＡＣＴ系に切り替わり、両系稼動状態となる。例えば、ＶｏＩＰサーバ１０Ａは、稼動状態へ移行するのか、待機状態へ移行するのかを指示する切り替え信号をＶｏＩＰサーバ１０Ｂヘ送信する。ＶｏＩＰサーバ１０Ｂは、切り替え信号を受信すると、指示に応じて稼動状態を切り替える。
【００２０】
図４は、両系稼動後、処理能力以上の呼を受信した時の様子を示している。ＡＣＴ系ＶｏＩＰサーバ１０Ａは処理能力範囲内のＩＰ端末５０Ａからの呼を処理する。次に、ＩＰ端末５０Ｂから呼を受信すると処理能力以上の呼を受信したことになるため、ＶｏＩＰサーバ１０Ａはリソース状態を確認し、リソースフラグをｕｐする。また、受信呼数と最大処理呼数を確認して、受信呼が最大処理呼数を超えているため、両系稼動をさせる。両系稼動後、ＶｏＩＰサーバ１０ＡはＩＰ端末５０Ｂに対して、ＶｏＩＰサーバ１０Ｂに呼を迂回するように指示する。ＶｏＩＰサーバ１０Ａから迂回指示の信号を受信したＩＰ端末５０ＢはＶｏＩＰサーバ１０Ｂに呼を送信して呼処理が実行される。ＶｏＩＰサーバ１０Ａの状態は、フラグｕｐ、最大処理呼数を受信し、ＶｏＩＰサーバ１０Ｂと処理を分担したため、リソース使用率が片系稼動状態の時よりも減っている。未使用だったＶｏＩＰサーバ１０Ｂはリソース使用率が上がり、許容内の呼を受信している状態に変化する。
【００２１】
図５は、ＶｏＩＰサーバ１０ＢがＳＢＹ系へ切り戻った後の処理について示している。ＶｏＩＰサーバ１０Ａにて、リソース使用率が落ち着き、リソースフラグがｄｏｗｎすると、ＶｏＩＰサーバ１０ＡはＶｏＩＰサーバ１０Ｂに対して系の切り替えを実施するよう信号を送信する。ＶｏＩＰサーバ１０Ｂは、ＶｏＩＰサーバ１０Ａから切り替えの信号を受信すると、ＡＣＴ系からＳＢＹ系に切り替わる。ＶｏＩＰサーバ１０Ｂが通常のＳＢＹ系に切戻った時のＶｏＩＰサーバ１０Ａの状態は、リソースフラグがｄｏｗｎ、受信呼数が許容範囲内である。両系稼動時に、ＩＰ端末５０Ｂの呼処理を実施していた、ＶｏＩＰサーバ１０ＢはＳＢＹ系に切り替わっているため、ＩＰ端末５０Ｂからの呼を受け付けなくなる。そのため、ＩＰ端末５０Ｂは通常動作に戻り、呼を送信する際はＶｏＩＰサーバ１０Ａに呼を送信するようになる。
【００２２】
上述した図３、図４、図５の方法によりＶｏＩＰサーバ１０Ａが処理能力以上の呼を受信した時、ＳＢＹ系のＶｏＩＰサーバ１０ＢをＡＣＴ系として稼動させ、両系稼動による呼処理を実施することができる。言い換えると、同等の処理能力を持ったＳＢＹ系ＶｏＩＰサーバを一時的にＡＣＴ系の状態にし、処理能力を向上させることができる。この手法を利用することで、ＶｏＩＰサーバ１０Ａに処理能力以上の呼が集中した時、呼損量を少なすることができる。これにより、クラスタ構成で運用中のサーバが、処理能力以上の呼を受信した際に、大量の呼損を発生させてしまうという問題を解決することを可能にする。
【００２３】
以下、上述した通信システムを実現するサーバ装置の構成について図面を参照して説明する。
まず図６Ａ、図６Ｂ、図７について説明する。
図６Ａは、実施形態１のサーバ装置の構成例を示すブロック図である。サーバ装置１００は、第１サーバ１１０と第２サーバ１３０とを備える。第１サーバ１１０は、通常の稼動状態で呼処理を実行する実行系サーバである。第２サーバ１３０は、通常の稼動状態では待機する待機系サーバである。図６Ａでは、以降の説明を容易にするため、端末２００を示している。サーバ装置１００は、端末２００から送信される呼を、ネットワークを介して受信する。なお、図６Ａでは、ネットワークの記載を省略している。
【００２４】
第１サーバ１１０は、第１リソース監視部１１１と第１呼処理部１１２とを備える。
第１リソース監視部１１１は、リソース使用率を取得し、リソース使用率が予め設定した閾値以上であるリソース使用率上昇状態を検出する。リソース使用率上昇状態は、例えば、上述したリソースフラグを用いて示すことができる。第１リソース監視部１１１は、リソース使用率上昇状態を検出すると、リソースフラグをｕｐし、リソース使用率上昇状態が解消されると、リソースフラグをｄｏｗｎする。
第１呼処理部１１２は、端末２００から受信する呼を処理する。加えて、第１呼処理部１１２は、リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数以上である場合には、第２サーバ１３０を稼動させるとともに、端末２００に対して第２サーバ１３０へ呼を送信するように指示する。
第２サーバ１３０は、第２呼処理部１３１を備える。第２呼処理部１３１は、端末２００から受信する呼を処理する。
【００２５】
なお、図６Ａのサーバ装置１００において、第２サーバ１３０は、少なくとも呼処理を実行できる機能を有する場合を示しているが、第１サーバ１１０と同じ構成を有する場合であってもよい。
加えて、図１乃至図５では、サーバ装置をＶｏＩＰサーバから構成される例を示したが、他の通信方式を用いる場合であっても、クラスタ構成のサーバ装置である場合には図６Ａに示す本実施形態のサーバ装置の機能（両系稼動機能）を適用することができる。
【００２６】
次に、図６Ａに示すサーバ装置１００の構成例を図１乃至図５に示すサーバ装置１０へ適用する場合を示す。
図６Ｂは、ＡＣＴ系ＶｏＩＰサーバの機能部について示したものである。図６Ｂは、図６Ａのサーバ装置１００の第１サーバ１１０の構成例を、ＶｏＩＰサーバ１０Ａに適用する構成例を示す。ＶｏＩＰサーバ１０Ａは、リソース監視部２０と呼処理部３０とを備える。リソース監視部２０はリソースの状態を管理・監視する機能部であり、図６Ａの第１リソース監視部１１１に相当する。呼処理部３０は、呼処理と、両系稼動を実現する機能部であり、図６Ａの第１呼処理部１１２に相当する。
リソース監視部２０は、リソース監視処理部２１とリソースフラグ部２２とを有する。
リソース監視処理部２１は、リソースの使用率とリソースの状態を監視してトラフィック情報を収集する。リソース監視処理部２１は、主にＣＰＵ、メモリ、ハードディスクの使用量を管理・監視の対象とする。
【００２７】
リソースフラグ部２２は、リソースフラグを保持し、ＶｏＩＰサーバ１０Ａが処理能力以上の呼を受信し、リソース監視処理部２１で収集されたリソース使用率が閾値以上になった場合、リソースフラグをｕｐする。リソースフラグは通常ｄｏｗｎである。
具体的には、リソースフラグ部２２は、閾値として、第１閾値（フラグｕｐ閾値）と、第１閾値より低い値の第２閾値（フラグｄｏｗｎ閾値）とを保持する。そして、リソースフラグ部２２は、リソース監視処理部２１が取得したリソース使用率が、第１閾値以上である場合に、リソースフラグをｕｐしてリソース使用率上昇状態に設定する。リソース使用率上昇状態に設定した後、リソース使用率が第２閾値より低くなると、リソースフラグをｄｏｗｎしてリソース使用率上昇状態を解除する。
閾値は管理者４０によって設定されるものとする。両系稼動を実施する際、ＶｏＩＰサーバ１０Ａは、リソースフラグ状態のフラグｄｏｗｎからフラグｕｐへの変化をトリガーにＳＢＹ系ＶｏＩＰサーバ１０ＢをＡＣＴ系に切り替える処理を実施し、リソースフラグ状態のフラグｕｐからフラグｄｏｗｎへの変化をトリガーにＳＢＹ系に切り戻す処理を実施する。
【００２８】
呼処理部３０は、呼処理機能部３１と両系稼動部３２とを有する。
呼処理機能部３１は、ＩＰ端末５０Ａからの呼Ａにより接続要求を受けて呼の処理を実施する機能部である。
両系稼動部３２は、ＡＣＴ系とＳＢＹ系との両系ＶｏＩＰサーバを稼動させる機能部である。具体的には、両系稼動部３２は、ＡＣＴ系ＶｏＩＰサーバ１０Ａの受信呼数が最大処理呼数以上であると、リソース使用率を取得する動作（言い換えると、リソース使用率上昇状態を検出する動作）をリソース監視部２０に指示する。そして、リソース使用率上昇状態であり、かつ、受信呼数が最大処理呼数を超える場合には、ＳＢＹ系ＶｏＩＰサーバ１０Ｂを待機状態から稼動状態へ切り替えるように制御するとともに、端末５０Ａに対してＶｏＩＰサーバ１０Ｂへ呼を送信するように指示する。さらに、ＶｏＩＰサーバ１０Ｂの稼動中（リソースフラグ状態：ｕｐ）にリソースフラグがｄｏｗｎしてリソース使用率上昇状態が解除されたことを検出すると、ＶｏＩＰサーバ１０Ｂを稼動状態から待機状態へ切り替えるように制御する。
ここで、図６Ｂに示す呼Ａは、ＩＰ端末５０Ａから最大処理呼数を超えた時に受信されるものとする。
【００２９】
図７は時間とリソース使用率の関係をグラフに示したものであり、ＡＣＴ系ＶｏＩＰサーバ１０Ａで実施されるものとする。この中で、フラグｕｐ／ｄｏｗｎする閾値はそれぞれ別の値で、「フラグｕｐ閾値」の方が大きく、ｕｐ／ｄｏｗｎは異なる値の２段階閾値設定とする。図７のタイミング７０Ａはリソースフラグｕｐのポイントを示す。タイミング７０Ａでは、リソース使用率が急上昇し、「フラグｕｐ閾値」に達し、リソースフラグがｕｐに切り替わる。図７のタイミング７０Ｂは、リソースフラグｄｏｗｎのポイントを示す。タイミング７０Ｂでは、リソースフラグがｕｐ中に、リソース使用率が下がり、「フラグｄｏｗｎ閾値」に達し、リソースフラグがｄｏｗｎに切り替わる。フラグｕｐ／ｄｏｗｎする閾値を２段階に分けているのは、例えば期間７０Ｃの部分でＣＰＵ使用率の変動が閾値付近で激しくなった時、フラグｕｐ／ｄｏｗｎもそれに合わせて動くことを避け、余計な負荷を少なくするためである。
タイミング７０Ａからタイミング７０Ｂの期間は、リソースフラグがｕｐであり、リソース使用率上昇状態となる。
【００３０】
ＳＢＹ系ＶｏＩＰサーバがＡＣＴ系へ切り替わるときには、リソースフラグ部２２と両系稼動部３２とが利用される。ＡＣＴ系ＶｏＩＰサーバ１０Ａで処理能力以上の呼を受信した場合、２つの機能を利用することによって解決できる手段について図６Ｂ、図７を利用して説明する。
処理能力以上の呼を受信すると、図６ＢのＡＣＴ系ＶｏＩＰサーバ１０Ａにおいて、リソース監視処理部２１で収集されるリソース使用率をリソースフラグ部２２が取得する。
リソースフラグ部２２は、リソース使用率が「フラグｕｐ閾値」以上か否かを判定し、リソース使用率が「フラグｕｐ閾値」達していれば、リソースフラグをｕｐにする。これは、図７のタイミング７０Ａにあたる。
【００３１】
次に、両系稼動部３２は、受信呼数と最大処理呼数とを比較して、受信呼数が最大処理呼数以上（受信呼数≧最大処理呼数）であることを確認すると、ＡＣＴ系ＶｏＩＰサーバ１０ＡはＳＢＹ系ＶｏＩＰサーバ１０ＢにＡＣＴ系に切り替わるように信号を送信する。ここで両系稼動になると、次に両系稼動部３２は、ＩＰ端末５０ＡにＡＣＴ系に切り替わったＳＢＹ系ＶｏＩＰサーバ１０Ｂに呼を迂回するように指示を出す。
呼が収束し、リソース使用率が「フラグｄｏｗｎ閾値」まで下がると、リソースフラグ部２２はリソースフラグをｄｏｗｎに変える。これは図７のタイミング７０Ｂの部分にあたる。リソースフラグがｄｏｗｎに切り替わると、両系稼動部３２は、両系稼動していたＶｏＩＰサーバ１０ＢをＳＢＹ系に切り替わるように信号を送信し、サーバ装置１０を元のクラスタ構成に切戻しする。
【００３２】
次に、本実施形態の動作の説明を図８、図９を用いて説明する。
まず、両系稼動機能の動作を説明する。図８に両系稼動機能時の動作例のフローチャートを示す。両系稼動機能は、受信呼数が設定した閾値以上の場合、ＳＢＹ系をＡＣＴ系にし、両系稼動させることで処理能力向上を図る機能である。
両系稼動機能のフローについて説明する。ＡＣＴ系ＶｏＩＰサーバは収容するＩＰ端末からの着信を契機に両系稼動機能（Ｓ１００〜Ｓ１１０）を動作させる。具体的には、ＡＣＴ系ＶｏＩＰサーバ１０Ａは、収容する端末（例えば、端末５０Ａ、５０Ｂ）から処理能力以上の呼を受信すると、両系稼動機能を開始する（Ｓ１００）。両系稼動部３２は、まず対向のＳＢＹ系ＶｏＩＰサーバ１０Ｂが正常に動作しているか確認するため起動状態を確認し（Ｓ１０１）、正常でなければ処理を終了する（Ｓ１０２）。そして、正常な場合、両系稼動部３２は、呼処理機能部３１の呼処理機能でＶｏＩＰサーバ１０Ａが受信した呼数を確認する（Ｓ１０３）。次に、両系稼動部３２は、リソースフラグ部２２のリソースフラグ状態の初期化（ｄｏｗｎ）を実施し（Ｓ１０４）、リソースフラグ機能をリソース監視部２０によって実行させる（Ｓ１０５）。リソースフラグ機能の実施に関しては、図９を参照して後述する。
【００３３】
リソースフラグ機能が実行されると、両系稼動部３２は、リソースフラグ状態を確認する（Ｓ１０６）。リソースフラグとは、その状態により、両系稼動の動作を実施するかを判断するトリガーとなるものである。両系稼動部３２は、リソースフラグがｕｐ（リソース使用率上昇状態）の時には、両系稼動の判定動作を実施し、リソースフラグがｄｏｗｎしている時には、両系稼動の判定動作を実施しない。
両系稼動の判定動作を実施する場合（Ｓ１０６、フラグｕｐ）、両系稼動部３２は、両系稼動させる判断をするため、まず受信呼数と最大処理呼数の比較をする（Ｓ１０７）。受信呼数が最大処理呼数以上である時（Ｓ１０７、受信呼数≧最大処理呼数）、両系稼動部３２は、ＳＢＹ系ＶｏＩＰサーバ１０ＢをＡＣＴ系に切替えるための信号をＳＢＹ系ＶｏＩＰサーバ１０Ｂに送信する（Ｓ１０８）。合わせて、両系稼動部３２は、呼を送信してきたＩＰ端末に対してＡＣＴ系に切り替わったＳＢＹ系ＶｏＩＰサーバの方へ呼を迂回するように指示して（Ｓ１０９）、両系稼動機能を終了する（Ｓ１１０）。
【００３４】
次に、リソースフラグ機能の動作を説明する。図９にリソースフラグ機能のフローチャートを示す。リソースフラグ機能はリソース使用率に応じてフラグをｕｐ／ｄｏｗｎさせるための機能である。また、リソースフラグは、ｕｐ／ｄｏｗｎによって両系稼動をさせるかのトリガーとなるものである。
初めに、両系稼動部３２によってリソースフラグ機能の実施を指示されると（Ｓ２００）、リソース監視処理部２１は、リソース使用率の情報を収集する（Ｓ２０１）。次に、リソース監視処理部２１が収集したリソース使用率がリソースフラグ部２２へ通知されると、リソースフラグ部２２は、リソース使用率と設定した閾値とを比較する（Ｓ２０２）。閾値は、「フラグｕｐ閾値」と「フラグｄｏｗｎ閾値」の二段階で設定し、「フラグｕｐ閾値」＞「フラグｄｏｗｎ閾値」とする。
リソース使用率がフラグｕｐ閾値以上（リソース使用率≧「フラグｕｐ閾値」）に達した時（Ｓ２０２、ＹＥＳ）、リソースフラグ部２２は、リソースフラグをｕｐする（Ｓ２０３）。
【００３５】
一方、リソース使用率がフラグｕｐ閾値より低い（リソース使用率＜「フラグｕｐ閾値」）時（Ｓ２０２、ＮＯ）、リソースフラグ部２２は、リソースフラグ状態がｕｐであり、かつ、リソース使用率がフラグｄｏｗｎ閾値より低い（リソース使用率≦「フラグｄｏｗｎ閾値」）にリソース使用率が下がった時（Ｓ２０４、ＹＥＳ）、リソースフラグ部２２は、フラグをｄｏｗｎし（Ｓ２０５）、リソースフラグ状態を両系稼動部３２へ通知する。両系稼動部３２は、リソースフラグ状態がｄｏｗｎになったことを検出すると、ＶｏＩＰサーバ１０ＢをＡＣＴ系からＳＢＹ系に切戻しをさせる（Ｓ２０６）。
それ以外の時は（Ｓ２０４、ＮＯ）、閾値の上下でリソース使用率が激しく変動している可能性があるため、リソースフラグ部２２は、その時のフラグ状態を維持する（Ｓ２０７）。フラグ状態の判定と変更をしたら、リソースフラグ部２２は、処理を終了する（Ｓ２０８）。
【００３６】
なお、図９では、ステップＳ２０４でリソースフラグ状態を確認しているが、このステップを実施しないで削除し、ステップＳ２０２でＮＯの場合、必ずステップＳ２０５を実施するようにしてもよい。
加えて、ステップ２０６において、両系稼動部３２は、ＶｏＩＰサーバ１０Ｂへ呼を送信するように指示したＩＰ端末に対して、ＶｏＩＰサーバ１０Ａへ送信するように指示する通知（信号）を送信してもよい。
ＩＰ端末は、両系稼動部３２から送信先を指示する通知を受信すると、次の呼の送信から指示されたＶｏＩＰサーバへ呼を送信するように構成されている。あるいは、通知を受け取らない場合には、ＩＰ端末は一方のＶｏＩＰサーバへ送信した呼が処理されないことを検出すると、他方のＶｏＩＰサーバへ呼を送信するように構成されている。
【００３７】
続いて、サーバ装置１０において、両系稼動機能を適用前及び適用後の動作の相違を説明する。図１０の左側の構成は、両系稼動機能を実行する前の状態であり、ＶｏＩＰサーバ１０Ａの受信呼数が最大処理呼数（１００個）以上の状況を示す。図１０の右の構成は、両系稼動機能を実行した後の状態であり、ＶｏＩＰサーバ１０Ａの受信呼数が最大処理呼数であり、ＶｏＩＰサーバ１０Ｂが呼を受信している状況を示す。
両系稼動機能適用前のクラスタ構成で動作している場合と、両系稼動機能適用後の両系稼動構成で動作している場合との全体図を図１０に示す。
両系稼動機能適用前では、サーバ装置１０はＡＣＴ系ＶｏＩＰサーバ１０ＡとＳＢＹ系ＶｏＩＰサーバ１０Ｂで構成され、ＩＰ端末５０Ａと５０Ｂを収容している。ＡＣＴ系ＶｏＩＰサーバ１０Ａが最大呼数量を超えて呼を受信してしまうと、呼損として扱うが、ＳＢＹ系ＶｏＩＰサーバ１０Ｂは障害発生時用のサーバとして待機している状態である。
【００３８】
一方、両系稼動機能適用後では、処理能力以上の呼を受信して両系稼動になった時のＶｏＩＰサーバ１０Ａ、１０Ｂを示している。サーバ装置１０はＡＣＴ系ＶｏＩＰサーバ１０ＡとＳＢＹ系ＶｏＩＰサーバ１０Ｂで構成され、ＩＰ端末５０Ａ、５０Ｂを収容している。ＡＣＴ系ＶｏＩＰサーバ１０Ａが最大呼数量を超えて呼を受信すると、ＡＣＴ系ＶｏＩＰサーバ１０ＡがＳＢＹ系ＶｏＩＰサーバ１０ＢにＡＣＴ系になるように指示し、両系稼動の状態となる。これにより、呼損しかけた呼の呼処理を実施することができる。
両系稼動機能適用前でリソースフラグｄｏｗｎのＡＣＴ系ＶｏＩＰサーバ１０Ａに最大処理呼数を超えてから受信した呼は処理されず、呼処理の結果がＮＧとなっているが、両系稼動機能適用後はフラグｕｐになり、最大処理呼数を超えた分の呼をＡＣＴ系になったＳＢＹ系ＶｏＩＰサーバ１０Ｂが処理するため、呼処理の結果がＯＫとなっている。
本実施形態の構成にすることにより、ＳＢＹ系ＶｏＩＰサーバ１０Ｂを一時的にＡＣＴ系の状態にすることができるため、呼損の量を低減することができる。
【００３９】
本実施形態の効果について図１０を用いて説明する。図１０の左側の構成（両系稼動機能適用前）は、本実施形態の機能を搭載していない従来技術と同様の動作を示す。図１０の両系稼動機能適用前では、ＡＣＴ系ＶｏＩＰサーバに最大処理呼数を超えて、ＩＰ端末５０Ｂから呼が着信すると呼を受けることができない。一方、本実施形態を適用した場合として図１０の両系稼動機能適用後を見ると、最大処理呼数を超えた時、ＳＢＹ系ＶｏＩＰサーバがＡＣＴ系となり両系稼動の状態となる。これにより、受信できなかったＩＰ端末５０Ｂからの呼をＶｏＩＰサーバ１０Ｂで処理することが可能となる。
両系稼動機能適用前では、突発的なトラフィック急上昇時に、サーバの輻輳によって、呼に規制がかかるため、呼損を発生させていた。しかし、両系稼動機能を適用することにより、両系稼動により両系で呼処理を分担させることで、呼損を少なくすることができる。また、両系稼動させているため、処理能力を倍の状態に向上させることができる。
【００４０】
加えて、本実施形態では、新装置を設置することなく、ＳＢＹ系サーバをトラフィック急上昇などの緊急時において有効に活用し、サーバのトラフィック処理能力を上げる事で呼損を低減させることが可能である。
さらに、リソース使用率を２段階に設定した閾値を用いて、リソース使用率が上昇中であるか否かを判定するため、閾値付近でリソース使用率が上昇と下降を繰り返す場合であっても、両系を稼動させることが可能になる。これにより、ＶｏＩＰサーバ１０Ｂの切り替え回数を低減することができる。その結果、サーバ装置１０は、呼損の量を低減し、処理能力を高く維持するとともに、安定した動作を実現することも可能になる。
【００４１】
なお、本発明は上記に示す実施形態に限定されるものではない。本発明の範囲において、上記実施形態の各要素を、当業者であれば容易に考えうる内容に変更、追加、変換することが可能である。
【符号の説明】
【００４２】
１０  サーバ装置
１０Ａ、１０Ｂ  ＶｏＩＰサーバ
２０  リソース監視部
２１  リソース監視処理部
２２  リソースフラグ部
３０  呼処理部
３１  呼処理機能部
３２  両系稼動部
５０Ａ、５０Ｂ  ＩＰ端末
６０  ＩＰネットワーク
【図１】
0005915297.tif 000002
【図２】
0005915297.tif 000003
【図３】
0005915297.tif 000004
【図４】
0005915297.tif 000005
【図５】
0005915297.tif 000006
【図６Ａ】
0005915297.tif 000007
【図６Ｂ】
0005915297.tif 000008
【図７】
0005915297.tif 000009
【図８】
0005915297.tif 000010
【図９】
0005915297.tif 000011
【図１０】
0005915297.tif 000012