JP2010531618A - リアルタイムプロトコルストリームマイグレーション - Google Patents

Abstract

ＲＴＳＰストリームを送信するプライマリサーバをモニタ及び移行させる方法が提供される。バックアップサーバは、プライマリサーバがアクティブであるか判断するため、少なくとも１つのプライマリサーバをモニタする。プライマリサーバが非アクティブであると判断すると、バックアップサーバは、非アクティブなプライマリサーバがデータをストリーミングしていた接続を引き継ぎ、その後にＲＴＳＰストリームの送信を引き継ぐ。バックアップサーバはさらに、送信される必要のある次のデータのファイルにおける位置を求めることができる。

Description

本原理は、一般にデータストリーミング通信に関し、より詳細にはリアルタイムストリーミング通信のフェイルオーバ機能を提供するシステム及び方法に関する。

様々な多数のメディアウェブサイトが、インターネットを介した消費者への大量のオーディオ及びビデオデータの提供がますます増大している。この結果、まずます多くのストリーミングデータがインターネットを介し送信されている。

しかしながら、オーディオ及びビデオストリーミングの性質は、オーディオ／ビデオ再生のため、ストリーミングサーバへのコンスタントな接続を必要とする。Ｉｎｔｅｒｎｅｔ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｄｏｃｕｍｅｎｔ ＲＦＣ ３５５０ Ｊｕｌｙ ２００３に説明されるようなリアルタイムストリーミングプロトコル（ＲＴＳＰ）は、一般にデータは相対的にシーケンシャルな順序によりクライアントに送信される必要がある離散的なパケットにより送信されることを規定する。さらに、ストリーミングサーバがさらなるストリームデータを送信することを妨げる障害に遭遇した場合、クライアントは劣化、障害又は完全な表示不能を被ることになる。

故障したストリーミングサーバに基づく接続を修復するためのいくつかの方法が提案されてきた。例えば、“Ｆｉｎｅ−ｇｒａｉｎｅｄ ｆａｉｌｏｖｅｒ ｕｓｉｎｇ ｃｏｎｎｅｃｔｉｏｎ ｍｉｇｒａｔｉｏｎ”は、プロキシーインターネットプロトコルアドレスを介し各ストリーミング接続をルーティングすることによってＴＣＰフェイルオーバ機能を提供する方法について記載している（“Ｆｉｎｅ−ｇｒａｉｎｅｄ ｆａｉｌｏｖｅｒ ｕｓｉｎｇ ｃｏｎｎｅｃｔｉｏｎ ｍｉｇｒａｔｉｏｎ”，Ａｌｅｘ Ｃ．Ｓｎｏｅｒｅｎ，Ｄａｖｉｄ Ｇ．Ａｎｄｅｒｓｅｎ，ａｎｄ Ｈａｒｉ Ｂａｌａｋｒｉｓｈｎａｎ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ３ｒｄ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ ａｎｄ Ｓｙｓｔｅｍｓ，ｐａｇｅｓ ２２１−２３２．Ｕｓｅｎｉｘ，２００１）。この方法は、データサーバが故障した場合、セカンダリサーバがプライマリサーバの役割を引き継ぐ。しかしながら、この移転は、アプリケーションプロトコルレベルについてはわからず、頻繁な状態同期がアプリケーションに応じて必要とされるかもしれない。

ストリームマイグレーション又はストリーム移行（ｓｔｒｅａｍ ｍｉｇｒａｔｉｏｎ）の１つの現在の実現形態は、ＲｅａｌＮｅｔｗｏｒｋｓ‘ｓ^ＴＭ Ｈｅｌｉｘ^ＴＭサーバに認めることができる。Ｈｅｌｉｘ^ＴＭストリームマイグレーションは、当初のサーバが故障した場合、クライアントメディアプレーヤーアプリケーションにバックアップサーバに接続させることを含む。しかしながら、これらのフェイルオーバ機構は、ライブストリーミング中にサーバがダウンする問題を解決するものでない。これが機能する方法は、クライアントにバックアップサーバのリストを提供し、サーバがダウンした場合、クライアント自体がバックアップサーバから新たな接続を要求する必要がある。従って、プライマリサーバがだめになった場合、この情報によって対処するのはクライアントの責任である。しかしながら、ユーザがサーバのダウンを認識可能であるとき、ユーザの経験の質が影響され、インターネットなどの通信ネットワークを介し受信した情報の遅延及びバッファリングによって新たなストリームがセットアップされるまで許容できない時間を要するかもしれない。

本原理は、クライアントから独立してクライアントに関して透過的にＲＴＳＰ送信を監視及び移行し、クライアントにフェイルオーバ処理を実装する必要なく、フェイルオーバを行うことを可能にするシステム及び方法を提案する。

一態様によると、ＲＴＳＰモニタリング及びフェイルオーバ処理の本原理は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケットを送信するＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ストリームをモニタし、バックアップサーバに移行する方法及びシステムであって、ストリーミングセッションをオープンし、プライマリサーバからクライアントへのデータ転送ストリームを開始するステップと、少なくとも１つのバックアップサーバにより前記プライマリサーバをｐｉｎｇするステップと、前記プライマリサーバがアクティブ又は非アクティブであるか判断するステップとを有するシステム及び方法により解決される。前記プライマリサーバが非アクティブであると判断すると、本方法はさらに、バックアップサーバが前記プライマリサーバのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを引き継ぐステップと、前記プライマリサーバの少なくとも１つのオープンなストリーミングセッションをループするステップと、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を前記プライマリサーバから前記バックアップサーバに移行するステップと、オープンな各ストリーミングセッションについてＲＴＰセッションストリーム状態を導出するステップと、前記導出されたＲＴＳＰセッションストリーム状態を用いて、前記バックアップサーバから前記クライアントへのＲＴＳＰセッションストリーミングを再開するステップとを有してもよい。前記プライマリサーバがアクティブであると判断すると、本方法はさらに、所定時間待機するステップと、少なくとも１つのバックアップサーバによる前記プライマリサーバをｐｉｎｇするステップに戻るステップとを有してもよい。

