46 votos

Linux sobre VMware - ¿por qué utilizar particiones?

Al instalar Linux en máquinas virtuales en un entorno virtualizado (ESXi en mi caso), hay razones de peso para partición de los discos (cuando se utiliza el sistema de archivos ext4) en lugar de sólo la adición de discos independientes para cada punto de montaje?

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

Por otro lado, puedo ver algunas buenas razones para no usar particiones (para otros de /boot, obviamente).

  • Mucho más fácil de extender los discos. Es sólo para aumentar el tamaño del disco de la máquina virtual (normalmente en VCenter), a continuación, volver a examinar el dispositivo en la máquina virtual, y cambiar el tamaño del sistema de archivos en línea.
  • No más problemas con la alineación de particiones con la que subyace a Lun.

No he encontrado mucho sobre este tema alrededor. He perdido algo importante?

27voto

Tina Puntos 21

Esta es una pregunta interesante...

Yo no creo que haya una respuesta definitiva, pero me puede dar un poco de contexto histórico sobre cómo las mejores prácticas en torno a este tema puede haber cambiado con el tiempo.

Yo he tenido el apoyo de miles de Linux VMs desplegados en diversas formas a través de los entornos de VMware desde 2007. Mi acercamiento a la implementación que se ha evolucionado, y he tenido el único (a veces lamentable) la experiencia de heredar y refactorización de los sistemas construidos por otros ingenieros.

Los viejos tiempos...

De vuelta en el día (2007), mis primeros VMware sistemas con particiones igual que mis sistemas bare metal. En el VMware lado, yo estaba usando split 2GB de espesor archivos de incluir los datos de máquina virtual, y ni siquiera pensar acerca de la noción de múltiples VMDKs, porque yo estaba feliz de que la virtualización podría incluso trabajar!

La Infraestructura Virtual...

Por ESX 3.5 y principios de los ESX/ESXi 4.x versiones (2009-2011), yo estaba usando Linux, con particiones como normal en la cima monolítico de Espesor aprovisionado archivos VMDK. Tener que asignar previamente almacenamiento me obligó a pensar acerca de Linux de diseño de una manera similar como lo haría con hardware real. Yo era la creación de 36GB, 72 GB, 146GB VMDK para el sistema operativo, la partición de la costumbre /, /boot, /usr, /var, /tmp, luego añadir otro VMDK para los "datos" o "crecimiento" de la partición (ya sea el /home, /opt o algo específico de la aplicación). De nuevo, el punto ideal en física tamaños de disco duro durante esta época fue 146GB, y desde preallocation era un requisito (a menos que el uso de NFS), necesitaba ser conservador con el espacio.

El advenimiento de thin provisioning

VMware desarrollado mejores características en torno a Thin provisioning en adelante ESXi 4.x lanzamientos, y esto cambió mi manera comenzó a instalar nuevos sistemas. Con el conjunto completo de características agregadas en 5.0/5.1, un nuevo tipo de flexibilidad que permiten los diseños más creativos. La mente, que era mantener el ritmo de aumento de las capacidades de las máquinas virtuales, en cuanto al número de vCPUS y la cantidad de RAM que podría estar comprometido a máquinas virtuales individuales. Más tipos de servidores y aplicaciones podrían ser virtualizado que en el pasado. Esto es justo como entornos de computación estaban empezando a ir totalmente virtual.

LVM es horrible...

Por el tiempo completo en caliente agregar la funcionalidad de la VM nivel estaba en el lugar y común (2011-2012), yo estaba trabajando con una empresa que se esforzó por mantener el tiempo de actividad de sus clientes VMs a cualquier costo (estúpido). Por lo que esta incluido en línea de VMware de CPU/memoria RAM aumenta y arriesgado LVM cambio de tamaño existentes VMDKs. La mayoría de los sistemas Linux en este entorno único VMDK configuraciones con particiones ext3 en la parte superior de LVM. Este fue terrible porque el LVM capa que se agrega complejidad y riesgos innecesarios para las operaciones. Quedando sin espacio en /usr, por ejemplo, podría resultar en una cadena de malas decisiones que a la postre significó la restauración de un sistema de copias de seguridad... Esto fue en parte del proceso y relacionados con la cultura, pero aún así...

Partición de esnobismo...

Aproveché esta oportunidad para intentar cambiar esto. Soy un poco una partición-snob en Linux y sentir que los sistemas de ficheros deben ser separados para el monitoreo y necesidades operacionales. También me disgusta LVM, especialmente con VMware y la capacidad para hacer lo que usted está preguntando acerca de. Así que amplié la adición de archivos VMDK a las particiones que podrían llegar a ser. /opt, /var, /home podría conseguir sus propios archivos de la máquina virtual, si es necesario. Y esos serían los discos raw. A veces, este era un método más fácil para expandir particular partición de poco tamaño sobre la marcha.

Obamacare...

