28 votos

Particionamiento del servidor Unix y disposición del sistema de archivos

Hay mucha información contradictoria sobre el particionamiento de servidores Unix en Internet, así que necesito algún consejo sobre cómo proceder.

Hasta ahora, en los servidores que en nuestro entorno de prueba no me importaba realmente el particionamiento y configuré un único monolítico / más una partición de intercambio. Este esquema de particionamiento no parece una buena idea para nuestros servidores de producción. He encontrado un buen punto de partida aquí pero parece muy vago en los detalles.


Básicamente tengo un servidor en el que voy a ejecutar una pila básica LAMP (Apache, PHP y MySQL). Tendrá que manejar la carga de archivos (hasta 2GB). El sistema tiene una matriz RAID 1 de 2TB.

Tengo la intención de establecer :

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

¿Te parece sensato, o estoy complicando demasiado las cosas?

1 votos

¿Cuál es su objetivo final? ¿Qué quiere conseguir exactamente?

9 votos

Sea como sea que decidas dividirlo, yo sugeriría usar LVM para definir tus particiones y luego asignar el espacio de forma conservadora, dejando algo de espacio en el disco sin asignar. Luego, cuando decidas que necesitas más espacio en alguna parte, puedes ampliar el LV y el sistema de archivos.

33voto

Scott Pack Puntos 11452

Una cosa que hay que tener en cuenta a la hora de disponer las particiones son los modos de fallo. Normalmente esa pregunta es del tipo "¿Qué pasa cuando la partición x se llena?" El queridísimo voretaq7 planteó la situación con un lleno / causando cualquier número de problemas difíciles de diagnosticar. Veamos algunas situaciones más específicas.

¿Qué ocurre si la partición que almacena los registros está llena? Se pierden datos de auditoría/informes y a veces es utilizado por los atacantes para ocultar su actividad. En algunos casos, su sistema no autenticará a los nuevos usuarios si no puede registrar su evento de inicio de sesión.

¿Qué sucede en un sistema basado en RPM cuando /var ¿está lleno? El gestor de paquetes no instalará ni actualizará los paquetes y, dependiendo de su configuración, puede fallar silenciosamente.

Llenar una partición es fácil, especialmente cuando un usuario es capaz de escribir en ella. Para divertirse, ejecute este comando y vea lo rápido que puede hacer un archivo bastante grande: cat /dev/zero > zerofile .

Va más allá de rellenar particiones también, cuando colocas ubicaciones en diferentes puntos de montaje también puedes personalizar sus opciones de montaje.

¿Qué sucede cuando /dev/ no está montado con noexec ? Desde /dev normalmente se asume que es mantenido por el SO y que sólo contiene dispositivos fue frecuentemente (y a veces todavía lo es) utilizado para ocultar programas maliciosos. Dejando fuera noexec permite lanzar los binarios almacenados allí.

Por todas estas razones, y más, muchas guías de endurecimiento hablarán de la partición como uno de los primeros pasos a realizar. De hecho, si estás construyendo un nuevo servidor, la forma de particionar el disco es casi exactamente la primero cosa que tienen para decidir, y a menudo la más difícil de cambiar posteriormente. Existe un grupo llamado Centro de Seguridad de Internet que produce montones de guías de configuración fáciles de leer. Es probable que pueda encontrar una guía para su Sistema operativo y ver los detalles que puedan decir.

Si nos fijamos en RedHat Enterprise Linux 6, el esquema de particionamiento recomendado es este:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

El principio que subyace a todos estos cambios es el de evitar que se afecten mutuamente y/o limitar lo que se puede hacer en una partición específica. Tomemos las opciones de /tmp por ejemplo. Lo que dice es que no se pueden crear nodos de dispositivo allí, no se pueden ejecutar programas desde allí, y el bit set-uid no se puede establecer en nada. Por su propia naturaleza, /tmp casi siempre es escribible en el mundo y suele ser un tipo especial de sistema de archivos que sólo existe en la memoria. Esto significa que un atacante podría utilizarlo como un punto de partida fácil para soltar y ejecutar código malicioso, y luego estrellar (o simplemente reiniciar) el sistema borrará toda la evidencia. Dado que la funcionalidad de /tmp no requiere ninguna de esas funciones, podemos desactivarlas fácilmente y evitar esa situación.