本原理の効果、性質及び追加的な各種特徴は、添付した図面に関してより詳細に説明される例示的な実現形態を考慮してより明らかになるであろう。

図面では、同様の参照番号は各図を通じて同様のコンポーネントを示す。
図１は、従来技術について知られるようなリアルタイムストリーミングネットワークシステムを示す。 図２は、本原理によるリアルタイムストリーミングネットワークシステムを示す。 図３は、本原理によるプライマリサーバが故障するとバックアップサーバにリアルタイムストリームをマイグレートする方法のブロック図である。 各図は本原理のコンセプトを説明するためのものであって、本原理を説明するための可能な唯一の構成である必要はないことが理解されるべきである。

インターネット通信の当業者にとって、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を介しストリーミングオーディオ及びビデオファイルを送信することが知られている。一般に、ＲＴＳＰプロトコルは、ストリーミングセッションの開始時にサーバからメディアライブファイルの一部を送信し（サーバから一部のデータをバッファリングすると共に）、ストリーミングデータの表示又は使用中に残りのデータを送信し続けることを求める。この送信構成は、ジャストインタイム表示アーキテクチャにおいてストリーミングデータがクライアントに受信されると表示されることを可能にする。しかしながら、ストリーミングデータはジャストインタイムに送信されるため、すなわち、それが受信直後に要求又は使用されるため、サーバにおけるネットワークラグ又は故障は、ユーザの体感に重大な影響を与えるかもしれない。

従って、本原理は、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を介し送信されるオーディオ及びビデオデータストリームをモニタし、故障又はオーバロードしたサーバからバックアップサーバにストリームをシームレスにマイグレート又は移行させるシステム及び方法を提供する。

本原理は、デジタル通信ネットワーク上のＲＴＳＰストリームマイグレーションに関して説明されることは理解されるが、本原理はより広範なものであり、任意の通信ネットワーク上の任意の形式のデータ送信を含むものであってもよい。さらに、本原理は、コンピュータ、電話、セットトップボックス、衛星リンクなどにより用いられる任意のデータ送信システムに適用可能である。本原理は、リアルタイムデータ送信システムに関して説明されるが、本原理のコンセプトは、データ送信システムに拡張可能である。

図示される各要素はハードウェア、ソフトウェア又はこれらの組み合わせの各種形態により実現可能であることが理解されるべきである。好ましくは、これらの要素は、プロセッサ、メモリ及び入出力インタフェースを有しうる１以上の適切にプログラムされた汎用装置上でハードウェアとソフトウェアの組み合わせにより実現される。

本説明は、本原理を説明する。ここでは明示的には説明又は図示されないが、本原理を実現し、その趣旨及び範囲内に含まれる各種構成を当業者が考案できることが理解されるであろう。

ここに記載されるすべての実施例及び条件付言語は、読者が本原理及び本発明者が技術の向上に貢献したコンセプトを理解するのに役立つための教育的目的のためであり、このような具体的に記載された実施例及び条件に限定するものでないと解釈されるべきである。

さらに、本原理と共にその具体例の原理、態様及び実現形態を記載したすべての記述は、それの構成的及び機能的均等の双方を包含するものである。さらに、このような均等は現在既知の均等と共に将来開発される均等、すなわち、構成に関係なく同一の機能を実行する開発された任意の要素を含むことが意図される。

従って、例えば、ここに提供されるブロック図は本原理を実現する例示的なモジュールの概念図を表すことは、当業者に理解されるであろう。同様に、任意のフローチャート、フロー図、状態遷移図、擬似コードなどは、実質的にコンピュータ可読媒体により表現され、明示的には図示されないが、コンピュータ又はプロセッサにより実行される各種処理を表すことが理解されるであろう。

図示された各種要素の機能は、専用のハードウェアと共に適切なソフトウェアと関連付けてソフトウェアを実行可能なハードウェアを使用することにより提供されてもよい。プロセッサ又は要素により提供されると、これらの機能は単一の専用プロセッサ、単一の共有プロセッサ、又は一部が共有可能な複数の個別のプロセッサにより提供されてもよい。さらに、“プロセッサ”又は“コントローラ”という用語の明示的使用は、ソフトウェアを実行可能なハードウェアのみを参照していると解釈されるべきでなく、限定されることなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを格納するＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）及び不揮発性ストレージを暗黙的に含むものであってもよい。

従来及び／又はカスタムハードウェアなどの他のハードウェアもまた含まれてもよい。同様に、図示される任意のネットワーク、スイッチ、ルータ又は判定ブロックは単に概念的なものである。それらの機能は、プログラムロジックの動作を介し、専用ロジックを介し、プログラム制御及び専用ロジックを介し又は手動により実行されてもよく、特定の技術は、本説明からより具体的に理解されるように実施者により選択可能である。

請求項において、指定された機能を実行する手段として表される任意の要素は、例えば、ａ）当該機能を実行する各回路要素の組み合わせ、又はｂ）当該機能を実行するためソフトウェアを実行する適切な回路と組み合わされるファームウェア、マイクロコードなどを含む何れかの形式のソフトウェアを含む、当該機能を実行する何れかの方法を包含するものである。このような請求項により規定される本原理は、記載された各種手段により提供される機能が請求項が求める方法により組み合わせ及び一体化されるという事実に属する。このため、これらの機能を提供可能な任意の手段がここに示されるものと均等であるとみなされる。

