WO2015088317A1

WO2015088317A1 - System and method for dynamic update through runtime injection

Info

Publication number: WO2015088317A1
Application number: PCT/MY2014/000166
Authority: WO
Inventors: VADIOALOO Ashokumar A/L; Chee Foo LEONG; ALI Norazman Bin MAT
Original assignee: Mimos Berhad
Priority date: 2013-12-11
Filing date: 2014-06-05
Publication date: 2015-06-18

Abstract

A system (100, 100a) and method (200) for dynamic update through runtime injection comprising: on receiving a user request for running of an application on a cloud ecosystem, sending a request from an SaaS platform to an laaS platform (201); launching images based on a golden image stored in a node controller of said laaS platform (202); segregating said images between a plurality of nodes of said laaS platform depending on storage availability (203, 204); checking for updates (205, 206); and updating images (214).

Description

SYSTEM AND METHOD FOR DYNAMIC UPDATE THROUGH RUNTIME INJECTION FIELD OF INVENTION

The present invention relates to a system and method for dynamic update through runtime injection. In particular the invention relates to systems and methods for dynamic update on a single running instance or multiple running instances of an application within an ecosystem through runtime injection.

BACKGROUND ART

In an integrated application execution within the SaaS ecosystem, any update to the ecosystem profile or components on a static golden image requires profile rebuilding to introduce the new elements into the ecosystem. This is time consuming due to profile rebuilding for administration and requires down-time for users (i.e. the system will not be accessible). Also, during the rebuilding process, ecosystems such as Mi-SaaS cannot spawn new instances. United States Patent Publication No. 2006/0174238 entitled "Updating software images associated with a distributed computing system" describes updating images running on computing nodes within a distributed computing system. For example, a distributed computing system comprises a plurality of application nodes, a software image repository and a control node interconnected via a network. The image repository stores a master software image and a plurality of software image instances generated from the master software image. The control node automatically updates each of the software image instances using an updated version of the master software image.

United States Patent Publication No. 2007/0276916 entitled "Methods and systems for updating clients from a server" describes a method of updating clients from a server. The method includes maintaining a master copy of a software on a server and capturing changes to the master copy of the software on an update disk image, where the changes are contained in at least one chunk. The method also includes merging the update disk image with one of two client disk images of the client copy of the software.

United States Patent Publication No. 2009/0125897 entitled "Systems and Methods for Updating Device Software" describes methods and systems for updating device software, including a method for updating an information handling system, the method comprising: rebooting the information handling system; loading operational software for operating the information handling system; applying one or more updates to the operational software to obtain updated operational software; and executing the updated operational software.

It would be advantageous if a system and method could be devised that facilitate automated, on the fly, runtime ecosystem update with the need for profile rebuilding. The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practice.

SUMMARY OF INVENTION

The present invention relates to a system and method for dynamic update through runtime injection. In particular, the invention relates to systems and methods for dynamic update on a single running instance or multiple running instances of an application within an ecosystem through runtime injection.

One aspect of the present invention provides a system for dynamic update through runtime injection. The system comprising at least one SaaS platform adapted to receive a user request for running of an application on a cloud ecosystem; at least one laaS platform adapted to receive said request from said SaaS platform; at least one node controller of said laaS platform for storing a golden image based on which images are to be launched; and a plurality of nodes of said laaS platform between which said images are to be segregated depending on storage availability.

Another aspect of the present invention provides a method for dynamic update through runtime injection. The method comprising steps of sending a request from an SaaS platform to an laaS platform on receiving a user request for running of an application on a cloud ecosystem; launching images based on a golden image stored in a node controller of said laaS platform; segregating said images between a plurality of nodes of said laaS platform depending on storage availability; checking for updates; and updating images through runtime injection. The step for updating images through runtime injection further comprises steps of updating of newly launched images; updating existing instances; escalating and communicating cloud updates availability to multiple peer agents; performing updates and detecting faults; and notifying update failures.

Another aspect of the invention provides a method wherein updating of newly launched images comprises steps of identifying an application instance based on SaaS cloud component type, any updates on the laaS being handled by an SaaS component update; accessing application typesets in an SaaS cloud update central repository; obtaining a cloud instance machine's address assigned previously by an laaS cloud controller; transferring all SaaS cloud updates of the particular instance type using the push method; identifying whether to recommend optimization on rebuilding the instance cloud's Golden image or maintain the peer-forwarding updates; recommending optimisation of the golden image based on total update file size and total updating duration if it is confirm to recommend optimization on rebuilding the instance cloud's Golden image or maintain the peer-forwarding updates; updating the selected Golden image by launching it as a new cloud instance in Cloud laaS infrastructure for cloud instance image rebuilding; uploading the updated instance into the cloud controller for cloud re-caching (on newly updated cloud golden images) and destroying the obsolete image; monitoring the local SaaS cloud component and application update progress; and logging and alerting on any errors to Platform Administration.

