Sådan bygger vi fremtidens netværk - Asbjørn Højmark, Conscia / Zitcom
•Download as PPTX, PDF•
0 likes•116 views
Conscia stiller ind på, hvordan Cisco imødekommer tendensen hen i mod Software-Defined Networking (SDN) med den intelligente netværksteknologi Application Centric Infrastructure (ACI). Conscia er i øvrigt den første ACI-certificerede partner i Nordeuropa og nummer tre på verdensplan. Dernæst fortæller hosting- og cloudleverandøren Zitcom, hvordan de, som den første danske virksomhed, har implementeret og i praksis bruger ACI til at reducere driftsomkostninger betragteligt.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to Sådan bygger vi fremtidens netværk - Asbjørn Højmark, Conscia / Zitcom
Similar to Sådan bygger vi fremtidens netværk - Asbjørn Højmark, Conscia / Zitcom (20)
Sådan bygger vi fremtidens netværk - Asbjørn Højmark, Conscia / Zitcom
- 1. Conscia: Sådan bygger vi fremtidens netværk Asbjørn Højmark, CCIE #8525 2015-03-12 1
- 2. Conscia – IT-infrastruktur og 24x7-services inden for netværk, datacenter og mobilitet Fra mobil IT- strategi og anvendelse af mobile services… 2 …over sikker adgang til et højtydende netværk… …til et veldesignet og automatiseret datacenter… …med fuld integration til public cloud- services
- 3. Conscia – førende kompetencer De stærkeste samarbejdspartnere: Cisco Gold Partner EMC Gold Partner Conscia leverer it-infrastrukturløsninger og 24x7-services inden for netværk, datacenter og mobilitet Dygtigste konsulenter inden for vores teknologi- områder Great Place to Work: Danmarks Bedste Arbejdsplads Danmarks Bedste IT-arbejdsplads Økonomisk robusthed Stærk ejerkreds Differentieret og unik serviceløsning med merværdi 3 Leverandør til krævende brancher og virksomheder
- 4. Hvad er der galt med netværket i dag? 4
- 5. Hvad er der galt med netværket? IP access- lister Spanning Tree Protocol VLAN VxLAN NVGRE Lag 2 overalt Service Insertion Flooding Policy- Based Routing Multi- Chassis Link Aggregation Gamle firewall- regler 3-tier hierarki (mindst) Langsomt Dyrt Besværligt HSRP VRRP GLBP
- 6. Hvad er der galt med netværket?
- 7. Cisco ACI (Application Centric Infrastructure)
- 8. Leaf / Spine
- 9. Lag 3, også for Lag 2 IP Forwarding: Forwarded using DIP address, HW learning of IP address 10.1.3.11 10.6.3.210.1.3.35 10.6.3.17 MAC Forwarding: Forwarded using DMAC address, HW learning of MAC address APIC
- 10. PayloadIPVXLANVTEP APIC VTEP VTEP VTEP VTEP VTEP VTEP Integreret overlay / netværksvirtualisering
- 11. End Points + Policies = Application Profile
- 14. • Port-densitet • Power (strømforbrug) • Performance • Programmérbarhed • Pris … Og så er Nexus 9000 bare en rigtig fin switch!
- 15. Zitcom: Sådan bruger vi ACI i praksis
Editor's Notes
- Ville du manuelt konfigurere firmware, MAC-adresser, WWNs, og BIOS-settings individuelt på alle dine servere? Nej, det er da helt idiotisk… og derfor er UCS en succes. Men hvorfor i himlens navn vil du så det på dit netværk?
- ACI : Application-Centric Infrastructure = En arkitektur Det er altså en infrastruktur, der er beregnet til applikationer. Det er ikke applikationer, der tilrettes til infrastruktur. APIC = Application Policy Infrastructure Controller = Noget software til at styre det Det er altså en controller, der styrer infrastrukturen med policies for applikationer Nexus 9000 = Noget virkelig fin hardware Det interessante er, at de her folk startede med arkitekturen og softwaren til at styre det. Quotes: “Need to clean up the policy mess in the network” “Not trying to virtualize the network. Trying to fundamentally fix it” “We need to built a better network that can support all the cheap hardware (servers)” Første danske kunde, Zitcom, i produktion i november 2015. De er med i dag for at fortælle om, hvorfor de valgte ACI. Et par håndfulde kunder i rigsfællesskabet, alle solgt af Conscia. 300-400 kunder på verdensplan.
- Simpelt To forskellige slags udstyr (leaf, spine) Hver box laver kun én ting Alle leafs forbundet til alle spines Alle spines forbundet til alle leafs Ingen andre forbindelser Genialt til øst/vest-trafik Fast, lav latency Høj båndbredde Hvorfor er øst/vest vigtigt? Aht. server-til-server og server-til-storage, server-til-appliance etc Når man har mere end to spines, ’koster det’ ikke så meget performance at miste en. Ved anti-STP (fx vPC) mister man halvdelen af performance 40G uplinks. 10G uplinks dur ikke. 10G + tag giver over-subscription. Små pakker giver kun ca. 81%. 10G uplink med Q-tag = 8G goodput ved små pakker. Spines behøver ikke være store chassis’er. Der er en ’baby spine’ med 36 porte.
- STP skal dø. ACI router alle pakker, også mellem hosts i samme subnet Lag 3 Er nemt at fejlsøge på Host-based forwarding Ingen ARP flooding (netværket kender jo alle hosts) Ingen unknown unicast flooding Fabric-routes er ISIS Host routes er i COOP Encapsulation er VXLAN Automagisk QoS Load-balancering af store (elephant) flows over flere links Automatisk prioritering af små flows over store
- Forwarding mellem leaf-switche er som nævnt baseret på VxLAN, så det minder jo meget om, hvad man får med software-baserede overlay-netværk. Men med software-overlays mister man hurtigt overblikket, fordi man har to netværk, og maskiner kan kun snakke sammen via software på andre maskiner! Men hvem ringer folk til, hvis ”netværket” ikke virker? Med ACI får man faktisk et overlay-netværk, der hverken koster (ekstra) penge eller performance, og som man ikke skal spekulere på at konfigurere Og det virker både med virtuelle hosts, bare metal, appliances (firewalls, load-balancers) og storage
- IP ACLs giver konceptuelt nul mening. Eksempel med access-lister, hvor folk har tilladt deres egne maskiner gennem en firewall. QoS er samme problem. Hvem interesserer sig for IP-adressen på en host? Og hvorfor lægge denne binding på, at hosten ikke kan flyttes? Det samme gælder selvfølgelig SLB, PBR. Derfor har vi overloadet VLAN- og subnet-begrebet til at handle om sikkerhed og services. Hvad nu, hvis vi i stedet definerede endpoints, og hvordan de må snakke med hinanden? Hosts kan skifte adresse, uden det betyder noget for policy Application Profile kan nemt flyttes / migreres (fx Dev -> Test -> Prod) EPG = Port (fysisk el. virtuel), VLAN, IP-subnet, VXLAN, VM attributter, Subnet, DNS name, NIC, vNIC Policy = Hvem må snakke med hvad? Netværksadministratoren ved jo, hvor pakker skal hen! ”Hvis de skal fra webserver til application server, skal de via en load-balancer”. Når vi ved det, kan netværket jo gennemtvinge det, uden at vi skal rode med VLAN-numre, PBR etc. Partnere er fx Citrix for fx Netscaler F5 for fx Big-IP
- Vi har overloadet VLAN-begrebet og bruger en masse VLAN og VRF’er, blot for at sende pakkerne de rigtige steder hen. Nogle gange bruger vi fx en firewall som default gateway, og det er jo ikke fordi en firewall er en fin router! Forside- og bagside-net skal bare dø VLAN skal kun have lokal signifikans Og det samme gælder VXLAN og NVGRE Netværksadministratoren ved jo, hvor pakker skal hen! ”Hvis de skal fra webserver til application server, skal de via en load-balancer”. Når vi ved det, kan netværket jo gennemtvinge det, uden at vi skal rode med VLAN-numre, PBR etc. Device Packs OpFlex Partnere er fx Citrix for fx Netscaler F5 for fx Big-IP
- Forskellige hosts bruger forskellig encapsulation: VMware m. 802.1Q (VLAN) VMware m. VXLAN Hyper-V m. NVGRE Det skal være ligegyldigt, hvilket VLAN en server sidder I Det bør være muligt, at serveren leverer noget andet end VLAN. En normalization kan ESX snakke med Hyper-V og med bare metal og appliances. Supporterede hypervisors: Canonical KVM, Citrix Xen, Microsoft Hyper-V, Red Hat KVM, VMware ESXi Det giver også et ’gratis’ (penalty-free) overlay, så fx NSX er unødvendigt
- Jeg fik også nævnt, at ACI også er noget super-fin hardware: Nexus 9500 og Nexus 9300. Port density? 36 x 40G per slot Power consumption ~15 W/port (40G) Tidligere generationer bruger ~50 W/port, 3x lavere Performance 3,8 Tbps per slot Nexus 7000 har op til 550 Gbps per slot, 7x højere (36 porte x 40G x 16 slot = 23 Tbps!) Programmability SNMP, SYSLOG, RMON, NETCONF, CLI, XMPP, Puppet, Chef, XML, JSON, REST-ful API, Python, Cisco onePK, Bash shell + Linux containers, OpenDaylight, OpenFlow, OpenStack. You got it. Price 36x40G + 64x10G N7K = 330 k$. N9K = 265 k$. Til gengæld har N7K færre 10G-porte og bruger flere slot og mere strøm. Hvis man synes, Nexus 9000 er en super-fin switch, kan man også bruge den i såkaldt ’standalone mode’ med almindeligt NX-OS.