Sin categoría

Introducción

Introducción

31 de julio de 2009
Por Pierre Vignéras

Abstracto:

Como probablemente sepa, Linux admite varios sistemas de archivos como Ext2, Ext3, Ext4, XFS, Reiserfs, JFS, entre otros, entre otros. Pocos usuarios realmente consideran esta parte de un sistema, seleccionando opciones predeterminadas del instalador de su distribución. En este artículo, daré algunas razones para una mejor consideración del sistema de archivos y de su diseño. Sugeriré un proceso de arriba para el diseño de un diseño "inteligente" que permanece lo más estable posible con el tiempo para un uso de computadora determinado.

Introducción

La primera pregunta que puede hacer es por qué hay tantos sistemas de archivos y cuáles son sus diferencias si hay alguna? Para hacerlo corto (ver Wikipedia para más detalles):

  • Ext2: es el Linux FS, quiero decir, el que fue diseñado específicamente para Linux (influenciado por Ext y Berkeley FFS). Pro: rápido; Contras: No Journalized (Long FSCK).
  • Ext3: la extensión natural Ext2. Pro: compatible con ext2, periodizado; Contras: más lento que Ext2, como muchos competidores, obsoletos hoy.
  • ext4: la última extensión de la familia ext. Pro: compatibilidad ascendente con ext3, gran tamaño; buena actuación de lectura; Contras: un poco demasiado reciente para saber?
  • JFS: IBM AIX FS portado a Linux. Pro: maduro, rápido, ligero y confiable, gran tamaño; Contras: todavía desarrollado?
  • XFS: SGI IRIX FS portado a Linux. Pro: Muy maduro y confiable, buen rendimiento promedio, gran tamaño, muchas herramientas (como un desfragmentador); Contras: ninguno que yo sepa.
  • Reiserfs: alternativa al sistema de archivos ext2/3 en Linux. Pro: rápido para archivos pequeños; Contras: todavía desarrollado?

Hay otros sistemas de archivos, en particular los nuevos como BTRFS, ZFS y NILFS2 que también pueden sonar muy interesantes. Trataremos con ellos más adelante en este artículo.

Entonces, ahora la pregunta es: ¿Qué sistema de archivos es el más adecuado para su situación particular?? La respuesta no es simple. Pero si realmente no lo sabe, si tiene alguna duda, recomendaría XFS por varias razones:

  1. funciona muy bien en general y particularmente en lectura/escritura concurrente (ver Benchmark);
  2. Es muy maduro y, por lo tanto, ha sido probado y ajustado ampliamente;
  3. Sobre todo, viene con excelentes características como XFS_FSR, un desfragmentador fácil de usar (solo haga un LN -SF $ (que XFS_FSR) /etc /Cron.diariamente/defrag y olvídalo).

El único problema que veo con XFS es que no puedes reducir un XFS FS. Puede cultivar una partición XFS incluso cuando se monta y en uso activo (crecimiento caliente), pero no puede reducir su tamaño. Por lo tanto, si tiene algunas necesidades de sistema reductor de archivos, elija otro sistema de archivos, como Ext2/3/4 o Reiserfs (hasta donde sé, no puede reducir los sistemas de archivos Ext3 ni Reiserfs de todos modos) de todos modos). Otra opción es mantener XFS y comenzar siempre con un tamaño de partición pequeño (ya que siempre puede cultivar en caliente después).

Si tiene una computadora de perfil de bajo (o servidor de archivos) y si realmente necesita su CPU para algo más que tratar con operaciones de entrada/salida, sugeriría JFS.

Si tiene muchos directorios o archivos pequeños, Reiserfs puede ser una opción.

Si necesita rendimiento a toda costa, sugeriría Ext2.

Honestamente, no veo ninguna razón para elegir Ext3/4 (rendimiento? en realidad?).

Eso es para la elección del sistema de archivos. Pero entonces, la otra pregunta es qué diseño debo usar? Dos particiones? Tres? Dedicado /hogar /? Solo lectura /? Separado /tmp?

Obviamente, no hay una sola respuesta a esta pregunta. Deben considerarse muchos factores para tomar una buena decisión. Primero definiré esos factores:

Complejidad: cuán complejo es el diseño a nivel mundial;
Flexibilidad: Qué fácil es cambiar el diseño;
Actuación: Qué tan rápido el diseño permite que el sistema se ejecute.

Encontrar el diseño perfecto es una compensación entre esos factores.

Diseño predeterminado

A menudo, un usuario final de escritorio con pocos conocimientos de Linux seguirá la configuración predeterminada de su distribución donde (generalmente) solo se hacen dos o tres particiones para Linux, con el sistema de archivos raíz ' /', /Boot y el intercambio. Las ventajas de dicha configuración son la simplicidad. El principal problema es que este diseño no es flexible ni rectante.

Falta de flexibilidad

La falta de flexibilidad es obvia por muchas razones. Primero, si el usuario final quiere otro diseño (por ejemplo, quiere cambiar el tamaño del sistema de archivos raíz, o quiere usar un sistema de archivos separado /TMP), tendrá que reiniciar el sistema y usar un software de partición (De un Livecd, por ejemplo). Tendrá que ocuparse de sus datos ya que la re-participación es una operación de fuerza bruta que el sistema operativo no tiene conocimiento de.

Además, si el usuario final quiere agregar algo de almacenamiento (por ejemplo, un nuevo disco duro), terminará modificando el diseño del sistema (/etc/fstab) y después de algunos, su sistema dependerá del diseño de almacenamiento subyacente (Número y ubicación de discos duros, particiones, etc.).

