Consejos para almacenar de manera eficiente más de 25 TB + millones de archivos en el sistema de archivos

Supongamos que se enfrenta a archivos de registro sin comprimir por valor de 25 TB y tiene a su disposición una serie de 20 cajas de productos básicos con una capacidad de almacenamiento gratuito colectivo de 25 TB.

¿Cómo almacenarías estos?

a) ¿Qué sistema de archivos distribuido usar?

b) ¿Qué formato / algoritmo de compresión / descompresión?

c) El tamaño del archivo de registro es de 1 MB a un máximo de 7 MB todo el texto y gran cantidad de espacios en blanco

d) El uso es a) las personas quieren los últimos archivos de registro más que los anteriores, así que qué sistema de almacenamiento en caché usar b) las personas solo leerán los archivos de registro, no los eliminarán c) la gente quiere una lista de los archivos de registro en un intervalo de fechas

e) El sistema operativo que se ejecuta en las cajas de productos básicos es Linux,

f) En cuanto a la copia de seguridad, tenemos una matriz de almacenamiento que se encarga de eso. Por lo tanto, existe la capacidad de restaurar datos de la matriz.

No quiero que accedan al sistema de archivos directamente. Qué tengo que hacer ? ¿Cómo les consigo una API basada en REST para esto?

Por favor, ahorre 2 centavos y ¿qué haría?

Ankur

No soy un sistema de archivos distribuido ninja, pero después de consolidar tantas unidades como puedo en la menor cantidad de máquinas que pueda, intentaría usar iSCSI para conectar la mayor parte de las máquinas a una máquina principal. Allí podría consolidar las cosas en un almacenamiento con tolerancia a fallos. Preferiblemente, tolerante a fallas dentro de una máquina (si se apaga una unidad) y entre máquinas (si una máquina completa está apagada).

Personalmente me gusta ZFS. En este caso, la compilación de compresión, deducción y tolerancia a fallos sería útil. Sin embargo, estoy seguro de que hay muchas otras formas de comprimir los datos al tiempo que los hace tolerantes a fallas.

Ojalá tuviera una solución de archivos distribuidos llave en mano real para recomendar, sé que esto es realmente muy difícil, pero espero que te indique la dirección correcta.

Editar: Todavía soy nuevo en ZFS y configuré iSCSI, pero recordé haber visto un video de Sun en Alemania donde mostraban la tolerancia a fallas de ZFS. Conectaron tres concentradores USB a una computadora y pusieron cuatro unidades flash en cada concentrador. Luego, para evitar que cualquier concentrador elimine el grupo de almacenamiento, crearon un volumen RAIDz que consta de una unidad flash de cada concentrador. Luego unen los cuatro volúmenes ZFS RAIDz. De esa forma, solo se utilizaron cuatro unidades flash para la paridad. Luego, por supuesto, el hub desenchufado y eso degradó cada zpool, pero todos los datos estaban disponibles. En esta configuración, se podrían perder hasta cuatro unidades, pero solo si dos unidades no estuvieran en el mismo grupo.

Si esta configuración se usara con la unidad sin formato de cada caja, eso preservaría más unidades para datos y no para paridad. Escuché que FreeNAS puede (o iba a poder) compartir unidades de una manera "cruda" a través de iSCSI, por lo que supongo que Linux puede hacer lo mismo. Como dije, todavía estoy aprendiendo, pero este método alternativo sería menos derrochador desde el punto de vista de la paridad de unidad que mi sugerencia anterior. Por supuesto, dependería del uso de ZFS, que no sé si sería aceptable. Sé que generalmente es mejor atenerse a lo que sabes si vas a tener que construir / mantener / reparar algo, a menos que sea una experiencia de aprendizaje.

Espero que esto sea mejor.

Editar: Investigué un poco y encontré el video del que hablé. La parte donde explican cómo extender la unidad flash USB a través de los hubs comienza a los 2m10s. El video es para hacer una demostración de su servidor de almacenamiento "Thumper" (X4500) y cómo distribuir los discos entre los controladores, de modo que si tiene una falla en el controlador del disco duro, sus datos seguirán siendo buenos. (Personalmente, creo que esto es solo un video de geeks divirtiéndose. Desearía tener una caja Thumper, pero a mi esposa no le gustaría que pasara una transpaleta por la casa.: D Esa es una caja grande).

