Architectures for open and scalable clouds

Architectures for open and scalable cloudsFebruary 14, 2012Randy Bias, CTO & Co-founder CCA - NoDerivs 3.0 Unported License - Usage OK, no modiﬁcations, full attribution

Our Perspective on Cloud Computing It came from the large Internet players. 2

A Story of Two Clouds 3

A Story of Two Clouds 4

Tenets of Open & Scalable Clouds1. Avoid vendor lock-in like bubonic plague • See also Open Cloud Initiative (opencloudinitiative.org)2. Simplicity scales, complexity fails • 10x bigger == 100x more complex3. TCO matters; measuring ROI is critical to success4. Security is paramount ... but different5. Risk acceptance over risk mitigation6. Agility & iteration over big bang 5

This is a BIG Topic• What I am covering today is patterns in: • Hardware and software • Networking, storage, and compute• NOT covered today: • Cloud operations • Infrastructure software engineering • Measuring success through operational excellence • Security 6

Open Clouds (brieﬂy) 7

A Word on ‘Open’ 8

Here we go ...• Elements: • Open APIs & protocols • Open hardware • Open networking • Open source software (OSS)• Combined with: • Architectural patterns, best practices, & de facto standards • Operational excellence 9

Open APIs & Protocols 10

Open Hardware 11

Open NetworkingPublished Networking Blueprints 12

Open Source SoftwareOpen Cloud OS 13

Open & ScalableCloud Patterns 14

Threads• Small failure domains are less impacting• Loose-coupling minimizes cascade failures• Scale-out over scale-up with exceptions• More AND cheaper• State synchronization is dangerous (remember CAP)• Everything has an API• Automation ONLY works w/ homogeneity & modularity• Lowest common denominator (LCD) services (LBaaS vs F5aaS)• People are the number one source of failures 15

Pattern: Loose couplingSynchronous, blocking calls mean cascading failures. Async, non-block calls mean failure in isolation. 16

Pattern:Open source software Excessive software taxation is the past. You can always fork. Black boxes create lock-in. 17

Pattern:Uptime in software - self managementHardware fails.Software fails. People fail. Only software can measure itself & respond to failure in near real-time. Applications designed for 99.999% uptime can run anywhere 18

Pattern: Scale-out, not UP You name them and when they get Scale Up: (Virtual*) sick, you nurseServers are like pets them back to health garﬁeld.company.com attrib: Bill Baker, Distinguished Engineer, Microsoft * added by yours truly ... 19

Pattern: Scale-out, not UP You name them and when they get Scale Up: (Virtual*) sick, you nurse Servers are like pets them back to health garﬁeld.company.com You number them Scale Out: (Virtual*) and when they getServers are like cattle sick, you shoot them web001.company.com attrib: Bill Baker, Distinguished Engineer, Microsoft * added by yours truly ... 19

Pattern: Buy from ODMsODMs operate theirbusinesses on 3-10% margins. AMZN, GOOG, and Facebook buy direct without a middleman. Only a few enterprise vendors are pivoting to compete. 20

Pattern:Less enterprise “value” in x86 servers Generic servers rule. Full stop. Nothing is better because nothing else is *generic*. “... a data center full of vanity free servers ... more efﬁcient ... less expensive to build and run ... “ - OCP 21

Pattern: Flat NetworkingThe largest cloud operators all run layer-3 routed, ﬂat networks with no VLANs. Cloud-ready apps don’t need or want VLANs. Enterprise apps can besupported on open clouds using Software-deﬁned Networking (SDN) 22

Pattern: Software-deﬁned Networking (SDN)• x86 server is the new Linecard• network switch is the new ASIC “Network Virtualization”• VXLAN (or NVGRE) is the new Chassis• SDN Controller is the new SUP Engine 23

Pattern: Flat Networking + SDNsFlat + SDN co-exist Internet & thrive together VM VM Availability Zone VM VM VPC VM Gateway Virtual L2 Network 1 2 VM VM Standard VM VM VPC Virtual Private Security Security Cloud Group Group Networking Physical Node 24

Pattern: RAIS instead of HA pairs/clusters• Redundant arrays of inexpensive services (RAIS) • Load balanced • No state sharing • On failure, connections are lost, but failures are rare• Ridiculously simple & scalable• Most things retry anyway• Hardware failures are in-frequent & impact subset of trafﬁc • (N-F)/N, where N = total, F = failed• Cascade failures are unlikely and failure domains are small 25

Service array (RAIS) example:Public IP Backbone Routers Blocks OSPF Route Announcements RAIS (NAT, LB, VPN) Cloud Access Switches API Return Trafﬁc (default or source NAT)CloudControl Plane AZ (Spine) Switches 26

Pattern: Lots of inexpensive 1RU Switches Simple spine-and-leaf ﬂat routed network Rack 1 Rack 2 Rack 31RU: 6K-30K VMs / AZ 27

Pattern: Lots of inexpensive 1RU Switches Simple spine-and-leaf ﬂat routed network Multiple Multiple Multiple Rack 1 Rack 2 Rack 3 Racks2 Rack Racks2 Rack Racks2 Rack Rack 1 Rack 1 Rack 11RU: 6K-30K VMs / AZ Modular: 40K-200K VMs / AZ 27

Pattern: Direct-attached Storage (DAS)Cloud-ready apps DAS is the smallest failuremanage their own domain possible withdata replication. reasonable storage I/O.SAN == massive failure SSDs will be the great domain. equalizer. 28

Pattern: Elastic Block Device Services EBS/EBD is a crutch for poorly written apps. Bigger failure domains (AWSoutage anyone?), complex, sets high expectations Sometimes you need a crutch. When you do, overbuild the network, and make sure you have a smart scheduler. 29

Pattern: More Servers == More Storage I/O >1M writes/second, triple-redundancy w/ Cassandra on AWS Linear scale-out == linear costs for performance 30

Pattern: Hypervisors are a commodityCloud end-users want OS of choice, not HVs. Level up! Managing iron is for mainframe operators. Hypervisor of the future is open source, easily modiﬁable, & extensible. 31

Open Cloud SystemSimply Scaled Production Ready randyb@cloudscaling.com @randybias 32

http://www.cloudscaling.com	1421
http://softwarestrategiesblog.com	657
http://www.cloudave.com	321
http://www.redditmedia.com	58
http://irq.tumblr.com	23
http://dev.cloudscaling.com	21
http://feeds.feedburner.com	12
http://blog.fasoulas.com	7
http://www.hanrss.com	6
http://translate.googleusercontent.com	2
https://www.newsblur.com	2
http://iblunk.com	2
http://www.twylah.com	1
http://paper.li	1
http://us-w1.rockmelt.com	1
http://webcache.googleusercontent.com	1
http://127.0.0.1	1
http://flavors.me	1

Architectures for open and scalable clouds

by Randy Bias on Feb 16, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

18 Embeds 2,538

Statistics

Architectures for open and scalable clouds — Presentation Transcript