Por cierto, tener particiones separadas para sus datos (/hogar, pero también todos los audio, video, base de datos, ...) hace mucho más fácil el cambio del sistema (por ejemplo, de una distribución de Linux a otro). También hace que el intercambio de datos entre los sistemas operativos (BSD, OpenSolaris, Linux e incluso Windows) sea más fácil y seguro. Pero esta es otra historia.

Una buena opción es usar la gestión lógica de volumen (LVM). LVM resuelve el problema de flexibilidad de una manera muy agradable, como veremos. La buena noticia es que la mayoría de las distribuciones modernas admiten LVM y algunas lo usan de forma predeterminada. LVM agrega una capa de abstracción además del hardware que elimina las dependencias difíciles entre el sistema operativo (/etc/fstab) y los dispositivos de almacenamiento subyacentes (/dev/hda,/dev/sda y otros). Esto significa que puede cambiar el diseño del almacenamiento, agregando y eliminando los discos duros, sin perturbar su sistema. El principal problema de LVM, hasta donde yo sé, es que puede tener problemas para leer un volumen LVM de otros sistemas operativos.

Falta de rendimiento.

Cualquiera que sea el sistema de archivos (Ext2/3/4, XFS, Reiserfs, JFS), no es perfecto para todo tipo de datos y patrones de uso (también conocido como carga de trabajo). Por ejemplo, se sabe que XFS es bueno en el manejo de archivos grandes como archivos de video. Por otro lado, se sabe que Reiserfs es eficiente en el manejo de archivos pequeños (como los archivos de configuración en su directorio de inicio o en /etc.). Por lo tanto, tener un sistema de archivos para todo tipo de datos y uso definitivamente no es óptimo. El único buen punto con este diseño es que el núcleo no necesita admitir muchos sistemas de archivos diferentes, por lo tanto, reduce la cantidad de memoria que el kernel usa al mínimo (esto también es cierto con los módulos). Pero a menos que nos centremos en los sistemas integrados, considero que este argumento es irrelevante con las computadoras de hoy.

Elegir lo correcto: un enfoque de arriba

A menudo, cuando se diseña un sistema, generalmente se realiza en un enfoque de abajo a arriba: el hardware se compra de acuerdo con los criterios que no están relacionados con su uso. A partir de entonces, un diseño del sistema de archivos se define de acuerdo con ese hardware: "Tengo un disco, puedo dividirlo de esta manera, esta partición aparecerá allí, esa otra allí, y así sucesivamente".

Propongo el enfoque inverso. Definimos lo que queremos en un alto nivel. Luego viajamos capas de arriba a abajo, hasta hardware real - dispositivos de almacenamiento en nuestro caso - como se muestra en la Figura 1. Esta ilustración es solo un ejemplo de lo que se puede hacer. Hay muchas opciones como veremos. Las siguientes secciones explicarán cómo podemos llegar a un diseño tan global.

Figura 1: Un ejemplo de diseño de archivo del sistema. Observe que dos particiones permanecen gratuitas (SDB3 y SDC3). Se pueden usar para /arranque, para el intercambio o ambos. No "copiar/pegar" este diseño. No está optimizado para su carga de trabajo. Es solo un ejemplo.

Comprar el hardware correcto

Antes de instalar un nuevo sistema, se debe considerar el uso del objetivo. Primero desde un punto de vista de hardware. ¿Es un sistema integrado, un escritorio, un servidor, una computadora múltiple de uso múltiple (con TV/audio/video/openOffice/web/chat/p2p, ...)?

Como ejemplo, siempre recomiendo a los usuarios finales con necesidades simples de escritorio (web, correo, chat, pocos medios) para comprar un procesador de bajo costo (el más barato), un montón de RAM (el máximo) y al menos dos discos duros.

Hoy en día, incluso el procesador más barato está lo suficientemente lejos para el surf en la web y la observación de películas. Mucho RAM ofrece un buen caché (Linux usa memoria libre para el almacenamiento en caché, reduciendo la cantidad de entrada/salida costosa a los dispositivos de almacenamiento). Por cierto, la compra de la cantidad máxima de RAM que su placa base puede admitir es una inversión por dos razones:

  1. Las aplicaciones tienden a requerir más y más memoria; Por lo tanto, tener la cantidad máxima de memoria ya le impide agregar memoria más adelante durante un tiempo;
  2. La tecnología cambia tan rápido que su sistema puede no admitir la memoria disponible en 5 años. En ese momento, comprar memoria antigua probablemente será bastante costosa.

Tener dos discos duros les permite usarse en el espejo. Por lo tanto, si uno falla, el sistema continuará funcionando normalmente y tendrá tiempo para obtener un nuevo disco duro. De esta manera, su sistema permanecerá disponible y sus datos, bastante seguros (esto no es suficiente, también respalda sus datos).

Definición del patrón de uso

Al elegir hardware, y específicamente el diseño del sistema de archivos, debe considerar aplicaciones que lo usarán. Las diferentes aplicaciones tienen una carga de trabajo de entrada/salida diferente. Considere las siguientes aplicaciones: Loggers (Syslog), Readers de correo (Thunderbird, KMail), Motor de búsqueda (Beagle), Base de datos (MySQL, PostgreSQL), P2P (EMULE, Gnutella, Vuze), Shells (Bash) ... ¿puede ver su entrada su entrada? /Patrones de salida y cuánto difieren?

Por lo tanto, defino la siguiente ubicación de almacenamiento abstracto conocida como volumen lógico - LV - en la terminología LVM:

TMP.LV:
Para datos temporales como el encontrado en/tmp,/var/tmp y también en el directorio de inicio de cada usuarios $ home/tmp (tenga en cuenta que los directorios de basura como $ home/basura, $ home/.La basura también se puede asignar aquí. Consulte la especificación de basura de Freedesktop para obtener implicaciones). Otro candidato es /var /caché. La idea de este volumen lógico es que podemos ajustarlo en exceso para el rendimiento y podemos aceptar una pérdida de datos, ya que estos datos no son esenciales para el sistema (consulte el estándar de jerarquía del sistema de archivos Linux (FHS) para obtener detalles sobre esas ubicaciones).
leer.LV:
Para los datos que se leen principalmente como para la mayoría de los archivos binarios en /bin, /usr /bin, /lib, /usr /lib, archivos de configuración en /etc. y la mayoría de los archivos de configuración en cada directorio de usuario $ home /.bashrc, y así sucesivamente. Esta ubicación de almacenamiento se puede ajustar para el rendimiento de lectura. Podemos aceptar un rendimiento de escritura deficiente ya que ocurren en raras ocasiones (e.G: Al actualizar el sistema). Perder datos aquí es claramente inaceptable.
escribir.LV:
Para datos que se escriben principalmente de manera aleatoria, como datos escritos por aplicaciones P2P o bases de datos. Podemos sintonizarlo para escribir el rendimiento. Tenga en cuenta que el rendimiento de lectura no puede ser demasiado bajo: tanto P2P como aplicaciones de bases de datos se leen aleatoriamente y a menudo los datos que escriben. Podemos considerar esta ubicación como la ubicación de "todo uso": si realmente no conoce el patrón de uso de una aplicación determinada, configúrela para que use este volumen lógico. Perder datos aquí también es inaceptable.
adjuntar.LV:
para datos que se escriben principalmente de manera secuencial como para la mayoría de los archivos en/var/log y también $ home/.xsession-errores entre otros. Podemos sintonizarlo para obtener un rendimiento de la adición, que puede ser bastante diferente al rendimiento de escritura aleatoria. Allí, el rendimiento de lectura generalmente no es tan importante (a menos que tenga necesidades específicas, por supuesto). Perder datos aquí es inaceptable para usos normales (el registro proporciona información sobre los problemas. Si pierde sus registros, ¿cómo puede saber cuál fue el problema??).
mm.LV:
para archivos multimedia; Su caso es un poco especial en el sentido de que generalmente son grandes (videos) y leen secuencialmente. El ajuste para la lectura secuencial se puede hacer aquí. Los archivos multimedia se escriben una vez (por ejemplo, desde la escritura.LV donde las aplicaciones P2P escriben al MM.lv), y leí muchas veces secuencialmente.

Puede agregar/sugerir cualquier otra categoría aquí con diferentes patrones como secuencial.leer.LV, por ejemplo.

Definición de puntos de montaje

Supongamos que ya tenemos todas esas ubicaciones abstractas de almacenamiento en forma de/dev/tbd/lv donde:

  • TBD es un grupo de volumen que se definirá más adelante (ver 3.5);
  • LV es uno de los volumen lógico que acabamos de definir en la sección anterior (leer.LV, TMP.LV, ...).

Entonces suponemos que ya tenemos/dev/tbd/tmp.lv,/dev/tbd/read.lv,/dev/tbd/write.lv, y así sucesivamente.

Por cierto, consideramos que cada grupo de volumen está optimizado para su patrón de uso (se ha encontrado una compensación entre rendimiento y flexibilidad).

Datos temporales: TMP.lv

Nos gustaría tener/tmp,/var/tmp, y cualquier $ home/tmp todo asignado a/dev/tbd/tmp.lv.

Lo que sugiero es lo siguiente:

  1. montura/dev/tbd/tmp.LV a A /.TMP Directorio oculto a nivel de raíz; En /etc /fstab, tendrá algo así (por supuesto, ya que el grupo de volumen es desconocido, esto no funcionará; el punto es explicar el proceso aquí.) 
    # Reemplace automático por el sistema de archivos real si desea # Reemplazar los valores predeterminados 0 2 por sus propias necesidades (Man fstab)/dev/tbd/tmp.LV /.TMP Auto Predeterminados 0 2
  2. vincular otras ubicaciones al directorio en /.TMP. Por ejemplo, suponga que no le importa tener directorios separados para /tmp y /var /tmp (ver FHS para obtener implicaciones), puede crear un directorio All_tmp dentro /dev /tbd /tmp.LV y unirse a ambos /TMP y /VAR /TMP. En /etc /fstab, agregue esas líneas: 
    /.TMP /ALL_TMP /TMP NINGUNA BIND 0 0 /.TMP/ALL_TMP/VAR/TMP NINGUNO BIND 0 0

    Por supuesto, si prefiere ajustarse al FHS, no hay problema. Cree dos directorios distintos FHS_TMP y FHS_VAR_TMP en el TMP.Volumen del VI, y agregue esas líneas:

    /.TMP /FHS_TMP /TMP NINGUNO BIND 0 0 /.TMP/FHS_VAR_TMP/VAR/TMP NINGUNA BIND 0 0 0
  3. Realice un enlace simbólico para el directorio TMP de usuario a /tmp /usuario. Por ejemplo, $ home/tmp es un enlace simbólico a/tmp/$ user_name/tmp (estoy usando el entorno KDE, por lo tanto, mi $ home/tmp es un enlace simbólico a/tmp/kde- $ user, así que todas las aplicaciones KDE usa el mismo LV). Puede automatizar este proceso utilizando algunas líneas en su .Bash_profile (o incluso en/etc/skel/.Bash_profile para que cualquier usuario nuevo lo tenga). Por ejemplo: 
    Si prueba ! -e $ home/tmp -a ! -e /tmp /kde- $ user; luego mkdir /tmp /kde- $ user; ln -s/tmp/kde- $ user $ home/tmp; FI

    (Este script es bastante simple y solo funciona en el caso de que $ Home/TMP y/TMP/KDE- $ user aún no existe. Puede adaptarlo a su propia necesidad.)

Leer principalmente datos: Leer.lv