本原理は、バックアップサーバにアクセス可能な位置においてサービスを提供しているサーバとすべてのアクティブなＲＴＳＰセッションに関する情報を維持することに関する。本原理はまた、各ＴＣＰ接続を移すのに必要とされるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）状態と共に、各セッションについてＲＴＳＰ会話を再生成するための情報を求めることを意図する。ハートビート機構は、サーバプールにおいてアクティブなサーバを追跡するのに使用される。サーバの機能停止があるとき、故障が検出可能であり、ＩＰアドレスの引き継ぎ（ロールオーバ）が実行される。標準的な手段を利用して、ＴＣＰ接続がその後にバックアップサーバに移すことができる。これらのステップは、典型的には、終了するまで数ミリ秒かかる。バックアップサーバは、その後にオリジナルサーバを引き継ぎ、プライマリサーなの代わりとしてＲＴＳＰ及びＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）データを送信することができる。いくつかの有用な実現形態では、プライマリサーバにより送信される同じメディアファイルがバックアップサーバにも利用可能である。これは、中央ストレージを実装し、、例えば、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）又はネットワーク接続されたバックアップサーバにファイルをバックアップする他のタイプのシステム又は方法などを利用して、当該ファイルシステムをエクスポートすることにより実現可能である。

ＲＴＳＰ状態がサーバをモニタすることによって決定される可能性があるため、主要な問題は、サーバとクライアントとの間のＲＴＰ状態を求める方法である。１つのオプションは、サーバとクライアントとの間で交換されたすべてのＲＴＰパケットのログをとることである。しかしながら、これは状態の更新を複数回することを意味し、毎秒数百万回のトランザクションを生じさせる。

本発明の原理の実現形態は、サーバ間の状態更新を回避するため、暗黙的な時間同期を利用するようにしてもよい。バックアップサーバは、特定のＲＴＳＰ送信の既知の開始時間からストリーム状態とＲＴＰ状態とを求めるようにしてもよい。ＲＴＰのキーとなる特徴は、ＲＴＰデータ送信がリアルタイムに基づくということである。所与の時点におけるストリーム状態は、時間とＲＴＳＰ状態とに基づく。本原理は、ＲＴＰストリーム状態の導出方法について説明する。

概略的に図１を参照するに、従来技術において知られているストリーミングネットワーク１００が図示される。まず、サーバグループ１３０は、１以上のリアルタイムプロトコル（ＲＴＰ）ストリーミングサーバ１３１ａ〜１３１ｃを有し、各ＲＴＰストリーミングサーバ１３１ａ〜１３１ｃは、ネットワーク１２０を介しメディアデータベース１１０に接続される。メディアデータベース１１０は、ストリーミングメディアとしてネットワーク１２０を介し送信可能なビデオ及びオーディオサービスを有する。

ＲＴＰストリーミングサーバ１３１ａ〜１３１ｃは、ルータ１４０を介しインターネット１５０（１つのタイプのネットワークとして）に接続され、これを介して、ＲＴＰストリーミングサーバ１３１ａ〜１３１ｃは、複数のクライアント１６１〜１６１ｄと通信する。

図２を参照するに、本発明の原理の一態様によるリアルタイムストリーミングネットワークシステム２００が図示される。まず、１以上のプライマリストリーミングサーバ１３１ａ〜１３１ｃを有するサーバグループ１３０が、ネットワーク１２０に接続され、これを介して、ストリーミングサーバ１３１ａ〜１３１ｃがメディアデータベース１１０にアクセス可能である。ストリーミングサーバ１３１ａ〜１３１ｃはまた、ルータ１４０などを介しインターネット１５０（１つのタイプの通信ネットワークとして）に接続され、これを介して、各サーバ１３１ａ〜１３１ｃは１以上のクライアント１６１ａ〜１６１ｄに双方向通信してもよい。

本原理はさらに、１以上のＲＴＰサーバ２１１ａ〜２１１ｃを有するバックアップサーバグループ２１０を有する。バックアップサーバは、各バックアップサーバがメディアデータベース１１０のオーディオ／ビデオコンテンツにアクセス可能となるように、メディアデータベース１１０とネットワーク１２０を介し通信するよう構成される。さらに、バックアップサーバ２１１ａ〜２１１ｃはまた、インターネット１５０上のルータ１４０を介し１以上のクライアント１６１ａ〜１６１ｄと通信するよう構成される。あるいは、サーバ１３１ａ〜１３１ｃとバックアップサーバ２１１ａ〜２１１ｃは、ネットワーク１２０を介しルータ１４０とインターネット１５０と接続してもよい。バックアップサーバ２１１ａ〜２１１ｃはさらに、各プライマリサーバ１３１ａ〜１３１ｃからのネットワークトラフィックをモニタするよう構成されてもよい。バックアップサーバ２１１ａ〜２１１ｃは、ストリーミングセッションコンフィギュレーションとストリーミングセッション状態とに関する情報をモニタ及び記録するよう構成されてもよい。さらに、バックアップサーバ２１１ａ〜２１１ｃは、プライマリサーバ１３１ａ〜１３１ｃと直接通信可能であってもよい。

