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

Vamos a ejecutar CentOS 7 en nuestro nuevo servidor. Tenemos 6 unidades de 300 GB en raid6 interno al servidor. (El almacenamiento es en gran parte externo en forma de caja de incursión de 40 TB). El volumen interno llega a aproximadamente 1.3 TB si está formateado como un solo volumen. Nuestro administrador de sistemas piensa que es una muy mala idea instalar el sistema operativo en una gran partición de 1.3TB.

Soy biólogo Constantemente instalamos nuevo software para ejecutar y probar, la mayoría de los cuales aterriza en / usr / local. Sin embargo, debido a que tenemos alrededor de 12 biólogos no informáticos que usan el sistema, también recolectamos mucha basura en el hogar. Nuestro último servidor tenía una partición de 200GB para /, y después de 2.5 años estaba 90% lleno. ¡No quiero que eso vuelva a suceder, pero tampoco quiero ir en contra de los consejos de expertos!

¿Cómo podemos utilizar 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?

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

• para separar el sistema operativo de sus datos de usuario y aplicación . Hasta el lanzamiento de RHEL 7 no había una ruta de actualización compatible y una actualización de la versión principal requeriría una reinstalación y luego tener, por ejemplo, /homey otros datos (de aplicaciones) en particiones separadas (o volúmenes LVM) le permite preservar fácilmente los datos del usuario y datos de la aplicación y borrar las particiones del sistema operativo.

• Los usuarios no pueden iniciar sesión correctamente y su sistema comienza a fallar de manera interesante cuando se queda completamente sin espacio en disco. Las particiones múltiples le permiten asignar espacio en 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.), lo que mitiga el riesgo operativo de usuarios y / o aplicaciones con mal comportamiento.

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

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

• Arranque Es posible que necesite una /bootpartición separada . Históricamente para abordar problemas de BIOS con el arranque más allá del límite de 1024 cilindros, hoy en día es un requisito más frecuente para admitir volúmenes cifrados, para admitir ciertos controladores RAID, HBA que no admiten el inicio desde SAN o sistemas de archivos no admitidos de inmediato por el instalador, etc.

• Ajuste Puede que necesite diferentes opciones de ajuste o incluso sistemas de archivos completamente diferentes.

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

Por lo general, recomiendo particionar su volumen principal como un gran volumen físico de Linux LVM grande y luego crear volúmenes lógicos que se ajusten a sus necesidades actuales y para el resto del espacio en disco, déjelo 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 hacer en un sistema en vivo), o crear otros adicionales también.

La reducción de los volúmenes LVM es trivial, pero a menudo la reducción de los sistemas de archivos en ellos no es muy compatible y probablemente debería evitarse.

El concepto de usar múltiples particiones es que una completa en el lugar equivocado no hará que todo el sistema funcione inesperadamente.

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, evitar que el sistema escriba nuevos datos en / tmp. Si hay otro proceso que quisiera escribir en / tmp, probablemente saldría con un error, causando un comportamiento inesperado.

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

Le recomendaría que verifique en su servidor anterior qué carpetas tienden a agrandarse. Puede hacerlo en la línea de comando con

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

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

El principal problema con tener una única 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 esto /homedebido 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 crear puntos de montaje separados para /var, /tmpy /homesea capaz de iniciar sesión como root al menos para reparar el sistema cuando una de las otras particiones es llenado.

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

Pero puede usar lvm (administrador de volumen lógico). Use 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, realice un monitoreo, que ya sabe, cuando su sistema comience a llenarse y expanda los discos que necesita. lvresize y resize2fs son herramientas en línea y puede hacer la expansión sin reiniciar el servidor. Sin embargo, no puede reducir los discos, por lo que debe comenzar razonablemente pequeño y aumentar donde lo necesite.

Hay problemas mínimos en torno a la configuración de partición grande de Linux, pero tiene grandes recompensas.

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

Su única ventaja es que tiene cierta protección contra problemas de disco completo. Pero encontrará estos problemas con mucha frecuencia. ¡Imagina la situación, si una de tus particiones está llena, y no puedes 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. Están diciendo 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 un inconveniente terrible en la flexibilidad del sistema, y ​​su verdadera motivación es que simplemente les gusta jugar con los mapas de partición .

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

Hay dos razones principales para la partición:

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

La primera razón es la más obvia: debe aislar las áreas que se llenarán con archivos de las que no lo hacen, y particularmente desea proteger /, para evitar un sistema que no se puede iniciar. Por ejemplo, el directorio / var es típicamente donde se almacenarán los archivos de registro (var significa "variable") y es por eso 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 en los que muchas personas inician sesión y realizan trabajos.

