Salut à tutti ! Cù questu articulu, AERODISK apre un blog nantu à Habré. Hurrah, camaradi !
Articuli precedenti nantu à Habré anu discututu e dumande nantu à l'architettura è a cunfigurazione basica di i sistemi di almacenamento. In questu articulu avemu da cunsiderà una quistione chì ùn hè micca stata cuperta prima, ma hè spessu dumandata - nantu à a tolleranza di difetti di i sistemi di almacenamiento AERODISK ENGINE. A nostra squadra farà tuttu per assicurà chì u sistema di almacenamentu AERODISK ferma di travaglià, i.e. rompe lu.
Hè accadutu chì l'articuli nantu à a storia di a nostra cumpagnia, nantu à i nostri prudutti, è ancu un esempiu di implementazione successu sò digià appiccicati à Habré, per quale Grazie mille à i nostri partenarii - cumpagnie TS Solution è Softline.
Dunque, ùn entreraghju micca e cumpetenze di gestione di copia-incolla quì, ma solu furnisce ligami à l'uriginali di questi articuli:
Vogliu ancu sparte una bona nutizia. Ma principiaraghju, sicuru, cù u prublema. Noi, cum'è un ghjovanu venditore, frà altri costi, simu constantemente affruntati cù u fattu chì parechji ingegneri è amministratori ùn sanu micca cumu fà u funziunamentu di u nostru sistema di almacenamento.
Hè chjaru chì a gestione di a maiò parte di i sistemi di almacenamentu hè apprussimatamente uguale da u puntu di vista di l'amministratore, ma ogni fabricatore hà e so caratteristiche. È ùn simu micca eccezzioni quì.
Dunque, per simplificà u compitu di furmà specialisti in IT, avemu decisu di dedicà questu annu à l'educazione libera. Per fà questu, in parechje grande cità di Russia avemu apertu una reta di Centri di Competenza AERODISK, in quale ogni specialista tecnicu interessatu pò piglià un cursu assolutamente gratuitu è riceve un certificatu in l'amministrazione di sistemi di almacenamento AERODISK ENGINE.
In ogni Centru di Competenza, installemu un stand demo cumpletu da u sistema di almacenamento AERODISK è un servitore fisicu, nantu à quale u nostru maestru duverà a furmazione in faccia. Publicaremu u calendariu di u travagliu di i Centri di Competenza dopu a so apparizione, ma avemu digià apertu un centru in Nizhny Novgorod è a cità di Krasnodar hè vicinu. Pudete iscrizzione per a furmazione usendu i ligami sottu. Eccu l'infurmazioni cunnisciute attualmente nantu à e cità è e date:
- Nizhny Novgorod (GIÀ APERTA - pudete iscrizzione quì );
Finu à u 16 d'aprile di u 2019, pudete visità u centru in ogni tempu di travagliu, è u 16 d'aprile di u 2019, un grande cursu di furmazione serà urganizatu. - Krasnodar (APERTURA PRONTO - pudete iscrizzione quì );
Da u 9 d'aprile à u 25 d'aprile di u 2019, pudete visità u centru in ogni tempu di travagliu, è u 25 d'aprile di u 2019 serà urganizatu un grande cursu di furmazione. - Екатеринбург (APERTURA PRONTO, seguitate l'infurmazioni nantu à u nostru situ web o nantu à Habré);
maghju-ghjugnu 2019. - Новосибирск (seguite l'infurmazioni nantu à u nostru situ web o in Habré);
Ottobre 2019. - Красноярск (seguite l'infurmazioni nantu à u nostru situ web o in Habré);
nuvembre 2019.
E, sicuru, se Mosca ùn hè micca luntanu da voi, allora in ogni mumentu pudete visità u nostru uffiziu in Mosca è sottumette una furmazione simile.
Tuttu. Avemu finitu cù u marketing, andemu à a tecnulugia !
In Habré publicheremu regularmente articuli tecnichi nantu à i nostri prudutti, teste di carica, paraguni, funziunalità d'usu è implementazioni interessanti.
Test di crash di u sistema di almacenamento AERODISK ENGINE N2, prova di forza
ATTENTI! Dopu avè lettu l'articulu, pudete dì: bè, sicuru, u vinditore verificarà ellu stessu per chì tuttu travaglia "cun bang", cundizioni di serra, etc. Rispondiraghju : nunda cusì ! A cuntrariu di i nostri cuncurrenti stranieri, simu situati quì, vicinu à voi, è pudete sempre vene à noi (in Mosca o in qualsiasi Cumitatu Centrale) è pruvà u nostru sistema di almacenamiento in ogni modu. Cusì, ùn hè micca assai sensu per noi per aghjustà i risultati à una stampa ideale di u mondu, perchè Semu assai faciuli di verificà. Per quelli chì sò troppu pigri per andà è ùn anu micca tempu, pudemu urganizà una prova remota. Avemu un laboratoriu speciale per questu. Cuntatta ci.
ACHTUNG-2! Questa prova ùn hè micca una prova di carica, perchè quì avemu solu cura di a tolleranza di colpa. In un paru di settimane, prepareremu un stand più putente è cunduceremu teste di carica di u sistema di almacenamento, publicendu i risultati quì (per via, e richieste di teste sò accettate).
Allora, andemu à rompe.
banc d'essai
U nostru stand hè custituitu da i seguenti hardware:
- 1 x Sistema di almacenamiento Aerodisk Engine N2 (2 controllers, 64GB cache, 8xFC porti 8Gb/s, 4xEthernet ports 10Gb/s SFP+, 4xEthernet ports 1Gb/s); I seguenti dischi sò stallati in u sistema di almacenamiento:
- 4 x dischi SSD SAS 900 GB;
- 12 x dischi SAS 10k 1,2 TB;
- 1 x Servitore fisicu cù Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xporte FC 8Gb/s, 2xporte Ethernet 10Gb/s SFP+);
- 2 x switch SAN 8G;
- 2 x LAN 10G switch;
Avemu cunnessu u servitore à u sistema di almacenamento per via di switch via FC è 10G Ethernet. U diagramma di stand hè quì sottu.
nantu Windows Server I cumpunenti chì ci vole, cum'è MPIO è l'iniziatore iSCSI, sò stallati.
I zoni sò cunfigurati nantu à i switch FC, i VLAN currispundenti sò cunfigurati nantu à i switch LAN, è MTU 9000 hè stallatu nantu à i porti di almacenamento, i switches è l'ospiti (cumu fà tuttu questu hè descrittu in a nostra ducumentazione, per quessa ùn avemu micca descrizzione). stu prucessu quì).
Metodologia di prova
U pianu di prova di crash hè u seguente:
- Verificate u fallimentu di i porti FC è Ethernet.
- Verificazione di a mancanza di energia.
- Verificazione di fallimentu di u controller.
- Verificazione di fallimentu di discu in un gruppu / pool.
Tutte e teste seranu realizate in cundizioni di carica sintetica, chì generaremu da u prugramma IOMETER. In parallelu, faremu i stessi testi, ma in cundizioni di cupià i schedarii grossi à u sistema di almacenamiento.
A cunfigurazione IOmeter hè a siguenti:
- Leghjite / Scrive - 70/30
- Block - 128k (avemu decisu di lavà i sistemi di almacenamento in grandi blocchi)
- Numero di filamenti - 128 (chì hè assai simili à a carica produtiva)
- Full Random
- Numero di travagliadori - 4 (2 per FC, 2 per iSCSI)
A prova hà i seguenti scopi:
- Assicuratevi chì a carica sintetica è u prucessu di copia ùn interrompe micca o causanu errori in diversi scenarii di fallimentu.
- Assicuratevi chì u prucessu di cambià i porti, i cuntrolli, etc. hè abbastanza automatizatu è ùn hè micca bisognu di l'azzioni di l'amministratore in casu di fallimenti (vale à dì, durante i failovers, ùn parlemu micca di failbacks, sicuru).
- Assicuratevi chì l'infurmazioni in i logs sò visualizati currettamente.
Preparazione di l'ospitu è u sistema di almacenamento
Avemu cunfiguratu l'accessu di bloccu nantu à u sistema di almacenamiento utilizendu porti FC è Ethernet (FC è iSCSI, rispettivamente). I ragazzi di TS Solution anu descrittu in dettagliu cumu fà questu in un articulu precedente (). E, sicuru, nimu hà annullatu i manuali è i corsi.
Avemu stabilitu un gruppu hibridu utilizendu tutte e unità chì avemu avutu. I dischi SSD 2 sò stati aghjuntu à a cache, i dischi SSD 2 sò stati aghjuntu cum'è un livellu di almacenamento supplementu (Livellu in linea). Avemu raggruppatu 12 unità SAS10k in RAID-60P (tripla parità) per verificà u fallimentu di trè unità in u gruppu in una volta. Un discu hè statu lasciatu per autoreplacement.
Avemu cunnessu dui LUN (unu via FC, unu via iSCSI).
U pruprietariu di i dui LUN hè u controller Engine-0
Cuminciamu a prova
Attivà IOMETER cù a cunfigurazione sopra.
Avemu registratu un throughput di 1.8 GB / s è una latenza di 3 millisecondi. Ùn ci hè micca errore (Conte Totale di Errori).
À u listessu tempu, da l'unità locale "C" di u nostru òspite, cuminciamu parallelamente à copià dui grandi fugliali 100GB à LUN di almacenamiento FC è iSCSI (unità E è G in Windows), utilizendu altre interfacce.
Sopra hè u prucessu di copia à LUN FC, sottu à iSCSI.
Test #1: Disattivazione di i porti I/O
Avvicinemu u sistema di almacenamentu da daretu))) è cun un ligeru muvimentu di a manu tiramu tutti i cavi FC è Ethernet 10G da u controller Engine-0. Hè cum'è s'è una donna di pulizia cun un mop passava è hà decisu di lavà u pianu ghjustu induve u snot era stendu è i cables eranu stendu (vale à dì, u controller hè sempre travagliatu, ma i porti I / O sò morti).
Fighjemu IOMETER è cupià i schedari. A produzzione hè cascata à 0,5 GB / s, ma hà tornatu rapidamente à u so livellu precedente (in circa 4-5 seconde). Ùn ci sò micca errori.
A copia di i fugliali ùn hà micca firmatu, ci hè una calata di velocità, ma ùn hè micca per tuttu criticu (da 840 MB/s hè cascatu à 720 MB/s). A copia ùn hè micca firmata.
Fighjemu à i logs di u sistema di almacenamentu è vede un missaghju nantu à a indisponibilità di i porti è a traslocazione automatica di u gruppu.
U pannellu d'infurmazioni ci dice ancu chì tuttu ùn hè micca assai bonu cù i porti FC.
U sistema di almacenamiento hà sopravvissutu à un fallimentu di i porti I/O cun successu.
Test No 2. Disattivà u controller di almacenamiento
Quasi subitu (dopu à avè aghjustatu i cavi in u sistema di almacenamentu) avemu decisu di finisce u sistema di almacenamentu tirà u controller fora di u chassis.
Una volta avemu avvicinatu u sistema di almacenamento da daretu (ci hè piaciutu))) è sta volta tiramu fora u controller Engine-1, chì in questu mumentu hè u pruprietariu di u RDG (à quale u gruppu si trasfirìu).
A situazione in IOmeter hè a siguenti. I/O si fermò per circa 5 seconde. L'errori ùn s'accumulanu micca.
Dopu à 5 seconde, l'I / O ripigliò cù circa u listessu throughput, ma cù latenzi di 35 millisecondi (latenzii curretti dopu à un paru di minuti). Comu pò esse vistu da i screenshots, u valore di u numeru di errore Totale hè 0, vale à dì, ùn ci era micca errore di scrittura o lettura.
Fighjemu à cupià i nostri schedari. Comu pudete vede, ùn hè micca stata interrotta, ci hè stata una ligera calata di rendiment, ma in generale tuttu hè tornatu à u listessu ~ 800 MB/s.
Andemu à u sistema di almacenamiento è vede una malidizioni in u pannellu d'infurmazioni chì u controller Engine-1 ùn hè micca dispunibule (di sicuru, avemu uccisu).
Avemu ancu vede una entrata simili in i logs.
U controller di almacenamiento hà ancu sopravvissutu à un fallimentu cun successu.
Test No. 3: Disconnecting the power supply.
Just in casu, avemu principiatu à cupià i schedari di novu, ma ùn firmavanu IOMETER.
Tiremu l'unità di alimentazione.
Una altra alerta hè stata aghjunta à u sistema di almacenamento in u pannellu d'infurmazioni.
Ancu in u menù di i sensori, vedemu chì i sensori assuciati cù l'alimentazione di l'alimentazione sò diventati rossi.
U sistema di almacenamiento cuntinueghja à travaglià. U fallimentu di l'unità di alimentazione ùn hà micca affettatu in alcun modu u funziunamentu di u sistema di almacenamento; da u puntu di vista di l'ospite, a velocità di copia è l'indicatori IOMETER sò rimasti invariati.
A prova di fallimentu di energia hè stata passata cun successu.
Prima di a prova finale, avemu decisu di rinvià u sistema di almacenamentu à a vita un pocu, rinviate u controller è l'unità di alimentazione, è ancu mette i cavi in ordine, chì u sistema di almacenamentu ci hà infurmatu felice cù icone verdi in u so pannellu di salute. .
Test No 4. Fiascu di trè dischi in un gruppu
Prima di sta prova, avemu fattu un passu di preparazione supplementu. U fattu hè chì u sistema di almacenamiento ENGINE furnisce una cosa assai utile - diverse pulitiche di ricustruzzione. TS Solution hà scrittu annantu à sta funzione prima, ma ricurdemu a so essenza. L'amministratore di almacenamiento pò specificà a priorità per l'assignazione di risorse durante a ricustruzione. Sia in a direzzione di u rendiment I / O, vale à dì, a ricustruzzione dura più, ma ùn ci hè micca un drawdown di rendiment. O in a direzzione di a veloce di ricustruisce, ma a produtividade serà ridutta. O una opzione equilibrata. Siccomu a prestazione di almacenamento durante a ricustruzzione di u gruppu di discu hè sempre un mal di testa di l'amministratore, testeremu una pulitica cù un preghjudiziu versu u rendiment I / O è à a spesa di a velocità di ricustruzione.
Avà cuntrollemu per fallimentu di u discu. Avemu ancu attivatu a registrazione in LUN (fichi è IOMETER). Siccomu avemu un gruppu cù triple parità (RAID-60P), questu significa chì u sistema deve sustene u fallimentu di trè dischi, è dopu à u fallimentu, l'auto-sustituzione deve travaglià, un discu deve piglià u postu di unu di i fiaschi. in u RDG, è a ricustruzione deve principià nantu à questu.
Principià. Prima, per mezu di l'interfaccia di almacenamento, mette in risaltu i dischi chì vulemu caccià (per ùn mancassi è tirà u discu autochange).
Cuntrollamu l'indicazione nantu à u hardware. Tuttu hè bè, vedemu trè dischi evidenziati.
E tiremu sti trè dischi.
Fighjemu ciò chì hè nantu à l'ospite. È ùn ci hè nunda di speciale.
L'indicatori di copia (sò più altu ch'è à l'iniziu, perchè u cache s'hè riscaldatu) è IOMETER ùn cambianu micca assai quandu sguassate i dischi è cumincianu a ricustruisce (in 5-10%).
Fighjemu ciò chì hè nantu à u sistema di almacenamiento.
In u statutu di u gruppu, vedemu chì u prucessu di ristrutturazione hà iniziatu è hè vicinu à a fine.
In u scheletru RDG pudete vede chì i dischi 2 sò in statu rossu, è unu hè statu sustituitu. U discu di autosustituzione ùn hè più quì; hà rimpiazzatu u terzu discu fallutu. A ricustruzzione hà pigliatu parechji minuti, scrive i fugliali quandu 3 dischi falluti ùn hè micca interrotta, è u rendiment I / O ùn hà micca cambiatu assai.
A prova di fallimentu di u discu hè definitivamente passatu cun successu.
cunchiusioni
À questu puntu, avemu decisu di piantà a viulenza contr'à i sistemi di almacenamento. Riassumemu:
- Verificazione di fallimentu di u portu FC - successu
- Verificazione di fallimentu di u portu Ethernet - successu
- Verificazione di fallimentu di u controller - successu
- Test di fallimentu di l'energia - Successu
- Verificazione di u fallimentu di u discu in u gruppu - successu
Nisunu di i fallimenti hà cessatu di registrà o hà causatu errori in a carica sintetica; di sicuru, ci hè statu un successu di rendiment (è sapemu cumu superà, chì faremu prestu), ma datu chì sò sicondi, hè abbastanza accettabile. Conclusioni: a tolleranza di difetti di tutti i cumpunenti di u sistema di almacenamiento AERODISK hà travagliatu à u livellu, ùn ci era micca punti di fallimentu.
Ovviamente, in un articulu ùn pudemu micca pruvà tutti i scenarii di fallimentu, ma avemu pruvatu à copre i più populari. Dunque, mandate i vostri cumenti, suggerimenti per publicazioni future è, sicuru, critiche adatte. Seremu cuntenti di discutiri (o megliu ancu, venite à a furmazione, duppiu u calendariu per casu) ! Finu à novi teste!
- Nizhny Novgorod (GIÀ APERTA - pudete iscrizzione quì );
Finu à u 16 d'aprile di u 2019, pudete visità u centru in ogni tempu di travagliu, è u 16 d'aprile di u 2019, un grande cursu di furmazione serà urganizatu. - Krasnodar (APERTURA PRONTO - pudete iscrizzione quì );
Da u 9 d'aprile à u 25 d'aprile di u 2019, pudete visità u centru in ogni tempu di travagliu, è u 25 d'aprile di u 2019 serà urganizatu un grande cursu di furmazione. - Екатеринбург (APERTURA PRONTO, seguitate l'infurmazioni nantu à u nostru situ web o nantu à Habré);
maghju-ghjugnu 2019. - Новосибирск (seguite l'infurmazioni nantu à u nostru situ web o in Habré);
Ottobre 2019. - Красноярск (seguite l'infurmazioni nantu à u nostru situ web o in Habré);
nuvembre 2019.
Source: www.habr.com