本発明の原理によりネットワークモニタリング技術を実現するとき、各バックアップサーバ２１１ａ〜２１１ｃのネットワークカードは、ネットワークカードがそれに対して具体的にアドレス指定されたトラフィックのみでなく、カードに送信されたすべてのネットワークトラフィックを受け付けるプロミスキャスモード（ｐｒｏｍｉｓｃｕｏｕｓ ｍｏｄｅ）に設定されてもよい。この実現形態では、クラスタの一部が特定のバックアップサーバ２１１ａ〜２１１ｃがモニタしているプライマリサーバ１３１ａ〜１３１ｃからのものでないネットワークトラフィックをフィルタリング可能であるとき、バックアップサーバ２１１ａ〜２１１ｃは、特定のプライマリサーバ１３１ａ〜１３１ｃをモニタする。しかしながら、バックアップサーバ２１１ａ〜２１１ｃの台数とプライマリサーバ１３１ａ〜１３１ｃの台数との任意の関係が効果的に利用可能であることに留意すべきである。例えば、資本コストを低下させるため、数台のバックアップサーバ２１１ａ〜２１１ｃしか多数のプライマリサーバ１３１ａ〜１３１ｃをモニタしないようにしてもよい。従って、バックアップサーバ２１１ａ〜２１１ｃの台数は、大きなプライマリサーバ１３１ａ〜１３１ｃのクラスタのための十分なフェイルオーバ機能を提供するよう調整されてもよい。

プライマリサーバ１３１ａ〜１３１ｃの台数とバックアップサーバ２１１ａ〜２１１ｃの台数のコンセプトはさらに、異なるＲＴＰストリームが各種プライオリティに割り当てられる状況に対して拡張可能である。例えば、高品位ビデオに係るＲＴＰストリームが、低品質なオーディオに係る別のＲＴＰストリームと同時にクライアント１６１ａに送信されている場合、ビデオストリームがオーディオストリームより重要であるプライオリティが存在しうる。従って、配信されるメディアのタイプ及び／又はコンテンツに対して、より高いプライオリティのメディア（ビデオ）が低プライオリティのメディア（低品質オーディオ）より多くのＲＴＰバックアップサーバ２１１ａ〜ｃに置かれるという割当てがなされることが考えられる。このメディアデータベース１１０のプライオリティの決定は、プライマリサーバ１３１ａ〜１３１ｃとバックアップサーバ２１１ａ〜ｃの両方を制御する主体によって行うことが可能である。

図３を参照するに、本原理の一態様によるプライマリサーバ１３１ａ〜１３１ｃの故障に応答してリアルタイムストリームを１以上のバックアップサーバ２１１ａ〜２１１ｃに移行（転送）するための方法３００のブロック図が示される。

まず、ブロック３１０において、ＲＴＰストリームが開始される。有用な一実現形態では、プライマリサーバ１３１ａ〜１３１ｃは、クライアント１６１ａ〜１６１ｄとの新たなセッションを開始する。このセッションは、効果的には、所定の条件が充足されることによって、又は既知若しくはまだ未発見の他の何れかの手段によって、クライアント１６１ａ〜１６１ｄのリクエストにより開始されてもよい。例えば、クライアント１６１ａ〜１６１ｄは、ウェブページに埋め込まれたハイパーリンクをクリックすることによって、最近のテレビ番組からのビデオを要求してもよい。その後、ユーザインタフェースがクライアント１６１ａ〜１６１ｄに表示され、ユーザがストリーミングメディアの表示を制御することが可能となる。例えば、リンクをクリックした後、クライアントは、メディア表示領域と再生ボタン、ポーズボタン、メディアクリップタイムラインなどを含む関連する制御とによりメディアプレーヤーをオープンしてもよい。このようなインタフェースは、既知であり、当業者に知られている。

適切なユーザインタフェースをロードすると、ブロック３１０において、データ転送が開始される。有用な一実現形態では、サーバ１３１ａ〜１３１ｃからクライアント１６１ａ〜１６１ｄに転送されるデータは、表示前の短時間クライアント１６１ａ〜１６１ｄにおいてバッファされてもよい。例えば、ユーザがストリーミングメディアファイルを表示するためリンクをクリックすると、メディアファイルがメディアプレーヤーインタフェースにおいてオープンされる。その後、メディアプレーヤーはサーバ１３１ａ〜１３１ｃに接続し、所望のファイルを要求する。サーバがこのリクエストを承認した後、サーバ１３１ａ〜１３１ｃは、メディア情報を含むデータパケットをクライアントに送信し始め、その後、それらが表示される。ストリーミングセッションのネゴシエーションは、ストリーミングセッションの開始部分とみなされる。同様に、ＲＴＳＰ状態は、自動的に開始されるか、又はユーザが再生ボタンをクリックしたときなどに、メディア再生を開始するためプレイするよう変更される。

各セッションを適切に追跡するため、以下に限定されないが、ＲＴＰヘッダにおいて使用される送信ソース識別子（ＳＳＲＣ）、ペイロードタイプ、ストリーミングされるリソースの位置（ＵＲＬ）、データがストリーミングされているサーバ及びクライアント番号、ＲＴＳＰ状態がプレイに変更された後の最初のＲＴＰパケットのシーケンス番号、ＲＴＳＰ状態がプレイに変更された後の最初のＲＴＰパケットのタイムスタンプ、ＲＴＳＰ状態がプレイに変更されたときのネットワークタイム（ＷＴ）及びストリーミングセッションが開始されたネットワークタイムを含む複数の情報が何れかのバックアップサーバ２１１ａ〜２１１ｃに格納され、利用可能とされる必要がある。

この情報は、他の方法では、バックアップサーバ２１１ａ〜２１１ｃにアクセス可能な共通のネットワーク位置に情報を保存することによって、情報をバックアップサーバ２１１ａ〜２１１ｃに直接送信することによって、又はバックアップサーバ２１１ａ〜２１１ｃがプライマリサーバ１３１ａ〜１３１ｃのネットワークトラフィックをモニタすることによって、バックアップサーバ１３１ａ〜１３１ｃに通信されてもよい。

