Pregunta ¿Qué tan malo es realmente instalar Linux en una gran partición?


Estaremos ejecutando CentOS 7 en nuestro nuevo servidor. Tenemos 6 unidades de 300 GB en raid6 internas al servidor. (El almacenamiento es en gran parte externo en forma de una caja de incursión de 40 TB). El volumen interno llega a aproximadamente 1,3 TB si se formatea como un solo volumen. Nuestro administrador de sistemas cree que es una muy mala idea instalar el sistema operativo en una gran partición de 1.3TB.

Soy bióloga Constantemente instalamos nuevo software para ejecutar y probar, la mayoría de los cuales aterriza en / usr / local. Sin embargo, debido a que tenemos cerca de 12 biólogos expertos en informática que utilizan el sistema, también recopilamos muchos cruceros en / home también. Nuestro último servidor tenía una partición de 200GB para /, y después de 2.5 años estaba 90% llena. No quiero que vuelva a suceder, pero tampoco quiero ir en contra del consejo de los expertos.

¿Cómo podemos usar mejor los 1.3TB disponibles para asegurarnos de que haya espacio disponible cuando y donde sea necesario, pero no crear una pesadilla de mantenimiento para el administrador del sistema?


91
2017-09-18 08:12


origen


Usa LVM y redimensiona a voluntad - thanasisk
@thanasisk At will resizability es un mito, porque no hay ningún sistema de archivos en Linux que se pueda reducir en línea. ext2 tuvo tal parche en los tiempos antiguos. - peterh
@PeterHorvath: ¿está satisfecho si sustituyo "redimensionar" por "expandir"? - thanasisk
¡Es un poco irreal esperar que lo que usted configure ahora sea óptimo en 2.5 años! Y el hecho de que los usuarios no expertos están haciendo un lío es una razón más para separar el sistema operativo de los datos. - JamesRyan
@PeterHorvath Leí tu comentario más de una vez solo para poder entenderlo. Usted escribió que estaría contento si existiera un sistema de archivos que pudiera expandirse y yo señalé un sistema de archivos que sí lo hace. Eso es todo. - gparent


Respuestas:


Las razones principales (históricas) para la partición son:

  • a Separe el sistema operativo de su usuario y los datos de la aplicación.. Hasta el lanzamiento de RHEL 7 no hubo soporte. ruta de actualización y una actualización de la versión principal requeriría una reinstalación y luego tener, por ejemplo, /home y otros datos (de aplicación) en particiones separadas (o volúmenes LVM) le permiten conservar fácilmente los datos de usuario y de aplicación y borrar las particiones del sistema operativo.

  • Los usuarios no pueden iniciar sesión correctamente y su sistema comienza a fallar de formas interesantes cuando se queda completamente sin espacio en disco. Las particiones múltiples le permiten asignar espacio de disco duro reservado para el sistema operativo y mantenerlo separado del área donde los usuarios y / o aplicaciones específicas pueden escribir (por ejemplo, /home /tmp/ /var/tmp/ /var/spool/ /oradata/ etc.), mitigando el riesgo operacional De usuarios y / o aplicaciones mal comportados.

  • Cuota. La cuota de disco permite al administrador evitar que un usuario individual use todo el espacio disponible, interrumpiendo el servicio a todos los demás usuarios del sistema. La cuota de disco individual se asigna por sistema de archivos, por lo que una sola partición y, por lo tanto, un solo sistema de archivos significa solo 1 unidad de disco. Múltiples particiones (LVM) significa múltiples sistemas de archivos que permiten una administración de cuotas más granular. Según el escenario de uso que desee, por ejemplo, puede permitir a cada usuario 10 GB en su directorio de inicio, 2TB en el directorio / data en la matriz de almacenamiento externo y configurar un área de scratch compartida grande donde cualquier persona puede volcar conjuntos de datos demasiado grandes para su directorio de inicio y donde la política se vuelve "completa está llena", pero cuando eso sucede, tampoco se rompe nada.

  • Siempre que rutas dedicadas de IO. Es posible que tenga una combinación de discos SSD y discos giratorios y haría bien en tratarlos de manera diferente. No tanto como un problema en un servidor de propósito general, pero bastante común en las configuraciones de bases de datos es también asignar ciertos ejes (discos) a diferentes propósitos para evitar la contención de IO, por ejemplo. discos separados para los registros de transacciones, discos separados para datos reales de la base de datos y discos separados para espacio temporal. .

  • Bota Es posible que tenga una necesidad de un separado /boot dividir. Históricamente, para solucionar problemas de BIOS con el arranque más allá del límite de 1024 cilindros, en la actualidad es más frecuente que se admitan volúmenes encriptados, que sean compatibles con ciertos controladores RAID, HBA que no admiten el arranque desde SAN o sistemas de archivos que el instalador no admite de inmediato.

  • Sintonización Es posible que necesite diferentes opciones de ajuste o incluso sistemas de archivos completamente diferentes.

