1 / 11

Mapping Service Templates to Concrete Network Semantics

Mapping Service Templates to Concrete Network Semantics. Some Ideas. 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

spence
Download Presentation

Mapping Service Templates to Concrete Network Semantics

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. 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 • Don’t 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

  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)

  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, …

  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

  6. SugarCRM Service Model SugarCRM Service Apache Web Server MySQL MySQL Client Endpoint Port 3306 SugarCRM App SugarCRM DB HTTP Client requires Application EndPoint HTTP Port 80 or 443 DocumentRoot:/SugarCRM PHP Module 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 Database content must be placed on storage of required capacity, availability and performance

  7. Specify kind (or name) of network used by each Endpoint Apache Web Server MySQL SugarCRM App SugarCRM DB Public Data requires PHP Module Mgmt could be implied or handled by the infrastructure Mgmt

  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

  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)

  10. We Can’t 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

  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, let’s take a stratified/layered approach • Just put the network model in a separate document with LNs referenced by name from the application’s service template • So you can define multiple reusable network models independent of the applications

More Related