¿Es la mejor práctica en la nube seguir teniendo varios discos (volúmenes) para un servidor?

Question

En elviejos tiemposEn el caso de los servidores físicos, se consideraba una buena práctica (al menos en los lugares en los que he trabajado) que un servidor siempre tuviera al menos dos discos (volúmenes), sin importar cuán simple estuviera alojada una aplicación.

Un disco para el Sistema Operativo (SO) y otro para la Aplicación. Hubo varias razones para esto:

1. Si la aplicación mata su disco, llenándolo o martillándolo con E/S, normalmente aún podría iniciar sesión y ver qué estaba pasando y el sistema operativo podría seguir registrando eventos para informarle lo que podría haber sucedido.
2. Detuvo el impacto del sistema operativo en el rendimiento de la aplicación al competir por las E/S disponibles desde un único volumen.
3. La copia de seguridad/restauración solo podría preocuparse por el disco de la aplicación, ya que el sistema operativo podría reconstruirse.
4. El disco de la aplicación se pudo administrar (por ejemplo, desmontar) porque esto no afectó al sistema operativo.

De forma predeterminada, los servidores en la nube solo tienen un disco. ¿Qué me hizo pensar si este enfoque de discos múltiples todavía tenía sentido en la nube? Teniendo en cuenta los puntos anteriores: (1), (3) y (4) probablemente todavía se apliquen, pero (2) menos ya que los discos son virtuales: asignados a un subsistema de almacenamiento que el proveedor de la nube administra de maneras que no puedo ver.

Entonces, ¿parece que todavía vale la pena seguir esta mejor práctica en la nube?

¿O me he perdido algún motivo por el que no es tan importante utilizar varios volúmenes en un entorno de nube?

Answer 1

El alquiler de computadoras como servicio no cambia significativamente la decisión de utilizar discos de datos separados.

Por supuesto, puede cambiar los valores predeterminados, ¿por qué si no existiría la API para crear y agregar discos adicionales a las instancias?

Un disco es más sencillo de administrar. Especialmente para imágenes relativamente estáticas donde la instancia es el sistema operativo y la instalación de la aplicación, no hay muchos datos dinámicos.

Evitar que el sistema de archivos esté lleno sigue siendo útil. Aunque son posibles otras soluciones además de varios discos físicos. Separe volúmenes lógicos con LVM. O registro o mensajería centralizados de modo que algunas instancias no tengan archivos de datos en crecimiento.

Exceder las cuotas de IOPS y tamaño puede requerir combinar varios discos en volúmenes lógicos. (Al menos la cuota tiende a estar bien definida en la nube, incluso si la matriz física sigue siendo un misterio). Existen bases de datos escalables.

Los volúmenes de datos separados permiten algunos trucos a nivel de bloque. Imagine una actualización importante del sistema operativo para una instancia de base de datos, pero no existe un almacenamiento secundario al que replicar. Prepare una instancia actualizada, pero sin datos. Durante el tiempo de inactividad, desmonte y separe volúmenes de datos, preséntelos en una nueva instancia y móntelos. Actualización rápida, sin copia de datos, sin segunda copia del volumen.