Dag Allemaal! Met dit artikel opent AERODISK een blog op Habré. Hoera, kameraden!
Eerdere artikelen op Habré bespraken vragen over de architectuur en basisconfiguratie van opslagsystemen. In dit artikel zullen we een vraag bespreken die nog niet eerder is behandeld, maar die vaak wordt gesteld: over de fouttolerantie van AERODISK ENGINE-opslagsystemen. Ons team zal er alles aan doen om ervoor te zorgen dat het AERODISK opslagsysteem niet meer werkt, d.w.z. Maak het kapot.
Het gebeurde zo dat artikelen over de geschiedenis van ons bedrijf, over onze producten en een voorbeeld van succesvolle implementatie al bij Habré hangen, waarvoor Veel dank aan onze partners - TS Solution- en Softline-bedrijven.
Daarom zal ik hier geen vaardigheden op het gebied van copy-pastebeheer trainen, maar alleen links naar de originelen van deze artikelen verstrekken:
Ik wil ook goed nieuws delen. Maar ik begin natuurlijk met het probleem. Wij worden als jonge leverancier onder andere voortdurend geconfronteerd met het feit dat veel ingenieurs en beheerders simpelweg niet weten hoe ze ons opslagsysteem goed moeten bedienen.
Het is duidelijk dat het beheer van de meeste opslagsystemen er vanuit het oogpunt van een beheerder ongeveer hetzelfde uitziet, maar elke fabrikant heeft zijn eigen kenmerken. En wij zijn hier geen uitzondering op.
Om de taak van het opleiden van IT-specialisten te vereenvoudigen, hebben we daarom besloten dit jaar te wijden aan gratis onderwijs. Om dit te doen, openen we in veel grote steden van Rusland een netwerk van AERODISK Competence Centers, waar elke geïnteresseerde technische specialist geheel gratis een cursus kan volgen en een certificaat kan ontvangen voor het beheer van AERODISK ENGINE-opslagsystemen.
In elk Competentiecentrum zullen we een volwaardige demostand van het AERODISK-opslagsysteem en een fysieke server installeren, waarop onze docent face-to-face training zal geven. We zullen het werkschema van de Competentiecentra publiceren zodra ze verschijnen, maar we hebben al een centrum geopend in Nizjni Novgorod en de stad Krasnodar is de volgende. Via onderstaande links kunt u zich aanmelden voor een training. Hier vindt u de momenteel bekende informatie over steden en data:
- Nizhny Novgorod (REEDS GEOPEND – u kunt zich hier aanmelden );
Tot 16 april 2019 kun je op elk werktijdstip terecht in het centrum en op 16 april 2019 wordt er een grote training georganiseerd. - Krasnodar (BINNENKORT GEOPEND - u kunt zich hier aanmelden );
Van 9 april tot en met 25 april 2019 kun je op elk werktijdstip terecht in het centrum en op 25 april 2019 wordt er een grote training georganiseerd. - Yekaterinburg (BINNENKORT GEOPEND, volg de informatie op onze website of op Habré);
Mei-juni 2019. - Novosibirsk (volg de informatie op onze website of op Habré);
oktober 2019 - Krasnoyarsk (volg de informatie op onze website of op Habré);
november 2019.
En als Moskou niet ver bij u vandaan is, kunt u natuurlijk op elk moment ons kantoor in Moskou bezoeken en een soortgelijke training volgen.
Alle. We zijn klaar met marketing, laten we verder gaan met technologie!
Op Habré publiceren we regelmatig technische artikelen over onze producten, belastingtests, vergelijkingen, gebruikskenmerken en interessante implementaties.
Crashtests van AERODISK ENGINE N2 opslagsysteem, sterktetest
WAARSCHUWING! Na het lezen van het artikel kun je zeggen: nou ja, natuurlijk zal de verkoper zichzelf controleren, zodat alles "met een knal" werkt, de kasomstandigheden, enz. Ik zal antwoorden: zoiets niet! In tegenstelling tot onze buitenlandse concurrenten zijn wij hier dichtbij u gevestigd en kunt u altijd naar ons toe komen (in Moskou of een ander Centraal Comité) om ons opslagsysteem op welke manier dan ook te testen. Het heeft dus weinig zin om de resultaten aan te passen aan een ideaal beeld van de wereld, omdat Wij zijn heel gemakkelijk te controleren. Voor degenen die te lui zijn om te gaan en geen tijd hebben, kunnen we tests op afstand organiseren. Hiervoor hebben wij een speciaal laboratorium. Neem contact met ons op.
ACHTUNG-2! Deze test is geen belastingstest, omdat hier gaat het alleen om fouttolerantie. Over een paar weken zullen we een krachtigere stand voorbereiden en belastingstests van het opslagsysteem uitvoeren, waarbij we de resultaten hier publiceren (trouwens, verzoeken om tests worden geaccepteerd).
Dus laten we het gaan breken.
Testbank
Onze stand bestaat uit de volgende hardware:
- 1 x Aerodisk Engine N2-opslagsysteem (2 controllers, 64 GB cache, 8xFC-poorten 8Gb/s, 4xEthernet-poorten 10Gb/s SFP+, 4xEthernet-poorten 1Gb/s); De volgende schijven zijn in het opslagsysteem geïnstalleerd:
- 4 x SAS SSD-schijven 900 GB;
- 12 x SAS 10k-schijven 1,2 TB;
- 1 x Fysieke server met Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC-poorten 8Gb/s, 2xEthernet-poorten 10Gb/s SFP+);
- 2 x SAN 8G-schakelaar;
- 2 x LAN 10G-schakelaar;
We hebben de server via switches via zowel FC als 10G Ethernet met het opslagsysteem verbonden. Het standdiagram vindt u hieronder.
De componenten die we nodig hebben, zoals MPIO en iSCSI-initiator, zijn geïnstalleerd op Windows Server.
Zones worden geconfigureerd op de FC-switches, de bijbehorende VLAN's worden geconfigureerd op de LAN-switches en MTU 9000 wordt geïnstalleerd op de opslagpoorten, switches en host (hoe u dit allemaal moet doen, wordt beschreven in onze documentatie, dus we zullen dit niet beschrijven dit proces hier).
Testmethodologie
Het crashtestplan ziet er als volgt uit:
- Controle van de storing van FC- en Ethernet-poorten.
- Controle stroomuitval.
- Controle op foutcontrole van de controller.
- Controleren op schijffouten in een groep/pool.
Alle tests zullen worden uitgevoerd onder synthetische belastingsomstandigheden, die we zullen genereren door het IOMETER-programma. Tegelijkertijd zullen we dezelfde tests uitvoeren, maar onder omstandigheden waarbij grote bestanden naar het opslagsysteem worden gekopieerd.
De IOmeter-configuratie is als volgt:
- Lezen/schrijven – 70/30
- Blok – 128k (we hebben besloten de opslagsystemen in grote blokken te wassen)
- Aantal threads – 128 (wat sterk lijkt op de productieve belasting)
- Volledig willekeurig
- Aantal werknemers – 4 (2 voor FC, 2 voor iSCSI)
De test heeft de volgende doelstellingen:
- Zorg ervoor dat het synthetische laad- en kopieerproces onder verschillende foutscenario's niet wordt onderbroken of fouten veroorzaakt.
- Zorg ervoor dat het proces van het wisselen van poorten, controllers, etc. voldoende geautomatiseerd is en geen beheerdersacties vereist in geval van fouten (dat wil zeggen, tijdens failovers hebben we het natuurlijk niet over failbacks).
- Zorg ervoor dat de informatie in de logboeken correct wordt weergegeven.
Het host- en opslagsysteem voorbereiden
We hebben bloktoegang op het opslagsysteem geconfigureerd met behulp van FC- en Ethernet-poorten (respectievelijk FC en iSCSI). De jongens van TS Solution hebben in een vorig artikel gedetailleerd beschreven hoe je dit moet doen (). En natuurlijk heeft niemand de handleidingen en cursussen geannuleerd.
We hebben een hybride groep opgezet met alle drijfveren die we hadden. Er zijn 2 SSD-schijven toegevoegd aan de cache, 2 SSD-schijven zijn toegevoegd als extra opslaglaag (Online-tier). We hebben 12 SAS10k-schijven gegroepeerd in RAID-60P (drievoudige pariteit) om de storing van drie schijven in de groep tegelijk te controleren. Eén schijf bleef over voor automatische vervanging.
We hebben twee LUN's aangesloten (één via FC, één via iSCSI).
De eigenaar van beide LUN's is de Engine-0-controller
Laten we beginnen met de test
We schakelen IOMETER in met de bovenstaande configuratie.
We registreren een doorvoer van 1.8 GB/s en een latentie van 3 milliseconden. Er zijn geen fouten (totaal aantal fouten).
Tegelijkertijd beginnen we vanaf de lokale schijf “C” van onze host parallel twee grote bestanden van 100 GB te kopiëren naar FC- en iSCSI-opslag-LUN's (schijven E en G in Windows), met behulp van andere interfaces.
Hierboven ziet u het kopieerproces naar LUN FC, hieronder naar iSCSI.
Test #1: I/O-poorten uitschakelen
We naderen het opslagsysteem van achteren))) en met een lichte handbeweging trekken we alle FC- en Ethernet 10G-kabels uit de Engine-0-controller. Het is alsof er een schoonmaakster met een dweil langsloopt en besluit de vloer te wassen, precies daar waar het snot lag en de kabels lagen (dat wil zeggen: de controller werkt nog steeds, maar de I/O-poorten zijn dood).
Laten we eens kijken naar IOMETER en het kopiëren van bestanden. De doorvoer daalde tot 0,5 GB/s, maar keerde snel terug naar het vorige niveau (in ongeveer 4-5 seconden). Er zijn geen fouten.
Het kopiëren van bestanden is niet gestopt, er is een snelheidsdaling, maar deze is helemaal niet kritisch (van 840 MB/s gedaald naar 720 MB/s). Het kopiëren is niet gestopt.
We kijken naar de logboeken van het opslagsysteem en zien een bericht over de onbeschikbaarheid van poorten en de automatische verplaatsing van de groep.
Het informatiepaneel vertelt ons ook dat alles niet zo goed is met de FC-poorten.
Het opslagsysteem overleefde een storing van de I/O-poorten met succes.
Test nr. 2. De opslagcontroller uitschakelen
Vrijwel onmiddellijk (nadat we de kabels weer in het opslagsysteem hadden aangesloten) besloten we het opslagsysteem af te maken door de controller uit het chassis te trekken.
Opnieuw benaderen we het opslagsysteem van achteren (we vonden het leuk))) en deze keer halen we de Engine-1-controller tevoorschijn, die op dit moment de eigenaar is van de RDG (waarnaar de groep is verhuisd).
De situatie in Iometer is als volgt. I/O stopte ongeveer 5 seconden. Fouten stapelen zich niet op.
Na 5 seconden werd de I/O hervat met ongeveer dezelfde doorvoer, maar met latenties van 35 milliseconden (latenties gecorrigeerd na ongeveer een paar minuten). Zoals uit de schermafbeeldingen blijkt, is de totale fouttellingswaarde 0, dat wil zeggen dat er geen schrijf- of leesfouten zijn geweest.
Laten we eens kijken naar het kopiëren van onze bestanden. Zoals je kunt zien, werd het niet onderbroken, er was een lichte prestatiedaling, maar over het algemeen keerde alles terug naar dezelfde ~ 800 MB/s.
We gaan naar het opslagsysteem en zien een vloek in het informatiepaneel dat de Engine-1-controller niet beschikbaar is (natuurlijk hebben we hem gedood).
We zien ook een soortgelijke vermelding in de logs.
De opslagcontroller overleefde ook een storing met succes.
Test nr. 3: De stroomtoevoer loskoppelen.
Voor de zekerheid zijn we opnieuw begonnen met het kopiëren van bestanden, maar hebben IOMETER niet gestopt.
We trekken de voedingseenheid.
Er is nog een waarschuwing toegevoegd aan het opslagsysteem in het informatiepaneel.
Ook in het sensorenmenu zien we dat de sensoren behorend bij de uitgetrokken voeding rood zijn geworden.
Het opslagsysteem blijft werken. Het falen van de voedingseenheid heeft op geen enkele manier invloed op de werking van het opslagsysteem; vanuit het oogpunt van de host bleven de kopieersnelheid en IOMETER-indicatoren ongewijzigd.
Stroomuitvaltest geslaagd met succes.
Voor de laatste test hebben we besloten om het opslagsysteem weer een beetje tot leven te wekken, de controller en de voeding terug te plaatsen en ook de kabels in orde te brengen, waarover het opslagsysteem ons graag informeerde met groene pictogrammen in het gezondheidspaneel .
Test nr. 4. Falen van drie schijven in een groep
Voorafgaand aan deze test hebben we een extra voorbereidingsstap uitgevoerd. Feit is dat het ENGINE-opslagsysteem iets heel nuttigs biedt: ander herbouwbeleid. TS Solution schreef eerder over deze functie, maar laten we de essentie ervan in herinnering brengen. De opslagbeheerder kan de prioriteit opgeven voor de toewijzing van bronnen tijdens het opnieuw opbouwen. Ofwel in de richting van I/O-prestaties, dat wil zeggen, het opnieuw opbouwen duurt langer, maar er is geen sprake van prestatievermindering. Of in de richting van wederopbouwsnelheid, maar de productiviteit zal worden verminderd. Of een evenwichtige optie. Omdat opslagprestaties tijdens het opnieuw opbouwen van schijfgroepen altijd de kopzorg van de beheerder zijn, zullen we een beleid testen dat gericht is op I/O-prestaties en dat ten koste gaat van de herbouwsnelheid.
Laten we nu controleren op schijffouten. We maken ook opname naar LUN's (bestanden en IOMETER) mogelijk. Omdat we een groep hebben met drievoudige pariteit (RAID-60P), betekent dit dat het systeem bestand moet zijn tegen het falen van drie schijven, en na het falen moet automatische vervanging werken, één schijf moet de plaats innemen van een van de defecte schijven in de RDG, en de wederopbouw moet daar beginnen.
Beginnen. Laten we eerst via de opslaginterface de schijven markeren die we eruit willen halen (om de autochange-schijf niet te missen en eruit te halen).
We controleren de indicatie op de hardware. Alles is in orde, we zien drie gemarkeerde schijven.
En we halen deze drie schijven eruit.
Laten we eens kijken wat er op de host staat. En daar... gebeurde er niets bijzonders.
De kopieerindicatoren (ze zijn hoger dan in het begin, omdat de cache is opgewarmd) en IOMETER veranderen niet veel bij het verwijderen van de schijven en het starten van het opnieuw opbouwen (binnen 5-10%).
Laten we eens kijken wat er op het opslagsysteem staat.
Aan de status van de groep zien we dat het herstructureringsproces is begonnen en bijna voltooid is.
In het RDG-skelet kun je zien dat 2 schijven in de rode status staan en dat er al één is vervangen. De autoreplacement-schijf is er niet meer; deze heeft de derde defecte schijf vervangen. Het opnieuw opbouwen duurde enkele minuten, het schrijven van bestanden wanneer drie schijven uitvielen werd niet onderbroken en de I/O-prestaties veranderden niet veel.
De schijffouttest is zeker geslaagd met succes.
Conclusie
Op dit punt hebben we besloten het geweld tegen opslagsystemen te stoppen. Laten we het samenvatten:
- Foutcontrole FC-poort - succesvol
- Foutcontrole Ethernet-poort - succesvol
- Controle fout controller - succesvol
- Test stroomuitval - succesvol
- Schijffout in grouppool controleren - succesvol
Geen van de fouten stopte met opnemen of veroorzaakte fouten in de synthetische belasting; natuurlijk was er een prestatiehit (en we weten hoe we die moeten overwinnen, wat we binnenkort zullen doen), maar aangezien dit seconden zijn, is het heel acceptabel. Conclusie: de fouttolerantie van alle componenten van het AERODISK-opslagsysteem werkte op hetzelfde niveau, er waren geen faalpunten.
Uiteraard kunnen we in één artikel niet alle faalscenario’s testen, maar we hebben geprobeerd de meest populaire te behandelen. Stuur daarom uw commentaar, suggesties voor toekomstige publicaties en uiteraard adequate kritiek. We bespreken het graag (of beter nog, kom naar de training, ik dupliceer het schema voor het geval dat)! Tot nieuwe testen!
- Nizhny Novgorod (REEDS GEOPEND – u kunt zich hier aanmelden );
Tot 16 april 2019 kun je op elk werktijdstip terecht in het centrum en op 16 april 2019 wordt er een grote training georganiseerd. - Krasnodar (BINNENKORT GEOPEND - u kunt zich hier aanmelden );
Van 9 april tot en met 25 april 2019 kun je op elk werktijdstip terecht in het centrum en op 25 april 2019 wordt er een grote training georganiseerd. - Yekaterinburg (BINNENKORT GEOPEND, volg de informatie op onze website of op Habré);
Mei-juni 2019. - Novosibirsk (volg de informatie op onze website of op Habré);
oktober 2019 - Krasnoyarsk (volg de informatie op onze website of op Habré);
november 2019.
Bron: www.habr.com