Является ли передовой облачной практикой использование нескольких дисков (томов) для сервера?

в старые времена физических серверов считалось хорошей практикой (по крайней мере, в тех местах, где я работал), чтобы на сервере всегда было как минимум два диска (тома), независимо от того, насколько просто размещалось приложение.

Один диск для операционной системы (ОС), а другой для приложения. Тому было несколько причин:

1. Если Приложение убило свой диск, заполнив его или забив его операциями ввода-вывода, вы, как правило, все еще могли войти в систему и посмотреть, что происходит, а ОС могла бы продолжать регистрировать события, чтобы сообщить вам, что могло произойти.
2. Это остановило влияние ОС на производительность приложения, конкурируя за операции ввода-вывода, доступные из одного тома.
3. Резервное копирование/восстановление может просто беспокоить диск приложений, так как ОС может быть пересобрана.
4. Диском приложений можно было управлять (например, размонтировать), потому что это не влияло на ОС.

По умолчанию облачные серверы имеют только один диск.Что заставило меня задуматься о том, имеет ли смысл этот многодисковый подход в облаке? Принимая во внимание приведенные выше пункты: (1), (3) и (4), вероятно, все еще применимы, но (2) в меньшей степени, поскольку диски являются виртуальными: они отображаются на подсистему хранения, которой управляет облачный поставщик способами, которые я не вижу.

Получается, что этой передовой практике все еще стоит следовать в облаке?

Или я упустил причину, по которой не так важно использовать несколько томов в облачной среде?

Аренда компьютеров как услуга существенно не меняет решение об использовании отдельных дисков данных.

Конечно, вы можете изменить значения по умолчанию, иначе зачем бы существовал API для создания и добавления дополнительных дисков к экземплярам.

Одним диском проще управлять. Особенно для относительно статических образов, где экземпляром является установка ОС и приложения, не так много динамических данных.

Предотвращение заполнения файловой системы остается полезным. Хотя возможны и другие решения, кроме нескольких физических дисков. Разделяйте логические тома с помощью LVM. Или централизованное ведение журнала или обмен сообщениями, чтобы у некоторых экземпляров не было растущих файлов данных.

Превышение квот на IOPS и размер может потребовать объединения нескольких дисков в логические тома. (По крайней мере, квота, как правило, четко определена в облаке, даже если физический массив остается загадочным.) Существуют масштабируемые базы данных.

Отдельные тома данных позволяют использовать некоторые трюки на уровне блоков. Представьте себе серьезное обновление ОС для экземпляра базы данных, но не существует вторичного хранилища для репликации. Подготовьте обновленный экземпляр, но без данных. Во время простоя отключайте и отключайте тома данных, представляйте их новому экземпляру и подключайте. Быстрое обновление, без копирования данных, без второй копии тома.