Si usa particiones duras, más o menos debe hacerlo correctamente en el momento de la instalación y luego una sola partición grande no es lo peor, pero sí viene con algunas de las restricciones anteriores.

Normalmente recomiendo particionar su volumen principal como gran volumen físico de Linux LVM y entonces crear volúmenes lógicos que se ajusten a sus necesidades actuales y por el resto de su espacio en disco, dejar sin asignar hasta que sea necesario.

Puede expandir esos volúmenes y sus sistemas de archivos según sea necesario (que es una operación trivial que se puede realizar en un sistema en vivo) o crear otros adicionales.

Reducir los volúmenes de LVM es trivial pero a menudo no se admite muy bien la reducción de los sistemas de archivos en ellos y probablemente debería ser evitado.


103
2017-09-18 09:49



En relación con el rendimiento, creo que también vale la pena señalar que, en caso de que se presente un sistema de archivos, se necesita una respuesta rápida, y 'df' devolverá información útil mucho más rápido que 'du -s $ DIRNAME' - symcbean
No estoy seguro de estar de acuerdo con "hasta que ... RH7 ... no hay ruta de actualización compatible". He realizado actualizaciones compatibles desde tiempo fuera de la mente, y sin duda mejoré los sistemas RH4-> 5. Es solamente RH5-> RH6 que carecía de tal camino, que yo sepa, y tengo la sensación de que sus usuarios lo han azotado por esa falta. +1 por el resto de una excelente respuesta, sin embargo. - MadHatter
¿A qué se refiere con "Hasta el lanzamiento de RHEL 7 no había una ruta de actualización compatible"? ¿RHEL admitirá actualizaciones entre las versiones principales de RHEL 7 y versiones posteriores? - Markus Hallmann
Las actualizaciones funcionaron, pero de acuerdo con sombrero rojo La política general todavía es: Red Hat no admite actualizaciones in situ entre las versiones principales de Red Hat Enterprise Linux.  Y un poco de matiz mas abajo. Red Hat actualmente admite actualizaciones de Red Hat Enterprise Linux 6 a Red Hat Enterprise Linux 7 solo para casos de uso específicos / específicos y aquí está el manual verificar - HBruijn


El concepto de usar varias particiones es que una completa en el lugar equivocado no hará que todo el sistema funcione de forma inesperada.

Considere un proceso en la máquina que llena un archivo de registro bastante rápido hasta el punto de que no hay espacio libre disponible. En una máquina de una sola partición, esto podría, por ejemplo, impedir que el sistema escriba datos nuevos en / tmp. Si hay otro proceso que querría escribir en / tmp, probablemente se cerraría con un error, lo que provocaría un comportamiento inesperado.

Esto se puede evitar si usa particiones diferentes para lugares donde los usuarios o procesos escriben normalmente en (/ home, / var, / tmp).

Le recomendaría que verifique su antiguo servidor en qué carpetas tienden a crecer. Puedes hacerlo en la línea de comandos con