さらに、ストリーミングセッションの移行（転送）を正確に計算するため、プライマリサーバ１３１ａ〜１３１ｃとバックアップサーバ２１１ａ〜２１１ｃのすべてが、同じ時間ベースを使用してネットワークタイム又はタイムスタンプを計算するようにしてもよい。有用な一実現形態では、プライマリサーバ１３１ａ〜１３１ｃとバックアップサーバ２２１ａ〜２２１ｃの内部クロックは、ネットワーク１２０上のネットワークタイムプロトコル（ＮＴＰ）を用いて同調されてもよい。

ブロック３１０においてデータストリームが開始された後、ブロック３３０において、バックアップサーバ２１１ａ〜２１１ｃはプライマリサーバをｐｉｎｇする。ｐｉｎｇという用語は、ｐｉｎｇ元のサーバがターゲットサーバが応答していることを確認することを可能にするシンプルなＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）エコーリクエストを意味するのに利用可能であるが、このケースにおけるｐｉｎｇという用語は、何れかの形式のサーバ活動の検証を含むものである。有用な一実現形態では、各プライマリサーバは、１以上のバックアップサーバ２１１ａ〜２１１ｃにアドレス指定されたハートビート信号をブロードキャストするようにしてもよい。他の有用な実現形態では、ｐｉｎｇは、ターゲットサーバ１３１ａ〜１３１ｃの一部に対してほとんど又は全く処理を要求しない小さなリクエストである。しかしながら、ＩＣＭＰエコーリクエストなどのシンプルなｐｉｎｇは、サーバが応答していることしか検証しない。これは、プライマリサーバ１３１ａ〜１３１ｃがトラフィックを処理していることを検証するのに有用であるかもしれないが、それは、ロードサーバ１３１ａ〜１３１ｃの下にあるサーバの検証が処理可能であることを許容するものでない。このような場合、ｐｉｎｇは、要求元サーバが応答時間を測定することによって、以下に限定されるものでないが、例えば、実際のメディアクリップ又はプライマリサーバ１３１ａ〜１３１ｃからの他のリソースに対するリクエストであってもよいし、又はプライマリサーバ１３１ａ〜１３１ｃが現在適切に実行中である若しくはオーバロードであることを示す状態コードにより応答するリクエストであってもよい。ｐｉｎｇという用語はまた、サーバがアクティブ又は非アクティブであるか示す状態メッセージを表すことが理解されるべきである。

他の有用な実現形態では、すべてのプライマリサーバが正常に動作していることを確認するため、すべてのバックアップサーバは定期的にすべてのプライマリサーバとｐｉｎｇ（通信）するようにしてもよい。しかしながら、プライマリサーバ１３１ａ〜１３１ｃの台数とバックアップサーバ２１１ａ〜２１１ｃの台数が増加するに従って、ｐｉｎｇリクエストの総数は指数的に増加する。このため、他の有用な実現形態では、プライマリサーバは、バックアップサーバ２１１ａ〜２１１ｃの関連するクラスタを有するクラスタにグループ化されてもよい。例えば、１０００台のプライマリサーバ１３１ａ〜１３１ｃと５００台のバックアップサーバ２１１ａ〜２１１ｃを有するデータセンタでは、４台のプライマリサーバが一緒にクラスタ化され、２台のバックアップサーバによりモニタされるようにしてもよい。各クラスタ内では、ブロック３３０においてサーバがｐｉｎｇされる毎に、８つのｐｉｎｇリクエストしか発生しない（クラスタの各バックアップサーバがクラスタの各プライマリサーバにｐｉｎｇすることによって）。このようなクラスタが２５０個ある場合、ブロック３３０においてサーバにｐｉｎｇするためのネットワーク負荷の全体は、２０００個のｐｉｎｇリクエストにしかならない。他方、５００台のバックアップサーバのすべてがこのようなネットワーク上の１０００台のプライマリサーバのすべてをモニタした場合、ブロック３３０においてサーバがｐｉｎｇされる毎に、５００，０００個のｐｉｎｇリクエストが必要となるであろう。本例は４台のプライマリサーバ１３１ａ〜１３１ｃのクラスタをモニタする２台のバックアップサーバ２１１ａ〜２１１ｃのクラスタを使用するが、任意数又は任意の構成のバックアップサーバ２１１ａ〜２１１ｃとプライマリサーバが、冗長性の要求とネットワークアーキテクチャの指示として利用されてもよい。

あるいは、プライマリサーバ１３１ａ〜１３１ｃがハートビート信号を使用するとき、各プライマリサーバ１３１ａ〜１３１ｃは、ブロック３３０において、ネットワーク１２０上に定期的にハートビート信号を送信するようにしてもよく、このハートビート信号は、バックアップサーバ２１１ａ〜２１１ｃがネットワーク１２０又はルータ１４０を介しプライマリサーバ１３１ａ〜１３１ｃのデータトラフィックをモニタすることによって受信されてもよい。

バックアップサーバ２１１ａ〜２１１ｃは、その後ブロック３４０において、各プライマリサーバ１３１ａ〜１３１ｃがアクティブ／非アクティブであったか決定する。有用な一実現形態では、バックアップサーバは、ブロック３３０において各プライマリサーバ１３１ａ〜１３１ｃに送信されるｐｉｎｇへの応答を受信するのに必要な期間を測定してもよい。ｐｉｎｇレスポンスが指定期間内に受信されなかった場合、バックアップサーバ２１１ａ〜２１１ｃは、解析されるプライマリサーバ１３１ａ〜１３１ｃがアクティブでないと判断し、その後、故障しているプライマリサーバ１３１ａ〜１３１ｃのＲＴＳＰストリームセッションをバックアップサーバ２１１ａ〜２１１ｃに移行させるようにしてもよい。あるいは、他の有用な実現形態では、解析されているプライマリサーバ１３１ａ〜１３１ｃは、プライマリサーバ１３１ａ〜１３１ｃがオーバロードであること、又はサーバが回復不能なタイプのハードウェア若しくはソフトウェアの故障の被ったことを示すｐｉｎｇに対するレスポンスを返すようにしてもよい。このようなケースでは、バックアップサーバ２１１ａ〜２１１ｃはまた、プライマリサーバ１３１ａ〜１３１ｃがブロック３４０においてもはやアクティブでないと決定してもよい。

