Hej alla! Med den här artikeln öppnar AERODISK en blogg på Habré. Hurra, kamrater!
Tidigare artiklar om Habré diskuterade frågor om arkitektur och grundläggande konfiguration av lagringssystem. I den här artikeln kommer vi att överväga en fråga som inte har täckts tidigare, men som ofta ställs - om feltoleransen hos AERODISK ENGINE-lagringssystem. Vårt team kommer att göra allt för att AERODISK-lagringssystemet slutar fungera, d.v.s. förstör den.
Det hände så att artiklar om vårt företags historia, om våra produkter, såväl som ett exempel på framgångsrik implementering redan hänger på Habré, för vilket Stort tack till våra partners - TS Solution och Softline företag.
Därför kommer jag inte träna copy-paste-hanteringsfärdigheter här, utan kommer helt enkelt att tillhandahålla länkar till originalen av dessa artiklar:
Jag vill också dela med mig av goda nyheter. Men jag börjar förstås med problemet. Vi, som en ung leverantör, bland andra kostnader, står ständigt inför det faktum att många ingenjörer och administratörer helt enkelt inte vet hur de ska sköta vårt lagringssystem på rätt sätt.
Det är tydligt att hanteringen av de flesta lagringssystem ser ungefär likadant ut från en administratörs synvinkel, men varje tillverkare har sina egna egenskaper. Och vi är inget undantag här.
Därför, för att förenkla uppgiften att utbilda IT-specialister, beslutade vi att ägna detta år åt gratis utbildning. För att göra detta öppnar vi i många stora städer i Ryssland ett nätverk av AERODISK Competence Centers, där alla intresserade tekniska specialister kan ta en kurs helt gratis och få ett certifikat i att administrera AERODISK ENGINE-lagringssystem.
I varje kompetenscenter kommer vi att installera ett fullfjädrat demoställ från lagringssystemet AERODISK och en fysisk server, på vilken vår lärare kommer att genomföra träning ansikte mot ansikte. Vi kommer att publicera kompetenscentrens arbetsschema när de dyker upp, men vi har redan öppnat ett center i Nizhny Novgorod och staden Krasnodar är nästa. Du kan anmäla dig till utbildningen via länkarna nedan. Här är den för närvarande kända informationen om städer och datum:
- Nizhny Novgorod (REDAN ÖPPET – du kan anmäla dig här );
Fram till den 16 april 2019 kan du besöka centret när som helst och den 16 april 2019 anordnas en stor utbildning. - krasnodar (ÖPPNAR SNART - du kan anmäla dig här );
Från 9 april till 25 april 2019 kan du besöka centret när som helst och den 25 april 2019 anordnas en stor utbildning. - Yekaterinburg (ÖPPNAR SNART, följ informationen på vår hemsida eller på Habré);
maj-juni 2019. - Novosibirsk (följ informationen på vår hemsida eller på Habré);
oktober 2019 - krasnoyarsk (följ informationen på vår hemsida eller på Habré);
november 2019.
Och, naturligtvis, om Moskva inte är långt från dig, kan du när som helst besöka vårt kontor i Moskva och genomgå liknande utbildning.
Allt. Vi är klara med marknadsföring, låt oss gå vidare till teknik!
På Habré kommer vi regelbundet att publicera tekniska artiklar om våra produkter, belastningstester, jämförelser, användningsegenskaper och intressanta implementeringar.
Krocktester av AERODISK ENGINE N2 lagringssystem, hållfasthetstest
VARNING! Efter att ha läst artikeln kan du säga: ja, naturligtvis kommer säljaren att kontrollera sig själv så att allt fungerar "med en smäll", växthusförhållanden, etc. Jag ska svara: inget sånt! Till skillnad från våra utländska konkurrenter finns vi här, nära dig, och du kan alltid komma till oss (i Moskva eller vilken centralkommitté som helst) och testa vårt lagringssystem på vilket sätt som helst. Därför är det inte mycket meningsfullt för oss att anpassa resultaten till en idealisk bild av världen, eftersom Vi är väldigt lätta att kontrollera. För dem som är för lata för att gå och inte har tid kan vi ordna fjärrtestning. Vi har ett speciellt labb för detta. Kontakta oss.
ACHTUNG-2! Detta test är inte ett belastningstest, eftersom här bryr vi oss bara om feltolerans. Om ett par veckor kommer vi att förbereda en mer kraftfull monter och genomföra belastningstester av lagringssystemet, publicera resultaten här (förresten, förfrågningar om tester accepteras).
Så, låt oss bryta det.
Testbänk
Vår monter består av följande hårdvara:
- 1 x Aerodisk Engine N2-lagringssystem (2 kontroller, 64GB cache, 8xFC-portar 8Gb/s, 4xEthernet-portar 10Gb/s SFP+, 4xEthernet-portar 1Gb/s); Följande diskar är installerade i lagringssystemet:
- 4 x SAS SSD-diskar 900 GB;
- 12 x SAS 10k diskar 1,2 TB;
- 1 x Fysisk server med Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC-portar 8Gb/s, 2xEthernet-portar 10Gb/s SFP+);
- 2 x SAN 8G-switch;
- 2 x LAN 10G switch;
Vi kopplade upp servern till lagringssystemet via switchar via både FC och 10G Ethernet. Stativdiagrammet finns nedan.
Komponenterna vi behöver, som MPIO och iSCSI initiator, är installerade på Windows Server.
Zoner konfigureras på FC-switcharna, motsvarande VLAN konfigureras på LAN-switcharna och MTU 9000 är installerad på lagringsportarna, switcharna och värden (hur man gör allt detta beskrivs i vår dokumentation, så vi kommer inte att beskriva denna process här).
Testmetodik
Krocktestplanen är följande:
- Kontrollerar fel på FC- och Ethernet-portar.
- Kontroll av strömavbrott.
- Kontroll av felkontroll.
- Söker efter diskfel i en grupp/pool.
Alla tester kommer att utföras under syntetiska belastningsförhållanden, som vi kommer att generera av programmet IOMETER. Parallellt kommer vi att utföra samma tester, men under förhållanden att kopiera stora filer till lagringssystemet.
IOmeter-konfigurationen är som följer:
- Läs/skriv – 70/30
- Block – 128k (vi bestämde oss för att tvätta lagringssystemen i stora block)
- Antal trådar – 128 (vilket är mycket likt den produktiva belastningen)
- Fullständig slumpmässig
- Antal arbetare – 4 (2 för FC, 2 för iSCSI)
Testet har följande mål:
- Se till att den syntetiska laddnings- och kopieringsprocessen inte kommer att avbryta eller orsaka fel under olika felscenarier.
- Se till att processen att byta portar, styrenheter etc. är tillräckligt automatiserad och inte kräver administratörsåtgärder vid fel (det vill säga under failovers pratar vi naturligtvis inte om failbacks).
- Se till att informationen i loggarna visas korrekt.
Förbereda värd- och lagringssystemet
Vi konfigurerade blockåtkomst på lagringssystemet med FC- och Ethernet-portar (FC respektive iSCSI). Killarna från TS Solution beskrev i detalj hur man gör detta i en tidigare artikel (). Och naturligtvis var det ingen som avbröt manualerna och kurserna.
Vi skapade en hybridgrupp med alla de enheter vi hade. 2 SSD-diskar lades till i cachen, 2 SSD-diskar lades till som en extra lagringsnivå (Online-tier). Vi grupperade 12 SAS10k-enheter i RAID-60P (trippelparitet) för att kontrollera felet på tre enheter i gruppen samtidigt. En disk fanns kvar för automatiskt utbyte.
Vi kopplade två LUN:er (en via FC, en via iSCSI).
Ägaren till båda LUN:erna är Engine-0-styrenheten
Låt oss börja testet
Vi aktiverar IOMETER med konfigurationen ovan.
Vi registrerar en genomströmning på 1.8 GB/s och en latens på 3 millisekunder. Det finns inga fel (Totalt antal fel).
Samtidigt, från den lokala enheten "C" på vår värd, börjar vi parallellt kopiera två stora 100 GB-filer till FC- och iSCSI-lagrings-LUN:er (enheterna E och G i Windows), med andra gränssnitt.
Ovan är kopieringsprocessen till LUN FC, nedan till iSCSI.
Test #1: Inaktivera I/O-portar
Vi närmar oss lagringssystemet bakifrån))) och med en lätt rörelse av handen drar vi ut alla FC- och Ethernet 10G-kablar från Engine-0-kontrollern. Det är som om en städerska med mopp gick förbi och bestämde sig för att tvätta golvet precis där snoppen låg och kablarna låg (dvs kontrollern fungerar fortfarande, men I/O-portarna är döda).
Låt oss titta på IOMETER och kopiera filer. Genomströmningen sjönk till 0,5 GB/s, men återgick snabbt till sin tidigare nivå (på cirka 4-5 sekunder). Det finns inga fel.
Kopieringen av filer har inte slutat, det finns en nedgång i hastighet, men det är inte alls kritiskt (från 840 MB/s sjönk det till 720 MB/s). Kopieringen har inte slutat.
Vi tittar på lagringssystemloggarna och ser ett meddelande om otillgängligheten av portar och den automatiska omlokaliseringen av gruppen.
Informationspanelen berättar också att allt inte är särskilt bra med FC-portarna.
Lagringssystemet överlevde ett fel i I/O-portar framgångsrikt.
Test nr 2. Inaktiverar lagringskontrollern
Nästan omedelbart (efter att ha kopplat tillbaka kablarna i lagringssystemet) bestämde vi oss för att avsluta lagringssystemet genom att dra ut styrenheten ur chassit.
Återigen närmar vi oss lagringssystemet bakifrån (vi gillade det))) och den här gången drar vi ut Engine-1-kontrollern, som för närvarande är ägaren till RDG (till vilken gruppen flyttade).
Situationen i IOmeter är följande. I/O stannade i cirka 5 sekunder. Fel ackumuleras inte.
Efter 5 sekunder återupptogs I/O med ungefär samma genomströmning, men med latenser på 35 millisekunder (latenser korrigerade efter ungefär ett par minuter). Som framgår av skärmdumparna är det totala felantalet värde 0, det vill säga det fanns inga skriv- eller läsfel.
Låt oss titta på att kopiera våra filer. Som du kan se avbröts den inte, det var en liten nedgång i prestanda, men totalt sett återgick allt till samma ~ 800 MB/s.
Vi går till lagringssystemet och ser en förbannelse i informationspanelen att Engine-1-styrenheten inte är tillgänglig (naturligtvis dödade vi den).
Vi ser också en liknande post i loggarna.
Lagringskontrollern överlevde också ett fel framgångsrikt.
Test nr 3: Koppla bort strömförsörjningen.
För säkerhets skull började vi kopiera filer igen, men stoppade inte IOMETER.
Vi drar strömförsörjningsenheten.
Ytterligare en varning har lagts till i lagringssystemet i informationspanelen.
Även i sensormenyn ser vi att sensorerna förknippade med den utdragna strömförsörjningen har blivit röda.
Lagringssystemet fortsätter att fungera. Felet i strömförsörjningsenheten påverkar inte på något sätt driften av lagringssystemet; ur värdens synvinkel förblev kopieringshastigheten och IOMETER-indikatorerna oförändrade.
Strömavbrottstest godkänt framgångsrikt.
Inför det sista testet bestämde vi oss för att väcka lite liv i lagringssystemet, sätta tillbaka styrenheten och strömförsörjningsenheten och även göra ordning på kablarna, vilket lagringssystemet glatt informerade oss om med gröna ikoner i sin hälsopanel .
Test nr 4. Fel på tre diskar i en grupp
Innan detta test utförde vi ytterligare ett förberedelsesteg. Faktum är att ENGINE-lagringssystemet ger en mycket användbar sak - olika ombyggnadspolicyer. TS Solution skrev om den här funktionen tidigare, men låt oss komma ihåg dess essens. Lagringsadministratören kan ange prioritet för resursallokering under ombyggnad. Antingen i riktning mot I/O-prestanda, det vill säga att ombyggnaden tar längre tid, men det finns ingen prestandaneddragning. Eller i riktning mot återuppbyggnadshastighet, men produktiviteten kommer att minska. Eller ett balanserat alternativ. Eftersom lagringsprestanda under återuppbyggnad av diskgrupp alltid är en administratörs huvudvärk, kommer vi att testa en policy med inriktning mot I/O-prestanda och på bekostnad av återuppbyggnadshastigheten.
Låt oss nu kolla efter diskfel. Vi möjliggör också inspelning till LUN:er (filer och IOMETER). Eftersom vi har en grupp med trippelparitet (RAID-60P) betyder det att systemet måste stå emot fel på tre diskar, och efter felet måste auto-ersättning fungera, en disk måste ersätta en av de misslyckade. i RDG, och ombyggnaden måste påbörjas på den.
Börja. Först, genom lagringsgränssnittet, låt oss markera de diskar som vi vill dra ut (för att inte missa och dra autoväxlingsskivan).
Vi kontrollerar indikeringen på hårdvaran. Allt är OK, vi ser tre markerade diskar.
Och vi drar ut dessa tre skivor.
Låt oss titta på vad som står på värden. Och där... hände inget speciellt.
Kopieringsindikatorerna (de är högre än i början, eftersom cachen har värmts upp) och IOMETER förändras inte mycket när du tar bort diskarna och startar ombyggnaden (inom 5-10%).
Låt oss titta på vad som finns på lagringssystemet.
I koncernens status ser vi att omstruktureringsprocessen har påbörjats och den är nära att slutföras.
I RDG-skelettet kan du se att 2 diskar är i röd status, och en har redan bytts ut. Den automatiska ersättningsskivan finns inte längre, den ersatte den tredje defekta disken. Ombyggnaden tog flera minuter, skrivandet av filer när 3 diskar misslyckades avbröts inte och I/O-prestandan förändrades inte mycket.
Diskfelstestet klarade definitivt framgångsrikt.
Slutsats
Vid det här laget bestämde vi oss för att stoppa våldet mot lagringssystem. Låt oss sammanfatta:
- Kontroll av FC-portfel - lyckades
- Felkontroll av Ethernet-porten - lyckades
- Kontroll av styrenhetsfel - lyckats
- Strömavbrottstest - framgångsrikt
- Kontrollerar diskfel i grupppoolen - lyckades
Inget av felen slutade spela in eller orsakade fel i den syntetiska belastningen; naturligtvis fanns det en prestandaträff (och vi vet hur vi ska övervinna det, vilket vi kommer att göra snart), men med tanke på att dessa är sekunder är det helt acceptabelt. Slutsats: feltoleransen för alla komponenter i AERODISK-lagringssystemet fungerade på nivån, det fanns inga felpunkter.
Uppenbarligen kan vi i en artikel inte testa alla felscenarier, men vi försökte täcka de mest populära. Skicka därför dina kommentarer, förslag för framtida publikationer och, naturligtvis, adekvat kritik. Vi diskuterar gärna (eller ännu bättre, kom till utbildningen, jag duplicerar schemat för säkerhets skull)! Tills nya tester!
- Nizhny Novgorod (REDAN ÖPPET – du kan anmäla dig här );
Fram till den 16 april 2019 kan du besöka centret när som helst och den 16 april 2019 anordnas en stor utbildning. - krasnodar (ÖPPNAR SNART - du kan anmäla dig här );
Från 9 april till 25 april 2019 kan du besöka centret när som helst och den 25 april 2019 anordnas en stor utbildning. - Yekaterinburg (ÖPPNAR SNART, följ informationen på vår hemsida eller på Habré);
maj-juni 2019. - Novosibirsk (följ informationen på vår hemsida eller på Habré);
oktober 2019 - krasnoyarsk (följ informationen på vår hemsida eller på Habré);
november 2019.
Källa: will.com