du -h -d 1 / 2> /dev/null

Verá dónde se acumula la mayor cantidad de datos y diseñará su próximo sistema de manera adecuada. La "-d 1" limita la salida a solo un nivel de profundidad de carpeta para que sea más legible.


17
2017-09-18 08:38





El principal problema de tener una sola partición grande es que al llenar el sistema de archivos es posible que ya no sea posible iniciar sesión.

El usuario root tiene su carpeta de inicio (/root) fuera de /home Debido a esto. Si el sistema de archivos se llena en algunas circunstancias, incluso la raíz no puede iniciar sesión y no puede reparar el sistema.

Esta es la razón por la que normalmente crea puntos de montaje separados para /var, /tmp y /home para poder iniciar sesión al menos como root para reparar el sistema cuando una de las otras particiones está llena.


12
2017-09-18 08:23



en algunos sistemas de archivos (ext3 f.e.) puede tener un pequeño espacio reservado para que el usuario root pueda evitar ese comportamiento. tendría que usar cuotas para evitar eso, lo mismo para / tmp que a menudo se olvida. - Dennis Nolte
@DennisNolte me olvidé de /tmp. Gracias, voy a añadir esto a mi respuesta. - Uwe Plonus
@DennisNolte el espacio reservado ayudará, pero creo que el mantenimiento es más difícil que usar diferentes particiones, ya que tiene que configurar cuotas correctamente. - Uwe Plonus
Creo que una razón más importante para /root estar fuera /home Es que en algunas instalaciones. /home estará en una unidad de red. En caso de que haya un problema al montarlo en la red, los archivos de raíz permanecen accesibles. (Esto puede compararse a cómo suele haber un editor de texto en /bin, en caso /usr no se monta.) Sospecho que este es un escenario más común en la práctica, en estos días, que /home llenando todo el camino. - Eliah Kagan


En mi humilde opinión, tener una partición como / es bastante razonable.

Pero puedes usar lvm (administrador de volumen lógico). Utilice todos los discos como grupo lvm, pero cree pequeños discos lógicos para /, / home, / usr y lo que prefiera su administrador de sistemas. Luego, ponga un poco de control en el momento en que su sistema comience a llenarse y expanda los discos que necesita. lvresize y resize2fs son herramientas en línea y puede hacer una expansión sin reiniciar el servidor. Sin embargo, no puede reducir los discos, por lo que necesita comenzar de forma razonablemente pequeña y aumentar donde lo necesite.


10
2017-09-18 08:22





Hay problemas mínimos en la configuración de una sola partición de linux, pero tiene grandes recompensas.

Cambiar el diseño de una partición es algo difícil y arriesgado, que a menudo no se puede hacer sin largos periodos de inactividad.

Su única ventaja es que tiene alguna protección contra problemas de disco completo. Pero encontrarás estos problemas. mucho a menudo. Imagine la situación, si una de sus particiones está llena, y No puede usar el espacio en las otras particiones, incluso si están casi vacías.!

Algunos administradores de sistemas profesionales tienen una opinión totalmente diferente sobre esto. Dicen que tener múltiples particiones puede hacer que su sistema sea más confiable y debe saber antes de su partición, qué tan grandes serán sus particiones. En mi opinión, esto simplemente no se puede decir, es una desventaja terrible en la flexibilidad del sistema, y ​​su motivación real es que son simplemente Me gusta jugar con los mapas de partición.

Hay un sistema simple llamado lvm, que permite el movimiento / cambio de tamaño sobre la marcha de "particiones" (en su terminología, volúmenes). Pero en un solo servidor del departamento local, en mi humilde opinión, normalmente no es necesario.


9
2017-09-18 08:43



