Linux en VMware: ¿por qué usar particiones?

Al instalar máquinas virtuales Linux en un entorno virtualizado (ESXi en mi caso), ¿hay alguna razón convincente para particionar los discos (cuando se usa ext4) en lugar de simplemente agregar discos separados para cada punto de montaje?

Lo único que puedo ver es que hace que sea un poco más fácil ver si hay datos presentes en un disco con, por ejemplo, fdisk.

Por otro lado, puedo ver algunas buenas razones para no usar particiones (para otras que no sean / boot, obviamente).

• Mucho más fácil de extender discos. Es solo para aumentar el tamaño del disco para la VM (generalmente en VCenter), luego volver a escanear el dispositivo en la VM y cambiar el tamaño del sistema de archivos en línea.
• No más problemas con la alineación de particiones con LUN subyacentes.

No he encontrado mucho sobre este tema. ¿Me he perdido algo importante?

Esta es una pregunta interesante...

No creo que haya una respuesta definitiva, pero puedo dar un contexto histórico sobre cómo las mejores prácticas en torno a este tema pueden haber cambiado con el tiempo.

He tenido que soportar miles de máquinas virtuales Linux implementadas en diversas formas en entornos VMware desde 2007. Mi enfoque para la implementación ha evolucionado, y he tenido la experiencia única (a veces desafortunada ) de heredar y refactorizar sistemas creados por otros ingenieros.

Los viejos tiempos...

En el pasado (2007), mis primeros sistemas VMware se dividieron al igual que mis sistemas de metal desnudo. En el lado de VMware, estaba usando archivos gruesos divididos de 2GB para comprender los datos de la VM, y ni siquiera pensé en la noción de múltiples VMDK, ¡porque estaba feliz de que la virtualización pudiera funcionar!

Infraestructura virtual ...

Con ESX 3.5 y las primeras versiones de ESX / ESXi 4.x (2009-2011), estaba usando Linux, particionado como normal sobre archivos VMDK aprovisionados Thick monolíticos . Tener que preasignar el almacenamiento me obligó a pensar en el diseño de Linux de manera similar a como lo haría con el hardware real. Estaba creando VMDK de 36 GB, 72 GB, 146 GB para el sistema operativo, particionando el /, / boot, / usr, / var, / tmp habitual, y luego agregué otro VMDK para la partición de "datos" o "crecimiento" (ya sea / inicio, / opt o algo específico de la aplicación). Nuevamente, el punto óptimo en el tamaño de los discos duros físicos durante esta era fue de 146 GB, y dado que la preasignación era un requisito (a menos que usara NFS), necesitaba ser conservador con el espacio.

El advenimiento del aprovisionamiento delgado

VMware desarrolló mejores funciones en torno al aprovisionamiento delgado en versiones posteriores de ESXi 4.x, y esto cambió la forma en que comencé a instalar nuevos sistemas. Con el conjunto completo de características que se agregó en 5.0 / 5.1, un nuevo tipo de flexibilidad permitió diseños más creativos. Eso sí, esto se mantenía al ritmo de las capacidades mejoradas en las máquinas virtuales, en términos de cuántos vCPUS y cuánta RAM podría comprometerse con máquinas virtuales individuales. Se podrían virtualizar más tipos de servidores y aplicaciones que en el pasado. Esto es correcto ya que los entornos informáticos comenzaban a ser completamente virtuales.

LVM es horrible ...

Para cuando la funcionalidad completa de agregar en caliente a nivel de VM estaba en su lugar y era común (2011-2012), estaba trabajando con una empresa que se esforzó por mantener el tiempo de actividad de las máquinas virtuales de sus clientes a cualquier costo ( estúpido ). Por lo tanto, esto incluyó el aumento de CPU / RAM VMware en línea y el cambio de tamaño de disco LVM arriesgado en VMDK existentes. La mayoría de los sistemas Linux en este entorno eran configuraciones de VMDK individuales con particiones ext3 sobre LVM. Esto fue terrible porque la capa LVM agregó complejidad y riesgos innecesarios para las operaciones. Quedarse sin espacio en / usr, por ejemplo, podría dar lugar a una cadena de malas decisiones que eventualmente significarían restaurar un sistema a partir de copias de seguridad ... Esto estuvo parcialmente relacionado con el proceso y la cultura, pero aún así ...

El esnobismo de la partición ...

Aproveché esta oportunidad para intentar cambiar esto. Soy un poco snob de partición en Linux y creo que los sistemas de archivos deben estar separados para las necesidades operativas y de monitoreo. Tampoco me gusta LVM, especialmente con VMware y la capacidad de hacer lo que me pides. Así que amplié la adición de archivos VMDK a particiones que potencialmente podrían crecer. / opt, / var, / home podrían obtener sus propios archivos de máquina virtual si fuera necesario. Y esos serían discos en bruto. A veces, este era un método más fácil para expandir particiones particulares de menor tamaño sobre la marcha.

