Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mapping Service Templates to Concrete Network Semantics Some Ideas.

Similar presentations


Presentation on theme: "Mapping Service Templates to Concrete Network Semantics Some Ideas."— Presentation transcript:

1 Mapping Service Templates to Concrete Network Semantics Some Ideas

2 Objective Derive concrete network semantics from a Service Template so the designer can have clear expectations of the resulting network topology – Logical Networks – Compute node attachment to LNs Dont specify the concrete topology with the service template (keep it declarative) – If you need to define a complete network topology separate infrastructure models are best used for this with simple projection from the Service Model to the Infrastructure Model via LNs 2

3 How should we talk about networking in a Service Template? Logical Networks enable logical connectivity between endpoints Compute nodes may require connectivity through Logical Networks (there may be un-modeled components on them) that must use the network EndPoints and Connection Relationships may require connectivity through specific: – Logical Networks specified by name or kind – Logical Networks with specific capabilities – Other semantics like isolation (still modeled as a LN capability) 3

4 Logical Network Attributes Kind – DMZ, Mgmt, App, Service, Backup, vMotion, DR, Provisioning, Boot, Monitoring, … Name – If you have more than one kind Capabilities – Private (namespaces) / Public (routable) – Services: DNS, DHCP, NTP, LB, [NFV]…. (IP services can be modeled in TOSCA more explicitly as endpoints) – Qualities: Isolation, bandwidth, delay, redundancy, security, … 4

5 Features Simple and declarative – EndPoints consume LNs Compartmentalized – Private by default Flow-based minimal connectivity – Connectivity is provisioned only when connectsTo relations appear – Allowed ports/protocols are concisely specified 5

6 6 SugarCRM Service SugarCRM Service Model Apache Web Server SugarCRM App PHP Module MySQL SugarCRM DB HTTP Client Application EndPoint HTTP Port 80 or 443 DocumentRoot:/SugarCRM Database client requires client credentials, DB Name, host and port Admin Access and/or Management Access possibly over separate isolated networks with different client credentials requires MySQL Client Endpoint Port 3306 Database content must be placed on storage of required capacity, availability and performance

7 7 Specify kind (or name) of network used by each Endpoint Apache Web Server SugarCRM App PHP Module MySQL SugarCRM DB requires Data Mgmt Public EndpointNetwork kind Sugar HTTP ServerPublic Sugar DB ClientData MySQL ServerData Apache Node SSHMgmt DBMS Node SSHMgmt Apache Node DNSService DBMS Node DNSService Mgmt could be implied or handled by the infrastructure

8 A few rules… EndPoints can be bound to Logical Networks by kind or by name. Named Logical Networks are useful when there exist more than one of a kind and can be modeled as node templates EndPoints with no logical network spec can be assumed associated with a default private network. I.e. all EndPoints in the same default are logically connected in the same L2 domain Tier isolation can be achieved by binding EndPoints of a tier to a tier specific LN. If two isolated tiers need to communicate, an L3 path can be provisioned automatically between the pair of LNs 8

9 Logical Networks avoid Specific IP address assignment and masking Specific interface bindings to LNs Specification of routers and route table configuration NAT (any suitable way to achieve the declarative requirements is fine) 9

10 We Cant Avoid Routing between logical networks in the deployment to/from external networks – But we can let the environment manage the translation and L3 configuration Binding public IP addresses to nodes which must be reachable from external networks – We still need a way to associate a set of public addresses to a set of EndPoints Awareness and synching with DNS – Some platforms can/will handle this for us 10

11 Can we still model the topology in more detail? Yes of course, but the question is why? – Not every environment will be able to support your topology Address spaces may be reserved, fragmented Makes the application less portable – The model becomes more complicated Do you really want to specify routers and route tables? Use NAT? Debug why it is not working in some cases Do we really have apps which require specific IP addressing? – The latest fabrics are separating network location from identity, minimizing L2 and STP, abstracting network functions, etc… If we must, lets take a stratified/layered approach – Just put the network model in a separate document with LNs referenced by name from the applications service template – So you can define multiple reusable network models independent of the applications 11


Download ppt "Mapping Service Templates to Concrete Network Semantics Some Ideas."

Similar presentations


Ads by Google