El particionamiento efectivo tiene algo de arte, y esta es quizás la razón por la cual hay administradores de sistemas que lo llevan 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 particularmente harto del departamento de Ops que construye 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 u / opt por separado. Estas máquinas comúnmente colocarán lo que queda del espacio en disco que solicitó en un volumen "/ stuff" en el que inevitablemente terminará instalando y simulando todo, pero eso no es un consuelo. El resultado neto es que a menudo pasamos más tiempo barajando archivos y enviando correos electrónicos de advertencia que haciendo un trabajo real.

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

Por lo tanto, 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 .

En mi humilde opinión, depende de usted por completo. Primero considere algunas cosas, aunque completamente 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 como un punto de montaje, también debe considerar lo que contiene datos cada vez mayores y lo que contiene datos crecientes.

Se sorprenderá de lo poco que requiere un sistema Linux (datos cada vez más grandes) para ejecutarse y cuánto consume el crecimiento de los datos (generalmente / var / opt / home / srv)

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

Un sistema de escritorio típico requeriría alrededor de 20 GB para instalar un montón de software, ya que todo el resto asignado a un hogar dedicado funcionará bien. LVM causa una sobrecarga menor en su sistema y en este caso particular no es de gran beneficio. 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 prudente tener puntos de montaje reales para componentes típicos del sistema de archivos como / tmp / var / usr / home / opt / srv. Se recomienda el uso de LVM aquí, por no decir obligatorio.

Esto ofrece una gran modularidad de su sistema, también permite hacer cosas tontas como clonar esa partición en una VM, por ejemplo. O crear 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 marcar una gran diferencia y puede aumentar notablemente la rentabilidad.

Mounpoint /

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

si usa mountpoint / home

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

si usa mountpoint / opt

si usa mountpoint / usr

• esto es complicado y depende enormemente de la base de software instalada

si usa mountpoint / var

• esto es complicado 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 los Linux
• tener un / var / tmp separado no es irrazonable

si usa mountpoint / tmp

• considerar tmpfs existe y asignado / tmp a RAM
• Considere que algunas aplicaciones pueden escribir muchos datos aquí

Tengo que preguntar, en primer lugar, ¿por qué incluso está publicando esta pregunta aquí, siendo un biólogo que está discutiendo con un administrador del sistema aparentemente competente sobre los puntos más delicados de la partición del disco duro! (sin ofender, solo me pregunto por qué no confías en tu administrador de sistemas).

Entonces, 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 del escritorio en estos días.

• Es poco probable que una instalación de cualquier distribución de Linux requiera más de 100 GB. Ciertamente, el tamaño para / (raíz) y (intercambio) debe determinarse fácilmente como números con límite superior al sobredimensionarlos generosamente (para raíz) o por las pautas de configuración del sistema (intercambio).

• el punto de montaje para / home debería estar apuntando a algo apagado en su servidor RAID de 40TB. No es necesario que esos datos, los directorios de inicio de los usuarios, estén en ningún lugar de ese dispositivo raíz. Ponerlos en el servidor RAID probablemente le brinde una mejor protección de todos modos. Y, lo más probable es que sea una instalación NAS fácilmente expandible, mientras que la pequeña RAID integrada 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 preservar esto en las actualizaciones del sistema operativo y los borrados de la partición raíz. De lo contrario, se enfrentará a la posibilidad de que tendrá que reinstalar sus aplicaciones de software "especiales" después de una actualización / reparación del sistema operativo / lo que sea.

• Si desea preocuparse por la administración de su sistema, le haría una pregunta diferente: ¿cuál es el proceso de recuperación de desastres después de que el edificio se incendie y los servidores y las cajas RAID se destruyan? A menos que los datos que le interesan permanezcan completamente en su cabeza, esta es una pregunta que todos los usuarios deben hacer a sus amigos de TI / administradores de sistemas. La estrategia debe incluir preguntas como "cómo replicaremos el hardware que necesitamos" y "cuánto tiempo pasará antes de que podamos volver a funcionar". Una 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,

• Del mismo modo, es posible que desee preguntar cuál es la estrategia para proteger los datos del usuario contra la pérdida de datos de errores del programa y del usuario. Guardar un archivo vacío sobre el borrador realmente bueno 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 tan seguramente como 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.

-

Esto permite realizar copias 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 que aún conserva la mayoría absoluta de los datos del usuario.

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

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

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

Mi respuesta breve es que incluso un escritorio nunca debe usar "una gran partición". Recientemente probé eso en contra de mi mejor juicio porque era "solo una computadora portátil" y el instalador automático usó una única partición, y simplemente hice clic en el botón.

Cuando fui a instalar una distribución diferente, tuve que volver a particionar mis unidades porque el instalador no se instalará en una distribución existente. Puede y mantendrá intacto su / hogar si está en su propia partición. Entonces, terminé arrancando un live-cd separado y reduciendo la partición, haciendo nuevas particiones para / home y otros, moviendo mis datos a las nuevas particiones, y finalmente arrancando en el instalador para el nuevo sistema operativo.

