mapping service templates to concrete network semantics n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Mapping Service Templates to Concrete Network Semantics PowerPoint Presentation
Download Presentation
Mapping Service Templates to Concrete Network Semantics

Loading in 2 Seconds...

play fullscreen
1 / 11

Mapping Service Templates to Concrete Network Semantics - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Mapping Service Templates to Concrete Network Semantics' - spence


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
objective
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
how should we talk about networking in a service template
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)
logical network attributes
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, …
features
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
sugarcrm service model
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

specify kind or name of network used by each endpoint
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

a few rules
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
logical networks avoid
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)
we can t avoid
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
can we still model the topology in more detail
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