Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Journey to OCP

461 views

Published on

Talk given at the Open Compute Meetup in Amsterdam, 20-Feb-2018

Recording at https://www.youtube.com/watch?v=c0Z32UsB5g0

Published in: Internet
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website! http://bit.ly/resumpro
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

A Journey to OCP

  1. 1. OCP Meetup
 Amsterdam 20-Feb-2018
  2. 2. A Journey to Open Compute Kristian Köhntopp
  3. 3. Global Hotel Room Experience Market.
  4. 4. Current Situation ● 3 data centers. ● rent full rooms, ● tier-3 “uptime” spec.
 ● ~30k machines. ● too many configurations. 4
  5. 5. On being boring ● We are a “REP STOSB” company. ● “We are not a technology company.”
 ● Moore’s Law also works backwards. 5
  6. 6. Interesting times…
  7. 7. Interesting times…
  8. 8. A naive projection
  9. 9. Incremental Buildout. ● Get space. ● Electrical buildout. ● Racks. ● Switches. ● Chassis. ● Blades. 9 Then finally, automation.
  10. 10. Constraints. ● Small rooms. ● Power Limit per Rack. ● Build times. ● Trash issues. ● And plenty of LOM issues. 10
  11. 11. Watts over Cores, resulting in 6.4kW/10U
  12. 12. 32 machines (40 cores ea) Hadoop
  13. 13. ● Underdocumented, multiple access paths.
 ● By default often insecure. ● Outdated Crypto
 (default: none). ● Insecure client requirements. ● Different access methods
 (partial fix: Redfish). ● Differences in feature sets.
 ● Way to many features.
 ● Unstable, slow. Bonus: LOM issues 13
  14. 14. Going Rack Scale.
 Bring volume up. Getting Rooms to match.

  15. 15. Going Rack Scale.
  16. 16. ● Ordering by the 
 blade center chassis.
 ● Solves trash issues. ● Streamlines late provisioning phase. ● Limited in what goes into a chassis.
 ● Chassis to be discontinued. ● Ordering by the rack.
 → Rack Scale Designs, → Open Compute
 ● More design flexibility.
 ● “shared power/cooling” savings? Larger Scale - Chassis, Rack. 16
  17. 17. ● Rackscale Design
 ● Integrated Rack Management. ● “Composeable Hardware”.
 ● Sometimes delivered including the DC. ● Open Compute
 ● “Less is more”.
 ● Value added at higher level software. ● For us, Kubernetes on top of it an important part of the equation. Alternatives 17 Even more
 bespoke. Bulk.
  18. 18. Potential Benefits ● Clean bare server design w/o “value add”. ● Documented, we can integrate with our systems.
 ● Delivery by the rack.
 
 ● Potential operative and capital savings. 18 See “Getting Volume Up”
  19. 19. Getting volume up.
  20. 20. Too many profiles ● Goes to 11. ● 2 CPU, 2 Mem sizes. ● Lots of different local storage profiles. 20
  21. 21. The answer is obvious: 21 Ban everything!
  22. 22. Storage Disaggregation 22 Production Space per Rack Budget: 2 OU, 500W, 1 Port 50cm, 100 GBit Copper Link Uniform Production Compute East-West Replication Traffic, production-side East-West Data Access Traffic, production-side Kubernetes: Resiliency, Application Mobility, Capacity Size Adjustment No Local Persistence
  23. 23. Storage Disaggregation ● 4 profiles or less. ● Disk “as requested”. ● Location independence. ● Independent HW upgrade. ● One single network.
 ● (Hadoop) 23 Production Space
  24. 24. Getting rooms to match.
  25. 25. Rack and Room as a System 25 OCP Gear
  26. 26. Two Sided Markets ● “Anonymous Supply and Demand”
 ● Key: 
 A common spec 
 to build to. 26 OCP Gear
  27. 27. DC Space availability ● Quick Availability. ● High Flexibility. ● Fewer Operative Distractions.
 ● Higher Cost. ● (Capacity Fragmentation.) 27 For smaller companies, this is essential.
  28. 28. How does this work on smaller scales? “Rack and Room as a System”
 “Two Sided Market”
 Leverage documented machine interfaces for open integration and management systems. 28

×