Obamacare ...

Con la incorporación de un cliente de muy alto perfil , me encargaron el diseño de la plantilla de referencia de VM de Linux que se utilizaría para crear su entorno de aplicación extremadamente visible. Los requisitos de seguridad de la aplicación requerían un conjunto único de montajes , por lo que trabajamos con los desarrolladores para tratar de agrupar las particiones sin crecimiento en un VMDK, y luego agregar VMDK separados para cada montaje que tenía potencial de crecimiento o tenía requisitos específicos (cifrado, auditoría, etc.) Entonces, al final, estas máquinas virtuales estaban compuestas de 5 o más VMDK, pero proporcionaban la mejor flexibilidad para el cambio de tamaño y la protección de datos en el futuro.

Lo que hago hoy ...

Hoy, mi diseño general para Linux y sistemas de archivos tradicionales es el sistema operativo en un VMDK delgado (particionado) y VMDK discretos para cualquier otra cosa. Agregaré en caliente según sea necesario. Para sistemas de archivos avanzados como ZFS, es un VMDK para el sistema operativo, y otro VMDK que sirve como un conjunto de ZFS y puede redimensionarse, dividirse en sistemas de archivos ZFS adicionales, etc.

Tiene razón en muchos aspectos, puedo ver el argumento; sin embargo, hay un problema que podría resultar complicado. Si usa grupos de recursos (y sé que no lo hago, cosas odiosas), las máquinas virtuales pueden obtener más tiempo de E / S si tienen más discos; en situaciones de recursos extremos limitados, una máquina virtual con dos discos podría obtener el doble de recursos de E / S que uno con Un solo disco. Puede que esto no sea un problema para usted, pero pensé en señalarlo.

Editar: ah, y también haría que el ajuste sea un poco más lento, pero nuevamente eso podría no ser un problema.

Cuando trabajaba en infraestructura en una "gran empresa de software de virtualización" en particular, a menudo necesitábamos aumentar el tamaño del sistema de archivos de un VM. Usamos ext3 / 4 en ese momento.

Incrementar el disco virtual es muy fácil, elegir el nuevo tamaño del dispositivo en un sistema operativo en vivo es relativamente fácil (hurgar en / sys), cambiar el tamaño del sistema de archivos ext3 / 4 en vivo fue fácil, pero lo que siempre parecía imposible (hacer en vivo) era Cambiar el tamaño de la partición.

Debía usar gparted o reescribir / cambiar el tamaño de la tabla de particiones usando fdisk, pero siempre estaba bloqueado por el núcleo y requería un reinicio para que el núcleo recogiera el nuevo diseño (partprobe tampoco lo hizo).

¡Moví muchos sistemas a LVM y cambiar el tamaño de los sistemas de archivos se convirtió en una experiencia fácil, casi agradable!