Idealmente, coloque / en un SSD, / home en un disco duro, / var en un disco duro, / usr podría estar en un SSD o HDD, dependiendo de la frecuencia con la que planea actualizar. / 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 root, y es / bin y / root. Esa es la diferencia entre / bin y / usr / bin, es / usr es algo que puede no estar disponible hasta que todas sus unidades estén montadas, por lo que el comando de montaje no puede estar en / usr. Por lo general, guardo un par de particiones adicionales para otras distribuciones de Linux, como la que está dividida en mi disco duro en caso de que arruine algo realmente malo, tengo otro sistema en vivo listo para hacer el trabajo de recuperación.

Para un servidor en el que es posible que necesite mover cosas, agregar almacenamiento de forma dinámica y que deba mantenerse activo todo el tiempo, ¡definitivamente use LVM!

No tiene que instalar el software en / usr / local, puede instalar todo el software en un prefijo diferente, que podría estar en / home. La mayoría del software puede hacer esto cuando lo compila desde la fuente, ejecutando p. Ej. ./configure --prefix=/home/bin

Como eres biólogo, es posible que te interese mucho software que no esté correctamente empaquetado en rpm o deb, y de todos modos tendrás que compilarlo desde la fuente.

Soy un administrador de sistemas para un sistema HPC con muchos biólogos entre nuestros usuarios, instalamos todo el software que solicitan en un / apps / filesystem, así que sé que es posible hacer esto para la mayoría del software, sin embargo, a veces podría Se muy duro. Para resolver este problema, mis colegas y yo hemos estado escribiendo en una herramienta llamada EasyBuild (código libre y abierto). Puede compilar e instalar software desde el código fuente, e instalarlo en una carpeta diferente, y crear automáticamente un archivo de módulo de entorno para usted. en realidad puede tener 2 versiones diferentes del mismo software instalado y no tener conflictos.

Eche un vistazo a nuestra lista de paquetes que podemos instalar con un solo comando, como biólogo puede reconocer muchos de ellos ;-)

Descargo de responsabilidad: soy desarrollador de EasyBuild

Creo que, en general, para un usuario principiante / introductorio * ix que tener la menor cantidad de particiones puede funcionar hasta que se aprenda más sobre la naturaleza del sistema. Sin embargo, no puede simplemente tener una parición y, en su caso, señor, por múltiples razones.

La primera y más práctica razón pública para esto es que la mayoría de los sistemas Linux requieren una partición de intercambio (generalmente debe estar entre 1-2 * su RAM) también requieren un sistema separado, arranque o particiones domésticas y en el caso de los sistemas de arranque UEFI de Linux una partición EFI (solo 500 MB).

La segunda razón, específicamente aplicable a su situación, es que tomar unidades de 6x 300GB y convertirlas en una incursión 6 no es, por decir lo menos, la disposición óptima. Aunque, la nueva tecnología, aclama a Raid 6 como un sistema universalmente mejor, el algoritmo de creación de bandas es más necesario y el espacio requerido para almacenar información (en comparación con RAID 5) es de mayor tamaño.

Sin mencionar que RAID 6 requiere una pieza adicional de hardware. Lo que debería usarse, en mi respetuosa opinión, en su caso para comprar discos más grandes para evitar fallas en el disco, tiempo de inactividad, recuperación ante desastres o costos adicionales de ayuda técnica. Entiendo que algunos, muchos tal vez, no estarán de acuerdo conmigo y quiero reafirmar que cuando los discos se hagan más grandes en los próximos dos años (ya que han bajado de precio en los últimos años) RAID6, para matrices más grandes y Las grandes corporaciones de ingresos serán una opción obvia. Sin embargo, en este caso, no sugiero el uso de RAID 6.

Sin embargo, para el segundo problema (no basado en RAID), crear una partición gigante cuando se refleje puede funcionar para usted, si desea maximizar la eficiencia, use unidades más grandes y particiones múltiples. De esa manera, si tiene una falla de doble disco, no tendrá tiempo de inactividad en ciertos puntos de montaje o poco dependiendo de / dev + / dir.

Al menos haga que su / sys (sistema, kernel, etc.) se ejecute por separado, de modo que si por alguna razón su kernel decide no arrancar, simplemente puede usar un kernel de recuperación, arranque remoto o PXE, arranque de disco, etc. su kernel y tener compañía- amplio acceso a su información mientras se lleva a cabo el proceso de recuperación d.

Es posible que su empresa no se preocupe por estos acentos mientras el sistema funcione, pero estoy tratando de explicar las razones por las cuales las personas hacen cosas. También me encantaría saber más de los demás, a favor y en contra de este argumento, y plantear otros puntos. Si no está de acuerdo, avíseme por qué. Cartel: también te enviaré algunos enlaces.

Un amor por nuestra comunidad de Linux Spencer Reiser

PD: especialmente en servidores de red o sistemas disponibles para el público en general, incluso si se cuenta con credenciales, sería realmente mejor separar sus particiones. Otros pueden ingresar más aquí, necesito más café.