他方、プライマリサーバ１３１ａ〜１３１ｃが適切なレスポンス又は許容期間内にレスポンスをバックアップサーバ２１１ａ〜２１１ｃに送信した場合、バックアップサーバ２１１ａ〜２１１ｃは、プライマリサーバがブロック３４０においてアクティブであると決定してもよい。

ブロック３４０において、バックアップサーバ２１１ａ〜２１１ｃがプライマリサーバ１３１ａ〜１３１ｃがアクティブであると決定した場合、サーバのアクティブティをチェックする処理は、再びブロック３３０におけるｐｉｎｇ処理の開始までブロック３２０において指定されたタイムアウトまで待機する。特に有用な実現形態では、ブロック３３０のタイムアウトの期間は、ユーザの体感を低下させることなくバックアップサーバ２１１ａ〜２１１ｃへのフェイルオーバが行われることを可能にするのに十分な短さとなる。

しかしながら、ブロック３４０において、サーバがアクティブでないと決定された場合、バックアップサーバ２１１ａ〜２１１ｃは、まずブロック３５０において故障したプライマリサーバ１３１ａ〜１３１ｃのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを引き継ぎ、ブロック３６０においてアクティブなＴＣＰ接続を移行することによって、故障したプライマリサーバ１３１ａ〜１３１ｃのＲＴＳＰストリーミングセッションをバックアップサーバ２１１ａ〜２１１ｃに移行させる。ブロック３５０におけるＩＰアドレスの引き継ぎと、ブロック３６０におけるＴＣＰ接続の移行は、データ通信の当業者に周知である。実際的には、ブロック３５０におけるこのようなＩＰアドレスの引き継ぎと、ブロック３６０におけるＴＣＰ接続の移行は、実現するのに数ミリ秒しかかからない。これは、バックアップサーバ２１１ａ〜２１１ｃが当初の現在故障しているプライマリサーバ１３１ａ〜１３１ｃになりすますことを可能にする。

その後ブロック３７０において、バックアップサーバ２１１ａ〜２１１ｃは、故障したプライマリサーバ１３１ａ〜１３１ｃのアクティブなＲＴＳＰストリーミングセッションのすべてをループし、ブロック３７０において遭遇する各アクティブストリーミングセッションに対して、バックアップサーバは、ブロック３８０においてセッション状態を求める。ブロック３８０におけるセッション状態の派生は、ストリームがブロック３１０において開始されたときに収集された情報を利用する。故障前にプライマリサーバ１３１ａ〜１３１ｃをモニタすることから収集されるストリームの状態に関する最新の既知の情報と共にこのような情報を使用することによって、バックアップサーバは、クライアント１６１ａ〜１６１ｃに送信される必要のある次のデータパケットを求めるようにしてもよい。有用な一実現形態では、以下の関数がストリーム状態を求めるのに利用されてもよい。

［１］ＳＮ（Ｘ）＝ＳＮ＋（Ｘ−ＳＮＭ）
ただし、Ｘは、クライアント１６１ａ〜１６１ｃに次に送信される必要のあるメディアファイルにおけるメディアサンプルのインデックスを表す。ＳＮ（Ｘ）は、ＲＴＰパケットに置かれるべき現在のシーケンス番号であり、ＳＮは、ＲＴＳＰストリーム状態がプレイに変更された後に最初のＲＴＰパケットのシーケンス番号であり、ＳＮＭは、ＲＴＳＰストリーム状態がプレイに変更されたときのＲＴＰパケットのメディアサンプルのインデックスである。従って、（Ｘ−ＳＮＭ）は、ＲＴＳＰストリームがプレイに変更されてからのサンプルの個数を表す。

Ｘは、［２］ＴＳ（Ｘ）＝ＴＳ（ＳＮＭ）＋Ｄから決定されてもよい。ただし、ＴＳ（Ｘ）は、Ｘのタイムスタンプであり、Ｄは、ＲＴＳＰ状態がプレイに変更されてから経過した時間である。Ｄは、［３］Ｄ＝ｔ−ＷＴにより計算されてもよい。ただし、ｔは現在のネットワークタイムであり、プライマリサーバ１３１ａ〜１３１ｃが故障した時間にほぼ近似し、ＷＴは、ＲＴＳＰセッション状態がプレイに変更されたネットワークタイムであり、ブロック３１０において記録され、その後にストリームが開始される。

従って、Ｄは、メディアサンプルがプライマリサーバ１３１ａ〜１３１ｃの故障前に送信された合計経過時間を表す。ＴＳ（ＳＮＭ）は、ＲＴＳＰがプレイに変更されたときに送信された最初のＲＴＰパケットのタイムスタンプを表し、Ｘ（ＴＳ（Ｘ））の現在必要とされるタイムスタンプを計算するための初期的なオフセットとして使用される。

