JP2011257847A - Communication system and communication system update method - Google Patents

Communication system and communication system update method Download PDF

Info

Publication number
JP2011257847A
JP2011257847A JP2010130030A JP2010130030A JP2011257847A JP 2011257847 A JP2011257847 A JP 2011257847A JP 2010130030 A JP2010130030 A JP 2010130030A JP 2010130030 A JP2010130030 A JP 2010130030A JP 2011257847 A JP2011257847 A JP 2011257847A
Authority
JP
Japan
Prior art keywords
node
updated
server cluster
application file
update
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.)
Granted
Application number
JP2010130030A
Other languages
Japanese (ja)
Other versions
JP5513997B2 (en
Inventor
Mikio Maeda
Yasutoshi Miyagi
Takaaki Moriya
Reiko Sakurada
幹夫 前田
安敏 宮城
高明 森谷
玲子 櫻田
Original Assignee
Nippon Telegr & Teleph Corp <Ntt>
日本電信電話株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nippon Telegr & Teleph Corp <Ntt>, 日本電信電話株式会社 filed Critical Nippon Telegr & Teleph Corp <Ntt>
Priority to JP2010130030A priority Critical patent/JP5513997B2/en
Publication of JP2011257847A publication Critical patent/JP2011257847A/en
Application granted granted Critical
Publication of JP5513997B2 publication Critical patent/JP5513997B2/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Images

Abstract

PROBLEM TO BE SOLVED: To update a file without interrupting existing services when scale-out is performed for a communication network and a communication service using a general-purpose server.SOLUTION: A communication system 1 comprises a node 2 where multiple server clusters 9, which are clustered by obtaining necessary resources from a resource pool 6, are arranged with application files to realize individual services. The communication system 1 includes a node 2a arranged with an old version application file 21 and a node 2b arranged with the same kind file 22. When a new function is added, the node 2a transfers data D used for processing the old version file 21 to the node 2b (S11) and updates to a new version file 23 (S12a). While the node 2a is updating, the node 2b executes processing to be performed by the node 2a in place of the node 2a and provides services (S13). After the update completes, the node 2a takes over the data D during update from the node 2b (S14).

Description

  The present invention relates to a communication system and a communication system update method, and more particularly, to a communication system composed of control nodes in a network, and a communication system update method by updating files of the control node.

  In recent years, diversification of network services has been remarkable. Normally, when a service provider launches a new service, it is difficult to clearly identify the number of users of the new service in advance. In terms of cost, it is effective to increase the number of servers as the number of users increases. Such a service provision start form is called small start.

  As a method for augmenting servers, performance enhancement, that is, a method of replacing hardware with a higher performance (called scale-up) has been conventionally performed. However, in scale-up, the cost increases exponentially when the performance of the hardware exceeds a certain level. Therefore, in recent years, as a method for increasing the number of servers, it is common to add servers that are not too high in performance and are inexpensive (scale out), and perform processing by operating multiple servers in parallel (this is called a cluster). It is becoming the target.

However, in order to quickly scale out when the number of service users increases, it is necessary to always keep a standby server that is not in operation waiting. It is costly for individual service providers to prepare such standby servers that are not always used.
Therefore, in recent years, a form called IaaS (Infrastructure as a Service) or the like in which a server management company such as a data center manages servers in a batch and hosts service providers has become common (non-patented). Reference 1).
In IaaS, not only is there a merit that hardware maintenance of the server is unnecessary for each service provider, but also server service maintenance costs can be reduced by sharing standby servers among multiple service providers. I can expect.

  On the other hand, in recent years, in communication networks, IP (Internet Protocol) of communication networks has been promoted for the purpose of reducing the cost of equipment maintenance costs. For this reason, it is common to implement a communication network and a communication service using a general-purpose server instead of dedicated hardware such as a conventional exchange. In addition, since communication services are also diversified, there is a demand to reduce facility costs by starting a new service in a small manner and scaling out the number of servers as the number of users increases.

  In response to such a request, each service is small-started, and when expanding the number of users of a certain service, a necessary server is acquired from the center (called a resource pool) where surplus standby resources are aggregated and scaled out. Applicable.

Amazon Elastic Compute Cloud (Amazon EC2), [Search April 6, 2010], Internet <URL: http: //aws.amazon.com/ec2/>

  However, for example, in a communication network and communication service using an IP network, a configuration in which a service (application) is executed by a plurality of general-purpose servers, that is, a scale-out configuration using a general-purpose server is simplified as a new method. It is difficult to adopt. For example, when a service function is added in a new communication network and communication service, it is completely different from the conventional equipment configuration. Therefore, the program file addition and update methods used in the conventional equipment configuration remain unchanged. Cannot be used. Therefore, a new file update method is necessary.

  In addition, for example, a communication network that uses an IP network and a communication provider that provides a communication service are required to have high reliability similar to that of a communication network such as an existing telephone network. It is desired to add a new service without interrupting the existing service provided so far.

  The present invention has been made to solve the above-described problems, and a communication system and communication system update capable of updating a file of an existing service without interruption when the communication network and the communication service are scaled out using a general-purpose server. It is an object to provide a method.

  In order to achieve the above object, a communication system according to the present invention includes a plurality of server clusters in which necessary resources are acquired in advance from a resource pool in which server resource components and boot images are previously pooled in excess. In addition, each node is a communication system that provides a service to a user terminal via a user service network, and includes nodes configured by deploying application files that implement individual services. A first node in which an application file of an old version is deployed; and a second node in which an application file of the same type capable of providing the predetermined service is provided, and the first node is connected to the predetermined service. When a new function is added, the previous version of the application The data used for processing the application file is moved to the second node, the old version application file is updated to a new version application file that realizes a new function for the predetermined service, and the application file is updated. After the update is completed, the data to be updated is taken over from the second node, and the second node performs processing to be performed by the first node while the first node is updating the application file. It executes instead to provide the predetermined service.

  In order to achieve the above object, the communication system update method according to the present invention is obtained by clustering a server resource component and a boot image obtained in advance from a resource pool obtained by excessively pooling a server resource component and a boot image. A communication system updating method in a communication system that includes nodes configured by deploying application files for realizing individual services in a plurality of server clusters, and each node provides services to user terminals via a user service network. The communication system includes a first node on which an old version application file that realizes a predetermined service is deployed, and a second node on which a similar application file that can provide the predetermined service is deployed. The first node comprises a previous When a new function is added to a predetermined service, a moving step of moving data used for processing the old version application file to the second node, and the old version application file to the predetermined service An update step for updating to a new version of the application file that implements a new function, and the second node should be performed by the first node while the first node is updating the application file. A step of providing a predetermined service by executing a process instead, and the first node takes over the data being updated from the second node after the update of the application file is completed It is characterized by performing.