Los lugares de almacenamiento de registros, /var/log y /var/log/audit se cortan para ayudar a evitar el agotamiento de los recursos en el buffer. Además, auditd puede realizar algunas cosas especiales (típicamente en entornos de mayor seguridad) cuando su almacenamiento de registros comienza a llenarse. Al colocarlo en su partición, esta detección de recursos funciona mejor.

Para ser más verborreico, y citar mount(8) , esto es exactamente lo que son las opciones usadas anteriormente:

noexec No permita la ejecución directa de ningún binario en el sistema de archivos montado. (Hasta hace poco era posible ejecutar binarios de todos modos usando un comando como /lib/ld*.so /mnt/binary. Este truco falla desde Linux 2.4.25 / 2.6.0).

nodev No interpretar los dispositivos especiales de caracteres o bloques en el sistema de archivos.

nosuid No permita que los bits set-user-identifier o set-group-identifier tengan efecto. (Esto parece seguro, pero en realidad es bastante inseguro si tiene instalado suidperl(1)).

Desde el punto de vista de la seguridad, estas opciones son muy buenas, ya que te permitirán poner protecciones en el propio sistema de archivos. En un entorno altamente seguro puedes incluso añadir el noexec opción de /home . Hará más difícil que su usuario estándar escriba Shell Shell para procesar datos, por ejemplo, analizando archivos de registro, pero también evitará que ejecute un binario que eleve los privilegios.

Además, hay que tener en cuenta que el directorio principal por defecto del usuario root es /root . Esto significa que estará en el / sistema de archivos, no en /home .

La cantidad exacta que se da a cada partición puede variar mucho en función de la carga de trabajo de los sistemas. Un servidor típico que he administrado rara vez requerirá la interacción de la persona y, como tal, el /home La partición no tiene por qué ser muy grande. Lo mismo ocurre con /var ya que suele almacenar datos más bien efímeros que se crean y borran con frecuencia. Sin embargo, un servidor web suele utilizar /var/www como su patio de recreo, lo que significa que o bien eso tiene que estar en una partición separada también o /var/ necesita hacerse grande.

En el pasado he recomendado lo siguiente como líneas de base.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Estos deben ser revisados y ajustados en función de la finalidad del sistema y del funcionamiento de su entorno. También recomendaría usar LVM y no asignar todo el disco. Esto le permitirá crecer fácilmente, o añadir, particiones si tales cosas son necesarias.

1 votos

El noexec observación es importante en general -- Se considera una buena práctica montar /tmp con el noexec para evitar que usuarios malintencionados carguen rootkits a través de explotaciones de seguridad del navegador. Del mismo modo, /home a menudo se monta nosuid ya que no hay razón para que los binarios setuid estén allí. Re: /dev y noexec en muchos sistemas modernos (aunque no en todos) /dev es a menudo un devfs y no permite a los usuarios crear/almacenar archivos normales (en FreeBSD devuelve " Operation not supported ", en Ubuntu el udev sistema de archivos montado en /dev le permite crear archivos regulares).

2 votos

@voretaq7: Sí, usando /tmp como plataforma de salto es muy divertido, ya que siempre está ahí y casi nunca se bloquea.

0 votos

Gracias por estos consejos. Comprobaré que noexec mejora la seguridad.

12voto

voretaq7 Puntos 63415

Ignorando la matriz RAID subyacente ( Consulte esta pregunta para obtener más detalles sobre los niveles de las matrices RAID y cuándo desea utilizarlos ), concentrémonos en la pregunta central que usted plantea:
"¿Cómo debo distribuir los sistemas de archivos de mi servidor Unix?"


¿Qué hay de malo en un gigante / ¿partición?

Como ha señalado en su pregunta, muchas distribuciones de Linux (especialmente las de "escritorio", como Ubuntu) utilizan una disposición muy simple del sistema de archivos: / y [swap] .

