Is Cloud Best Practice To Still Have Multiple Disks (Volumes) For a Server?

Question

In the old days of physical servers, it was considered good practice (at least at the places I have worked at) for a server to always have at least two disks (volumes) no matter how simple an application was being hosted.

One disk for the Operating System (OS) and another for the Application. There were a number of reasons for this:

1. If the Application killed its disk, by filling it up or hammering it with I/Os, you could usually still log on and see what was going on and the OS would be able to keep logging events to tell you what might have happened.
2. It stopped the OS impacting the application's performance by contending for the I/Os available from a single volume.
3. Backup/Restore could just worry about the Application Disk, as the OS could be re-built.
4. The Application Disk could be managed (e.g. umounted) because this didn't affect the OS.

By default, cloud servers only have one disk. Which made me think about whether this multiple disk approach still made sense in the cloud? Considering the points above: (1), (3) and (4) probably still apply, but (2) less so as disks are virtual: mapped onto a storage subsystem the cloud vendor manages in ways I don't get to see.

So it appears that this best practice is still worth following in the cloud?

Or have I missed a reason why it is not as important to use multiple volumes in a cloud environment?

Answer 1

Renting computers as a service does not significantly change the decision to use separate data disks.

Of course you can change the defaults, why else would the API exist to create and add additional disks to instances.

One disk is simpler to manage. Especially for relatively static images where the instance is the OS and application install, not much dynamic data.

Preventing file system full remains useful. Although solutions other than multiple physical disks are possible. Separate logical volumes with LVM. Or centralized logging or messaging such that some instances do not have growing data files.

Exceeding quotas on IOPS and size may require combining multiple disks into logical volumes. (At least the quota tends to be well defined in cloud, even if the physical array remains mysterious.) Scale up databases exist.

Separate data volumes allows for some block level tricks. Imagine a major OS upgrade for a database instance, but no secondary storage exists to replicate to. Prepare an upgraded instance, but with no data. During downtime, dismount and detach data volumes, present them to new instance, and mount. Fast upgrade, no data copying, no second copy of the volume.