Partición del servidor Unix y diseño del sistema de archivos

Hay mucha información contradictoria sobre la partición de servidores Unix en Internet, por lo que necesito algunos consejos sobre cómo proceder.

Hasta ahora, en los servidores que utilicé en nuestro entorno de prueba, realmente no me importaba la partición y configuré un solo monolítico /más una partición de intercambio. Este esquema de partición 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 ejecutaré una pila LAMP básica (Apache, PHP y MySQL). Tendrá que manejar la carga de archivos (hasta 2 GB). El sistema tiene una matriz RAID 1 de 2 TB.

Planeo establecer:

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

¿Suena sano o estoy complicando demasiado las cosas?

Una cosa a tener en cuenta al diseñar sus particiones son los modos de falla. Por lo general, esa pregunta es de la forma: "¿Qué sucede cuando la partición x se llena?" El más querido voretaq7 sacó a relucir la situación por completo, /causando cualquier cantidad de problemas difíciles de diagnosticar. Veamos algunas situaciones más específicas.

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

¿Qué sucede en un sistema basado en RPM cuando /varestá lleno? El administrador 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 la diversión, ejecute este comando y ver lo rápido que puede hacer un archivo de gran tamaño bastante: cat /dev/zero > zerofile.

También va más allá de llenar particiones, cuando coloca ubicaciones en diferentes puntos de montaje, también puede personalizar sus opciones de montaje.

¿Qué sucede cuando /dev/no está montado con noexec? Como /devse supone que el sistema operativo suele mantener y solo contiene dispositivos, con frecuencia (y a veces todavía se usa) para ocultar programas maliciosos. Dejarlo apagado le noexecpermite iniciar binarios almacenados allí.

Por todas estas razones, y más, muchas guías de refuerzo discutirán la partición como uno de los primeros pasos a realizar. De hecho, si usted está construyendo un nuevo servidor cómo particionar el disco es casi exactamente la primera cosa que usted tiene que decidir sobre, ya menudo el más difícil de cambiar más adelante. Existe un grupo llamado Center for Internet Security 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 específico y ver los detalles que pueden decir.

Si observamos RedHat Enterprise Linux 6, el esquema de partición 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 detrás de todos estos cambios es evitar que se impacten entre sí y / o limitar lo que se puede hacer en una partición específica. Tome las opciones /tmppor ejemplo. Lo que dice es que no se pueden crear nodos de dispositivos allí, no se pueden ejecutar programas desde allí, y el bit set-uid no se puede configurar en nada. Por su propia naturaleza, /tmpcasi siempre se puede escribir en el mundo y, a menudo, es un tipo especial de sistema de archivos que solo existe en la memoria. Esto significa que un atacante podría usarlo como un punto de preparación fácil para soltar y ejecutar código malicioso, luego de fallar (o simplemente reiniciar) el sistema borrará toda la evidencia. Dado que la funcionalidad de /tmpno requiere ninguna de esas funciones, podemos desactivar fácilmente las funciones y prevenir esa situación.

