150 TB y creciendo, pero ¿cómo crecer?

18

Mi grupo actualmente tiene dos servidores de almacenamiento de gran tamaño, ambos NAS ejecutan Debian Linux. El primero es un servidor todo en uno de 24 discos (SATA) que tiene varios años. Tenemos dos RAIDS de hardware configurados con LVM sobre esos. El segundo servidor tiene 64 discos divididos en 4 gabinetes, cada uno de ellos RAID 6 de hardware, conectado a través de SAS externo. Usamos XFS con LVM sobre eso para crear 100 TB de almacenamiento utilizable. Todo esto funciona bastante bien, pero estamos superando estos sistemas. Después de construir dos servidores de este tipo y seguir creciendo, queremos construir algo que nos permita una mayor flexibilidad en términos de crecimiento futuro, opciones de copia de seguridad, que se comporte mejor en caso de falla del disco (comprobar que el sistema de archivos más grande puede tomar un día o más) y puede resistir en un entorno muy concurrente (piense en un pequeño grupo de computadoras). No tenemos soporte de administración del sistema,

Por lo tanto, lo que buscamos es una solución de almacenamiento de rendimiento aceptable y de costo relativamente bajo que permita un crecimiento futuro y una configuración flexible (piense en ZFS con diferentes grupos que tienen diferentes características operativas). Probablemente estemos fuera del ámbito de un único NAS. Hemos estado pensando en una combinación de ZFS (en openindiana, por ejemplo) o btrfs por servidor con glusterfs corriendo encima de eso si lo hacemos nosotros mismos. Lo que estamos comparando es simplemente morder la bala e invertir en soluciones de almacenamiento Isilon o 3Par.

Cualquier sugerencia o experiencia es apreciada.

seandavi
fuente

Respuestas:

16

Espero que esto ayude un poco. Traté de no dejar que se convirtiera en una pared llena de texto. :)

3Par / Isilon

Si puede y dedicará una cantidad fija de horas hombre a alguien que asuma el rol de administrador de SAN y quiera disfrutar de una vida indolora con el sueño nocturno en lugar del trabajo nocturno, esta es la forma en que yo iría.

Una SAN le permite hacer todas las cosas donde un solo "almacenamiento" lo limitaría (es decir, conectar una matriz flash de almacenamiento puro y un gran monstruo sata de 3 par al mismo servidor), pero también tiene que pagar por ello y mantenerlo bien mantenido. el momento si quieres hacer uso de la flexibilidad.

Alternativas

Amplidata

Pros: escalable, económica, diseñada con un concepto agradable y capas de caché de lectura / escritura dedicadas. Esto podría ser lo mejor para ti.

RisingTideOS

Su software de destino se usa en casi todos los almacenes de Linux ahora y está permitiendo una gestión un poco mejor que las cosas simples de Linux / Gluster. (Imho) La versión comercial podría valer la pena.

Gluster / btrfs

PRO: se escala y los "ladrillos" le brindan una capa de abstracción que es muy buena para la administración.

CON: El primero ha sido un PITA total para mí. No era robusto, y las fallas podrían ser locales para un ladrillo o eliminar todo. Ahora, con RedHat en control, podría convertirse en algo que funcione e incluso he conocido personas que pueden domesticarlo para que funcione durante años. Y el segundo todavía es medio experimental. Normalmente, un FS necesita de 3 a 4 años después de que esté "hecho" hasta que se pruebe y sea robusto. Si te interesan los datos, ¿por qué considerarías esto? Hablando de experimental, el soporte comercial de Ceph ya casi está disponible, pero es necesario adherirse a la capa "RBD", el FS todavía no está suficientemente probado. Sin embargo, quiero dejar en claro que Ceph es mucho más atractivo a largo plazo. :)

ZFS

Pro: características que definitivamente ponen un clavo en el ataúd de otras cosas. Esas características están bien diseñadas (piense en L2ARC) y la compresión / deducción es divertida. Tener más "grupos de almacenamiento", lo que significa tener también pequeñas fallas en lugar de un gran boom consolidado