Este esquema tiene la ventaja de simplicidad -- es genial para los usuarios de DOS/Windows que están acostumbrados a su PC doméstico con "el disco duro" como un gran contenedor monolítico ( C:\ ) en el que vuelcas cosas, y no tienes que preocuparte por quedarte sin espacio en los sistemas de archivos: sólo tienes que asegurarte de estar por debajo de la capacidad del disco y todo estará (al menos en teoría) bien.

Sin embargo, el esquema de sistema de archivos único tiene varias desventajas: la más citada es que los sistemas Unix tienden a reaccionar muy mal cuando el sistema de archivos root se llena (hasta el punto de negarse a arrancar), y si todo está escribiendo en / (root) un programa o usuario díscolo puede hacer caer todo el sistema.
Un único sistema de archivos de gran tamaño también es propenso a ser una pérdida total en caso de caída del sistema y posterior corrupción del sistema de archivos.

Las cuestiones anteriores, además de un fuerte sentido de la organización, es la razón por la que los servidores Unix suelen tener múltiples sistemas de archivos.


¿Cómo se divide el sistema de archivos de Unix?

Así que espero que estés convencido de que tener varios sistemas de archivos tiene sentido. La cuestión ahora es cómo dividir el sistema en trozos lógicos, y cómo decidir cuánto espacio recibe cada uno.
La respuesta es que conozcas y entiendas lo que tu sistema operativo va a poner en cada lugar. El punto de partida para esa comprensión es el hier página de manual. La mayoría de los sistemas Unix vienen con ( man hier desde un sistema linux y man hier de un sistema BSD ), y eso más su conocimiento local de lo que el código usted va a instalar le guiará en la creación de una disposición de partición sana.

Voy a describir un esquema de partición general aquí, pero este esquema siempre debe ser modificado para satisfacer sus necesidades específicas.

Un esquema general de particionamiento de Unix

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Sistemas de archivos especiales

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

2 votos

Las dos razones que has enumerado son en gran medida obsoletas hoy en día. ext[234] reserva algo de espacio para el root y no permite que los programas de usuario lo utilicen todo para que el sistema no tenga problemas de falta de espacio, y todos los sistemas de archivos modernos utilizan el registro en el diario para que no se corrompan después de un fallo.

2 votos

@psusi El espacio reservado para el usuario root (normalmente entre el 5 y el 10% del tamaño del sistema de archivos) no sirve de nada si el usuario root es el que escribe los archivos que llenan el disco (como suele ocurrir con los archivos de registro). También es incorrecto asumir que sólo porque un sistema de archivos está registrado siempre estará a salvo de la corrupción - el registro en el diario aumenta la robustez, pero no Garantizar la seguridad (especialmente si te tropiezas con un error no descubierto en el código del sistema de archivos/diario y cuajas el diario - La gente de ReiserFS puede contar algunas grandes historias sobre eso desde los primeros días de ese sistema de archivos).

2 votos

Tener una /usr o /var no ayuda si / se corrompe. Del mismo modo, tener un / no ayuda ( mucho ) si /home se corrompe. En cualquier caso, acabas teniendo que restaurar desde una copia de seguridad. Por no mencionar que estos fallos son uno entre un millón, a menos que estés ejecutando un fs nuevo/inestable.

4voto

psusi Puntos 1837

La práctica de dividir el sistema de archivos de esta manera viene de la época en la que no existía el software raid, y las unidades de disco eran pequeñas, por lo que había que utilizar varias, y por lo tanto, la única manera de hacerlo era dividir el sistema de archivos y poner diferentes directorios en diferentes unidades. La otra razón histórica era para poder desmontar fácilmente una partición y dump para hacer una copia de seguridad, lo que no se podía hacer con root. Esta herramienta ha caído en gran parte en desgracia en estos días y en su lugar se puede utilizar en una instantánea LVM incluso en root.

Ya no hay casi ninguna razón para hacerlo. La única razón que queda para hacerlo es si se quiere, por ejemplo, evitar /tmp de llenar todo el disco.

Esta razón es en gran medida irrelevante hoy en día porque proporcionar a los usuarios acceso general a Shell se ha quedado en el camino, y en estos días los servidores ejecutan servicios dedicados, tales como servidores web o de correo. Como no hay usuarios aleatorios que puedan ejecutar comandos arbitrarios, generalmente no hay que preocuparse de que intenten llenar el sistema de archivos ( e incluso cuando lo hacían, tenían cuotas de disco para evitarlo ).