Dado que el sistema de archivos raíz contiene /etc, /bin, /usr /bin, etc., son perfectos para leer.lv. Por lo tanto, en /etc /fstab, colocaría lo siguiente:

/dev/tbd/read.LV / AUTO Predeterminados 0 1

Para los archivos de configuración en los directorios de inicio del usuario, las cosas no son tan simples como puede suponer. Uno puede intentar usar la variable de entorno XDG_CONFIG_HOME (ver Freedesktop)

Pero no recomendaría esta solución por dos razones. Primero, pocas aplicaciones realmente se ajustan hoy en día (la ubicación predeterminada es de $ hogar/.configurar cuando no se establece explícitamente). Segundo, es que si establece xdg_config_home a una lectura.subdirectorio de LV, los usuarios finales tendrán problemas para encontrar sus archivos de configuración. Por lo tanto, para ese caso, no tengo ninguna buena solución y haré directorios de inicio y todos los archivos de configuración almacenados a la escritura general.Ubicación del LV.

Datos mayormente escritos: escribir.lv

Para ese caso, reproduciré de alguna manera el patrón utilizado para TMP.lv. Ataré diferentes directorios para diferentes aplicaciones. Por ejemplo, tendré en el FSTAB algo similar a esto:

/dev/tbd/escribir.LV /.Escribe Auto Valores predeterminados 0 2 /.Write /DB /DB Ninguno Bind 0 0 /.escribir /P2P /P2P Ninguno Bind 0 0 /.escribir /hogar /inicio ninguno BIND 0 0

Por supuesto, esto suponga que se han creado directorios DB y P2P en Write.lv.

Tenga en cuenta que es posible que tenga que conocer el acceso a los derechos. Una opción es proporcionar los mismos derechos que para /tmp donde cualquiera puede escribir /leer sus propios datos. Esto se logra mediante el siguiente comando de Linux, por ejemplo: Chmod 1777 /P2P.

Principalmente Agradecer datos: agregar.lv

Ese volumen ha sido sintonizado para aplicaciones de estilo de registros como syslog (y sus variantes syslog_ng, por ejemplo), y cualquier otro registrador (java loggers, por ejemplo). El /etc /fstab debería ser similar a esto:

/dev/tbd/append.LV /.Agregar Auto Predeterminados 0 2 /.append /syslog /var /log ninguno bing 0 0 /.Agregar/ULOG/VAR/ULOG NINGUNO BIND 0 0

Nuevamente, Syslog y ULOG son directorios previamente creados en append.lv.

Datos multimedia: MM.lv

Para archivos multimedia, solo agrego la siguiente línea:

 /dev/tbd/mm.LV /mm Auto predeterminados 0 2

Inside /mm, creo fotos, audios y directorios de videos. Como usuario de escritorio, generalmente comparto mis archivos multimedia con otros miembros de la familia. Por lo tanto, los derechos de acceso deben diseñarse correctamente.

Es posible que prefiera tener volúmenes distintos para archivos de foto, audio y video. Siéntase libre de crear volúmenes lógicos en consecuencia: Fotos.LV, Audios.LV y videos.lv.

Otros

Puede agregar sus propios volúmenes lógicos de acuerdo con su necesidad. Los volúmenes lógicos son bastante libres de lidiar con. No agregan una gran sobrecarga y proporcionan mucha flexibilidad que lo ayudan a sacar al máximo su sistema, particularmente al elegir el sistema de archivos adecuado para su carga de trabajo.

Definición de sistemas de archivos para volúmenes lógicos

Ahora que nuestros puntos de montaje y nuestros volúmenes lógicos se han definido de acuerdo con los patrones de uso de nuestra aplicación, podemos elegir el sistema de archivos para cada volumen lógico. Y aquí tenemos muchas opciones como ya hemos visto. En primer lugar, tiene el sistema de archivos en sí (E.g: ext2, ext3, ext4, reiserfs, xfs, jfs, etc.). Para cada uno de ellos también tiene sus parámetros de ajuste (como el tamaño del bloque de ajuste, el número de inodos, las opciones de registro (XF), etc.). Finalmente, al montar también puede especificar diferentes opciones de acuerdo con algún patrón de uso (NOATME, DATA = redacción (ext3), barrera (XFS), etc.). La documentación del sistema de archivos debe leerse y entenderse para que pueda asignar opciones al patrón de uso correcto. Si no tiene ninguna idea sobre qué FS usar para qué propósito, aquí están mis sugerencias:

