«

»

Understanding Web-Scale Properties

Last week Gartner released an article saying that by 2017, Web-scale IT will be an architectural approach found operating in 50 percent of global enterprises.

Gartner Says By 2017 Web-Scale IT Will Be an Architectural Approach Found Operating in 50 Percent of Global Enterprises

Web-scale IT is more than just a buzzword, it is the way datacenters and software architectures are designed to incorporate multi-dimensional concepts such as scalability, consistency, tolerance, versioning etc.

Web-scale describes the tendency of modern architectures to grow at (far-)greater-than-linear rates. Systems that claim to be Web-scale are able to handle rapid growth efficiently and not have bottlenecks that require re-architecting at critical moments

Web-scale architecture and properties is not something new and have been systematically used by large web companies like Google, Facebook and Amazon. The major difference is that now these same technology that allowed those companies to scale to massive compute environments are being introduced into mainstream enterprises, with purpose-built virtualization properties.

In an internal discussion, Nutanix CEO, Dheeraj Pandey, he wrote about the key concepts of Web-scale architectures. I used some of his thoughts and expanded into different areas to write this article.

I must however admit that highly scalable distributed systems are a new area to me, and I am going trough a learning process. I will be sharing more of my learning’s over the next months.

The first important thing to remember: Web-scale is not exclusively applicable to SDS (Software Defined Storage); rather it is an architecture model for very large distributed systems.

 

What qualifies a software or architecture as web-scale?

  • Everything should be in software, running on standard x86 hardware, with no special purpose machines doing one and one thing only. This is where Web-scale intersects with the SDDC (Software Defined Datacenter) for the 1st time. Zero hardware crutches. Taiwan hardware with pure software-based services. A number of services already take this approach, including SDN (Software Defined Network), Virtual Services and SDS (Software Defined Storage).
  • There should be architectural considerations for no single point of failure or bottleneck for management services. Tolerance of failures is key to a stable, scalable distributed system, and ability to function in the presence of failures is crucial for availability. Techniques like vector clocks, two-phase commit, consensus algorithms, leader elections, eventual consistency, multiple replicas, dynamic flow control, rate limiting, exponential back-offs, optimistic replication, automatic failover, hinted-handoffs, data scrubbing, checksumming among others all go towards the ability of a distributed system to handle failures.
  • Web-scale systems should provide elastic services with an embarrassingly parallel approach to systems building (http://en.m.wikipedia.org/wiki/Embarrassingly_parallel). Parallel approaches enable non-disruptively approach to traditionally disruptive tasks, such as rolling or forklift upgrades, always-on clusters, and all workflows always online.
  • Web-scale systems should be able to be expanded and continue to function normally as one unit, instead of relying on multiple deployments of functional units that are not scalable units by themselves.
  • Web-scale systems are built from ground up and should expect and tolerate failures while upholding the promised performance and availability guarantees or service level agreements.
  • Web-scale systems should provide programmatic interfaces to allow complete control and automation via HTTP-based services, for intra- and inter-datacenter communication. These APIs must utilize latency and loss-tolerant protocols with avenues for asynchronous request-responses.
  • Web-scale systems must provide self-defining (and versioned) objects. In the case of SDS, self-defining disk formats with ability to encode and serialize structured data in efficient yet extensible formats, like protobuf, Avro, et al. This way, upgrades of disk data can be done lazily. Web-scale cannot assume a one-shot data upgrade, given the scale.
  • Web-scale systems should have self-describing (and version-aware) services such that different parts of the distributed system can communicate at different versions, without expecting a one-shot upgrade for all components.
  • Analytics software to reduce human interaction. Web-scale infrastructures at large web companies have a 1:10,000 ratio for SRE per machines managed. Enterprises are currently at 1:500 ratio. There is a huge gap that only analytics and automation can fill.
  • Strictly and eventually consistent consistency models with clear understanding of the CAP theorem (Consistency, Availability and Partition Tolerance) (http://en.m.wikipedia.org/wiki/CAP_theorem). I found this article by Julian Browne to be a good staring point to learn more about the CAP theorem.

 

CAP_Diagram_dist copy

 

A good example that is close to my heart is vCenter Server. vCenter should have been designed from the ground-up to be a distributed management platform that provides no single point of failure using a shared nothing architecture. As we know vCenter Server is a critical piece for vSphere clusters and when unavailable may drastically impact operations. The same can be said about Microsoft Hyper-V SCVMM.

While it’s true that hypervisors themselves are standalone units and will operate without management servers, the potential lack of management should not be a probability.

If vCenter had been designed using web-scale principles it would either be a clustered virtual appliance or built into the hypervisor kernel. The more nodes added to the cluster more resilient the solution would become, and when a node was down another node could be used as a management end-point.

Nutanix chose to build data and control planes from the ground up to be a Web-scale distributed system following all the above properties and guidelines. These guidelines not only guarantee resiliency, scalability, consistency, and tolerance to failures, but also ensure a platform to bootstrap future datacenter innovation.

 

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net

4 comments

1 ping

Skip to comment form

  1. brugh

    nice article. if new systems would be built with these directives my work would be much simpler 😉
    i’m unsure though what you are comparing in the last two paragraphs. vcenter is a management server (or service if you will) that manages a cluster that runs on top of hardware.
    nutanix doesnt manage anything above the platform layer and has nothing to do with whatever runs on top of it.
    i get the web-scale architecture but apart from the storage layer with NDFS, what is the link between vcenter and nutanix you’re trying to make?

  2. Andre Leibovici

    brugh, thanks for your comment.

    It doesn’t matter where vCenter or SCVMM or any other system is in relation to the hardware, cluster or hypervisor. The point here is that distributed systems would be more resilient as you add more nodes. This is one of the main points of web-scale. You do not need an external management platform to manage your cluster and hosts, they could be their own managers; and that’s what happens with Nutanix.

    Let’s for a moment imagine that vCenter was bolted into each ESXi server and they all talk to each other to create a very large distributed system. The more nodes you add, more resilient you management platform would become.

    Putting in other words, what if Nutanix distributed cluster was responsible for doing vCenter management tasks. This won’t happen, but I believe VMware should also be exploring distributed systems approach for vCenter.

  3. David Cruz

    Nice post. Your article always been informative. This is the who really gonna help me. Thanks. ti can make the work really easier

  4. Andre Leibovici

    David Cruz, Thanks!

  1. Call for Action Top vBlog 2015 > United We Scale-Out » myvirtualcloud.net

    […] Understanding Web-Scale Properties […]

Leave a Reply