Ｘのシーケンス番号（ＳＮ（Ｘ））は、独立して計算される。Ｘに対して計算されたタイムスタンプ（ＴＳ（Ｘ））を用いて、バックアップサーバ２１１ａ〜２１１ｃは、サンプルＸがタイムスタンプＴＳ（Ｘ）を有する場合、メディアファイルのサンプルＸの位置にメディアファイルのリードポインタを移動させてもよい。その後、バックアップサーバは、Ｘのシリアル番号を検出してもよい。最初のＲＴＰパケットのシリアル番号（ＳＮ）は、ストリーム全体の初期的なオフセットとして利用され、これに対して、現在のメディアファイルの現在のサンプルのシーケンス番号（Ｘ−ＳＮＭ）が加えられる。

ストリーミングセッション全体のオフセットと共にメディアファイルのオフセットを利用することによって、複数のメディアファイルが１つのセッションにおいてシーケンシャルにストリーミングされ、方法３００は、最初のメディアファイルの移行のメディアファイルの再生中の故障を処理するようにしてもよい。

ブロック３８０において、各アクティブなセッションに対して、ストリームセッション状態が求められると、バックアップサーバは、ブロック３５０において引き継いだＩＰアドレスを利用して、ブロック３６０において移行されたＴＣＰ接続を介し、ブロック３９０において、必要とされるメディアサンプルを送信する。

ストリーミングサーバをモニタするシステム及び方法の好適な実現形態が説明されたが（例示的であって限定的なものでない）、上記教示に基づき当業者は変更及び改良が可能であることに留意されたい。添付した請求項により規定される本原理の範囲及び趣旨の範囲内の変更は、開示された本原理の実現形態において可能であることが理解されるべきである。詳細により本原理が説明され、特許法により要求されるため、特許権により保護されることが所望及び請求されるものが添付した請求項に与えられる。

Claims (21)

1. ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケットを送信するＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ストリームをモニタし、バックアップサーバに移行する方法であって、
   ストリーミングセッションをオープンし、プライマリサーバからクライアントへのデータ転送ストリームを開始するステップと、
   少なくとも１つのバックアップサーバにより前記プライマリサーバをｐｉｎｇするステップと、
   前記プライマリサーバがアクティブ又は非アクティブであるか判断するステップと、
   を有し、
   前記プライマリサーバが非アクティブであると判断すると、
   バックアップサーバが前記プライマリサーバのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを引き継ぐステップと、
   前記プライマリサーバの少なくとも１つのオープンなストリーミングセッションをループするステップと、
   ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を前記プライマリサーバから前記バックアップサーバに移行するステップと、
   オープンな各ストリーミングセッションについてＲＴＰセッションストリーム状態を導出するステップと、
   前記導出されたＲＴＳＰセッションストリーム状態を用いて、前記バックアップサーバから前記クライアントへのＲＴＳＰセッションストリーミングを再開するステップと、
   を有する方法。
2. 前記プライマリサーバがアクティブであると判断すると、
   所定時間待機するステップと、
   少なくとも１つのバックアップサーバによる前記プライマリサーバをｐｉｎｇするステップに戻るステップと、
   を有する、請求項１記載の方法。
3. 前記オープンするステップはさらに、
   前記プライマリサーバが、前記ＲＴＳＰ状態がプレイに変更された後の最初のＲＴＰパケットのシーケンス番号を決定し、前記バックアップサーバに利用可能にするステップと、
   前記プライマリサーバが、前記ＲＴＳＰ状態がプレイに変更された後の最初のＲＴＰパケットのタイムスタンプを決定し、前記バックアップサーバに利用可能にするステップと、
   前記プライマリサーバが、前記ＲＴＳＰ状態がプレイに変更されたネットワークタイムを決定し、前記バックアップサーバに利用可能にするステップと、
   前記プライマリサーバが、前記ストリーミングセッションが開始されたネットワークタイムを決定し、前記バックアップサーバに利用可能にするステップと、
   を有する、請求項２記載の方法。
4. 前記導出するステップはさらに、
   メディアファイルにおけるメディアサンプルを有するＲＴＰパケットのシーケンス番号を決定するステップと、
   前記メディアファイルのファイルリードポインタを、前記メディアサンプルのタイムスタンプに基づき送信すべき前記メディアサンプルの位置に移動するステップと、
   を有する、請求項３記載の方法。
5. 前記シーケンス番号を決定するステップは、
   送信されたメディアパケットの個数を決定するため、前記ＲＴＳＰ状態がプレイに変更されたときのＲＴＰパケットにおけるメディアサンプルのインデックスを減じるステップと、
   前記送信されたメディアパケットの個数を前記ストリーム状態がプレイに変更された後の最初のＲＴＰパケットのシーケンス番号に加えることによって、次に送信されるメディアサンプルを有するＲＴＰパケットのシーケンス番号を決定するステップと、
   を有する、請求項４記載の方法。
6. 前記ファイルリードポインタを移動するステップは、
   前記ＲＴＳＰセッション状態がプレイに変更されたネットワークタイムを現在のネットワークタイムから減じることによって、前記ＲＴＳＰ状態がプレイに変更されてからの経過時間を計算するステップと、
   前記ＲＴＳＰストリーム状態がプレイに変更されたときの最初のＲＴＰパケットにおける前記メディアファイルのサンプルのタイムスタンプに前記経過時間を加えることによって、送信される前記メディアサンプルのタイムスタンプを計算するステップと、
   メディアファイルのファイルリードポインタを、前記送信されるメディアファイルのタイムスタンプに等しいタイムスタンプを有するメディアサンプルのファイル位置に移動するステップと、
   を有する、請求項４記載の方法。
7. 前記ｐｉｎｇするステップは、
   前記プライマリサーバからハートビートメッセージを送出するステップと、
   前記ハートビートメッセージを前記少なくとも１つのバックアップサーバにおいて待機するステップと、
   を有し、
   前記バックアップサーバは、前記ハートビートメッセージを所定時間内に受信できなかったことによって、前記プライマリサーバがアクティブ又は非アクティブであるか判断する、請求項１記載の方法。