TMP.LV:
Este volumen contendrá muchos tipos de datos, escritos/lecturas por aplicaciones y usuarios, pequeños y grandes. Sin ningún patrón de uso definido (en su mayoría leído, en su mayoría escritura), usaría un sistema de archivos genérico como XFS o Ext4.
leer.LV:
Este volumen contiene el sistema de archivos raíz con muchos binarios (/bin,/usr/bin), bibliotecas (/lib,/usr/lib), muchos archivos de configuración (/etc.) ... ya que la mayoría de sus datos se leen, el archivo -Sistema puede ser el que tiene el mejor rendimiento de lectura, incluso si su rendimiento de escritura es pobre. XFS o Ext4 son opciones aquí.
escribir.LV:
Esto es bastante difícil ya que esta ubicación es la "ajustar todoUbicación, debe manejar tanto leer y escribir correctamente. De nuevo, XFS o Ext4 también son opciones.
adjuntar.LV:
Allí, podemos elegir un sistema de archivos estructurado de registro puro, como el nuevo NILFS2 admitido por Linux desde 2.6.30 que debería proporcionar un rendimiento de escritura muy bueno (pero tenga cuidado con sus limitaciones (especialmente, no hay soporte para atime, atributos extendidos y ACL).
mm.LV:
contiene archivos de audio/video que pueden ser bastante grandes. Esta es una elección perfecta para XFS. Tenga en cuenta que en IRIX, XFS admite una sección en tiempo real para aplicaciones multimedia. Esto no es compatible (todavía?) bajo Linux hasta donde yo sé.
Puede jugar con los parámetros de ajuste XFS (ver Man XFS), pero requiere un buen conocimiento sobre su patrón de uso y sobre las partes internas XFS.

En ese alto nivel, también puede decidir si necesita soporte de cifrado o compresión. Esto puede ayudar a elegir el sistema de archivos. Por ejemplo, para mm.LV, la compresión es inútil (ya que los datos multimedia ya están comprimidos), mientras que puede sonar útil para /hogar. Considere también si necesita cifrado.

En ese paso hemos elegido los sistemas de archivos para todos nuestros volúmenes lógicos. El tiempo ahora es ir a la siguiente capa y definir nuestros grupos de volumen.

Definición del grupo de volumen (VG)

El siguiente paso es definir grupos de volumen. En ese nivel, definiremos nuestras necesidades en términos de ajuste de rendimiento y tolerancia a fallas. Propongo definir VGS de acuerdo con el siguiente esquema: [R | S].[R | W].[n] donde:

'r' - significa aleatorio;
's' - significa secuencial;
'R' - representa la lectura;
'W' - representa la escritura;
'norte' - es un entero positivo, cero inclusive.

Letras determinan el tipo de optimización para el volumen nombrado. El número proporciona una representación abstracta del nivel de tolerancia a fallas. Por ejemplo:

  • riñonal.Riñonal.0 significa optimizado para una lectura aleatoria con un nivel de tolerancia a fallas de 0: la pérdida de datos ocurre tan pronto como falla un dispositivo de almacenamiento (dijo lo contrario, el sistema es tolerante a la falla del dispositivo de almacenamiento de 0).
  • s.W.2 significa optimizado para la escritura secuencial con un nivel de tolerancia a fallas de 2: la pérdida de datos ocurre tan pronto como tres dispositivos de almacenamiento fallan (dijo lo contrario, el sistema es tolerante a 2 dispositivos de almacenamiento, falla).

Luego tenemos que asignar cada volumen lógico a un grupo de volumen dado. Sugiero lo siguiente:

TMP.LV:
se puede asignar a un RS.RW.0 grupo de volumen o un RS.RW.1 dependiendo de sus requisitos relacionados con la tolerancia a fallas. Obviamente, si su deseo es que su sistema permanezca en línea en línea 24/24 horas, 365 días/año, la segunda opción definitivamente debe considerarse. Desafortunadamente, la tolerancia a fallas tiene un costo tanto en términos de espacio de almacenamiento como de rendimiento. Por lo tanto, no debe esperar el mismo nivel de rendimiento de un RS.RW.0 VG y un RS.RW.1 VG con el mismo número de dispositivos de almacenamiento. Pero si puede pagar los precios, hay soluciones para Rs de bastante rendimiento.RW.1 e incluso RS.RW.2, 3 y más! Más sobre eso en el siguiente nivel hacia abajo.
leer.LV:
puede ser mapeado a una R.Riñonal.1 VG (aumentar el número tolerante de fallas si lo necesita);
escribir.LV:
puede ser mapeado a una R.W.1 vg (lo mismo);
adjuntar.LV:
se puede asignar a un S.W.1 vg;
mm.LV:
se puede asignar a un S.Riñonal.1 VG.

Por supuesto, tenemos una declaración 'mayo' y no una declaración 'debe', ya que depende de la cantidad de dispositivos de almacenamiento que puede poner en la ecuación. Definir VG es bastante difícil ya que no siempre puede abstraer completamente el hardware subyacente. Pero creo que definir sus requisitos primero puede ayudar a definir el diseño de su sistema de almacenamiento a nivel mundial.

Veremos en el siguiente nivel, cómo implementar esos grupos de volumen.

Definición de volúmenes físicos (PV)

Ese nivel es donde realmente implementa los requisitos de un grupo de volumen determinado (definido utilizando la notación RS.RW.n descrito anteriormente). Con suerte, no hay, hasta donde yo sé, muchas maneras de implementar un requisito de VG. Puede usar algunas de las funciones de LVM (reflejo, eliminación), RAID de software (con Linux MD) o Raid de hardware. La elección depende de sus necesidades y de su hardware. Sin embargo, no recomendaría una redada de hardware (hoy en día) para una computadora de escritorio o incluso un pequeño servidor de archivos, por dos razones:

  • Muy a menudo (la mayoría de las veces en realidad), lo que se llama Hardware Raid, en realidad es una redada de software: tiene un chipset en su placa base que presenta un controlador RAID de bajo costo que requiere algún software (controladores) para hacer el trabajo real. Definitivamente, Linux Raid (MD) es mucho mejor tanto en términos de rendimiento (creo) como en términos de flexibilidad (seguro).
  • A menos que tenga una CPU muy antigua (clase Pentium II), Soft Raid no es tan costoso (esto no es tan cierto para RAID5 en realidad, pero para RAID0, RAID1 y RAID10, es cierto).

Entonces, si no tiene ninguna idea sobre cómo implementar una especificación dada usando RAID, consulte la documentación de RAID.

Sin embargo, algunas pistas:

  • cualquier cosa con un .0 se puede asignar a RAID0, que es la combinación de incursión más desempeñada (pero si un dispositivo de almacenamiento falla, pierde todo).
  • s.Riñonal.1, R.Riñonal.1 y sr.Riñonal.1 se puede asignar en orden de preferencias a RAID10 (se requieren un mínimo de 4 dispositivos de almacenamiento (SD), RAID5 (requerido 3 SD), RAID1 (2 SD).
  • s.W.1, se puede mapear en orden de preferencias a RAID10, RAID1 y RAID5.
  • riñonal.W.1, se puede asignar en orden de preferencias a RAID10 y RAID1 (RAID5 tiene un rendimiento muy pobre en la escritura aleatoria).
  • sr.Riñonal.2 se puede asignar a RAID10 (de alguna manera) y a RAID6.

Cuando mapee el espacio de almacenamiento a un volumen físico dado, no conecte dos espacios de almacenamiento del mismo dispositivo de almacenamiento (i.mi. particiones). Perderá ambas ventajas de rendimiento y tolerancia a fallas! Por ejemplo, hacer /dev /sda1 y /dev /sda2 parte del mismo volumen físico RAID1 es bastante inútil.

Finalmente, si no está seguro de qué elegir entre LVM y MDADM, sugeriría que MDADM tiene que es un poco más flexible (es compatible (Similar a RAID1)).

Incluso si no se requiere estrictamente, si usa MDADM, probablemente terminará con un mapeo uno a uno entre VG y PVS. Dijo lo contrario, puede asignar muchos PV a un VG. Pero esto es un poco inútil en mi humilde opinión. MADM proporciona toda la flexibilidad requerida en la asignación de particiones/dispositivos de almacenamiento en implementaciones de VG.

Definición de particiones

Finalmente, es posible que desee hacer algunas particiones con sus diferentes dispositivos de almacenamiento para cumplir con sus requisitos fotovoltaicos (por ejemplo, RAID5 requiere al menos 3 espacios de almacenamiento diferentes). Tenga en cuenta que en la gran mayoría de los casos, sus particiones deberán ser del mismo tamaño.

Si puede, sugeriría usar dispositivos de almacenamiento directamente (o hacer solo una solo partición con un disco). Pero puede ser difícil si tiene breve en dispositivos de almacenamiento. Además, si tiene dispositivos de almacenamiento de diferentes tamaños, tendrá que dividir uno de ellos al menos.

Es posible que deba encontrar una compensación entre sus requisitos fotovoltaicos y sus dispositivos de almacenamiento disponibles. Por ejemplo, si solo tiene dos discos duros, definitivamente no puede implementar un RAID5 PV. Tendrá que confiar solo en una implementación RAID1.

Tenga en cuenta que si realmente sigue el proceso de fondo superior descrito en este documento (y si puede pagar el precio de sus requisitos, por supuesto), no hay una compensación real con la que tratar! 😉

/bota

No mencionamos en nuestro estudio el sistema de archivos /arranque donde se almacena el cargador de arranque. Algunos preferirían tener solo un solo / donde / bota es solo un subdirectorio. Otros prefieren separar / y / arrancar. En nuestro caso, donde usamos LVM y MDADM, sugeriría la siguiente idea:

  1. /Boot es un sistema de archivos separado porque un cargador de arranque puede tener problemas con los volúmenes LVM;
  2. /Boot es un sistema de archivos EXT2 o EXT3 ya que esos formatos están bien admitidos por cualquier cargador de arranque;
  3. /El tamaño del arranque sería de 100 MB de tamaño porque los initRAMF pueden ser bastante pesados ​​y puede tener varios núcleos con sus propios initramfs;
  4. /Boot no es un volumen LVM;
  5. /Boot es un volumen RAID1 (creado usando MDADM). Esto asegura que al menos dos dispositivos de almacenamiento tengan exactamente el mismo contenido compuesto por núcleo, initramfs, sistema.mapa y otras cosas requeridas para el arranque;
  6. El volumen /Boot Raid1 está hecho de dos particiones primarias que son la primera partición en sus respectivos discos. Esto evita que algunas biogs antiguas no encuentren el cargador de arranque debido a las antiguas limitaciones de 1 GB.
  7. El cargador de arranque se ha instalado en ambas particiones (discos) para que el sistema pueda arrancar desde ambos discos.
  8. El BIOS se ha configurado correctamente para arrancar desde cualquier disco.

Intercambio

Swap también es una cosa que no discutimos hasta ahora. Tienes muchas opciones aquí:

actuación:
Si necesita rendimiento a toda costa, definitivamente, cree una partición en cada uno de sus dispositivos de almacenamiento y úselo como una partición de intercambio. El núcleo equilibrará la entrada/salida a cada partición de acuerdo con su propia necesidad, lo que lleva al mejor rendimiento. Tenga en cuenta que puede jugar con prioridad para dar algunas preferencias a los discos duros dados (por ejemplo, una unidad rápida puede recibir una prioridad más alta).
Tolerancia a fallos:
Si necesita tolerancia a fallas, definitivamente, considere la creación de un volumen de intercambio LVM a partir de una R.RW.1 grupo de volumen (implementado por un RAID1 o RAID10 PV, por ejemplo).
flexibilidad:
Si necesita cambiar el tamaño de su intercambio por algunas razones, sugiero usar uno o muchos volúmenes de intercambio de LVM.

Sistemas de archivos futuros y/o exóticos

Uso de LVM es bastante fácil configurar un nuevo volumen lógico creado a partir de algún grupo de volumen (dependiendo de lo que desee probar y su hardware) y formatearlo en algunos sistemas de archivos. LVM es muy flexible a este respecto. Siéntase libre de crear y eliminar los sistemas de archivos a voluntad.

Pero de alguna manera, los futuros sistemas de archivos como ZFS, BTRFS y NILFS2 no encajan perfectamente con LVM. La razón es que LVM conduce a una clara separación entre las necesidades de aplicación/usuario e implementaciones de estas necesidades, como hemos visto. Por otro lado, ZFS y BTRFS integran tanto las necesidades como la implementación en una sola cosa. Por ejemplo, tanto ZFS como BTRFS admite el nivel de redacción directamente. Lo bueno es que alivia la creación del diseño del sistema de archivos. Lo malo es que viola algunas formas en que la separación de la estrategia de preocupación.

Por lo tanto, puede terminar con un XFS/LV/VG/MD1/SD A, B 1 y BTRFS/SD A, B 2 dentro del mismo sistema. No recomendaría tal diseño y sugeriría usar ZFS o BTRFS para todo o no en absoluto.

Otro sistema de archivos que puede ser interesante es NILFS2. Estos sistemas de archivos estructurados de registro tendrán un rendimiento de escritura muy bueno (pero tal vez un rendimiento de lectura deficiente). Por lo tanto, dicho sistema de archivos puede ser un muy buen candidato para el volumen lógico de agregar o en cualquier volumen lógico creado a partir de un RS.W.n grupo de volumen.

Unidades USB

Si desea usar una o varias unidades USB en su diseño, considere lo siguiente:

  1. El ancho de banda del bus USB V2 es de 480 Mbits/s (60 Mbytes/s) que es suficiente para la gran mayoría de las aplicaciones de escritorio (excepto quizás video HD);
  2. Hasta donde sé, no encontrará ningún dispositivo USB que pueda cumplir con el ancho de banda USB V2.

Por lo tanto, puede ser interesante usar varias unidades USB (o incluso STAK) para que sean parte de un sistema RAID, especialmente un sistema RAID1. Con tal diseño, puede sacar una unidad USB de una matriz RAID1 y usarla (en modo de solo lectura) en otro lugar. Luego, lo vuelves a meter en su matriz RAID1 original, y con un comando mágico mDadm como:

MDADM /dev /md0 -add /dev /sda1

La matriz se reconstruirá automáticamente y volverá a su estado original. Sin embargo, no recomendaría hacer ninguna otra matriz de incursiones en USB Drive. Para RAID0, es obvio: si elimina una unidad USB, pierde todos sus datos! Para RAID5, tener un disco USB y, por lo tanto, la capacidad de plug-sty no ofrece ninguna ventaja: la unidad USB que ha sacado es inútil en un modo RAID5! (mismo comentario para RAID10).

Discos de estado sólido

Finalmente, se pueden considerar nuevas unidades SSD al definir volúmenes físicos. Sus propiedades deben tenerse en cuenta:

  • Tienen una latencia muy baja (tanto leen como escriben);
  • Tienen muy buen rendimiento de lectura aleatoria y la fragmentación no tiene impacto en su rendimiento (rendimiento determinista);
  • El número de escrituras es limitado.

Por lo tanto, las unidades SSD son adecuadas para implementar grupos de volumen RSR#n. Como ejemplo, mm.LV y Leer.Los volúmenes del VI se pueden almacenar en SSD ya que los datos generalmente se escriben una vez y se leen muchas veces. Este patrón de uso es perfecto para SSD.

Conclusión

En el proceso de diseño de un diseño de sistema de archivos, el enfoque de fondo superior comienza con necesidades de alto nivel. Este método tiene la ventaja de que puede confiar en requisitos realizados previamente para sistemas similares. Solo la implementación cambiará. Por ejemplo, si diseña un sistema de escritorio: puede terminar con un diseño dado (como el de la Figura 1). Si instala otro sistema de escritorio con diferentes dispositivos de almacenamiento, puede confiar en sus primeros requisitos. Solo tienes que adaptar las capas inferiores: PVS y particiones. Por lo tanto, el gran trabajo, el patrón de uso o la carga de trabajo, el análisis se puede hacer solo una vez por sistema, naturalmente.

En la sección siguiente y final, daré algunos ejemplos de diseño, sintonizados aproximadamente para algunos usos de computadora bien conocidos.

Ejemplos de diseño

Cualquier uso, 1 disco.

Esto (ver el diseño superior de Figura 2) es una situación bastante extraña en mi opinión. Como ya se dijo, considero que cualquier computadora debe ser dimensionada de acuerdo con algún patrón de uso. Y tener solo un disco adjunto a su sistema significa que acepta una falla completa de alguna manera. Pero sé que la gran mayoría de las computadoras hoy, especialmente las computadoras portátiles y netbooks, se venden (y se diseñan) con un solo disco. Por lo tanto, propongo el siguiente diseño que se centra en la flexibilidad y el rendimiento (tanto como sea posible):

flexibilidad:
Como el diseño le permite cambiar el tamaño de los volúmenes a voluntad;
actuación:
Como puede elegir un sistema de archivos (ext2/3, XFS, etc.) de acuerdo con los patrones de acceso a datos.
Figura 2: Un diseño con un disco (arriba) y otro para el uso de escritorio con dos discos (abajo).

Uso de escritorio, alta disponibilidad, 2 discos.

Aquí (ver el diseño inferior de la Figura 2), nuestra preocupación es la alta disponibilidad. Dado que solo tenemos dos discos, solo se puede usar RAID1. Esta configuración proporciona:

flexibilidad:
Como el diseño le permite cambiar el tamaño de los volúmenes a voluntad;
actuación:
Como puede elegir un sistema de archivos (ext2/3, XFS, etc.) de acuerdo con los patrones de acceso a datos y desde una R.Riñonal.1 VG puede ser proporcionado por un RAID1 PV para un buen rendimiento de lectura aleatoria (en promedio). Tenga en cuenta que ambos s.Riñonal.n y rs.W.n no se puede proporcionar solo 2 discos para ningún valor de n.
Alta disponibilidad:
Si un disco falla, el sistema continuará trabajando en un modo degradado.

Nota: La región de intercambio debe estar en el PV RAID1 para garantizar una alta disponibilidad.

Uso de escritorio, alto rendimiento, 2 discos

Aquí (ver el diseño superior de la Figura 3), nuestra preocupación es el alto rendimiento. Sin embargo, tenga en cuenta que todavía considero inaceptable perder algunos datos. Este diseño proporciona lo siguiente:

flexibilidad:
Como el diseño le permite cambiar el tamaño de los volúmenes a voluntad;
actuación:
Como puede elegir un sistema de archivos (ext2/3, xfs, etc.) de acuerdo con los patrones de acceso a datos, y desde que ambos R.Riñonal.1 y RS.RW.0 se puede proporcionar con 2 discos gracias a RAID1 y RAID0.
Disponibilidad media:
Si un disco falla, los datos importantes seguirán siendo accesibles, pero el sistema no podrá funcionar correctamente a menos que se tomen algunas acciones para mapear /.TMP e intercambio a algún otro LV asignado a un VG seguro.
Nota: La región de intercambio está hecha de RS.RW.0 VG implementado por RAID0 PV para garantizar la flexibilidad (cambiar el tamaño de las regiones de intercambio es indolora). Otra opción es usar directamente una cuarta partición de ambos discos.

Figura 3: Arriba: Diseño para el uso de escritorio de alto rendimiento con dos discos. Abajo: Diseño para el servidor de archivos con cuatro discos.

Servidor de archivos, 4 discos.

Aquí (ver el diseño inferior de la Figura 3), nuestra preocupación es tanto de alto rendimiento como alta disponibilidad. Este diseño proporciona lo siguiente:

flexibilidad:
Como el diseño le permite cambiar el tamaño de los volúmenes a voluntad;
actuación:
Como puede elegir un sistema de archivos (ext2/3, XFS, etc.) de acuerdo con los patrones de acceso a datos, y dado que ambos RS.Riñonal.1 y RS.RW.1 se puede proporcionar con 4 discos gracias a RAID5 y RAID10.
Alta disponibilidad:
Si un disco falla, cualquier dato seguirá siendo accesible y el sistema podrá funcionar correctamente.

Nota 1:

Es posible que hayamos usado RAID10 para todo el sistema, ya que proporciona una muy buena implementación de RS.RW.1 VG (y de alguna manera también Rs.RW.2). Desafortunadamente, esto viene con un costo: se requieren 4 dispositivos de almacenamiento (aquí particiones), cada una de la misma capacidad s (digamos S = 500 gigabytes). Pero el volumen físico RAID10 no proporciona una capacidad de 4*s (2 terabytes) como puede esperar. Solo proporciona la mitad, 2*s (1 terabytes). Los otros 2*s (1 terabytes) se usan para alta disponibilidad (espejo). Ver documentación de RAID para más detalles. Por lo tanto, elijo usar RAID5 para implementar RS.Riñonal.1. RAID5 proporcionará 3*s de capacidad (1.5 gigabytes), el S restante (500 gigabytes) se usa para alta disponibilidad. El mm.El LV generalmente requiere una gran cantidad de espacio de almacenamiento, ya que contiene archivos multimedia.

Nota 2:

Si exporta a través de los directorios 'Home' de NFS o SMB, puede considerar su ubicación con cuidado. Si sus usuarios necesitan mucho espacio, haciendo casas en la escritura.LV (la ubicación 'Fit-All') puede ser costosa porque está respaldado por un RAID10 PV donde la mitad del espacio de almacenamiento se usa para la reflejo (y el rendimiento). Tienes dos opciones aquí:

  1. Ya sea, tiene suficiente almacenamiento o/y sus usuarios tienen altas necesidades de acceso de escritura aleatoria/secuencial, el RAID10 PV es la buena opción;
  2. O bien, no tiene suficiente almacenamiento o/y sus usuarios no tienen altas necesidades de acceso de escritura al azar/secuencial, el RAID5 PV es la buena opción.

Preguntas, comentarios y sugerencias

Si tiene alguna pregunta, comentario y/o sugerencia en este documento, no dude en ponerse en contacto conmigo en la siguiente dirección: [email protected].

Derechos de autor

Este documento tiene licencia bajo un Creative Commons Attribution-compartir 2.0 Licencia de Francia.

Descargo de responsabilidad

La información contenida en este documento es solo para fines de información general. Pierre Vignéras proporciona la información y, aunque me esfuerzo por mantener la información actualizada y correcta, no hago representaciones ni garantías de ningún tipo, expresas o implícitas, sobre la integridad, precisión, confiabilidad, idoneidad o disponibilidad con respecto a la documento o el información, productos, servicios o gráficos relacionados contenidos en el documento para cualquier propósito.

Cualquier confianza que ubique en dicha información, por lo tanto, es estrictamente bajo su propio riesgo. En ningún caso, seremos responsables de cualquier pérdida o daño, incluida, entre otros, pérdida o daño indirecto o consecuente, o cualquier pérdida o daño que surja de la pérdida de datos o ganancias que surgen o en relación con el uso de esto documento.

A través de este documento, puede vincular a otros documentos que no están bajo el control de Pierre Vignéras. No tengo control sobre la naturaleza, el contenido y la disponibilidad de esos sitios. La inclusión de cualquier enlace no implica necesariamente una recomendación o respalda las opiniones expresadas dentro de ellos.

Tutoriales de Linux relacionados:

  • Cosas para instalar en Ubuntu 20.04
  • Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
  • Archivos de configuración de Linux: los 30 principales más importantes
  • Cosas que hacer después de instalar Ubuntu 22.04 Jellyfish de Jammy ..
  • Cómo verificar una salud del disco duro desde la línea de comandos ..
  • Mint 20: Mejor que Ubuntu y Microsoft Windows?
  • Descarga de Linux
  • Ubuntu 20.04 Guía
  • Manjaro Linux Windows 10 Dual Boot
  • Una introducción a la automatización, herramientas y técnicas de Linux