WO2021086169A1

WO2021086169A1 - Method and system for orchestration of virtual machine (vm) tenants in multi-tenant cloud for enabling non-silo communication

Info

Publication number: WO2021086169A1
Application number: PCT/MY2020/050093
Authority: WO
Inventors: Shahrol Hisham BAHAROM; Sharipah Setapa; Saliza HASAN; Jing Yuan Luke; Hong Hoe ONG
Original assignee: Mimos Berhad
Priority date: 2019-10-29
Filing date: 2020-09-28
Publication date: 2021-05-06

Abstract

The present invention discloses a method and a system for orchestration of virtual machine (VM) tenants, either from public cloud or private cloud, who share workload resources in a multi-tenant cloud to enable a non-silo communication. The system comprises a VM tracking member for receiving an access request to an application from the VM tenants and for identifying parameters of the VM tenants to detect any silo VM tenant; an orchestra module for establishing a first, a second and a third orchestra; a clone checking gateway member for determining validity of network connectivity and preparing secure phrases for the VM tenants based on a secure phrase information of the SLA; and a connection role gateway member for retrieving a degree of role from the SLA to grant an access permit to the VM tenants who correctly answer a challenge-response test for accessing the application.

Description

METHOD AND SYSTEM FOR ORCHESTRATION OF VIRTUAL MACHINE (VM) TENANTS IN MULTI-TENANT CLOUD FOR ENABLING NON-SILO

COMMUNICATION

FIELD OF THE INVENTION

The present invention relates generally to cloud orchestration. More particularly, the present invention relates to an improved method and system for orchestration of virtual machine (VM) tenants in a multi-tenant cloud for enabling a non-silo communication.

BACKGROUND OF THE INVENTION

Cloud computing is essentially for delivery of on-demand computing resources which include everything from application to data centers, over the Internet on an on-demand, and on pay-for-use basis through a cloud service platform. It remains a powerful technology which enables computing over the internet. Enterprises use it frequently to lower their capital costs, and day-to-day expenses, while enabling online powerful applications. Organizations often use a combination of public cloud, and private cloud solutions in what is termed hybrid cloud, and commonly have more than one cloud provider, which is known as multi-cloud.

A multi-tenant cloud is a cloud computing architecture that allows customers to share computing resources in a public or private cloud. Each tenant's data is isolated and remains invisible to other tenants. In this cloud environment, multiple tenants share hardware and software resources to reduce costs and complexity while increasing performance and efficiency. Cloud orchestration refers to the arrangement and coordination of automated tasks resulting in a consolidated process or workflow across both public and private cloud solutions. It allows organizations to accelerate delivery for new innovations, applications, and hybrid infrastructure by orchestrating processes across domains, systems, and teams.

By way of background, United States Patent 9,053,162 B2 (hereinafter “the Ί62 patent”) discloses a multi-tenant hosted application system. According to the Ί62 patent, the server computers utilized to provide the hosted application are organized into logical groupings of server computers called scale groups. One or more tenants are assigned to each scale group. When a new tenant is provisioned, the tenant is assigned to a scale group and a database server in the assigned scale group creates a database for the tenant. An association between the tenant and the scale group is also created in a shared configuration database. In the Ί62 patent, when a request is received from a tenant to access the hosted application, the shared configuration database is consulted to locate the scale group hosting the tenant. Once the appropriate scale group has been located, the request is redirected to the appropriate scale group for processing.

Designing and managing multi-tenant clouds has its own challenges. In one multi-tenant cloud, virtual machine (VM) tenants from public cloud and private cloud may have a same schema for connecting to their applications. VM tenants from these two different clouds may have the same media access control (MAC) address and Internet Protocol (IP) address for their respective devices inside the tenants - which makes it difficult to trace or identify the actual source. This also results in silo communication problems of VM tenants that further hinders resource orchestration between VM tenants. Furthermore, each VM tenant may connect to multiple organizations rendering the management of such cloud environments a very complex task from security, traffic management, reliability, and extensibility aspects. It might cause certain damages on software should anything happen to VM tenants or multi tenant applications.