A further aspect of the invention provides a method wherein updating existing instances comprises steps of checking on new SaaS cloud components and application updates availability based on broadcast information; checking for cloud updates in repository in accordance with scheduling at predefined time if turned on; comparing SaaS cloud components' version installed on local instance with cloud updates list; deciding on obtaining SaaS cloud component updates from a peer agent (message sender - peer forwarding) or from a centralized cloud repository; triggering pulling of all updates of a particular instance using the push method; monitoring a local cloud component and its application update progress; and checking if changes require restarting of local services or rebooting of any SaaS cloud components or VM (virtual machine) instances.

Yet another aspect of the invention provides a method wherein escalating and communicating cloud updates availability to multiple peer agents further comprises steps of communicating (broadcast messages) to other peer agents on SaaS cloud components or application update availability (peer forwarding); receiving confirmation a peer agent will further relay the same messages (peer forwarding) to other peer agents on its list within the same laaS infrastructure cloud group or network subnets; receiving confirmation a peer agent will determine SaaS cloud components and application update types and create update job on local system if update type relevant to a hosting machine; cancelling messages relaying and deleting this when the exact same message ID is re-received by the same agent; identifying the sending agents and making TCP connection request to check on server availability to acquire the SaaS cloud and application updates from sending peer (Master Agent), whereby sending peers can host the updates and become peer-repository; ignoring and not accepting peer TCP connection request when the local host is not ready or is in a busy state, the requesting agent trying to obtain the updates from the identified cloud central repository once the peer connection request is rejected or failed; updating content SaaS cloud files key which identifies the versions, size and date-time of the updates; and optionally, receiving peer-agents obtaining SaaS component updates from multiple sources either from multiple agents or from a centralized laaS cloud repository at the same time to speed up file collection.

Another aspect of the invention provides a method wherein performing updates and detecting faults comprises steps of grabbing the SaaS components cloud update list and files from other peers or from a repository depending on the peers' availability; if a peer is not available, getting this from the cloud central repository; triggering a local update; monitoring local SaaS component update progress; marking update stages on cloud component errors / faults including agent's logs; triggering rollback procedures upon SaaS cloud components and application update failure; and reporting rollback status (success or failures) to Platform Admin.

A further aspect of the invention provides a method wherein notifying update failures further comprises steps of triggering an 'alert notification' when a fault is detected; informing a Master Agent (update origins - sender peers) on failures; receiving fault details by said Master Agent from reporting agents; said Master Agent relaying error messages with statuses and states to peer agents on the same net (peer forwarding), the SaaS's cloud component updating each failure with its own logs and states for further analysis, including its stop / halt location; stopping updating relevant peer agent local and perform rollback upon confirmation from the Master Agent; receiving peers cancelling the messages if not relevant (such as on different cloud SaaS component types) or if said messages are already received; receiving peers further relaying fault messages to its subnets or infrastructure laaS cloud groups for first time messages received; relevant peers signalling rollback status (success or failure) to SaaS or laaS cloud Platform Admin for conciliation and update logs coverage; and sending error / fault logs to Platform Admin for further troubleshooting by said Master Agent

The present invention consists of features and a combination of parts hereinafter fully described and illustrated in the accompanying drawings, it being understood that various changes in the details may be made without departing from the scope of the invention or sacrificing any of the advantages of the present invention.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

To further clarify various aspects of some embodiments of the present invention, a more particular description of the invention will be rendered by references to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the accompanying drawings in which: FIG. 1 illustrates the system of an embodiment of the invention.

FIG. 1a illustrates a simplified diagram of the architecture of the invention.

FIG. 2 illustrates a flowchart of the method of updating newly launched instances of an embodiment of the invention.

FIG. 2a illustrates a diagram of the method of updating newly launched instances of an embodiment of the invention. FIG. 3 illustrates a flowchart of the method of updating running instance using peer- forwarding.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a system and method for dynamic update through runtime injection. In particular the invention relates to systems and methods for dynamic update on a single running instance or multiple running instances of an application within an ecosystem through runtime injection.

Hereinafter, this specification will describe the present invention according to the preferred embodiments. It is to be understood that limiting the description to the preferred embodiments of the invention is merely to facilitate discussion of the present invention and it is envisioned without departing from the scope of the appended claims.