According to the communication system having such a configuration or the communication system updating method according to such a procedure, the communication system deploys an application file to a server cluster in which each node has clustered surplus resources acquired from the resource pool. Therefore, in a small-started node, it is possible to easily scale out by adding a server cluster as the demand for the service to be provided increases.
The communication system deploys the same type of application file to a plurality of nodes, and executes services on each node.
Therefore, when adding a function to an application by updating an application file, the first node to be updated performs the update process after moving the data to the second node that executes the same type of application, and During this update, the second node takes over the first node and provides the existing service by the same kind of application, so that the file update for the additional function can be realized without service interruption.

  In the communication system according to the present invention, the node includes a management function for managing and managing the node, and the communication system distributes tasks and traffic to a plurality of server clusters constituting the node. Data that was used for processing in an unupdated server cluster already held in the node when a new service was added using the updated boot image by the node management function. To the server outside the same kind that can provide the same kind of service as the unupdated server cluster or another server cluster inside the node, and using the updated boot image, the new server Create a cluster and add the configured updated server cluster to the node and After the added updated server cluster coexists with the unupdated server cluster already held, and confirming the stable operation of the updated server cluster, the unupdated server cluster is disassembled. Returning to the resource pool, the distribution function unit distributes traffic to the node to the updated server cluster and the unupdated server cluster based on an instruction from the management function of the node. Is preferred.

  In the communication system update method according to the present invention, the node includes a management function for managing and managing the node, and the communication system distributes tasks and traffic to a plurality of server clusters constituting the node. The node management function is used for processing in an unupdated server cluster already held in the node when a new service is added using the updated boot image. Moving the data to the node outside the same kind that can provide the same kind of service as the unupdated server cluster or another server cluster inside the node, and using the updated boot image. Create a new server cluster and add the updated server cluster to the node An adding step, a coexistence step in which the added updated server cluster and an unupdated server cluster already held in the node coexist, and an operation for confirming the stable operation of the updated server cluster After confirming the stable operation of the updated server cluster, performing a confirmation step, disassembling the unupdated server cluster, and returning the disassembled component to the resource pool, The distribution function unit distributes traffic to the node to the updated server cluster and the non-updated server cluster based on an instruction from the management function of the node in the coexistence step. Is preferably performed.

According to the communication system configured as described above or the communication system update method according to such a procedure, when a communication system adds a new service to a node by updating a boot image, the node management function updates each server cluster. Do. Since the update is performed for each server cluster in this way, the destination of the data of the unupdated server cluster to be moved before the update is not only the external node but another unupdated server cluster inside the node. May be.
In addition, since the updated server cluster and the unupdated server cluster coexist in the boot image update file update process, the deployed application file may continue to operate during the boot image update. it can.
In addition, since the updated server cluster and the non-updated server cluster coexist, traffic to the node can be flexibly distributed to each server cluster in accordance with the file update state.
Furthermore, since the update is performed for each server cluster without updating all the server clusters at once, file update for a new service can be realized without interruption of the service.

  Further, in the communication system according to the present invention, the node management function starts the operation monitoring of the node from the file update start time when the new service is added, grasps the file update state in each server cluster, It is preferable to cancel the operation monitoring after the stable operation of the updated cluster can be confirmed over a predetermined time.

  Further, the communication system update method according to the present invention includes a monitoring start step in which the node management function starts operation monitoring of the node at the start of file update before the disassembly step when the new service is added. An update state management step for grasping a file update state in each server cluster, and a monitoring release step for releasing the operation monitoring after the stable operation of the updated cluster has been confirmed over a predetermined time, Is preferably performed.

  According to the communication system configured as described above or the communication system update method according to such a procedure, the communication system monitors the operation state of the node, grasps the file update state in each server cluster from the start of the update process, and Then, during a predetermined time after the update, it continues to check whether any trouble has occurred in the communication system. For this reason, even if a problem occurs during a predetermined time after the update, it is possible to cope with it and to realize non-interruption of service.

  Further, in the communication system according to the present invention, when a failure occurs in the server cluster during the operation monitoring of the node, the node management function disconnects all the updated clusters from the node, It is preferable to operate only on an unupdated cluster before update.

  Further, the communication system update method according to the present invention detaches all the updated clusters from the node when the management function of the node causes a failure in the server cluster during operation monitoring of the node. It is preferable to execute the step and the step of operating only on the unupdated cluster before the update.

  According to the communication system configured as described above or the communication system update method according to such a procedure, the communication system coexists the updated server cluster and the unupdated server cluster in the file update process of the boot image update. Therefore, even if a problem occurs in the updated server cluster within a predetermined time after the update, the node management function moves the task from the updated server cluster to the non-updated cluster. An interruption can be realized.

  In the communication system according to the present invention, the first node updates the old version application file to the new version application file, and the stable operation of the new version application file is predetermined. If it is confirmed over a predetermined time, the data being updated is taken over from the second node, and if the stable operation of the application file of the new version cannot be confirmed during the predetermined time, the application of the new version If the stable operation of the new version of the application file is confirmed after the file is redeployed and redeployed, it is preferable to take over the data being updated from the second node.

  In the communication system update method according to the present invention, the first node executes an update step of updating the old version of the application file to the new version of the application file, thereby stabilizing the new version of the application file. When the operation can be confirmed over a predetermined time, the data being updated is taken over from the second node, and the stable operation of the new version of the application file cannot be confirmed during the predetermined time. Re-deploying the new version of the application file, and taking over the data being updated from the second node when the stable operation of the new version of the application file is confirmed after redeployment. It is preferable to do.

  According to the communication system configured as described above or the communication system update method according to the procedure, the communication system moves data to the same type of node before updating in the application file update, and during the update, the data movement destination Therefore, even if a problem occurs during application file update, uninterrupted processing (hereinafter referred to as service uninterrupted) can be continued as a service. In addition, during this service uninterrupted process, the update target node can change the status of the file update status and redeploy, so it can take over data as soon as stable operation can be confirmed. it can.

According to the present invention, it is possible to add a new service while maintaining high reliability required for a communication network such as an existing telephone network and no service interruption.
Further, according to the present invention, it is possible to realize non-interruption of service even if the node to be updated has an operation monitoring state for a predetermined time, even if it becomes unstable immediately after adding a new service. .

  Furthermore, according to the present invention, in a file update process for boot image update, a file that is updated or added during the operation monitoring period by coexisting an updated server cluster and an unupdated server cluster. It is possible to immediately return to the state before the update or addition when a defect is found. Also, in this case, when new data is added or new data is referenced or added, the request can be distributed to the old and new services.

It is a block diagram which shows an example of the communication system which concerns on embodiment of this invention. FIG. 2 is a conceptual diagram schematically illustrating a configuration example of a node illustrated in FIG. 1. FIG. 3 is a conceptual diagram schematically illustrating a redundant configuration example of a server cluster illustrated in FIG. 2. It is a conceptual diagram which shows the outline | summary of the update method of an application file in the communication system which concerns on embodiment of this invention. It is a conceptual diagram which shows the operation | movement at the time of the update of the communication system which concerns on embodiment of this invention. It is a conceptual diagram which shows an example of the outline | summary of the update method of a boot image in the communication system which concerns on embodiment of this invention. It is a conceptual diagram which shows the other example of the outline | summary of the update method of a boot image in the communication system which concerns on embodiment of this invention. It is a conceptual diagram which shows the outline | summary of the update procedure of a server cluster in the communication system which concerns on embodiment of this invention. FIG. 9 is a conceptual diagram illustrating traffic during update of the server cluster illustrated in FIG. 8. It is a conceptual diagram which shows the process of the management function during the update of the server cluster shown in FIG. It is a conceptual diagram which shows an example of the process in the driving | running monitoring state by the management function shown in FIG. It is a conceptual diagram which shows the other example of the process in the driving | running monitoring state by the management function shown in FIG.

  DESCRIPTION OF EMBODIMENTS A communication system and an updating method thereof according to the present invention will be described in detail with reference to the drawings.

(First embodiment)
[Configuration of communication system]
As shown in FIG. 1, the communication system 1 includes a plurality of control nodes (hereinafter simply referred to as nodes) 2 having a cluster configuration that provides communication services to users. The number of nodes 2 is arbitrary, but the same service is provided by one or more nodes 2. That is, the communication system 1 is a system that can add (scale out) a node that performs the same processing after a small start. The communication system 1 is operated by, for example, a telecommunications carrier. The type of communication service is not particularly limited, and examples thereof include a call processing service such as a telephone call.

The node 2 is connected to the user terminal 3 via the user service network N 1 . The user terminal 3 is a terminal used by a user who enjoys a communication service, and includes, for example, a general personal computer (PC) or a portable information terminal that can be connected to a wired or wireless network. The user service network N 1 is not particularly limited, but may be an IP network, for example.

A load balancer (LB, distribution function unit) 4 is provided between the node 2 and the user service network N 1 . Load balancer 4, there is for distributing traffic or task from a user service network N 1 to the node 2 to one of the server cluster 9 in the node 2, for example, it is a device having a common load balancing .

A control node 5 other than the node 2 is also connected to the user service network N 1 . The control node 5 performs, for example, routing processing, traffic monitoring processing, failure detection processing, etc. in the user service network N 1 . The control node 5 is composed of, for example, a general server or router.

The node 2 is connected to the resource pool 6, the resource pool manager 7, and the operator terminal 8 via, for example, a maintenance network N 2 of a communication carrier.
The resource pool 6 indicates a network space in which resources (resources) are aggregated to some extent. Resources aggregated in the resource pool are used as surplus standby resources. In this embodiment, as an example, the whole of Japan is divided into seven regions in total: Kyushu and Okinawa, China and Shikoku, Kinki, Hokuriku and Tokai, Kanto, Tohoku, and Hokkaido. Correspondingly, it is assumed that seven resource pools 6 (6a to 6g) are prepared (see FIG. 5).

The resource pool manager 7 manages the resource pools 6 scattered throughout the country, and includes, for example, a general server.
The operator terminal 8 is a terminal used by, for example, an operator of a telecommunications carrier in order to input a command to the resource pool manager 7, and is composed of, for example, a general PC. The number of user terminals 3, control nodes 5, resource pool managers 7, and operator terminals 8 is arbitrary.

  As shown in FIG. 1, the node 2 is configured by deploying application files for realizing individual services from a resource pool 6 to a redundant server cluster 9 obtained by acquiring necessary resources in advance and clustered. A plurality of server clusters 9 and a management function 10.

As shown in FIG. 2, the resource pool 6 includes a server resource component 30. The server resource component 30 is pooled excessively.
The server resource component 30 is a physical composition of the node 2 and is a physical server in which a CPU (Central Processing Unit), a memory, a NIC (Network Interface Card) and the like are assembled. Show. In FIG. 2, individual servers 31, 32, and 33 are illustrated as an example of the server resource component 30, and these are collectively referred to as the server resource component 30.

  In the present embodiment, the resource pool 6 also includes a boot image 40. The boot image 40 is pooled excessively. The boot image 40 is a software component for realizing the function of the node 2 and indicates, for example, an OS (Operating System), middleware, a library, and the like.

  The example of the boot image 40 shown in FIG. 2 schematically represents the state pooled in the resource pool 6, and for the server cluster 9, the software component 50 as shown in FIG. Represented as: In this case, the server cluster 9 includes, as the software component 50, for example, an OS 51, middleware 52, and a library 53.

In FIG. 2, as an example of the boot image 40, a cluster server 41, a cluster LB (load balancer) 42, and a cluster management function 43 are illustrated.
The cluster server 41 is an image file in which software components used in the server cluster 9 that provides services are assembled for each server.
The cluster LB42 is an image file in which software components used for the load balancer 4 are assembled for each load balancer.
The cluster management function 43 is an image file in which software components used for the management function 10 for managing and managing nodes are assembled for each management function.

  In FIG. 5, the cluster EMS 44 is also illustrated as an example of the boot image 40. The cluster EMS 44 is an image file in which software components used for a monitoring detection function (not shown) for monitoring a node operation state to detect a failure are assembled for each EMS (Event Monitoring Service).

  The resource pool 6 may be divided into a server resource pool and a boot image pool. In this case, the server resource pool includes only the server resource component 30, and the boot image pool includes only the boot image 40.

  As shown in FIG. 2, a cluster of the server resource component 30 and the boot image 40 corresponds to the server cluster 9. This server cluster 9 can be realized in an N-layer configuration (N is an integer of 2 or more). Further, the node 2 is configured by deploying application files 20 for realizing individual services in the server cluster 9. That is, FIG. 2 schematically shows the hierarchical structure of the node 2.