It would therefore be advantageous to provide a solution that would overcome the deficiencies of the prior art by providing improved orchestration of VM tenants in a multi-tenant cloud.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Accordingly, the present invention provides a method for orchestration of virtual machine (VM) tenants sharing resources in a multi-tenant cloud. The method of the present invention which enables a non-silo communication may be characterized by the steps of receiving an access request to an application from the VM tenants with registration of a service level agreement (SLA) that defines a secure phrase information; identifying, by a VM tracking member, parameters associated with the VM tenants including Internet Protocol (IP) address, ports and media access control (MAC) address and network connectivity associated with the VM tenants; detecting any of the VM tenants running in silo by comparing the IP address and the MAC address of the VM tenants with each other; establishing a first orchestra based on the parameters and the SLA thereby subjecting the VM tenants to the first orchestra; establishing a second orchestra interconnected with the first orchestra through a foreground communication; determining, by a clone checking gateway member, validity of the network connectivity by comparing against the SLA registered thereof; preparing, by the clone checking gateway member, secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA; subjecting the VM tenants having the network connectivity validated and the secure phrases prepared to the second orchestra; establishing a third orchestra interconnected with the second orchestra; retrieving, by a connection role gateway member, a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra; subjecting the VM tenants having the degree of role retrieved to the third orchestra; and granting, by the connection role gateway member, an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof, wherein the said VM tenants answer a correct secure phrase in response to a challenge-response test raised by the connection role gateway member.

Preferably, the method includes the step of conducting the challenge- response test prior to the step of granting an access permit.

Preferably, the step of preparing secure phrases includes checking with a workload database connected to the clone checking gateway member for avoiding secure phrase duplication.

Preferably, the step of granting an access permit comprises preparing the access permit for accessing the application granted to a plurality of VM tenants has no overlapping degree of role. Accordance with another aspect of the present invention, a system for orchestration of VM tenants sharing resources in a multi-tenant cloud is provided.

The system of the present invention which enables a non-silo communication may be characterized by a VM tracking member configured for receiving an access request to an application from the VM tenants with registration of a SLA that defines a secure phrase information, wherein the VM tracking member identifies parameters associated with the VM tenants including IP address, ports and MAC address and network connectivity associated with the VM tenants, wherein the VM tracking member detects any of the VM tenants running in silo by comparing the IP address and the MAC address of the VM tenants with each other; an orchestra module configured for establishing a first orchestra, a second orchestra and a third orchestra, wherein the first orchestra is created based on the parameters and the SLA, wherein the second orchestra is interconnected with the first orchestra through a foreground communication, wherein the third orchestra is interconnected with the second orchestra; a clone checking gateway member configured for determining validity of the network connectivity by comparing against the SLA registered thereof, wherein the clone checking gateway member prepares secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA, wherein the clone checking gateway member is associated with the second orchestra comprising the VM tenants having the network connectivity validated and the secure phrases prepared; and a connection role gateway member configured for retrieving a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra, wherein the connection role gateway member grants an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof, wherein the said VM tenants answers a correct secure phrase in response to a challenge-response test raised by the connection role gateway member, wherein the connection role gateway member is associated with the third orchestra comprising the VM tenants having the degree of role retrieved.

The foregoing and other objects, features, aspects and advantages of the present invention will become better understood from a careful reading of a detailed description provided herein below with appropriate reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendant advantages thereof will be readily as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

Figure 1 is a flow diagram depicting a method for orchestration of VM tenants sharing resources in a multi-tenant cloud according to one embodiment of the present invention;

Figure 2 is a flow diagram depicting the step of establishing a first orchestra based on the parameters and the SLA thereby subjecting the VM tenants to the first orchestra according to one embodiment of the present invention;

Figure 3 is a flow diagram depicting the step of establishing a second orchestra interconnected with the first orchestra through a foreground communication according to one embodiment of the present invention;

Figure 4 is a flow diagram depicting the step of determining, by a clone checking gateway member, validity of the network connectivity by comparing against the SLA registered thereof according to one embodiment of the present invention;

