Managing infrastructure with Application Policy by Mike Cohen

  • 549 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
549
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
18
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. MANAGING INFRASTRUCTURE WITH APPLICATION POLICY Mike Cohen Director of Product Management, Cisco 1
  • 2. PROBLEMS TODAY IN NETWORKING •  Networks today are high touch, micromanaged environments •  Network configuration is an “art” completely divorced from the desired intent of the app developer! •  Causes huge problems in scaling, coping with failures, and interoperability •  SDN to date has not fixed this problem 2
  • 3. TWO OPERATIONAL MODELS Declarative Control “Configure   acl”   “Let  my  web   servers  talk  to   my  app  servers”   “Allow  Host  A  to   talk  to  Host  B”   Faults   “Add  route  …”   Admin   “Trunk  vlan”   “Deploy   Applica-on  X”   Elements   Manager  pushes   configura-on  changes  to   devices.       Control  System   Imperative Control “Will  Do”   Applicable   changes  made   3
  • 4. COMPARISON TO THE SERVER WORLD – DEVOPS! •  The DevOps movement is largely based on Declarative Policy! •  Millions of servers are managed in a highly scalable manner DevOps LAMP Stack MySQL Servers Java App Servers •  Time of the network to catch up! 4
  • 5. COMPARISON TO TRADITIONAL SDN Declarative Control OpenFlow + OVSDB Data Plane Policy Mgr APIC Control  System   SDN Controller Elements   Policy Mgr + Control Plane Admin   Imperative Control Protocols TBD… Control + Data Plane 5
  • 6. ADVANTAGES OF DECLARATIVE MANAGEMENT Simple, abstract way of managing infrastructure Resiliency Promise interfaces provide an easy way to cope with failures Interoperability Device complexity / versions is hidden from users and control software Ease of use Self-documenting, easily automated policies How do we represent our declarations / policy? Admin   “Let  my  web   servers  talk  to   my  app  servers”   “Allow  Host  A  to   talk  to  Host  B”   Faults   Scalability Control  System   Key Advantages include: Declarative Control Elements   Declarative management (ie. Promise Theory) is the voluntary cooperation of individuals or agents who publish their intentions via commitments to each other. “Will  Do”   Applicable   changes  made   6
  • 7. POLICY 7
  • 8. WHAT IS POLICY? User Intent Operational Requirements Cloud Management System Infrastructure Capabilities Challenge: How to capture user intent through a policy abstraction! State of the System 8
  • 9. Simple provider-consumer Or client-server relationship or symmetric peer-to-peer relationship like in a cluster. I Invoke governed by contract. taboo contract I can speak french EPG ? you! subject I can talk about bees EPG … Vous me rappelez des abeilles! Blah blah blah. subject contract Providers Peers taboo Consumers Peers 9
  • 10. WHAT IS AN APPLICATION? App Tiers/Components More than just a VM each is a collection of end-points with semantically identical properties Interconnected components internet V M V M V M … External Private Network ? db … … V M app V M V M application web protected by contract membrane 10
  • 11. NETWORK ENDPOINTS à Things that connect to the fabric and use it to interface with other things à A compute, storage or service instance attaching to a fabric NIC vNIC IP end-points [ EP ] MAC Network Linux Container Namespace 11
  • 12. NETWORK ENDPOINTS à Things that connect to the fabric and use it to interface with other things à A compute, storage or service instance attaching to a fabric EP EP EP . . . A collection of end-points with identical network behavior form a … … end-point group [ EPG ] All EPs share common properties à  à  à  à  à  Connectivity Security/Access control QoS Services … 12
  • 13. ENDPOINT GROUPS GROUP APP SERVER policies GROUP WEB EP EP EP . . . Allows to specify rules and policies on groups of physical or virtual end-points without understanding of specific identifiers and regardless of physical location. Can flexibly map into à  application tier of multi-tier app à  segmentation construct (ala VLAN) à  a security construct à  ESX port group à  … … end-point group [ EPG ] All EPs share common properties à  à  à  à  à  Connectivity Security/Access control QoS Services … 13
  • 14. CONTRACTS GROUP APP SERVER provider … contract End points in group WEB can access end-points in group APP SERVER according to rules specified in the contract consumer … Allows to specify rules and policies on groups of physical or virtual end-points without understanding of specific identifiers and regardless of physical location. filter GROUP WEB EP EP . . . filter action identifies subject to which actions will be filter applied … EP action L4 port ranges TCP options … filter identifies actions applied to the subject action QoS Log Redirect into SVC graph … action defined bi-directionally in the “provider” centric way 14
  • 15. EXAMPLE: THREE-TIER APP infra shared services Outside Group DB provide provide consume sql contract provide provide subnet Group APP consume java contract subnet consume provide NW Private Group WEB web contract NW Public consume consume consume provide mgmt contract L3 context Bridge domain Bridge Domain Bridge Domain 15
  • 16. ACTIVITIES IN THE OPEN SOURCE COMMUNITY 16
  • 17. OVERVIEW – DRIVING OPEN SOURCE POLICY APP CENTRIC POLICY MODEL •  •  Cloud Orchestration Network Neutron API for app centric policy Future extensions to Heat / Nova / Horizon •  •  •  Policy API support / extensions Policy enforcement modules Service redirection APIC Hypervisor / vSwitch Application centric policy management through an open source software stack 17
  • 18. GROUP-BASED POLICY IN OPENSTACK Group-Based Policy Model Extensions (ACI-compatible) Dashboard Automation GROUP POLICY MODEL Compute ACI Fabric Networking Storage Merchant Silicon OpenFlow Software Overlay Etc. 18
  • 19. GROUP POLICY IN OPEN DAYLIGHT Group Policy REST API Affinity “Native” OpenFlow ACI Fabric Openflow, 3rd party switches, … Project currently in “Incubation” Status in ODL. See: https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin 19
  • 20. DATA MODEL 20
  • 21. OPEN DAYLIGHT ARCHITECTURE 21
  • 22. CISCO ACI 22
  • 23. ACI BUILDING BLOCKS FUTURE PROOF—SOFTWARE UPGRADABLE TO ACI NEXT GENERATION NEXUS—TRADITIONAL NETWORKS OPEN RESTFUL APIS CENTRALIZED POLICY MODEL OPEN SOURCE APIC SIMPLE, SECURE CONTROLLER PRICE APIC POLICY MODEL RATE 9300 NEXUS 9500 and BUILT-IN LINE INNOVATIONS IN SOFTWARE HARDWARE AND SYSTEM DESIGN PERFORMANCE PROGRAMMABILITY POWER EFFICIENCY SCALE OUT WITHOUT NX-OS OPTIMIZED COMPROMISE COMMON BUILDING BLOCKS - ACCESS AND CORE INTEGRATED OVERLAY 40G NON-BLOCKING FABRIC >_ >_ RESILIENCY: IN SERVICE PATCHING, UPGRADE, FAST RESTART END POINT DIRECTORY PORT DENSITY 50% SIMPLER CODE BASE ACI FUTURE PROOF UPGRADABLE TO ACI NETWORK VIRTUALIZATION SUPPORT PROGRAMMABILITY AND AUTOMATION 23
  • 24. ACI: RAPID DEPLOYMENT OF APPLICATIONS ONTO NETWORKS WITH SCALE, SECURITY AND FULL VISIBILITY Physical Networking Hypervisors and Virtual Networking Compute L4–L7 Services Storage Multi DC WAN and Cloud ENABLED BY PHYSICAL AND VIRTUAL INTEGRATION 24
  • 25. ACI OPEN APIS AND ECOSYSTEM Automation Enterprise Monitoring Hypervisor Management Systems Management Orchestration Frameworks OVM REST API APIC Fabric-attached Device API L4-7 Orchestration Scripting API NORTHBOUND PROGRAMMABILITY LAYER SOUTHBOUND PROGRAMMABILITY LAYER APIC SUPPORTS A RICH ECOSYSTEM BUILT AROUND OPEN NORTHBOUND AND SOUTHBOUND APIS 25
  • 26. HYPERVISOR SWITCH •  Develop extensions to Open vSwitch to support: 1.  Policy enforcement 2.  Service Redirection 3.  Linux containers 4.  Stateful services 26
  • 27. APPENDIX 27
  • 28. SERVICE INSERTION contract filter filter Subject A action action subject … Subject B filter action prio Subject C … svc graph Service Graph Definition term in Automatically derives parameters from EP, EPG, Tenant –level information out term FW SLB out in 28
  • 29. MULTIPLE CONTRACTS EPG APP SERVER EPs in EPG WEB can NOT access EPs in EPG APP SERVER on subjects (L4 ports) specified in these contracts provider mgmt contract consumer web contract ssh contract EPG WEB EP EP EP . . . EPs in EPG WEB can access EPs in EPG APP SERVER on subjects (L4 ports) specified in this contract, subjected to actions in this contract à Explicit white-list like model for specifying rules between groups 29
  • 30. EPG CONSUMPTION LABELS Outside NW Internet web contract http provide consume EPG WEB For Internet https NW Intranet consume ftp provide EPG WEB For Intranet EPG Label Allows to chose a group of EPGs behind the contract “NW Internet” can only access “EPG WEB For Internet” “NW Intranet” can access both “EPG WEB For Internet” and “EPG WEB For Internet” 30
  • 31. SUBJECT LABELS Outside NW Internet web contract http provide consume EPG WEB For Internet https NW Intranet consume ftp provide EPG WEB For Intranet Subject Label For a providing EPG, allows selection of supported subjects in the contract “EPG WEB For Internet” only provides “https” “EPG WEB For Intranet” provides “http”, “https” and “ftp” 31
  • 32. WHY IS NETWORKING SO HARD? à the rest is path optimization YES You can talk about this: { subject*, L4 Ports, … } A NO You can’t B à End point A can talk to end point B C D à End point C can’t talk to end point D 32