Editar: recordé venir a través de un sistema de archivos distribuido llamado OpenAFS . No lo había intentado, solo había leído algo al respecto. Quizás otros sepan cómo se maneja en el mundo real.

Primero, los archivos de registro se pueden comprimir a relaciones realmente altas. Encuentro que mis archivos de registro se comprimen en una proporción de 10: 1. Si se comprimen incluso a una relación de 5: 1, eso es solo 5 GB, o el 20% de su capacidad de almacenamiento.

Dado que tiene más que suficiente almacenamiento, el algoritmo de compresión específico no es demasiado importante. Tú podrías...

• Use archivos zip si los usuarios de Windows accederán a los archivos directamente.
• Use gzip si se accede a ellos a través de Linux y la descompresión rápida es importante.
• Use bzip2 si se accederá a ellos a través de Linux y es importante tener los archivos más pequeños posibles.

La pregunta más importante es: ¿cómo va a proporcionar a sus usuarios un acceso fácil a estos archivos? Parte de esto depende de cómo estén configuradas sus máquinas.

Si puede colocar suficiente almacenamiento en una sola máquina, puede hacer algo extremadamente simple, como compartir archivos de Windows de solo lectura. Simplemente organice los archivos en subdirectorios y estará listo para comenzar.

Si no puede crear un único servidor de archivos para estos archivos, es posible que necesite un sistema de archivos distribuido. Windows tiene un Sistema de archivos distribuido (DFS) que puede satisfacer sus necesidades.

Si sus necesidades son más avanzadas, es posible que desee una aplicación web como front-end donde sus usuarios puedan navegar y descargar archivos de registro. En este caso, recomiendo usar MogileFS, que es un sistema de archivos distribuido diseñado para usarse con un servidor de aplicaciones front-end. Es muy fácil de integrar con la mayoría de los lenguajes de programación web. No puede montarlo como una unidad compartida en su computadora, pero es de primera categoría como un almacén de datos para una aplicación web.

lessfs es un sistema de archivos de deduplicación y compresión. Si bien no resolverá todo el problema, puede valer la pena mirarlo como backend.

exportar estas carpetas a través de NFS

móntelos en una sola máquina con apache ejecutándose (debajo de la raíz del documento) como un árbol

use zip para comprimirlos: buena relación de compresión, zip se puede abrir desde todos los sistemas operativos

listar archivos en Apache, por lo que le está dando a los usuarios acceso de solo lectura (no se supone que los archivos de registro sean editados, correcto)

¿Alguna vez pensaste en comprimir los archivos de registro? Luego, haga algo en la interfaz para descomprimirlos antes de entregarlos al usuario final. Tal vez una especie de script CGI.

@Ankur y @Porch. Estoy totalmente de acuerdo con la necesidad de comprimir estos registros.

@jet Creo que el esquema más simple es mejor, por lo tanto, httpd para el usuario final es casi ideal. Y el backend podría ser cualquiera.

Mi opinión: dividir los registros en 2 grupos: carpetas 'antiguas' y 'nuevas'.

Fusionarlos en la raíz del documento de httpd. Utilice una compresión fuerte para archivos antiguos (archivos xz o 7z, populares para todos los sistemas operativos) con diccionario grande y tamaños de bloque, incluso pueden ser archivos sólidos.

Use fs de compresión para los nuevos: lessfs (rw, métodos de deduplicación + compresión ligera), fusecompress 0.9.x (rw, métodos de compresión ligeros a fuertes), btrfs / zfs, squashfs (ro, métodos de compresión ligeros a fuertes, algunos dedup, use para registros recién rotados).

Incluso puede escribir registros de forma transparente en fs comprimido (fusecompress, lessfs, btrfs / zfs). Proporcione acceso R / o por httpd a los registros que se están escribiendo. Serán transparentes para los usuarios y transparentemente descomprimidos para ellos.

Advertencias sobre fusecompress: 1) use solo 0.9.x - es estable. Clonar desde aquí https://github.com/hexxellor/fusecompress

Las versiones posteriores no admiten bien lzma o pierden datos.

2) utiliza solo 1 núcleo de CPU para comprimir un archivo, por lo que puede ser lento.

Vuelva a comprimir cada registro en la carpeta 'nueva', anterior a algún tiempo (varios meses) y vaya a 'antigua'.