(57)【特許請求の範囲】
【請求項１】
視聴端末に映像コンテンツの配信サービスをおこなうストリーミングサーバと、前記ストリーミングサーバがフェイルオーバーするバックアップサーバと、を含む複数のサーバがクラスタリングされたストリーミングサーバクラスタであって、
前記ストリーミングサーバの障害時に前記バックアップサーバにフェイルオーバーを行うクラスタ制御部を有し、
前記ストリーミングサーバは、
前記映像コンテンツの配信サービスの配信状況および配信に必要な情報を示すセッション状態とストリーミング状況を示すメディア状態の情報を保持する状態記憶部と、
前記視聴端末にストリーミングを行うとともに、前記視聴端末からストリーミング制御メッセージを受けた時に、前記セッション状態の情報をフェイルオーバー時のサービス継続情報として前記バックアップサーバに通知して前記バックアップサーバと同期するストリーミング部と、を備え、
前記バックアップサーバは、
前記ストリーミングサーバからフェイルオーバー時のサービス継続情報として通知された前記セッション状態の情報を記憶する状態バックアップ記憶部と、
前記クラスタ制御部によるフェイルオーバー時に、前記ストリーミングサーバから通知された前記セッション状態の情報を基に求めたストリーミング状況を示すメディア状態に従って、前記視聴端末へのストリーミングを継続するストリーミングバックアップ部と、
を備える
ことを特徴とするストリーミングサーバクラスタ。
【請求項２】
請求項１に記載のストリーミングサーバクラスタにおいて、
前記ストリーミングサーバの状態記憶部に保持され、前記ストリーミングサーバから前記バックアップサーバに通知されるセッション状態には、前記視聴端末のＩＰアドレスとポート番号と、ストリーミングサーバが前記視聴端末から再生開始メッセージを受信してストリームを開始した時刻を示すストリーム開始時刻と、ストリーミングサーバがストリーミング開始したコンテンツの時刻位置を示すストリーム開始位置と、が含まれ、
前記バックアップサーバのストリーミングバックアップ部は、
前記状態バックアップ記憶部の前記セッション状態の情報に基づいて、前記ストリーム開始位置に、フェイルオーバー処理時刻と前記ストリーム開始時刻の差分を加算して継続するストリーミングの再生位置を求めてメディア状態を更新する
ことを特徴とするストリーミングサーバクラスタ。
【請求項３】
請求項１に記載のストリーミングサーバクラスタにおいて、
前記ストリーミングサーバの状態記憶部に保持され、前記ストリーミングサーバから前記バックアップサーバに通知されるセッション状態には、前記視聴端末のＩＰアドレスとポート番号と、前記視聴端末から再生開始メッセージを受信してストリームを開始したときの映像パケットのシーケンス番号を示すストリーム開始シーケンス番号と、が含まれ、
前記バックアップサーバの状態バックアップ記憶部は、フェイルオーバー時に継続するストリームのストリーミング状況を示すメディア状態を含み、
前記ストリーミングバックアップ部は、前記状態バックアップ記憶部の前記セッション状態の情報の前記ストリーム開始シーケンス番号を基に、前記視聴端末へのストリーミングを行わない擬似ストリーミング処理をおこない、ストリームの映像パケットのシーケンス番号を求めて前記メディア状態を更新する
ことを特徴とするストリーミングサーバクラスタ。
【請求項４】
請求項１に記載のストリーミングサーバクラスタにおいて、
前記バックアップサーバは、第１のバックアップサーバと第２のバックアップサーバとから成り、
前記ストリーミングサーバは、第１の映像ストリーミングを行う第1のストリーミング部と第２の映像ストリーミングを行う第２のストリーミング部を有し、
前記第１の映像ストリーミングに関する第１のセッション状態の情報を第１のバックアップサーバに通知し、前記第２の映像ストリーミングに関する第２のセッション状態の情報を第２のバックアップサーバに通知し、
前記第１のバックアップサーバは、フェイルオーバー時に、前記ストリーミングサーバから通知された前記第１のセッション状態の情報を基に求めたメディア状態に従って、前記視聴端末への第1の映像ストリーミングを継続し、
前記第２のバックアップサーバは、前記第１のバックアップサーバと並行して、フェイルオーバー時に、前記ストリーミングサーバから通知された前記第２のセッション状態の情報を基に求めたメディア状態に従って、前記視聴端末への第２の映像ストリーミングを継続する
ことを特徴とするストリーミングサーバクラスタ。
【請求項５】
視聴端末に映像コンテンツの配信サービスをおこなうストリーミングサーバと、前記ストリーミングサーバがフェイルオーバーするバックアップサーバと、前記ストリーミングサーバの障害時に前記バックアップサーバにフェイルオーバーを行うクラスタ制御部と、を含む複数のサーバがクラスタリングされたストリーミングサーバクラスタのストリーミング制御方法であって、
前記ストリーミングサーバが、前記の映像コンテンツの配信サービスの配信状況および配信に必要な情報を示すセッション状態とストリーミング状況を示すメディア状態の情報を更新するステップと、
前記ストリーミングサーバが、前記視聴端末からストリーミング制御メッセージを受けた時に、前記セッション状態の情報をフェイルオーバー時のサービス継続情報として前記バックアップサーバに通知して前記バックアップサーバと同期するステップと、
前記バックアップサーバが、前記クラスタ制御部によるフェイルオーバー時に、前記ストリーミングサーバからフェイルオーバー時のサービス継続情報として通知された前記セッション状態の情報を基に求めたメディア状態に従って、前記視聴端末へのストリーミングを継続するステップと、含む
ことを特徴とするストリーミングサーバクラスタのストリーミング制御方法。
【請求項６】
請求項５に記載のストリーミングサーバクラスタのストリーミング制御方法であって、
前記セッション状態はストリームの再生中また停止中を示す配信状況を含み、
前記バックアップサーバが、前記セッション状態の配信状況がストリームの再生中を示す情報のときに、前記セッション状態の情報を基にメディア状態を求める
ことを特徴とするストリーミングサーバクラスタのストリーミング制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散処理機構のクラスタシステム上に実現するストリーミングサーバに関する。
【背景技術】
【０００２】
インターネットの普及とアクセス回線の帯域拡大にともない、オンラインゲームや映像配信サービス等の市場が拡大している。このようなサービスでは、視聴者からの要求に応じてメディアを配信しながら、視聴者の端末で再生することで、視聴環境へのデータの保管を必須としないストリーミング方式を使用することが多い。
【０００３】
このメディアをストリーミング配信するストリーミングサーバを、クラスタ構成として実現する技術がある。このクラスタシステムによれば、大量の配信要求処理が発生しても、クラスタを構成する複数サーバへストリーミング負荷を分散することで、視聴者数の変動に対応した効率的なシステム運用をおこなうことができる。また、クラスタシステムでは、サーバの障害発生時に、他のサーバに処理を引き継ぐこともできるので、ストリーミングサーバの高可用性を実現できる。
【０００４】
詳しくは、クラスタシステムでは、クライアントごとに発生するセッションやトランザクションといった一連の処理単位に各サーバが処理分担する。このとき、サーバがセッション状態などの状態データを保持しながら動作するステートフルサービスでは、初期要求信号を受けて状態データを保持するサーバのみがそのクライアントの継続要求信号を処理可能である。つまり、ステートフルサービスへのクラスタシステムの適用にはクライアントからの要求信号を状態データのあるサーバへ確実に届けることが必要となる。ステートフルサービスへのクラスタシステムの適用例として、サービスを継続したままの動的な構成変更を可能にするクラスタモデルが提案されている（例えば、非特許文献1を参照）。
【０００５】
また、クラスタシステムの中にはクラスタを構成するサーバ同士が互いの状態データのバックアップを持ち合い常に同期することで、サーバ障害時にバックアップデータを持つサーバが処理を引き継いでサービスを継続するものがある（例えば、非特許文献２を参照）。
以上の先行技術を用いることで、クラスタシステムのサーバ台数の増減と、サーバ故障時の処理の引継ぎをサービス無中断で行うことが可能となり、システムの運用コストを低く抑えることや、高い可用性を持たせることを実現している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】入江道生他、スケールアウト柔軟な構成変更を実現するセッション制御サーバのクラスタモデル、電子情報通信学会総合大会2011、B-6-11.
【非特許文献２】岩佐絵里子他、高可用サーバクラスタにおける大規模障害を考慮したデータ複製方式の検討、電子情報通信学会総合大会2012、B-6-26.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記のとおり、ステートフルサービスを提供するクラスタシステムでサーバのフェイルオーバーを行う際には、状態データ（セッション情報）に基づいて、現用系サーバから待機系サーバに処理を切り替えて、処理の引き継ぎが行われる。現用系サーバと待機系サーバで、状態データ（セッション情報）を保持する場合には、状態データ（セッション情報）が継続的に同期するようにしている。ところで、この状態データ（セッション情報）の同期頻度が、クラスタシステムのフェイルオーバー時の処理の継続性に影響を与えることがある。
【０００８】
例えば、ＶＯＤ（Video On Demand）サービスを提供するストリーミングサーバでは、状態データ（セッション情報）に配信コンテンツの再生位置が記録され、コンテンツのストリームミングが継続して行われている。フェイルオーバー時に、待機系サーバは、この状態データ（セッション情報）を参照して、処理の引き継ぎを行う。
【０００９】
この状態データ（セッション情報）の同期頻度が低いと、フェイルオーバー時に参照する状態データ（セッション情報）の再生位置の情報は、既に配信したコンテンツの再生位置のため、ストリームの巻き戻しや再生中断が生じてしまう可能性がある。
このため、状態データ（セッション情報）の同期頻度は高いほうが望ましい。
しかし、同期する状態データ（セッション情報）の数は、ストリーミングするセッションの数分だけあり、状態データ（セッション情報）の同期頻度を高めると、サーバ（ノード）間の通信量が増加して、クラスタシステムのスループットが低下する問題がある。
また、クラスタシステムのサーバ（ノード）間を専用また高速なネットワークで接続して、状態データ（セッション情報）の同期負荷を低減する場合には、ネットワークコストが増加する問題がある。
【００１０】
本発明の目的は、上記の課題を解決し、処理負荷が少なく、低ネットワークコストで、動的構成変更が可能なストリーミングサーバのクラスタシステムを提供することにある。
【課題を解決するための手段】
【００１１】
前記課題を解決するため、請求項１に記載の発明は、視聴端末に映像コンテンツの配信サービスをおこなうストリーミングサーバと、前記ストリーミングサーバがフェイルオーバーするバックアップサーバと、を含む複数のサーバがクラスタリングされたストリーミングサーバクラスタであって、前記ストリーミングサーバの障害時に前記バックアップサーバにフェイルオーバーを行うクラスタ制御部を有し、前記ストリーミングサーバは、前記映像コンテンツの配信サービスの配信状況および配信に必要な情報を示すセッション状態とストリーミング状況を示すメディア状態の情報を保持する状態記憶部と、前記視聴端末にストリーミングを行うとともに、前記視聴端末からストリーミング制御メッセージを受けた時に、前記セッション状態の情報をフェイルオーバー時のサービス継続情報として前記バックアップサーバに通知して前記バックアップサーバと同期するストリーミング部と、を備え、前記バックアップサーバは、前記ストリーミングサーバからフェイルオーバー時のサービス継続情報として通知された前記セッション状態の情報を記憶する状態バックアップ記憶部と、前記クラスタ制御部によるフェイルオーバー時に、前記ストリーミングサーバから通知された前記セッション状態の情報を基に求めたストリーミング状況を示すメディア状態に従って、前記視聴端末へのストリーミングを継続するストリーミングバックアップ部と、を備えることを特徴とするストリーミングサーバクラスタとした。
【００１２】
上記のとおり、ストリーミング制御メッセージを受けた時にフェイルオーバー時のサービス継続情報を示すセッション状態を同期するようにしたので、同期頻度を小さくすることができ、サーバ間の通信量が少なくなってストリーミングサーバクラスタのスループットの低下を抑制することができる。
【００１３】
請求項２に記載の発明は、請求項１に記載のストリーミングサーバクラスタにおいて、前記ストリーミングサーバの状態記憶部に保持され、前記ストリーミングサーバから前記バックアップサーバに通知されるセッション状態には、前記視聴端末のＩＰアドレスとポート番号と、ストリーミングサーバが前記視聴端末から再生開始メッセージを受信してストリームを開始した時刻を示すストリーム開始時刻と、ストリーミングサーバがストリーミング開始したコンテンツの時刻位置を示すストリーム開始位置と、が含まれ、前記バックアップサーバのストリーミングバックアップ部は、前記状態バックアップ記憶部の前記セッション状態の情報に基づいて、前記ストリーム開始位置に、フェイルオーバー処理時刻と前記ストリーム開始時刻の差分を加算して継続するストリーミングの再生位置を求めてメディア状態を更新する
ことを特徴とするストリーミングサーバクラスタとした。
【００１４】
これにより、ストリームサーバをフェイルオーバーした際に、メディアがロールバックすることなしに、ストリーミングを継続することができる。
【００１５】
請求項３に記載の発明は、請求項１に記載のストリーミングサーバクラスタにおいて、前記ストリーミングサーバの状態記憶部に保持され、前記ストリーミングサーバから前記バックアップサーバに通知されるセッション状態には、前記視聴端末のＩＰアドレスとポート番号と、前記視聴端末から再生開始メッセージを受信してストリームを開始したときの映像パケットのシーケンス番号を示すストリーム開始シーケンス番号と、が含まれ、前記バックアップサーバの状態バックアップ記憶部は、フェイルオーバー時に継続するストリームのストリーミング状況を示すメディア状態を含み、前記ストリーミングバックアップ部は、前記状態バックアップ記憶部の前記セッション状態の情報の前記ストリーム開始シーケンス番号を基に、前記視聴端末へのストリーミングを行わない擬似ストリーミング処理をおこない、ストリームの映像パケットのシーケンス番号を求めて前記メディア状態を更新することを特徴とするストリーミングサーバクラスタとした。
【００１６】
これによれば、フェイルオーバー時に、ストリームのパケットのシーケンス番号が非連続にならないので、ストリームの連続性を確保できるとともに、フェイルオーバー時に、ストリームを継続するためのメディア情報が生成されているので、引き継ぎ処理時間の短縮を図ることができる。
【００１７】
請求項４に記載の発明は、  請求項１に記載のストリーミングサーバクラスタにおいて、前記バックアップサーバは、第１のバックアップサーバと第２のバックアップサーバとから成り、前記ストリーミングサーバは、第１の映像ストリーミングを行う第1のストリーミング部と第２の映像ストリーミングを行う第２のストリーミング部を有し、前記第１の映像ストリーミングに関する第１のセッション状態の情報を第１のバックアップサーバに通知し、前記第２の映像ストリーミングに関する第２のセッション状態の情報を第２のバックアップサーバに通知し、前記第１のバックアップサーバは、フェイルオーバー時に、前記ストリーミングサーバから通知された前記第１のセッション状態の情報を基に求めたメディア状態に従って、前記視聴端末への第1の映像ストリーミングを継続し、前記第２のバックアップサーバは、前記第１のバックアップサーバと並行して、フェイルオーバー時に、前記ストリーミングサーバから通知された前記第２のセッション状態の情報を基に求めたメディア状態に従って、前記視聴端末への第２の映像ストリーミングを継続することを特徴とするストリーミングサーバクラスタとした。
【００１８】
これにより、アクティブ／アクティブ構成のクラスタシステムで、ストリーミングサーバを構築することができ、さらに、フェイルオーバー処理を並行処理できるので、引き継ぎ処理時間の短縮をおこなえる。
【００１９】
請求項５に記載の発明は、視聴端末に映像コンテンツの配信サービスをおこなうストリーミングサーバと、前記ストリーミングサーバがフェイルオーバーするバックアップサーバと、前記ストリーミングサーバの障害時に前記バックアップサーバにフェイルオーバーを行うクラスタ制御部と、を含む複数のサーバがクラスタリングされたストリーミングサーバクラスタのストリーミング制御方法であって、前記ストリーミングサーバが、前記の映像コンテンツの配信サービスの配信状況および配信に必要な情報を示すセッション状態とストリーミング状況を示すメディア状態の情報を更新するステップと、前記ストリーミングサーバが、前記視聴端末からストリーミング制御メッセージを受けた時に、前記セッション状態の情報をフェイルオーバー時のサービス継続情報として前記バックアップサーバに通知して前記バックアップサーバと同期するステップと、前記バックアップサーバが、前記クラスタ制御部によるフェイルオーバー時に、前記ストリーミングサーバからフェイルオーバー時のサービス継続情報として通知された前記セッション状態の情報を基に求めたメディア状態に従って、前記視聴端末へのストリーミングを継続するステップと、含むことを特徴とするストリーミングサーバクラスタのストリーミング制御方法とした。
【００２０】
これにより、ストリーミング制御メッセージを受けた時にフェイルオーバー時のサービス継続情報を示すセッション状態を同期するようにしたので、同期頻度を小さくすることができ、ストリーミングサーバクラスタのスループットの低下を抑制することができる。
【００２１】
請求項６に記載の発明は、請求項５に記載のストリーミングサーバクラスタのストリーミング制御方法であって、前記セッション状態はストリームの再生中また停止中を示す配信状況を含み、前記バックアップサーバが、前記セッション状態の配信状況がストリームの再生中を示す情報のときに、前記セッション状態の情報を基にメディア状態を求めることを特徴とするストリーミングサーバクラスタのストリーミング制御方法とした。
【００２２】
これにより、ストリーミングサーバとバックアップサーバのメディア状態を同期できるので、フェイルオーバー時のストリームの連続性を確保できる。
【発明の効果】
【００２３】
本発明によれば、サービスの中断が少ない動的構成変更が可能なストリーミングサーバクラスタを低いサーバ負荷とネットワークコストで構築可能である。
【図面の簡単な説明】
【００２４】
【図１】実施例１のストリーミングサーバの構成を示す図である。
【図２】実施例１のセッション状態のデータ構成を説明する図である。
【図３】実施例１のセッション状態の設定制御フローを説明する図である。
【図４】実施例２のストリーミングサーバの構成を示す図である。
【図５】実施例２のセッション状態のデータ構成を説明する図である。
【図６】実施例２のセッション状態の設定制御フローを説明する図である。
【図７】比較例のアクティブ/スタンバイ構成のクラスタシステムを示す図である。
【図８】比較例の状態データのデータ構成を説明する図である。
【発明を実施するための形態】
【００２５】
《比較例》
本発明の実施形態を説明する前に、ＶＯＤサービスをクラスタシステムで実施する一例を図７、図８により説明する。
【００２６】
図７は、複数台の物理サーバがクラスタ構成されたストリーミングサーバクラスタ７０において、ひとつの物理サーバを待機系としたアクティブ/スタンバイ構成のクラスタシステムを示す図である。
具体的には、ストリーミングサーバクラスタ７０は、サーバＡ（７１）とサーバＢ（７２）とサーバＣ（７３）がクラスタリングされ、サーバＢ（７２）がサーバＡ（７１）の待機系として構成されている。また、ストリーミングするメディアは、サーバＡ（７１）、または、図示しないメディアサーバに格納されている。
なお、本明細書では、待機系サーバをバックアップサーバと称することがある。
【００２７】
ストリーミングサーバクラスタ７０には、視聴端末７４と視聴端末７５が接続され、それぞれの端末からのＶＯＤサービスの要求に基づいて、サーバＡ（７１）のストリーム部７６とストリーム部７７により、映像配信１と映像配信２のコンテンツ配信を行っている。
このとき、図示していない視聴端末から、新たなＶＯＤサービスの要求があった時には、図示していないロードバランサーが、サーバＡ（７１）の負荷状態を監視し、サーバＣ（７３）から新たにメディアのストリーミングが行われる。
【００２８】
ＶＯＤサービスでは、ストリーミングサーバは、メディアの再生開始、一時停止、再生再開、再生位置移動、再生終了の視聴者要求に基づいて、ストリーミング制御を行っている。また、これらの配信状況の他に、宛先ＩＰアドレス（Internet Protocol address）などの配信に必要な情報すべてを視聴者（ストリーム）ごとにサービスの状態データ（図８参照）として保持している。
また、ＶＯＤサービスは、ステートフルサービスであり、サーバＡ（７１）でサービスを開始した時には、サーバＡ（７１）のみが、状態データの更新が可能であり、視聴者への配信を継続することができる。
【００２９】
サーバＡ（７１）からサーバＢ（７２）にフェイルオーバーする際には、サーバＢ（７２）はこの状態データに基づいて、視聴者に対する配信処理を引き継ぐ。
具体的には、図７のサーバＡ（７１）には、視聴端末１（７４）へストリーミング配信を行うストリーミング部１（７６）と視聴端末２（７５）へストリーミング配信を行うストリーミング部２（７７）が設けられ、ストリーミング部１（７６）は映像配信１の状態データ１を有し、ストリーミング部２（７７）は映像配信２の状態データ２を保持している。
【００３０】
サーバＡ（７１）とサーバＢ（７２）とサーバＣ（７３）には、それぞれ、サーバを監視し、サーバ障害時に連携してフェイルオーバー処理をおこなうクラスタ制御部（７８a、７８ｂ、７８ｃ）が設けられている。クラスタ制御部（７８a、７８ｂ）は、待機系のサーバＢ（７２）にストリーミング部１（７６）の状態データ１とストリーミング部２（７７）の状態データ２のバックアップを定期的に生成して、引き継ぎ処理に備えている。
フェイルオーバーすると、サーバＢ（７２）のストリーミングバックアップ部１（７９）は、状態データ１に基づいて、ストリーミング部１（７６）のストリーミングを引き継ぎ処理し、ストリーミングバックアップ部２（８０）は、状態データ２に基づいて、ストリーミング部２（７７）のストリーミングを引き継ぐ。
【００３１】
ここで、ストリーミング部１（７６）とストリーミング部２（７７）、ストリーミングバックアップ部１（７９）とストリーミングバックアップ部２（８０）、クラスタ制御部（７８a、７８ｂ、７８ｃ）は、サーバＡ（７１）とサーバＢ（７２）に搭載されるＣＰＵ（Central Processing Unit）のプログラム処理により実現することができる。
【００３２】
ここで、図８により、状態データのデータ構成をより詳細に説明する。
データ構成の配信先ＩＰアドレスは、視聴端末のネットワークアドレスであり、ポート番号は、音声や動画などのデータストリームをリアルタイムに配送するための伝送プロトコルであるＲＴＰ（Real-time Transport Protocol）やＲＴＣＰ（RTP Control Protocol）やＲＴＳＰ（Real Time Streaming Protocol）等の伝送プロトコルに基づいて提供されるＶＯＤサービスを受ける視聴アプリケ―ションの識別番号を示している。
そして、配信状況は、ストリームが再生中（送出中）であるか、停止中であるかを示している。
再生位置は、ストリーミングしているコンテンツの再生位置を時刻表示した情報である（コンテンツの先頭が時刻０）。
【００３３】
ＶＯＤサービスでは、ストリーム再生中では、常に状態データの再生位置が変化している。状態データの待機系サーバへのバックアップする頻度が低い、つまり、状態データの同期頻度が小さいと、フェイルオーバーした際に、ストリームのロールバックが発生する問題がある。
この問題は、フェイルオーバーを制御するクラスタマネージャ（クラスタ制御部）が高頻度に状態データの同期を行うことで解消することができるが、通信量の増加に伴いサーバ負荷が増加し、ストリーミングサーバのスループットが低下する問題が生じる。
【００３４】
そこで、本実施例では、クラスタマネージャ（クラスタ制御部）により定期的に状態データの同期を行うのではなく、ストリーミング状態に変化があったときに、状態データの同期を行うとともに、状態データにストリーミング状態に変化があったときの、ストリームの再生位置と再生時刻またはパケットシーケンス番号を記憶するようにした。なお、実施例では、他との区別のため、待機系サーバと同期をとるための状態データを、セッション状態と称する。
【００３５】
さらに、本実施例の待機系サーバは、上記のセッション状態を参照して、フェイルオーバー時にストリーミングを再開するコンテンツの再生位置を求めて、処理の引き継ぎを行うようにした。
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
【００３６】
《実施例１》
図１は、本実施例のストリーミングサーバクラスタの構成を示す図である。
本実施例のストリーミングサーバクラスタ１０は、複数台の物理サーバがクラスタ構成されたストリーミングサーバにおいて、待機系の物理サーバを設けずにバックアップサーバも分散させるアクティブ／アクティブ構成のクラスタシステムを構成している。
具体的には、ストリーミングサーバクラスタ１０は、サーバＡ（１１）とサーバＢ（１２）とサーバＣ（１３）がクラスタリングされ、サーバＢ（１２）とサーバＣ（１３）に、サーバＡ（１１）で実行されるストリーミングアプリケーションがフェイルオーバーされる。
【００３７】
詳細は後述するが、本実施例によれば、フェイルオーバーする際に参照するセッション状態の同期によるサーバ負荷が少ないので、サーバＢ（１２）とサーバＣ（１３）のスループットを低下させることがない。このため、待機系の物理サーバを設ける必要がないので、高可用性のクラスタシステムを実現できる。
【００３８】
ストリーミングサーバクラスタ１０には、視聴端末１４と視聴端末１５が接続され、それぞれの端末からのＶＯＤサービスの要求に基づいて、サーバＡ（１１）のストリーミング部１（１６）とストリーミング部２（１７）によりメディア配信を行っている。この時、ストリーミングするメディアは、サーバＡ（１１）、または、図示しないメディアサーバに格納されている。
【００３９】
ＶＯＤサービスでは、ストリーミングサーバは、メディアの再生開始、一時停止、再生再開、再生位置移動、再生終了の視聴者要求に基づいて、ストリーミング制御を行っている。また、これらの配信状況の他に、宛先ＩＰアドレスなどの配信に必要な情報すべてを視聴者（サービス）ごとのストリームのセッション状態（図２参照）として保持している。
また、ＶＯＤサービスは、ステートフルサービスであり、サーバＡ（１１）でサービスを開始した時には、サーバＡ（１１）のみが、セッション状態の更新が可能であり、視聴者への配信を継続することができる。このセッション状態の詳細は後述する。
【００４０】
サーバＡ（１１）には、セッション状態の他に、メディア状態を示す情報を保持している。このメディア状態には、先に説明した図８の再生位置の情報と同じ、ストリーミングしているコンテンツの再生位置を時刻表示した情報（コンテンツの先頭が時刻０）を含んでいる。
【００４１】
このように、本実施例では、サーバＡ（１１）のストリーミング部１（１６）とストリーミング部２（１７）の実行状態を、ストリーム制御の動作設定や変更の指示により変わるセッション状態とメディアのスリーム動作により変化するメディア状態に分けて管理するようにした。
そして、セッション状態を、フェイルオーバーの引き継ぎ情報として、バックアップサーバに同期するようにした。
これにより、サーバＡ（１１）からサーバＢ（１２）とサーバＣ（１３）にフェイルオーバーする際に、サーバＢ（１２）とサーバＣ（１３）は、このセッション状態に基づいて、視聴者に対する配信処理を引き継ぐことができる。
【００４２】
具体的には、図１のサーバＡ（１１）は、視聴端末１（１４）へ映像配信１をストリーミングするストリーミング部１（１６）と、視聴端末２（１５）へ映像配信２をストリーミングするストリーミング部２（１７）が設けられ、ストリーミング部１（１６）は、セッション状態１と、視聴端末１（１４）へストリーミングする映像配信１のメディア状態１とを保持し、ストリーミング部２（１７）は、セッション状態２と、視聴端末２（１５）へストリーミングする映像配信２のメディア状態２を保持している。
【００４３】
サーバＡ（１１）とサーバＢ（１２）とサーバＣ（１３）には、それぞれ、サーバを監視し、サーバ障害時に連携してフェイルオーバー処理をおこなうクラスタ制御部（１８a、１８ｂ、１８ｃ）が設けられている。クラスタ制御部（１８a、１８ｂ、１８ｃ）は、待機系のサーバＢ（１２）にストリーミング部１（１６）のセッション状態１のバックアップを定期的に生成し、さらに、待機系のサーバＣ（１３）にストリーミング部２（１７）のセッション状態２のバックアップを定期的に生成し、サーバＡ（１１）のフェイルオーバーによるストリーミングの引き継ぎ処理に備えている。また、これにより、サーバＡ（１１）とサーバＢ（１２）、サーバＣ（１３）の同期が行われる。
【００４４】
フェイルオーバーすると、サーバＢ（１２）のストリーミングバックアップ部１（１９）は、セッション状態１に基づいて、サーバＡ（１１）のストリーミング部１（１６）のストリーミングを引き継ぎ処理し、サーバＣ（１３）のストリーミングバックアップ部２（２０）は、セッション状態２に基づいて、サーバＡ（１１）ストリーミング部２（１７）のストリーミングを引き継ぐ。
ここで、ストリーミング部１（１６）とストリーミング部２（１７）、ストリーミングバックアップ部１（１９）とストリーミングバックアップ部２（２０）、クラスタ制御部（１８a、１８ｂ、１８ｃ）は、サーバＡ（１１）とサーバＢ（１２）とサーバＣ（１３）に搭載されるＣＰＵ（Central Processing Unit）のプログラム処理により実現することができる。
【００４５】
つぎに、図２により、セッション状態のデータ構成をより詳細に説明する。
データ構成の配信先ＩＰアドレスは、視聴端末のネットワークアドレスであり、ポート番号は、ＶＯＤ視聴アプリケーションの識別番号を示している。
そして、配信状況は、ストリームが再生中（送出中）であるか、停止中であるかを示している。
【００４６】
ストリーム開始時刻は、視聴端末のＲＴＳＰによるストリームのＰＬＡＹメッセージ（再生開始要求）やＰＡＵＳＥメッセージ（一時停止要求）等の要求メッセージを受信した時刻を示している。このときの時刻は、ＮＴＰ（Network Time Protocol）サーバ等に同期したサーバＡ（１１）とサーバＢ（１２）、サーバＣ（１３）、視聴端末１（１４）、視聴端末２（１５）に共通の時刻とする。
ストリーム開始位置は、ストリーミングしているコンテンツの再生位置を時刻表示した情報である（コンテンツの先頭が時刻０）。
【００４７】
つぎに、図３により、セッション状態の設定制御フローを説明する。本実施例では、
映像配信１のセッション状態１と、映像配信２のセッション状態２があり、セッション状態１がサーバＢ（１２）に通知され、セッション状態２がサーバＣ（１３）に通知される。図３のフロー図は、ひとつのセッション状態の設定制御フローを示したもので、他方のセッション状態も同様に処理される。
【００４８】
まず、ストリーミング部１（１６）は、視聴端末からＲＴＳＰメッセージを受信したか否かを判定し（Ｓ３０１）、ＲＴＳＰメッセージでなかった場合には（Ｓ３０１のＮｏ）、実施例のセッション状態の設定制御フローを終了する。
【００４９】
ステップＳ３０１で、ストリーミング部１（１６）は、ＲＴＳＰメッセージを受信した場合には（Ｓ３０１のＹｅｓ）、セッション状態に配信先ＩＰアドレスとポート番号を設定する（Ｓ３０２）。
つぎに、受信したＲＴＳＰメッセージが、“再生開始メッセージ”であるか否かを判定し（Ｓ３０３）、“再生開始メッセージ”でなかった場合には（Ｓ３０３のＮｏ）、他のメッセージの判定に進む（Ｓ３０８）。
【００５０】
ステップＳ３０３で、ストリーミング部１（１６）は、“再生開始メッセージ”だった場合には（Ｓ３０３のＹｅｓ）、セッション状態を参照して、メディア配信（ストリーミング）が停止中であるか否かを判定する（Ｓ３０４）。
配信停止中でなければ（Ｓ３０４のＮｏ）、セッション状態のストリーム開始時刻に現在時刻を設定し、セッション状態のストリーム開始位置にストリーミングを開始するコンテンツの再生位置（時刻）を設定する（Ｓ３０６）。新たにストリーミングを開始する場合には、ストリーム開始位置には、０が設定される。
【００５１】
そして、セッション状態の配信状況に、“再生中”を設定し、セッション状態のストリーム開始位置に設定された再生位置（時刻）から、コンテンツのストリーミングを開始する（Ｓ３０７）。
その後、ストリーミング部１（１６）は、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ３１４）、セッション状態の設定制御フローを終了する。
【００５２】
ステップＳ３０４で、ストリーミング部１（１６）は、メディア配信（ストリーミング）が停止中であった場合には（Ｓ３０４のＹｅｓ）、セッション状態のストリーム開始時刻に現在時刻を設定し（Ｓ３０５）、ステップＳ３０７に進む。
このとき、セッション状態のストリーム開始位置には、後述する“一時停止”のＲＴＳＰメッセージを受信した時に、ストリーミングを再開するコンテンツの再生位置（時刻）が設定されている。
ステップＳ３０７では、ストリーミング部１（１６）は、セッション状態の配信状況に、“再生中”を設定し、セッション状態のストリーム開始位置にされた時刻から、コンテンツのストリーミングを開始し、その後、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ３１４）、セッション状態の設定制御フローを終了する。
【００５３】
ステップＳ３０８では、ストリーミング部１（１６）は、受信したＲＴＳＰメッセージが、“一時停止メッセージ”であるか否かを判定し、“一時停止メッセージ”でない場合には（Ｓ３０８のＮｏ）、他のメッセージの判定に進む（Ｓ３１１）。
【００５４】
ステップＳ３０８で、ストリーミング部１（１６）は、受信したＲＴＳＰメッセージが、“一時停止メッセージ”だった場合には（Ｓ３０８のＹｅｓ）、セッション状態の配信状況に“停止中”を設定し、ストリーミングを停止する（Ｓ３０９）。
そして、セッション状態のストリーム開始位置に、ストリーミングを再開する際のコンテンツの再生位置（時刻）を設定する（Ｓ３１０）。
その後、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ３１４）、セッション状態の設定制御フローを終了する。
【００５５】
ステップＳ３１１では、ストリーミング部１（１６）は、受信したＲＴＳＰメッセージが“再生位置移動メッセージ”であるか否かを判定し、“再生位置移動メッセージ”でない場合には（Ｓ３１１のＮｏ）、他のメッセージの判定に進む（Ｓ３１５）。
【００５６】
ステップＳ３１１で、ストリーミング部１（１６）は、受信したＲＴＳＰメッセージが、“再生位置移動メッセージ”だった場合には（Ｓ３１１のＹｅｓ）、セッション状態のストリーム開始時刻に、現在時刻を設定し、セッション状態のストリーム開始位置に、“再生位置移動メッセージ”で指定されたコンテンツの再生位置（時刻）を設定する（Ｓ３１２）。
そして、セッション状態の配信状況に、“再生中”を設定し、セッション状態のストリーム開始位置に設定された再生位置（時刻）から、コンテンツのストリーミングを開始する（Ｓ３１３）。
その後、ストリーミング部１（１６）は、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ３１４）、セッション状態の設定制御フローを終了する。
【００５７】
ステップＳ３１５では、ストリーミング部１（１６）は、受信したＲＴＳＰメッセージが、“再生終了メッセージ”であるか否かを判定し、“再生終了メッセージ”でない場合には（Ｓ３１５のＮｏ）、実施例のセッション状態の設定制御フローを終了する。
ステップＳ３１５で、受信したＲＴＳＰメッセージが、“再生終了メッセージ”であった場合には（Ｓ３１５のＮｏ）、ＲＴＳＰセッションが終了されるため、セッション状態を破棄し（Ｓ３１６）、実施例のセッション状態の設定制御フローを終了する。
【００５８】
つぎに、フェイルオーバーする待機系サーバのストリーミングバックアップ部１（１９）とストリーミングバックアップ部２（２０）が、セッション状態を用いて行う、ストリーミングサーバの引き継ぎ処理について説明する。
図１に示すように、サーバＡ（１１）からフェイルオーバーするサーバＢ（１２）とサーバＣ（１３）には、それぞれセッション状態が同期されているが、ストリーミングするコンテンツの再生位置（再生時刻）等のストリーミング状況を示すメディア状態は保持していない。サーバＢ（１２）のストリーミングバックアップ部１（１９）とサーバＣ（１３）のストリーミングバックアップ部２（２０）は、引き継ぎ処理で、セッション状態からコンテンツの再生位置（再生時刻）を求めてメディア状態とし、ストリーミングを継続する。
【００５９】
上記のセッション状態のストリーム開始時刻は、同期が行われた時の時刻を示している。したがって、サーバ障害を検出しフェイルオーバーする時の時刻とは異なり、タイムラグが生じている。サーバ障害がストリーミング中に発生した場合には、セッション状態のストリーム開始位置より進んだ再生位置（再生時刻）からストリーミングを再開する必要がある。
サーバＢ（１２）のストリーミングバックアップ部１（１９）とサーバＣ（１３）のストリーミングバックアップ部２（２０）は、それぞれが、セッション状態を保持しているので、並行して、引き継ぎ処理を行う。ここでは、サーバＢ（１２）のストリーミングバックアップ部１（１９）の処理を説明するが、サーバＣ（１３）のストリーミングバックアップ部２（２０）でも並行して同じ引き継ぎ処理が行われる。
【００６０】
ストリーミングバックアップ部１（１９）は、まず、セッション状態の配信状況を確認する。
セッション状態の配信状況が“停止中”の場合には、サーバ障害が発生した時にストリーミングが停止していた（例えば、ＲＴＳＰの一時停止メッセージを受信）ので、ストリーミングの再生位置は進んでおらず、セッション状態のストリーム開始位置をメディア状態に設定して、ストリーミング処理を継続する。
【００６１】
セッション状態の配信状況が“再生中”の場合には、ストリーミングバックアップ部１（１９）は、サーバ障害が発生した時にストリーミングしていた（例えば、ＲＴＳＰの再生開始メッセージを受信）ので、ストリーミングの再生位置が進んでいるので、次の数式１により、セッション状態のストリーム開始時刻とストリーム開始位置からメディア状態の再生位置を求める。
再生位置（時刻）  ＝
ストリーム開始位置（時刻）＋（現在時刻−ストリーム開始時刻）  …（数式１）
【００６２】
つまり、ストリーミングを引き継ぐバックアップサーバのストリーミングバックアップ部１（１９）は、ＲＴＳＰメッセージの受信タイミングで同期されているセッション状態のストリーム開始位置（時刻）に、現在時刻とストリーム開始時刻の差分を加えることで、継続するストリーミングの開始位置（時刻）を算出する。
これにより、サーバをフェイルオーバーしても、ストリームがロールバックすることなしに、ストリーミングを継続することができる。なお、本実施例では、フェイルオーバー時のストリームの欠落を防止することはできないが、フェイルオーバーに要する時間に応じて、ストリーミング・バッファ量を調整することで、ストリームの欠落を防止できる。
【００６３】
また、本実施例によれば、処理の引き継ぎのためのセッション状態の同期頻度を小さくできるので、サーバのスループットの低下を抑制でき、アクティブ／アクティブ構成のストリーミングサーバのクラスタシステムを実現することができる。さらに、フェイルオーバー時の引き継ぎ処理が分散されるので、見掛けのフェイルオーバーに要する時間を短縮でき、フェイルオーバー時のストリームの欠落を低減することができる。
【００６４】
本実施例では、フェイルオーバーする際の引き継ぎ情報であるセッション状態を、ＲＴＳＰメッセージの受信により同期する例を説明したが、図３のフローの要求メッセージに限定されるものではないことは言うまでもない。また、ＲＴＳＰ以外のプロトコルにより、セッション状態の同期を行ってもよい。例えば、ＲＴＣＰレポートの受信タイミングで、セッション状態の同期を行う。
【００６５】
《実施例２》
つぎに、上記の実施例１とは、フェイルオーバーする際の引き継ぎ情報であるセッション状態と、待機系サーバの処理が異なる他の実施例について説明する。
図４は、本実施例のストリーミングサーバの構成を示す図であり、図５は、本実施例のセッション状態のデータ構成を説明する図である。
【００６６】
本実施例のストリーミングサーバクラスタ４０は、複数台の物理サーバがクラスタ構成されたストリーミングサーバにおいて、待機系の物理サーバを設けずに、バックアップサーバを分散させるアクティブ／アクティブ構成のクラスタシステムを構成している。
具体的には、ストリーミングサーバクラスタ４０は、サーバＡ（４１）とサーバＢ（４２）とサーバＣ（４３）がクラスタリングされ、サーバＢ（４２）とサーバＣ（４３）に、サーバＡ（４１）で実行されるストリーミング処理がフェイルオーバーされる。
【００６７】
ストリーミングサーバクラスタ４０には、視聴端末４４と視聴端末４５が接続され、それぞれの端末からのＶＯＤサービスの要求に基づいて、サーバＡ（４１）で実行され、ＲＴＰ／ＲＴＣＰ、ＲＴＳＰにより制御をおこなうストリーミングアプリケーションにより、映像配信を行っている。この時、ストリーミングするメディアは、サーバＡ（４１）、または、図示しないメディアサーバに格納されている。
詳細には、サーバＡ（４１）は、視聴端末１（４４）へ映像配信１をストリーミングするストリーミング部１（４６）と、視聴端末２（４５）へ映像配信２をストリーミングするストリーミング部２（４７）が設けられている。
【００６８】
サーバＡ（４１）のストリーミング部１（４６）には、視聴端末４４に、ＶＯＤサービスを行うストリーミングアプリケーションの実行に必要な宛先ＩＰアドレスなどの配信に必要な情報を、セッション状態１に保持している（詳細は後述）。さらに、ストリーミングデータであるＲＴＰパケットのシーケンス番号またはＲＴＰタイムスタンプ等の送出コンテンツの再生時刻を含んでいるメディア状態１を保持し、メディアのストリーミングを制御している。サーバＡ（４１）のストリーミング部２（４７）も同様にセッション状態２とメディア状態２を保持している。
より詳細には、サーバＡ（４１）は、視聴端末１（４４）の視聴要求に基づくストリーミングと、視聴端末２（４５）の視聴要求に基づくストリーミングを行っており、ストリーミング部１（４６）で、セッション状態１とメディア状態１により視聴端末１（４４）への映像配信１が制御され、ストリーミング部２（４７）で、セッション状態２とメディア状態２により視聴端末２（４５）への映像配信２が制御されている。
【００６９】
サーバＡ（４１）とサーバＢ（４２）とサーバＣ（４３）には、それぞれ、サーバを監視し、サーバ障害時に連携してフェイルオーバー処理をおこなうクラスタ制御部（４８a、４８ｂ、４８ｃ）が設けられている。
クラスタ制御部（４８a、４８ｂ、４８ｃ）は、サーバＡ（４１）を監視して、障害検出時にフェイルオーバー処理をおこなうサーバＢ（４２）にセッション状態１のバックアップを定期的に生成し、サーバＣ（４３）にセッション状態２のバックアップを定期的に生成して、サーバＡ（４１）のストリーミング処理の引き継ぎに備えている。また、これにより、サーバＡ（４１）とサーバＢ（４２）、サーバＣ（４３）の同期が行われる。
【００７０】
また、詳細は後述するが、サーバＢ（４２）のストリーミングバックアップ部１（４９）は、セッション状態１を基に映像擬似配信１を行い、メディア状態１を自己更新しながら、引き継ぎ処理に備え、フェイルオーバー時には、メディア状態１を基にストリーミングを継続する。サーバＣ（４３）のストリーミングバックアップ部２（５０）も、同様に、セッション状態２を基に映像擬似配信２を行い、メディア状態２を自己更新しながら、引き継ぎ処理に備え、フェイルオーバー時には、メディア状態２を基にストリーミングを継続する。
【００７１】
本実施例のセッション状態のデータ構成は、図５に示すように、視聴端末のネットワークアドレスを示す配信先ＩＰアドレスと、視聴端末のＶＯＤ視聴アプリケーションの識別番号を示すボート番号を含んでいる。
さらに、セッション状態は、ストリームが再生中（送出中）であるか、停止中であるかを示す配信状況と、送出するＲＴＰパケットのストリーム開始シーケンス番号とを含んで構成されている。
このセッション状態は、サーバＡ（４１）のストリーミング部１（４６）とストリーミング部２（４７）で、図６に示す制御フローによりＲＴＳＰメッセージを視聴端末から受信するたびに設定され、バックアップサーバであるサーバＢ（４２）やサーバＣ（４３）に転送されて、セッション状態が同期される。
【００７２】
図６により、視聴端末の映像配信ごとにサーバＡ（４１）のストリーミング部１（４６）で処理されるセッション状態の設定制御フローを詳細に説明する。ここで、セッション状態のストリーム開始シーケンス番号は、ＲＴＰパケットのシーケンス番号に設定されるものとする。サーバＡ（４１）のストリーミング部２（４７）でも同様の処理が行われる。
まず、ストリーミング部１（４６）は、視聴端末からＲＴＳＰメッセージを受信したか否かを判定し（Ｓ６０１）、ＲＴＳＰメッセージでなかった場合には（Ｓ６０１のＮｏ）、実施例のセッション状態の設定制御フローを終了する。
【００７３】
ステップＳ６０１で、ストリーミング部１（４６）は、ＲＴＳＰメッセージを受信した場合には（Ｓ６０１のＹｅｓ）、セッション状態の配信先ＩＰアドレスとポート番号を設定する（Ｓ６０２）。
つぎに、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“再生開始メッセージ”であるか否かを判定し（Ｓ６０３）、“再生開始メッセージ”でなかった場合には（Ｓ６０３のＮｏ）、他のメッセージの判定に進む（Ｓ６０４）。
ステップＳ６０４では、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“再生位置移動メッセージ”であるか否かを判定し、“再生位置移動メッセージ”でなかった場合には（Ｓ６０４のＮｏ）、他のメッセージの判定に進む（Ｓ６０６）。
【００７４】
ステップＳ６０３で、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが“再生開始メッセージ”だった場合（Ｓ６０３のＹｅｓ）、または、ステップＳ６０４で、受信したＲＴＳＰメッセージが“再生位置移動メッセージ”だった場合（Ｓ６０４のＹｅｓ）には、セッション状態の配信状況に“再生中”を設定し、コンテンツのストリーミングを行う（Ｓ６０５）。
その後、ストリーミング部１（４６）は、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ６０８）、セッション状態の設定制御フローを終了する。
このとき、ストリーミング部１（４６）は、セッション状態のストリーム開始シーケンス番号には、ＲＴＰにより送出されるパケットのシーケンス番号が設定されている。
【００７５】
ステップＳ６０６では、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“一時停止メッセージ”であるか否かを判定し、“一時停止メッセージ”でない場合には（Ｓ６０６のＮｏ）、他のメッセージの判定に進む（Ｓ６０９）。
ステップＳ６０６で、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“一時停止メッセージ”だった場合には（Ｓ６０６のＹｅｓ）、セッション状態の配信状況に“停止中”を設定し、ストリーミングを停止する（Ｓ６０７）。
その後、ストリーミング部１（４６）は、バックアップサーバのセッション状態と内容を同期させて、セッション状態のバックアップを作成し（Ｓ６０８）、セッション状態の設定制御フローを終了する。
【００７６】
ステップＳ６０９では、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“再生終了メッセージ”であるか否かを判定し、“再生終了メッセージ”でない場合には（Ｓ６０９のＮｏ）、実施例のセッション状態の設定制御フローを終了する。
ステップＳ６０９で、ストリーミング部１（４６）は、受信したＲＴＳＰメッセージが、“再生終了メッセージ”であった場合には（Ｓ６０９のＮｏ）、映像配信が終了されるため、セッション状態を破棄し（Ｓ６１０）、実施例のセッション状態の設定制御フローを終了する。
【００７７】
つぎに、セッション状態を用いて、フェイルオーバーするバックアップサーバのストリーミングサーバの引き継ぎ処理について説明する。
図４に示すサーバＡ（４１）からフェイルオーバーするサーバＢ（４２）とサーバＣ（４３）には、それぞれストリーミング処理を継続するためのセッション状態とメディア状態が保持され、ストリーミングバックアップ部１（４９）とストリーミングバックアップ部２（５０）により参照される。
【００７８】
ここで、セッション状態は、上記のサーバＡ（４１）のストリーミング部１（４６）とストリーミング部２（４７）で同期処理されるが、メディア状態は更新されない。そこで、本実施例のサーバＢ（４２）のストリーミングバックアップ部１（４９）とサーバＣ（４３）のストリーミングバックアップ部２（５０）は、サーバＡ（４１）に同期しているセッション状態を基に、擬似ストリーミング処理をおこない、ストリーミングするコンテンツの再生位置（再生時刻）を含むメディア情報を更新して、フェイルオーバーに備える。
【００７９】
このとき、サーバＡ（４１）のストリーミング部１（４６）とストリーミング部２（４７）で映像配信１または映像配信２のストリームが停止した際には、サーバＢ（４２）のストリーミングバックアップ部１（４９）とサーバＣ（４３）のストリーミングバックアップ部２（５０）のメディア情報の更新も停止する。これは、セッション状態の配信状況を参照して制御することができる。
【００８０】
つぎに、サーバＢ（４２）のストリーミングバックアップ部１（４９）またはサーバＣ（４３）のストリーミングバックアップ部２（５０）で行われるストリーミングサーバの引き継ぎ処理（メディア情報の更新処理）の内容を説明する。以下は、サーバＢ（４２）のストリーミングバックアップ部１（４９）について説明するものであるが、サーバＣ（４３）のストリーミングバックアップ部２（５０）も同様である。
ストリーミングバックアップ部１（４９）は、まず、セッション状態の配信状況を確認する。
セッション状態の配信状況が“停止中”の場合には、サーバＡ（４１）の映像配信１のストリームが停止しているので、ストリーミングバックアップ部１（４９）は、メディア情報の更新処理を行わない。
【００８１】
セッション状態の配信状況が“停止中”から“再生中”に変わった時に、ストリーミングバックアップ部１（４９）は、セッション情報のストリーム開始シーケンス番号の内容をメディア状態に設定し、擬似ストリーミング処理を開始して、メディア状態（ＲＴＰパケットのシーケンス番号またはＲＴＰタイムスタンプ）の更新を行う。
ストリーミングバックアップ部１（４９）の擬似ストリーミング処理は、サーバＡ（４１）の実際のストリーミング処理に並行して行われる。
【００８２】
また、この擬似ストリーミング処理では、ストリーミングバックアップ部１（４９）は、視聴端末４４へのストリーミングは行わずに、配信先をサーバＢ（４２）のループバックアドレスとしてストリーミングを行い、順次、ＲＴＰパケットを送出してシーケンス番号をインクリメントし、シーケンス番号を含むメディア状態を更新する。
これにより、フェイルオーバーによる引き継ぎが行われる際には、ＲＴＰパケットのシーケンス番号が非連続にならないので、ストリームの連続性を確保できる。
【００８３】
上記の擬似ストリーミング処理では、ループバックアドレスへのデータ出力や、メディアサーバへの接続を行うため、サーバＢ（４２）の処理負荷が発生する。
このため、サーバＡ（４１）のＲＴＰパケットの送出周期に対応して、サーバＢ（４２）のストリーミングバックアップ部１（４９）が、ＲＴＰパケットのシーケンス番号をインクリメントしてメディア状態を更新するようにして、サーバＢ（４２）の処理負荷を低減してもよい。
【００８４】
本実施例によれば、バックアップサーバで、ストリーミングサーバのＲＴＳＰメッセージの受信に同期して更新されるセッション状態を参照して、ストリームの配信中／停止中を判定し、ストリーミングサーバのストリームの配信中に、ストリーミングサーバとは別にバックアップサーバでＲＴＰパケットのシーケンス番号を含むセッション状態を更新するようにしたので、フェイルオーバー時のセッション状態の生成が不要となり、引き継ぎ処理時間の短縮をおこなえる。これにより、フェイルオーバー時のストリーム欠落を防止することができる。
【００８５】
上記の実施例では、ストリーミングサーバがアクティブ／アクティブ構成のクラスタシステムであるとして説明したが、アクティブ/スタンバイ構成のクラスタシステムでも実施することができる。
【００８６】
また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。上記の実施例は本発明で分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。
【符号の説明】
【００８７】
１０  ストリーミングクラスタ
１１  サーバＡ（ストリーミングサーバ）
１２  サーバＢ（バックアップサーバ）
１３  サーバＣ（バックアップサーバ）
１４  視聴端末１
１５  視聴端末２
１６  ストリーミング部１
１７  ストリーミング部２
１８ａ、１８ｂ、１８ｃ  クラスタ制御部
１９  ストリーミングバックアップ部１
２０  ストリーミングバックアップ部２
【図１】
0006343241.tif 000002
【図２】
0006343241.tif 000003
【図３】
0006343241.tif 000004
【図４】
0006343241.tif 000005
【図５】
0006343241.tif 000006
【図６】
0006343241.tif 000007
【図７】
0006343241.tif 000008
【図８】
0006343241.tif 000009