Referring to Figure 1 and 1a, the overall system 100 includes SaaS platform 110 and laaS platform 120. The SaaS platform 110 includes a webserver 111 , an application server 112 and a database server 113. The laaS platform 120 includes a Node Controller server 121 and a plurality of nodes 122 with dedicated storage 123 attached to each node 122. Once user makes a request for a desired set of servers to run their application on the cloud ecosystem, the SaaS platform 110 sends the request to the laaS platform 120. The laaS platform 120 then launches the images 130 based on the golden image stored in the node controller 121. The golden image is a workable, good and updated master copy that will be duplicated and cloned as a new instance based on a request. The golden image further comprising a clone image, said clone image is a new instance launched from the golden image by laaS platform based on a request. The images 130 are segregated between the nodes 122 equally depending on the storage 123 availability. Once the image 130 is up, the agent checks for updates and updates the images 130.

Referring to Figure 2 and Figure 2a, a method 200 of updating a newly launch instance is illustrated. Upon user request for a new instance 20 , the system triggers the creation of a new instance 202 using cloud infrastructure. The cloud instance starts up and agent starts, attaching cloud allocated disk volume 203 and the system assigns cloud group, cloud private IP, cloud public IP to the particular newly launched instance 204. The agent identifies cloud instance type 205 and searches for idle Peer repository or central cloud repository 206. The agent then engages connection to the cloud peers or central repository through instance cloud private IP 207.

After the agent finishes collecting the updates based on the update list of the particular instance cloud component type using the SCP method 208, the agent the verifies if the updates recommended rebuilding of a Golden image 209 and verifies whether the updates are runtime or non-runtime updates 210 and whether these updates require any service restart 211. Service restart 212 and instance reboot 213 will be executed accordingly and the updates process is completed 214.

Referring to Figure 3, a method 300 of updating running instance using peer-forwarding is illustrated. This method 300 has two entry points, one of which is scheduler-based 301 and another through peer-forwarding 302. The instance's agent listens on update availability on a Peer-Forwarding command channel 303. Update available news is determined 304. Whenever there is update available news, the agent identifies whether the updates have already been executed or new updates are present that require implementation 305. The agent verifies the news updates and determines whether this should be considered a fault peer-forwarding 306. If the news update is a fault alert, the agent halts any related update process 307 and performs a peer-forwarding fault message 317 and rollback on any updated changes 308.

If the news update is not a fault alert, the agent broadcasts to another of the same subnet or cloud group peer on this news update 309 and checks whether the new update is from cloud peers or the cloud repository 310 and compares the cloud component versions, keys, size, datetime with local system component types 311. This identifies whether the update is available and is a relevant cloud component type 312. Upon complete verification with confirmation to implement, the system engages connection to either the peer repository or the central cloud repository 313 and retrieves and stores packages 314 while the agent monitors the progress and states of the host 315. If the updates fail 316, the agent will perform a peer-forwarding fault message 317 and rollback activity 308. Otherwise, the agent identifies the necessity to restart service or reboot instance 318 and the restart or reboot performed accordingly 319. Unless the context requires otherwise or specifically stated to the contrary, integers, steps or elements of the invention recited herein as singular integers, steps or elements clearly encompass both singular and plural forms of the recited integers, steps or elements.

Throughout this specification, unless the context requires otherwise, the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated step or element or integer or group of steps or elements or integers, but not the exclusion of any other step or element or integer or group of steps, elements or integers. Thus, in the context of this specification, the term "comprising" is used in an inclusive sense and thus should be understood as meaning "including principally, but not necessarily solely".

It will be appreciated that the foregoing description has been given by way of illustrative example of the invention and that all such modifications and variations thereto as would be apparent to persons of skill in the art are deemed to fall within the broad scope and ambit of the invention as herein set forth.

Claims

1. A system (100) for dynamic update through runtime injection comprising:

at least one SaaS platform (110) adapted to receive a user request for running of an application on a cloud ecosystem;

at least one laaS platform (120) adapted to receive said request from said SaaS platform;

at least one node controller (121) of said laaS platform for storing a golden image based on which images are to be launched; and a plurality of nodes (122) of said laaS platform between which said images are to be segregated depending on storage availability.

2. A system (100) as claimed in claim 1 , wherein said golden image is a workable, good and updated master copy that will be duplicated and cloned as a new instance based on a request.

3. A system (100) as claimed in claim 1 , wherein said golden image further comprising a clone image, said clone image is a new instance launched from the golden image by said laaS platform based on a request.

4. A method (200) for dynamic update through runtime injection comprising:

sending a request from SaaS platform to laaS platform on receiving a user request for running of an application on a cloud ecosystem (201); launching images based on a golden image stored in a node controller of said laaS platform (202);