FIG. 3 shows a redundant configuration example of the server cluster shown in FIG.
In the duplex cluster 9A shown in FIG. 3A, the active server cluster (ACT) and the standby server cluster (SBY) both include two servers.
In the triple cluster 9B shown in FIG. 3B, the active server cluster (ACT) and the standby server cluster (SBY) both include three servers.
In the following, it is assumed that the server cluster 9 is a double cluster, and only the active server is illustrated.

[File update method when adding a new service]
When a new service is added when an existing service is provided, a first case of updating the application file 20, a second case of updating the boot image 40, and a third case of updating both. A case is assumed. Among these, in the third case, the file update can be performed by performing the processing of the first case and the processing of the second case in this order or in the reverse order. In the following, two locations of the application file 20 and the boot image 40 will be described independently as update target locations when adding a service.

[First case when adding a new service]
First, the operation at the time of updating the application file as the first update target portion at the time of adding a service will be described with reference to FIG.
As a premise, it is assumed that the node 2a and the node 2b are connected to the user service network N 1 (see FIG. 1).
Further, it is assumed that the node 2a uses the data D for the application file 21 “APL ver1.0” that provides a call processing service, for example. Further, it is assumed that the node 2b is a node that provides the same service (same application) as the node 2a by using the application file 22 “APL verx.x”. The application file 22 “APL verx.x” may be the application file 21 “APL ver1.0” or an updated application file 23 “APL ver2.0”. In the following, an example of updating the application file 21 “APL ver1.0” of the node 2a is shown. Nodes that provide applications having the same or different versions as described above are hereinafter referred to as the same type of nodes.

  At the time of application update, the node 2a, which is a node to be updated, sweeps out the data D used so far to the outside. Here, the node 2a moves the data D used so far to another node 2b of the same kind (step S11). Thus, the service can be updated without interruption when the application file 20 is updated.

  After moving the data D, the node 2a updates the application file (step S12a). Since the node 2a does not update the software components 50 such as the OS 51, middleware 52, and library 53 in the server cluster 9, the existing nodes can be used as they are for these software components 50 (step S12b). ).

  While the node 2a is updating the application file, the node 2b, which is the data movement destination, takes over the traffic and performs processing (step S13). After that, when the application file 21 “APL ver1.0” is updated to the application file 23 “APL ver2.0”, the node 2a notifies the update completion report to the node 2b. The node 2b that has received the notification takes over the data taken over from the updated node 2a (step S14). Through the series of operations described above, the service can be updated without interruption when the application file 20 is updated.

[Second case when adding a new service]
Next, the operation at the time of updating the boot image will be described with reference to FIGS. The outline of the update processing related to the boot image is as follows. After the boot image 40 to be updated is updated, the server cluster 9 is formed using the updated boot image 40, and the boot image 40 for each cluster with respect to the node 2. Update. In other words, when updating the boot image, there are roughly the following three stages of processing. The first stage is a stage in which the boot image 40 to be updated is updated (see FIG. 5). The second stage is a stage in which the server cluster 9 is formed using the updated boot image 40 (see FIGS. 6 to 7). The third stage is a stage in which an updated server cluster and an unupdated server cluster coexist (see FIGS. 8 to 10). Hereinafter, each step will be described.

<First stage: Boot image update>
In the first stage, for example, as shown in FIG. 5, the whole country is divided into a plurality of regions, and the boot image 40 can be partially updated without service interruption for each resource pool 6.
In the case of the present embodiment, the boot image 40 is updated in the resource pool 6. Therefore, in the resource pool 6, the server resource component 30 is appropriately updated as necessary, and the server resource component 30 is not interrupted without service. Can be partially updated.

  Specifically, in the first stage, as shown in FIG. 5, the operator instructs the resource pool manager 7 about the update schedule of the designated node 2 (step S1). Then, the resource pool manager 7 inputs a command to the resource pool 6 based on an instruction from the operator (step S2). In the case of complicated instructions, the operator directly inputs commands to the resource pool 6. Thereby, the boot image 40 and the server resource component 30 in each resource pool 6 are updated. Subsequently, as shown below, the node 2 is updated by updating the server cluster 9, and as a result, the communication system 1 is updated. Note that the update of the boot image 40 includes an update of the software component 50.

<Second stage: Server cluster composition>
In the second stage, data can be moved in two different ways for server cluster composition.
≪First movement method: Data movement to external node≫
FIG. 6 shows a conceptual diagram of the first movement method when updating the server cluster 9 to be updated using the updated boot image. FIG. 6 shows an example in which a part of the server cluster included in the node 2a is updated. It is assumed that the server cluster 9 of the node 2a uses, for example, call processing data and data for maintenance operation processing (hereinafter simply referred to as data D). In the nodes 2a and 2b, it is assumed that the application file 20 is operating independently of the update using the boot image.

  Under these assumptions, the update target server cluster 201 of the node 2a starts file update (step S21). The server cluster 201 to be updated of the node 2a moves the data D that has been used so far to another node 2b of the same type (step S22). As a result, the server cluster 202 of the destination node 2b takes over the processing.

«Second migration method: Data migration to internal server cluster»
FIG. 7 shows a conceptual diagram of the second migration method when updating the server cluster 9 to be updated using the updated boot image. FIG. 7 shows an example in which a part of the server cluster included in the node 2a is updated. It is assumed that the server cluster 9 of the node 2a uses data D. The update target server cluster 201 of the node 2a starts file update (step S21). The server cluster 201 to be updated of the node 2a moves the data D used so far to another server cluster 203 in the node 2a (step S23). As a result, the server cluster 203 at the movement destination takes over the processing.

