The advantages of Arista/OVH configurations, and the technologies behind building and operating DCs
1 like634 views
The document outlines strategies for building a next-generation data center (DC) using a spine-leaf architecture, emphasizing cost optimization, scalability, and standardization with IP fabrics. It discusses the transition from manual to automated deployment and day-to-day services, leveraging tools like Arista's Zero Touch Provisioning and advanced event management for enhanced control and programmability. Additionally, it highlights the importance of state streaming for active monitoring of DCs, ensuring real-time updates and efficient operations.
The advantages of Arista/OVH configurations, and the technologies behind building and operating DCs
- 2. PRESENTEDBY LET’S BUILD A NG DC LAURENT GALLAMPOIS ARISTA lg@arista.com ROOM NAME 4.30 PM
- 3. HOW TO BUILD NEW GENERATION DC ? AGENDA Let’s summarize it in few steps Building the topology Automate deployment and day to day services Monitor actively your DC
- 4. THE STORY BEGIN WITH SPINE/LEAF DESIGN BUILDING THE TOPOLOGY IP only between Spine and Leaves (IPv4 or IPv6) Mainly BGP protocol between Spine and Leaves Spine can be chassis or simple ToR (depending of scalability level)
- 5. IT WAS ABOUT OPTIMIZING ARCHITECTURE … BUILDING THE TOPOLOGY Universal SpineLeaf/SpineLegacy Access Distribution Core Switching Legacy Core Routing Optical DCIInternet DCIInternet DCI Transit Public Peering Internet Inter-DC WAN Spine Leaf EW Spin e Spine Leaf
- 6. THEN CLOUD COMPANIES HAVE ARRIVED … BUILDING THE TOPOLOGY Spine/Leaf still the reference design but they wanted Cost optimized products As few as possible references Huge scaling level Spine only pushing some traffic like a “switching Fabric in chassis” No proprietary model from Hardware and Software standpoint OK, Chassis is not the most appropriate … Well, how to scale … ?
- 7. HOW ANSWER TO THIS NEEDS ? BUILDING THE TOPOLOGY Let’s explode chassis component … Switching Fabric are now Spine LineCards are now Leaves Internal links are now standard Ethernet links, at desired speed, with BGP and IPv4/IPv6 !!
- 8. SO WHAT ? BUILDING THE TOPOLOGY Finally we’ve just created a Spine/Leaf based on ToR, … But in fully standardized manner Ethernet, IPv4/IPv6 BGP 1 RU, Cost Attractive switches Merchant Silicon Approach 1 RU, Cost Attractive switches Merchant Silicon Approach
- 9. LET’S PUT THIS IP FABRIC INTO CONTEXT BUILDING THE TOPOLOGY Each chassis is now a “PLAN” PLAN - #1 PLAN - #2 PLAN - #3 PLAN - #4
- 10. PLAN CONCEPT IS HIGHLY SCALABLE … BUILDING THE TOPOLOGY Increase bandwidth on demand … Increase density on demand … Increase ToR bandwidth on demand …
- 11. IPV6 OR NOT IPV6 FOR THE FABRIC THAT IS THE QUESTION ? BUILDING THE TOPOLOGY ServersServers No real problem about using IPv4 – Except lack of IPv4 addresses perhaps IPv6 can be deployed and some gateway between both world are there RFC 5549 : IPv4 with IPv6 nexthop IPv6 HW-VTEP is possible with T3, Jericho+/Jericho2, Tofino (Barefoot) Rack 1 Rack N ToR ToR ASN-11 ASN-12 SW VTEP IPv6 Fabrics/Plans IPv6 connectivity BGP for VTEP Reachability HW – VTEP IPv6 Layer 2 – Layer 3 traffic with dot1q or not ServersServers Rack 1 Rack Nq ToR ToR ASN-21 ASN-22 HW – VTEP IPv4 End to End IPv6 IPv4 VTEP with NH IPv6 IPv6 VTEP IPv6 NLRI IPv6 VTEP IPv6 NLRI IPv4 VTEP IPv6 NLRI IPv4 VTEP IPv6 NLRI
- 12. NOW WE HAVE FABRICS HOW DO WE ADD SERVICES ? BUILDING THE TOPOLOGY Servers Servers Traffic encapsulated at HW-VTEP/ToR level Only IP traffic to carry when entering IP Fabrics/Plans Works for Layer 2 and Layer 3 services : eVPN+VXLAN as standard solution Rack 1 Rack N ToR ToR ASN-11 ASN-12 SW VTEP IP Fabrics/Plans IP connectivity HW - VTEP BGP for HW-VTEP IP reachability Shared Segment Layer 2 – Layer 3 traffic with dot1q or not
- 13. THE TRANSITION TO CLOUD NETWORKING AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Manual, Box-by-Box Automated, Network-wide Legacy Networking Cloud Networking Closed architectures Open, decoupled, standards-based approaches Limited integration and control Control through deeper programmability at all layers Networking skill sets New skill sets - virtualization, DevOps, scripting
- 14. ARISTA ZERO TOUCH PROVISIONING - ZTP AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES It’s the automated provisioning of new switches… New switches are provisioned automatically, including code version, extensions and configuration. Powerful customization options using open standard tools, topology awareness Allows for the automatic and parallel operation of repetitive tasks Helping eliminate the chances of operator error Drastically reducing maintenance windows Enables Zero Touch Replacement (ZTR) Reduces on-site skills requirement for hardware replacement Especially useful in secure or remote data centers Rack… Connect… Power on…
- 15. DEVOPS AND SCRIPTING CAPABILITIES : … … EVERYTHING CAN BE AUTOMATED AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES AEM : Advanced Event Management Trigger some action based on criteria : Interfaces state, counters, VM move, … Launch action based on time, repetitively, ... Monitor network activity : mac, arp, next-hop, ... Multiple API available : eAPI over http, https C++ SDK with Python interface : Ability to create your own agent Go API Access to Bash running on unmodifed Linux kernel Install existing package Install package you created Access to Docker capabilities Support of Ansible, Puppet, … NetConf/RestConf Yang
- 16. AEM : ADVANCED EVENT MANAGER AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Event Scheduler Execute script, command or any program Based on given time every day Every amount of time. Event Handler Execute script, command or any program triggered by specific event ▪ on-boot trigger condition occurs on system boot ▪ on-counters trigger condition occurs on evaluating statistical counters ▪ on-intf trigger condition occurs on specified interface changes ▪ on-logging trigger condition occurs when regex match any log message ▪ on-maintenance trigger condition occurs on maintenance operation ▪ on-startup-config trigger condition occurs on startup config changes ▪ vm-tracer trigger condition occurs on VmTracer events
- 17. EAPI : DEAD SIMPLE AUTOMATION API AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Anything you can do, you should be able to automate… … in just a few lines of code! Send a list of any CLI commands, and get back structured data Use JSON over HTTP(S) for painless, cross-platform compatibility Works well for remote or on-box programming
- 18. EAPI AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Very simple protocol means you can use any language you'd like: Python, Go, Javascript, C++, Java, Bash (hello curl!), node.js, Ruby, Perl, and almost every other language There is an eAPI specific library in Python to make the API even easier: pyeapi 3rd party client libraries: ▪ Ruby https://github.com/imbriaco/arista-eapi ▪ Node.js https://github.com/thwi/node-eAPI ▪ Go https://github.com/fredhsu/eapigo, etc.
- 19. EOS SDK: UNLEASH THE FULL POWER OF EOS AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES A very powerful C++/Python API that enables the development of native, high performance applications/agents that can manipulate and react to switch state via a stable API to Sysdb. third-party agents get all of the EOS goodness: event-driven notifications, ProcMgr control, CLI + eAPI integration, etc. open development and docs on GitHub 30+ modules available now, more coming soon
- 20. IN ANY CASES, VALIDATION IS KEY AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Test everything you can, to anticipate problems : Deployment automation, Service deployment, Software upgrade, … You need flexible environment to achieve it easily …
- 21. EOS FLEXIBILITY IS ALLOWING EASIER VALIDATION AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Arista Hardware x86 Server EOS (Linux) Multi-Hypervisor X86 Server Arista hardware 3rd Party hardware Linux Kernel Container Docker cEOS VM vEOS (Linux) HW+SW Bundled solution vEOS Lab vEOS Router Kernel independence (Cloud) Hardware Disaggregation General lab simulation Standard EOS EOS in a virtual machine EOS in a container Use casesArchitecture
- 22. MONITOR ACTIVELY YOUR DC MONITOR ACTIVELY YOUR DC SNMP: Networking’s old school API Ubiquitous and well integrated in standard tools Well documented models Support for common types of configuration and notifications But this doesn’t catch everything … When we should be able to do it
- 23. WHAT IS STATE STREAMING ? MONITOR ACTIVELY YOUR DC Every NetDB state change. From every device. Instantaneously. Interface Counters sFlow Data Temperature Sensor Routing Tables MAC Tables ACL Counters Buffer Utilization System logs CPU Load Fan Speed Power Draw VXLAN Mappings State Streaming Every state change triggers an update… LANZ Data Table Utilization Configurations …and streamed to a central state repository
- 24. WHY IS IT SO EASY FOR EOS ? MONITOR ACTIVELY YOUR DC Low Inter-Process Communication Arista EOS – Publish / Subscribe Efficient Publish/Subscribe Publish Notify PIM SNMP BGP Driver MLAG STP eAPI IGMP Linear Cloud Scale This is just about adding a new agent !! No internal polling with process before streaming : Agent is connected on NetDB Telemetry NetDB
- 25. SUMMARY AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES Un grand merci à OVH et ses équipes pour nous avoir : Choisi pour les déploiements initiaux VXLAN en 2014 Fait confiance pendant ces 4 années de collaboration MERCI !!
- 27. 27 Complete, Real-time state streaming EOS TerminAttr EOS TerminAttr EOS TerminAttr EOS TerminAttr EOS TerminAttr Custom backend OR EOS OpenConfig EOS OpenConfig EOS OpenConfig EOS OpenConfig EOS OpenConfig ODL or other Controller (YANG models) gRPC (protobuf), HTTP, Custom gRPC (protobuf), RESTCONF, NETCONF All EOS internal state (data models) including SysDB, Counters, logs, kernel; etc Data models defined by OpenConfig YANG models Open APIs • CloudVision Apps • Partner Apps • Custom Apps TerminAttr OpenConfig OR Ingest (ockafka) Kibana / Elastic Search / Logstash