segregating said images between a plurality of nodes of said laaS platform depending on storage availability (203, 204);

checking for updates (205, 206); and

updating images through runtime injection (214)

characterized in that

updating images through runtime injection (214) further comprises steps of:

updating of newly launched images; updating existing instances;

escalating and communicating cloud updates availability to multiple peer agents;

performing updates and detecting faults; and notifying update failures.

5. A method as claimed in claim 4, wherein updating of newly launched images further comprises steps of:

identifying an application instance based on SaaS cloud component type, any updates on the laaS being handled by an SaaS component update

(205) ; accessing application typesets in an SaaS cloud update central repository

(206) ; obtaining a cloud instance machine's address assigned previously by an laaS cloud controller (207); transferring all SaaS cloud updates of the particular instance type using the push method (208); identifying whether to recommend optimization on rebuilding the instance cloud's Golden image or maintain the peer-forwarding updates (209); recommending optimisation of the golden image based on total update file size and total updating duration if it is confirm to recommend optimization on rebuilding the instance cloud's Golden image or maintain the peer-forwarding updates (210); updating the selected Golden image by launching it as a new cloud instance in Cloud laaS infrastructure for cloud instance image rebuilding (211); uploading the updated instance into the cloud controller for cloud re- caching (on newly updated cloud golden images) and destroying the obsolete image (214); monitoring the local SaaS cloud component and application update progress; and logging and alerting on any errors to Platform Administration.

A method as claimed in claim 4, wherein updating existing instances (300) further comprises steps of: checking on new SaaS cloud components and application updates availability based on broadcast information (303); checking for cloud updates in repository in accordance with scheduling at predefined time if turned on (304); comparing SaaS cloud components' version installed on local instance with cloud updates list (311); deciding on obtaining SaaS cloud component updates from a peer agent (message sender - peer forwarding) or from a centralized cloud repository (312); triggering pulling of all updates of a particular instance using the push method. monitoring a local cloud component and its application update progress; and checking if changes require restarting of local services or rebooting of any SaaS cloud components or VM (virtual machine) instances (318).

A method as claimed in claim 4, wherein escalating and communicating cloud updates availability to multiple peer agents further comprises steps of: communicating (broadcast messages) to other peer agents on SaaS cloud components or application update availability (peer forwarding); receiving confirmation a peer agent will further relay the same messages (peer forwarding) to other peer agents on its list within the same laaS infrastructure cloud group or network subnets; receiving confirmation a peer agent will determine SaaS cloud components and application update types and create update job on local system if update type relevant to a hosting machine; cancelling messages relaying and deleting this when the exact same message ID is re-received by the same agent; identifying the sending agents and making TCP connection request to check on server availability to acquire the SaaS cloud and application updates from sending peer (Master Agent), whereby sending peers can host the updates and become peer-repository; ignoring and not accepting peer TCP connection request when the local host is not ready or is in a busy state, the requesting agent trying to obtain the updates from the identified cloud central repository once the peer connection request is rejected or failed; updating content SaaS cloud files key which identifies the versions, size and date-time of the updates; and receiving peer-agents obtaining SaaS component updates from multiple sources either from multiple agents or from a centralized laaS cloud repository at the same time to speed up file collection.

8. A method as claimed in claim 4, wherein performing updates and detecting faults further comprises steps of: grabbing the SaaS components cloud update list and files from other peers or from a repository depending on the peers' availability; if a peer is not available, getting this from the cloud central repository; triggering a local update; monitoring local SaaS component update progress; marking update stages on cloud component errors / faults including agent's logs; triggering rollback procedures upon SaaS cloud components and application update failure; and reporting rollback status (success or failures) to Platform Admin.

9. A method as claimed in claim 4, wherein notifying update failures further comprises steps of: triggering an 'alert notification' when a fault is detected; informing a Master Agent (update origins - sender peers) on failures; receiving fault details by said Master Agent from reporting agents; relaying error messages with statuses and states to peer agents on the same net (peer forwarding) by the said Master Agent, the SaaS's cloud component updating each failure with its own logs and states for further analysis, including its stop / halt location; stopping updating relevant peer agent local and perform rollback upon confirmation from the Master Agent; receiving peers cancelling the messages if not relevant (such as on different cloud SaaS component types) or if said messages are already received; receiving peers further relaying fault messages to its subnets or infrastructure laaS cloud groups for first time messages received; relevant peers signalling rollback status (success or failure) to SaaS or laaS cloud Platform Admin for conciliation and update logs coverage; and sending error / fault logs to Platform Admin for further troubleshooting by said Master Agent.