<Third stage: Coexistence stage of updated cluster and non-updated cluster>
≪Overview of server cluster coexistence≫
When the boot image 40 is updated, the service can be updated by reconfiguring the server cluster 9. However, if all the existing server clusters 9 constituting the node 2 are simply replaced at once with the newly formed server cluster 9, the service must be stopped once, and the service in operation is not stopped or interrupted. Cannot update the file. Therefore, in the present embodiment, as a countermeasure against such a problem, the server cluster 9 is not switched at the same time, and an updated server cluster and an unupdated server cluster are mixed as shown in FIG. It was decided to run the application. FIG. 8 shows the flow from the middle of the file update to the server cluster disassembly after the update.

  In this case, as shown in FIG. 8, first, the node 2a adds a server cluster 301 (step S31). That is, a new server cluster is formed using the software component 50 of the updated boot image 40. When the server resource component 30 is updated, clustering is performed using the updated server resource component 30 as necessary.

  Subsequently, in addition to the server cluster 301, the node 2a sequentially forms additional server clusters 302 and 303 within the range allowed by the resources (step S32). Here, the tasks newly processed by the node 2a are sequentially performed in the updated server cluster (hereinafter referred to as the updated server cluster 9b). When the node 2a confirms the stable operation of all the updated server clusters 9b (server clusters 301 to 303) (step S33), the node 2a disassembles the old server cluster (unupdated server cluster 9a) (step S34). That is, the server cluster 9a is released from the cluster configuration, is separated into each server (server resource component) as a component, and the software component is deleted. Then, the node 2a returns the server resource component to each resource pool 6 (step S35). Thereby, each server (server resource component) returned to the resource pool 6 waits as a surplus resource that can be configured.

  As a result, the server cluster 9 is sequentially added and the task that is newly processed by the node 2a is performed in the updated server cluster 9b without switching the boot images 40 of all the server clusters 9 simultaneously, and the updated server After confirming the stable operation of the cluster 9, the old server cluster (unupdated server cluster) 9a is disassembled and the server resource is returned, so that the file update without interruption can be performed. Note that, when the stable operation of the updated server clusters 301 to 303 cannot be confirmed, the node 2a may notify the operator or the like to that effect.

≪Overview of traffic being updated≫
The traffic when the application is operated in a state where the updated server cluster and the non-updated server cluster are mixed will be described with reference to FIG. The user service network N 1, the load balancer 4 disposed in front of the node 2a from node 2a, receive a control instruction for the distribution in accordance with the update status of the server cluster (step S41), OK response Is returned (step S42). Thereby, tasks and traffic can be allocated to the server cluster 9.

In the example shown in FIG. 9, initially, the load balancer 4, the traffic from the user service network N 1 to the node 2a, distributed to the server cluster 9a unupdated only. After that, when the first added server cluster is updated and becomes an updated server cluster 9b and starts to operate, the load balancer 4 has not updated the traffic 402 which is a part of the traffic to the node 2a. While distributing to the server cluster 9a, another part of the traffic 403 is allocated to the updated server cluster 9b in operation. Note that the load balancer 4 does not distribute traffic to the server cluster 401 in the composition.

  In addition, this allows the updated server cluster 9b and the unupdated server cluster 9a to coexist before dismantling the old server cluster (unupdated server cluster) 9a. When data is referenced or added to a service, the load balancer 4 can distribute the request to the new and old services.

  According to the communication system 1 according to the first embodiment, when starting a new service, the system user acquires necessary servers from the resource pool 6 in which surplus standby resources are aggregated, and scales out as a cluster configuration. By taking a small start configuration, the equipment cost can be reduced.

  Moreover, according to the communication system update method according to the first embodiment, when adding a new service as an additional function of the node 2 constituting the communication system 1, the existing communication service can be updated without interruption. .

(Second Embodiment)
Immediately after updating the boot image 40 or the like as in the second case described in the first embodiment by using the file update method when adding a new service, some trouble may occur in the communication system. is assumed. Even in such a case, a communication system that realizes no service interruption will be described as a second embodiment. Since the configuration of the communication system of the second embodiment is the same as that of the first embodiment, the configuration diagram is omitted, the same reference numerals are given to the same components, and the description is appropriately omitted.

  The management function 10 (see FIG. 1) of the node 2 enters the operation monitoring state of the node 2 from the start of update of the file such as the boot image 40, and grasps the file update state in each server cluster 9 of the node 2. Here, the file update status ascertained by the management function 10 indicates whether the current status of the server cluster to be updated in the file update is “cluster in progress”, “not updated”, or “updated”. It is the information which shows. Here, “during cluster composition” indicates a state from the start of update processing to completion, and “updated” indicates a state where update is completed. Further, “unupdated” means a reset state before starting the update process or a state in which the status “updated” fluctuates and is reset because stable operation is not confirmed. The management function 10 stores a database in which the file update status is recorded for each server cluster in a storage unit (not shown) and sequentially updates it.

  The management function 10 releases the operation monitoring state when it is determined by the operation monitoring of the node 2 that the stable operation of the updated server cluster is successful. Specifically, the management function 10 determines that the stable operation of the server cluster whose file update status is recognized as “updated” can be continuously confirmed for a predetermined time T. Cancel the operation monitoring state.

  On the other hand, when the management function 10 determines by the operation monitoring of the node 2 that the stable operation of the updated server cluster has failed, that is, the time when the stable operation of the server cluster can be continuously confirmed is the predetermined time T When the condition is not satisfied, the operation monitoring state is canceled, and the task that has been performed by the updated server cluster is returned to the unupdated old server cluster. Here, for such an additional function in the management function 10, a software component assembled into an image file as the cluster EMS 44 (see FIG. 5) can be used. Note that when the operation monitoring state so far is cancelled, the operation monitoring state of the node 2 related to the task processing of the old server cluster may be entered.

  As a specific example, a third stage in which the boot image 40 and the like are updated as in the second case and the updated server cluster and the unupdated server cluster coexist will be described with reference to FIG. FIG. 10 shows the flow from the middle of the file update to the disassembly of the server cluster after the end of the update as in FIG. In FIG. 10, the same operations as those in FIG.

  In this case, as shown in FIG. 10, when the node 2a starts the composition by adding the server cluster 301 in step S31, the management function 10 of the node 2a monitors the operation of the node 2a from the start of the file update. The state is entered (step S51). Then, the management function 10 starts to grasp the file update state in each server cluster 9 of the node 2a. Specifically, at the start of file update, the file update state of the existing unupdated server cluster 9a is “not updated” and the file update state of the added server cluster 301 is “cluster composition”. To be understood. When the update in the server clusters 301 to 303 sequentially added by the node 2a is completed, it is recognized that the file update state of the updated server cluster 9b is “updated”.

  Then, the management function 10 can confirm the stable operation of the updated server cluster 9b for a predetermined time T by the operation monitoring of the node 2a, and cancels the operation monitoring state when it is determined that the stable operation is successful (step S53). Thereafter, the management function 10 disassembles the old server cluster (unupdated server cluster 9a) (step S34), and returns the component to each resource pool 6 (step S35). On the other hand, when the management function 10 determines that the stable operation has failed after the time during which the stable operation of the updated server cluster 9b can be confirmed continuously does not reach the predetermined time T by the operation monitoring of the node 2a. In addition to immediately returning to the original service, the file update state “updated” is reset to “not updated” to release the operation monitoring state.