• Aumente la imagen del disco virtual fuera de la VM
• En la VM
  • Poke / sys para volver a analizar las métricas del disco (echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (redimensionar el volumen físico en LVM)
  • lvresize --extents + 100% FREE / dev / VG / lvolXX (redimensionar el volumen lógico en LVM)
  • resize2fs (cambiar el tamaño del sistema de archivos)

Todo esto se puede hacer de forma segura en un sistema en vivo, ¡ y no se requiere reiniciar!

¿Por qué no un disco desnudo? Me pone nervioso: no creo que los discos desnudos sean lo suficientemente aceptados todavía, pero creo que estamos al borde de una aceptación mucho más amplia. Había un hilo en la lista de correo btrfs relacionado con esto:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Pero un disco desnudo solo necesitaría rescan y resize2fs.

Entonces, en resumen, sí, evite las tablas de particiones si puede.

Si bien su pregunta tal como está escrita es sobre VMWare (ESXi), me gustaría agregar una situación en la que volví a usar tablas de partición después de tener la misma idea en KVM.

Resultó que si tiene volúmenes LVM como discos para máquinas virtuales y crea un grupo de volúmenes LVM dentro de la máquina virtual sin usar particiones (usando todo el disco virtual como PV), este VG será visible fuera de la máquina virtual en la máquina host. Este no es el caso si usa particiones como PV.

De acuerdo, es un caso de esquina, pero vale la pena considerarlo si necesita dicha configuración.

Si es mejor hacer esto o no depende de su sistema.

Hay ventajas y desventajas de cada configuración.

Sin embargo, las principales ventajas de un solo disco son las siguientes:

1. Simplicidad: una sola unidad tiene un solo archivo, que puede distribuirse y replicarse fácilmente.
2. Indicaciones para el sistema operativo host: un solo archivo se tratará como un solo bloque de datos y, por lo tanto, el sistema operativo host sabrá que todas las secuencias de acceso a la máquina invitada estarán en ese único archivo. Esto se puede lograr en algunas configuraciones del sistema operativo host simplemente colocando todas las imágenes de la unidad en el mismo archivo, pero no será necesariamente el caso.

Sin embargo, hay ventajas para la unidad múltiple.

1. Afinidad de metal desnudo / ubicación manual: con una sola unidad, está bloqueado a una sola afinidad de metal desnudo de la unidad.
2. Limitaciones de tamaño: si su sistema tiene límites en el tamaño de la unidad o en los archivos, puede afectarlos en sistemas muy grandes.
3. Volúmenes de solo lectura para seguridad: esta es la gran ventaja. Si su volumen maestro para el sistema operativo es de solo lectura en el lado de la VM, proporciona importantes ventajas de seguridad, esencialmente bloqueando la capacidad de los programas dentro de la VM de editar el sistema operativo base del invitado. El uso de una unidad de datos separada le permite crear unidades de solo lectura, que pueden iniciarse de lectura-escritura para mantenimiento y actualizaciones sin solo datos de plantilla de sala limpia, evitando la modificación de directorios vitales del sistema operativo desde el servidor por completo.

Hay otra opción: montar los datos de la aplicación en volúmenes NFS. Necesita buenos archivadores (no todas las implementaciones de NFS son iguales).

Cuando los volúmenes NFS se llenen, expanda el volumen, el cliente de Linux verá el espacio extra de inmediato.

Su aplicación y su proveedor deben admitir tener sus datos en NFS, y necesita un diseño NAS cuidadoso, pero así lo hace con todas las soluciones de almacenamiento para su entorno virtualizado.

Otro punto adicional para este enfoque es que si su proveedor de almacenamiento tiene tecnología de instantáneas / clonación (como zfs o Netapp), respaldar los datos y crear entornos de prueba / desarrollo es realmente fácil.

La razón por la que aún necesita particionar el disco para algunas distribuciones de Linux se debe al hecho de que hay un gestor de arranque y todas las piezas heredadas que lo acompañan, es decir, BIOS emulado. Esto hace que sea más difícil cambiar el tamaño de un disco y muchos terminarían usando LVM u otro sin sentido similar.

Simplemente se puede crear un sistema de archivos en todo el volumen y montarlo /, lo que funcionará con una distribución de Linux muy personalizada (o personalizable / no obstinada). La última vez que probé esto con Ubuntu 12.04, el instalador no sabía cómo manejarlo, ya que debía instalar su estúpida tabla de particiones y todo el jazz. Este es uno de los problemas de las distribuciones de propósito general en el mundo virtualizado.

Por otro lado, uno puede realmente hacer que la partición tenga un uso menos tradicional, por ejemplo, ChromeOS y CoreOS tienen dos particiones raíz de solo lectura para las actualizaciones del sistema.

Una razón que no se ha mencionado hasta ahora es que en algunas infraestructuras como Google Compute, el rendimiento del disco IO aumenta linealmente con el tamaño del disco . En otras palabras, una unidad particionada grande tendrá un mejor rendimiento de E / S que varias unidades pequeñas.

Tenga en cuenta que este no es generalmente el caso. Como mencionó Chopper3, la mayoría de las unidades múltiples tendrán un mejor rendimiento de E / S. En última instancia, si todas sus unidades virtuales se asignan a una sola unidad física, no debería haber diferencia.

En mi experiencia, el mejor enfoque es usar 1 VMDK para el sistema operativo y generalmente lo particiono de la siguiente manera:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

He encontrado que 8GB son suficientes para /, porque generalmente instalo una distribución mínima de Linux (~ 800MB) + software que necesito. Los registros también van a esa partición, pero si se configuran correctamente (rotar durante una semana) y se envían a otro lugar (syslog / elasticsearch), generalmente no representan un regalo para llenar la partición.

Los datos se agregan como otro VMDK, y generalmente formateo el sistema de archivos directamente sobre un disco vacío (por ejemplo, / dev / sdb). Esto me permite redimensionar el volumen en VmWare y redimensionarlo directamente en VM sin necesidad de volver a particionar / desmontar / reiniciar.

Particiono por dos razones:

1. Documentación: una vez tuve un administrador de EMC "capacitado" que me robó los LUN directamente porque estaban indocumentados y le parecían no asignados, y en medio de la noche, se buscó una base de datos Oracle que de repente se desconectó. Había reaprovisionado mis LUN para otro volumen para una aplicación no relacionada. Desde entonces estoy paranoico sobre la documentación.
2. Sobreaprovisionamiento de mi disco. Con platos, mantiene los datos fuera de los cilindros más lentos y con SSD, extiende la vida útil / MTBF.