Sziasztok! Ezzel a cikkel az AERODISK blogot nyit a Habré-n. Hurrá elvtársak!
A Habréval kapcsolatos korábbi cikkek a tárolórendszerek architektúrájával és alapvető konfigurációjával kapcsolatos kérdéseket tárgyalták. Ebben a cikkben megvizsgálunk egy korábban nem tárgyalt, de gyakran feltett kérdést – az AERODISK ENGINE tárolórendszerek hibatűrésével kapcsolatban. Csapatunk mindent megtesz annak érdekében, hogy az AERODISK tárolórendszer ne működjön, pl. törd össze.
Történt ugyanis, hogy a Habrén már lógnak cikkek cégünk történetéről, termékeinkről, valamint a sikeres megvalósítás példája, amihez Köszönjük partnereinknek - a TS Solution és a Softline cégeknek.
Ezért itt nem a másolás-beillesztés kezelési készségeket fogom képezni, hanem egyszerűen hivatkozásokat adok ezen cikkek eredeti példányaihoz:
Szeretnék egy jó hírt is megosztani. De kezdem természetesen a problémával. Fiatal eladóként az egyéb költségek mellett folyamatosan szembesülünk azzal a ténnyel, hogy sok mérnök és rendszergazda egyszerűen nem tudja, hogyan kell megfelelően működtetni a tárolórendszerünket.
Nyilvánvaló, hogy a legtöbb tárolórendszer kezelése a rendszergazda szemszögéből megközelítőleg ugyanúgy néz ki, de minden gyártónak megvannak a maga sajátosságai. És itt sem vagyunk kivételek.
Ezért az informatikusok képzésének egyszerűsítése érdekében úgy döntöttünk, hogy az idei évet az ingyenes oktatásnak szenteljük. Ennek érdekében Oroszország számos nagyvárosában megnyitjuk az AERODISK kompetenciaközpontok hálózatát, ahol minden érdeklődő műszaki szakember teljesen ingyenesen részt vehet egy tanfolyamon, és bizonyítványt kaphat az AERODISK ENGINE tárolórendszerek adminisztrálásáról.
Minden Kompetencia Központba beépítünk egy teljes értékű demó állványt az AERODISK tárolórendszerből és egy fizikai szervert, amelyen tanárunk személyes oktatást tart. A Kompetencia Központok munkarendjét megjelenésükkor közzétesszük, de Nyizsnyij Novgorodban már nyitottunk egy központot, és Krasznodar város a következő. Az alábbi linkeken tudsz jelentkezni a képzésre. Itt vannak a jelenleg ismert információk a városokról és dátumokról:
- Nyizsnyij Novgorod (MÁR NYITVA – itt tudsz jelentkezni );
16. április 2019-ig bármely munkaidőben látogatható a központ, 16. április 2019-án pedig nagyszabású képzést szerveznek. - Krasnodar (HAMAROSAN NYITÁS - itt tudtok jelentkezni );
9. április 25-től április 2019-ig bármely munkaidőben látogatható a központ, 25. április 2019-én pedig nagyszabású képzést szerveznek. - Ekaterinburg (HAMAROSAN NYITÁS, kövesse a honlapunkon vagy a Habrén található információkat);
2019. május-június. - Novoszibirszk (kövesse a honlapunkon vagy a Habrén található információkat);
2019. október - Krasnoyarsk (kövesse a honlapunkon vagy a Habrén található információkat);
2019. november
És természetesen, ha Moszkva nincs messze Öntől, akkor bármikor felkeresheti moszkvai irodánkat, és részt vehet hasonló képzésen.
Minden. A marketinggel végeztünk, térjünk át a technológiára!
A Habrén rendszeresen publikálunk műszaki cikkeket termékeinkről, terhelési tesztekről, összehasonlításokról, használati jellemzőkről és érdekes megvalósításokról.
AERODISK ENGINE N2 tárolórendszer töréstesztjei, szilárdsági teszt
FIGYELEM! A cikk elolvasása után azt mondhatja: nos, természetesen az eladó ellenőrzi magát, hogy minden "durranással" működjön, üvegházi körülmények stb. Azt válaszolom: semmi ilyesmi! Külföldi versenytársainkkal ellentétben mi itt találhatóunk, közel Önhöz, és bármikor eljöhet hozzánk (Moszkvába vagy bármely Központi Bizottságba), és bármilyen módon tesztelheti tárolórendszerünket. Így nincs sok értelme, hogy az eredményeket egy ideális világképhez igazítsuk, mert Nagyon könnyű ellenőrizni minket. Azok számára, akik lusták elmenni, és nincs idejük, távoli tesztelést is szervezhetünk. Van erre egy speciális laborunk. Lépjen kapcsolatba velünk.
ACHTUNG-2! Ez a teszt nem terhelési teszt, mert itt csak a hibatűréssel foglalkozunk. Néhány héten belül elkészítjük az erősebb standot, és lefolytatjuk a tárolórendszer terhelési tesztelését, az eredményeket itt közzétesszük (egyébként tesztkéréseket elfogadunk).
Szóval, törjük meg.
Próbapad
Standunk a következő hardverekből áll:
- 1 x Aerodisk Engine N2 tárolórendszer (2 vezérlő, 64 GB gyorsítótár, 8xFC port 8Gb/s, 4xEthernet port 10Gb/s SFP+, 4xEthernet port 1Gb/s); A következő lemezek vannak telepítve a tárolórendszerbe:
- 4 db 900 GB-os SAS SSD lemez;
- 12 db SAS 10k lemez, 1,2 TB;
- 1 x fizikai szerver Windows Server 2016 rendszerrel (2xXeon E5 2667 v3, 96 GB RAM, 2xFC port 8Gb/s, 2xEthernet port 10Gb/s SFP+);
- 2 x SAN 8G kapcsoló;
- 2 x LAN 10G kapcsoló;
A szervert FC és 10G Ethernet kapcsolókon keresztül kapcsoltuk a tárolórendszerhez. Az állvány diagramja alább látható.
A szükséges összetevők, például az MPIO és az iSCSI iniciátor, telepítve vannak a Windows Server rendszeren.
A zónák az FC-kapcsolókon, a megfelelő VLAN-ok a LAN-kapcsolókon, az MTU 9000 pedig a tárolóportokon, a kapcsolókon és a gazdagépen van konfigurálva (mindennek leírása a dokumentációban található, ezért nem írjuk le ez a folyamat itt).
Vizsgálati módszertan
A törésteszt terve a következő:
- Az FC és az Ethernet portok meghibásodásának ellenőrzése.
- Áramszünet ellenőrzése.
- Vezérlő hiba ellenőrzése.
- Lemezhiba ellenőrzése egy csoportban/készletben.
Minden tesztet szintetikus terhelési körülmények között hajtunk végre, amit az IOMETER programmal generálunk. Ezzel párhuzamosan ugyanazokat a teszteket hajtjuk végre, de a nagy fájlok tárolórendszerbe másolásának feltételei mellett.
Az IOmeter konfigurációja a következő:
- Olvasás/írás – 70/30
- Blokk – 128k (úgy döntöttünk, hogy a tárolórendszereket nagy tömbökben mossuk)
- A szálak száma – 128 (ami nagyon hasonló a termelési terheléshez)
- Teljes véletlenszerű
- Dolgozók száma – 4 (2 FC, 2 iSCSI)
A tesztnek a következő céljai vannak:
- Győződjön meg arról, hogy a szintetikus betöltési és másolási folyamat nem szakad meg, és nem okoz hibákat különböző meghibásodási forgatókönyvek esetén.
- Ügyeljünk arra, hogy a portok, vezérlők stb. váltási folyamata kellően automatizált legyen, és ne igényeljen rendszergazdai beavatkozást meghibásodások esetén (tehát a feladatátvételek során természetesen nem failbackről beszélünk).
- Győződjön meg arról, hogy a naplókban szereplő információk helyesen jelennek meg.
A gazdagép és a tárolórendszer előkészítése
A blokk hozzáférést a tárolórendszeren FC és Ethernet portok (FC, illetve iSCSI) segítségével konfiguráltuk. A TS Solution srácai egy korábbi cikkben részletesen leírták, hogyan kell ezt megtenni (). És természetesen senki sem mondta le a kézikönyveket és a tanfolyamokat.
Létrehoztunk egy hibrid csoportot az összes meghajtónk felhasználásával. 2 SSD-lemez került a gyorsítótárba, 2 SSD-lemez további tárolórétegként (Online-tier). 12 SAS10k meghajtót csoportosítottunk RAID-60P-be (hármas paritás), hogy egyszerre három meghajtó meghibásodását ellenőrizhessük a csoportban. Egy lemez maradt az automatikus cserére.
Összekötöttünk két LUN-t (egyet FC-n, egyet iSCSI-n keresztül).
Mindkét LUN tulajdonosa az Engine-0 vezérlő
Kezdjük a tesztet
A fenti konfigurációval engedélyezzük az IOMETER-t.
1.8 GB/s átviteli sebességet és 3 ezredmásodperces késleltetést rögzítünk. Nincsenek hibák (Total Error Count).
Ezzel egyidejűleg a gazdagépünk helyi „C” meghajtójáról párhuzamosan elkezdünk két nagy, 100 GB-os fájl másolását FC és iSCSI tároló-LUN-okra (Windows E és G meghajtókra), más interfészek segítségével.
Fent a LUN FC-be, lent az iSCSI-be a másolási folyamat látható.
1. teszt: I/O portok letiltása
Hátulról közelítjük meg a tárolórendszert))) és egy enyhe kézmozdulattal kihúzzuk az összes FC és Ethernet 10G kábelt az Engine-0 vezérlőből. Mintha egy takarítónő ment volna el mellette felmosóval, és úgy döntött, hogy pont ott mossa a padlót, ahol a takony és a kábelek feküdtek (azaz a vezérlő még működik, de az I/O portok halottak).
Nézzük az IOMETER-t és a fájlok másolását. Az átviteli sebesség 0,5 GB/s-ra csökkent, de gyorsan (kb. 4-5 másodperc alatt) visszatért a korábbi szintre. Nincsenek hibák.
A fájlok másolása nem állt le, van sebességcsökkenés, de egyáltalán nem kritikus (840 MB/s-ról 720 MB/s-ra csökkent). A másolás nem állt le.
Megnézzük a tárolórendszer naplóit, és üzenetet látunk a portok elérhetetlenségéről és a csoport automatikus áthelyezéséről.
Az információs panelen az is kiderül, hogy az FC-portokkal nincs minden rendben.
A tárolórendszer túlélte az I/O portok meghibásodását sikeresen.
2. számú teszt. A tárolóvezérlő letiltása
Szinte azonnal (miután visszadugtuk a kábeleket a tárolórendszerbe) úgy döntöttünk, hogy befejezzük a tárolórendszert úgy, hogy kihúzzuk a vezérlőt a házból.
Ismét hátulról közelítjük meg a tárolórendszert (tetszett))), és ezúttal kihúzzuk az Engine-1 vezérlőt, amely ebben a pillanatban az RDG tulajdonosa (amelyhez a csoport költözött).
Az IOmeter helyzete a következő. Az I/O körülbelül 5 másodpercre leállt. A hibák nem halmozódnak fel.
5 másodperc elteltével az I/O körülbelül azonos átviteli sebességgel folytatódott, de 35 ezredmásodperces késleltetéssel (a késések körülbelül néhány perc után korrigálva). Ahogy a képernyőképekből is látszik, a Total error count értéke 0, vagyis nem volt sem írási, sem olvasási hiba.
Nézzük a fájljaink másolását. Amint látható, nem szakadt meg, volt egy kis teljesítménycsökkenés, de összességében minden visszatért ugyanarra a ~ 800 MB/s-ra.
Elmegyünk a tárolórendszerhez, és az információs panelen egy átkot látunk, miszerint az Engine-1 vezérlő nem elérhető (természetesen megöltük).
Hasonló bejegyzést látunk a naplókban is.
A tárolóvezérlő is túlélt egy meghibásodást sikeresen.
3. teszt: Az áramellátás leválasztása.
Minden esetre újra elkezdtük a fájlok másolását, de nem hagytuk abba az IOMETER-t.
Meghúzzuk a tápegységet.
Újabb riasztás került a tárolórendszerbe az információs panelen.
Az érzékelők menüben is azt látjuk, hogy a kihúzott tápegységhez tartozó érzékelők pirosra váltak.
A tárolórendszer tovább működik. A tápegység meghibásodása semmilyen módon nem befolyásolja a tárolórendszer működését, a gazda szemszögéből a másolási sebesség és az IOMETER jelzők változatlanok maradtak.
Az áramszünet tesztje sikeres sikeresen.
Az utolsó teszt előtt úgy döntöttünk, hogy egy kicsit újra életre keltjük a tárolórendszert, visszahelyezzük a vezérlőt és a tápegységet, valamint a kábeleket is rendbe tesszük, amiről a tárolórendszer örömmel tájékoztatott minket egészségpaneljén zöld ikonokkal. .
4. teszt. Három lemez meghibásodása egy csoportban
A teszt előtt további előkészítő lépést hajtottunk végre. A helyzet az, hogy az ENGINE tárolórendszer egy nagyon hasznos dolgot kínál – különböző újraépítési szabályzatokat. A TS Solution korábban írt erről a funkcióról, de emlékezzünk vissza a lényegére. A tárhely adminisztrátora megadhatja az erőforrás-elosztás prioritását az újraépítés során. Vagy az I/O teljesítmény irányába, vagyis az újraépítés tovább tart, de nincs teljesítménycsökkenés. Vagy az újjáépítési sebesség irányába, de a termelékenység csökkenni fog. Vagy egy kiegyensúlyozott lehetőség. Mivel a lemezcsoport-újraépítés során a tárolási teljesítmény mindig fejfájást okoz az adminisztrátornak, tesztelni fogunk egy olyan házirendet, amely az I/O-teljesítményre torzít, és az újraépítési sebesség rovására megy.
Most nézzük meg a lemezhibát. Lehetővé teszi a felvételt a LUN-okba (fájlok és IOMETER). Mivel van egy hármas paritású csoportunk (RAID-60P), ez azt jelenti, hogy a rendszernek három lemez meghibásodását kell kibírnia, és a meghibásodás után működnie kell az automatikus cserének, az egyik meghibásodott helyére egy lemeznek kell lépnie. az RDG-ben, és rajta kell kezdeni az újjáépítést.
Kezdődik. Először a tárolófelületen keresztül jelöljük ki azokat a lemezeket, amelyeket ki szeretnénk húzni (hogy ne hagyjuk ki és ne húzzuk ki az automatikus cserelemezt).
Ellenőrizzük a jelzést a hardveren. Minden rendben van, három kiemelt lemezt látunk.
És kihúzzuk ezt a három lemezt.
Nézzük meg, mi van a hoston. És ott... semmi különös nem történt.
A másolásjelzők (magasabbak, mint az elején, mert felmelegedett a gyorsítótár) és az IOMETER nem sokat változnak a lemezek eltávolításakor és az újraépítés indításakor (5-10%-on belül).
Nézzük meg, mi van a tárolórendszeren.
A csoport státuszában azt látjuk, hogy a szerkezetátalakítási folyamat elkezdődött, és közel áll a befejezéshez.
Az RDG vázban látható, hogy 2 lemez piros állapotban van, és egy már ki lett cserélve. Az automatikusan helyettesítő lemez már nincs meg, a 3. meghibásodott lemez helyére került. Az újraépítés több percet vett igénybe, a 3 lemez meghibásodása esetén a fájlok írása nem szakadt meg, és az I/O teljesítmény sem változott sokat.
A lemezhiba teszt határozottan sikeres volt sikeresen.
Következtetés
Ezen a ponton úgy döntöttünk, hogy véget vetünk a tárolórendszerek elleni erőszaknak. Összefoglaljuk:
- FC port hiba ellenőrzése - sikeres
- Ethernet port hibaellenőrzés - sikeres
- Vezérlő hibaellenőrzés - sikeres
- Áramkimaradás teszt – Sikeres
- Lemezhiba ellenőrzése a csoporttárban - sikeres
Egyik meghibásodás sem állt le a rögzítésben, nem okozott hibát a szintetikus terhelésben, természetesen volt teljesítményhiba (és tudjuk, hogyan lehet ezt leküzdeni, amit hamarosan meg is teszünk), de tekintve, hogy ezek másodpercek, ez teljesen elfogadható. Következtetés: az AERODISK tárolórendszer minden alkatrészének hibatűrése szinten működött, nem volt hibapont.
Nyilvánvaló, hogy egy cikkben nem tudjuk tesztelni az összes meghibásodási forgatókönyvet, de megpróbáltuk lefedni a legnépszerűbbeket. Ezért kérjük, küldjék el észrevételeiket, javaslataikat a jövőbeni publikációkhoz, és természetesen megfelelő kritikát. Szívesen megbeszéljük (vagy ami még jobb, gyere el az edzésre, minden esetre lemásolom az órarendet)! Új tesztekig!
- Nyizsnyij Novgorod (MÁR NYITVA – itt tudsz jelentkezni );
16. április 2019-ig bármely munkaidőben látogatható a központ, 16. április 2019-án pedig nagyszabású képzést szerveznek. - Krasnodar (HAMAROSAN NYITÁS - itt tudtok jelentkezni );
9. április 25-től április 2019-ig bármely munkaidőben látogatható a központ, 25. április 2019-én pedig nagyszabású képzést szerveznek. - Ekaterinburg (HAMAROSAN NYITÁS, kövesse a honlapunkon vagy a Habrén található információkat);
2019. május-június. - Novoszibirszk (kövesse a honlapunkon vagy a Habrén található információkat);
2019. október - Krasnoyarsk (kövesse a honlapunkon vagy a Habrén található információkat);
2019. november
Forrás: will.com