Ola a todos! Con este artigo, AERODISK abre un blog sobre Habré. Hurra, compañeiros!
Os artigos anteriores sobre Habré discutían cuestións sobre a arquitectura e a configuración básica dos sistemas de almacenamento. Neste artigo consideraremos unha pregunta que non se cubriu anteriormente, pero que se fai moitas veces: sobre a tolerancia a fallos dos sistemas de almacenamento do motor AERODISK. O noso equipo fará todo o posible para garantir que o sistema de almacenamento AERODISK deixe de funcionar, é dicir. rompelo.
Aconteceu que en Habré xa están colgados artigos sobre a historia da nosa empresa, sobre os nosos produtos, así como un exemplo de implantación exitosa, para o que Moitas grazas aos nosos socios: empresas TS Solution e Softline.
Polo tanto, non adestrarei aquí habilidades de xestión de copiar e pegar, senón que simplemente proporcionarei ligazóns aos orixinais destes artigos:
Tamén quero compartir boas novas. Pero vou comezar, por suposto, co problema. Nós, como un provedor novo, entre outros custos, afrontámonos constantemente co feito de que moitos enxeñeiros e administradores simplemente non saben como operar correctamente o noso sistema de almacenamento.
Está claro que xestionar a maioría dos sistemas de almacenamento parece aproximadamente o mesmo desde o punto de vista dun administrador, pero cada fabricante ten as súas propias características. E aquí non somos unha excepción.
Por iso, para simplificar a tarefa de formación de especialistas en informática, decidimos dedicarnos este ano á gratuidade. Para iso, en moitas grandes cidades de Rusia estamos abrindo unha rede de Centros de Competencia AERODISK, na que calquera especialista técnico interesado pode realizar un curso totalmente gratuíto e recibir un certificado de administración de sistemas de almacenamento AERODISK ENGINE.
En cada Centro de Competencias instalaremos un stand de demostración completo do sistema de almacenamento AERODISK e un servidor físico, no que o noso profesor impartirá formación presencial. Publicaremos o calendario de traballo dos Centros de Competencia despois da súa aparición, pero xa abrimos un centro en Nizhny Novgorod e a próxima cidade de Krasnodar. Podes inscribirte na formación a través das seguintes ligazóns. Aquí tes a información coñecida actualmente sobre cidades e datas:
- Nizhny Novgorod (XA ABERTO: podes rexistrarte aquí );
Ata o 16 de abril de 2019 pódese visitar o centro en calquera horario laboral, e o 16 de abril de 2019 organizarase un amplo curso de formación. - Krasnodar (APERTURA PROXIMA: podes rexistrarte aquí );
Do 9 de abril ao 25 de abril de 2019 poderase visitar o centro en calquera horario laboral e o 25 de abril de 2019 organizarase un amplo curso de formación. - Yekaterinburg (PROXIMADAMENTE, siga a información na nosa web ou en Habré);
Maio-xuño 2019. - Novosibirsk (siga a información na nosa web ou en Habré);
Outubro 2019. - Krasnoyarsk (siga a información na nosa web ou en Habré);
Novembro de 2019.
E, por suposto, se Moscova non está lonxe de ti, podes visitar a nosa oficina en Moscova en calquera momento e recibir unha formación similar.
Todos. Rematamos o marketing, pasemos á tecnoloxía!
En Habré publicaremos regularmente artigos técnicos sobre os nosos produtos, probas de carga, comparacións, características de uso e implementacións interesantes.
Probas de choque do sistema de almacenamento AERODISK ENGINE N2, proba de resistencia
Atención! Despois de ler o artigo, podes dicir: ben, por suposto, o vendedor comprobarase a si mesmo para que todo funcione "cunha explosión", as condicións do invernadoiro, etc. Vou responder: nada así! A diferenza dos nosos competidores estranxeiros, estamos situados aquí, preto de ti, e sempre podes vir a nós (en Moscova ou en calquera Comité Central) e probar o noso sistema de almacenamento de calquera forma. Así, non ten moito sentido para nós axustar os resultados a unha imaxe ideal do mundo, porque Somos moi fáciles de comprobar. Para aqueles que teñen preguiza para ir e non teñen tempo, podemos organizar probas remotas. Temos un laboratorio especial para iso. Contacta connosco.
ACHTUNG-2! Esta proba non é unha proba de carga, porque aquí só nos importa a tolerancia a fallos. Nun par de semanas, prepararemos un stand máis potente e realizaremos probas de carga do sistema de almacenamento, publicando aquí os resultados (por certo, acéptanse solicitudes de probas).
Entón, imos rompelo.
Banco de probas
O noso stand consta do seguinte hardware:
- 1 x Sistema de almacenamento Aerodisk Engine N2 (2 controladores, caché de 64 GB, 8 portos FC 8 Gb/s, 4 portos Ethernet 10 Gb/s SFP+, 4 portos Ethernet 1 Gb/s); Os seguintes discos están instalados no sistema de almacenamento:
- 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, 96 GB de RAM, 2 x portos FC 8 Gb/s, 2 x portos Ethernet 10 Gb/s SFP+);
- 2 x interruptor SAN 8G;
- 2 x interruptor LAN 10G;
Conectamos o servidor ao sistema de almacenamento mediante interruptores a través de Ethernet FC e 10G. O diagrama do stand está a continuación.
Os compoñentes que necesitamos, como o iniciador MPIO e iSCSI, están instalados en Windows Server.
As zonas están configuradas nos switches FC, as VLAN correspondentes están configuradas nos switches LAN e MTU 9000 está instalado nos portos de almacenamento, switches e host (como facer todo isto descríbese na nosa documentación, polo que non describiremos este proceso aquí).
Metodoloxía da proba
O plan de proba de choque é o seguinte:
- Comprobando o fallo dos portos FC e Ethernet.
- Comprobación de fallo de alimentación.
- Comprobación de fallos do controlador.
- Comprobando fallos de disco nun grupo/grupo.
Todas as probas realizaranse en condicións de carga sintética, que xeraremos polo programa IOMETER. Paralelamente, realizaremos as mesmas probas, pero en condicións de copiar ficheiros grandes ao sistema de almacenamento.
A configuración do IOmeter é a seguinte:
- Ler/Escribir – 70/30
- Bloque - 128k (decidimos lavar os sistemas de almacenamento en bloques grandes)
- Número de fíos: 128 (que é moi semellante á carga produtiva)
- Aleatorio completo
- Número de traballadores: 4 (2 para FC, 2 para iSCSI)
A proba ten os seguintes obxectivos:
- Asegúrese de que o proceso de copia e carga sintética non interrompa nin cause erros en varios escenarios de fallo.
- Asegúrese de que o proceso de conmutación de portos, controladores, etc. estea suficientemente automatizado e non requira accións do administrador en caso de fallos (é dicir, durante os failovers, non estamos a falar de failbacks, claro).
- Asegúrese de que a información dos rexistros se mostra correctamente.
Preparación do sistema host e almacenamento
Configuramos o acceso en bloque no sistema de almacenamento mediante portos FC e Ethernet (FC e iSCSI, respectivamente). Os rapaces de TS Solution describiron en detalle como facelo nun artigo anterior (). E, por suposto, ninguén cancelou os manuais e os cursos.
Creamos un grupo híbrido usando todas as unidades que tiñamos. Engadíronse 2 discos SSD á caché, 2 discos SSD engadíronse como un nivel de almacenamento adicional (nivel en liña). Agrupamos 12 unidades SAS10k en RAID-60P (triple paridade) para comprobar a falla de tres unidades do grupo á vez. Quedou un disco para a súa substitución automática.
Conectamos dous LUN (un a través de FC, outro a través de iSCSI).
O propietario de ambos os LUN é o controlador Engine-0
Imos comezar a proba
Activamos IOMETER coa configuración anterior.
Gravamos un rendemento de 1.8 GB/s e unha latencia de 3 milisegundos. Non hai erros (Reconto de erros totais).
Ao mesmo tempo, desde a unidade local "C" do noso servidor, comezamos a copiar paralelamente dous ficheiros grandes de 100 GB a LUN de almacenamento FC e iSCSI (unidades E e G en Windows), utilizando outras interfaces.
Arriba está o proceso de copia a LUN FC, abaixo a iSCSI.
Proba #1: Desactivación de portos de E/S
Achegámonos ao sistema de almacenamento por detrás))) e cun leve movemento da man sacamos todos os cables FC e Ethernet 10G do controlador Engine-0. É coma se unha muller da limpeza cunha fregona pasase e decidira lavar o chan xusto onde estaba o moco e os cables (é dicir, o controlador aínda funciona, pero os portos de E/S están mortos).
Vexamos IOMETER e copiamos ficheiros. O rendemento baixou a 0,5 GB/s, pero volveu rapidamente ao seu nivel anterior (en aproximadamente 4-5 segundos). Non hai erros.
A copia de ficheiros non parou, hai unha baixada de velocidade, pero non é para nada crítico (de 840 MB/s baixouse a 720 MB/s). A copia non parou.
Observamos os rexistros do sistema de almacenamento e vemos unha mensaxe sobre a non dispoñibilidade de portos e a reubicación automática do grupo.
O panel de información tamén nos indica que non todo está moi ben cos portos FC.
O sistema de almacenamento sobreviviu a un fallo dos portos de E/S con éxito.
Proba n.o 2. Desactivando o controlador de almacenamento
Case inmediatamente (despois de volver conectar os cables ao sistema de almacenamento) decidimos rematar o sistema de almacenamento sacando o controlador do chasis.
De novo achegámonos ao sistema de almacenamento por detrás (gustounos))) e nesta ocasión sacamos o controlador Engine-1, que neste momento é o propietario do RDG (ao que se trasladou o grupo).
A situación en IOmeter é a seguinte. E/S detívose durante uns 5 segundos. Os erros non se acumulan.
Despois de 5 segundos, a E/S retomouse con aproximadamente o mesmo rendemento, pero con latencias de 35 milisegundos (latencias corrixidas despois dun par de minutos). Como se pode ver nas capturas de pantalla, o valor do reconto de erros totais é 0, é dicir, non houbo erros de escritura ou lectura.
Vexamos como copiar os nosos ficheiros. Como podes ver, non se interrompeu, houbo unha lixeira caída no rendemento, pero en xeral todo volveu ao mesmo ~ 800 MB/s.
Imos ao sistema de almacenamento e vemos unha maldición no panel de información de que o controlador Engine-1 non está dispoñible (por suposto, matámolo).
Tamén vemos unha entrada similar nos rexistros.
O controlador de almacenamento tamén sobreviviu a un fallo con éxito.
Proba no 3: Desconectar a alimentación.
Por se acaso, comezamos a copiar ficheiros de novo, pero non paramos IOMETER.
Tiramos da unidade de alimentación.
Engadiuse outra alerta ao sistema de almacenamento no panel de información.
Tamén no menú de sensores vemos que os sensores asociados á fonte de alimentación extraída se puxeron en vermello.
O sistema de almacenamento segue funcionando. A falla da fonte de alimentación non afecta de ningún xeito ao funcionamento do sistema de almacenamento; desde o punto de vista do host, a velocidade de copia e os indicadores IOMETER permaneceron inalterados.
Proba de fallo de enerxía superada con éxito.
Antes da proba final, decidimos recuperar un pouco o sistema de almacenamento, poñer de novo o controlador e a fonte de alimentación e tamén poñer en orde os cables, do que o sistema de almacenamento nos informou felizmente con iconas verdes no seu panel de saúde. .
Proba no 4. Fallo de tres discos nun grupo
Antes desta proba, realizamos un paso adicional de preparación. O feito é que o sistema de almacenamento ENGINE ofrece unha cousa moi útil: diferentes políticas de reconstrución. TS Solution escribiu sobre esta función anteriormente, pero recordemos a súa esencia. O administrador de almacenamento pode especificar a prioridade para a asignación de recursos durante a reconstrución. Ou na dirección do rendemento de E/S, é dicir, a reconstrución leva máis tempo, pero non hai unha diminución do rendemento. Ou na dirección da velocidade de reconstrución, pero a produtividade reducirase. Ou unha opción equilibrada. Dado que o rendemento do almacenamento durante a reconstrución do grupo de discos é sempre unha dor de cabeza para o administrador, probaremos unha política tendente ao rendemento de E/S e a costa da velocidade de reconstrución.
Agora imos comprobar a falla do disco. Tamén habilitamos a gravación en LUN (arquivos e IOMETER). Dado que temos un grupo con triple paridade (RAID-60P), isto significa que o sistema debe soportar o fallo de tres discos, e despois do fallo, a substitución automática debe funcionar, un disco debe substituír a un dos que fallan. no RDG, e hai que comezar a reconstruír nel.
Comeza. En primeiro lugar, a través da interface de almacenamento, imos destacar os discos que queremos sacar (para non perdernos e tirar do disco de autocambio).
Comprobamos a indicación no hardware. Todo está ben, vemos tres discos destacados.
E sacamos estes tres discos.
Vexamos o que hai no host. E alí... non pasou nada especial.
Os indicadores de copia (son máis altos que ao principio, porque a caché se quentou) e IOMETER non cambian moito ao eliminar os discos e iniciar a reconstrución (dentro do 5-10%).
Vexamos o que hai no sistema de almacenamento.
No estado do grupo, vemos que o proceso de reestruturación comezou e está a piques de rematar.
No esqueleto RDG podes ver que 2 discos están en estado vermello e un xa foi substituído. O disco de substitución automática xa non está aí; substituíu o terceiro disco fallido. A reconstrución levou varios minutos, a escritura de ficheiros cando fallaban 3 discos non se interrompeu e o rendemento de E/S non cambiou moito.
A proba de fallo do disco pasou definitivamente con éxito.
Conclusión
Neste punto, decidimos deter a violencia contra os sistemas de almacenamento. Imos resumir:
- Comprobación de fallo do porto FC: exitosa
- Comprobación de fallo do porto Ethernet: exitosa
- Comprobación de fallo do controlador: exitosa
- Proba de fallo de alimentación: exitosa
- Comprobando o fallo do disco no grupo de grupos: exitoso
Ningún dos fallos deixou de gravar nin provocou erros na carga sintética; por suposto, houbo un acerto de rendemento (e sabemos como superalo, que o faremos en breve), pero dado que son segundos, é bastante aceptable. Conclusión: a tolerancia a fallos de todos os compoñentes do sistema de almacenamento AERODISK funcionou a nivel, non houbo puntos de fallo.
Obviamente, nun artigo non podemos probar todos os escenarios de fallo, pero tentamos cubrir os máis populares. Por iso, por favor, envíe os seus comentarios, suxestións para futuras publicacións e, por suposto, as críticas adecuadas. Estaremos encantados de discutir (ou mellor aínda, ven á formación, duplico o horario por se acaso)! Ata novas probas!
- Nizhny Novgorod (XA ABERTO: podes rexistrarte aquí );
Ata o 16 de abril de 2019 pódese visitar o centro en calquera horario laboral, e o 16 de abril de 2019 organizarase un amplo curso de formación. - Krasnodar (APERTURA PROXIMA: podes rexistrarte aquí );
Do 9 de abril ao 25 de abril de 2019 poderase visitar o centro en calquera horario laboral e o 25 de abril de 2019 organizarase un amplo curso de formación. - Yekaterinburg (PROXIMADAMENTE, siga a información na nosa web ou en Habré);
Maio-xuño 2019. - Novosibirsk (siga a información na nosa web ou en Habré);
Outubro 2019. - Krasnoyarsk (siga a información na nosa web ou en Habré);
Novembro de 2019.
Fonte: www.habr.com