¿Qué tipo de administrador masoquista? gustos ¿Jugar con mapas de partición? La parte divertida es construir el kernel, ¿puedo obtener un Amén??? - bishop
¡Amén! Ahora sobre el argumento de que a los administradores les gusta jugar con particiones, me gustaría contrarrestar eso con el hecho de que linux tiene probablemente 100 tipos diferentes de sistemas de archivos y dependiendo de los patrones de uso, elegir el sistema de archivos correcto para una tarea en particular puede significar La diferencia entre un sistema óptimo y un sistema no funcional. Y tal vez solo necesite ese sistema de archivos en unas pocas carpetas. Ahí. - Lennart Rolland


Hay dos razones principales para la partición:

  1. Para mantener los datos estáticos lejos de los datos no estáticos
  2. Mantener los datos públicos alejados de los datos privados.

La primera razón es la más obvia: necesita aislar áreas que se llenarán con archivos de aquellos que no lo hacen, y particularmente desea proteger /, para evitar un sistema que no se puede arrancar. Por ejemplo, el directorio / var es típicamente donde se almacenarán los archivos de registro (var significa "variable") y es por esto que / var tiende a montarse en una partición separada de /.

La segunda razón anterior es menos citada (la escuché por última vez en un curso de Veritas Volume Manager hace unos 15 años) y en realidad solo es relevante para los sistemas donde muchas personas inician sesión y realizan trabajos.

Hay una especie de arte para una partición efectiva, y esta es quizás la razón por la que hay administradores de sistemas que lo llevan un poco demasiado lejos (IMO). No solo necesita conocer el sistema de archivos al revés, sino que también debe conocer el uso previsto. Personalmente, creo que es un enfoque bastante anticuado que se está volviendo cada vez menos relevante para la forma en que se usan los servidores hoy en día.

Como desarrollador de software, estoy especialmente harto de que el departamento de Operaciones construya Máquinas Virtuales con esquemas de partición irreflexivos que restringen severamente el tamaño de / tmp, / home, / var y /, independientemente del espacio total en disco disponible, pero luego no No monte opciones obvias como / usr o / opt por separado. En general, estas máquinas pondrán todo lo que quede fuera del espacio en disco que solicitó en un volumen "/ stuff" en el que inevitablemente terminará instalando y sincronizando todo, pero eso no es un consuelo. El resultado final es que a menudo pasamos más tiempo barajando los archivos y enviando correos electrónicos de advertencia que haciendo cualquier trabajo real.

No hay nada intrínsecamente "malo" en tener una sola partición. En cualquier sistema, debe supervisar de forma proactiva el uso del disco y emplear estrategias de mantenimiento razonables (por ejemplo, rotación de registros, cuotas en los directorios principales), por lo que la única pregunta real es: ¿de cuántos sistemas de archivos separados desea preocuparse?

Por eso diría: a menos que esté 100% seguro de su capacidad para particionar el sistema de manera efectiva para su caso de uso particular, no particione en absoluto.


3
2017-09-18 09:41



Exactamente. Ok, tal vez la separación de datos público-privado debería ser hecha por los permisos en el sistema de archivos y en sus servicios. - peterh


En mi humilde opinión depende de usted por completo. Primero considere algunas cosas, aunque por completo es algo relativo.

  • ¿Se administrará este sistema con frecuencia?
  • ¿Este sistema será utilizado por uno o más usuarios?
  • ¿Servirá este sistema como escritorio o servidor, o ambos?

Dado que uno puede considerar (casi) cualquier directorio, un punto de montaje, también debe considerar qué contiene datos un tanto crecientes y qué contiene datos crecientes.

Se sorprendería de lo poco que se necesita para ejecutar un sistema Linux (datos algo crecientes) y cuánto se consume con los datos crecientes (generalmente / var / opt / home / srv)

También depende de cómo defina el uso para este sistema que describe los requisitos de partición. El uso para LVM incluido.

Un sistema de escritorio típico requeriría unos 20 GB para instalar un montón de software, y todo el resto asignado a un hogar / dedicado funcionará bien en ese momento. LVM causa una sobrecarga menor en su sistema y, en este caso particular, no es tan beneficioso. Aunque las opiniones pueden diferir.

