Hej alle! Med denne artikel åbner AERODISK en blog på Habré. Hurra, kammerater!
Tidligere artikler om Habré diskuterede spørgsmål om arkitekturen og den grundlæggende konfiguration af lagersystemer. I denne artikel vil vi overveje et spørgsmål, der ikke tidligere har været dækket, men ofte stilles - om fejltolerancen af AERODISK ENGINE lagersystemer. Vores team vil gøre alt for at AERODISK lagersystemet holder op med at fungere, dvs. Ødelæg det.
Det skete sådan, at artikler om vores virksomheds historie, om vores produkter samt et eksempel på vellykket implementering allerede hænger på Habré, for hvilket Mange tak til vores partnere - TS Solution og Softline virksomheder.
Derfor vil jeg ikke træne copy-paste ledelsesfærdigheder her, men vil blot give links til originalerne af disse artikler:
Jeg vil også gerne dele gode nyheder. Men jeg starter selvfølgelig med problemet. Vi, som en ung sælger, er blandt andre omkostninger konstant konfronteret med det faktum, at mange ingeniører og administratorer simpelthen ikke ved, hvordan de skal betjene vores lagersystem korrekt.
Det er klart, at administration af de fleste lagersystemer ser omtrent ens ud fra en administrators synspunkt, men hver producent har sine egne karakteristika. Og vi er ingen undtagelse her.
Derfor, for at forenkle opgaven med at uddanne it-specialister, besluttede vi at afsætte dette år til gratis uddannelse. For at gøre dette åbner vi i mange store byer i Rusland et netværk af AERODISK-kompetencecentre, hvor enhver interesseret teknisk specialist kan tage et kursus helt gratis og modtage et certifikat i at administrere AERODISK ENGINE-lagringssystemer.
I hvert Kompetencecenter vil vi installere en fuldgyldig demo-stand fra AERODISK-lagersystemet og en fysisk server, hvor vores underviser vil udføre træning ansigt-til-ansigt. Vi vil offentliggøre arbejdsplanen for kompetencecentrene, når de dukker op, men vi har allerede åbnet et center i Nizhny Novgorod, og byen Krasnodar er den næste. Du kan tilmelde dig træning ved at bruge nedenstående links. Her er de aktuelt kendte oplysninger om byer og datoer:
- Nizhny Novgorod (ALLEREDE ÅBEN – du kan tilmelde dig her );
Frem til den 16. april 2019 kan du besøge centret til enhver tid, og den 16. april 2019 tilrettelægges et stort uddannelsesforløb. - Krasnodar (ÅBNER SNART - du kan tilmelde dig her );
Fra den 9. april til den 25. april 2019 kan du besøge centret til enhver tid, og den 25. april 2019 afholdes et stort uddannelsesforløb. - Jekaterinburg (ÅBNER SNART, følg informationen på vores hjemmeside eller på Habré);
maj-juni 2019. - Novosibirsk (følg informationen på vores hjemmeside eller på Habré);
oktober 2019. - Krasnoyarsk (følg informationen på vores hjemmeside eller på Habré);
november 2019
Og selvfølgelig, hvis Moskva ikke er langt fra dig, kan du til enhver tid besøge vores kontor i Moskva og gennemgå lignende uddannelse.
Alle. Vi er færdige med markedsføring, lad os gå videre til teknologi!
På Habré vil vi jævnligt udgive tekniske artikler om vores produkter, belastningstest, sammenligninger, brugsegenskaber og interessante implementeringer.
Crashtest af AERODISK ENGINE N2 opbevaringssystem, styrketest
ADVARSEL! Efter at have læst artiklen kan du sige: ja, selvfølgelig vil sælgeren tjekke sig selv, så alt fungerer "med et brag", drivhusforhold osv. Jeg vil svare: intet som det! I modsætning til vores udenlandske konkurrenter er vi placeret her, tæt på dig, og du kan altid komme til os (i Moskva eller en hvilken som helst centralkomité) og teste vores lagersystem på enhver måde. Det giver således ikke meget mening for os at tilpasse resultaterne til et idealbillede af verden, pga Vi er meget nemme at tjekke. For dem, der er for dovne til at gå og ikke har tid, kan vi organisere fjerntest. Vi har et specielt laboratorium til dette. Kontakt os.
ACHTUNG-2! Denne test er ikke en belastningstest, fordi her bekymrer vi os kun om fejltolerance. Om et par uger vil vi forberede en mere kraftfuld stand og udføre belastningstest af lagersystemet, og offentliggøre resultaterne her (i øvrigt accepteres anmodninger om test).
Så lad os gå i stykker.
Prøvestativ
Vores stand består af følgende hardware:
- 1 x Aerodisk Engine N2-lagersystem (2 controllere, 64GB cache, 8xFC-porte 8Gb/s, 4xEthernet-porte 10Gb/s SFP+, 4xEthernet-porte 1Gb/s); Følgende diske er installeret i lagersystemet:
- 4 x SAS SSD-diske 900 GB;
- 12 x SAS 10k diske 1,2 TB;
- 1 x Fysisk server med Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC-porte 8Gb/s, 2xEthernet-porte 10Gb/s SFP+);
- 2 x SAN 8G switch;
- 2 x LAN 10G switch;
Vi koblede serveren til lagersystemet via switches via både FC og 10G Ethernet. Standdiagrammet er nedenfor.
De komponenter vi skal bruge, såsom MPIO og iSCSI initiator, er installeret på Windows Server.
Zoner er konfigureret på FC-switchene, de tilsvarende VLAN'er er konfigureret på LAN-switcherne, og MTU 9000 er installeret på lagerportene, switchene og værten (hvordan man gør alt dette er beskrevet i vores dokumentation, så vi vil ikke beskrive denne proces her).
Testmetode
Crashtestplanen er som følger:
- Kontrol af fejl på FC- og Ethernet-porte.
- Kontrol af strømsvigt.
- Kontrol af controllerfejl.
- Kontrollerer for diskfejl i en gruppe/pulje.
Alle test vil blive udført under syntetiske belastningsforhold, som vi vil generere af IOMETER-programmet. Sideløbende vil vi udføre de samme tests, men under betingelser for kopiering af store filer til lagersystemet.
IOmeter-konfigurationen er som følger:
- Læs/skriv – 70/30
- Blok – 128k (vi besluttede at vaske lagersystemerne i store blokke)
- Antal tråde – 128 (hvilket er meget lig den produktive belastning)
- Fuld tilfældig
- Antal arbejdere – 4 (2 for FC, 2 for iSCSI)
Testen har følgende mål:
- Sørg for, at den syntetiske indlæsnings- og kopieringsproces ikke vil afbryde eller forårsage fejl under forskellige fejlscenarier.
- Sørg for, at processen med at skifte porte, controllere osv. er tilstrækkeligt automatiseret og ikke kræver administratorhandlinger i tilfælde af fejl (det vil sige under failovers taler vi selvfølgelig ikke om failbacks).
- Sørg for, at oplysningerne i loggene vises korrekt.
Forberedelse af værts- og lagersystemet
Vi konfigurerede blokadgang på lagersystemet ved hjælp af FC- og Ethernet-porte (henholdsvis FC og iSCSI). Fyrene fra TS Solution beskrev i detaljer, hvordan man gør dette i en tidligere artikel (). Og selvfølgelig var der ingen, der aflyste manualerne og kurserne.
Vi oprettede en hybridgruppe ved hjælp af alle de drev, vi havde. 2 SSD-diske blev tilføjet til cachen, 2 SSD-diske blev tilføjet som et ekstra lagerniveau (Online-tier). Vi grupperede 12 SAS10k-drev i RAID-60P (triple parity) for at kontrollere fejlen på tre drev i gruppen på én gang. En disk var tilbage til automatisk udskiftning.
Vi tilsluttede to LUN'er (en via FC, en via iSCSI).
Ejeren af begge LUN'er er Engine-0-controlleren
Lad os starte testen
Vi aktiverer IOMETER med konfigurationen ovenfor.
Vi registrerer en gennemstrømning på 1.8 GB/s og en latenstid på 3 millisekunder. Der er ingen fejl (Total fejlantal).
På samme tid, fra det lokale drev "C" på vores vært, begynder vi parallelt at kopiere to store 100 GB-filer til FC- og iSCSI-lager-LUN'er (drev E og G i Windows), ved hjælp af andre grænseflader.
Ovenfor er kopieringsprocessen til LUN FC, nedenfor til iSCSI.
Test #1: Deaktivering af I/O-porte
Vi nærmer os lagersystemet bagfra))) og med en lille bevægelse af hånden trækker vi alle FC- og Ethernet 10G-kablerne ud fra Engine-0-controlleren. Det er, som om en rengøringsdame med en moppe gik forbi og besluttede at vaske gulvet lige der, hvor snottet lå, og kablerne lå (dvs. controlleren virker stadig, men I/O-portene er døde).
Lad os se på IOMETER og kopiering af filer. Gennemstrømningen faldt til 0,5 GB/s, men vendte hurtigt tilbage til det tidligere niveau (på omkring 4-5 sekunder). Der er ingen fejl.
Kopiering af filer er ikke stoppet, der er et fald i hastigheden, men det er slet ikke kritisk (fra 840 MB/s faldt det til 720 MB/s). Kopieringen er ikke stoppet.
Vi ser på lagringssystemloggene og ser en besked om manglende tilgængelighed af porte og den automatiske flytning af gruppen.
Informationspanelet fortæller os også, at alt ikke er særlig godt med FC-portene.
Lagersystemet overlevede en fejl i I/O-porte succesfuldt.
Test nr. 2. Deaktivering af lagercontrolleren
Næsten øjeblikkeligt (efter at have sat kablerne tilbage i lagersystemet) besluttede vi at afslutte lagersystemet ved at trække controlleren ud af chassiset.
Igen nærmer vi os lagersystemet bagfra (vi kunne lide det))), og denne gang trækker vi Engine-1-controlleren ud, som i øjeblikket er ejeren af RDG'en (som gruppen flyttede til).
Situationen i IOmeter er som følger. I/O stoppede i ca. 5 sekunder. Fejl akkumuleres ikke.
Efter 5 sekunder genoptog I/O med omtrent samme gennemløb, men med latenser på 35 millisekunder (latenserne korrigeret efter ca. et par minutter). Som det kan ses på skærmbillederne, er værdien for Total fejlantal 0, det vil sige, at der ikke var nogen skrive- eller læsefejl.
Lad os se på at kopiere vores filer. Som du kan se, blev den ikke afbrudt, der var et lille fald i ydeevnen, men generelt vendte alt tilbage til de samme ~ 800 MB/s.
Vi går til lagersystemet og ser en forbandelse i informationspanelet om, at Engine-1-controlleren ikke er tilgængelig (selvfølgelig slog vi den ihjel).
Vi ser også en lignende indtastning i loggene.
Lagercontrolleren overlevede også en fejl succesfuldt.
Test nr. 3: Afbrydelse af strømforsyningen.
For en sikkerheds skyld begyndte vi at kopiere filer igen, men stoppede ikke IOMETER.
Vi trækker strømforsyningsenheden.
Endnu en advarsel er blevet tilføjet til lagersystemet i informationspanelet.
Også i sensormenuen ser vi, at sensorerne forbundet med den udtrukne strømforsyning er blevet røde.
Lagersystemet fortsætter med at fungere. Fejlen i strømforsyningsenheden påvirker ikke på nogen måde driften af lagersystemet; fra værtens synspunkt forblev kopihastigheden og IOMETER-indikatorerne uændrede.
Strømsvigt test bestået succesfuldt.
Inden den sidste test besluttede vi at bringe lagersystemet lidt til live igen, sætte controlleren og strømforsyningsenheden tilbage og også sætte kablerne i stand, hvilket lagersystemet gladeligt informerede os om med grønne ikoner i sundhedspanelet. .
Test nr. 4. Fejl på tre diske i en gruppe
Før denne test udførte vi et yderligere forberedelsestrin. Faktum er, at ENGINE-lagringssystemet giver en meget nyttig ting - forskellige genopbygningspolitikker. TS Solution skrev om denne funktion tidligere, men lad os huske dens essens. Lageradministratoren kan angive prioriteten for ressourceallokering under genopbygning. Enten i retning af I/O-ydelse, det vil sige, at genopbygningen tager længere tid, men der er ingen ydelsesnedsættelse. Eller i retning af genopbygningshastighed, men produktiviteten vil blive reduceret. Eller en afbalanceret mulighed. Da lagerydeevne under genopbygning af diskgruppe altid er en administrators hovedpine, vil vi teste en politik med en bias mod I/O-ydeevne og på bekostning af genopbygningshastighed.
Lad os nu tjekke for diskfejl. Vi muliggør også optagelse til LUN'er (filer og IOMETER). Da vi har en gruppe med tredobbelt paritet (RAID-60P), betyder det, at systemet skal modstå fejl på tre diske, og efter fejlen skal automatisk udskiftning virke, én disk skal erstatte en af de fejlede. i RDG, og ombygningen skal begynde på den.
Begynde. Først gennem lagergrænsefladen, lad os fremhæve de diske, som vi vil trække ud (for ikke at gå glip af og trække autoskiftdisken).
Vi tjekker indikationen på hardwaren. Alt er OK, vi ser tre fremhævede diske.
Og vi trækker disse tre diske ud.
Lad os se på, hvad der er på værten. Og der... skete der ikke noget særligt.
Kopieringsindikatorerne (de er højere end i begyndelsen, fordi cachen er blevet varmet op) og IOMETER ændrer sig ikke meget, når man fjerner diskene og starter genopbygningen (inden for 5-10%).
Lad os se på, hvad der er på lagersystemet.
I status for koncernen ser vi, at omstruktureringsprocessen er begyndt, og den er tæt på at være afsluttet.
I RDG-skelettet kan du se, at 2 diske er i rød status, og den ene er allerede blevet udskiftet. Den automatiske udskiftningsdisk er der ikke længere; den erstattede den 3. fejlbehæftede disk. Genopbygningen tog flere minutter, skrivning af filer, når 3 diske fejlede, blev ikke afbrudt, og I/O-ydelsen ændrede sig ikke meget.
Diskfejlstesten bestod definitivt succesfuldt.
Konklusion
På dette tidspunkt besluttede vi at stoppe vold mod lagersystemer. Lad os opsummere:
- Kontrol af FC-portfejl - vellykket
- Kontrol af Ethernet-portfejl - vellykket
- Kontrol af controllerfejl - vellykket
- Strømsvigtstest - vellykket
- Kontrol af diskfejl i grouppool - vellykket
Ingen af fejlene stoppede med at optage eller forårsagede fejl i den syntetiske belastning; selvfølgelig var der et præstationshit (og vi ved, hvordan vi overvinder det, hvilket vi vil gøre snart), men i betragtning af at disse er sekunder, er det helt acceptabelt. Konklusion: fejltolerancen for alle komponenter i AERODISK-lagersystemet fungerede på niveauet, der var ingen fejlpunkter.
I en artikel kan vi naturligvis ikke teste alle fejlscenarier, men vi forsøgte at dække de mest populære. Send derfor gerne dine kommentarer, forslag til fremtidige udgivelser og selvfølgelig fyldestgørende kritik. Vi vil med glæde diskutere (eller endnu bedre, kom til træningen, jeg duplikerer tidsplanen for en sikkerheds skyld)! Indtil nye tests!
- Nizhny Novgorod (ALLEREDE ÅBEN – du kan tilmelde dig her );
Frem til den 16. april 2019 kan du besøge centret til enhver tid, og den 16. april 2019 tilrettelægges et stort uddannelsesforløb. - Krasnodar (ÅBNER SNART - du kan tilmelde dig her );
Fra den 9. april til den 25. april 2019 kan du besøge centret til enhver tid, og den 25. april 2019 afholdes et stort uddannelsesforløb. - Jekaterinburg (ÅBNER SNART, følg informationen på vores hjemmeside eller på Habré);
maj-juni 2019. - Novosibirsk (følg informationen på vores hjemmeside eller på Habré);
oktober 2019. - Krasnoyarsk (følg informationen på vores hjemmeside eller på Habré);
november 2019
Kilde: www.habr.com