Hei alle sammen! Med denne artikkelen åpner AERODISK en blogg på Habré. Hurra, kamerater!
Tidligere artikler om Habré diskuterte spørsmål om arkitektur og grunnleggende konfigurasjon av lagringssystemer. I denne artikkelen vil vi vurdere et spørsmål som ikke har vært dekket tidligere, men som ofte stilles - om feiltoleransen til AERODISK ENGINE lagringssystemer. Teamet vårt vil gjøre alt for å sikre at AERODISK-lagringssystemet slutter å fungere, d.v.s. ødelegg det.
Det hendte seg at artikler om selskapets historie, om produktene våre, samt et eksempel på vellykket implementering allerede henger på Habré, som Tusen takk til våre partnere - TS Solution og Softline selskaper.
Derfor vil jeg ikke trene copy-paste-administrasjonsferdigheter her, men vil ganske enkelt gi lenker til originalene til disse artiklene:
Jeg vil også dele gode nyheter. Men jeg starter selvfølgelig med problemet. Vi, som en ung leverandør, står blant andre kostnader konstant overfor det faktum at mange ingeniører og administratorer rett og slett ikke vet hvordan de skal betjene lagringssystemet vårt.
Det er klart at administrasjon av de fleste lagringssystemer ser omtrent likt ut fra en administrators synspunkt, men hver produsent har sine egne egenskaper. Og vi er intet unntak her.
Derfor, for å forenkle oppgaven med å trene IT-spesialister, bestemte vi oss for å vie dette året til gratis utdanning. For å gjøre dette åpner vi i mange store byer i Russland et nettverk av AERODISK-kompetansesentre, der enhver interessert teknisk spesialist kan ta et kurs helt gratis og motta et sertifikat i å administrere AERODISK ENGINE-lagringssystemer.
I hvert kompetansesenter vil vi installere et fullverdig demo-stativ fra AERODISK-lagringssystemet og en fysisk server, hvor læreren vår vil gjennomføre opplæring ansikt til ansikt. Vi vil publisere arbeidsplanen til kompetansesentrene når de dukker opp, men vi har allerede åpnet et senter i Nizhny Novgorod og byen Krasnodar er neste. Du kan melde deg på trening ved å bruke lenkene nedenfor. Her er den kjente informasjonen om byer og datoer:
- Nizjnij Novgorod (ALLEREDE ÅPENT – du kan melde deg på her );
Frem til 16. april 2019 kan du besøke senteret til enhver arbeidstid, og 16. april 2019 arrangeres et stort opplæringskurs. - Krasnodar (ÅPNER SNART - du kan melde deg på her );
Fra 9. april til 25. april 2019 kan du besøke senteret til enhver arbeidstid, og 25. april 2019 arrangeres et stort opplæringskurs. - Jekaterinburg (ÅPNER SNART, følg informasjonen på nettsiden vår eller på Habré);
mai-juni 2019. - Novosibirsk (følg informasjonen på vår nettside eller på Habré);
oktober 2019. - Krasnoyarsk (følg informasjonen på vår nettside eller på Habré);
november 2019.
Og selvfølgelig, hvis Moskva ikke er langt fra deg, kan du når som helst besøke kontoret vårt i Moskva og gjennomgå lignende opplæring.
Alle. Vi er ferdige med markedsføring, la oss gå videre til teknologi!
På Habré vil vi jevnlig publisere tekniske artikler om våre produkter, belastningstester, sammenligninger, bruksegenskaper og interessante implementeringer.
Kollisjonstester av AERODISK ENGINE N2 oppbevaringssystem, styrketest
ADVARSEL! Etter å ha lest artikkelen, kan du si: Vel, selvfølgelig vil leverandøren sjekke seg selv slik at alt fungerer "med et smell", drivhusforhold, etc. Jeg vil svare: ikke noe sånt! I motsetning til våre utenlandske konkurrenter, er vi lokalisert her, nær deg, og du kan alltid komme til oss (i Moskva eller hvilken som helst sentralkomité) og teste lagringssystemet vårt på noen måte. Dermed gir det ikke mye mening for oss å justere resultatene til et ideelt bilde av verden, fordi Vi er veldig enkle å sjekke. For de som er for late til å gå og ikke har tid, kan vi organisere fjerntesting. Vi har et spesielt laboratorium for dette. Kontakt oss.
ACHTUNG-2! Denne testen er ikke en belastningstest, fordi her bryr vi oss kun om feiltoleranse. Om et par uker vil vi forberede et kraftigere stativ og gjennomføre lasttesting av lagringssystemet, og publisere resultatene her (forresten, forespørsler om tester aksepteres).
Så la oss bryte det.
Prøvestativ
Standen vår består av følgende maskinvare:
- 1 x Aerodisk Engine N2 lagringssystem (2 kontrollere, 64 GB cache, 8xFC-porter 8Gb/s, 4xEthernet-porter 10Gb/s SFP+, 4xEthernet-porter 1Gb/s); Følgende disker er installert i lagringssystemet:
- 4 x SAS SSD-disker 900 GB;
- 12 x SAS 10k disker 1,2 TB;
- 1 x fysisk server med Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC-porter 8Gb/s, 2xEthernet-porter 10Gb/s SFP+);
- 2 x SAN 8G-bryter;
- 2 x LAN 10G-svitsj;
Vi koblet serveren til lagringssystemet via brytere via både FC og 10G Ethernet. Standdiagrammet er under.
Komponentene vi trenger, som MPIO og iSCSI initiator, er installert på Windows Server.
Soner er konfigurert på FC-svitsjene, de tilsvarende VLAN-ene er konfigurert på LAN-svitsjene, og MTU 9000 er installert på lagringsportene, svitsjene og verten (hvordan du gjør alt dette er beskrevet i dokumentasjonen vår, så vi vil ikke beskrive denne prosessen her).
Testmetodikk
Krasjtestplanen er som følger:
- Kontrollerer feilen i FC- og Ethernet-portene.
- Kontroll av strømbrudd.
- Kontroller feilkontroll.
- Se etter diskfeil i en gruppe/pool.
Alle tester vil bli utført under syntetiske belastningsforhold, som vi vil generere av IOMETER-programmet. Parallelt vil vi utføre de samme testene, men under betingelser for å kopiere store filer til lagringssystemet.
IOmeter-konfigurasjonen er som følger:
- Les/skriv – 70/30
- Blokk – 128k (vi bestemte oss for å vaske lagringssystemene i store blokker)
- Antall tråder – 128 (som er veldig lik den produktive belastningen)
- Full tilfeldig
- Antall arbeidere – 4 (2 for FC, 2 for iSCSI)
Testen har følgende mål:
- Sørg for at den syntetiske innlastings- og kopieringsprosessen ikke vil avbryte eller forårsake feil under ulike feilscenarier.
- Sørg for at prosessen med å bytte porter, kontrollere osv. er tilstrekkelig automatisert og ikke krever administratorhandlinger i tilfelle feil (det vil si under failovers snakker vi selvfølgelig ikke om failbacks).
- Sørg for at informasjonen i loggene vises riktig.
Klargjøring av verts- og lagringssystem
Vi konfigurerte blokktilgang på lagringssystemet ved å bruke FC- og Ethernet-porter (henholdsvis FC og iSCSI). Gutta fra TS Solution beskrev i detalj hvordan du gjør dette i en tidligere artikkel (). Og selvfølgelig var det ingen som kansellerte manualene og kursene.
Vi opprettet en hybridgruppe ved å bruke alle stasjonene vi hadde. 2 SSD-disker ble lagt til cachen, 2 SSD-disker ble lagt til som et ekstra lagringsnivå (Online-tier). Vi grupperte 12 SAS10k-stasjoner i RAID-60P (trippel paritet) for å sjekke feilen til tre stasjoner i gruppen samtidig. En disk ble igjen for automatisk erstatning.
Vi koblet sammen to LUN-er (en via FC, en via iSCSI).
Eieren av begge LUN-ene er Engine-0-kontrolleren
La oss starte testen
Vi aktiverer IOMETER med konfigurasjonen ovenfor.
Vi registrerer en gjennomstrømning på 1.8 GB/s og en ventetid på 3 millisekunder. Det er ingen feil (totalt antall feil).
Samtidig, fra den lokale stasjonen "C" til verten vår, begynner vi parallelt å kopiere to store 100 GB-filer til FC- og iSCSI-lagrings-LUN-er (stasjoner E og G i Windows), ved å bruke andre grensesnitt.
Over er kopieringsprosessen til LUN FC, nedenfor til iSCSI.
Test #1: Deaktivering av I/O-porter
Vi nærmer oss lagringssystemet bakfra))) og med en liten bevegelse av hånden trekker vi ut alle FC- og Ethernet 10G-kablene fra Engine-0-kontrolleren. Det er som om en rengjøringsdame med mopp gikk forbi og bestemte seg for å vaske gulvet akkurat der snøret lå og kablene lå (dvs. kontrolleren fungerer fortsatt, men I/O-portene er døde).
La oss se på IOMETER og kopiering av filer. Gjennomstrømningen falt til 0,5 GB/s, men gikk raskt tilbake til forrige nivå (på omtrent 4-5 sekunder). Det er ingen feil.
Kopiering av filer har ikke stoppet, det er et fall i hastighet, men det er slett ikke kritisk (fra 840 MB/s falt det til 720 MB/s). Kopieringen har ikke stoppet.
Vi ser på lagringssystemloggene og ser en melding om manglende tilgjengelighet av porter og automatisk flytting av gruppen.
Informasjonspanelet forteller oss også at alt ikke er veldig bra med FC-portene.
Lagringssystemet overlevde en feil i I/O-porter vellykket.
Test nr. 2. Deaktivering av lagringskontrolleren
Nesten umiddelbart (etter å ha koblet kablene tilbake til lagringssystemet) bestemte vi oss for å fullføre lagringssystemet ved å trekke kontrolleren ut av chassiset.
Igjen nærmer vi oss lagringssystemet bakfra (vi likte det))) og denne gangen trekker vi ut Engine-1-kontrolleren, som i dette øyeblikk er eieren av RDG (som gruppen flyttet til).
Situasjonen i IOmeter er som følger. I/O stoppet i ca. 5 sekunder. Feil akkumuleres ikke.
Etter 5 sekunder ble I/O gjenopptatt med omtrent samme gjennomstrømning, men med latenser på 35 millisekunder (latenser korrigert etter omtrent et par minutter). Som det fremgår av skjermbildene, er den totale feiltellingsverdien 0, det vil si at det ikke var noen skrive- eller lesefeil.
La oss se på å kopiere filene våre. Som du kan se, ble den ikke avbrutt, det var et lite fall i ytelsen, men totalt sett gikk alt tilbake til de samme ~ 800 MB/s.
Vi går til lagringssystemet og ser en forbannelse i informasjonspanelet om at Engine-1-kontrolleren ikke er tilgjengelig (selvfølgelig drepte vi den).
Vi ser også en lignende oppføring i loggene.
Lagringskontrolleren overlevde også en feil vellykket.
Test nr. 3: Koble fra strømforsyningen.
For sikkerhets skyld begynte vi å kopiere filer igjen, men stoppet ikke IOMETER.
Vi trekker strømforsyningsenheten.
Et annet varsel er lagt til lagringssystemet i informasjonspanelet.
Også i sensormenyen ser vi at sensorene knyttet til den uttrukket strømforsyningen har blitt røde.
Lagringssystemet fortsetter å fungere. Feilen i strømforsyningsenheten påvirker ikke på noen måte driften av lagringssystemet; fra vertens synspunkt forble kopihastigheten og IOMETER-indikatorene uendret.
Strømbruddstest bestått vellykket.
Før den siste testen bestemte vi oss for å vekke lagringssystemet litt til live igjen, sette tilbake kontrolleren og strømforsyningsenheten, og også sette kablene i orden, noe lagringssystemet gladelig informerte oss om med grønne ikoner i helsepanelet sitt. .
Test nr. 4. Feil på tre disker i en gruppe
Før denne testen utførte vi et ekstra forberedelsestrinn. Faktum er at ENGINE-lagringssystemet gir en veldig nyttig ting - forskjellige retningslinjer for gjenoppbygging. TS Solution skrev om denne funksjonen tidligere, men la oss huske essensen. Lagringsadministratoren kan angi prioritet for ressursallokering under gjenoppbygging. Enten i retning av I/O-ytelse, det vil si at ombyggingen tar lengre tid, men det er ingen ytelsesnedgang. Eller i retning av gjenoppbyggingshastighet, men produktiviteten vil reduseres. Eller et balansert alternativ. Siden lagringsytelse under gjenoppbygging av diskgrupper alltid er en administrators hodepine, vil vi teste en policy med en skjevhet mot I/O-ytelse og på bekostning av gjenoppbyggingshastighet.
La oss nå se etter diskfeil. Vi muliggjør også opptak til LUN-er (filer og IOMETER). Siden vi har en gruppe med trippel paritet (RAID-60P) betyr dette at systemet må tåle feil på tre disker, og etter feilen må auto-erstatning fungere, en disk må erstatte en av de mislykkede. i RDG, og ombyggingen må begynne på den.
Begynne. Først, gjennom lagringsgrensesnittet, la oss fremheve diskene som vi vil trekke ut (for ikke å gå glipp av og trekke autochange-disken).
Vi sjekker indikasjonen på maskinvaren. Alt er OK, vi ser tre uthevede disker.
Og vi trekker ut disse tre diskene.
La oss se på hva som står på verten. Og der... skjedde ingenting spesielt.
Kopieringsindikatorene (de er høyere enn i begynnelsen, fordi cachen er varmet opp) og IOMETER endres ikke mye når du fjerner diskene og starter gjenoppbyggingen (innen 5-10%).
La oss se på hva som er på lagringssystemet.
I statusen til konsernet ser vi at omstillingsprosessen er påbegynt og den nærmer seg ferdigstillelse.
I RDG-skjelettet kan du se at 2 disker er i rød status, og en er allerede skiftet ut. Autoerstatningsdisken er ikke lenger der; den erstattet den tredje mislykkede disken. Gjenoppbyggingen tok flere minutter, skriving av filer når 3 disker feilet ble ikke avbrutt, og I/O-ytelsen endret seg ikke mye.
Diskfeiltesten besto definitivt vellykket.
Konklusjon
På dette tidspunktet bestemte vi oss for å stoppe vold mot lagringssystemer. La oss oppsummere:
- Kontroll av FC-portfeil - vellykket
- Feilkontroll for Ethernet-port - vellykket
- Kontroller feilkontroll – vellykket
- Strømsvikttest – vellykket
- Kontrollerer diskfeil i grouppool - vellykket
Ingen av feilene stoppet opptaket eller forårsaket feil i den syntetiske belastningen; selvfølgelig var det et ytelsestreff (og vi vet hvordan vi skal overvinne det, noe vi vil gjøre snart), men gitt at dette er sekunder, er det ganske akseptabelt. Konklusjon: feiltoleransen til alle komponenter i AERODISK-lagringssystemet fungerte på nivået, det var ingen feilpunkter.
I en artikkel kan vi selvsagt ikke teste alle feilscenarier, men vi prøvde å dekke de mest populære. Send derfor dine kommentarer, forslag til fremtidige publikasjoner og selvfølgelig tilstrekkelig kritikk. Vi vil gjerne diskutere (eller enda bedre, kom til treningen, jeg dupliserer timeplanen i tilfelle)! Inntil nye tester!
- Nizjnij Novgorod (ALLEREDE ÅPENT – du kan melde deg på her );
Frem til 16. april 2019 kan du besøke senteret til enhver arbeidstid, og 16. april 2019 arrangeres et stort opplæringskurs. - Krasnodar (ÅPNER SNART - du kan melde deg på her );
Fra 9. april til 25. april 2019 kan du besøke senteret til enhver arbeidstid, og 25. april 2019 arrangeres et stort opplæringskurs. - Jekaterinburg (ÅPNER SNART, følg informasjonen på nettsiden vår eller på Habré);
mai-juni 2019. - Novosibirsk (følg informasjonen på vår nettside eller på Habré);
oktober 2019. - Krasnoyarsk (følg informasjonen på vår nettside eller på Habré);
november 2019.
Kilde: www.habr.com