Pregunta Diseño HW / SW: 2 Petabyte de almacenamiento.


Renuncia Sí, te estoy pidiendo que diseñes un sistema para mí :)

Tengo la tarea de diseñar un sistema para almacenar aproximadamente 10 TB / día con un tiempo de retención de 180 días.

Mi primer enfoque sería ir con GlusterFS y usar una configuración de HW como esta:

Nodo único en el sistema:

Necesitaría 9 nodos para obtener un almacenamiento de red (sin replicación o incursión en discos locales) que pueda contener los datos.

Pros:

  • Puedo empezar con un solo servidor sin estantes
  • Crece agregando estantes a un solo servidor (o agregue servidores, solo póngalos a la vista de la escala agregando primero nodos o agregando primero estantes o alguna combinación de ambos)
  • escalas "infinitamente" (para ciertas definiciones de "infinito")

Contras:

  • En general: en realidad no tengo idea de cómo verificar si esta será una configuración viable una vez que alcance la etapa final de expansión (1.8 PB estimado)

No tengo ninguna dirección preferida real, solo algo de experiencia con GlusterFS donde tengo un sistema de 4 TB (distribuido, replicado, 4 nodos) que ya usa GlusterFS.

Estoy bastante seguro de que no hay mucha diferencia si esta configuración ejecuta Hadoop / Gluster / Netapp / EMC / Hitachi / EveryoneElse pero el caso de uso es (tambor):

ls -ltr | grep 'something' | xargs grep somethingelse

Sí, eso da miedo. Traté de convencer a las personas para que realmente ejecuten trabajos analíticos reales sobre esos datos, pero parece que eso no sucederá. (Está bien, no es tan malo, pero esa gente usará una sesión simple de ssh en algún sistema de "análisis" para ir a algún directorio manualmente, buscar recursivamente en algunos archivos y luego determinar si los datos están bien o no, lo que suena aún peor ahora yo lo escribi)

Estoy abierto a cualquier idea, tengo gente que ejecuta "gran almacenamiento" dentro de nuestra empresa (un sistema de respaldo tiene 2PB por ejemplo) y me encantaría ir con lo que sea que ya tenga. Pero también tengo que probar que están haciendo lo correcto (por favor, no preguntes sobre esto, es algo político, confiaría mis datos al equipo de almacenamiento, no tengo idea de por qué tengo que duplicar el trabajo)

Pensar en el problema de cómo ejecutar realmente el análisis en los datos está explícitamente fuera de alcance.

Hubo innumerables reuniones y mencioné todo, desde Splunk hasta los trabajos de análisis desarrollados en casa (con y / o sin un Sistema de Mapa / Reducción). No hay interés en eso. Toda la gente se preocupa por:

  • 10 TB / día
  • Mantener los datos 180 días.
  • Haz que esté altamente disponible (aún no se ha definido por completo, pero sí algo como 99.9, 99.99 ...)

5
2018-02-23 22:25


origen


Si entiendo esto bien, ¿básicamente va a estar analizando (¿registro?) Archivos en busca de "error"? Sé que esto no te ayuda, pero hay una razón por la que Splunk es un billón de dólares para un conjunto de datos de este tamaño. - MDMarra
No tengo idea de lo que van a analizar. Pero sugerí que deberían desarrollarlos con los requisitos adecuados ... también aclaró el caso de uso ... - serverhorror
Tengo curiosidad por la industria ... ¿Tiene alguna idea de los datos? Si se trata de archivos de texto / planos, ¿es compresible? En finanzas, he tratado con datos de tick que generalmente están en formato binario, por lo que no había optimizaciones a ese nivel. Ya que estás hablando de grep, ¿qué tan compresibles son los datos? - ewwhite
También: el análisis de registro adecuado desafortunadamente no parece ser interesante para las personas que definen los requisitos. Es "Almacene 10 TB de datos, mantenga los datos 180 días, final de la historia" - serverhorror
@ewwhite: ya gzipped. Tenemos un sistema de "spooling" de 4TB enfrente del que hace la compresión. A partir de ahora, 10 TB / día son los datos comprimidos que se almacenarán. Se trata de 1:20 (comprimido: crudo). - serverhorror