Con: mantener muchas pequeñas cajas de software en lugar de un almacenamiento real. Necesita integrarlos y pasar $$$ horas para tener una configuración robusta.

Florian Heigl
fuente
3
+1. Espero que no te importe que lo haya hecho un poco menos complicado.
Kyle Smith
@ florian-heigl ¿Podríamos tener algunos enlaces a seguir ya que no tengo suerte para encontrar algunas de las soluciones que menciona (por ejemplo, 3Par, Isilon, RisingTideOS). TIA
ossandcad
7

La ruta XFS + LVM es de hecho una de las mejores opciones para una solución de almacenamiento de Linux puro escalada en los últimos años. Me animo que ya estés allí. Ahora que necesita crecer más, tiene algunas opciones más disponibles.

Como saben, los grandes proveedores de hardware tienen cabezales NAS para su almacenamiento. De hecho, esto le daría un único proveedor con el que trabajar para que todo suceda, y funcionaría bastante bien. Son soluciones fáciles de obtener (en comparación con el bricolaje), y su capacidad de mantenimiento es menor. Pero, cuestan bastante. Por un lado, tendrá más recursos de ingeniería para resolver sus problemas principales en lugar de problemas de infraestructura; Por otro lado, si eres como la mayoría de los departamentos universitarios, he sabido que la mano de obra es realmente barata en relación con el pago en efectivo de las cosas.

Yendo por la ruta del bricolaje, ya tiene una buena apreciación de las opciones de bricolaje disponibles para usted. ZFS / BTRFS son la ruta de actualización obvia de XFS + LVM para el almacenamiento escalado. Me mantendría alejado de BTRFS hasta que se declare 'estable' en el núcleo de la línea principal de Linux, que debería ser bastante pronto ahora que varias de las principales distribuciones gratuitas lo están utilizando como el sistema de archivos predeterminado. Para ZFS, recomendaría usar una base BSD en lugar de OpenIndiana simplemente porque ha existido por más tiempo y tiene los problemas (más) resueltos.

Gluster fue diseñado para el caso de uso que describe aquí. Puede realizar la replicación y presentar un único servidor virtual con mucho almacenamiento conectado. Sus volúmenes distribuidos suenan exactamente lo que está buscando, ya que distribuyen los archivos en todos los servidores de almacenamiento en el volumen declarado. Puede continuar agregando servidores de almacenamiento discretos para continuar expandiendo el volumen visible. Nombre único espacio!

El problema con Gluster es que funciona mejor cuando sus clientes pueden usar Gluster Client para acceder al sistema en lugar de las opciones CIFS o NFS. Como está ejecutando un pequeño clúster de clúster, es posible que pueda utilizar el cliente GlusterFS.

Estás en el camino correcto aquí.

sysadmin1138
fuente
Una solución hágalo usted mismo significará que si lo rompe usted mismo, debe solucionarlo usted mismo. Esto se vuelve costoso a medida que superas los límites de un par de servidores. Si existe algún tipo de presión comercial para hacer que este almacenamiento sea altamente disponible, gastará menos dinero comprando una rueda que reinventando una. Se puede hacer que el software de almacenamiento que se ejecuta en servidores haga cualquier cosa que el almacenamiento real pueda hacer, pero no de manera más económica.
Albahaca
1

Según tengo entendido, podría usar una solución SAN basada en Linux SCST + FibreChannel o infiniband, que es algo que estoy construyendo en este momento. Como base para los LUN, puede usar LVM sobre RAID de hardware y ocuparse de las instantáneas / replicación (tome DRBD como ejemplo) por debajo del nivel del sistema de archivos. Como sistema de archivos, no conozco ninguna buena solución para la seguridad, ya que pongo ESXi en la parte superior de los nodos, por lo que los almacenes de datos son administrados por FS concurrente de ESX. Creo que GFS2 podría funcionar con ese entorno, pero no estoy 100% seguro, ya que debería verificar sus requisitos precisos. De todos modos, una vez que tenga una SAN robusta debajo de sus nodos, es bastante fácil hacer las cosas.

Martino Dino
fuente