JP5513997B2 - 通信システムおよび通信システム更新方法 - Google Patents
通信システムおよび通信システム更新方法 Download PDFInfo
- Publication number
- JP5513997B2 JP5513997B2 JP2010130030A JP2010130030A JP5513997B2 JP 5513997 B2 JP5513997 B2 JP 5513997B2 JP 2010130030 A JP2010130030 A JP 2010130030A JP 2010130030 A JP2010130030 A JP 2010130030A JP 5513997 B2 JP5513997 B2 JP 5513997B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- server cluster
- updated
- application file
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Description
本発明は、通信システムおよび通信システム更新方法に関し、特にネットワーク中の制御ノードからなる通信システム、および制御ノードのファイル更新による通信システム更新方法に関する。
近年、ネットワークサービスの多様化が顕著である。通常、サービス提供事業者は、新サービスを立ち上げる際は、その新サービスの利用者数を事前に明確に把握することが困難であるため、まずは小規模のサーバを用いてサービス提供を開始し、利用者の増加に応じてサーバを増強していくことがコスト面で有効である。このようなサービス提供開始形態をスモールスタートという。
サーバを増強する方法として、性能強化、すなわち、ハードウェアをより性能の高いものに交換する方法（スケールアップという）が従来から行われている。しかし、スケールアップでは、ハードウェアの性能が、ある一定の性能を超える場合にコストが指数関数的に増加してしまう。そのため、近年では、サーバを増強する方法として、性能が高すぎず安価なサーバを追加し（スケールアウトし）、複数のサーバが並列動作すること（これをクラスタという）によって処理を行うことが一般的となりつつある。
ただし、サービスの利用者数の増加時に、速やかにスケールアウトを行うためには、稼働していない予備のサーバを常に待機させておく必要がある。そのような常には使用していない待機サーバを、個々のサービス提供事業者が用意するには高いコストがかかる。
そこで、近年では、データセンタのようなサーバ管理事業者が、一括してサーバを管理し、サービス提供事業者をホスティングするＩａａＳ（Infrastructure as a Service）などと呼ばれる形態が一般化している（非特許文献１参照）。
ＩａａＳでは、個々のサービス提供事業者にとって、サーバのハードウェアメンテナンスが不要であるというメリットがあるだけでなく、複数のサービス提供事業者が待機サーバを共有することにより、サーバ設備維持費の低減が期待できる。
そこで、近年では、データセンタのようなサーバ管理事業者が、一括してサーバを管理し、サービス提供事業者をホスティングするＩａａＳ（Infrastructure as a Service）などと呼ばれる形態が一般化している（非特許文献１参照）。
ＩａａＳでは、個々のサービス提供事業者にとって、サーバのハードウェアメンテナンスが不要であるというメリットがあるだけでなく、複数のサービス提供事業者が待機サーバを共有することにより、サーバ設備維持費の低減が期待できる。
一方、近年では、通信ネットワークにおいて、設備維持費のコスト低減を目的として通信網のＩＰ（Internet Protocol）化が進んでいる。このため、従来の交換機のような専用ハードウェアではなく、汎用サーバを用いて通信ネットワークおよび通信サービスを実現することが一般化している。また、通信サービスにおいても、サービスは多様化しているため、新サービスをスモールスタートし、利用者の拡大に応じてサーバ数をスケールアウトすることにより、設備コストを低減したいという要求がある。
そのような要求に対して、各サービスをスモールスタートし、あるサービスの利用者拡大時に、余剰待機資源が集約されたセンタ（リソースプールという）から必要なサーバを獲得し、スケールアウトを行う構成の適用が考えられる。
Amazon Elastic Compute Cloud (Amazon EC2)、[平成22年4月6日検索]、インターネット<URL:http://aws.amazon.com/ec2/>
しかしながら、例えばＩＰ網を用いた通信ネットワークおよび通信サービスにおいて、複数の汎用的なサーバで、サービス（アプリケーション）を実行する構成、すなわち、汎用的なサーバを用いたスケールアウト構成を、新方式として単純に採用することは困難である。例えば、新方式の通信ネットワークおよび通信サービスにおいて、サービス機能の追加などが発生した場合、従来の設備構成と全く異なるため、従来の設備構成で用いている、プログラムファイルの追加手法や更新手法をそのまま使用することができない。そのため、新たなファイル更新手法が必要である。
また、例えばＩＰ網を用いた通信ネットワークおよび通信サービスを提供する通信事業者には、既存の電話網等の通信ネットワークと同様な高い信頼性が求められており、サービス機能を追加する際には、それまでに提供している既存サービスを中断することなく新規サービスの追加を行うことが望まれている。
本発明は、前記した問題を解決するために成されたものであり、通信ネットワークおよび通信サービスを汎用サーバを用いてスケールアウトした際に既存サービスを無中断でファイル更新できる通信システムおよび通信システム更新方法を提供することを課題とする。
前記目的を達成するために、本発明に係る通信システムは、ユーザサービスネットワークを介してユーザ端末にサービスを提供するノードを備える通信システムであって、前記ノードは、複数のサーバクラスタを備え、前記複数のサーバクラスタそれぞれに、個々のサービスを実現するアプリケーションファイルを配備することで構成され、前記サーバクラスタは、サーバリソースコンポーネントと、ブートイメージとを、予め余剰にプールしたリソースプールから、必要な資源を予め獲得してクラスタリングされて成る複数のサーバが並列動作するＮ重化構成のクラスタをアクティブ側及びスタンバイ側にそれぞれ備え、前記通信システムは、前記ノードとして、所定のサービスを実現する旧バージョンのアプリケーションファイルが配備された第１のノードと、前記所定のサービスを提供できる同種のアプリケーションファイルが配備された第２のノードとを備え、前記第１のノードが、前記所定のサービスへの新機能追加時に、前記旧バージョンのアプリケーションファイルの処理に用いていたデータを前記第２のノードに移動し、前記旧バージョンのアプリケーションファイルを、前記所定のサービスへの新機能を実現する新バージョンのアプリケーションファイルへ更新し、前記アプリケーションファイルの更新終了後に、前記第２のノードから更新中のデータを引き継ぎ、前記第２のノードが、前記第１のノードがアプリケーションファイルを更新している間、前記第１のノードが行うべき処理を代わりに実行して前記所定のサービスを提供することを特徴とする。
また、前記目的を達成するために、本発明に係る通信システム更新方法は、ユーザサービスネットワークを介してユーザ端末にサービスを提供するノードを備える通信システムにおける通信システム更新方法であって、前記ノードは、複数のサーバクラスタを備え、前記複数のサーバクラスタそれぞれに、個々のサービスを実現するアプリケーションファイルを配備することで構成され、前記サーバクラスタは、サーバリソースコンポーネントと、ブートイメージとを、予め余剰にプールしたリソースプールから、必要な資源を予め獲得してクラスタリングされて成る複数のサーバが並列動作するＮ重化構成のクラスタをアクティブ側及びスタンバイ側にそれぞれ備え、前記通信システムは、前記ノードとして、所定のサービスを実現する旧バージョンのアプリケーションファイルが配備された第１のノードと、前記所定のサービスを提供できる同種のアプリケーションファイルが配備された第２のノードとを備え、前記第１のノードが、前記所定のサービスへの新機能追加時に、前記旧バージョンのアプリケーションファイルの処理に用いていたデータを前記第２のノードに移動する移動ステップと、前記旧バージョンのアプリケーションファイルを、前記所定のサービスへの新機能を実現する新バージョンのアプリケーションファイルへ更新する更新ステップとを実行し、前記第２のノードが、前記第１のノードがアプリケーションファイルを更新している間、前記第１のノードが行うべき処理を代わりに実行して前記所定のサービスを提供するサービス提供ステップを実行し、前記第１のノードが、前記アプリケーションファイルの更新終了後に、前記第２のノードから更新中のデータを引き継ぐ引継ステップを実行することを特徴とする。
かかる構成の通信システム、または、かかる手順の通信システム更新方法によれば、通信システムは、各ノードが、リソースプールから獲得された余剰資源をクラスタ構成したサーバクラスタにアプリケーションファイルをデプロイ（配備）することで構成されているので、スモールスタートしたノードにおいて、その提供するサービスの需要増加に伴って、サーバクラスタを追加することで、容易にスケールアウトすることができる。
そして、通信システムは、複数のノードに同種のアプリケーションファイルをデプロイしており、各ノードでサービスを実行する。
そのため、アプリケーションファイル更新によってアプリケーションへ機能を追加する際には、更新対象である第１のノードが、同種のアプリケーションを実行する第２のノードにデータを移動させてから更新処理を行い、かつ、この更新中に第２のノードが第１のノードの肩代わりをして同種のアプリケーションによって既存のサービスを提供するので、追加機能のためのファイル更新をサービス無中断で実現することができる。
そして、通信システムは、複数のノードに同種のアプリケーションファイルをデプロイしており、各ノードでサービスを実行する。
そのため、アプリケーションファイル更新によってアプリケーションへ機能を追加する際には、更新対象である第１のノードが、同種のアプリケーションを実行する第２のノードにデータを移動させてから更新処理を行い、かつ、この更新中に第２のノードが第１のノードの肩代わりをして同種のアプリケーションによって既存のサービスを提供するので、追加機能のためのファイル更新をサービス無中断で実現することができる。
また、本発明に係る通信システムは、前記ノードが、当該ノードを管理統括する管理機能を備え、前記通信システムが、前記ノードを構成する複数のサーバクラスタに対するタスクの振分およびトラフィックの振分を行う振分機能部を備え、前記ノードの管理機能が、更新されたブートイメージを利用した新たなサービス追加時に、当該ノードにおいて既に保持している未更新のサーバクラスタにて処理に用いていたデータを、当該未更新のサーバクラスタと同種のサービスを提供できる同種の外部にある前記ノードまたは当該ノード内部にある他のサーバクラスタに移動し、前記更新されたブートイメージを利用して新たな前記サーバクラスタを組成し、組成された更新済みのサーバクラスタを当該ノードに追加し、当該ノードにおいて前記追加された更新済みのサーバクラスタと、既に保持している未更新のサーバクラスタとを共存させ、前記更新済みのサーバクラスタの安定動作を確認した後で、前記未更新のサーバクラスタを解体して前記リソースプールに戻し、前記振分機能部が、当該ノードの管理機能からの指示に基づいて、当該ノードへのトラフィックを、前記更新済みのサーバクラスタと、前記未更新のサーバクラスタとに振り分けることが好ましい。
また、本発明に係る通信システム更新方法は、前記ノードが、当該ノードを管理統括する管理機能を備え、前記通信システムが、前記ノードを構成する複数のサーバクラスタに対するタスクの振分およびトラフィックの振分を行う振分機能部を備え、前記ノードの管理機能が、更新されたブートイメージを利用した新たなサービス追加時に、当該ノードにおいて既に保持している未更新のサーバクラスタにて処理に用いていたデータを、当該未更新のサーバクラスタと同種のサービスを提供できる同種の外部にある前記ノードまたは当該ノード内部にある他のサーバクラスタに移動する移動ステップと、前記更新されたブートイメージを利用して新たな前記サーバクラスタを組成し、組成された更新済みのサーバクラスタを当該ノードに追加する追加ステップと、当該ノードにおいて前記追加された更新済みのサーバクラスタと、既に保持している未更新のサーバクラスタとを共存させる共存ステップと、前記更新済みのサーバクラスタの安定動作を確認する動作確認ステップと、前記更新済みのサーバクラスタの安定動作を確認した後で、前記未更新のサーバクラスタを解体する解体ステップと、前記解体したコンポーネントを前記リソースプールに戻す返却ステップと、を実行し、前記振分機能部が、前記共存ステップにて、当該ノードの管理機能からの指示に基づいて、当該ノードへのトラフィックを、前記更新済みのサーバクラスタと、前記未更新のサーバクラスタとに振り分けるステップを実行することが好ましい。
かかる構成の通信システム、または、かかる手順の通信システム更新方法によれば、通信システムは、ブートイメージ更新によってノードに新規サービスを追加する際には、ノードの管理機能が、サーバクラスタ毎に更新を行う。このようにサーバクラスタ毎に更新を行うので、更新前に移動させる未更新のサーバクラスタのデータの移動先は、外部のノードの他に、当該ノードの内部の別の未更新のサーバクラスタであってもよい。
また、ブートイメージ更新のファイル更新処理においては、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させているので、デプロイされているアプリケーションファイルは、ブートイメージ更新中に動作し続けることができる。
また、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させているので、ファイル更新状態に合わせて、当該ノードへのトラフィックを各サーバクラスタへ柔軟に振り分けることができる。
さらに、すべてのサーバクラスタを一括して更新することなく、更新をサーバクラスタ毎に行うので、新規サービス用のファイル更新をサービス無中断で実現することができる。
また、ブートイメージ更新のファイル更新処理においては、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させているので、デプロイされているアプリケーションファイルは、ブートイメージ更新中に動作し続けることができる。
また、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させているので、ファイル更新状態に合わせて、当該ノードへのトラフィックを各サーバクラスタへ柔軟に振り分けることができる。
さらに、すべてのサーバクラスタを一括して更新することなく、更新をサーバクラスタ毎に行うので、新規サービス用のファイル更新をサービス無中断で実現することができる。
また、本発明に係る通信システムは、前記ノードの管理機能が、前記新たなサービス追加時に、ファイル更新開始時点から当該ノードの運転監視を開始し、各サーバクラスタにおけるファイル更新状態を把握し、前記更新済みのサーバクラスタの安定動作が予め定められた所定時間に亘って確認できた後に、前記運転監視を解除することが好ましい。
また、本発明に係る通信システム更新方法は、前記ノードの管理機能が、前記新たなサービス追加時に、前記解体ステップの前において、ファイル更新開始時に、当該ノードの運転監視を開始する監視開始ステップと、各サーバクラスタにおけるファイル更新状態を把握する更新状態管理ステップと、前記更新済みのサーバクラスタの安定動作が予め定められた所定時間に亘って確認できた後に、前記運転監視を解除する監視解除ステップとを実行することが好ましい。
かかる構成の通信システム、または、かかる手順の通信システム更新方法によれば、通信システムは、ノードの運転状態を監視し、更新処理の開始時点から、各サーバクラスタにおけるファイル更新状態を把握し、さらに、更新後所定時間の間に、通信システムに何らかの不具合が発生したか確認し続ける。そのため、更新後所定時間の間に不具合が発生しても、対処することが可能であり、サービス無中断を実現することができる。
また、本発明に係る通信システムは、前記ノードの管理機能が、当該ノードの運転監視中に、前記サーバクラスタ内で不具合が発生した場合、当該ノードから、前記更新済みのサーバクラスタを全て切り離し、前記更新前の未更新のサーバクラスタだけで動作させることが好ましい。
また、本発明に係る通信システム更新方法は、前記ノードの管理機能が、当該ノードの運転監視中に、前記サーバクラスタ内で不具合が発生した場合、当該ノードから、前記更新済みのサーバクラスタを全て切り離すステップと、前記更新前の未更新のサーバクラスタだけで動作させるステップとを実行することが好ましい。
かかる構成の通信システム、または、かかる手順の通信システム更新方法によれば、通信システムは、ブートイメージ更新のファイル更新処理において、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させているので、更新後所定時間の間に、更新済みのサーバクラスタ内で不具合が発生したとしても、ノードの管理機能が、更新済みのサーバクラスタから、未更新のクラスタにタスクを移すことで、サービス無中断を実現することができる。
また、本発明に係る通信システムは、前記第１のノードが、前記旧バージョンのアプリケーションファイルを、前記新バージョンのアプリケーションファイルへ更新して、前記新バージョンのアプリケーションファイルの安定動作が予め定められた所定時間に亘って確認できた場合に、前記第２のノードから更新中のデータを引き継ぎ、前記所定時間の間に前記新バージョンのアプリケーションファイルの安定動作が確認できない場合に、前記新バージョンのアプリケーションファイルを配備しなおし、再配備後に、前記新バージョンのアプリケーションファイルの安定動作が確認できた場合に、前記第２のノードから更新中のデータを引き継ぐことが好ましい。
また、本発明に係る通信システム更新方法は、前記第１のノードが、前記旧バージョンのアプリケーションファイルを、前記新バージョンのアプリケーションファイルへ更新する更新ステップを実行し、前記新バージョンのアプリケーションファイルの安定動作が予め定められた所定時間に亘って確認できた場合に、前記第２のノードから更新中のデータを引き継ぎ、前記所定時間の間に前記新バージョンのアプリケーションファイルの安定動作が確認できない場合に、前記新バージョンのアプリケーションファイルを配備しなおすステップと、再配備後に、前記新バージョンのアプリケーションファイルの安定動作が確認できた場合に、前記第２のノードから更新中のデータを引き継ぐステップとを実行することが好ましい。
かかる構成の通信システム、または、かかる手順の通信システム更新方法によれば、通信システムは、アプリケーションファイル更新において、更新前に、データを同種のノードに移動させ、更新中には、このデータ移動先のノードで処理を肩代わりしているので、アプリケーションファイル更新中に不具合が生じたとしても、サービスとして無中断の処理（以下、サービス無中断という）が継続可能である。また、このサービス無中断の処理の間に、更新対象のノードは、ファイル更新状態のステータスを変更してデプロイしなおす処理をすることができるので、安定動作が確認でき次第、データを引き継ぐことができる。
本発明によれば、既存の電話網等の通信ネットワークに求められる高い信頼性や、サービス無中断を維持したまま、新規サービスの追加を行うことができる。
また、本発明によれば、更新対象のノードに所定時間の運転監視状態を持たせることで、新規サービスを追加した直後に不安定な状態になったとしてもサービス無中断を実現することができる。
また、本発明によれば、更新対象のノードに所定時間の運転監視状態を持たせることで、新規サービスを追加した直後に不安定な状態になったとしてもサービス無中断を実現することができる。
さらに、本発明によれば、ブートイメージ更新のファイル更新処理において、更新済みのサーバクラスタと、未更新のサーバクラスタとを共存させることで、運転監視期間中に、更新または追加を行っているファイルに不具合を発見した際に、更新または追加前の状態に即座に戻すことが可能である。また、この場合、新サービス追加時に、新旧サービスに対するデータの参照や追加が発生した際には、それぞれ新旧サービスに対して、その要求を振り分けることが可能である。
図面を参照して本発明の通信システム及びその更新方法を実施するための形態について詳細に説明する。
（第１実施形態）
［通信システムの構成］
図１に示すように、通信システム１は、ユーザに通信サービスを提供するクラスタ構成の複数の制御ノード（以下、単にノードという）２を備えている。ノード２の個数は任意であるが、同じサービスを１つ以上のノード２により提供するものとする。つまり、通信システム１は、スモールスタートした後に、同じ処理を行うノードを追加（スケールアウト）することができるシステムである。この通信システム１は、例えば通信事業者によって運用される。通信サービスの種類は特に限定されないが、例えば、通話等の呼処理のサービスが挙げられる。
［通信システムの構成］
図１に示すように、通信システム１は、ユーザに通信サービスを提供するクラスタ構成の複数の制御ノード（以下、単にノードという）２を備えている。ノード２の個数は任意であるが、同じサービスを１つ以上のノード２により提供するものとする。つまり、通信システム１は、スモールスタートした後に、同じ処理を行うノードを追加（スケールアウト）することができるシステムである。この通信システム１は、例えば通信事業者によって運用される。通信サービスの種類は特に限定されないが、例えば、通話等の呼処理のサービスが挙げられる。
ノード２は、ユーザサービスネットワークＮ1を介してユーザ端末３と接続される。ユーザ端末３は、通信サービスを享受するユーザが使用する端末であって、例えば、有線または無線のネットワーク接続可能な一般的なパーソナルコンピュータ（ＰＣ）や携帯情報端末等から構成される。ユーザサービスネットワークＮ1は、特に限定するものではないが、例えばＩＰネットワークとすることができる。
ノード２と、ユーザサービスネットワークＮ1との間には、ロードバランサ（load balancer：ＬＢ、振分機能部）４が設けられている。ロードバランサ４は、ユーザサービスネットワークＮ1からノード２へのトラフィックやタスクをノード２内のサーバクラスタ９のいずれかに振り分けるものであって、例えば、一般的な負荷分散機能を有した装置である。
ユーザサービスネットワークＮ1には、ノード２以外の制御ノード５も接続されている。制御ノード５は、例えば、ユーザサービスネットワークＮ1におけるルーティング処理、トラフィック監視処理、障害検出時処理等を行うものである。制御ノード５は、例えば、一般的なサーバやルータ等から構成される。
ノード２は、例えば通信事業者の保守ネットワークＮ2を介して、リソースプール６と、リソースプールマネージャ７と、オペレータ端末８と接続されている。
リソースプール６は、ある程度余剰にリソース（資源）が集約されたネットワーク空間を示している。リソースプールに集約されたリソースは、余剰待機資源として活用される。本実施形態では、一例として、日本全国を、九州および沖縄地方、中国および四国地方、近畿地方、北陸および東海地方、関東地方、東北地方、北海道地方の合計７つの地方に区分し、各区分に対応して７つのリソースプール６（６ａ〜６ｇ）が用意されていることとする（図５参照）。
リソースプール６は、ある程度余剰にリソース（資源）が集約されたネットワーク空間を示している。リソースプールに集約されたリソースは、余剰待機資源として活用される。本実施形態では、一例として、日本全国を、九州および沖縄地方、中国および四国地方、近畿地方、北陸および東海地方、関東地方、東北地方、北海道地方の合計７つの地方に区分し、各区分に対応して７つのリソースプール６（６ａ〜６ｇ）が用意されていることとする（図５参照）。
リソースプールマネージャ７は、全国各地に点在したリソースプール６を管理するものであって、例えば、一般的なサーバ等から構成される。
オペレータ端末８は、リソースプールマネージャ７にコマンドを投入するために、例えば通信事業者のオペレータが使用する端末であって、例えば、一般的なＰＣ等から構成される。なお、ユーザ端末３、制御ノード５、リソースプールマネージャ７およびオペレータ端末８の台数は任意である。
オペレータ端末８は、リソースプールマネージャ７にコマンドを投入するために、例えば通信事業者のオペレータが使用する端末であって、例えば、一般的なＰＣ等から構成される。なお、ユーザ端末３、制御ノード５、リソースプールマネージャ７およびオペレータ端末８の台数は任意である。
図１に示すように、ノード２は、リソースプール６から、必要な資源を予め獲得してクラスタリングされた冗長構成のサーバクラスタ９に、個々のサービスを実現するアプリケーションファイルを配備することで構成されており、複数のサーバクラスタ９と、管理機能１０とを備えている。
図２に示すように、リソースプール６は、サーバリソースコンポーネント３０を備えている。サーバリソースコンポーネント３０は余剰にプールされている。
サーバリソースコンポーネント３０とは、ノード２を物理的に組成するものであって、ここでは、ＣＰＵ（Central Processing Unit）、メモリ、ＮＩＣ（Network Interface Card）等がアセンブルされた物理的なサーバのことを示している。図２では、サーバリソースコンポーネント３０の一例として、個別のサーバ３１，３２，３３を図示し、こられを一括してサーバリソースコンポーネント３０と呼称している。
サーバリソースコンポーネント３０とは、ノード２を物理的に組成するものであって、ここでは、ＣＰＵ（Central Processing Unit）、メモリ、ＮＩＣ（Network Interface Card）等がアセンブルされた物理的なサーバのことを示している。図２では、サーバリソースコンポーネント３０の一例として、個別のサーバ３１，３２，３３を図示し、こられを一括してサーバリソースコンポーネント３０と呼称している。
また、本実施形態では、リソースプール６は、ブートイメージ４０も備えている。ブートイメージ４０は余剰にプールされている。ブートイメージ４０とは、ノード２の機能を実現するためのソフトウェアコンポーネントであって、例えば、ＯＳ（Operating System）、ミドルウェア、ライブラリ等を示している。
なお、図２に示したブートイメージ４０の例は、リソースプール６にてプールされた状態を模式的に表したものであり、サーバクラスタ９に対しては、図４に示すようにソフトウェアコンポーネント５０として表される。この場合、サーバクラスタ９は、ソフトウェアコンポーネント５０として、例えば、ＯＳ５１と、ミドルウェア５２と、ライブラリ５３とを備えている。
図２では、ブートイメージ４０の一例として、クラスタサーバ４１と、クラスタＬＢ（load balancer）４２と、クラスタ管理機能４３とを図示した。
クラスタサーバ４１は、サービスを提供するサーバクラスタ９に用いられるソフトウェアコンポーネントをサーバ毎にアセンブルされたイメージファイルである。
クラスタＬＢ４２は、ロードバランサ４に用いられるソフトウェアコンポーネントをロードバランサ毎にアセンブルされたイメージファイルである。
クラスタ管理機能４３は、ノードを管理統括する管理機能１０に用いられるソフトウェアコンポーネントを管理機能毎にアセンブルされたイメージファイルである。
クラスタサーバ４１は、サービスを提供するサーバクラスタ９に用いられるソフトウェアコンポーネントをサーバ毎にアセンブルされたイメージファイルである。
クラスタＬＢ４２は、ロードバランサ４に用いられるソフトウェアコンポーネントをロードバランサ毎にアセンブルされたイメージファイルである。
クラスタ管理機能４３は、ノードを管理統括する管理機能１０に用いられるソフトウェアコンポーネントを管理機能毎にアセンブルされたイメージファイルである。
また、図５では、ブートイメージ４０の一例として、クラスタＥＭＳ４４も図示した。このクラスタＥＭＳ４４は、ノードの動作状態を監視して不具合を検知する図示しない監視検知機能に用いられるソフトウェアコンポーネントをＥＭＳ（Event Monitoring Service）毎にアセンブルされたイメージファイルである。
なお、リソースプール６を、サーバリソースプールと、ブートイメージプールとに分けてもよい。この場合、サーバリソースプールは、サーバリソースコンポーネント３０のみを備え、ブートイメージプールは、ブートイメージ４０のみを備える。
図２に示すように、サーバリソースコンポーネント３０と、ブートイメージ４０とをクラスタリングしたものがサーバクラスタ９に相当する。このサーバクラスタ９は、Ｎ重化構成で実現することができる（Ｎは２以上の整数）。さらに、個々のサービスを実現するアプリケーションファイル２０を、サーバクラスタ９にデプロイ(配備）することで、ノード２を構成している。つまり、図２は、ノード２の階層構造を模式的に示している。
図２に示すサーバクラスタの冗長構成例を図３に示す。
図３（ａ）に示す２重化クラスタ９Ａは、アクティブ側のサーバクラスタ（ACT）と、スタンバイ側のサーバクラスタ（SBY）とが共に２つのサーバを備えている。
図３（ｂ）に示す３重化クラスタ９Ｂは、アクティブ側のサーバクラスタ（ACT）と、スタンバイ側のサーバクラスタ（SBY）とが共に３つのサーバを備えている。
以下では、サーバクラスタ９は、２重化クラスタであるものとして、アクティブ側のサーバのみを図示することとする。
図３（ａ）に示す２重化クラスタ９Ａは、アクティブ側のサーバクラスタ（ACT）と、スタンバイ側のサーバクラスタ（SBY）とが共に２つのサーバを備えている。
図３（ｂ）に示す３重化クラスタ９Ｂは、アクティブ側のサーバクラスタ（ACT）と、スタンバイ側のサーバクラスタ（SBY）とが共に３つのサーバを備えている。
以下では、サーバクラスタ９は、２重化クラスタであるものとして、アクティブ側のサーバのみを図示することとする。
［新規サービスを追加する際のファイル更新手法］
既存サービスを提供しているときに、新規サービスを追加する際には、アプリケーションファイル２０を更新する第１のケースと、ブートイメージ４０を更新する第２のケースと、双方を更新する第３のケースとが想定される。このうち、第３のケースは、第１のケースの処理と、第２のケースの処理とをこの順番で行うか、逆の順序で行うことでファイル更新を行うことができる。以下では、サービス追加時の更新対象箇所として、アプリケーションファイル２０と、ブートイメージ４０との２箇所をそれぞれ独立に説明する。
既存サービスを提供しているときに、新規サービスを追加する際には、アプリケーションファイル２０を更新する第１のケースと、ブートイメージ４０を更新する第２のケースと、双方を更新する第３のケースとが想定される。このうち、第３のケースは、第１のケースの処理と、第２のケースの処理とをこの順番で行うか、逆の順序で行うことでファイル更新を行うことができる。以下では、サービス追加時の更新対象箇所として、アプリケーションファイル２０と、ブートイメージ４０との２箇所をそれぞれ独立に説明する。
［新規サービス追加時の第１のケース］
まず、サービス追加時の１つ目の更新対象箇所として、アプリケーションファイル更新時の動作について、図４を参照（適宜図１参照）して説明する。
前提として、ユーザサービスネットワークＮ1（図１参照）には、ノード２ａと、ノード２ｂとが接続されているものとする。
また、ノード２ａは、例えば、呼処理のサービスを提供するアプリケーションファイル２１「APL ver1.0」のためにデータＤを使用しているものとする。また、ノード２ｂは、アプリケーションファイル２２「APL verx.x」を用いて、ノード２ａと同じサービス（同一アプリケーション）を提供しているノードであるとする。なお、アプリケーションファイル２２「APL verx.x」は、アプリケーションファイル２１「APL ver1.0」でもよいし、それを更新したアプリケーションファイル２３「APL ver2.0」でもよい。以下では、ノード２ａのアプリケーションファイル２１「APL ver1.0」を更新する例を示す。このようにバージョンが同一または異なるアプリケーションを提供するノードのことを、以下では同種のノードと呼ぶ。
まず、サービス追加時の１つ目の更新対象箇所として、アプリケーションファイル更新時の動作について、図４を参照（適宜図１参照）して説明する。
前提として、ユーザサービスネットワークＮ1（図１参照）には、ノード２ａと、ノード２ｂとが接続されているものとする。
また、ノード２ａは、例えば、呼処理のサービスを提供するアプリケーションファイル２１「APL ver1.0」のためにデータＤを使用しているものとする。また、ノード２ｂは、アプリケーションファイル２２「APL verx.x」を用いて、ノード２ａと同じサービス（同一アプリケーション）を提供しているノードであるとする。なお、アプリケーションファイル２２「APL verx.x」は、アプリケーションファイル２１「APL ver1.0」でもよいし、それを更新したアプリケーションファイル２３「APL ver2.0」でもよい。以下では、ノード２ａのアプリケーションファイル２１「APL ver1.0」を更新する例を示す。このようにバージョンが同一または異なるアプリケーションを提供するノードのことを、以下では同種のノードと呼ぶ。
アプリケーション更新時に、更新対象のノードであるノード２ａは、それまでに使用していたデータＤを、外部に掃き出す。ここでは、ノード２ａは、それまでに使用していたデータＤを他の同種のノード２ｂに移動する（ステップＳ１１）。これにより、アプリケーションファイル２０の更新時に無中断でサービスの更新を行うことができる。
ノード２ａは、データＤを移動した後、アプリケーションファイルの更新を行う（ステップＳ１２ａ）。なお、ノード２ａは、サーバクラスタ９において、ＯＳ５１、ミドルウェア５２、ライブラリ５３等のソフトウェアコンポーネント５０に関しては更新がないため、これらのソフトウェアコンポーネント５０に関しては既存のノードをそのまま利用することができる（ステップＳ１２ｂ）。
ノード２ａがアプリケーションファイルを更新している間、データ移動先であるノード２ｂは、トラフィックを肩代わりし、処理を行う（ステップＳ１３）。その後、ノード２ａは、アプリケーションファイル２１「APL ver1.0」を、アプリケーションファイル２３「APL ver2.0」に更新すると、更新終了報告をノード２ｂに通知する。通知を受けたノード２ｂは、更新済みのノード２ａに対して、肩代わりしていたデータを引き継ぐ（ステップＳ１４）。以上の一連の動作により、アプリケーションファイル２０の更新時には、無中断でサービスの更新を行うことができる。
［新規サービス追加時の第２のケース］
次に、サービス追加時の２つ目の更新対象箇所として、ブートイメージ更新時の動作について図５〜図９を参照して説明する。ブートイメージに係る更新処理の概要は、更新対象のブートイメージ４０が更新された後、更新されたブートイメージ４０を利用してサーバクラスタ９を組成し、ノード２に対してクラスタ毎にブートイメージ４０の更新を行う。つまり、ブートイメージ更新時には、大別して、次の３段階の処理がある。第１の段階は、更新対象のブートイメージ４０を更新する段階である（図５参照）。第２の段階は、更新されたブートイメージ４０を利用してサーバクラスタ９を組成する段階である（図６〜７参照）。第３の段階は、更新済みのサーバクラスタと未更新のサーバクラスタとを共存させる段階である（図８〜９参照）。以下、各段階について説明する。
次に、サービス追加時の２つ目の更新対象箇所として、ブートイメージ更新時の動作について図５〜図９を参照して説明する。ブートイメージに係る更新処理の概要は、更新対象のブートイメージ４０が更新された後、更新されたブートイメージ４０を利用してサーバクラスタ９を組成し、ノード２に対してクラスタ毎にブートイメージ４０の更新を行う。つまり、ブートイメージ更新時には、大別して、次の３段階の処理がある。第１の段階は、更新対象のブートイメージ４０を更新する段階である（図５参照）。第２の段階は、更新されたブートイメージ４０を利用してサーバクラスタ９を組成する段階である（図６〜７参照）。第３の段階は、更新済みのサーバクラスタと未更新のサーバクラスタとを共存させる段階である（図８〜９参照）。以下、各段階について説明する。
＜第１の段階：ブートイメージ更新＞
第１の段階では、例えば、図５に示すように全国を複数の地域に区分して、リソースプール６別にブートイメージ４０をサービス無中断で部分的に更新することができる。
なお、本実施形態の場合、ブートイメージ４０の更新は、リソースプール６にて行うので、リソースプール６において、必要に応じてサーバリソースコンポーネント３０の更新も適宜行い、サーバリソースコンポーネント３０をサービス無中断で部分的に更新することができる。
第１の段階では、例えば、図５に示すように全国を複数の地域に区分して、リソースプール６別にブートイメージ４０をサービス無中断で部分的に更新することができる。
なお、本実施形態の場合、ブートイメージ４０の更新は、リソースプール６にて行うので、リソースプール６において、必要に応じてサーバリソースコンポーネント３０の更新も適宜行い、サーバリソースコンポーネント３０をサービス無中断で部分的に更新することができる。
具体的には、第１の段階では、図５に示すように、オペレータは、リソースプールマネージャ７に対して、指定のノード２のアップデートスケジュール等を指示する（ステップＳ１）。そして、リソースプールマネージャ７は、オペレータからの指示をもとに、リソースプール６に対してコマンドを投入する（ステップＳ２）。なお、複雑な指示の場合は、オペレータがリソースプール６に対してコマンドを直接投入する。これにより、各リソースプール６内のブートイメージ４０やサーバリソースコンポーネント３０が更新される。引き続いて、以下に示すように、サーバクラスタ９を更新することでノード２を更新し、その結果として通信システム１を更新する。なお、ブートイメージ４０の更新とは、ソフトウェアコンポーネント５０の更新を含む。
＜第２の段階：サーバクラスタ組成＞
第２の段階において、サーバクラスタ組成のために２つの異なる方法でデータを移動することができる。
≪第１の移動手法：外部のノードにデータ移動≫
更新されたブートイメージを用いて更新対象のサーバクラスタ９を更新する際の第１の移動手法の概念図を図６に示す。図６では、ノード２ａが有するサーバクラスタの一部を更新する例を示している。ノード２ａのサーバクラスタ９は、例えば、呼処理データや保守運用処理のためのデータ（以下、単にデータＤと表記する）を使用しているものとする。また、ノード２ａ，２ｂにおいて、アプリケーションファイル２０は、ブートイメージを用いた更新とは独立に、動作中であるものとする。
第２の段階において、サーバクラスタ組成のために２つの異なる方法でデータを移動することができる。
≪第１の移動手法：外部のノードにデータ移動≫
更新されたブートイメージを用いて更新対象のサーバクラスタ９を更新する際の第１の移動手法の概念図を図６に示す。図６では、ノード２ａが有するサーバクラスタの一部を更新する例を示している。ノード２ａのサーバクラスタ９は、例えば、呼処理データや保守運用処理のためのデータ（以下、単にデータＤと表記する）を使用しているものとする。また、ノード２ａ，２ｂにおいて、アプリケーションファイル２０は、ブートイメージを用いた更新とは独立に、動作中であるものとする。
これらの前提のもと、ノード２ａの更新対象のサーバクラスタ２０１は、ファイル更新を開始する（ステップＳ２１）。ノード２ａの更新対象のサーバクラスタ２０１は、それまでに使用していたデータＤを他の同種のノード２ｂに移動する（ステップＳ２２）。これにより、移動先のノード２ｂのサーバクラスタ２０２で処理を肩代わりしてもらう。
≪第２の移動手法：内部のサーバクラスタにデータ移動≫
更新されたブートイメージを用いて更新対象のサーバクラスタ９を更新する際の第２の移動手法の概念図を図７に示す。図７では、ノード２ａが有するサーバクラスタの一部を更新する例を示している。ノード２ａのサーバクラスタ９は、データＤを使用しているものとする。ノード２ａの更新対象のサーバクラスタ２０１は、ファイル更新を開始する（ステップＳ２１）。ノード２ａの更新対象のサーバクラスタ２０１は、それまでに使用していたデータＤを、ノード２ａ内の他のサーバクラスタ２０３に移動する（ステップＳ２３）。これにより、移動先のサーバクラスタ２０３で処理を肩代わりしてもらう。
更新されたブートイメージを用いて更新対象のサーバクラスタ９を更新する際の第２の移動手法の概念図を図７に示す。図７では、ノード２ａが有するサーバクラスタの一部を更新する例を示している。ノード２ａのサーバクラスタ９は、データＤを使用しているものとする。ノード２ａの更新対象のサーバクラスタ２０１は、ファイル更新を開始する（ステップＳ２１）。ノード２ａの更新対象のサーバクラスタ２０１は、それまでに使用していたデータＤを、ノード２ａ内の他のサーバクラスタ２０３に移動する（ステップＳ２３）。これにより、移動先のサーバクラスタ２０３で処理を肩代わりしてもらう。
＜第３の段階：更新クラスタおよび未更新クラスタの共存段階＞
≪サーバクラスタ共存の概要≫
ブートイメージ４０の更新時には、サーバクラスタ９を組成し直すことでサービスを更新できる。しかしながら、ノード２を構成する既存のすべてのサーバクラスタ９を新たに組成したサーバクラスタ９に単純に一度に置き換えると、サービスを一旦停止しなければならず、動作中のサービスを無停止および無中断にてファイル更新を行うことができない。そこで、本実施形態では、このような問題の対策として、全サーバクラスタ９を同時に切り替えることはせずに、図８に示すように、更新済みサーバクラスタと未更新サーバクラスタとが混在した状態でアプリケーションを動作させることとした。図８は、ファイル更新を行っている最中から更新終了後のサーバクラスタ解体までの流れを示す。
≪サーバクラスタ共存の概要≫
ブートイメージ４０の更新時には、サーバクラスタ９を組成し直すことでサービスを更新できる。しかしながら、ノード２を構成する既存のすべてのサーバクラスタ９を新たに組成したサーバクラスタ９に単純に一度に置き換えると、サービスを一旦停止しなければならず、動作中のサービスを無停止および無中断にてファイル更新を行うことができない。そこで、本実施形態では、このような問題の対策として、全サーバクラスタ９を同時に切り替えることはせずに、図８に示すように、更新済みサーバクラスタと未更新サーバクラスタとが混在した状態でアプリケーションを動作させることとした。図８は、ファイル更新を行っている最中から更新終了後のサーバクラスタ解体までの流れを示す。
この場合、図８に示すように、まず、ノード２ａは、サーバクラスタ３０１を追加する（ステップＳ３１）。すなわち、更新されたブートイメージ４０のソフトウェアコンポーネント５０を用いて新たにサーバクラスタを組成する。なお、サーバリソースコンポーネント３０が更新されたときには、必要に応じて、更新されたサーバリソースコンポーネント３０を用いてクラスタリングする。
続いて、ノード２ａは、サーバクラスタ３０１に加えて、リソースの許す範囲内でサーバクラスタ３０２，３０３を順次追加組成する（ステップＳ３２）。ここで、新しくノード２ａが処理を行うタスクは、更新済みのサーバクラスタ（以下、更新済みのサーバクラスタ９ｂと表記する）で順次行うようにする。ノード２ａは、更新済みのサーバクラスタ９ｂのすべて（サーバクラスタ３０１〜３０３）の安定動作を確認すると（ステップＳ３３）、古いサーバクラスタ（未更新のサーバクラスタ９ａ）を解体する（ステップＳ３４）。つまり、サーバクラスタ９ａは、それぞれクラスタ構成が解除され、コンポーネントである各サーバ（サーバリソースコンポーネント）へ分離され、ソフトウェアコンポーネントは消去される。そして、ノード２ａは、サーバリソースコンポーネントをそれぞれのリソースプール６に戻す（ステップＳ３５）。これにより、リソースプール６に返却された各サーバ（サーバリソースコンポーネント）は、組成可能な余剰資源として待機することとなる。
これにより、全サーバクラスタ９のブートイメージ４０を同時に切り替えず、サーバクラスタ９を順次追加組成し、新しくノード２ａが処理を行うタスクは、更新済みのサーバクラスタ９ｂで行うようにし、更新済みのサーバクラスタ９の安定動作を確認後に古いサーバクラスタ（未更新のサーバクラスタ）９ａを解体、サーバリソースの返却をすることでサービス無中断のファイル更新を行うことが可能になる。なお、ノード２ａは、更新済みのサーバクラスタ３０１〜３０３の安定動作を確認できない場合、その旨をオペレータ等に通知するようにしてもよい。
≪更新中のトラフィックの概要≫
更新済みサーバクラスタと、未更新サーバクラスタとが混在した状態でアプリケーションを動作させているときのトラフィックについて図９を参照して説明する。ユーザサービスネットワークＮ1に対して、ノード２ａの手前に設置されたロードバランサ４は、ノード２ａから、サーバクラスタの更新状況に応じた振分のための制御指示を受け取り（ステップＳ４１）、ＯＫ応答を返す（ステップＳ４２）。これにより、サーバクラスタ９に対するタスク、トラフィックの振分を行うことができる。
更新済みサーバクラスタと、未更新サーバクラスタとが混在した状態でアプリケーションを動作させているときのトラフィックについて図９を参照して説明する。ユーザサービスネットワークＮ1に対して、ノード２ａの手前に設置されたロードバランサ４は、ノード２ａから、サーバクラスタの更新状況に応じた振分のための制御指示を受け取り（ステップＳ４１）、ＯＫ応答を返す（ステップＳ４２）。これにより、サーバクラスタ９に対するタスク、トラフィックの振分を行うことができる。
図９に示す例では、当初は、ロードバランサ４は、ユーザサービスネットワークＮ1からノード２ａへのトラフィックを、未更新のサーバクラスタ９ａにだけ振り分ける。その後、最初に追加されたサーバクラスタが更新済みとなり、更新済みサーバクラスタ９ｂになって動作し始めると、ロードバランサ４は、ノード２ａへのトラフィックのうちの一部であるトラフィック４０２を未更新のサーバクラスタ９ａに振り分けると共に、他の一部のトラフィック４０３を、動作中の更新済みサーバクラスタ９ｂに振り分ける。なお、ロードバランサ４は、組成中のサーバクラスタ４０１に対してはトラフィックを振り分けない。
また、これにより、古いサーバクラスタ（未更新のサーバクラスタ）９ａを解体する前においては、更新済みのサーバクラスタ９ｂと未更新のサーバクラスタ９ａとを共存させているので、新サービス追加時に、新旧サービスに対するデータの参照や追加が発生した際には、それぞれ新旧サービスに対して、ロードバランサ４が、その要求を振り分けることができる。
第１実施形態に係る通信システム１によれば、システム利用者は、新サービスを始める際に、余剰待機資源が集約されたリソースプール６から必要なサーバを獲得し、クラスタ構成としてスケールアウトを行うスモールスタートの構成を取ることで、設備コストを低減できる。
また、第１実施形態に係る通信システム更新方法によれば、通信システム１を構成するノード２の追加機能として新規サービスを追加する際に、既存の通信サービスを無中断でファイル更新することができる。
（第２実施形態）
新規サービスを追加する際のファイル更新手法を用いて、第１実施形態にて説明した第２のケースのようにブートイメージ４０等を更新した直後には、通信システムに何らかの不具合が発生することが想定される。このような場合であっても、サービス無中断を実現する通信システムを第２実施形態として説明する。第２実施形態の通信システムの構成は、第１実施形態と同様なので、構成図を省略し、同じ構成には同じ符号を付して説明を適宜省略する。
新規サービスを追加する際のファイル更新手法を用いて、第１実施形態にて説明した第２のケースのようにブートイメージ４０等を更新した直後には、通信システムに何らかの不具合が発生することが想定される。このような場合であっても、サービス無中断を実現する通信システムを第２実施形態として説明する。第２実施形態の通信システムの構成は、第１実施形態と同様なので、構成図を省略し、同じ構成には同じ符号を付して説明を適宜省略する。
ノード２の管理機能１０（図１参照）は、ブートイメージ４０等のファイルの更新開始時点から、ノード２の運転監視状態に入り、ノード２の各サーバクラスタ９におけるファイル更新状態を把握する。ここで、管理機能１０が把握するファイル更新状態とは、ファイル更新において更新対象のサーバクラスタの現在状態が、「クラスタ組成中」、「未更新」および「更新済み」のいずれの状態であるかを示す情報のことである。ここで、「クラスタ組成中」は、更新処理を開始してから完了するまでの状態を示し、「更新済み」は更新が完了した状態を示す。また、「未更新」は、更新処理を開始する前のリセット状態、または、ステータス「更新済み」が、安定動作が確認されないことに起因して変動してリセットされた状態を意味する。管理機能１０は、ファイル更新状態をサーバクラスタ毎に記録したデータベースを図示しない記憶手段に格納し、順次更新する。
管理機能１０は、ノード２の運転監視により、更新済みのサーバクラスタの安定動作が成功したと判定した場合に運転監視状態を解除する。具体的には、管理機能１０は、ファイル更新状態が「更新済み」の状態として把握されているサーバクラスタの安定動作が、予め定められた所定時間Ｔの間、継続して確認できた場合に運転監視状態を解除する。
一方、管理機能１０は、ノード２の運転監視により、更新済みのサーバクラスタの安定動作が失敗したと判定した場合に、すなわち、サーバクラスタの安定動作が継続して確認できた時間が所定時間Ｔに満たなかった場合に、運転監視状態を解除すると共に、更新済みサーバクラスタがこれまで行っていたタスクを、未更新の古いサーバクラスタに戻す。ここで、このような管理機能１０における追加機能には、クラスタＥＭＳ４４（図５参照）としてイメージファイルにアセンブルされたソフトウェアコンポーネントを用いることができる。なお、これまでの運転監視状態を解除したときに、古いサーバクラスタのタスク処理に係るノード２の運転監視状態に入るようにしてもよい。
具体例として、第２のケースのようにブートイメージ４０等を更新し、更新済みのサーバクラスタおよび未更新のサーバクラスタが共存した第３の段階について図１０を参照して説明する。図１０は、図８と同様にファイル更新を行っている最中から更新終了後のサーバクラスタ解体までの流れを示している。なお、図１０において、図８と同じ動作については同じ処理番号を付して説明を省略する。
この場合、図１０に示すように、ノード２ａは、ステップＳ３１にてサーバクラスタ３０１を追加して組成を始めると、ファイルの更新開始時点から、ノード２ａの管理機能１０が、ノード２ａの運転監視状態に入る（ステップＳ５１）。そして、管理機能１０は、ノード２ａの各サーバクラスタ９におけるファイル更新状態を把握し始める。具体的には、ファイルの更新開始時点では、既存の未更新のサーバクラスタ９ａのファイル更新状態が「未更新」であり、追加されたサーバクラスタ３０１のファイル更新状態が「クラスタ組成中」であることとして把握される。そして、ノード２ａが順次追加したサーバクラスタ３０１〜３０３における更新が終了すると、これら更新済みのサーバクラスタ９ｂのファイル更新状態が「更新済み」であることとして把握される。
そして、管理機能１０は、ノード２ａの運転監視により、更新済みのサーバクラスタ９ｂの安定動作が所定時間Ｔの間確認でき、安定動作が成功したと判定した場合に運転監視状態を解除する（ステップＳ５３）。その後、管理機能１０は、古いサーバクラスタ（未更新のサーバクラスタ９ａ）を解体し（ステップＳ３４）、それぞれのリソースプール６にコンポーネントを戻す（ステップＳ３５）。一方、管理機能１０は、ノード２ａの運転監視により、更新済みのサーバクラスタ９ｂの安定動作が継続して確認できた時間が所定時間Ｔに満たずに、安定動作が失敗したと判定した場合に、即座に元のサービスに戻すと共に、ファイル更新状態「更新済み」を「未更新」にリセットして運転監視状態を解除する。
ブートイメージ４０のファイル更新失敗の具体例として、管理機能１０がノード２ａの運転監視状態中に、更新済みのサーバクラスタ９ｂ内のソフトウェアやハードウェアで不具合が発生した場合の処理について図１１を参照して説明する。なお、図１１において、図１０と同様の構成には同じ符号を付して説明を省略する。図１１に示すように、例えば、ノード２ａの更新済みサーバクラスタ９ｂにて、更新ファイルの不具合が発生したとする（ステップＳ６１）。この場合、ノード２ａの管理機能１０は、ノード２ａから、更新済みのサーバクラスタ９ｂを全て切り離す（ステップＳ６２）。なお、図１１において符号９ｂ１の破線は、更新済みサーバクラスタ９ｂを切り離したことを示している。
そして、ノード２ａの管理機能１０は、ファイル更新前の状態と同じように、未更新のサーバクラスタ９ａのみで動作させる（ステップＳ６３）。これにより、サービス無中断を実現することができる。
そして、ノード２ａの管理機能１０は、ファイル更新前の状態と同じように、未更新のサーバクラスタ９ａのみで動作させる（ステップＳ６３）。これにより、サービス無中断を実現することができる。
第２実施形態の通信システムによれば、ノード２ａの管理機能１０は、ブートイメージ４０の更新後の所定時間Ｔの間に通信システムに何らかの不具合が発生した場合に、即座に元のサービスに戻すことができるので、このような場合であってもサービス無中断を実現することができる。
（第３実施形態）
新規サービスを追加する際のファイル更新手法を用いて、第１実施形態にて説明した第２のケースのようにブートイメージ４０等を更新した後の不具合発生時だけではなく、それに加えて、第１のケースのようにアプリケーションファイル２０の更新を行った後の不具合発生時においても、サービス無中断を実現する通信システムを第３実施形態として説明する。第３実施形態の通信システムの構成は、第２実施形態と同様なので、構成図を省略し、同じ構成には同じ符号を付して説明を適宜省略する。
新規サービスを追加する際のファイル更新手法を用いて、第１実施形態にて説明した第２のケースのようにブートイメージ４０等を更新した後の不具合発生時だけではなく、それに加えて、第１のケースのようにアプリケーションファイル２０の更新を行った後の不具合発生時においても、サービス無中断を実現する通信システムを第３実施形態として説明する。第３実施形態の通信システムの構成は、第２実施形態と同様なので、構成図を省略し、同じ構成には同じ符号を付して説明を適宜省略する。
第３実施形態に係るノード２の管理機能１０（図１参照）は、第２実施形態に係るノード２の管理機能１０と同様であるが、それに加えて、アプリケーションファイル２０に関して以下のように新たな機能が追加されている点が異なる。
管理機能１０は、アプリケーションファイル２０の更新処理を開始した時点から、ノード２の運転監視状態に入り、ノード２におけるアプリケーションファイル２０についてのファイル更新状態を把握する。このファイル更新状態とは、ファイル更新において更新対象のアプリケーションファイルの現在状態が、「未更新」、「更新済み」、「更新中」のいずれの状態であるかを示す情報のことである。ここで、「未更新」は、更新処理を開始する前の状態を示し、「更新済み」は更新が完了した状態を示す。また、「更新中」は、ステータス「更新済み」が、安定動作が確認されないことに起因して変動して一旦リセットされて、更新を再度行う必要があるという状態を意味する。なお、管理機能１０は、アプリケーションファイル２０についてのファイル更新状態を記録したデータベースを図示しない記憶手段に格納し、順次更新する。
管理機能１０は、ノード２の運転監視により、更新済みのアプリケーションファイル２０の安定動作が成功したと判定した場合に運転監視状態を解除する。具体的には、管理機能１０は、更新状態が「更新済み」の状態として把握されているアプリケーションファイル２０の安定動作が、予め定められた所定時間Ｔの間、継続して確認できた場合に運転監視状態を解除し、アプリケーションファイルの更新終了報告を、データ移動先のノード２に通知する。
一方、管理機能１０は、ノード２の運転監視により、更新済みのアプリケーションファイル２０の安定動作が失敗したと判定した場合に、すなわち、アプリケーションファイル２０の安定動作が継続して確認できた時間が所定時間Ｔに満たなかった場合には、アプリケーションファイルの更新終了報告を、データ移動先のノード２に通知せずに、運転監視状態を継続する。ここで、運転監視状態の継続とは、例えば、所定時間Ｔや、所定時間Ｔとは異なる予め定められた所定時間Ｔ0に亘って当該ノード２の運転状態をあらためて監視すると共に、アプリケーションファイル２０の更新状態を「更新済み」から「更新中」に変更することを意味する。
アプリケーションファイル２０のファイル更新失敗の具体例として、管理機能１０がノード２の運転監視状態中（所定時間Ｔ経過以前）に、更新済みのアプリケーションファイル２０で不具合が発生した場合の処理について図１２を参照して説明する。なお、図１２において、図４と同様の構成には同じ符号を付すと共に、図４と同じ動作については同じ処理番号を付して説明を省略する。なお、ノード２ａ，２ｂにおいて管理機能１０の図示を省略する。また、ノード２ａ，２ｂは、同じアプリケーションファイル２１をデプロイされているものとした。
図１２に示すように、例えば、ノード２ａは、アプリケーションファイル２１「APL ver1.0」を、アプリケーションファイル２３「APL ver2.0」に更新した後、所定時間Ｔの間に、更新済みのアプリケーションファイル２３にて不具合が発生したとする（ステップＳ７１）。この場合、アプリケーションファイル２３「APL ver2.0」は、ファイルの更新状態が、「更新済み」から「更新中」に変更される。このようにアプリケーションファイルの現在状態がリセットされて「更新中」の状態になったファイルは、未更新アプリケーションファイルとして扱われる。
そして、ノード２ａの管理機能１０は、この未更新アプリケーションファイル（アプリケーションファイル２３「APL ver2.0」）をデプロイしなおし（ステップＳ７２）、ステップＳ１２ａに戻る。なお、ノード２ａにおいて、アプリケーションファイルをデプロイしなおしている間、データ移動先であるノード２ｂは、更新終了報告を受けていないので、ノード２ａのトラフィックを肩代わりしたまま、引き続き処理を行う（ステップＳ１３）。
そして、ノード２ａの管理機能１０は、アプリケーションファイルをデプロイしなおした後、運転監視状態の継続によって、更新済みのアプリケーションファイル２３「APL ver2.0」の安定動作が成功したと判定した場合に、運転監視状態を解除すると共に、アプリケーションファイルの更新終了報告を、データ移動先のノード２ｂに通知する。ノード２ｂは、通知を受けて安定動作が確認できたら、更新対象のノード２ａに対して、肩代わりしていたデータを引き継ぐ（ステップＳ７３）。
第３実施形態の通信システムによれば、ノード２ａの管理機能１０が、更新済みのアプリケーションファイル２０の所定時間Ｔの監視状態にある場合に、このアプリケーションファイル２０に何らかの不具合が発生したとしても、トラフィックを他のノード２ｂで肩代わりしているため、サービスとして無中断の処理が継続可能である。また、このサービス無中断の間に、更新対象のノード２ａは、ファイル更新状態のステータスを変更してデプロイし直す処理をすることができるので、安定動作が確認でき次第、データを引き継ぐことができる。
以上、本発明の各実施形態について説明したが、本発明はこれらに限定されるものではなく、その趣旨を変えない範囲で実施することができる。例えば、第１実施形態の通信システム１は、アプリケーションファイル２０を更新する機能と、ブートイメージ４０等を更新する機能との双方を有したベストモードとしたが、アプリケーションファイル２０の更新機能だけを備えるようにしてもよい。この場合、ノード２の前段にロードバランサ４を必ずしも設ける必要はない。このような構成としても、アプリケーションファイル２０の更新により既存サービスを提供しているときに、サービス無中断で新規サービスを追加することができる。
１ 通信システム
２ ノード（制御ノード）
２ａ ノード（第１のノード）
２ｂ ノード（第２のノード）
３ ユーザ端末
４ ロードバランサ（振分機能部）
５ 制御ノード
６（６ａ〜６ｇ） リソースプール
７ リソースプールマネージャ
８ オペレータ端末
９ サーバクラスタ
１０ 管理機能
２０，２１，２２，２３ アプリケーションファイル
３０ サーバリソースコンポーネント
３１，３２，３３ サーバ
４０ ブートイメージ
４１ クラスタサーバ
４２ クラスタＬＢ
４３ クラスタ管理機能
４４ クラスタＥＭＳ
５０ ソフトウェアコンポーネント
５１ ＯＳ
５２ ミドルウェア
５３ ライブラリ
２ ノード（制御ノード）
２ａ ノード（第１のノード）
２ｂ ノード（第２のノード）
３ ユーザ端末
４ ロードバランサ（振分機能部）
５ 制御ノード
６（６ａ〜６ｇ） リソースプール
７ リソースプールマネージャ
８ オペレータ端末
９ サーバクラスタ
１０ 管理機能
２０，２１，２２，２３ アプリケーションファイル
３０ サーバリソースコンポーネント
３１，３２，３３ サーバ
４０ ブートイメージ
４１ クラスタサーバ
４２ クラスタＬＢ
４３ クラスタ管理機能
４４ クラスタＥＭＳ
５０ ソフトウェアコンポーネント
５１ ＯＳ
５２ ミドルウェア
５３ ライブラリ
Claims (10)
- ユーザサービスネットワークを介してユーザ端末にサービスを提供するノードを備える通信システムであって、
前記ノードは、複数のサーバクラスタを備え、前記複数のサーバクラスタそれぞれに、個々のサービスを実現するアプリケーションファイルを配備することで構成され、
前記サーバクラスタは、サーバリソースコンポーネントと、ブートイメージとを、予め余剰にプールしたリソースプールから、必要な資源を予め獲得してクラスタリングされて成る複数のサーバが並列動作するＮ重化構成のクラスタをアクティブ側及びスタンバイ側にそれぞれ備え、
前記通信システムは、前記ノードとして、所定のサービスを実現する旧バージョンのアプリケーションファイルが配備された第１のノードと、前記所定のサービスを提供できる同種のアプリケーションファイルが配備された第２のノードとを備え、
前記第１のノードは、
前記所定のサービスへの新機能追加時に、前記旧バージョンのアプリケーションファイルの処理に用いていたデータを前記第２のノードに移動し、
前記旧バージョンのアプリケーションファイルを、前記所定のサービスへの新機能を実現する新バージョンのアプリケーションファイルへ更新し、
前記アプリケーションファイルの更新終了後に、前記第２のノードから更新中のデータを引き継ぎ、
前記第２のノードは、前記第１のノードがアプリケーションファイルを更新している間、前記第１のノードが行うべき処理を代わりに実行して前記所定のサービスを提供する
ことを特徴とする通信システム。 - 前記ノードは、当該ノードを管理統括する管理機能を備え、
前記通信システムは、前記ノードを構成する複数のサーバクラスタに対するタスクの振分およびトラフィックの振分を行う振分機能部を備え、
前記ノードの管理機能は、
更新されたブートイメージを利用した新たなサービス追加時に、当該ノードにおいて既に保持している未更新のサーバクラスタにて処理に用いていたデータを、当該未更新のサーバクラスタと同種のサービスを提供できる同種の外部にある前記ノードまたは当該ノード内部にある他のサーバクラスタに移動し、前記更新されたブートイメージを利用して新たな前記サーバクラスタを組成し、組成された更新済みのサーバクラスタを当該ノードに追加し、当該ノードにおいて前記追加された更新済みのサーバクラスタと、既に保持している未更新のサーバクラスタとを共存させ、前記更新済みのサーバクラスタの安定動作を確認した後で、前記未更新のサーバクラスタを解体して前記リソースプールに戻し、
前記振分機能部は、当該ノードの管理機能からの指示に基づいて、当該ノードへのトラフィックを、前記更新済みのサーバクラスタと、前記未更新のサーバクラスタとに振り分ける
ことを特徴とする請求項１に記載の通信システム。 - 前記ノードの管理機能は、
前記新たなサービス追加時に、ファイル更新開始時点から当該ノードの運転監視を開始し、各サーバクラスタにおけるファイル更新状態を把握し、前記更新済みのサーバクラスタの安定動作が予め定められた所定時間に亘って確認できた後に、前記運転監視を解除する
ことを特徴とする請求項２に記載の通信システム。 - 前記ノードの管理機能は、
当該ノードの運転監視中に、前記サーバクラスタ内で不具合が発生した場合、当該ノードから、前記更新済みのサーバクラスタを全て切り離し、前記更新前の未更新のサーバクラスタだけで動作させる
ことを特徴とする請求項３に記載の通信システム。 - 前記第１のノードは、
前記旧バージョンのアプリケーションファイルを、前記新バージョンのアプリケーションファイルへ更新して、前記新バージョンのアプリケーションファイルの安定動作が予め定められた所定時間に亘って確認できた場合に、前記第２のノードから更新中のデータを引き継ぎ、
前記所定時間の間に前記新バージョンのアプリケーションファイルの安定動作が確認できない場合に、前記新バージョンのアプリケーションファイルを配備しなおし、再配備後に、前記新バージョンのアプリケーションファイルの安定動作が確認できた場合に、前記第２のノードから更新中のデータを引き継ぐ
ことを特徴とする請求項１ないし請求項４のいずれか一項に記載の通信システム。 - ユーザサービスネットワークを介してユーザ端末にサービスを提供するノードを備える通信システムにおける通信システム更新方法であって、
前記ノードは、複数のサーバクラスタを備え、前記複数のサーバクラスタそれぞれに、個々のサービスを実現するアプリケーションファイルを配備することで構成され、
前記サーバクラスタは、サーバリソースコンポーネントと、ブートイメージとを、予め余剰にプールしたリソースプールから、必要な資源を予め獲得してクラスタリングされて成る複数のサーバが並列動作するＮ重化構成のクラスタをアクティブ側及びスタンバイ側にそれぞれ備え、
前記通信システムは、前記ノードとして、所定のサービスを実現する旧バージョンのアプリケーションファイルが配備された第１のノードと、前記所定のサービスを提供できる同種のアプリケーションファイルが配備された第２のノードとを備え、
前記第１のノードは、
前記所定のサービスへの新機能追加時に、前記旧バージョンのアプリケーションファイルの処理に用いていたデータを前記第２のノードに移動する移動ステップと、
前記旧バージョンのアプリケーションファイルを、前記所定のサービスへの新機能を実現する新バージョンのアプリケーションファイルへ更新する更新ステップとを実行し、
前記第２のノードは、
前記第１のノードがアプリケーションファイルを更新している間、前記第１のノードが行うべき処理を代わりに実行して前記所定のサービスを提供するサービス提供ステップを実行し、
前記第１のノードは、
前記アプリケーションファイルの更新終了後に、前記第２のノードから更新中のデータを引き継ぐ引継ステップを実行する
ことを特徴とする通信システム更新方法。 - 前記ノードは、当該ノードを管理統括する管理機能を備え、
前記通信システムは、前記ノードを構成する複数のサーバクラスタに対するタスクの振分およびトラフィックの振分を行う振分機能部を備え、
前記ノードの管理機能は、
更新されたブートイメージを利用した新たなサービス追加時に、当該ノードにおいて既に保持している未更新のサーバクラスタにて処理に用いていたデータを、当該未更新のサーバクラスタと同種のサービスを提供できる同種の外部にある前記ノードまたは当該ノード内部にある他のサーバクラスタに移動する移動ステップと、
前記更新されたブートイメージを利用して新たな前記サーバクラスタを組成し、組成された更新済みのサーバクラスタを当該ノードに追加する追加ステップと、
当該ノードにおいて前記追加された更新済みのサーバクラスタと、既に保持している未更新のサーバクラスタとを共存させる共存ステップと、
前記更新済みのサーバクラスタの安定動作を確認する動作確認ステップと、
前記更新済みのサーバクラスタの安定動作を確認した後で、前記未更新のサーバクラスタを解体する解体ステップと、
前記解体したコンポーネントを前記リソースプールに戻す返却ステップと、を実行し、
前記振分機能部は、
前記共存ステップにて、当該ノードの管理機能からの指示に基づいて、当該ノードへのトラフィックを、前記更新済みのサーバクラスタと、前記未更新のサーバクラスタとに振り分けるステップを実行する
ことを特徴とする請求項６に記載の通信システム更新方法。 - 前記ノードの管理機能は、
前記新たなサービス追加時に、前記解体ステップの前において、
ファイル更新開始時に、当該ノードの運転監視を開始する監視開始ステップと、
各サーバクラスタにおけるファイル更新状態を把握する更新状態管理ステップと、
前記更新済みのサーバクラスタの安定動作が予め定められた所定時間に亘って確認できた後に、前記運転監視を解除する監視解除ステップとを実行する
ことを特徴とする請求項７に記載の通信システム更新方法。 - 前記ノードの管理機能は、
当該ノードの運転監視中に、前記サーバクラスタ内で不具合が発生した場合、当該ノードから、前記更新済みのサーバクラスタを全て切り離すステップと、
前記更新前の未更新のサーバクラスタだけで動作させるステップとを実行することを特徴とする請求項８に記載の通信システム更新方法。 - 前記第１のノードは、
前記旧バージョンのアプリケーションファイルを、前記新バージョンのアプリケーションファイルへ更新する更新ステップを実行し、
前記新バージョンのアプリケーションファイルの安定動作が予め定められた所定時間に亘って確認できた場合に、前記第２のノードから更新中のデータを引き継ぎ、
前記所定時間の間に前記新バージョンのアプリケーションファイルの安定動作が確認できない場合に、前記新バージョンのアプリケーションファイルを配備しなおすステップと、
再配備後に、前記新バージョンのアプリケーションファイルの安定動作が確認できた場合に、前記第２のノードから更新中のデータを引き継ぐステップとを実行することを特徴とする請求項６ないし請求項９のいずれか一項に記載の通信システム更新方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010130030A JP5513997B2 (ja) | 2010-06-07 | 2010-06-07 | 通信システムおよび通信システム更新方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010130030A JP5513997B2 (ja) | 2010-06-07 | 2010-06-07 | 通信システムおよび通信システム更新方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2011257847A JP2011257847A (ja) | 2011-12-22 |
| JP5513997B2 true JP5513997B2 (ja) | 2014-06-04 |
Family
ID=45473994
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010130030A Active JP5513997B2 (ja) | 2010-06-07 | 2010-06-07 | 通信システムおよび通信システム更新方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5513997B2 (ja) |
Families Citing this family (75)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9081964B2 (en) * | 2012-12-27 | 2015-07-14 | General Electric Company | Firmware upgrade error detection and automatic rollback |
| US9961011B2 (en) | 2014-01-21 | 2018-05-01 | Oracle International Corporation | System and method for supporting multi-tenancy in an application server, cloud, or other environment |
| US9405530B2 (en) | 2014-09-24 | 2016-08-02 | Oracle International Corporation | System and method for supporting patching in a multitenant application server environment |
| US10318280B2 (en) | 2014-09-24 | 2019-06-11 | Oracle International Corporation | System and method for supporting patching in a multitenant application server environment |
| US9715402B2 (en) | 2014-09-30 | 2017-07-25 | Amazon Technologies, Inc. | Dynamic code deployment and versioning |
| US9600312B2 (en) | 2014-09-30 | 2017-03-21 | Amazon Technologies, Inc. | Threading as a service |
| US9678773B1 (en) | 2014-09-30 | 2017-06-13 | Amazon Technologies, Inc. | Low latency computational capacity provisioning |
| US9323556B2 (en) | 2014-09-30 | 2016-04-26 | Amazon Technologies, Inc. | Programmatic event detection and message generation for requests to execute program code |
| US10048974B1 (en) | 2014-09-30 | 2018-08-14 | Amazon Technologies, Inc. | Message-based computation request scheduling |
| US9830193B1 (en) | 2014-09-30 | 2017-11-28 | Amazon Technologies, Inc. | Automatic management of low latency computational capacity |
| US9146764B1 (en) | 2014-09-30 | 2015-09-29 | Amazon Technologies, Inc. | Processing event messages for user requests to execute program code |
| US9537788B2 (en) | 2014-12-05 | 2017-01-03 | Amazon Technologies, Inc. | Automatic determination of resource sizing |
| US9733967B2 (en) | 2015-02-04 | 2017-08-15 | Amazon Technologies, Inc. | Security protocols for low latency execution of program code |
| US9588790B1 (en) | 2015-02-04 | 2017-03-07 | Amazon Technologies, Inc. | Stateful virtual compute system |
| US9930103B2 (en) | 2015-04-08 | 2018-03-27 | Amazon Technologies, Inc. | Endpoint management system providing an application programming interface proxy service |
| US9785476B2 (en) | 2015-04-08 | 2017-10-10 | Amazon Technologies, Inc. | Endpoint management system and virtual compute system |
| US9811434B1 (en) | 2015-12-16 | 2017-11-07 | Amazon Technologies, Inc. | Predictive management of on-demand code execution |
| US10013267B1 (en) | 2015-12-16 | 2018-07-03 | Amazon Technologies, Inc. | Pre-triggers for code execution environments |
| US10754701B1 (en) | 2015-12-16 | 2020-08-25 | Amazon Technologies, Inc. | Executing user-defined code in response to determining that resources expected to be utilized comply with resource restrictions |
| US10067801B1 (en) | 2015-12-21 | 2018-09-04 | Amazon Technologies, Inc. | Acquisition and maintenance of compute capacity |
| US9910713B2 (en) | 2015-12-21 | 2018-03-06 | Amazon Technologies, Inc. | Code execution request routing |
| US11132213B1 (en) | 2016-03-30 | 2021-09-28 | Amazon Technologies, Inc. | Dependency-based process of pre-existing data sets at an on demand code execution environment |
| US10891145B2 (en) | 2016-03-30 | 2021-01-12 | Amazon Technologies, Inc. | Processing pre-existing data sets at an on demand code execution environment |
| CN109075994B (zh) * | 2016-04-28 | 2022-04-05 | 斯诺弗雷克公司 | 多集群仓库 |
| US10282229B2 (en) | 2016-06-28 | 2019-05-07 | Amazon Technologies, Inc. | Asynchronous task management in an on-demand network code execution environment |
| US10102040B2 (en) | 2016-06-29 | 2018-10-16 | Amazon Technologies, Inc | Adjusting variable limit on concurrent code executions |
| US10277708B2 (en) | 2016-06-30 | 2019-04-30 | Amazon Technologies, Inc. | On-demand network code execution with cross-account aliases |
| US10203990B2 (en) | 2016-06-30 | 2019-02-12 | Amazon Technologies, Inc. | On-demand network code execution with cross-account aliases |
| US10884787B1 (en) | 2016-09-23 | 2021-01-05 | Amazon Technologies, Inc. | Execution guarantees in an on-demand network code execution system |
| US10061613B1 (en) | 2016-09-23 | 2018-08-28 | Amazon Technologies, Inc. | Idempotent task execution in on-demand network code execution systems |
| US11119813B1 (en) | 2016-09-30 | 2021-09-14 | Amazon Technologies, Inc. | Mapreduce implementation using an on-demand network code execution system |
| US11237814B2 (en) | 2017-08-17 | 2022-02-01 | Oracle International Corporation | System and method for supporting custom hooks during patching in an application server environment |
| US10564946B1 (en) | 2017-12-13 | 2020-02-18 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
| US10733085B1 (en) | 2018-02-05 | 2020-08-04 | Amazon Technologies, Inc. | Detecting impedance mismatches due to cross-service calls |
| US10831898B1 (en) | 2018-02-05 | 2020-11-10 | Amazon Technologies, Inc. | Detecting privilege escalations in code including cross-service calls |
| US10353678B1 (en) | 2018-02-05 | 2019-07-16 | Amazon Technologies, Inc. | Detecting code characteristic alterations due to cross-service calls |
| US10725752B1 (en) | 2018-02-13 | 2020-07-28 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
| US10776091B1 (en) | 2018-02-26 | 2020-09-15 | Amazon Technologies, Inc. | Logging endpoint in an on-demand code execution system |
| US10853115B2 (en) | 2018-06-25 | 2020-12-01 | Amazon Technologies, Inc. | Execution of auxiliary functions in an on-demand network code execution system |
| US10649749B1 (en) | 2018-06-26 | 2020-05-12 | Amazon Technologies, Inc. | Cross-environment application of tracing information for improved code execution |
| US11146569B1 (en) | 2018-06-28 | 2021-10-12 | Amazon Technologies, Inc. | Escalation-resistant secure network services using request-scoped authentication information |
| US10949237B2 (en) | 2018-06-29 | 2021-03-16 | Amazon Technologies, Inc. | Operating system customization in an on-demand network code execution system |
| US11099870B1 (en) | 2018-07-25 | 2021-08-24 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
| US11243953B2 (en) | 2018-09-27 | 2022-02-08 | Amazon Technologies, Inc. | Mapreduce implementation in an on-demand network code execution system and stream data processing system |
| US11099917B2 (en) | 2018-09-27 | 2021-08-24 | Amazon Technologies, Inc. | Efficient state maintenance for execution environments in an on-demand code execution system |
| US11943093B1 (en) | 2018-11-20 | 2024-03-26 | Amazon Technologies, Inc. | Network connection recovery after virtual machine transition in an on-demand network code execution system |
| US10884812B2 (en) | 2018-12-13 | 2021-01-05 | Amazon Technologies, Inc. | Performance-based hardware emulation in an on-demand network code execution system |
| US11010188B1 (en) | 2019-02-05 | 2021-05-18 | Amazon Technologies, Inc. | Simulated data object storage using on-demand computation of data objects |
| US11861386B1 (en) | 2019-03-22 | 2024-01-02 | Amazon Technologies, Inc. | Application gateways in an on-demand network code execution system |
| US11119809B1 (en) | 2019-06-20 | 2021-09-14 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
| US11159528B2 (en) | 2019-06-28 | 2021-10-26 | Amazon Technologies, Inc. | Authentication to network-services using hosted authentication information |
| US11115404B2 (en) | 2019-06-28 | 2021-09-07 | Amazon Technologies, Inc. | Facilitating service connections in serverless code executions |
| US11190609B2 (en) | 2019-06-28 | 2021-11-30 | Amazon Technologies, Inc. | Connection pooling for scalable network services |
| US11023311B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | On-demand code execution in input path of data uploaded to storage service in multiple data portions |
| US11263220B2 (en) | 2019-09-27 | 2022-03-01 | Amazon Technologies, Inc. | On-demand execution of object transformation code in output path of object storage service |
| US11023416B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | Data access control system for object storage service based on owner-defined code |
| US11416628B2 (en) | 2019-09-27 | 2022-08-16 | Amazon Technologies, Inc. | User-specific data manipulation system for object storage service based on user-submitted code |
| US11656892B1 (en) | 2019-09-27 | 2023-05-23 | Amazon Technologies, Inc. | Sequential execution of user-submitted code and native functions |
| US10996961B2 (en) | 2019-09-27 | 2021-05-04 | Amazon Technologies, Inc. | On-demand indexing of data in input path of object storage service |
| US10908927B1 (en) | 2019-09-27 | 2021-02-02 | Amazon Technologies, Inc. | On-demand execution of object filter code in output path of object storage service |
| US11386230B2 (en) | 2019-09-27 | 2022-07-12 | Amazon Technologies, Inc. | On-demand code obfuscation of data in input path of object storage service |
| US11250007B1 (en) | 2019-09-27 | 2022-02-15 | Amazon Technologies, Inc. | On-demand execution of object combination code in output path of object storage service |
| US11055112B2 (en) | 2019-09-27 | 2021-07-06 | Amazon Technologies, Inc. | Inserting executions of owner-specified code into input/output path of object storage service |
| US11394761B1 (en) | 2019-09-27 | 2022-07-19 | Amazon Technologies, Inc. | Execution of user-submitted code on a stream of data |
| US11106477B2 (en) | 2019-09-27 | 2021-08-31 | Amazon Technologies, Inc. | Execution of owner-specified code during input/output path to object storage service |
| US11360948B2 (en) | 2019-09-27 | 2022-06-14 | Amazon Technologies, Inc. | Inserting owner-specified data processing pipelines into input/output path of object storage service |
| US11550944B2 (en) | 2019-09-27 | 2023-01-10 | Amazon Technologies, Inc. | Code execution environment customization system for object storage service |
| US10942795B1 (en) | 2019-11-27 | 2021-03-09 | Amazon Technologies, Inc. | Serverless call distribution to utilize reserved capacity without inhibiting scaling |
| US11119826B2 (en) | 2019-11-27 | 2021-09-14 | Amazon Technologies, Inc. | Serverless call distribution to implement spillover while avoiding cold starts |
| US11714682B1 (en) | 2020-03-03 | 2023-08-01 | Amazon Technologies, Inc. | Reclaiming computing resources in an on-demand code execution system |
| US11188391B1 (en) | 2020-03-11 | 2021-11-30 | Amazon Technologies, Inc. | Allocating resources to on-demand code executions under scarcity conditions |
| US11775640B1 (en) | 2020-03-30 | 2023-10-03 | Amazon Technologies, Inc. | Resource utilization-based malicious task detection in an on-demand code execution system |
| US11593270B1 (en) | 2020-11-25 | 2023-02-28 | Amazon Technologies, Inc. | Fast distributed caching using erasure coded object parts |
| US11550713B1 (en) | 2020-11-25 | 2023-01-10 | Amazon Technologies, Inc. | Garbage collection in distributed systems using life cycled storage roots |
| US11388210B1 (en) | 2021-06-30 | 2022-07-12 | Amazon Technologies, Inc. | Streaming analytics using a serverless compute system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4158517B2 (ja) * | 2002-12-25 | 2008-10-01 | 富士通株式会社 | マルチプロセッサ装置の共有データアクセス方式 |
| JP4870915B2 (ja) * | 2004-07-15 | 2012-02-08 | 株式会社日立製作所 | ストレージ装置 |
| WO2006040810A1 (ja) * | 2004-10-12 | 2006-04-20 | Fujitsu Limited | ソフトウェア更新プログラム、ソフトウェア更新装置およびソフトウェア更新方法 |
-
2010
- 2010-06-07 JP JP2010130030A patent/JP5513997B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2011257847A (ja) | 2011-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5513997B2 (ja) | 通信システムおよび通信システム更新方法 | |
| CN108475251B (zh) | 针对容器的虚拟网络、热交换、热缩放与灾难恢复 | |
| CN112099918A (zh) | 容器化环境中的集群的实时迁移 | |
| US7716373B2 (en) | Method, apparatus, and computer product for updating software | |
| US9529582B2 (en) | Modular architecture for distributed system management | |
| KR20160136489A (ko) | 클라우드 서비스를 위한 가상화 기반 자원 관리 방법 | |
| CN115665147A (zh) | 分布式计算网络中的数据平面api | |
| JP2019144717A (ja) | サービス提供システム、資源割り当て方法、及び資源割り当てプログラム | |
| JP2019032686A (ja) | 管理装置、管理装置の制御方法、及びプログラム | |
| CN113824723A (zh) | 一种应用于音视频数据传输的端到端系统解决方法 | |
| JP4167643B2 (ja) | 業務システムの運用方法、運用管理システムおよび運用プログラム | |
| JP5667506B2 (ja) | クラスタシステムおよびソフトウェアアップデート方法 | |
| KR20140061534A (ko) | 확장가능 분산 멀티클러스터 장치 관리 서버 아키텍처 및 그 동작 방법 | |
| CN106534758B (zh) | 会议备份方法和装置 | |
| CN115391058B (zh) | 一种基于sdn的资源事件处理方法、资源创建方法及系统 | |
| CN109936462B (zh) | 容灾方法及装置 | |
| JP5632403B2 (ja) | タスク管理システム、タスク管理サーバ、タスク管理方法、及びタスク管理プログラム | |
| JP4034201B2 (ja) | 計算機資源利用方式及び計算機資源利用方法 | |
| JP2001216174A (ja) | アプリケーション代替方法及びアプリケーション代替プログラムを格納した記憶媒体 | |
| JP7135489B2 (ja) | 分散処理システムに用いられるサーバ装置、分散処理方法およびプログラム | |
| CN111338647A (zh) | 一种大数据集群管理方法和装置 | |
| JP2018073099A (ja) | スケールイン処理プログラム、スケールイン処理方法および情報処理システム | |
| JP2013003982A (ja) | 負荷分散システム、負荷分散装置およびサーバ装置 | |
| WO2023032106A1 (ja) | ジョブ管理システム及びその制御方法 | |
| JP4123440B2 (ja) | オブジェクト指向のネットワーク分散型コンピューティングシステム、その負荷分散装置及びサーバ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120828 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20130201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130531 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130910 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20131106 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140325 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140328 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5513997 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |