Everyone who works in IT knows (or should know) that the word “scale” means “to increase the size of” something so it can handle a bigger workload. If you have more demand hitting a server, you must “scale” it to serve that demand. Products get evaluated on their ability to scale.
So far, so good, but now consider that there are two kinds of scaling: scale-up and scale-out. What is the difference between scale-up versus scale-out? Simply put, scale-up refers to making the existing resource larger. Scale-out means adding more resources of similar size. [Figure 1]
For example, let’s say you have a two-slot toaster. That’s fine if you want two pieces of toast. But what if eight people want toast at the same time? You could buy an eight-slot toaster. Or, you could buy three more two-slot toasters.
Either way, you can make eight slices of toast at once. The eight-slot toaster represents scaling up. Having four two-slot toasters is scaling out. Does it matter? Yes. Each approach has its own reason for being the right choice under a given set of circumstances. People may want different kinds of bread toasted, for example. That would favor the scale-out approach to toast. What if all eight toast customers are crowding you and need the same kind of toast immediately? That would favor the scale-up, eight-slot toaster.
In IT, scale-up, also known as “vertical scaling,” means adding more capacity to an existing system. The results will be called a “scale-up architecture.” For example, with a database, building a scale-up architecture involves adding more processors to the database server CPU and/or adding data storage capacity to that server. The goal is usually to handle a higher load while meeting service level agreements (SLAs).
Scale-out for the database, in contrast, requires installing additional database server instances to meet the new load under existing SLA terms. If the load doubles, you get two database servers. If the load triples, you add a third database server, and so forth.
What are the advantages and disadvantages of a scale-up architecture?
Why would you choose scale-up versus scale-out? Each approach has its advantages and disadvantages. There’s a whole lot of “it depends” reasoning that goes into figuring out which way is best. In general, though, the main advantage of scale-up, especially for architecture, is its relative speed, simplicity, and low cost. All things being equal, it’s typically easier, faster and cheaper to buy a bigger box and install it.
A dual-processor replaces a single processor and voila, you’ve doubled your CPU throughput. And, if you’re simply making an existing machine bigger, then most of the software configuration and network connectivity stays the same. That alone saves a lot of hassle and time from the scaling process.
The question, then, is why not scale-up all the time? Scale-up has drawbacks in certain situations. One issue is that switching to a new machine causes downtime, which doesn’t happen with scale-out. In scale-out, you add a new instance, which enables switchover.
More significantly, some use cases simply don’t favor scale-up. For instance, a workload may not move faster on a higher-capacity machine. Video processing is one example of a workload that may not run faster in a scale-up architecture. A scale-up architecture may result in higher latency, leading to poorer application performance. In contrast, running multiple machines in parallel can reduce latency for end users and improve application performance.
What are the advantages and disadvantages of a scale-out architecture?
Scale-out is not always the automatic answer for greater demand, either. For one thing, you may run out of rack space. And more than likely increase your power and cooling costs. Standing up new equipment and configuring a scale-out cluster also takes time and effort. Upfront costs tend to be higher with scale-out because of the person-hours and additional equipment involved. Scaling out with virtual machines (VMs) in the cloud is an option, but it may add latency and administrative overhead. We’ll save that topic for a later blog.
Which architecture is better suited for private clouds: scaling up or scaling out?
Which architecture is better for a private cloud: scale-up or scale-out? Again, it depends. The choice depends partly on how you set up your private cloud. If your private cloud runs in an on-premises data center or colocation facility, you’ll face all of scale-out’s space and cost issues. However, if the workload is best suited to scale-out, it will still be the right choice.
Issues to consider when deciding on scale-up vs scale-out in a private cloud include:
- What are your SLAs and how will the choice affect your ability to meet them?
- How critical is latency? Will scale-up or scale-out negatively impact latency?
- How will either choice affect your admin capacity? Will it overstretch the team? Do you have the required skill set?
- Are you constrained by space, cost, or both?
How does NVMe/TCP integrate into a scale-out storage architecture?
NVMe-based SSDs, disaggregated storage, and scale-out software-defined architectures deliver highly efficient infrastructure for private clouds. Disaggregated architecture is a form of scale-out, built with a set of shared storage devices that can be allocated to any server on the network over a high-performance network. NVMe over TCP (NVMe/TCP) networking is a critical part of this solution because it runs on industry-standard Ethernet and TCP/IP networks to enable high performance, high availability, low latency, high scalability, and greater efficiency. Anyone running iSCSI today can run NVMe/TCP on the same hardware.
The advantage of NVMe/TCP is that it requires no special drivers, custom hardware, or additional expenses (over and above iSCSI), while delivering an order of magnitude lower storage latencies. NVMe/TCP enables a move to disaggregated (i.e., scale-out) shared storage.
Related Blogs:
