1 / 8

Solution for Sharing existing Node Instance

Solution for Sharing existing Node Instance. Problem Statement.

dory
Télécharger la présentation

Solution for Sharing existing Node Instance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Solution for Sharing existing Node Instance

  2. Problem Statement • TOSCA supports deployment of Apps in a cloud environment, and one user can deploy many Apps which may be co-related with each other. One of the way to co-relate one App with the other is that the two Apps actually share one resource. • Take database as an example, App1 and App2 can share one mySql server instance with two separate DBs, or further, with the same DB (but new tables may be created for the later App) • This contribution will explain the solution of supporting two Apps sharing the same resource with TOSCA: • Assumption: For simplicity, App1 and App2 are deployed by the same user/deployer • Problem to resolve: App1 and App2 share the same DB in one mySql server • Extensions necessary to TOSCA • Impacts/modifications to Plans of App1 and App2 • Concrete proposal to TOSCA will be provided after discussion of this contribution.

  3. App2 Shares existing DB Instance with App1 ServiceTemplate of App1 Instance of App1 • Step 0: Deploy App1 • Instance of App1 is created • A Database named i-DB1 is created with tables such as Employee. ConnectTo App 1 i-App 1 DB1 i-DB1 • DB: SugarCRM • Tables: • Employee • … Step 0 HoseOn HoseOn Now I want to deploy another application App2, which will reuse the database created for App1, and will add one more table named Customer in the database. Apache mySql i-Apache i-mySql Step 1 ServiceTemplate of App2 Referencing to existing node instance • Step 1: Modify the NodeTemplate of DB2 to reference to existing node instance i-DB1 of i-App1 • i-App2 will reuse the database created for i-App1, and will create one more table named Customer ConnectTo App 2 DB2 MySQL-CustomerTable MySQL-CustomerTable HoseOn A new table is created Apache Instance of App2 Step 2 ConnectTo i-App 2 i-DB1 • Step 2: Deploy App2 • Instance of App2 is created, which is i-App2 • The instance is connected to i-DB1, and further, a new table named Customer is created • DB: SugarCRM • Tables: • Employee • Customer • … Reference to i-DB1 D- Artifacts i-Apache

  4. Describe App2 With 1. Define a new ArtifactType, which indicates an ArtifactTemplate of this type actually references to an existing Node instance <ArtifactType name="ExistingResourceArtifact" targetNamespace="http://docs.oasisopen.org/tosca/ns/2011/12/Artifacts"/> 2. Define an ArtifactTemplate of this ArtifactType, referencing to existing node instance <ArtifactTemplate id="MySQLAT" type="ExistingResourceArtifact "> <ArtifactReferences> <ArtifactReference reference=“i-app1. i-DB1 "/> </ArtifactReferences> </ArtifactTemplate> Extension to TOSCA 3. Modify NodeTemplate of AppB.DB2 <NodeTemplate id=“MySql" nodeType="MySQLServer"> <DeploymentArtifacts> <DeploymentArtifact name=" MySQLDA" artifactType=" ExistingResourceArtifact" artifactRef=" MySQLAT"/> <DeploymentArtifact name=" MySQL-CustomerTable" artifactType=" mySqlScript" artifactRef=" MySQL-CustomerTable .sql"/> </DeploymentArtifacts> … //other definitions  </NodeTemplate>

  5. Further Modification to App2 • If App2 is developed with the idea to share an known existing instance node, then we can assume that App2 is ready for direct deployment. • But if App2 is developed as a brand-new app, and only when deployment, the deployer hopes to make it share an existing instance node, then at least the following stuff should be modified. • Build Plan • Not to create a new DB, but to connect to existing i-DB1 • Remove Plan • Not to remove i-DB1, but only delete table Customer (which was created by the deployment artifact of App2.DB2

  6. Modification to App1 Since now App2 and App1 share the same database ( and are still two separate apps), it’s necessary to check the state of App2 before executing any operations of APP1 that will impact the database. For instance, the precondition to execute Remove operation of App1 is to check whether App2 is removed. <Plan id=“remove“> <PreConditionexpressionLanguage="www.example.com/text"> The state of app2 is REMOVED </PreCondition> </ Plan >

  7. Simplified Process Flow Client Container MySQL(VM) 1 Get id of node instance i-App1.i-DB1 2 Modify App2 ST 3 Deploy App2 4 Get connection information of MySQL 5 Execute MySQL-CustomerTable.sql, create Customer table in i-App1.i-DB1 6 OK 7 OK

More Related