Figure 5 is a flow diagram depicting the step of preparing, by a clone checking gateway member, secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA according to one embodiment of the present invention;

Figure 6 is a flow diagram depicting the step of establishing a third orchestra interconnected with the second orchestra according to one embodiment of the present invention;

Figure 7 shows a system for orchestration of VM tenants sharing resources in a multi-tenant cloud according to one embodiment of the present invention;

Figure 8 shows an operation of the system of Figure 7 according to one exemplary embodiment of the present invention; and Figure 9 shows a CAPTCHA searching mechanism for trust according to one exemplary embodiment of the present invention.

It is noted that the drawings may not be to scale. The drawings are intended to depict only typical aspects of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numberings represent like elements between the drawings.

DETAILED DESCRIPTION OF THE INVENTION

Essentially, the present invention provides a method and a system for orchestration of virtual machine (VM) tenants, either from public cloud or private cloud, who share workload resources in a multi-tenant cloud to enable a non-silo communication. The present invention is capable of connecting and emulating the entire tenancy to be in a same orchestra regardless of whether the VM tenants are private or public tenancy. All resources must be identified before the orchestration can be implemented. Both the clouds, i.e. private and public clouds, are essential to be identified so as to obtain a role degree in respect of read, write or full access permissions.

According to one preferred embodiment of the present invention, the method for orchestration of VM tenants sharing workload resources in the multi-tenant cloud is shown in a flow diagram of Figure 1. The method preferably begins with the step 100 of receiving an access request to an application from the VM tenants. At this step, the VM tenants also shall proceed with submission of a service level agreement (SLA) which defines a secure phrase information during registration into an organization. The secure phrase information preferably comprises a set of secure phrases in sequence.

Upon receiving the access request from the VM tenants, a VM tracking member 200 will be triggered. In step 101 , the VM tracking member 200 initiates identification of parameters that are associated with the VM tenants. These parameters include, but are not limited to, Internet Protocol (IP) address, ports and media access control (MAC) address as well as network connectivity associated with the VM tenants thereof. By collecting the parameters, it enables the present invention to identify whether the VM tenants are located in private cloud or public cloud by reviewing tenant backgrounds and structures of network behavior. These useful parameters shall be adopted in the course of designing an appropriate structure of an orchestra. The proposed orchestra structure is used to create an “impression” that those VM tenants are situated in the same location.

Following the collection of the parameters thereof, the method of the present invention provides detection of the VM tenants who run in silo (or silo communication) in step 102. It is preferred that the detection of silo VM tenants is completed by way of comparing the IP address and the MAC address of the VM tenants with each other. The silo VM tenant will be detected if the VM tenant has a same IP address and/or a same MAC address as that of other VM tenants. The silo VM tenant and its records such as tenancy, logging and processing data will be recorded and stored in a workload database for review and further analysis.

Once the parameters, the network connectivity and the SLA are collected, a first orchestra will be established in step 103. The first orchestra is preferably configured to distinguish and differentiate paths of the VM tenants whether the path is public to private or the path is private to public. The VM tenants subsequently will be subjected or assigned to the first orchestra thereof. The above establishment of the first orchestra is shown in Figure 2. According to Figure 2, the parameters associated with the VM tenants with registration of SLA will be identified prior to creation of the first orchestra which shall be based on the parameters and the SLA. A checking as to whether the first orchestra has been interconnected with those parameters will be made. This is important to check link interoperability for multiple orchestra. If the first orchestra has not been interconnected, then the creation of the first orchestra will be denied and shall be subject to revision. The revision, for instance, may involve modification of the SLA to support orchestra initialization and retrieval for the next orchestra. If the first orchestra has been interconnected, then the creation of the first orchestra will be allowed and the first orchestra will be established and provisioned.

The method of the present invention further provides the step 104 of establishing a second orchestra. It is preferred that the second orchestra is interconnected with the first orchestra through a foreground communication. It is preferred that the first orchestra communicates with the second orchestra to obtain the foreground communication between these two orchestra which will be utilized for legal communication. The second orchestra is preferably configured for setting up a challenge and a response on a mutual and synchronous manner for use during a negotiation of a Completely Automated Public Test to tell Computers and Humans Apart (CAPTCHA). It is crucial to note that only related VM tenants are allowed to be assigned to the second orchestra. According to Figure 3, the connection with orchestra having different profiles and structures will be activated. The activation is preferably made once the creation of the second orchestra having interconnection with another working orchestra is initiated. A foreground communication will be initialized to find a suitable orchestra to match, e.g. the first orchestra to match with the second orchestra. If the foreground communication is working, then the creation of the second orchestra interconnected with the first orchestra will be allowed and the second orchestra will be established and provisioned. If the foreground communication is not working, then a reconfiguration with another orchestra will be initiated that includes, but is not limited to, amendment of rules in the configuration to test any relevant orchestra.

In step 105, a clone checking gateway member 201 is adopted to determine validity of the network connectivity of the VM tenants thereof. The validity of the network connectivity is determined by way of comparing the same against the SLA registered thereof. The clone checking gateway member 201 preferably communicates with the workload database to validate that the network connectivity or connection is using a valid SLA in view of the SLA registered thereof. Figure 4 shows a flow diagram of step 105 and its sub-steps involved for determining validity of the network connectivity thereof. The identity of the first orchestra containing the VM tenants will be tracked. The VM tenants which bound private and public or vice versa will be identified. This information will be collected and recorded as historical data for profiling and in case the next orchestra is failed to accept the previous orchestra. Upon contact with the clone checking gateway member 201 , the validity of the network connectivity will be determined. At this stage, a modification towards the validation, response of which is received from the clone checking gateway member 201 is proposed to incorporate an acknowledgement of secure phrase thereto. The workload database is also cross-checked to retrieve the logging or processing data of the previous VM tenants in the first orchestra. Based on the input obtained from the workload database, the clone checking gateway member 201 will decide whether to allow the interconnectivity. Separately, the clone checking gateway member 201 will be cross-checked for the modification to incorporate an acknowledgement of secure phrase when communicating with the VM tenants from the first orchestra. The clone checking gateway member 201 is further configured for preparing secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA (see step 106). The clone checking gateway member 201 is responsible for checking a historical data of the VM tenants to avoid duplication of secure phrases. As shown in Figure 5, the connection with other orchestras having different profiles and structures will be activated. The activation is preferably made once the creation of the interconnection with the first orchestra is initiated. Subsequently, a secure phrase for immediate orchestra between the first orchestra and the second orchestra will be added. The added secure phrase will be cross checked if the elected secure phrase is working or not. If the secure phrase is not working, then a reconfiguration will be initiated that includes, but is not limited to, amendment of rules in the configuration to obtain another working secure phrase. If the secure phrase is working, then the first orchestra and the second orchestra will be executed and communication therebetween will be initialized.

Once the network connectivity is validated and the secure phrases are prepared, the VM tenants residing in the first orchestra will be subjected or assigned to the second orchestra thereof as shown in step 107.

In step 108, a third orchestra that is interconnected with the second orchestra will be established. The third orchestra is adopted to allow the VM tenants to access their respective application with a degree of role.

In relation to step 108, a connection role gateway member 202 is adopted. The connection role gateway member 202 is configured to retrieve a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra (see step 109). It is preferred that the connection role gateway member 202 filters the role (e.g. read, write or both) of the VM tenants requesting for access to their respective applications. The VM tenants will be assigned to the role based on the SLA. Once the degree of role is retrieved, these VM tenants will be subjected or assigned to the third orchestra in step 110.

The connection role gateway member 202 is further configured for granting an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof (see step 111). It is preferred that the connection role gateway member 202 prepares the access permit granted to a plurality of VM tenants for accessing the application has no overlapping degree of role between the plurality of VM tenants accessing the same application. The access permit is preferably granted if the VM tenants answer a correct secure phrase in response to a challenge-response test raised by the connection role gateway member 202. The challenge-response test is preferably conducted by connection role gateway member 202.

Figure 6 shows a flow diagram of step 108 and its sub-steps involved for establishing the third orchestra interconnected with the second orchestra. A communication with the connection role gateway member 202 will be established once the creation of the third orchestra having interconnection with various applications is initiated. Subsequently, a degree of role of each VM tenant will be retrieved and identified. Based on the degree of role, the connection role gateway member 202 will prepare and issue a corresponding access permit. If a VM tenant has an access permit, then the third orchestra will be executed alongside communication to the second orchestra. As a result, the said VM tenant will be allowed to access the requested application with a particular role. If a VM tenant has no access permit, then the said VM tenant will not be allowed to access the application. The role of the said VM tenant will be reviewed with the workload database and the connection role gateway member 202 for role matching.

According to another preferred embodiment of the present invention, the system, also known as “Cluster Connector Degree Gateway”, for orchestration of VM tenants is shown in a schematic diagram of Figure 7. In the embodiments discussed in the preceding paragraphs, the system of the present invention further comprises an orchestra module alongside the VM tracking member 200, the clone checking gateway member 201 and the connection role gateway member 202.

The VM tracking member 200 may be configured for receiving an access request to an application from the VM tenants with registration of SLA that defines a secure phrase information. The VM tracking member 200 identifies parameters associated with the VM tenants including IP address, ports and MAC address and network connectivity associated with the VM tenants. It is preferred that the VM tracking member 200 detects any of the VM tenants running in silo by comparing the IP address and the MAC address of the VM tenants with each other.

The orchestra module may be configured for establishing the first orchestra, the second orchestra and the third orchestra. The first orchestra is created based on the parameters and the SLA. The second orchestra is interconnected with the first orchestra through a foreground communication. The third orchestra is interconnected with the second orchestra.

The clone checking gateway member 201 may be configured for determining validity of the network connectivity by comparing the same against the SLA registered thereof. It is preferred that the clone checking gateway member 201 prepares secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA. The clone checking gateway member 201 is preferably associated with the second orchestra comprising the VM tenants having the network connectivity validated and the secure phrases prepared.

The connection role gateway member 202 may be configured for retrieving a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra. It is preferred that the connection role gateway member 202 grants an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof. In this regard, the said VM tenants answers a correct secure phrase in response to a challenge-response test raised by the connection role gateway member 202. The connection role gateway member 202 is preferably associated with the third orchestra comprising the VM tenants having the degree of role retrieved.

Figure 8 shows an example of operation of the system of the present invention. As can be seen, there is a plurality of VM tenants (e.g. VM 1 , VM 2, VM 3 and VM 4) from private cloud and public cloud that are ready to transmit an access request to multi-tenant applications. These VM tenants will be subject to the VM tracking member 200, the clone checking gateway member 201 and the connection role gateway member 202 where a first orchestra, a second orchestra and a third orchestra will be established accordingly. At the end of the cluster connector degree gateway, the VM tenants with an access permit (specifying a degree of role) are allowed to respectively access the requested multi-tenant applications. For instance, there are two VM tenants, i.e. VM 1 and VM 3, allowed to access Application 1 , but each granted with a different degree of role. The VM tenants preferably share the same Application 1 but with different degrees of role to execute the application although sharing the same resource. Figure 9 shows a CAPTCHA searching mechanism for trust that involves a plurality of CAPTCHAs implemented therein. Each VM tenant preferably has its own CAPTCHA which will be issued and produced during initialization of communication between the clone checking gateway member 201 and the VM tenants. If a wrong CAPTCHA is shown, then a communication is terminated and rebooted until a correct CAPTCHA is given based on profiling gathered from the SLA. At the beginning, the clone checking gateway member 201 initiates a search for CAPTCHA A. If CAPTCHA A is not found, then the clone checking gateway member 201 will look for CAPTCHA B and so forth. A state of waiting will be explored until a relevant or sequence is finalized. If any of CAPTCHAs has satisfied the requirement and meets the SLA, then the CAPTCHA will be selected. If there is no CAPTCHA is shown, then the connection will be terminated and proceed to a new registration.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Detailed description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The foregoing description, for the purpose of explanation, has been described with reference to specific example embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the possible example embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The example embodiments were chosen and described in order to best explain the principles involved and their practical applications, to thereby enable others skilled in the art to best utilize the various example embodiments with various modifications as are suited to the particular use contemplated.

It will also be understood that, although the terms “first,” “second,” and so forth may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present example embodiments. The first contact and the second contact are both contacts, but they are not the same contact. The terminology used in the description of the example embodiments herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used in the description of the example embodiments and the appended examples, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context.

Claims

1. A method for orchestration of virtual machine, VM, tenants sharing resources in a multi-tenant cloud, characterized in that, the method that enables a non-silo communication comprising the steps of: receiving an access request to an application from the VM tenants with registration of a service level agreement, SLA, that defines a secure phrase information (100); identifying, by a VM tracking member (200), parameters associated with the VM tenants including Internet Protocol, IP, address, ports and media access control, MAC, address and network connectivity associated with the VM tenants (101 ); detecting any of the VM tenants running in silo by comparing the IP address and the MAC address of the VM tenants with each other (102); establishing a first orchestra based on the parameters and the SLA thereby subjecting the VM tenants to the first orchestra (103); establishing a second orchestra interconnected with the first orchestra through a foreground communication (104); determining, by a clone checking gateway member (201), validity of the network connectivity by comparing against the SLA registered thereof (105); preparing, by the clone checking gateway member (201), secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA (106); subjecting the VM tenants having the network connectivity validated and the secure phrases prepared to the second orchestra (107); establishing a third orchestra interconnected with the second orchestra (108); retrieving, by a connection role gateway member (202), a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra (109); subjecting the VM tenants having the degree of role retrieved to the third orchestra (110); and granting, by the connection role gateway member (203), an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof (111), wherein the VM tenants answer a correct secure phrase in response to a challenge-response test raised by the connection role gateway member (202).

2. The method according to Claim 1 includes the step of conducting the challenge- response test prior to the step of granting an access permit.

3. The method according to Claim 1 , wherein the step of preparing secure phrases (106) includes checking with a workload database connected to the clone checking gateway member (201) for avoiding secure phrase duplication.

4. The method according to Claim 1 , wherein the step of granting an access permit (111) comprises preparing the access permit for accessing the application granted to a plurality of VM tenants has no overlapping degree of role.

5. A system for orchestration of virtual machine, VM, tenants sharing resources in a multi-tenant cloud, characterized in that, the system that enables a non-silo communication comprising: a VM tracking member (200) configured for receiving an access request to an application from the VM tenants with registration of a service level agreement, SLA, that defines a secure phrase information, wherein the VM tracking member (200) identifies parameters associated with the VM tenants including Internet Protocol, IP, address, ports and media access control, MAC, address and network connectivity associated with the VM tenants, wherein the VM tracking member (200) detects any of the VM tenants running in silo by comparing the IP address and the MAC address of the VM tenants with each other; an orchestra module configured for establishing a first orchestra, a second orchestra and a third orchestra, wherein the first orchestra is created based on the parameters and the SLA, wherein the second orchestra is interconnected with the first orchestra through a foreground communication, wherein the third orchestra is interconnected with the second orchestra; a clone checking gateway member (201) configured for determining validity of the network connectivity by comparing against the SLA registered thereof, wherein the clone checking gateway member (201) prepares secure phrases for each of the VM tenants based on the secure phrase information embedded in the SLA, wherein the clone checking gateway member (201) is associated with the second orchestra comprising the VM tenants having the network connectivity validated and the secure phrases prepared; and a connection role gateway member (202) configured for retrieving a degree of role indicating read permission, write permission or combination thereof from the SLA of the VM tenants residing in the second orchestra, wherein the connection role gateway member (202) grants an access permit stating the degree of role to the VM tenants residing in the third orchestra for allowing access to the application requested thereof, wherein the VM tenants answers a correct secure phrase in response to a challenge-response test raised by the connection role gateway member (202), wherein the connection role gateway member (202) is associated with the third orchestra comprising the VM tenants having the degree of role retrieved.