As a specific example of the file update failure of the boot image 40, refer to FIG. 11 for processing when a problem occurs in software or hardware in the updated server cluster 9b while the management function 10 is in the operation monitoring state of the node 2a. To explain. In FIG. 11, the same components as those in FIG. As shown in FIG. 11, for example, it is assumed that a defect of the update file has occurred in the updated server cluster 9b of the node 2a (step S61). In this case, the management function 10 of the node 2a disconnects all the updated server clusters 9b from the node 2a (step S62). In FIG. 11, the broken line 9b1 indicates that the updated server cluster 9b is disconnected.
Then, the management function 10 of the node 2a is operated only by the unupdated server cluster 9a as in the state before the file update (step S63). Thereby, service non-interruption is realizable.

  According to the communication system of the second embodiment, the management function 10 of the node 2a immediately returns to the original service when any trouble occurs in the communication system during the predetermined time T after the update of the boot image 40. Therefore, even in such a case, service interruption can be realized.

(Third embodiment)
Using the file update method when adding a new service, not only when a failure occurs after updating the boot image 40 etc. as in the second case described in the first embodiment, A communication system that realizes non-disruption of service even when a problem occurs after updating the application file 20 as in the case 1 will be described as a third embodiment. Since the configuration of the communication system of the third embodiment is the same as that of the second embodiment, the configuration diagram is omitted, and the same components are denoted by the same reference numerals and the description thereof is omitted as appropriate.

  The management function 10 (see FIG. 1) of the node 2 according to the third embodiment is the same as the management function 10 of the node 2 according to the second embodiment. The difference is that various functions have been added.

  The management function 10 enters the operation monitoring state of the node 2 from the time when the update process of the application file 20 is started, and grasps the file update state of the application file 20 in the node 2. The file update status is information indicating whether the current status of the application file to be updated in the file update is “not updated”, “updated”, or “updated”. Here, “unupdated” indicates a state before the update process is started, and “updated” indicates a state where the update is completed. “Updating” means that the status “updated” fluctuates due to the fact that the stable operation is not confirmed, and is reset once, and it is necessary to update again. The management function 10 stores a database in which the file update status for the application file 20 is recorded in a storage unit (not shown) and sequentially updates it.

  The management function 10 cancels the operation monitoring state when it is determined by the operation monitoring of the node 2 that the stable operation of the updated application file 20 is successful. Specifically, the management function 10 determines that the stable operation of the application file 20 whose update state is recognized as “updated” can be continuously confirmed for a predetermined time T. The operation monitoring state is canceled, and the update completion report of the application file is notified to the data movement destination node 2.

On the other hand, when the management function 10 determines by the operation monitoring of the node 2 that the stable operation of the updated application file 20 has failed, that is, the time when the stable operation of the application file 20 can be continuously confirmed is predetermined. If the time T has not been reached, the operation monitoring state is continued without notifying the data migration destination node 2 of the update completion report of the application file. Here, the continuation of the operation monitoring state means, for example, that the operation state of the node 2 is newly monitored over a predetermined time T or a predetermined time T 0 different from the predetermined time T, and the application file 20 This means that the update state of “Updated” is changed from “Updated” to “Updating”.

  As a specific example of the file update failure of the application file 20, FIG. 12 shows processing when a failure occurs in the updated application file 20 while the management function 10 is in the operation monitoring state of the node 2 (before the predetermined time T has elapsed). The description will be given with reference. In FIG. 12, the same components as those in FIG. 4 are denoted by the same reference numerals, and the same operations as those in FIG. The management function 10 is not shown in the nodes 2a and 2b. The nodes 2a and 2b are assumed to have the same application file 21 deployed.

  As shown in FIG. 12, for example, the node 2a updates the application file 21 “APL ver1.0” to the application file 23 “APL ver2.0” and then updates the application file for a predetermined time T. It is assumed that a problem occurs at 23 (step S71). In this case, the update state of the application file 23 “APL ver2.0” is changed from “Updated” to “Updating”. In this way, a file in which the current state of the application file is reset and becomes “updating” is treated as an unupdated application file.

  Then, the management function 10 of the node 2a redeploys the unupdated application file (application file 23 “APL ver2.0”) (step S72), and returns to step S12a. Note that while the application file is being redeployed in the node 2a, the node 2b that is the data movement destination has not received the update completion report, and thus continues the processing while taking over the traffic of the node 2a (step S13). ).

  Then, when the management function 10 of the node 2a redeploys the application file and determines that the stable operation of the updated application file 23 “APL ver2.0” has succeeded due to the continuation of the operation monitoring state, The operation monitoring state is canceled, and the update completion report of the application file is notified to the data movement destination node 2b. When the node 2b receives the notification and confirms the stable operation, the node 2b takes over the data taken over by the node 2a to be updated (step S73).

  According to the communication system of the third embodiment, when the management function 10 of the node 2a is in the monitoring state of the updated application file 20 for a predetermined time T, even if some trouble occurs in the application file 20, Since the traffic is taken over by the other node 2b, uninterrupted processing can be continued as a service. In addition, during the service uninterrupted, the update target node 2a can change the status of the file update state and redeploy, so that the data can be taken over as soon as stable operation can be confirmed. .

  As mentioned above, although each embodiment of this invention was described, this invention is not limited to these, It can implement in the range which does not change the meaning. For example, the communication system 1 according to the first embodiment is the best mode having both the function of updating the application file 20 and the function of updating the boot image 40 and the like, but includes only the function of updating the application file 20. You may do it. In this case, it is not always necessary to provide the load balancer 4 before the node 2. Even with such a configuration, when an existing service is provided by updating the application file 20, a new service can be added without interruption.