Los lugares de almacenamiento de registros, /var/logy /var/log/auditestán separados para ayudar a protegerlos del agotamiento de los recursos. Además, auditado puede realizar algunas cosas especiales (generalmente 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 detallado y citar mount(8), esto es exactamente lo que son las opciones utilizadas 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 interprete caracteres ni bloquee dispositivos especiales en el sistema de archivos.

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

Desde una perspectiva de seguridad, estas son muy buenas opciones para conocer, ya que le permitirán poner protecciones en el sistema de archivos. En un entorno altamente seguro, incluso puede agregar la noexecopción /home. Hará que sea más difícil para su usuario estándar escribir scripts de shell para procesar datos, por ejemplo, analizar archivos de registro, pero también evitará que ejecuten un binario que elevará los privilegios.

Además, tenga en cuenta que el directorio de inicio predeterminado del usuario raíz es /root. Esto significa que estará en el /sistema de archivos, no en /home.

La cantidad exacta que le da a cada partición puede variar mucho según la carga de trabajo del sistema. Un servidor típico que he administrado rara vez requerirá la interacción de una persona y, como tal, la /homepartición no necesita ser muy grande. Lo mismo se aplica /varya que tiende a almacenar datos bastante efímeros que se crean y eliminan con frecuencia. Sin embargo, un servidor web generalmente usa /var/wwwcomo su patio de recreo, lo que significa que eso también debe estar en una partición separada o /var/debe 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 revisarse y ajustarse de acuerdo con el propósito del sistema y cómo funciona su entorno. También recomendaría usar LVM y no asignar todo el disco. Esto le permitirá crecer o agregar particiones fácilmente si se requieren tales cosas.

Ignorando la matriz RAID subyacente ( consulte esta pregunta para obtener más detalles sobre los niveles de la matriz RAID y cuándo desea usarlos ), concentrémonos en la pregunta central que está haciendo:
"¿Cómo debo diseñar los sistemas de archivos de mi servidor Unix?"

¿Qué hay de malo con una /partición gigante ?

Como señaló en su pregunta, muchas distribuciones de Linux (especialmente las distribuciones de "Escritorio" como Ubuntu) utilizan un diseño de sistema de archivos muy simple: /y [swap].

Este esquema tiene la ventaja de la simplicidad : es ideal para los usuarios de DOS / Windows que están acostumbrados a su PC doméstica con "el disco duro" como un gran contenedor monolítico ( C:\) en el que volcar cosas, y no tiene que preocuparse sobre quedarse sin espacio en los sistemas de archivos, solo asegúrese de mantenerse por debajo de la capacidad del disco y de que todo esté (al menos en teoría) bien.

Sin embargo, el esquema de sistema de archivos único tiene varias desventajas: la desventaja más frecuentemente citada es que los sistemas Unix tienden a reaccionar muy mal cuando el sistema de archivos raíz se llena (hasta el punto de negarse a arrancar), y si todo está escribiendo en /(la raíz) Un programa o usuario descarriado puede eliminar todo el sistema.
Un solo sistema de archivos grande también es propenso a ser una pérdida total en caso de un bloqueo del sistema y la posterior corrupción del sistema de archivos.

Los problemas anteriores, más un fuerte sentido de organización, es la razón por la cual los servidores Unix suelen tener múltiples sistemas de archivos.

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

Espero que esté convencido de que tener múltiples sistemas de archivos tiene sentido. La pregunta ahora es ¿cómo divide el sistema en fragmentos lógicos y cómo decide cuánto espacio ocupa cada uno?
La respuesta es que usted sabe y comprende lo que su sistema operativo va a poner dónde. El punto de partida para esa comprensión es la hierpágina del manual. La mayoría de los sistemas Unix vienen con ( man hierde un sistema Linux y man hierde un sistema BSD ), y eso además de su conocimiento local de lo que va a hacer el código que está instalando lo guiará en la creación de un diseño de partición sensata.

Aquí voy a describir un esquema general de particionamiento, pero este esquema siempre debe modificarse 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.

La práctica de dividir el sistema de archivos de esa manera es de los días en que no había una incursión de software, y las unidades de disco eran pequeñas, por lo que tenía que usar varias de ellas, y por lo tanto, la única forma de hacerlo era dividir el sistema de archivos y poner diferentes directorios en diferentes unidades. La otra razón histórica para ello fue que podía desmontar fácilmente una partición y hacer dumpuna copia de seguridad, lo que no podía hacer con la raíz. Esta herramienta ha caído en desgracia en estos días y en su lugar se puede usar en una instantánea LVM incluso en la raíz.

Hay pocas o ninguna razón para hacer esto más. La única razón que queda para hacer esto es si desea, por ejemplo, evitar que se /tmpllene todo el disco.

Esta razón es en gran medida irrelevante en estos días porque se ha dejado de lado a los usuarios con acceso general a shell, y en estos días los servidores ejecutan servicios dedicados, como servidores web o de correo. Dado que no tiene usuarios aleatorios capaces de ejecutar comandos arbitrarios, generalmente no necesita preocuparse de que intenten llenar su sistema de archivos (e incluso cuando lo hizo, tenía cuotas de disco para detener eso).

En cuanto a qué nivel de banda utilizar, debe recordar que el objetivo principal de la banda no es proteger los datos (para eso están las copias de seguridad), sino mantener el tiempo de actividad. Si pones /tmpun raid0, entonces tu servidor aún no funcionaría y tendrías que repararlo si falla uno de los discos. También es posible que desee utilizar raid10 en lugar de raid1 para obtener un mejor rendimiento también.

Una muy buena razón para NO romper el sistema de archivos es que si las asignaciones son incorrectas, puede terminar con una parte del sistema de archivos llena a pesar de que hay mucho espacio libre en otro lugar. Corregir esto puede ser difícil, a menos que use LVM y deje algo de espacio sin asignar.

Mucha de la información de particionamiento se generó cuando el espacio en disco era escaso. Como resultado, verá particiones relativamente pequeñas para varios casos. Los tamaños de partición requeridos varían según el uso del servidor. El más variable tienden a ser /tmp, /var, home, /opt, y /srv. /usrtiende a ser de un tamaño razonable y estable. El espacio para /puede incluir cualquiera o todas las otras particiones y sus requisitos de espacio. El dimensionamiento depende realmente de lo que esté haciendo el sistema.

Aumentaría swapy seguiría /tmpadelante tmpfs. Usted /tmpva a utilizar a continuación de intercambio como un almacén de respaldo, pero la memoria uso como disponible. El tamaño de su /tmpapariencia es extremadamente alto, pero manejará la carga abortada que no se limpia.

Consideraría mover los archivos MySQL a /srv. Este es un nivel relativamente nuevo en la jerarquía del disco.

Si no conoce sus requisitos finales, considere usar LVM y expandir sus particiones como relleno.

Dependiendo de su arquitectura, es posible que no quiera usar / tmp ya que se borra después de cada reinicio. Si su sitio trata con el procesamiento eventual de cargas, puede ser una idea cambiar esto a otra ubicación (a través de php.ini); en el que puedes convertirlo en cualquier punto de montaje.

Como se sugirió anteriormente, se recomienda usar LVM e incrementar según sea necesario.

También recomiendo una partición dedicada para datos MySQL (aún puede montarla en / var / lib / mysql).