Is shared disk architecture scaling up or scaling out?

Question

In Design Data Intensive Applications,

If all you need is to scale to higher load, the simplest approach is to buy a more powerful machine (sometimes called vertical scaling or scaling up). Many CPUs, many RAM chips, and many disks can be joined together under one operating system, and a fast interconnect allows any CPU to access any part of the memory or disk. In this kind of shared-memory architecture, all the components can be treated as a single machine [1].

The problem with a shared-memory approach is that the cost grows faster than linearly: a machine with twice as many CPUs, twice as much RAM, and twice as much disk capacity as another typically costs significantly more than twice as much. And due to bottlenecks, a machine twice the size cannot necessarily handle twice the load.

A shared-memory architecture may offer limited fault tolerance—high-end machines have hot-swappable components (you can replace disks, memory modules, and even CPUs without shutting down the machines)—but it is definitely limited to a single geographic location.

Another approach is the shared-disk architecture, which uses several machines with independent CPUs and RAM, but stores data on an array of disks that is shared between the machines, which are connected via a fast network. ii This architecture is used for some data warehousing workloads, but contention and the overhead of locking limit the scalability of the shared-disk approach [2].

By contrast, shared-nothing architectures [3] (sometimes called horizontal scaling or scaling out) have gained a lot of popularity. In this approach, each machine or virtual machine running the database software is called a node. Each node uses its CPUs, RAM, and disks independently. Any coordination between nodes is done at the software level, using a conventional network.

Is shared disk architecture scale-up or scale out or both or neither?

The architectures uses multiple machines, since "several machines with independent CPUs and RAM, but stores data on an array of disks that is shared between the machines".

But I am not sure if the architecture is scaling out, because the machines share disks, and the book doesn't mention scaling out until shared nothing architecture.

Thanks.

Answer 1

Shared disk is vertically scaled approach for disk. As Robert Harvey points out, you are scaling horizontally for memory and CPU but the disk is one (or a few) component.

There's a simple way to determine whether something is horizontally or vertically scaled. If you want to add more capacity, do you add more components (memory, disk, CPU) or do you need to increase the capacity of the component (or replace it.)

Answer 2

Looking at the definitions you quote, my personal interpretation is that shared-disk architecture is still vertically-scaling architecture. True, CPU and memory can be scaled horizontally indefinitely, but the bottleneck is still in the disk storage. And disk storage cannot natively scale horizontally, it can only be scaled vertically. So sooner or later, you hit a limit of vertical scaling of disk throughput.

Answer 3

At this point, its best to think of the disks as no longer part of the server, but a separate and specialised form of the service 'Network Attached Storage' (or NAS).

In simple cases, NAS provides a block interface (e.g. using iSCSI) to a single remote computer to use as a disk for its own sole use. However, the article quoted goes an extra step, providing the same block interface to multiple servers.

This service can be scaled vertically, by adding more disks into the NAS to increase the capacity, or by increasing the multiple redundant copies to improve read throughput . (e.g. RAID)

At first glance, this service can also be scaled horizontally by having multiple NAS controllers mirror each other. However the complexities of keeping multiple copies of data concurrent over multiple servers, with the exacting requirements of a filesytem means that in practice, mirrors are used for redundancy and read only performance, improving fault tolerance and availability characteristics, but not overall throughput (and no additional scaling).