1 Communication system 2 Node (control node)
2a node (first node)
2b node (second node)
3 User terminal 4 Load balancer (distribution function part)
5 Control node 6 (6a to 6g) Resource pool 7 Resource pool manager 8 Operator terminal 9 Server cluster 10 Management function 20, 21, 22, 23 Application file 30 Server resource component 31, 32, 33 Server 40 Boot image 41 Cluster server 42 Cluster LB
43 Cluster management function 44 Cluster EMS
50 software components 51 OS
52 Middleware 53 Library

Claims (10)

  1. Configured by deploying application files that realize individual services to multiple server clusters that have been clustered by acquiring necessary resources in advance from a resource pool in which server resource components and boot images are pooled in advance. Each node is a communication system that provides services to user terminals via a user service network,
    A first node on which an old version of an application file that realizes a predetermined service is deployed; and a second node on which a similar application file that can provide the predetermined service is deployed;
    The first node is:
    When adding a new function to the predetermined service, the data used for processing the application file of the old version is moved to the second node,
    Updating the old version of the application file to a new version of the application file that implements a new function for the predetermined service,
    After the update of the application file is completed, the data being updated is taken over from the second node,
    The second node provides the predetermined service by executing processing to be performed by the first node instead while the first node is updating the application file. system.
  2. The node has a management function for managing and managing the node,
    The communication system includes a distribution function unit that distributes tasks and traffic to a plurality of server clusters constituting the node,
    The node management function is:
    When a new service is added using the updated boot image, the same type of service as the unupdated server cluster can be provided using the data used for processing in the unupdated server cluster already held in the node. Move to the same external node or another server cluster inside the node, use the updated boot image to form a new server cluster, and configure the updated server cluster After adding to the node, coexisting the updated server cluster added in the node and the unupdated server cluster already held, and confirming the stable operation of the updated server cluster, Dismantle the unupdated server cluster and return it to the resource pool,
    The distribution function unit distributes traffic to the node to the updated server cluster and the unupdated server cluster based on an instruction from the management function of the node. The communication system according to 1.
  3. The node management function is:
    When the new service is added, operation monitoring of the node is started from the file update start point, the file update state in each server cluster is grasped, and the stable operation of the updated cluster is performed over a predetermined time. The communication system according to claim 2, wherein the operation monitoring is canceled after confirmation.
  4. The node management function is:
    When a failure occurs in the server cluster during operation monitoring of the node, all the updated clusters are disconnected from the node, and only the unupdated cluster before the update is operated. Item 4. The communication system according to Item 3.
  5. The first node is:
    When the old version of the application file is updated to the new version of the application file and the stable operation of the new version of the application file has been confirmed over a predetermined time, the second node Take over the data being updated,
    When the stable operation of the new version of the application file cannot be confirmed during the predetermined time, and when the new version of the application file is redeployed and after the redeployment, the stable operation of the new version of the application file can be confirmed The communication system according to any one of claims 1 to 4, wherein the data being updated is taken over from the second node.
  6. Configured by deploying application files that realize individual services to multiple server clusters that have been clustered by acquiring necessary resources in advance from a resource pool in which server resource components and boot images are pooled in advance. A communication system update method in a communication system for providing a service to a user terminal via a user service network.
    The communication system includes a first node in which an application file of an old version that realizes a predetermined service is deployed, and a second node in which the same type of application file that can provide the predetermined service is deployed,
    The first node is:
    A moving step of moving data used for processing the application file of the old version to the second node when a new function is added to the predetermined service;
    Updating the old version of the application file to a new version of the application file that implements a new function for the predetermined service; and
    The second node is
    While the first node is updating the application file, a service providing step of providing the predetermined service by executing processing to be performed by the first node instead is executed.
    The first node is:
    A communication system update method, wherein after the update of the application file is completed, a takeover step of taking over data being updated from the second node is executed.
  7. The node has a management function for managing and managing the node,
    The communication system includes a distribution function unit that distributes tasks and traffic to a plurality of server clusters constituting the node,
    The node management function is:
    When a new service is added using the updated boot image, the same type of service as the unupdated server cluster can be provided using the data used for processing in the unupdated server cluster already held in the node. A move step of moving to the node outside the same kind or another server cluster inside the node;
    Adding the new server cluster using the updated boot image and adding the updated server cluster to the node;
    A coexistence step in which the added updated server cluster and an unupdated server cluster already held in the node coexist,
    An operation confirmation step for confirming a stable operation of the updated server cluster;
    Dismantling the unupdated server cluster after confirming the stable operation of the updated server cluster;
    Returning the disassembled component to the resource pool; and
    The distribution function unit
    In the coexistence step, based on an instruction from the management function of the node, the step of allocating traffic to the node to the updated server cluster and the unupdated server cluster is performed. The communication system update method according to claim 6.
  8. The node management function is:
    Before adding the new service, before the dismantling step,
    A monitoring start step for starting operation monitoring of the node at the start of file update;
    An update status management step for grasping the file update status in each server cluster;
    The communication system update according to claim 7, wherein after the stable operation of the updated cluster has been confirmed over a predetermined time, a monitoring cancellation step of canceling the operation monitoring is executed. Method.
  9. The node management function is:
    During the operation monitoring of the node, if a failure occurs in the server cluster, detaching all the updated clusters from the node;
    The communication system updating method according to claim 8, wherein the operation is performed only on the unupdated cluster before the update.
  10. The first node is:
    Performing an update step of updating the old version of the application file to the new version of the application file;
    When the stable operation of the application file of the new version can be confirmed over a predetermined time, the data being updated is taken over from the second node,
    Re-deploying the new version of the application file if stable operation of the new version of the application file cannot be confirmed during the predetermined time;
    10. The step of taking over the data being updated from the second node when the stable operation of the new version of the application file can be confirmed after redeployment. The communication system update method as described in any one of Claims.
JP2010130030A 2010-06-07 2010-06-07 Communication system and communication system update method Active JP5513997B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010130030A JP5513997B2 (en) 2010-06-07 2010-06-07 Communication system and communication system update method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010130030A JP5513997B2 (en) 2010-06-07 2010-06-07 Communication system and communication system update method

Publications (2)

Publication Number Publication Date
JP2011257847A true JP2011257847A (en) 2011-12-22
JP5513997B2 JP5513997B2 (en) 2014-06-04

Family

ID=45473994

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010130030A Active JP5513997B2 (en) 2010-06-07 2010-06-07 Communication system and communication system update method

Country Status (1)

