¡Hola a todos! Con este artículo, AERODISK abre un blog sobre Habré. ¡Hurra, camaradas!
Artículos anteriores sobre Habré discutieron cuestiones sobre la arquitectura y la configuración básica de los sistemas de almacenamiento. En este artículo consideraremos una pregunta que no se ha tratado anteriormente, pero que se plantea con frecuencia: acerca de la tolerancia a fallas de los sistemas de almacenamiento AERODISK ENGINE. Nuestro equipo hará todo lo posible para garantizar que el sistema de almacenamiento AERODISK deje de funcionar, es decir. romperlo.
Dio la casualidad de que en Habré ya están colgados artículos sobre la historia de nuestra empresa, sobre nuestros productos, así como un ejemplo de implementación exitosa, por lo que Muchas gracias a nuestros socios: las empresas TS Solution y Softline.
Por lo tanto, no entrenaré aquí habilidades de gestión de copiar y pegar, sino que simplemente proporcionaré enlaces a los originales de estos artículos:
También quiero compartir buenas noticias. Pero empezaré, por supuesto, por el problema. Nosotros, como proveedor joven, nos enfrentamos constantemente, entre otros costes, al hecho de que muchos ingenieros y administradores simplemente no saben cómo utilizar correctamente nuestro sistema de almacenamiento.
Está claro que la gestión de la mayoría de los sistemas de almacenamiento parece aproximadamente igual desde el punto de vista del administrador, pero cada fabricante tiene sus propias características. Y aquí no somos una excepción.
Por eso, para simplificar la tarea de formar especialistas en TI, decidimos dedicar este año a la educación gratuita. Para ello, en muchas grandes ciudades de Rusia estamos abriendo una red de Centros de Competencia AERODISK, en los que cualquier especialista técnico interesado puede realizar un curso de forma totalmente gratuita y recibir un certificado en la administración de sistemas de almacenamiento AERODISK ENGINE.
En cada Centro de Competencia instalaremos un stand de demostración completo del sistema de almacenamiento AERODISK y un servidor físico, en el que nuestro profesor realizará la formación presencial. Publicaremos el calendario de trabajo de los Centros de Competencia cuando aparezcan, pero ya hemos abierto un centro en Nizhny Novgorod y la siguiente será la ciudad de Krasnodar. Puede registrarse para recibir capacitación utilizando los enlaces a continuación. Aquí está la información actualmente conocida sobre ciudades y fechas:
- Nizhny Novgorod (YA ABIERTO – puedes registrarte aquí );
Hasta el 16 de abril de 2019 se podrá visitar el centro en cualquier horario laboral, y el 16 de abril de 2019 se organizará un gran curso de formación. - Krasnodar (APERTURA PRONTO - puedes registrarte aquí );
Del 9 al 25 de abril de 2019 se podrá visitar el centro en cualquier horario laboral, y el 25 de abril de 2019 se organizará un gran curso de formación. - Ekaterimburgo (PRÓXIMA APERTURA, siga la información en nuestro sitio web o en Habré);
Mayo-junio 2019. - Novosibirsk (siga la información en nuestro sitio web o en Habré);
Octubre 2019 - Krasnoyarsk (siga la información en nuestro sitio web o en Habré);
Noviembre de 2019.
Y, por supuesto, si Moscú no está lejos de usted, en cualquier momento puede visitar nuestra oficina en Moscú y recibir una formación similar.
Todo. Hemos terminado con el marketing, ¡pasemos a la tecnología!
En Habré publicaremos periódicamente artículos técnicos sobre nuestros productos, pruebas de carga, comparaciones, características de uso e implementaciones interesantes.
Pruebas de choque del sistema de almacenamiento AERODISK ENGINE N2, prueba de resistencia
¡ADVERTENCIA! Después de leer el artículo, se puede decir: bueno, por supuesto, el vendedor se comprobará él mismo para que todo funcione "a la perfección", las condiciones del invernadero, etc. Yo responderé: ¡nada de eso! A diferencia de nuestros competidores extranjeros, estamos ubicados aquí, cerca de usted, y usted siempre puede venir a nosotros (en Moscú o en cualquier Comité Central) y probar nuestro sistema de almacenamiento de cualquier forma. Por lo tanto, no tiene mucho sentido para nosotros ajustar los resultados a una imagen ideal del mundo, porque Somos muy fáciles de comprobar. Para aquellos a los que les dé pereza ir y no tengan tiempo, podemos organizar pruebas remotas. Contamos con un laboratorio especial para esto. Contáctenos.
¡ACHTUNG-2! Esta prueba no es una prueba de carga, porque Aquí sólo nos importa la tolerancia a fallos. En un par de semanas prepararemos un soporte más potente y realizaremos pruebas de carga del sistema de almacenamiento, publicando los resultados aquí (por cierto, se aceptan solicitudes de pruebas).
Entonces, vamos a romperlo.
Banco de pruebas
Nuestro stand consta del siguiente hardware:
- 1 sistema de almacenamiento Aerodisk Engine N2 (2 controladores, 64 GB de caché, 8 puertos FC de 8 Gb/s, 4 puertos Ethernet de 10 Gb/s SFP+, 4 puertos Ethernet de 1 Gb/s); Los siguientes discos están instalados en el sistema de almacenamiento:
- 4 discos SSD SAS de 900 GB;
- 12 discos SAS 10k de 1,2 TB;
- 1 x Servidor físico con Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xPuertos FC 8Gb/s, 2xPuertos Ethernet 10Gb/s SFP+);
- 2 conmutadores SAN 8G;
- 2 conmutadores LAN 10G;
Conectamos el servidor al sistema de almacenamiento mediante conmutadores a través de FC y Ethernet 10G. El diagrama del soporte se encuentra a continuación.
Los componentes que necesitamos, como MPIO y el iniciador iSCSI, están instalados en Windows Server.
Las zonas se configuran en los conmutadores FC, las VLAN correspondientes se configuran en los conmutadores LAN y se instala MTU 9000 en los puertos de almacenamiento, conmutadores y host (cómo hacer todo esto se describe en nuestra documentación, por lo que no describiremos este proceso aquí).
Metodología de prueba
El plan de prueba de choque es el siguiente:
- Comprobando el fallo de los puertos FC y Ethernet.
- Comprobación de fallo de alimentación.
- Comprobación de fallos del controlador.
- Comprobación de fallos de disco en un grupo/grupo.
Todas las pruebas se realizarán bajo condiciones de carga sintética, que generaremos mediante el programa IOMETER. Paralelamente realizaremos las mismas pruebas, pero bajo condiciones de copiar archivos de gran tamaño al sistema de almacenamiento.
La configuración de IOmeter es la siguiente:
- Lectura/Escritura – 70/30
- Bloque – 128k (decidimos lavar los sistemas de almacenamiento en bloques grandes)
- Número de subprocesos: 128 (que es muy similar a la carga productiva)
- Completamente aleatorio
- Número de trabajadores: 4 (2 para FC, 2 para iSCSI)
La prueba tiene los siguientes objetivos:
- Asegúrese de que el proceso de carga y copia sintética no se interrumpa ni cause errores en diversos escenarios de falla.
- Asegúrese de que el proceso de conmutación de puertos, controladores, etc. esté suficientemente automatizado y no requiera acciones del administrador en caso de fallas (es decir, durante las conmutaciones por error, no estamos hablando de conmutaciones por recuperación, por supuesto).
- Asegúrese de que la información de los registros se muestre correctamente.
Preparación del sistema host y de almacenamiento
Configuramos el acceso al bloque en el sistema de almacenamiento mediante puertos FC y Ethernet (FC e iSCSI, respectivamente). Los chicos de TS Solution describieron en detalle cómo hacer esto en un artículo anterior (). Y, por supuesto, nadie canceló los manuales y cursos.
Creamos un grupo híbrido utilizando todas las unidades que teníamos. Se agregaron 2 discos SSD al caché, se agregaron 2 discos SSD como nivel de almacenamiento adicional (nivel en línea). Agrupamos 12 unidades SAS10k en RAID-60P (triple paridad) para verificar la falla de tres unidades del grupo a la vez. Se dejó un disco para reemplazo automático.
Conectamos dos LUN (uno vía FC, otro vía iSCSI).
El propietario de ambos LUN es el controlador Engine-0
comencemos la prueba
Habilitamos IOMETER con la configuración anterior.
Registramos un rendimiento de 1.8 GB/s y una latencia de 3 milisegundos. No hay errores (Recuento total de errores).
Al mismo tiempo, desde la unidad local “C” de nuestro host, comenzamos a copiar paralelamente dos archivos grandes de 100 GB a LUN de almacenamiento FC e iSCSI (unidades E y G en Windows), utilizando otras interfaces.
Arriba está el proceso de copia a LUN FC, abajo a iSCSI.
Prueba n.º 1: deshabilitar los puertos de E/S
Nos acercamos al sistema de almacenamiento por detrás))) y con un ligero movimiento de la mano sacamos todos los cables FC y Ethernet 10G del controlador Engine-0. Es como si una señora de la limpieza pasara con un trapeador y decidiera lavar el piso justo donde estaban los mocos y los cables (es decir, el controlador todavía funciona, pero los puertos de E/S están muertos).
Veamos IOMETER y la copia de archivos. El rendimiento cayó a 0,5 GB/s, pero rápidamente volvió a su nivel anterior (en unos 4-5 segundos). No hay errores.
La copia de archivos no se ha detenido, hay una caída en la velocidad, pero no es nada crítica (de 840 MB/s bajó a 720 MB/s). La copia no ha cesado.
Miramos los registros del sistema de almacenamiento y vemos un mensaje sobre la falta de disponibilidad de puertos y la reubicación automática del grupo.
El panel informativo también nos dice que no todo va muy bien con los puertos FC.
El sistema de almacenamiento sobrevivió a una falla en los puertos de E/S exitosamente.
Prueba número 2. Deshabilitar el controlador de almacenamiento
Casi de inmediato (después de haber vuelto a enchufar los cables al sistema de almacenamiento) decidimos terminar el sistema de almacenamiento sacando el controlador del chasis.
Nuevamente nos acercamos al sistema de almacenamiento por detrás (nos gustó))) y esta vez sacamos el controlador Engine-1, que en este momento es el dueño del RDG (al que se mudó el grupo).
La situación en IOmeter es la siguiente. La E/S se detuvo durante unos 5 segundos. Los errores no se acumulan.
Después de 5 segundos, la E/S se reanudó con aproximadamente el mismo rendimiento, pero con latencias de 35 milisegundos (las latencias se corrigieron después de aproximadamente un par de minutos). Como se puede ver en las capturas de pantalla, el valor del recuento total de errores es 0, es decir, no hubo errores de escritura o lectura.
Veamos cómo copiar nuestros archivos. Como puede ver, no se interrumpió, hubo una ligera caída en el rendimiento, pero en general todo volvió a lo mismo ~ 800 MB/s.
Vamos al sistema de almacenamiento y vemos una maldición en el panel de información de que el controlador Engine-1 no está disponible (por supuesto, lo matamos).
También vemos una entrada similar en los registros.
El controlador de almacenamiento también sobrevivió a una falla. exitosamente.
Prueba No. 3: Desconectando la fuente de alimentación.
Por las dudas, comenzamos a copiar archivos nuevamente, pero no detuvimos IOMETER.
Sacamos la fuente de alimentación.
Se ha añadido otra alerta al sistema de almacenamiento en el panel de información.
También en el menú de sensores vemos que los sensores asociados a la fuente de alimentación desconectada se han puesto en rojo.
El sistema de almacenamiento sigue funcionando. La falla de la fuente de alimentación no afecta de ninguna manera el funcionamiento del sistema de almacenamiento; desde el punto de vista del host, la velocidad de copia y los indicadores IOMETER se mantuvieron sin cambios.
Prueba de fallo de alimentación superada exitosamente.
Antes de la prueba final, decidimos darle un poco de vida al sistema de almacenamiento, volver a colocar el controlador y la fuente de alimentación, y también ordenar los cables, de lo cual el sistema de almacenamiento nos informó felizmente con íconos verdes en su panel de estado. .
Prueba No. 4. Fallo de tres discos en un grupo.
Antes de esta prueba, realizamos un paso de preparación adicional. El hecho es que el sistema de almacenamiento ENGINE proporciona algo muy útil: diferentes políticas de reconstrucción. TS Solution escribió sobre esta característica anteriormente, pero recordemos su esencia. El administrador de almacenamiento puede especificar la prioridad para la asignación de recursos durante la reconstrucción. Ya sea en la dirección del rendimiento de E/S, es decir, la reconstrucción lleva más tiempo, pero no hay una reducción del rendimiento. O en la dirección de acelerar la reconstrucción, pero la productividad se reducirá. O una opción equilibrada. Dado que el rendimiento del almacenamiento durante la reconstrucción del grupo de discos siempre es un dolor de cabeza para el administrador, probaremos una política con un sesgo hacia el rendimiento de E/S y a expensas de la velocidad de reconstrucción.
Ahora verifiquemos si hay fallas en el disco. También habilitamos la grabación en LUN (archivos e IOMETER). Dado que tenemos un grupo con triple paridad (RAID-60P), esto significa que el sistema debe soportar la falla de tres discos, y después de la falla, el reemplazo automático debe funcionar, un disco debe tomar el lugar de uno de los fallidos. en el RDG, y debe comenzar su reconstrucción.
Comenzar. Primero, a través de la interfaz de almacenamiento, resaltemos los discos que queremos extraer (para no perdernos y extraer el disco de cambio automático).
Comprobamos la indicación en el hardware. Todo está bien, vemos tres discos resaltados.
Y sacamos estos tres discos.
Veamos qué hay en el host. Y ahí… no pasó nada especial.
Los indicadores de copia (son más altos que al principio, porque el caché se ha calentado) y el IOMETER no cambian mucho al retirar los discos y comenzar la reconstrucción (entre un 5 y un 10%).
Veamos qué hay en el sistema de almacenamiento.
En el estado del grupo vemos que el proceso de reestructuración ha comenzado y está a punto de finalizar.
En el esqueleto de RDG puede ver que 2 discos están en estado rojo y uno ya ha sido reemplazado. El disco de reemplazo automático ya no está allí; reemplazó el tercer disco fallido. La reconstrucción tomó varios minutos, la escritura de archivos cuando fallaron 3 discos no se interrumpió y el rendimiento de E/S no cambió mucho.
La prueba de falla del disco definitivamente pasó exitosamente.
Conclusión
En este punto, decidimos detener la violencia contra los sistemas de almacenamiento. Resumamos:
- Comprobación de fallo del puerto FC: exitosa
- Comprobación de fallo del puerto Ethernet: exitosa
- Comprobación de fallo del controlador: exitosa
- Prueba de falla de energía: exitosa
- Comprobando falla del disco en grouppool - exitosa
Ninguno de los fallos dejó de grabar ni provocó errores en la carga sintética; por supuesto, hubo un golpe de rendimiento (y sabemos cómo superarlo, lo cual haremos pronto), pero siendo segundos, es bastante aceptable. Conclusión: la tolerancia a fallas de todos los componentes del sistema de almacenamiento AERODISK funcionó al nivel, no hubo puntos de falla.
Obviamente, en un artículo no podemos probar todos los escenarios de falla, pero intentamos cubrir los más populares. Por ello, por favor envíen sus comentarios, sugerencias para futuras publicaciones y, por supuesto, las críticas adecuadas. ¡Estaremos encantados de discutirlo (o mejor aún, venir a la capacitación, duplico el horario por si acaso)! ¡Hasta nuevas pruebas!
- Nizhny Novgorod (YA ABIERTO – puedes registrarte aquí );
Hasta el 16 de abril de 2019 se podrá visitar el centro en cualquier horario laboral, y el 16 de abril de 2019 se organizará un gran curso de formación. - Krasnodar (APERTURA PRONTO - puedes registrarte aquí );
Del 9 al 25 de abril de 2019 se podrá visitar el centro en cualquier horario laboral, y el 25 de abril de 2019 se organizará un gran curso de formación. - Ekaterimburgo (PRÓXIMA APERTURA, siga la información en nuestro sitio web o en Habré);
Mayo-junio 2019. - Novosibirsk (siga la información en nuestro sitio web o en Habré);
Octubre 2019 - Krasnoyarsk (siga la información en nuestro sitio web o en Habré);
Noviembre de 2019.
Fuente: habr.com