Является ли облачная практика лучшей по-прежнему иметь несколько дисков (томов) для сервера?

Question

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

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

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

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

Так что, похоже, этой передовой практике все еще стоит следовать в облаке?

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

Answer 1

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

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

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

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

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

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