8. 前記ｐｉｎｇするステップは、前記プライマリサーバのネットワークトラフィックを前記少なくとも１つのバックアップサーバにおいてモニタするステップを有し、
   前記少なくとも１つのバックアップサーバは、前記バックアップサーバが所定時間内に前記プライマリサーバからのネットワークトラフィックを検出できなかったことによって、前記プライマリサーバがアクティブ又は非アクティブであるか決定する、請求項１記載の方法。
9. 複数のバックアップサーバを有する複数のバックアップサーバクラスタが、複数のプライマリサーバを有する複数のプライマリサーバクラスタをモニタするステップをさらに有し、
   各バックアップサーバクラスタは、１つのプライマリサーバクラスタをモニタする、請求項１記載の方法。
10. ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用して、前記プライマリサーバと前記バックアップサーバとの内部クロックを共通のネットワークタイムに同期させるステップをさらに有する、請求項１記載の方法。
11. クライアントとのストリーミングセッションが開始された後、第１サーバに第２サーバから状態クエリメッセージを送信するステップと、
    前記クライアントとのストリーミングセッションが終了するまで、又は前記状態メッセージが前記第１サーバが非アクティブであることを示すまで、前記第１サーバからの状態メッセージが前記第１サーバがアクティブ状態であることを示した後のある期間、前記状態クエリメッセージの送信を繰り返すステップと、
    前記第１サーバが非アクティブとして報告されると、前記ストリーミングセッションを表すデータを前記第２サーバから前記クライアントに送信するステップと、
    を有するモニタ方法。
12. 前記ストリーミングセッションは、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を送信するＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ストリーミングセッションである、請求項１１記載の方法。
13. 前記第１サーバが非アクティブであると判断すると、前記送信するステップは、前記第１サーバのＲＴＳＰストリーミングセッションを前記第２サーバからのＲＴＳＰストリーミングセッションと置換する、請求項１２記載の方法。
14. 前記移行するステップは、
    前記第２バックアップサーバが、前記第１サーバのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを引き継ぐステップと、
    前記プライマリサーバから前記バックアップサーバにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を移行させるステップと、
    前記第１サーバの少なくとも１つのオープンなストリーミングセッションをループするステップと、
    ＲＴＳＰセッションストリーム状態を導出するステップと、
    前記導出したＲＴＳＰセッションストリーム状態を用いて、前記第２サーバから前記クライアントへのＲＴＳＰセッションストリーミングを再開するステップと、
    を有する、請求項１３記載の方法。
15. １つのプライマリサーバが前記第１サーバである複数のプライマリサーバを有する複数のプライマリサーバクラスタが、１つのバックアップサーバが前記第２サーバである複数のバックアップサーバを有する複数のバックアップサーバクラスタによりモニタされ、
    バックアップサーバクラスタは、少なくとも１つのプライマリサーバクラスタをモニタする、請求項１４記載の方法。
16. 前記第１サーバと前記第２サーバとは、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用して共通のネットワークタイムに同期される内部クロックを有する、請求項１４記載の方法。
17. ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケットを送信するＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ストリームをモニタ及び移行するシステムであって、
    ネットワークを介しメディアファイルを送信するよう構成されるメディアデータベースと、
    少なくとも１つのクライアントからメディアファイルリクエストを受け付け、前記ネットワークを介し前記メディアデータベースからメディアファイルを抽出し、ストリーミングセッションをオープンし、前記リクエストされたメディアファイルのプライマリサーバからクライアントへの転送を開始するよう構成される少なくとも１つのプライマリサーバと、
    前記少なくとも１つのプライマリサーバをモニタし、前記少なくとも１つのプライマリサーバのそれぞれがアクティブ又は非アクティブであるか判断し、非アクティブなプライマリサーバがあるとバックアップサーバが判断すると、前記プライマリサーバのＲＴＳＰストリームを移行させるよう構成される少なくとも１つのバックアップサーバと、
    を有するシステム。
18. 有形に実現されるアプリケーションプログラムを有するプログラム記憶装置であって、
    前記アプリケーションプログラムは、
    プライマリサーバをｐｉｎｇし、
    前記プライマリサーバがアクティブ又は非アクティブであるか判断し、
    前記プライマリサーバがアクティブであると判断すると、所定時間待機し、少なくとも１つのバックアップサーバが前記プライマリサーバのｐｉｎｇを繰り返し、
    前記プライマリサーバが非アクティブであると判断すると、故障している前記プライマリサーバの少なくとも１つのストリーミングセッションをバックアップサーバに移行させる、
    ための命令を有するプログラム記憶装置。
19. 前記移行を実行するための命令はさらに、前記故障しているプライマリサーバの少なくとも１つのＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ストリーミングセッションを前記バックアップサーバに移行させるための命令を有する、請求項１８記載のプログラム記憶装置。
20. 前記移行を実行するための命令はさらに、
    前記プライマリサーバのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを引き継ぎ、
    前記プライマリサーバからＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続を移行させ、
    前記プライマリサーバの少なくとも１つのオープンなストリーミングセッションをループし、
    ＲＴＳＰセッションストリーム状態を導出し、
    前記導出したＲＴＳＰセッションストリーム状態を用いてＲＴＳＰセッションストリーミングを再開する、
    ための命令を有する、請求項１９記載のプログラム記憶装置。
21. 前記判断を実行するための命令はさらに、
    前記プライマリサーバからのハートビート信号を聴取し、
    前記プライマリサーバがアクティブ又は非アクティブであるか、前記ハートビート信号を所定時間内に受信できなかったことによって判断する、
    ための命令を有する、請求項１８記載のプログラム記憶装置。

Images