En cuanto a qué nivel de raid utilizar, hay que recordar que el objetivo principal del raid no es proteger los datos (para eso están las copias de seguridad), sino mantener el tiempo de actividad. Si pones /tmp en un raid0, entonces tu servidor seguiría cayendo y tendrías que ir a repararlo si uno de los discos falla. También es posible que desee utilizar raid10 en lugar de raid1 para que usted obtenga un mejor rendimiento también.

Una muy buena razón para NO dividir el sistema de archivos es que si se equivocan en las asignaciones, se puede terminar con parte del sistema de archivos lleno a pesar de que haya mucho espacio libre en otras partes. Corregir esto puede ser difícil, a menos que utilices LVM y dejes algún espacio sin asignar.

4 votos

Hay muchas razones para seguir dividiendo un sistema de archivos Unix de la manera tradicional. Si no hubiera ninguna razón para hacerlo, ya habríamos dejado de hacerlo - los administradores de sistemas no son QUE apegado a las tradiciones arcanas :)

1 votos

@voretaq7, entonces nombra algunas. Si no puedes, entonces asumir ciegamente que debe haberlos es una tontería.

1 votos

A los que votan en contra les correspondería aportar un argumento contrario en lugar de repetir ciegamente la sabiduría convencional.

3voto

BillThor Puntos 15761

Gran parte de la información de las particiones se generó cuando el espacio en disco era escaso. Como resultado, verá particiones relativamente pequeñas para un número de casos. Los tamaños de las particiones requeridas varían dependiendo del uso del servidor. Los más variables suelen ser /tmp , /var , home , /opt y /srv . /usr tiende a ser de un tamaño razonable y estable. El espacio para / puede incluir alguna o todas las demás particiones y sus necesidades de espacio. El tamaño depende realmente de lo que está haciendo el sistema.

Aumentaría swap y montar /tmp en tmpfs . Usted /tmp utilizará entonces swap como almacén de respaldo, pero utilizará la memoria disponible. El tamaño de su /tmp parece extremadamente alta, pero se encargará de la carga abortada que no se limpie.

Yo consideraría mover los archivos de MySQL a /srv . Este es un nivel relativamente nuevo en la jerarquía de los discos.

Si no conoce sus necesidades finales, considere usar LVM y ampliar sus particiones a medida que se llenan.

0 votos

Es bueno tener "suficiente" swap, pero si tienes demasiado, nunca lo usarás (porque para el momento en que estás intercambiando tanto, el rendimiento del sistema es demasiado doloroso). Yo diría que los 4G propuestos en la pregunta son probablemente "suficientes" para una pila LAMP -- si estás usando 4G de swap (y realmente paginando esos datos dentro y fuera) probablemente también estás en el teléfono siendo gritado porque el sitio web es lento :)

1 votos

@voretaq7 No importa el tamaño del swap si lo usas para programas activos. Usarlo para tmpfs donde los archivos grandes se escriben en el disco pero los más pequeños permanecen residentes en la memoria es un uso razonable de la swap. Se ahorra escribir cada archivo en el disco cuando la intención es ponerlo en otro lugar. Sugerí aumentar el espacio de swap porque parecía un gran /tmp puede requerir espacio.

0 votos

¿Por qué no utilizar un archivo normal para el intercambio? ¿No han sido tan rápidos como una partición de intercambio dedicada durante mucho tiempo?

2voto

thinice Puntos 3805

Dependiendo de su arquitectura, es posible que no quiera utilizar /tmp, ya que se borra después de cada reinicio. Si su sitio se ocupa de procesar eventualmente las subidas, cambiar esto a otra ubicación (a través de php.ini) puede ser una idea; en la que puede hacer cualquier punto de montaje.

Como se ha sugerido anteriormente, es muy recomendable utilizar LVM e incrementar según sea necesario.

También recomendaría encarecidamente una partición dedicada para los datos de MySQL (puedes seguir montándola en /var/lib/mysql).

0 votos

Generalmente es una buena idea asumir que los archivos en /tmp puede no estar allí más tarde - le ahorra sorpresas desagradables más tarde :-)

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: