説明

通信ノードのサーバクラウド化ネットワーク

【課題】ネットワーク内の通信を制御するサーバとリンクを収容するルータとを通信ノードとして構成されるネットワークにおいて、サーバリソースを効率的に使用する。
【解決手段】通信ノードのサーバクラウド化ネットワーク1は、以下の3点を満足するようにして構成される。(1)すべてのサーバ110を仮想化したサーバクラウド100を構築し、サーバクラウド100内のサーバ110用の接続は、ユーザの使用する端末160が接続された回線またはリンクを収容する既存のルータ140とリンクとで構成されたルータ網150を用いて行う。すなわち、クラウド化するために、専用のネットワークを新たに構築しない。(2)サーバクラウド100には、代表アドレスSを設定する。(3)すべてのルータ140は、サーバクラウド100に、代表アドレスSを用いて接続する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワーク内の通信を制御するサーバとリンクを収容するルータとを通信ノードとして構成されるネットワークにおいて、サーバリソースを効率的に使用する技術に関する。
【背景技術】
【0002】
NGN(Next Generation Network)等で扱われるネットワークには、ネットワーク内の通信を制御するサーバとリンクを収容するルータとを通信ノードとして構成するものがある(非特許文献1参照)。
ルータは、ユーザが使用する端末を収容してルーチング制御を実行するとともに、端末から受信した送信先のアドレスをサーバ宛のアドレスに変換したり、登録ユーザ以外からのアクセスを排除したり、伝送路の輻輳制御を実施したりする。また、ルータは、リンクを収容するため、その設置場所が限定されている。
【0003】
サーバは、予め決められた狭いエリア(地域)に設置されている複数のルータと通信可能に接続され、ネットワーク内の通信を制御する。サーバは、例えばネットワークがIP(Internet Protocol)網の場合には、呼制御を行うSIP(Session Initiation Protocol)サーバ、認証を行うRADIUS(Remote Authentication Dial In User Service)サーバ、アドレス解決の役目を果たすDNS(Domain Name System)サーバ、および各種サービスを制御するアプリケーションサーバ等を含んでいる。
また、サーバは、その処理負荷の予測量(短期間の時間変動予測だけでなく中長期的な需要予測も含む)に応じて、予め必要な場所に必要なリソースで設置されている。その際、サーバは、予測される処理負荷の変動に対して対応可能なように、十分な余裕を持つようにリソースが設定される。そのため、サーバのリソースを必ずしも効率的に使用していない状態が発生している。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】笠原英樹,他,「次世代ネットワークを支えるネットワーク基盤技術」,NTT技術ジャーナル,Vol.19,No.4,p.38-43,(2007)
【発明の概要】
【発明が解決しようとする課題】
【0005】
そこで、本発明は、ネットワーク内の通信を制御するサーバとリンクを収容するルータとを通信ノードとして構成されるネットワークにおいて、サーバリソースを効率的に使用することを課題とする。
【課題を解決するための手段】
【0006】
本発明は、ネットワーク内の通信を制御する複数のサーバとリンクを収容する複数のルータとを通信ノードとして構成される通信ノードのサーバクラウド化ネットワークが、複数の前記サーバを仮想化して1つのサーバとして機能し、前記ルータと通信する際に用いる宛先として1つの代表アドレスを設定しているサーバクラウドと、ユーザが使用する端末が接続された回線または前記リンクを収容する前記ルータと前記リンクとによって構築され、前記端末と前記サーバとを通信可能に接続するルータ網とを備えることを特徴とする。
【0007】
このような構成によれば、通信ノードのサーバクラウド化ネットワークは、サーバを仮想化して1つのサーバとして機能するサーバクラウドを備えている。そのため、サーバクラウド内では処理負荷の大きいサーバの処理を他のサーバで分担することが可能となり、サーバリソースを効率的に使用することができる。また、サーバクラウド内のサーバ用の接続には、端末を収容しているルータとリンクとによって構成されるルータ網を用いるので、新たにサーバクラウド内のサーバ用のネットワークを構築する必要がない。そのため、通信ノードのサーバクラウド化ネットワークを構築するためのコストの低減も図ることができる。また、サーバクラウドが1つの代表アドレスを設定しているので、どのルータからも必ずサーバクラウドに接続することが可能となる。
【0008】
また、本発明は、前記通信ノードのサーバクラウド化ネットワークにおいて、前記サーバクラウドが、前記サーバに処理を割り振るロードバランサを備え、前記ロードバランサは、前記代表アドレスを設定していることを特徴とする。
【0009】
このような構成によれば、サーバクラウド内のロードバランサが各サーバに処理を割り振っている。このとき、ロードバランサが各サーバの処理負荷を監視し、サーバクラウド内では処理負荷に応じて処理を負荷の低いサーバに割り振る機能を持てば、サーバリソースを効率的に使用することができる。
【0010】
また、本発明は、前記通信ノードのサーバクラウド化ネットワークにおいて、前記ルータが複数のグループのいずれかに属し、前記グループごとに前記サーバクラウドを備え、各前記サーバクラウドがそれぞれ異なる前記代表アドレスを設定していることを特徴とする。
【0011】
このような構成によれば、複数に分割された通信ノードのサーバクラウド化ネットワークのそれぞれが、異なる事業者によって運営される場合であっても、各サーバクラウド内においては、処理負荷の大きいサーバの処理を他のサーバで分担することが可能となり、サーバリソースを効率的に使用することができる。
【発明の効果】
【0012】
本発明によれば、ネットワーク内の通信を制御するサーバとリンクを収容するルータとを通信ノードとして構成されるネットワークにおいて、サーバリソースを効率的に使用することができる。
【図面の簡単な説明】
【0013】
【図1】現状のネットワークを示す図である。
【図2】本発明の通信ノードのサーバクラウド化ネットワークの概念図を表す図である。
【図3】本実施形態におけるサーバクラウドの構成例を示す図であり、(a)はロードバランサを1台備える場合を表し、(b)はロードバランサを階層構造に備える場合を表す。
【図4】本実施形態のサーバクラウドを地域ごとに備える構成例を示す図である。
【図5】本実施形態のルータの構成例を示す図である。
【図6】本実施形態の通信ノードのサーバクラウド化ネットワークにおいて、SIPサーバにおける端末登録時の処理シーケンス例を示す図である。
【図7】端末登録後のセッション設定のための処理シーケンス例を示す図である。
【発明を実施するための形態】
【0014】
本発明を実施するための形態(以降、「実施形態」と称す。)について、適宜図面を参照しながら詳細に説明する。なお、以降の説明では、ネットワークがIP網で、サーバがSIPサーバの場合を例として説明するが、これに限られず、ネットワークがIPとは異なるプロトコルで、サーバが当該プロトコルに対応してネットワーク内の通信を制御する各種サーバであっても構わない。
【0015】
本実施形態の概要について、図1,2を用いて説明する。図1は、サーバとルータとを通信ノードとして構成される現状のネットワークの一例を表している。また、図2は、本実施形態における通信ノードのサーバクラウド化ネットワークの概念図を表している。なお、図1,2それぞれには、日本地図が記載されているが、日本に限られることは無く、一地域の狭い範囲または世界に跨る広い範囲であっても構わない。
【0016】
図1に示すサーバ110は、ネットワーク内の通信の制御を実行し、ルータ140は、ユーザの使用する端末160およびリンクを収容している。なお、図1に示す現状のネットワークでは、サーバ110およびルータ140は、予め決められた場所に所定のリソースのものが設置されており、固定的に運用されている。そして、ルータ140と、そのルータ140の接続先のサーバ110とは、ペアとして予め決められている。サーバ110は、サーバ110のペアとして決められているルータ140が収容する端末160の登録情報を記憶している。また、端末160は、例えば、PC(Personal Computer)であり、パケットの送受信を行う。なお、図1では、パケットをリンクを介して転送する中継ルータおよび中継サーバについては、記載を省略しているが、この中継ルータもルータ140に含まれ、中継サーバもサーバ110に含まれるものとする。
【0017】
端末160が他の端末160と通信を行うとき、その端末160は、通信を行う前に、予め自分が接続すべきサーバ110に端末160の登録(REGISTER)を行っておく。この時、端末160は、DHCP(Dynamic Host Configuration Protocol)によって、サーバ110のアドレスではなく、ルータ140のアドレスを取得する。そして、ルータ140は、端末160からパケットを受信したとき、受信したパケットの宛先をルータ140のアドレスからサーバ110のアドレスに変換して、当該パケットをサーバ110に送信する。
【0018】
サーバ110は、予測される処理負荷の変動に対して対応可能なように、十分な余裕を持つようにリソースが設定される。そのため、現状のネットワークでは、サーバ110は、必ずしも、そのリソースを効率的に使用していない状態になる。
【0019】
図2は、本実施形態の通信ノードのサーバクラウド化ネットワーク1の概念図を示し、図1と同じ構成には、それぞれ同じ符号を付している。なお、図2では、パケットをリンクを介して転送する中継ルータおよび中継サーバについては、記載を省略しているが、この中継ルータもルータ140に含まれ、中継サーバもサーバ110に含まれるものとする。
【0020】
通信ノードのサーバクラウド化ネットワーク1では、通信ノードのうち、ルータ140はリンクを収容するため、地理的に設置場所が限定されている。しかし、サーバ110は、ネットワーク内の通信を制御するために、ルータ140および他のサーバ110との間で通信が行えられれば、どこに設置されていても構わない。
【0021】
そこで、通信ノードのサーバクラウド化ネットワーク1は、以下の3点を満足するようにして構成する。
(1)すべてのサーバ110を仮想化したクラウド(以降、サーバクラウド100と称する。)を構築し、サーバクラウド100内のサーバ110用の接続は、ユーザの使用する端末160を収容する既存のルータ140とリンクとで構成されたルータ網150を用いて行う。すなわち、クラウド化するために、専用のネットワークを新たに構築しない。
(2)サーバクラウド100には、代表アドレスSを設定する。
(3)すべてのルータ140は、サーバクラウド100に、代表アドレスSを用いて接続する。
【0022】
ここで、サーバ仮想化について、説明する。
サーバを効率良く利用する手段として、1台のサーバ(プロセッサ)に、1つのOS(オペレーティングシステム)やアプリケーションを割り当てるのではなく、例えば、ハイパーバイザというソフトウェアを用いて、1台のサーバ(プロセッサ)を仮想的に同一仕様の複数のサーバ(プロセッサ)に見せかけて、複数のOSやアプリケーションを動作させる技術が用いられている。この技術により、1台のサーバ上で異なる種類のOSを動作させたり、プロセッサの使用効率の低いプログラムを複数動作させたりすることにより、複数のサーバで行っていた処理を1台のサーバで効率良く処理することができる。また、複数のサーバすべてを仮想化し、それらを1つにまとめ、仮想的に大規模な1台のサーバに見せることもできる。
【0023】
すなわち、通信ノードのサーバクラウド化ネットワーク1は、図1の現状のネットワークのように各ルータ140のペアとなるサーバ110を意識することなく、ルータ140のペアであったサーバ110が提供していたサービスを、サーバクラウド100から受ける形態(例えば、SaaS;Software as a Service)をとることができる。なお、SaaSとは、サーバクラウド100の運営者が、サーバ110のリソースだけを提供するのではなく、サーバリソース100上に運営者がOSやアプリケーションをセットアップし、ユーザにそのアプリケーションをネットワークを介して利用可能とするサービスのことである。
【0024】
次に、本実施形態におけるサーバクラウド100の構成例について、図3を用いて説明する。なお、図3(a)はロードバランサを1台備える場合を表し、(b)はロードバランサを階層構造に備える場合を表す。また、図3(a),(b)では、端末160の記載を省略している。
【0025】
図3(a)では、サーバクラウド100は、1台のロードバランサ130と複数のサーバ110で構成される。ロードバランサ130は、ルータ140から受信したパケットに対する応答処理を実行するサーバ110を決定する機能を備える。なお、図3(a)では、ロードバランサ130は1台しか記載していないが、前記したサーバ仮想化の技術を適用することによって、複数台を1台に見せても構わない。
【0026】
ロードバランサ130は、代表アドレスSを設定され、ルータ140からパケットを受信する。そして、ロードバランサ130は、処理を担当させるサーバ110の順番に機械的に割り振り、サーバクラウド100内のいずれのサーバ110に処理を担当させるかを決定する。なお、このサーバ110の決定において、ロードバランサ130は、各サーバ110の処理負荷を考慮して、処理負荷の小さいサーバ110に処理を割り当てるようにしても構わない。また、ロードバランサ130は、受信したパケットを、処理を担当させるサーバ110に送信する。
【0027】
サーバクラウド100内のサーバ110は、端末160に通知するアドレスとして、その端末160を収容しているルータ140のアドレスを用いて、受信したパケットに対応する応答情報を送信する。なお、応答情報の宛先に用いられるアドレスは、サーバ110の代わりにルータ140によって付加されても良い。
また、端末160がサーバクラウド100にアクセスする際には、ルータ140は、端末160から受信したパケットの宛先(ルータ140のアドレス)を、サーバクラウド100の代表アドレスSに変換して、受信したパケットをサーバクラウド100に送信する。なお、当該変換には、例えば、NAT(Network Address Translation)技術を用いても良い。
【0028】
サーバクラウド100内のサーバ110は、端末160の登録情報を記憶しているので、任意の端末160から受信したパケットに対する応答処理を実行できる。
【0029】
次に、ロードバランサを階層構造に備える場合の構成例について、図3(b)を用いて説明する。図3(b)が図3(a)と異なる点は、代表アドレスを設定されたロードバランサ131とサーバ110との間に、さらにロードバランサ132を階層的に備えていることである。ただし、ロードバランサ131,132の機能は、ルータ140から受信したパケットに対する応答処理を実行するサーバ110を決定することである。このロードバランサ132は、ロードバランサ131の負荷を分散するためのものである。なお、ロードバランサ131,132間の配線は、新たに実施される。また、図3(b)では、階層数が2の場合を示しているが、階層数が3以上であっても構わない。また、前記相違点以外の構成については、図3(a)と同様であるので、同じ符号を付し、詳細な説明を省略する。
【0030】
図3(b)では、サーバクラウド100の外部に見えるアドレスはロードバランサ131の代表アドレスSである。したがって、端末160がサーバ110にアクセスする際には、ルータ140は、端末160から受信したパケットの宛先(ルータ140のアドレス)を、サーバクラウド100の代表アドレスSに変換して、受信したパケットをサーバクラウド100に送信すれば良い。なお、ロードバランサ131とロードバランサ132とを組み合わせて、図3(a)に示すような1台のロードバランサの機能を実現しても構わない。
【0031】
次に、本実施形態のサーバクラウド100を地域ごとに備える構成例について、図4を用いて説明する。図4では、地域(グループ)が2つある場合を示している。例えば、東地域と西地域とでネットワークの管理者が異なる場合である。なお、端末160については、記載を省略している。
図4では、ルータ140がいずれかの地域(グループ)に属するように配置される。また、地域(グループ)ごとにサーバクラウド100が構成される。サーバクラウド100内の構成は、図3(a)に示す構成と同様であるので説明を省略する。ただし、各サーバクラウド100のロードバランサ130は、それぞれ異なる代表アドレスS1,S2を設定している。
【0032】
西地域に設置されている端末160がサーバクラウド100にアクセスする際には、ルータ140は、端末160から受信したパケットの宛先(ルータ140のアドレス)を、ロードバランサ130の代表アドレスS1に変換して、受信したパケットをサーバクラウド100に送信する。また、東地域に設置されている端末160がサーバクラウド100にアクセスする際には、ルータ140は、端末160から受信したパケットの宛先(ルータ140のアドレス)を、ロードバランサ130の代表アドレスS2に変換して、受信したパケットをサーバクラウド100に送信する。
なお、図4では、地域(グループ)が2つある場合について説明したが、3以上の地域(グループ)に分かれていても、サーバクラウド100ごとに異なる代表アドレスを設定すれば良い。
【0033】
次に、本実施形態の通信ノードのサーバクラウド化ネットワーク1で用いるルータ140の構成例について、図5を用いて説明する(適宜、図3(a)参照)。
ルータ140は、処理部410、通信部420、および記憶部430を備える。
処理部410は、図示しないCPU(Central Processing Unit)およびメインメモリによって構成され、記憶部430に記憶されているアプリケーションプログラムをメインメモリに展開して、少なくとも、アドレス変換部411の機能を具現化する。また、処理部410は、通信部420および記憶部430におけるデータの送受信等の制御を行う。ただし、処理部410において、ルーチング制御や輻輳制御等の機能については、記載を省略している。
通信部420は、ネットワークに接続するインタフェースであり、端末160、他のルータ140、およびロードバランサ130との間でパケットを送受信する。
記憶部430は、少なくとも、前記アプリケーションプログラムや、サーバクラウド100の代表アドレス431を記憶している。
【0034】
次に、本実施形態の通信ノードのサーバクラウド化ネットワーク1において、SIPサーバにおける端末登録時の処理シーケンス例について、図6を用いて説明する(適宜、図3(a)参照)。
SIPを用いて端末160A,160B間で通信を行う際には、通信を行う前に、予め、端末160A,160Bは自分が接続すべきサーバ110に登録(RESISTER)を行っておく。図6は、その登録の処理シーケンス例を示している。
【0035】
端末160A,160Bは、DHCPによって、それぞれルータ140A,140Bのアドレスを取得する。そして、ルータ140Aは、端末160Aから受信したパケットの宛先アドレスをサーバクラウド100の代表アドレスSに変換して、パケットをサーバクラウド100に送信する。また、ルータ140Bは、端末160Bから受信したパケットの宛先アドレスをサーバクラウド100の代表アドレスSに変換して、パケットをサーバクラウド100に送信する。
【0036】
ステップS501では、端末160Aは、登録(RESISTER)用のパケットをルータ140A(アドレス:R1)に送信する。
ステップS502では、ルータ140Aは、受信したパケットの宛先のアドレスR1をサーバクラウド100の代表アドレスSに変換する。
ステップS503では、ルータ140Aは、端末160Aから受信した登録(RESISTER)用のパケットをサーバクラウド100(アドレス:S)に送信する。
ステップS504では、サーバクラウド100は、登録(RESISTER)用のパケットを受信したことに対する応答情報としてACKを端末160A(アドレス:UA−A)に送信する。
【0037】
また、ステップS511では、端末160Bは、登録(RESISTER)用のパケットをルータ140B(アドレス:R2)に送信する。
ステップS512では、ルータ140Bは、受信したパケットの宛先のアドレスR2をサーバクラウド100の代表アドレスSに変換する。
ステップS513では、ルータ140Bは、端末160Bから受信した登録(RESISTER)用のパケットをサーバクラウド100(アドレス:S)に送信する。
ステップS514では、サーバクラウド100は、登録(RESISTER)用のパケットを受信したことに対する応答情報としてACKを端末160B(アドレス:UA−B)に送信する。
【0038】
次に、端末登録後のセッション設定のための処理シーケンス例について、図7を用いて説明する。
ステップS601では、端末160AがINVITEリクエストをルータ140A(アドレス:R1)に送信する。
ステップS602では、ルータ140Aは、INVITEリクエストを受信し、受信したパケットの宛先のアドレスR1をサーバクラウド100の代表アドレスSに変換する。
ステップS603では、ルータ140Aは、受信したINVITEリクエストをサーバクラウド100(アドレス:S)に送信する。
【0039】
ステップS604では、サーバクラウド100は、INVITEリクエストを端末160B(アドレス:UA−B)に送信する。
また、ステップS605では、サーバクラウド100は、INVITEリクエストを受信して処理中であることを示すレスポンス(Trying)を端末160A(アドレス:UA−A)に返信する。
【0040】
ステップS606では、端末160Bは、呼び出しを行っていることを送信元に知らせるためのレスポンス(Ringing)をルータ140B(アドレス:R2)に送信する。
ステップS607では、ルータ140Bは、受信したレスポンス(Ringing)の宛先のアドレスR2をサーバクラウド100の代表アドレスSに変換する。
ステップS608では、ルータ140Bは、受信したレスポンス(Ringing)をサーバクラウド100(アドレス:S)に送信する。
ステップS609では、サーバクラウド100は、レスポンス(Ringing)を送信元の端末160A(アドレス:UA−A)に送信する。
【0041】
また、ステップS610では、端末160Bは、INVITEリクエストを受信したことを送信元に知らせるためのレスポンス(OK)をルータ140B(アドレス:R2)に返信する。
ステップS611では、ルータ140Bは、受信したレスポンス(OK)の宛先のアドレスR2をサーバクラウド100の代表アドレスSに変換する。
ステップS612では、ルータ140Bは、受信したレスポンス(OK)をサーバクラウド100(アドレス:S)に送信する。
ステップS613では、サーバクラウド100は、レスポンス(OK)を送信元の端末160A(アドレス:UA−A)に送信する。
【0042】
そして、ステップS614では、端末160Aは、レスポンス(OK)を受信したことを確認するためのレスポンス(ACK)を端末160B(アドレス:UA−B)に送信する。
ステップS615では、端末160Aと端末160Bとは、双方の間にセッションを確立し(Media Session)、通信情報を相互に交換する。
【0043】
以上、本実施形態の通信ノードのサーバクラウド化ネットワーク1は、すべてのサーバ110を仮想化してサーバクラウド100を備え、サーバクラウド100内のサーバ110用の接続を、端末160を収容するルータ140とリンクとで構成されたルータ網150を用いて接続する。すなわち、サーバ110のクラウド化のために、専用のネットワークを新たに構築しない。また、サーバクラウド100には、処理負荷を分散させる機能を備えるロードバランサ130を設けて、そのロードバランサ130に代表アドレスSが設定される。したがって、すべてのルータ140は、サーバクラウド100に、代表アドレスSを用いて接続する。そして、サーバクラウド100内のサーバ110は、ロードバランサ130によって、処理負荷を分散することができるので、通信ノードのサーバクラウド化ネットワーク1は、サーバリソースを効率的に使用することが可能となる。また、サーバクラウド100内のサーバ用のネットワークを新たに構築する必要がないので、コストの低減を図ることもできる。
【符号の説明】
【0044】
1 通信ノードのサーバクラウド化ネットワーク
100 サーバクラウド
110 サーバ
130,131,132 ロードバランサ
140 ルータ
150 ルータ網
160 端末
410 処理部
411 アドレス変換部
420 通信部
430 記憶部
431,S,S1,S2 代表アドレス

【特許請求の範囲】
【請求項1】
ネットワーク内の通信を制御する複数のサーバとリンクを収容する複数のルータとを通信ノードとして構成される通信ノードのサーバクラウド化ネットワークであって、
複数の前記サーバを仮想化して1つのサーバとして機能し、前記ルータと通信する際に用いる宛先として1つの代表アドレスを設定しているサーバクラウドと、
ユーザが使用する端末が接続された回線または前記リンクを収容する前記ルータと前記リンクとによって構築され、前記端末と前記サーバとを通信可能に接続するルータ網と
を備えることを特徴とする通信ノードのサーバクラウド化ネットワーク。
【請求項2】
前記サーバクラウドは、
前記サーバに処理を割り振るロードバランサを備え、
前記ロードバランサは、前記代表アドレスを設定している
ことを特徴とする請求項1に記載の通信ノードのサーバクラウド化ネットワーク。
【請求項3】
前記ルータが複数のグループのいずれかに属し、
前記グループごとに前記サーバクラウドを備え、
各前記サーバクラウドがそれぞれ異なる前記代表アドレスを設定している
ことを特徴とする請求項1に記載の通信ノードのサーバクラウド化ネットワーク。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2012−155564(P2012−155564A)
【公開日】平成24年8月16日(2012.8.16)
【国際特許分類】
【出願番号】特願2011−14660(P2011−14660)
【出願日】平成23年1月27日(2011.1.27)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】