Con la incorporación de un muy alto perfil de cliente, que tuvo la tarea con el diseño de Linux VM plantilla de referencia que se utiliza para crear su muy visible del entorno de la aplicación. Los requisitos de seguridad de la aplicación se requiere de un conjunto único de montajes, tan trabajado con los desarrolladores para probar a meter por el no-crecimiento de las particiones en un VMDK y, a continuación, agregar separado VMDKs para cada montaje que tenía el potencial de crecimiento o tenía requisitos específicos (cifrado, auditoría, etc.) Así que, al final, estas máquinas virtuales se compone de 5 o más VMDKs, pero siempre que la mejor flexibilidad para el futuro cambio de tamaño y de protección de datos.

¿Qué puedo hacer hoy...

Hoy, mi generales de diseño para Linux y tradicional de los sistemas de ficheros es OS en una delgada VMDK (particiones), y discretos VMDKs para otra cosa. Voy a agregar en activo como sea necesario. Para los avanzados sistemas de ficheros como ZFS, es uno de los VMDK para el sistema operativo, y otra VMDK que sirve como una ZFS zpool y se pueden cambiar de tamaño, tallada a otros sistemas de archivos ZFS, etc.

7voto

Some French Guy Puntos 96

Tienes razón en muchas maneras, puedo ver el argumento - hay una cuestión que podría resultar difícil sin embargo. Si utiliza grupos de Recursos (y sé que no, odio las cosas), a continuación, las máquinas virtuales puede obtener más IO tiempo si tienen más discos en extrema de recursos limitados situaciones de una VM con dos discos podría conseguir el doble IO de recursos como uno con un solo disco. Esto bien puede no ser un problema para usted, pero pensé en punto.

Editar - ah, y que haría que el ajuste es un poco más lento, pero de nuevo, que podría no ser un problema.

6voto

rrauenza Puntos 181

Cuando yo trabajaba en infraestructura en una "gran empresa de software de virtualización," a menudo nos necesita para aumentar el tamaño de una máquina virtual del sistema de ficheros. Hemos utilizado ext3/4 en el momento.

El aumento de la disco virtual es muy fácil, recogiendo el nuevo tamaño del dispositivo en un sistema operativo live es relativamente fácil (hurgar en /sys), cambiar el tamaño de la ext3/4 sistema de ficheros en vivo fue fácil, pero lo que siempre pareció imposible (en vivo) fue cambiar el tamaño de la partición.

Tenía que usar gparted o reescribir/cambiar el tamaño de la tabla de particiones con fdisk-pero siempre fue bloqueado por el kernel y requiere un reinicio para obtener el kernel para recoger el nuevo diseño (partprobe no hacerlo bien).

Me mudé muchos sistemas de LVM y el tamaño de los sistemas de ficheros se convirtió en una forma fácil, casi agradable, la experiencia!

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

Todo esto se podría hacer de manera segura en un sistema vivo -- y reinicio no se requiere!

¿Por qué no un desnudo de disco? Me pone nervioso - yo no siento que llevaban los discos son ampliamente aceptadas aún lo suficiente, pero creo que estamos en el borde de la mucho más amplia aceptación. Había un hilo en el btrfs lista de correo con relación a esto:

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

Pero un desnudo de disco tendría que sólo la reexploración y resize2fs.

Así que, en resumen, sí, evitar la partición de tablas, si puede.

1voto

Sven Puntos 51980

Mientras que su pregunta como está escrito es acerca de VMWare (ESXi), me gustaría agregar una situación en la que me cambié de nuevo a usar las tablas de particiones después de haber tenido la misma idea sobre KVM.

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

Concedido, es un caso de esquina, pero vale la pena considerar si usted necesita una instalación de estas.

1voto

Si es mejor hacer esto o no, depende de tu sistema.

Hay pros y los contras de cada instalación.

Sin embargo, las principales ventajas de un único disco son como sigue:

  1. Simplicidad: Una sola unidad tiene un único archivo, que puede ser fácilmente distribuidos y replicados.
  2. Señales para el sistema operativo de Host: UN único archivo serán tratados como un solo bloque de datos, y por lo tanto el sistema operativo del host se sabe que las secuencias de la máquina huésped acceso a todos estarán en un archivo. Esto puede ser logrado en algunas configuraciones del sistema operativo simplemente colocando todas las imágenes de disco en el mismo archivo, pero no tiene que ser necesariamente el caso.

Sin embargo, hay ventajas a la multi-unidad.

  1. Bare metal afinidad / manual de la ubicación: Con una sola unidad que están bloqueados a un solo bare-metal de la afinidad de la unidad.
  2. Las limitaciones de tamaño: Si su sistema tiene límites en el tamaño de la unidad o en los archivos, usted podría golpear en muy grandes sistemas.
  3. Volúmenes Solo de lectura para la seguridad: Esta es la gran ventaja. Si su volumen maestro para el sistema operativo es de sólo lectura en la VM lado proporciona ventajas importantes de seguridad, esencialmente el bloqueo de la capacidad de los programas dentro de la máquina virtual a partir de la edición de la base del sistema operativo huésped. Utilizando otra unidad de datos le permite crear sólo lectura unidades, que pueden ser arrancado de lectura-escritura para el mantenimiento y las actualizaciones sin sala blanca de la plantilla de datos, la prevención de la modificación de vital OS directorios en el servidor por completo.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X