Hei kaikki! Tällä artikkelilla AERODISK avaa Habrén blogin. Hurraa, toverit!
Habrén aiemmissa artikkeleissa käsiteltiin tallennusjärjestelmien arkkitehtuuria ja peruskonfiguraatiota koskevia kysymyksiä. Tässä artikkelissa käsittelemme kysymystä, jota ei ole aiemmin käsitelty, mutta jota kysytään usein - AERODISK ENGINE -tallennusjärjestelmien vikasietoisuudesta. Tiimimme tekee kaikkensa varmistaakseen, että AERODISK-tallennusjärjestelmä lakkaa toimimasta, ts. rikkoa se.
Sattui niin, että Habressa roikkuu jo artikkeleita yrityksemme historiasta, tuotteistamme sekä esimerkki onnistuneesta toteutuksesta, jota varten Suuri kiitos kumppaneillemme - TS Solution- ja Softline-yrityksille.
Siksi en harjoita täällä copy-paste-hallintataitoja, vaan annan vain linkkejä näiden artikkeleiden alkuperäisiin:
Haluan myös kertoa hyviä uutisia. Mutta aloitan tietysti ongelmasta. Nuorena myyjänä joudumme muiden kustannusten lisäksi jatkuvasti sen tosiasian kanssa, että monet insinöörit ja järjestelmänvalvojat eivät yksinkertaisesti tiedä, miten varastojärjestelmäämme käytetään oikein.
On selvää, että useimpien tallennusjärjestelmien hallinta näyttää pääkäyttäjän näkökulmasta suunnilleen samalta, mutta jokaisella valmistajalla on omat ominaisuutensa. Ja emme ole tässä poikkeus.
Siksi IT-asiantuntijoiden kouluttamisen yksinkertaistamiseksi päätimme omistaa tämän vuoden ilmaiselle koulutukselle. Tätä varten avaamme monissa Venäjän suurissa kaupungeissa AERODISK-osaamiskeskusten verkoston, jossa kuka tahansa kiinnostunut tekninen asiantuntija voi suorittaa kurssin täysin ilmaiseksi ja saada todistuksen AERODISK ENGINE -tallennusjärjestelmien hallinnoinnista.
Jokaiseen osaamiskeskukseen asennamme AERODISK-tallennusjärjestelmästä täyden demojalustan ja fyysisen palvelimen, jolla opettajamme suorittaa kasvokkain koulutusta. Julkaisemme osaamiskeskusten työaikataulun niiden ilmestyessä, mutta olemme jo avanneet keskuksen Nižni Novgorodissa ja Krasnodarin kaupunki on seuraavana. Voit ilmoittautua koulutukseen alla olevien linkkien kautta. Tässä tällä hetkellä tiedossa olevat tiedot kaupungeista ja päivämääristä:
- Nizhny Novgorod (JO AVOIN - voit ilmoittautua tästä );
16 asti keskuksessa voi vierailla mihin tahansa työaikaan ja 2019 järjestetään laaja koulutus. - Krasnodar (AVAA PIAN - voit ilmoittautua tästä );
9.-25 keskuksessa voi vierailla mihin tahansa työaikaan ja 2019 järjestetään laaja koulutus. - Jekaterinburg (AVAA PIAN, seuraa tietoja verkkosivuillamme tai Habressa);
Touko-kesäkuu 2019. - Novosibirsk (seuraa verkkosivuillamme tai Habrén tietoja);
lokakuuta 2019 - Krasnojarskin (seuraa verkkosivuillamme tai Habrén tietoja);
marraskuuta 2019.
Ja tietysti, jos Moskova ei ole kaukana sinusta, voit milloin tahansa vierailla toimistossamme Moskovassa ja suorittaa samanlaisen koulutuksen.
Kaikki. Markkinointi on valmis, siirrytään teknologiaan!
Julkaisemme Habrella säännöllisesti teknisiä artikkeleita tuotteistamme, kuormitustesteistä, vertailuista, käyttöominaisuuksista ja mielenkiintoisista toteutuksista.
AERODISK ENGINE N2 -tallennusjärjestelmän törmäystestit, lujuustesti
VAROITUS! Artikkelin lukemisen jälkeen voit sanoa: no, tietenkin, myyjä tarkistaa itsensä, jotta kaikki toimii "räjähdysmäisesti", kasvihuoneolosuhteet jne. Vastaan: ei mitään sellaista! Toisin kuin ulkomaiset kilpailijamme, olemme täällä, lähellä sinua, ja voit aina tulla meille (Moskovaan tai mihin tahansa keskuskomiteaan) testaamaan varastojärjestelmäämme millä tahansa tavalla. Siksi meidän ei ole kovin järkevää mukauttaa tuloksia ihanteelliseen maailmakuvaan, koska Meidän on erittäin helppo tarkistaa. Niille, jotka ovat liian laiskoja lähtemään ja joilla ei ole aikaa, voimme järjestää etätestauksen. Meillä on erityinen laboratorio tätä varten. Ota meihin yhteyttä.
ACHTUNG-2! Tämä testi ei ole kuormitustesti, koska tässä välitämme vain vikasietoisuudesta. Parin viikon kuluttua valmistelemme tehokkaamman osaston ja suoritamme tallennusjärjestelmän kuormitustestauksen, julkaisemme tulokset täällä (muuten testipyyntöjä otetaan vastaan).
Joten mennään rikkomaan se.
Testiteline
Osastomme koostuu seuraavista laitteistoista:
- 1 x Aerodisk Engine N2 -tallennusjärjestelmä (2 ohjainta, 64 Gt välimuisti, 8xFC-porttia 8Gb/s, 4xEthernet-porttia 10Gb/s SFP+, 4xEthernet-porttia 1Gb/s); Seuraavat levyt on asennettu tallennusjärjestelmään:
- 4 x SAS SSD -levyt 900 Gt;
- 12 x SAS 10k -levyä 1,2 TB;
- 1 x fyysinen palvelin Windows Server 2016:lla (2xXeon E5 2667 v3, 96GB RAM, 2xFC-portit 8Gb/s, 2xEthernet-portit 10Gb/s SFP+);
- 2 x SAN 8G -kytkin;
- 2 x LAN 10G -kytkin;
Yhdistimme palvelimen tallennusjärjestelmään kytkimillä sekä FC:n että 10G Ethernetin kautta. Telinekaavio on alla.
Tarvitsemme komponentit, kuten MPIO ja iSCSI Initiator, asennetaan Windows Serveriin.
Vyöhykkeet konfiguroidaan FC-kytkimille, vastaavat VLAN-verkot konfiguroidaan LAN-kytkimille ja MTU 9000 on asennettu tallennusportteihin, kytkimiin ja isäntään (kaiken tämän tekeminen on kuvattu dokumentaatiossamme, joten emme kuvaile tämä prosessi täällä).
Testausmenetelmä
Törmäystestisuunnitelma on seuraava:
- FC- ja Ethernet-porttien vikojen tarkistaminen.
- Virtakatkon tarkistus.
- Ohjaimen vian tarkistus.
- Tarkistetaan levyvirheitä ryhmässä/poolissa.
Kaikki testit suoritetaan synteettisissä kuormitusolosuhteissa, jotka luomme IOMETER-ohjelmalla. Samanaikaisesti suoritamme samat testit, mutta olosuhteissa, joissa kopioidaan suuria tiedostoja tallennusjärjestelmään.
IOmeterin konfiguraatio on seuraava:
- Lue/kirjoita – 70/30
- Lohko – 128k (päätimme pestä varastojärjestelmät isoissa lohkoissa)
- Kierteiden määrä – 128 (joka on hyvin samanlainen kuin tuotantokuorma)
- Full Random
- Työntekijöiden määrä – 4 (2 FC:lle, 2 iSCSI:lle)
Testillä on seuraavat tavoitteet:
- Varmista, että synteettinen lataus- ja kopiointiprosessi ei keskeydy tai aiheuta virheitä erilaisissa vikatilanteissa.
- Varmista, että porttien, ohjaimien jne. vaihtoprosessi on riittävän automatisoitu eikä vaadi järjestelmänvalvojan toimenpiteitä vikojen sattuessa (eli vikatilanteiden aikana emme tietenkään puhu failbackistä).
- Varmista, että lokien tiedot näkyvät oikein.
Isäntä- ja tallennusjärjestelmän valmistelu
Määritimme tallennusjärjestelmän eston käytön FC- ja Ethernet-porttien (vastaavasti FC ja iSCSI) avulla. TS Solutionin kaverit kuvasivat yksityiskohtaisesti, kuinka tämä tehdään edellisessä artikkelissa (). Ja tietenkään kukaan ei peruuttanut oppaita ja kursseja.
Perustimme hybridiryhmän, jossa käytimme kaikkia käytössämme olevia asemia. 2 SSD-levyä lisättiin välimuistiin, 2 SSD-levyä lisättiin lisätallennustasoksi (Online-taso). Ryhmittelimme 12 SAS10k-asemaa RAID-60P:hen (kolminkertainen pariteetti) tarkistaaksemme kolmen ryhmän aseman vian kerralla. Yksi levy jäi automaattiseen vaihtoon.
Yhdistimme kaksi LUN:ia (yksi FC:n kautta, toisen iSCSI:n kautta).
Molempien LUN-tunnusten omistaja on Engine-0-ohjain
Aloitetaan testi
Otamme IOMETERin käyttöön yllä olevalla konfiguraatiolla.
Tallennamme suorituskyvyn 1.8 Gt/s ja latenssin 3 millisekuntia. Ei virheitä (Total Error Count).
Samanaikaisesti aloitamme isäntämme paikalliselta asemalta C rinnakkain kahden suuren 100 Gt:n tiedoston kopioimisen FC- ja iSCSI-tallennus-LUN:iin (Windowsissa E- ja G-asemat) käyttämällä muita rajapintoja.
Yllä on kopiointiprosessi LUN FC:hen, alla iSCSI:hen.
Testi #1: I/O-porttien poistaminen käytöstä
Lähestymme tallennusjärjestelmää takaapäin))) ja vedämme kevyellä käden liikkeellä kaikki FC- ja Ethernet 10G -kaapelit ulos Engine-0-ohjaimesta. Ihan kuin siivooja, jolla oli moppi, olisi kävellyt ohi ja päättänyt pestä lattian juuri siellä, missä räkä ja kaapelit makasivat (eli ohjain toimii edelleen, mutta I/O-portit ovat kuolleet).
Katsotaanpa IOMETERia ja tiedostojen kopioimista. Suorituskyky putosi 0,5 Gt/s, mutta palasi nopeasti aikaisemmalle tasolle (noin 4-5 sekunnissa). Virheitä ei ole.
Tiedostojen kopiointi ei ole pysähtynyt, nopeudessa on laskua, mutta se ei ole ollenkaan kriittinen (840 MB/s putosi 720 MB/s). Kopiointi ei ole pysähtynyt.
Katsomme tallennusjärjestelmän lokeja ja näemme viestin porttien epäkäytettävyydestä ja ryhmän automaattisesta siirrosta.
Tietopaneeli kertoo myös, että kaikki ei ole kovin hyvin FC-porttien kanssa.
Tallennusjärjestelmä selvisi I/O-porttien viasta onnistuneesti.
Testi nro 2. Tallennusohjaimen poistaminen käytöstä
Melkein välittömästi (kun kaapelit oli kytketty takaisin säilytysjärjestelmään) päätimme lopettaa säilytysjärjestelmän vetämällä ohjaimen ulos rungosta.
Taas lähestymme säilytysjärjestelmää takaapäin (tykkäsimme siitä))) ja tällä kertaa vedämme ulos Engine-1-ohjaimen, joka tällä hetkellä on RDG:n (johon ryhmä muutti) omistaja.
IOmeterissä tilanne on seuraava. I/O pysähtyi noin 5 sekunniksi. Virheitä ei kerry.
Viiden sekunnin kuluttua I/O jatkui suunnilleen samalla suorituskyvyllä, mutta 5 millisekunnin viiveillä (latenssit korjattu noin muutaman minuutin kuluttua). Kuten kuvakaappauksista näkyy, virheiden kokonaismäärä on 35, eli kirjoitus- tai lukuvirheitä ei ollut.
Katsotaanpa tiedostojemme kopioimista. Kuten näette, se ei keskeytynyt, suorituskyvyssä oli pieni lasku, mutta kaiken kaikkiaan kaikki palasi samaan ~ 800 MB/s.
Menemme tallennusjärjestelmään ja näemme tietopaneelissa kirouksen, että Engine-1-ohjain ei ole käytettävissä (tietenkin tapimme sen).
Näemme myös samanlaisen merkinnän lokeissa.
Myös tallennusohjain selvisi vioista onnistuneesti.
Testi nro 3: Virransyötön irrottaminen.
Varmuuden vuoksi aloimme kopioida tiedostoja uudelleen, mutta emme lopettaneet IOMETERia.
Vedämme virtalähteen.
Tietopaneelin tallennusjärjestelmään on lisätty toinen hälytys.
Myös anturivalikossa näemme, että irrotettuun virtalähteeseen liittyvät anturit ovat muuttuneet punaisiksi.
Säilytysjärjestelmä toimii edelleen. Virtalähteen vika ei millään tavalla vaikuta tallennusjärjestelmän toimintaan, isännän näkökulmasta kopiointinopeus ja IOMETER-indikaattorit säilyivät ennallaan.
Sähkökatkostesti läpäissyt onnistuneesti.
Ennen viimeistä testiä päätimme herättää säilytysjärjestelmän hieman henkiin, laittaa takaisin ohjaimen ja virtalähteen sekä myös kaapelit kuntoon, mistä tallennusjärjestelmä iloisesti ilmoitti vihreillä kuvakkeilla terveyspaneelissaan. .
Testi nro 4. Kolmen levyn epäonnistuminen ryhmässä
Ennen tätä testiä suoritimme lisävalmisteluvaiheen. Tosiasia on, että ENGINE-tallennusjärjestelmä tarjoaa erittäin hyödyllisen asian - erilaisia uudelleenrakennuskäytäntöjä. TS Solution kirjoitti tästä ominaisuudesta aiemmin, mutta muistetaanpa sen ydin. Tallennuksen järjestelmänvalvoja voi määrittää resurssien allokoinnin prioriteetin uudelleenrakennuksen aikana. Joko I/O-suorituskyvyn suuntaan, toisin sanoen uudelleenrakentaminen kestää kauemmin, mutta suorituskyvyn heikkenemistä ei tapahdu. Tai jälleenrakennusnopeuden suuntaan, mutta tuottavuus heikkenee. Tai tasapainoinen vaihtoehto. Koska tallennussuorituskyky levyryhmän uudelleenmuodostuksen aikana on aina järjestelmänvalvojan päänsärky, testaamme käytäntöä, joka on vinoutunut I/O-suorituskykyyn ja jälleenrakennusnopeuden kustannuksella.
Tarkastetaan nyt levyvirheitä. Mahdollistamme myös tallennuksen LUN:iin (tiedostot ja IOMETER). Koska meillä on ryhmä, jolla on kolminkertainen pariteetti (RAID-60P), tämä tarkoittaa, että järjestelmän on kestettävä kolmen levyn vika ja vian jälkeen automaattisen vaihdon on toimittava, yhden levyn tulee korvata yksi epäonnistuneista. RDG:ssä, ja jälleenrakentaminen on aloitettava siitä.
Alkaa. Korostetaan ensin tallennusrajapinnan kautta levyt, jotka haluamme vetää ulos (jotta emme missaa ja vedä vuorottelulevyä).
Tarkistamme laitteiston merkinnät. Kaikki on kunnossa, näemme kolme korostettua levyä.
Ja vedämme nämä kolme levyä ulos.
Katsotaanpa, mitä isännässä on. Ja siellä... mitään erikoista ei tapahtunut.
Kopiointiindikaattorit (ne ovat korkeammat kuin alussa, koska välimuisti on lämmennyt) ja IOMETER eivät juurikaan muutu levyjä irrotettaessa ja uudelleenmuodostusta käynnistettäessä (5-10 % sisällä).
Katsotaanpa, mitä tallennusjärjestelmässä on.
Konsernin asemassa näemme, että uudelleenjärjestelyprosessi on alkanut ja se on lähellä valmistumista.
RDG-rungossa näet, että 2 levyä on punaisessa tilassa ja yksi on jo vaihdettu. Automaattinen vaihtolevy ei ole enää siellä; se korvasi kolmannen epäonnistuneen levyn. Uudelleenrakennus kesti useita minuutteja, tiedostojen kirjoittaminen, kun 3 levyä epäonnistui, ei keskeytynyt, eikä I/O-suorituskyky muuttunut paljon.
Levyvirhetesti meni ehdottomasti läpi onnistuneesti.
Johtopäätös
Tässä vaiheessa päätimme lopettaa tallennusjärjestelmiin kohdistuvan väkivallan. Tehdään yhteenveto:
- FC-porttivirheen tarkistus - onnistui
- Ethernet-portin virheen tarkistus - onnistui
- Ohjaimen vian tarkistus - onnistui
- Virtakatkostesti - Onnistui
- Tarkistetaan levyvirhettä ryhmäpoolissa - onnistui
Yksikään epäonnistumisista ei lopettanut tallennusta tai aiheuttanut virheitä synteettisessä kuormassa; tottakai oli suorituskykyhitti (ja tiedämme kuinka voittaa se, minkä teemme pian), mutta ottaen huomioon, että nämä ovat sekunteja, se on melko hyväksyttävää. Johtopäätös: AERODISK-tallennusjärjestelmän kaikkien komponenttien vikasietoisuus toimi tasolla, vikapisteitä ei ollut.
Ilmeisesti yhdessä artikkelissa emme voi testata kaikkia epäonnistumisskenaarioita, mutta yritimme kattaa suosituimmat. Lähetä siis kommenttejasi, ehdotuksiasi tulevia julkaisuja varten ja tietysti riittävästi kritiikkiä. Keskustelemme mielellämme (tai vielä parempaa, tule koulutukseen, kopioin aikataulun varmuuden vuoksi)! Uusiin kokeisiin asti!
- Nizhny Novgorod (JO AVOIN - voit ilmoittautua tästä );
16 asti keskuksessa voi vierailla mihin tahansa työaikaan ja 2019 järjestetään laaja koulutus. - Krasnodar (AVAA PIAN - voit ilmoittautua tästä );
9.-25 keskuksessa voi vierailla mihin tahansa työaikaan ja 2019 järjestetään laaja koulutus. - Jekaterinburg (AVAA PIAN, seuraa tietoja verkkosivuillamme tai Habressa);
Touko-kesäkuu 2019. - Novosibirsk (seuraa verkkosivuillamme tai Habrén tietoja);
lokakuuta 2019 - Krasnojarskin (seuraa verkkosivuillamme tai Habrén tietoja);
marraskuuta 2019.
Lähde: will.com