Country Link
JP (1) JP5513997B2 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014130585A (en) * 2012-12-27 2014-07-10 General Electric Co <Ge> Firmware upgrade error detection and automatic rollback
JP2017534107A (en) * 2014-09-30 2017-11-16 アマゾン テクノロジーズ インコーポレイテッド Dynamic code deployment and versioning
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10140137B2 (en) 2014-09-30 2018-11-27 Amazon Technologies, Inc. Threading as a service
US10162688B2 (en) 2014-09-30 2018-12-25 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US10203990B2 (en) 2016-06-30 2019-02-12 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
US10277708B2 (en) 2016-06-30 2019-04-30 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
US10282229B2 (en) 2016-06-28 2019-05-07 Amazon Technologies, Inc. Asynchronous task management in an on-demand network code execution environment
US10353746B2 (en) 2014-12-05 2019-07-16 Amazon Technologies, Inc. Automatic determination of resource sizing
US10353678B1 (en) 2018-02-05 2019-07-16 Amazon Technologies, Inc. Detecting code characteristic alterations due to cross-service calls
US10365985B2 (en) 2015-12-16 2019-07-30 Amazon Technologies, Inc. Predictive management of on-demand code execution
US10387177B2 (en) 2015-02-04 2019-08-20 Amazon Technologies, Inc. Stateful virtual compute system
US10437629B2 (en) 2015-12-16 2019-10-08 Amazon Technologies, Inc. Pre-triggers for code execution environments
US10528390B2 (en) 2016-09-23 2020-01-07 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US10552193B2 (en) 2015-02-04 2020-02-04 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US10564946B1 (en) 2017-12-13 2020-02-18 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10592269B2 (en) 2017-07-24 2020-03-17 Amazon Technologies, Inc. Dynamic code deployment and versioning

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004206453A (en) * 2002-12-25 2004-07-22 Fujitsu Ltd Shared data access system for multiprocessor
JP2006031312A (en) * 2004-07-15 2006-02-02 Hitachi Ltd Storage device
WO2006040810A1 (en) * 2004-10-12 2006-04-20 Fujitsu Limited Software update program, software update device, and software update method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004206453A (en) * 2002-12-25 2004-07-22 Fujitsu Ltd Shared data access system for multiprocessor
JP2006031312A (en) * 2004-07-15 2006-02-02 Hitachi Ltd Storage device
WO2006040810A1 (en) * 2004-10-12 2006-04-20 Fujitsu Limited Software update program, software update device, and software update method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CSNG200900603002; 金子 雅志,入江 道生,四七 秀貴,飯尾 政美: '高可用サーバクラスタにおけるシステム更新方式の検討' 電子情報通信学会技術研究報告 Vol.109,No.279, 20091105, pp.5-10, 社団法人電子情報通信学会 *
JPN6013044468; 金子 雅志,入江 道生,四七 秀貴,飯尾 政美: '高可用サーバクラスタにおけるシステム更新方式の検討' 電子情報通信学会技術研究報告 Vol.109,No.279, 20091105, pp.5-10, 社団法人電子情報通信学会 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014130585A (en) * 2012-12-27 2014-07-10 General Electric Co <Ge> Firmware upgrade error detection and automatic rollback
JP2017534107A (en) * 2014-09-30 2017-11-16 アマゾン テクノロジーズ インコーポレイテッド Dynamic code deployment and versioning
US10140137B2 (en) 2014-09-30 2018-11-27 Amazon Technologies, Inc. Threading as a service
US10162688B2 (en) 2014-09-30 2018-12-25 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US10353746B2 (en) 2014-12-05 2019-07-16 Amazon Technologies, Inc. Automatic determination of resource sizing
US10387177B2 (en) 2015-02-04 2019-08-20 Amazon Technologies, Inc. Stateful virtual compute system
US10552193B2 (en) 2015-02-04 2020-02-04 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US10365985B2 (en) 2015-12-16 2019-07-30 Amazon Technologies, Inc. Predictive management of on-demand code execution
US10437629B2 (en) 2015-12-16 2019-10-08 Amazon Technologies, Inc. Pre-triggers for code execution environments
US10282229B2 (en) 2016-06-28 2019-05-07 Amazon Technologies, Inc. Asynchronous task management in an on-demand network code execution environment
US10402231B2 (en) 2016-06-29 2019-09-03 Amazon Technologies, Inc. Adjusting variable limit on concurrent code executions
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
US10528390B2 (en) 2016-09-23 2020-01-07 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US10592269B2 (en) 2017-07-24 2020-03-17 Amazon Technologies, Inc. Dynamic code deployment and versioning
US10564946B1 (en) 2017-12-13 2020-02-18 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10353678B1 (en) 2018-02-05 2019-07-16 Amazon Technologies, Inc. Detecting code characteristic alterations due to cross-service calls

Also Published As

Publication number Publication date
JP5513997B2 (en) 2014-06-04

Similar Documents

Publication Publication Date Title
US10326653B2 (en) Method for upgrading network functions virtualization application, service forwarding method, and apparatus
US9999030B2 (en) Resource provisioning method
Butzin et al. Microservices approach for the internet of things
US9037899B2 (en) Automated node fencing integrated within a quorum service of a cluster infrastructure
US9015177B2 (en) Dynamically splitting multi-tenant databases
US20180322162A1 (en) Query dispatch and execution architecture
US9454469B2 (en) Cloud-based test execution
CN102567015B (en) For performing the method and system that dynamic software version is selected
JP5789640B2 (en) System for managing program execution by multiple computer systems
US8726280B2 (en) Method and system for autonomic application program spawning in a computing environment
JP5306523B2 (en) Method for managing communication terminal device, communication terminal, and communication system
US9634965B2 (en) System and method for providing a job manager for use with a cloud platform environment
US9338067B2 (en) Network resource deployment for cloud-based services
JP6026705B2 (en) Update management system and update management method
CN102427481B (en) System for managing cloud computing service and cloud computing management method
CN102426543B (en) Hard and soft restriction is used to be placed on main frame by object
US9794352B2 (en) Network function virtualization service chaining
US8209415B2 (en) System and method for computer cloud management
EP3053052B1 (en) Managing a number of secondary clouds by a master cloud service manager
US7213065B2 (en) System and method for dynamic server allocation and provisioning
JP4496093B2 (en) Remote enterprise management of high availability systems
US7426737B2 (en) Method and apparatus for operating an open API network having a proxy
DE102004052270B4 (en) Processing device management system
EP3170071A1 (en) Self-extending cloud
US7434220B2 (en) Distributed computing infrastructure including autonomous intelligent management system

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