Respuestas:


Bueno, no mencionaste el presupuesto ... Así que compra esto ahora. Los datos a esa escala probablemente deberían dejarse en manos de un equipo con experiencia en ese ámbito. Es bueno tener apoyo y alguien a quien gritar :)

http://www.racktopsystems.com/products/brickstor-superscalar/

http://www.racktopsystems.com/products/brickstor-superscalar/tech-specs/

4 x Storage Heads BrickStor Foundation Units
10 x BrickStor Bricks (36 x 3.5″ Bay JBOD)
2 x 16-port SAS switch
1 x pullout rackmount KVM
1 x 48U Rack
1 x 10Gb Network Switch (24 x 10Gb non-Blocking)
NexentaStor Plug-ins:VMDC, WORM, HA-cluster or Simple-HA
Onsite installation 5-days
24/7/365 day email and phone support
Onsite Support

Dado que la aplicación que describe realmente no parece estar en el ámbito del almacenamiento en clúster (dado el caso de uso), use ZFS. Obtendrá el infinito escalabilidad Tendrás la oportunidad de descargar parte de la compresión en el sistema de almacenamiento y podrás contarle a todos tus amigos al respecto :)

Más que eso, el almacenamiento en caché L2ARC (utilizando SSD) mantendrá los datos calientes disponibles para su análisis a la velocidad de SSD.

Edición: Otra solución basada en ZFS - http://www.aberdeeninc.com/abcatg/petarack.htm


Además, Red Hat se encuentra ahora en la industria del almacenamiento escalable.

Ver: http://www.redhat.com/products/storage/storage-software/


5
2018-02-23 22:52



Eso parece un sistema realmente limpio. Y el precio parece correcto también ... - Mark Henderson♦
Me gusta la idea de cualquier cosa comercializada como "$ 1.4 millones para el primero y $ 1.1 millones para cada adicional". > sonríe < - Evan Anderson
Parecen bastante confiados. ¿Es esta una mala recomendación? :) - ewwhite
Parte de las cosas de RedHat a las que te refieres es GlusterFS. Y sí, el presupuesto no es el bloqueador en este caso. Respecto al sistema distribuido. También con 360 discos de 2 TB cada uno, no voy a almacenar los 1.8 Petabytes, por lo que necesito 2 tiendas, que se distribuyen en mi libro. - serverhorror
¿Y qué decidiste hacer? - ewwhite


Como MDMarra menciona que necesita Splunk para esto, soy un gran usuario y fanático, para volúmenes muy similares a los que discute y, de inmediato, le ahorrará tener que comprar casi todo ese almacenamiento y reducir toda la complejidad. Un servidor de tamaño decente (quizás 150-200TB máx.) Hará el trabajo si se usa con Splunk, la indexación sobre la marcha es perfecta para este tipo de cosas y sus capacidades de búsqueda superan con creces cualquier cosa que usted administre. No es gratis, por supuesto, pero no consideraría nada más.


2
2018-02-23 23:42



Estoy de acuerdo en que la solución "real" sería algo así como splunk, pero cualquier cosa que no se pueda montar de alguna manera es peor que la capacidad de realizar una búsqueda significativa de sus datos. Ya hice la sugerencia y la dirección de indexar los datos para obtener un acceso estructurado desafortunadamente no es una opción. Odio decir eso, pero pensar en cómo obtener información de la montaña de datos está más allá del alcance de esto. Lea: Pensar en el problema real no es algo que las personas con los requisitos deseen que yo haga. - serverhorror
Wow, eso apesta, literalmente te están robando la mejor opción. La indexación de Splunk solo hace que valga la pena el esfuerzo. Para ser honesto, si solo quieren que tengas un sistema de archivos de 2 PB, lo harás generalmente de la manera correcta, aunque es una pena que hagas esto ahora, ya que hay un próximo modelo de HP SL que REALMENTE te ayudará. Esto pero no sale hasta el verano. Considere los estantes para unidades HP MDS 600 de 70 ranuras sobre la D2612. Me encantan las 'D', pero se debe considerar las 600. Pueden ser más lo suyo. Ah, y usa 10GigE para los enlaces de tus nodos glusteros. - Chopper3