En un servidor es menos probable que el software instalado sea tan dinámico como para un sistema de escritorio. También es más sabio tener puntos de montaje reales para los componentes típicos del sistema de archivos como / tmp / var / usr / home / opt / srv. Se recomienda el uso de LVM aquí para no decir obligatorio.

Esto ofrece una gran modularidad de su sistema, también permite hacer cosas tontas, como clonar esa partición en una máquina virtual, por ejemplo. O creando una copia de seguridad a nivel de bloque usando dd.

Basado en alguna experiencia, aquí hay algunas notas. También considere tener múltiples puntos de montaje que permitan un mayor control, asignar un dispositivo de disco rápido o lento a un punto de montaje puede hacer una gran diferencia y puede aumentar considerablemente la eficiencia de los costos.

Mounpoint /

  • 1 GB (si usa puntos de montaje separados para / var / usr / opt / home / tmp)
  • +10 o incluso +20 GB si se usa como sistema de escritorio con un / home separado

si usa mountpoint / home

  • asigne todo el espacio libre si se usa, / home ne

si usa mountpoint / opt

si usa mountpoint / usr

  • Este es un problema difícil y depende enormemente de la base de software instalada.

si usa mountpoint / var

  • Este es un problema difícil y depende enormemente de la base de software instalada.
  • por ejemplo, las bases de datos escriben sus datos aquí en sistemas basados ​​en Debian, si no todos Linux
  • tener un / var / tmp separado no es irrazonable

si usa mountpoint / tmp

  • considera que tmpfs existe y asigna / tmp a RAM
  • Considere algunas aplicaciones pueden escribir una gran cantidad de datos aquí

2
2017-09-18 14:18





Antes de nada, tengo que preguntarme por qué está publicando esta pregunta aquí, ¡siendo un biólogo que está discutiendo con un administrador del sistema aparentemente competente con respecto a los puntos más finos de la partición del disco duro! (No se ofenda, solo me pregunto por qué no confía en su administrador de sistemas).

Así que, algunas observaciones:

  • 1.3 TB ya no es un disco grande. 2 TB es un tamaño de unidad SATA más o menos estándar en el mundo de los escritorios en estos días.

  • es poco probable que una instalación de cualquier Linux Distro requiera más de 100 GB. Ciertamente, el tamaño para / (root) y (swap) se debe determinar fácilmente como números de límite superior mediante un sobredimensionamiento generoso de ellos (para root) o mediante pautas de configuración del sistema (swap).

  • el punto de montaje para / home debe estar apuntando a algo apagado en su servidor RAID de 40TB. No hay necesidad de que los datos, los directorios personales de los usuarios, estén en cualquier lugar de ese dispositivo raíz. Ponerlos en el servidor RAID probablemente le dé una mejor protección de todos modos. Y, lo más probable es que sea una instalación NAS fácilmente expandible, mientras que el pequeño RAID integrado en la caja del servidor probablemente no lo sea.

  • probablemente debería colocar su software especial en una partición separada (punto de montaje para / usr / local / bin, etc.) para que pueda mantener esto en todas las actualizaciones del sistema operativo y borrados de particiones de raíz. De lo contrario, tendrá la posibilidad de que tendrá que volver a instalar sus aplicaciones de software "especiales" después de una actualización / reparación / lo que sea del sistema operativo.

  • Si quiere preocuparse por la administración de su sistema, me gustaría hacer una pregunta diferente: ¿cuál es el proceso de recuperación después de que el edificio se incendie y los servidores y las cajas de RAID se destruyan? A menos que los datos que le interesan queden totalmente en su cabeza, esta es una pregunta que todos los usuarios deben hacerles a sus amigos de IT / sysadmin. La estrategia debe incluir preguntas como "cómo replicaremos el hardware que necesitamos" y "cuánto tiempo tomará antes de que podamos volver a estar en funcionamiento". Alguna discusión sobre la virtualización de sus servidores podría ayudar a resolver problemas relacionados con las dependencias de hardware y hacer que las cosas vuelvan a funcionar sin la necesidad de reconfigurar su sistema operativo (ya que podría configurarse para ejecutarse en un entorno de dispositivo "suave" que no cambia, incluso cuando hardware subyacente es completamente diferente)

  • de manera similar, es posible que desee preguntar cuál es la estrategia para proteger los datos del usuario contra las pérdidas de datos de errores del programa y del usuario. Guardar un archivo vacío sobre el excelente borrador de su trabajo de investigación, o hacer que un usuario escriba el comando incorrecto (rm -rf * por ejemplo) causará la pérdida de datos con la misma seguridad que un terremoto o incendio u otro daño físico. Las soluciones para la recuperación de archivos individuales son un poco diferentes (o pueden serlo) de las más útiles para la recuperación de desastres al por mayor.

  • -

