Internet Scale Architecture
•
0 likes•4,410 views
Cloud computing revolutionized application design, and changed the way people think about infrastructure. The rise of cloud computing coincided with a new generation of applications and services that required scale. New architecture and design had to take into account low latency network connectivity, geographic distribution, large real-time data stores, the ability to meet demand (while not knowing exactly how much demand to handle), and so much more. We refer to this as Internet Scale. Yet most discussion of scale and cloud revolves around compute as virtualized instances, which have defined configurations and constrained options. Delivering on the promise of Internet Scale involves substantial upfront design, and a comprehensive understanding of the entire architecture - from the underlying hardware, to the operating system, the application stack, services, and deployment. And, it involves choice - choices you should make based on your requirements. Join us for a discussion on the many facets of Internet Scale, and how it can apply to your applications and services.
Report
Share
Internet Scale Architecture
- 1. Deliver on the Promise of Internet Scale Design and Architecture Marc Jones, VP of Product Innovation
- 3. 100k servers 24k customers 23million domains
- 6. Enterprise apps Defined user base Relative predictability Cost Internet scale apps Global potential Relative chaos Revenue
- 7. Defining Cloud Computing Marketing term Reference Architecture Operations Model Capacity on demand Consumption-based pricing Self-service provisioning Accessible via API
- 8. On-demand, elastic resources with Internet 24×7 reliability. Scale? Scale is resource availability and capacity. Scale does not directly correlate to “faster” performance. Scale can help provide predictable performance.
- 9. 51 million blogs 57 million daily posts 21 billion blog posts
- 10. 50million downloads 30hrs drawings / sec 200 million dollars
- 11. Online Retail seasonality $13,000.00 $9,750.00 $6,500.00 $3,250.00 $0 Q1 08 Q2 08 Q3 08 Q4 08 Q1 09 Q2 09 Q3 09 Q4 09 Q1 10 Q2 10 Q3 10 Q4 10 Net Sales (1,000,000’s)
- 12. Does an SMB need Internet scale?
- 13. SMB promotional activity, social buzz 100,000 75,000 50,000 25,000 0 JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC Monthly Unique Visitors
- 14. Built for Internet Scale Unpredictable traffic patterns Unconstrained user base Global potential Network-sensitive Leading-edge technology stack
- 15. Choice Applications dictate infrastructure Workload characteristics Performance targets Control requirements Availability mandates
- 17. Design + Architecture Why is scalability so hard? It can’t be an after-thought. It requires applications and platforms designed with scaling in mind. Is achieving good scalability possible? Absolutely, but only if we architect and engineer our systems to take scalability into account. Simply throwing additional CPU cycles or storage at an application is not going to deliver linear scalability unless the application was designed to scale in such a manner.
- 18. Simplicity Over Complexity Think simple. If it is a complex problem, reduce to a simpler form. Iterate. Simple is actually hard. You have to work to simplify. Eliminate multi-step processes. Reduce each step of every process to its atoms. They perform their work in complete isolation, and communicate among one another with messages. “A system can be so simple that there are obviously no bugs, or it can be so complex that there are no obvious bugs.”
- 19. Design + Architecture Choose tools that can grow. The cloud makes it easy to add nodes. Does your software? Choose tools that can shrink. The cloud makes it easy to remove nodes. Most software does not. Leverage the best available to meet your requirements.
- 20. Design + Architecture Stateless and async. One of the guiding principles for linear scalability is to have lightweight, independent, stateless operations that can be executed anywhere and run on newly deployed threads/processes/cores/machines transparently as needed in order to service an increasing number of requests. Share nothing. Testing async code can be non-trivial. Test coverage should be pursued early (as in at the start). Test early, test often.
- 21. Bottlenecks Eliminate choke points. Everything that has to be coordinated by a single machine, or even a single cluster, is a failure waiting to happen. I/O - Network - Storage Architecture, design, and/or implementation flaws. Try to find them intentionally, not accidentally.
- 22. Design + Architecture Expect failure. Hosting infrastructure and the cloud are comprised of a lot of moving parts, each of which are prone to fail in their own way. Understand the potential failure points and architect your mission critical resources to survive.
- 23. IPv6 Connectivity < 40ms 10Gb
- 24. 13 data centers Reach 16 network POPs 20Gb fiber interconnects
- 25. Distributed Singapore Dallas Amsterdam
- 26. Local Storage
- 27. Network Storage
- 29. Inventory (You can’t deploy what doesn’t exist)
- 30. Hybrid architectures Common network API
- 31. Scale Up
- 32. Scale Out
- 33. Scale Down
- 34. Unified image-based provisioning system Move between virtual, physical Clone/reload/snapshot physical servers
- 35. Time Provisioning speed API feature set Contract length
- 36. Control
- 37. Better living through programming Increase agility Reduce human error Enable application autoscaling Evaluate on scope, documentation, support & community Control
- 38. Global deployments ! No capital expenditure ! Significant scale Consumptive billing ! Complete control
- 39. Why CloudPlatform?! Mature Easy-to-use GUI Citrix-backed RightScale compatible Flexible network architecture Internet scale Open source platform
- 40. Zones! One Management node supports one or more zones Private VLAN! VLAN ! Private VLAN! Spanning Management Server! ZONE 1! MULTIPLE OTHER ZONES! DATA CENTER 1! MULTIPLE DATA CENTERS!
- 41. Clusters & Hosts! One or more clusters per zone, one or more hosts per cluster Cluster defined by storage Local storage == single-server cluster Cluster Cluster Guest VMs! Guest VMs! Guest VMs! Physical Host! Physical Host! Physical Host! Management Server! ZONE 1! DATA CENTER 1!
- 42. Hardware Options! Management Node Single Proc Quad Core Westmere, 6 GB DDR3 2x2TB SATA Host Node Options Smallest: Dual Proc Quad Core Nehalem, 6-192GB DDR3 Biggest: Quad Processor 10 Core Westmere EX, 32-512GB DDR3 Storage: SATA, SA SCSI SSD Network: 100Mb-10Gb line speed Guest VMs! Guest VMs! Management Server! Host Node! Host Node!
- 43. COMMAND & CONTROL! Dallas! San Jose! Singapore! PUBLIC CLOUD WEB SERVERS! Guest VMs! Guest VMs! Physical Hosts! Physical Hosts! Management Server! Object Storage! Object Storage! PRIVATE CLOUD! PRIVATE CLOUD! DEDICATED! ZONE 1: DALLAS! ZONE 2: SINGAPORE! HADOOP CLUSTER: DALLAS!