Pozdravljeni vsi skupaj! S tem člankom AERODISK odpira blog na Habréju. Hura, tovariši!
Prejšnji članki na Habréju so obravnavali vprašanja o arhitekturi in osnovni konfiguraciji sistemov za shranjevanje. V tem članku bomo obravnavali vprašanje, ki prej ni bilo obravnavano, a se pogosto postavlja - o toleranci napak sistemov za shranjevanje AERODISK ENGINE. Naša ekipa bo naredila vse, da sistem za shranjevanje AERODISK preneha delovati, t.j. polomi.
Tako se je zgodilo, da na Habréju že visijo članki o zgodovini našega podjetja, o naših izdelkih, pa tudi o primeru uspešne izvedbe, za kar Najlepša hvala našim partnerjem - podjetjema TS Solution in Softline.
Zato tukaj ne bom uril veščin upravljanja kopiraj in prilepi, ampak bom le ponudil povezave do izvirnikov teh člankov:
Želim deliti tudi dobro novico. Začel pa bom seveda s problemom. Kot mlad prodajalec se poleg ostalih stroškov nenehno soočamo z dejstvom, da veliko inženirjev in skrbnikov preprosto ne zna pravilno upravljati našega skladiščnega sistema.
Jasno je, da je upravljanje večine sistemov za shranjevanje z vidika skrbnika videti približno enako, vendar ima vsak proizvajalec svoje značilnosti. In tu nismo izjema.
Zato smo se za poenostavitev naloge usposabljanja informatikov odločili, da letošnje leto posvetimo brezplačnim izobraževanjem. Da bi to naredili, v mnogih velikih mestih Rusije odpiramo mrežo kompetenčnih centrov AERODISK, v katerih se lahko vsak zainteresirani tehnični strokovnjak popolnoma brezplačno udeleži tečaja in prejme certifikat za upravljanje sistemov za shranjevanje AERODISK ENGINE.
V vsakem kompetenčnem centru bomo namestili polno demo stojalo iz skladiščnega sistema AERODISK in fizični strežnik, na katerem bo naš učitelj izvajal usposabljanje iz oči v oči. Urnik dela kompetenčnih centrov bomo objavili, ko se bodo pojavili, vendar smo že odprli center v Nižnem Novgorodu, sledi mesto Krasnodar. Na izobraževanje se lahko prijavite na spodnjih povezavah. Tukaj so trenutno znani podatki o mestih in datumih:
- Nižni Novgorod (ŽE ODPRTO – prijavite se lahko tukaj );
Do 16. aprila 2019 lahko center obiščete ob katerem koli delovnem času, 16. aprila 2019 pa bo organizirano veliko izobraževanje. - Krasnodar (KMALU ODPRTO - prijavite se lahko tukaj );
Od 9. aprila do 25. aprila 2019 lahko center obiščete ob katerem koli delovnem času, 25. aprila 2019 pa bo organizirano veliko izobraževanje. - Jekaterinburg (ODPRTO KMALU, spremljajte informacije na naši spletni strani ali na Habréju);
maj-junij 2019. - Novosibirsk (sledite informacijam na naši spletni strani ali na Habréju);
oktober 2019. - Krasnoyarsk (sledite informacijam na naši spletni strani ali na Habréju);
november 2019.
In seveda, če Moskva ni daleč od vas, potem lahko kadar koli obiščete našo pisarno v Moskvi in opravite podobno usposabljanje.
Vse. Končali smo z marketingom, pojdimo k tehnologiji!
Na Habréju bomo redno objavljali tehnične članke o naših izdelkih, obremenitvenih testih, primerjavah, značilnostih uporabe in zanimivih izvedbah.
Crash testi sistema za shranjevanje AERODISK ENGINE N2, test trdnosti
OPOZORILO! Ko preberete članek, lahko rečete: no, seveda se bo prodajalec sam preveril, ali vse deluje "z udarcem", pogoji v rastlinjaku itd. Odgovoril bom: nič takega! Za razliko od naših tujih konkurentov se nahajamo tukaj, blizu vas, in vedno lahko pridete k nam (v Moskvi ali katerem koli Centralnem komiteju) in na kakršen koli način preizkusite naš skladiščni sistem. Tako nima velikega smisla, da rezultate prilagajamo idealni sliki sveta, ker Zelo enostavno smo preveriti. Za tiste, ki ste preleni in nimate časa, lahko organiziramo testiranje na daljavo. Za to imamo poseben laboratorij. Kontaktiraj nas.
ACHTUNG-2! Ta test ni test obremenitve, ker tukaj nas zanima le toleranca napak. V nekaj tednih bomo pripravili zmogljivejše stojalo in izvedli obremenitveno testiranje pomnilniškega sistema, rezultate pa bomo objavili tukaj (mimogrede, zahteve za teste sprejemamo).
Torej, pojdimo ga zlomiti.
Testno stojalo
Naše stojalo je sestavljeno iz naslednje strojne opreme:
- 1 x Aerodisk Engine N2 sistem za shranjevanje (2 krmilnika, 64GB predpomnilnika, 8xFC portov 8Gb/s, 4xEthernet portov 10Gb/s SFP+, 4xEthernet portov 1Gb/s); V sistemu za shranjevanje so nameščeni naslednji diski:
- 4 x SAS SSD diski 900 GB;
- 12 x SAS 10k diskov 1,2 TB;
- 1 x Fizični strežnik z Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC porta 8Gb/s, 2xEthernet porta 10Gb/s SFP+);
- 2 x SAN 8G stikalo;
- 2 x stikalo LAN 10G;
Strežnik smo povezali s sistemom za shranjevanje prek stikal prek FC in 10G Etherneta. Diagram stojala je spodaj.
Komponente, ki jih potrebujemo, kot sta MPIO in iSCSI iniciator, so nameščene na Windows Server.
Območja so konfigurirana na stikalih FC, ustrezni VLAN so konfigurirani na stikalih LAN, MTU 9000 pa je nameščen na vratih za shranjevanje, stikalih in gostitelju (kako vse to narediti je opisano v naši dokumentaciji, zato ne bomo opisovali ta postopek tukaj).
Metodologija testiranja
Načrt preizkusa trčenja je naslednji:
- Preverjanje okvare vrat FC in Ethernet.
- Preverjanje izpada električne energije.
- Preverjanje okvare krmilnika.
- Preverjanje okvare diska v skupini/bazenu.
Vsi testi bodo izvedeni v pogojih sintetične obremenitve, ki jih bomo generirali s programom IOMETER. Vzporedno bomo izvedli iste teste, vendar pod pogoji kopiranja velikih datotek v sistem za shranjevanje.
Konfiguracija IOmeter je naslednja:
- Branje/pisanje – 70/30
- Blok – 128k (odločili smo se za pranje skladiščnih sistemov v velikih blokih)
- Število niti - 128 (kar je zelo podobno produktivni obremenitvi)
- Polno naključno
- Število delavcev – 4 (2 za FC, 2 za iSCSI)
Test ima naslednje cilje:
- Zagotovite, da proces sintetičnega nalaganja in kopiranja ne bo prekinil ali povzročil napak v različnih scenarijih napake.
- Prepričajte se, da je postopek preklapljanja vrat, krmilnikov itd. dovolj avtomatiziran in ne zahteva skrbniških dejanj v primeru okvar (torej med samodejnimi preklopi, seveda ne govorimo o povratnih napakah).
- Prepričajte se, da so podatki v dnevnikih pravilno prikazani.
Priprava gostiteljskega in skladiščnega sistema
Konfigurirali smo blokiran dostop do sistema za shranjevanje z uporabo vrat FC in Ethernet (FC oziroma iSCSI). Fantje iz TS Solution so podrobno opisali, kako to storiti v prejšnjem članku (). In seveda nihče ni preklical priročnikov in tečajev.
Vzpostavili smo hibridno skupino z uporabo vseh pogonov, ki smo jih imeli. 2 SSD diska sta bila dodana v predpomnilnik, 2 SSD diska sta bila dodana kot dodatna raven shranjevanja (Online-tier). 12 pogonov SAS10k smo združili v RAID-60P (trojna pariteta), da bi preverili okvaro treh pogonov v skupini hkrati. En disk je ostal za samodejno zamenjavo.
Povezali smo dva LUN-a (enega preko FC, enega preko iSCSI).
Lastnik obeh LUN-ov je krmilnik Engine-0
Začnimo s testom
IOMETER omogočimo z zgornjo konfiguracijo.
Beležimo prepustnost 1.8 GB/s in zakasnitev 3 milisekunde. Ni napak (skupno število napak).
Istočasno z lokalnega pogona »C« našega gostitelja vzporedno začnemo kopirati dve veliki 100 GB datoteki v pomnilniške LUN-e FC in iSCSI (pogona E in G v sistemu Windows) z uporabo drugih vmesnikov.
Zgoraj je postopek kopiranja v LUN FC, spodaj v iSCSI.
Test št. 1: Onemogočanje V/I vrat
Sistemu za shranjevanje se približamo od zadaj))) in z rahlim premikom roke izvlečemo vse kable FC in Ethernet 10G iz krmilnika Engine-0. Kot da bi prišla mimo čistilka s krpo in se odločila pomiti tla prav tam, kjer so ležali smrkelj in kabli (tj. krmilnik še vedno deluje, vendar so I/O vrata mrtva).
Poglejmo IOMETER in kopiranje datotek. Prepustnost je padla na 0,5 GB/s, vendar se je hitro vrnila na prejšnjo raven (v približno 4-5 sekundah). Ni napak.
Kopiranje datotek se ni ustavilo, opaziti je upad hitrosti, a ni nič kritičnega (iz 840 MB/s je padla na 720 MB/s). Kopiranje se ni ustavilo.
Pogledamo sistemske dnevnike za shranjevanje in vidimo sporočilo o nedosegljivosti vrat in samodejni premestitvi skupine.
Informacijska plošča nam tudi pove, da s FC vrati ni vse v redu.
Sistem za shranjevanje je preživel okvaro V/I vrat uspešno.
Test št. 2. Onemogočanje krmilnika za shranjevanje
Skoraj takoj (po tem, ko smo kable priključili nazaj v sistem za shranjevanje) smo se odločili dokončati sistem za shranjevanje tako, da smo krmilnik izvlekli iz ohišja.
Spet se približamo sistemu za shranjevanje od zadaj (všeč nam je bil))) in tokrat izvlečemo krmilnik Engine-1, ki je v tem trenutku lastnik RDG (na katerega se je skupina preselila).
Situacija v IOmeter je naslednja. V/I se je ustavil za približno 5 sekund. Napake se ne kopičijo.
Po 5 sekundah se je V/I nadaljeval s približno enako prepustnostjo, vendar z zakasnitvami 35 milisekund (zakasnitve popravljene po približno nekaj minutah). Kot je razvidno iz posnetkov zaslona, je vrednost skupnega števila napak 0, kar pomeni, da ni bilo napak pri pisanju ali branju.
Oglejmo si kopiranje naših datotek. Kot lahko vidite, ni bilo prekinjeno, prišlo je do rahlega padca zmogljivosti, a na splošno se je vse vrnilo na isto ~ 800 MB/s.
Gremo v sistem za shranjevanje in na informacijski plošči vidimo prekletstvo, da krmilnik Engine-1 ni na voljo (seveda smo ga ubili).
Podoben vnos vidimo tudi v dnevnikih.
Krmilnik za shranjevanje je prav tako preživel napako uspešno.
Test št. 3: Odklop napajanja.
Za vsak slučaj smo znova začeli kopirati datoteke, vendar nismo ustavili IOMETER.
Potegnemo napajalno enoto.
V sistem za shranjevanje na informacijski plošči je bilo dodano še eno opozorilo.
Tudi v meniju senzorjev vidimo, da so senzorji, povezani z izvlečenim napajalnikom, postali rdeči.
Sistem za shranjevanje še naprej deluje. Okvara napajalne enote na noben način ne vpliva na delovanje pomnilniškega sistema, z vidika gostitelja sta hitrost kopiranja in kazalnika IOMETER ostala nespremenjena.
Preizkus izpada električne energije opravljen uspešno.
Pred zadnjim testom smo se odločili, da shrambni sistem malo oživimo, postavimo nazaj krmilnik in napajalnik ter spravimo v red kable, o čemer nas je shranjevalni sistem veselo obvestil z zelenimi ikonami v zdravstveni plošči. .
Test št. 4. Okvara treh diskov v skupini
Pred tem preizkusom smo izvedli dodatni pripravljalni korak. Dejstvo je, da sistem za shranjevanje ENGINE ponuja zelo uporabno stvar - različne politike obnove. TS Solution je o tej funkciji že pisal, vendar se spomnimo njenega bistva. Skrbnik pomnilnika lahko določi prioriteto za dodelitev virov med vnovično gradnjo. Bodisi v smeri V/I zmogljivosti, kar pomeni, da ponovna izgradnja traja dlje, vendar ni zmanjšanja zmogljivosti. Ali v smeri hitrosti obnove, vendar se bo produktivnost zmanjšala. Ali uravnotežena možnost. Ker je zmogljivost shranjevanja med vnovično izgradnjo diskovne skupine vedno glavni glavobol skrbnika, bomo preizkusili politiko s pristranskostjo V/I zmogljivosti in na račun hitrosti vnovične izdelave.
Zdaj pa preverimo, ali obstaja okvara diska. Omogočamo tudi snemanje na LUN-e (datoteke in IOMETER). Ker imamo skupino s trojno pariteto (RAID-60P), to pomeni, da mora sistem prenesti izpad treh diskov, po izpadu pa mora delovati samodejna zamenjava, en disk mora prevzeti mesto enega od okvarjenih. v RDG in na njem je treba začeti obnovo.
Začeti. Najprej prek vmesnika za shranjevanje označimo diske, ki jih želimo izvleči (da ne bi zamudili in izvlekli diska za samodejno menjavo).
Preverimo indikacijo na strojni opremi. Vse je v redu, vidimo tri označene diske.
In izvlečemo te tri diske.
Poglejmo, kaj je na gostitelju. In tam ... nič posebnega se ni zgodilo.
Indikatorji kopiranja (višji so kot na začetku, ker se je predpomnilnik segrel) in IOMETER se ob odstranitvi diskov in začetku obnove ne spremenijo veliko (znotraj 5-10%).
Poglejmo, kaj je na sistemu za shranjevanje.
V statusu skupine vidimo, da se je proces prestrukturiranja začel in bliža koncu.
V skeletu RDG vidite, da sta 2 diska v rdečem stanju, eden pa je že zamenjan. Diska za samodejno zamenjavo ni več; zamenjal je 3. okvarjeni disk. Obnovitev je trajala nekaj minut, pisanje datotek, ko so odpovedali 3 diski, ni bilo prekinjeno, zmogljivost V/I pa se ni veliko spremenila.
Test okvare diska je vsekakor uspel uspešno.
Zaključek
Na tej točki smo se odločili, da ustavimo nasilje nad skladiščnimi sistemi. Naj povzamemo:
- Preverjanje okvar vrat FC - uspešno
- Preverjanje napake ethernetnih vrat - uspešno
- Preverjanje napake krmilnika - uspešno
- Preizkus izpada napajanja - Uspešno
- Preverjanje napake diska v skupini skupin - uspešno
Nobena od okvar ni ustavila snemanja ali povzročila napak pri sintetični obremenitvi, seveda je bil udarec v zmogljivosti (in vemo, kako ga preseči, kar bomo kmalu), a glede na to, da gre za sekunde, je povsem sprejemljivo. Zaključek: toleranca napak vseh komponent sistema za shranjevanje AERODISK je delovala na ravni, ni bilo točk okvare.
Očitno v enem članku ne moremo preizkusiti vseh scenarijev napak, vendar smo poskušali zajeti najbolj priljubljene. Zato prosim za svoje pripombe, predloge za prihodnje objave in seveda ustrezne kritike. Z veseljem se bomo pogovorili (ali še bolje, pridite na trening, podvajam urnik za vsak slučaj)! Do novih testov!
- Nižni Novgorod (ŽE ODPRTO – prijavite se lahko tukaj );
Do 16. aprila 2019 lahko center obiščete ob katerem koli delovnem času, 16. aprila 2019 pa bo organizirano veliko izobraževanje. - Krasnodar (KMALU ODPRTO - prijavite se lahko tukaj );
Od 9. aprila do 25. aprila 2019 lahko center obiščete ob katerem koli delovnem času, 25. aprila 2019 pa bo organizirano veliko izobraževanje. - Jekaterinburg (ODPRTO KMALU, spremljajte informacije na naši spletni strani ali na Habréju);
maj-junij 2019. - Novosibirsk (sledite informacijam na naši spletni strani ali na Habréju);
oktober 2019. - Krasnoyarsk (sledite informacijam na naši spletni strani ali na Habréju);
november 2019.
Vir: www.habr.com