2
2017-09-23 13:10





Esto permite hacer una copia de seguridad, restaurar o reinstalar el sistema operativo independientemente de los datos del usuario. Esto te da libertad, independencia y seguridad.

  1. Es mucho más fácil migrar a otra distribución de Linux aún conservando la mayoría absoluta de los datos del usuario.

  2. Es fácil revertir las actualizaciones de errores aplicando la copia de seguridad de la partición del sistema operativo (se requiere un arranque dual). Esta copia de seguridad puede ser bastante antigua; puede aplicarla y actualizarla posteriormente a la versión estable a sabiendas.

  3. Es sencillo volver a la versión anterior del sistema operativo si no le gusta la "actualización importante" aplicada recientemente (se requiere un arranque dual).

Para el mayor potencial de este enfoque, también debe configurar el arranque dual (también puede ser CentOS / CentOS), para que pueda sobrescribir una partición del sistema operativo mientras ejecuta el sistema operativo desde otra. Y, seguramente, debe hacer una copia de seguridad de la partición del sistema al menos una vez unos meses.


2
2017-09-18 11:13



¿Y por qué -1? ¿Vería esperar sin conexión inalámbrica para la corrección de errores como un enfoque más profesional? Ha sido parcheado en tres semanas, por cierto. - h22
No lo sé, pero compensado. Si ves algo similar, hazlo también. - peterh


Mi respuesta corta es que incluso un escritorio nunca debe usar "una gran partición". Recientemente probé eso en contra de mi mejor criterio porque era "solo una computadora portátil" y el autoinstalador usó una sola partición, y simplemente hice clic en el botón.

Cuando fui a instalar una distro diferente, tuve que volver a particionar mis unidades porque el instalador no se va a instalar sobre una distro existente. Puede y mantendrá su / casa intacta si está en su propia partición. Entonces, terminé arrancando un gparted live-cd y encogiendo la partición, creando nuevas particiones para / home y otros, moviendo mis datos a las nuevas particiones, y luego finalmente iniciando el instalador para el nuevo sistema operativo.

Idealmente, poner / en un SSD, / home en un disco duro, / var en un disco duro, / usr podría estar en un SSD o HDD, según la frecuencia con la que planee realizar la actualización. / tmp a un disco duro. Por lo general, hago otra partición para archivos multimedia compartidos como mp3 y películas con enlaces simbólicos desde mi / home. Tenga en cuenta que / sbin es parte de la raíz, y es / bin y / root. Esa es la diferencia entre / bin y / usr / bin, es que / usr es algo que podría no estar disponible hasta que todas las unidades estén montadas, por lo que el comando mount no puede estar en / usr! Por lo general, mantengo un par de particiones adicionales para otras distribuciones de Linux, como si gparted está en mi disco duro, en caso de que estropee algo realmente malo, tengo otro sistema en vivo listo para realizar trabajos de recuperación.

Para un servidor en el que necesite mover cosas, agregar almacenamiento dinámicamente y necesita estar siempre activo, definitivamente use LVM.


1
2017-09-20 05:38