Bevezetés Ez a nehéz és hálátlan feladat a RAID-vezérlők tesztelése. A helyzetet persze némileg menti, hogy a tesztelési folyamat elég jól automatizált, de ennek ellenére az időköltségek rendkívül magasak. Az okok egyszerűek: rengeteg teszt van, és sokáig tart, ráadásul a beérkező „számjegyek” száma finoman szólva is nagy. Bárhogy is legyen, az elmúlt hat hónapban hat legújabb generációs SAS RAID vezérlő került a kezünkbe, minden nagyobb gyártótól egy-egy, és nem tudunk ellenállni annak, hogy egy összefoglaló cikkben szembetalálkozzunk velük. Sőt, most szünet van a vezérlők piacán: a meglévő modellek elég sikeresen megbirkóznak a terhelésekkel, a PCI-Express busz kiszorította a PCI-X-et a piacról, a meghajtó interfészek változása pedig a soros teljes és feltétlen győzelmével ért véget. SAS (és SATA kompatibilis) párhuzamos SCSI-n és PATA-n keresztül. Természetesen a SAS 2.0 már a láthatáron van, 3 Gb/s-ról 6 Gb/s-ra növelve a sávszélességet, de ez egyelőre csak a jövőben van, és a vezérlőgyártóknak volt idejük egy kis levegővételre. Természetesen nem pazarolják hiába - irigylésre méltó rendszerességgel adnak ki firmware-frissítéseket, eltávolítva a bosszantó hibákat és növelve a termelékenységet. Azonnal foglaljunk: a vezérlőket pontosan azzal a firmware-rel hasonlítjuk össze, amelyik a legfrissebb volt, amikor a vezérlők a kezünkbe kerültek. Lehet, hogy ez nem túl helyes, mivel az utolsó "vendégeket" valamivel előnyösebb helyzetbe hozza, de őszintén szólva nincs lehetőségünk egyszerre hat vezérlőt egyszerre tesztelni.

Mielőtt elkezdené összehasonlítani a vezérlőket, először szeretném elmagyarázni, hogy valójában milyen eredményeket várunk el tőlük. Mindenekelőtt természetesen a munka stabilitása és a maximális, lehetőleg kiszámítható eredmény. Sajnos a munka stabilitása az egyik rendkívül nehezen ellenőrizhető érték - ha a tesztpadon minden vezérlő problémamentesen működött, akkor a hálózaton olyan panaszok találhatók, amelyek a legtöbb esetben egyes kombinációk problémáihoz kapcsolódnak. vezérlők és lemezek bizonyos modelljei. Sajnos nem áll módunkban az összes lehetséges opciót tesztelni – tekintse meg a hivatalos kompatibilitási dokumentumokat vagy ... vagy folytassa a saját felelősségére. Ez persze kevés vigasz lesz a "szerencsétleneknek", de mégis: a modern vezérlők sokkal kisebb mértékben vannak kitéve megmagyarázhatatlan "hibáknak", mint elődeik. Ami a vezérlők teljesítményét illeti, van néhány pont, amit külön szeretnék megemlíteni, mivel ezekre igyekszünk rendszeresen odafigyelni.

A legegyszerűbb a RAID0 tömbökről beszélni - ez a legegyszerűbb lehetőség a vezérlők számára, csak helyesen kell megbirkóznia a terheléssel, és maximális sebességet kell mutatnia lineáris olvasásban, és másodpercenként minél több műveletet kell végrehajtania a hozzáférések véletlenszerű jellege mellett. Külön sor a többszálú betöltések és a fájlműveletek. Amint a gyakorlat azt mutatja, minden vezérlő veszít sebességéből több szálon, de nagy jelentősége van ennek a csökkenésnek. A helyzet különösen nehéz a vezérlők számára, ha a kérések minimális sormélységgel érkeznek – a legtöbb vezérlő váratlanul alacsony sebességet mutat ilyen jóindulatúnak tűnő körülmények között. Mellette a valódi fájlok sebességének problémája van - általában észrevehetően alacsonyabbak, mint a szintetikus tesztekben tapasztaltak. Néha az abszurditásig jut – a vezérlő gyorsabban tudja írni ugyanazt a fájlt vagy fájlkészletet, mint az olvasást. Ennek persze van némi érdeme a vezérlők puffermemóriájában, amely imponáló, 256 vagy akár 512 MB-ra nőtt, de mégis - minden tesztterhelésünk úgy van kiszámítva, hogy nem fér el a gyorsítótárban teljesen. Tehát a firmware-algoritmusokat továbbra is felelősnek kell tekinteni az ilyen teljesítménygyakorlatokért.

A vezérlők számára valamivel bonyolultabbak a tükrözött párokat használó tömbök: RAID1, RAID10 és RAID1E. Mellesleg, ha nem ismeri az utolsót, javasoljuk töltse ki ezt a hiányt. Számukra az összes pont érvényben marad, amiről az imént beszéltünk, és hozzáadódik néhány sajátjuk, amelyek rendkívül jellemzőek a tükrözéssel rendelkező tömbökre.

Először is, ez a vezérlő azon képessége, hogy mindkét lemezről egyszerre, tükrözött párokban olvasson adatokat. Az egyik lemezen a fej mindig kicsit közelebb lesz a kívánt szektorhoz, ami azt jelenti, hogy kicsit gyorsabban érkeznek az adatok róla. Ennek eredményeként az ezt a technológiát tökéletesen uraló vezérlő észrevehető előnnyel rendelkezik a véletlenszerű olvasásban: teljesítmény szempontjából a RAID10 tömbje nem degenerálódik feleannyi lemezről RAID0-vá, de eléggé képes kezelni a RAID0-t ugyanannyi lemezt (és néha még előzni is).

Második jellemző tulajdonság Egy dolog, amit mindig megjegyezünk, az a képesség (vagy ennek hiánya), hogy párhuzamosítsuk a lineáris olvasási terhelést egy tükrözött pár két lemezén. Ha kellően hosszú szekvenciális olvasás esetén nem egyszerű mindkét lemezről egyszerre és „szimmetrikusan” olvasni, hanem minden páros kérést az egyik lemezre, a páratlant a másikra küldeni, akkor kiváló lehetőségünk van hogy érezhető sebességnövekedést érjünk el lineáris olvasás. Általában ennek a növekedésnek a mérete nem csak a fájl méretétől függ, hanem attól is, hogy a kérések mekkora méretű blokkjaitól függenek. Természetesen nagyon szeretnénk, ha nagyobb lenne a növekedés, és kisebb lenne a szükséges blokkméret.

Végül a harmadik jellemző tulajdonság az, hogy a különböző lemezeken többszálú terhelést párhuzamosíthatunk tükrözött párokban. Ha a vezérlő képes volt felismerni a terhelés természetét, vagyis meghatározni, hogy mondjuk két lineáris folyam mit olvas ki belőle, akkor nagyon kívánatos, hogy minden adatfolyamot egy tükörpárból egy külön lemezre irányítson. Azt gondolom, nem szükséges részletesen leírni, hogy ez igen jelentős teljesítménynövekedést adhat.

Mi az eredmény? A tükrözött tömbök nem ilyen egyszerűek – a vezérlőalgoritmusoknak képesnek kell lenniük hatékonyan felismerni a terhelés természetét, és megfelelő optimalizálásokat kell alkalmazniuk, hogy teljes mértékben kielégítsék a kérésünket. És ne gondolja, hogy túl sokat akarunk - mindezek az algoritmusok körülbelül tíz éve léteznek, és megjelentek a modern szabványok szerint rendkívül gyenge processzorokkal rendelkező ATA-vezérlőkön.

Végül RAID5 és RAID6 forgó ellenőrzőösszeg tömbök. Egyrészt a vezérlők legújabb generációja sokkal könnyebben megbirkózik velük - a bennük használt modern nagy teljesítményű processzorok könnyen megbirkóznak a számítással ellenőrző összegeket, még ha nem is egy van, mint a RAID5-ben, hanem kettő, mint a RAID6-ban. Másrészt az algoritmusok hiányosságai sokkal élesebben kezdtek érezni - ha korábban az elégtelen XOR számítási sebesség hátterében rejtőztek, akkor most előtérbe kerültek. De az ilyen típusú tömbökre egyre nagyobb a kereslet – kevesen vállalják, hogy a lemezkapacitás felét elveszítik a tükrözéssel történő tömbök rendszerezéséhez, miközben lavinaszerűen nő a hibavédett tárolást igénylő információ mennyisége. A RAID6 népszerűsége meglehetősen egyszerű okoknak köszönhető. A modern tömbök egyszerűen elképesztő mennyiséget érnek el – még ha nem is veszel teljesen új meghajtókat, senki sem törődik azzal, hogy 30 TB-os tömböt építsen fel például Seagate ST31000640SS meghajtók SAS interfésszel. És ha egy ilyen tömb egyik lemeze meghibásodik, akkor egy ilyen tömb helyreállítása egyáltalán nem több órát vesz igénybe, hanem több (vagy akár tíz) napot. És annak érdekében, hogy ne kockáztassák az információkat ebben az időben (és a kockázat mértéke ebben az esetben meglehetősen magas), nem RAID5-öt, hanem RAID6-ot használnak, amely nem egy, hanem két lemez meghibásodását képes egyszerre ellenállni. Igen, a sebesség katasztrofálisan csökken, de ennek ellenére gyakran ez alkalmasabb megoldásnak bizonyul, mint a tükrözéssel ellátott tömbök használata, hiszen a felhasználható kapacitásuk ugyanannyi lemez mellett közel a fele ennek.

És mielőtt befejezném ezt az elhúzódó bevezetőt, szeretnék válaszolni egy meglehetősen népszerű kérdésre: „Érdemesek ezek a vezérlők ekkora figyelmet, ha megteheti a szilárdtestet? SSD meghajtók flash memórián, lenyűgöző teljesítményt mutatva? Igen. Az információk lemezeken való tárolásának költsége még mindig többszöröse (pontosabban egy nagyságrenddel) alacsonyabb, mint az SSD-ken. Az SSD-kötetek még mindig nagyon kicsik, ezért egy komoly rendszerhez több darabot kell venni, és ebben az esetben jobb, ha ugyanazokon a RAID-vezérlőkön keresztül csatlakoztatja őket. Igen, és ami a teljesítményt illeti, nem minden olyan egyszerű - ha a többcsatornás olvasás során (igen, a kérdezősködőknek ideje elgondolkodniuk azon, hogyan is jön létre ez a sokcsatornás) az SSD nyilvánvalóan jobb, mint bármely lemeztömb, akkor az íráshoz a lemeztömbök nem vonulnak vissza a második terv szerint. És azzal a ténnyel kombinálva, hogy az SSD-k korlátozott számú átírási művelettel rendelkeznek, ez ahhoz a tényhez vezet, hogy jobb olyan lemezalrendszert építeni, amely képes kezelni nagyszámú írási kérelmet a SAS-lemezek RAID-tömbjén. És olcsóbb és megbízhatóbb.

Teszt résztvevői

Tehát ismerkedjen meg a mai áttekintés hőseivel:

3ware 9690SA-8I egyetlen csomaggal 9.5.1
Adaptec RAID ASR-5805 5.2.0 build 16116 firmware-rel és 5.2.0.15728 illesztőprogramokkal
Areca ARC-1680ix-16 1.46-os firmware-rel és 20.0.14-es illesztőprogramokkal
HighPoint RocketRAID HPT4320 1.2.12.11 firmware-rel és 1.2.19.4 illesztőprogramokkal
LSI MegaRAID SAS 8708EM2 9.1.1-0013 firmware-rel és 2.20.0.32 illesztőprogramokkal
Ígérje meg a SuperTrak EX8650-et SR1 firmware 1.04 és SR1 illesztőprogramokkal

Ha szeretné, a linkeket követve megtekintheti az egyes vezérlők részletes áttekintését, ezért itt csak rövid általános szavakra szorítkozunk. Egyre szembetűnőbb a gyártók egységesség iránti vágya - nagy sorozatban, egyetlen kivitelben próbálnak vezérlőket gyártani, amelyek nagyjából csak a portok számában, a memória méretében és a processzor frekvenciájában térnek el egymástól. Utóbbi azonban nem sokban tér el egymástól – az itt bemutatott hat modell közül négyben Intel IOP81348 kétmagos processzor működik: az Areca, Adaptec és HighPoint vezérlők 1,2 GHz-es, a Promise pedig 800 MHz-es változatot kapott. A 3Ware és az LSI továbbra is kitart saját fejlesztései mellett: a 3ware vezérlőben 266 MHz frekvenciájú AMCC Power PC405CR, az LSI-ben pedig 500 MHz-en működő LSISAS1078 (szintén PowerPC architektúrával).

Lenyűgöző költségcsökkentés véletlen hozzáférésű memória rendszeres puffermemória növekedést okozott a vezérlőkön. Tehát csak az LSI-nek van 128 MB, a HighPointnak és a Promise-nak már 256 MB, a többinek pedig egyáltalán 512 MB.

Ráadásul az Areca vezérlőben a memória nem forrasztva, hanem külön tartóba van beépítve. Ezt a lehetőséget nem hagyhattuk ki – ez a vezérlő kétszer ment át minden teszten: 512 MB-os alapmemóriával és 2 GB-os modullal. A helyes szó, az eredmények rendkívül váratlanok voltak.

Minden vezérlő támogatja a legnépszerűbb tömbtípusok túlnyomó részét, beleértve a kétszintűeket is, mint például a RAID50. Természetesen alaposan megkeresheti a különbséget, és azt tapasztalhatja, hogy valaki tudja, hogyan kell RAID3-at, valaki pedig nem tud a RAID1E létezéséről, de nehéz komoly különbségnek számítani, mivel csak egy ember számára érdekes. rendkívül szűk felhasználói kör. Emellett mind a hat tesztalany komoly illesztőprogramokkal rendelkezik a különféle operációs rendszerekhez. Mindegyikük meglehetősen fejlett vezérlési, felügyeleti és beállítási rendszerrel büszkélkedhet az operációs rendszer alól. Mindezek a rendszerek hálózati protokollokat használnak, amelyek nemcsak a helyi, hanem a távirányítókkal is interakciót biztosítanak, azaz más gépeken találhatók. Egyébként a meglévő infrastruktúra jelenléte gyakran meghatározza a vezérlőmárka kiválasztását a következő alrendszer létrehozásakor: sokkal kényelmesebb a kényelmes és logikus központosított vezérlés, mint egyszerre több márka berendezésének támogatása. .

Az összes felsorolt vezérlő támogatja a gyorsítótár akkumulátor (BBU) telepítését – erősen javasoljuk, hogy mindig használja. Higgye el nekem, a költsége sokkal alacsonyabb, mint a tömbön tárolt információk költsége, amelyet a késleltetett írás engedélyezése esetén bármilyen áramkimaradás esetén elveszíthet. Hogy mi történik a teljesítménnyel, ha letiltjuk a késleltetett írást, láthatjuk a Promise példáján. Ebben a vezérlőben lehetetlen aktiválni a késleltetett felvételt, ha nincs akkumulátor, és ez utóbbi nem jelent meg az univerzum hátsó udvarán az elmúlt hat hónapban. Igen, ezzel vesztes helyzetbe kerül a vezérlő, de mit tehetsz.

Vizsgálati módszertan

A tesztelés során a következő programokat használtuk:

IOMeter verzió 2003.02.15;
WinBench 99-es verzió 2.0;
FC-Test verzió 1.0;

A tesztrendszer a következő volt:

Intel SC5200 ház;
alaplap Intel SE7520BD2;
két 2,8 GHz-es Intel Xeon processzor 800 MHz-es rendszerbuszon;
2 x 512 MB DDR PC3200 ECC regisztrált memória
15 GB IBM DTLA-307015 merevlemez rendszermeghajtóként;
grafikus kártya - ATI Rage XL integrált videó
operációs rendszer Microsoft Windows 2000 Professional SP4

A tesztek során a vezérlők az alaplap PCI-Express x8 foglalatába kerültek. A teszteléshez Fujitsu MBA3073RC merevlemezeket használtak, amelyeket az SC5200 ház standard szánjába szereltek, és alul négy csavarral rögzítették. Az összes vezérlőt nyolc merevlemezen tesztelték a következő módokban:

RAID0;
RAID10;
RAID5;
RAID6;

Sajnos a négylemezes tömbök eredményeit, valamint a leromlott tömbök mutatóit félre kellett tennünk - enélkül bőségesebbek lesznek az adatok.

A csíkméretet minden típusú tömbön 64 kB-ra állítottuk be.

IOMeter: Adatbázis

Mint mindig, kezdjük a vezérlő terhelése szempontjából talán a legérdekesebb teszttel - az "Adatbázis", amelynek segítségével megtudjuk, hogy a vezérlők képesek-e dolgozni a 8 KB-os blokkok olvasására és írására vonatkozó kérések folyamaival. adatok véletlenszerű címzéssel. A tesztelés során az írási kérelmek százalékos aránya következetesen nulláról száz százalékra változik (10%-os lépésekben) az összes kérés számához képest, és a parancssor mélysége 1-ről 256-ra nő.

A továbbiakban a numerikus mérési eredményeket, ha kívánja, megtalálhatja az egyes vezérlők részletes áttekintésével foglalkozó korábbi cikkekben, de mi csak grafikonokkal és diagramokkal dolgozunk.

Tehát a minimális terhelés, vagyis a kérési sor mélysége eggyel egyenlő.

Nos, úgy tűnik, honnan származhat észrevehető különbség a RAID0-ban a legegyszerűbb betöltésnél? A válasz egyszerű – késleltetett írás. Ha az összes tömb olvasáskor nagyon hasonló, akkor nagy számú írási kérés esetén az nyer, aki gyorsabban és többet tud „elrejteni” a puffermemóriában, majd gyorsan „szétszórja” azt a lemezeken. Ebben a kategóriában az Adaptec az abszolút vezető, az LSI és a Promise pedig a vesztesek közé kerül.

Hasonló képet figyelhetünk meg a RAID10 esetében is – ugyanazok a vezetők és vesztesek a terhelési zónában, nagy arányú írási kérelmekkel. Az LSI különösen rosszul érzi magát – őszintén szólva megadta magát a tiszta rekordnak.

Volt azonban különbség az olvasásban - ennek oka a sikeresebb lemez kiválasztása tükörpárokban. Ebben az esetben a HighPoint nyilvánvalóan jobbnak bizonyult, mint mások. Tiszta olvasás esetén az LSI is remek, de vegyes terhelésekkel rosszabbul bírja.

És itt jönnek a forgó paritású tömbök. Egy dolog egyetlen blokkot írni RAID0 és RAID10 tömbök esetén, és egészen más RAID5 használatakor, mert minden írási művelet valójában két blokk, két XOR művelet és két írási művelet olvassává válik. Nyilvánvalóan jobb, mint mások, ez a teszt megfelel az Adaptecnek. A 3ware vezérlő tiszta írás esetén is jó, de vegyes terhelésnél érezhetően alulmúlja a versenytársakat. De a kívülállók a HighPoint, amelynek nyilvánvaló problémái vannak a lekérdezések gyorsítótárazásával és a Promise, amely teljesen mentes a késleltetett írástól. Ez utóbbi teljesítményének katasztrofális visszaesését nehéz nem észrevenni.

Pontosan ugyanazt a helyzetet figyeljük meg a RAID6-ban, csak az abszolút értékek csökkentek, de a vezérlők viselkedése ugyanaz marad, mint a RAID5-ben. Ha a számítási algoritmushoz hozzáadunk egy második ellenőrző összeget, és felírjuk, az csökkenti a sebességet, de radikális változtatásokat már nem hajt végre, mivel a processzor teljesítménye elegendő.

De figyelmen kívül hagytuk a 2 GB telepített memóriával rendelkező Areca vezérlő viselkedését. Ez azonban nem meglepő – eredményei szinte minden esetben pontosan megismétlik az 512 MB memóriával kapott adatokat. Szóval nem lesznek sebességrekordok?

De növeljük a terhelést 16 kérésre a sorban.

A RAID0-ban a vezérlők elképesztő egyhangúságot mutatnak – a négy grafikon gyakorlatilag egybeolvad. De az Adaptec egyértelműen kiemelkedik hatékonyabb lusta írásaival. Ezt pedig képtelenség a nagyobb memória számlájára írni – a 3ware-ben és az Arecában legalább nincs kevesebb belőle (igen, a plusz 1,5 GB megint semmiben nem nyilvánul meg), utóbbiban is pontosan ugyanaz a processzor.

A vesztes ismét az LSI és a Promise, de érdemes megjegyezni, hogy a veszteség nem olyan nagy.

Hú, micsoda karakterek sokfélesége adja a lusta írási algoritmusok, a lekérdezések átrendezésének és lekérésének különféle kombinációit a legjobb lemez. A lemezen ismét "előtt a többiek előtt" az Adaptec - ez a vezérlő egyértelműen bebizonyította, hogy neki van a legjobb késleltetett felvétel. De a rögzített LSI őszintén szólva rossz – nyilvánvaló problémák vannak a gyorsítótárazással. Ez pedig aligha indokolható a jelenlévők minimális memóriamennyiségével.

De ugyanaz az LSI sikeresen versenyez a HighPointtal és a 3ware-rel a "kiváló olvasás tükörtömbökből" éremért. Ügyeljen arra, hogy mekkora a különbség e három tömb között a versenytársaktól.

Egyes vezérlők írásra, mások olvasásra szolgálnak - a szerver alrendszer tervezése rendkívül jó kezdésnek a jövőbeni terhelés jellegének meghatározásával. A 3ware azonban ebben az esetben generalistának nevezhető - eredményei folyamatosan jók a teljes tartományban.

A várakozási sor jelenléte lehetővé teszi a vezérlők számára, hogy többé-kevésbé sikeresen gyorsítótárazzák a kéréseket, vagy több műveletet hajtsanak végre egyidejűleg. Mennyire sikeres? Különböző módokon: az Adaptec jól megy, de a HighPoint majdnem kétszer olyan rossz írással birkózik meg (ne feledje, pontosan ugyanazzal a processzorral), de legalább nem hiba, mint a minimális sormélység esetén. Nos, Promise-val csak együtt lehet érezni - késleltetett felvétel nélkül rendkívül nehéz dolga van.

És ismét hasonló helyzetet látunk a RAID6 esetében. Igaz, megjelent egy érdekesség: minden kiváló teljesítménye ellenére az Adaptec mindenki mással szemben veszít az olvasási kérések elsöprő fölénye esetén. Rendszeresség vagy véletlenszerűség – nézzük a nagy terheléseket.

Sajnos az Areca 2 GB-os verziójáról gyakorlatilag nincs mit mondani - a megnövekedett memóriakapacitás egyáltalán nem nyilvánul meg. Furcsa, nagyon furcsa viselkedés.

A nehéz terhelésekkel minden vezérlő sikeresen megbirkózott, de mindegyik a maga módján. Az Adaptec továbbra is jeleskedik az írási teljesítményben, a 3ware átvette a vezetést az olvasás terén, az Areca pedig szépen becsúszott a kettő közé vegyes terhelés esetén, ami talán a legkiegyensúlyozottabb viselkedést mutatja.

Vicces, de a RAID10-es tömbök esetében is hasonló erőkiosztás alakult ki. A vezetők tábora egyáltalán nem változott, az LSI pedig kiemelkedett a többiek közül. És nem a jobb oldalon – a nagy terhelésen való írással kapcsolatos problémái a teljesítmény nagyon komoly visszaesését eredményezték minden olyan terhelésen, ahol vannak írási műveletek.

A hatalmas sormélység kíméli a Promise-t – ilyen sormélységek mellett a kérések rendezése egy része a meghajtóban történik a vezérlőbe való belépés előtt, ami lehetővé tette a vezérlő számára, hogy az eredményeket a HighPoint szintre emelje.

Az Adaptec továbbra is vezeti az írást... és ismét, mint a RAID6 esetében 16 kérésnél, nem olyan jó, elsöprő olvasási fölénnyel. Úgy tűnik, ez valóban az ő munkájának jellemzője - minden erőt a felvételbe vetnek.

A RAID6 esetében továbbra is ugyanazok a vezetők, de a HighPoint nyilvánvaló kívülállókká ereszkedett - láthatóan valami még mindig nem stimmel az algoritmusaival, valahol komoly és indokolatlan erőforrásköltségek vannak.

IOMeter: Lemez válaszidő

A válaszidő mérésére az IOMeter segítségével kéréseket küldünk a meghajtónak 512 bájtos adatblokkok olvasására vagy írására, amelyekben a kimenő kérések sormélysége tíz percig egyenértékű. A meghajtó által feldolgozott kérések száma meghaladja a hatvanezret, így a meghajtó állandó válaszidejét kapjuk, függetlenül a puffermemória méretétől.

Az olvasási válaszidő elég vicces dolog. Egyrészt nagyon röviden jellemzi a lemez alrendszer teljesítményét, pusztán ez alapján szinte lehetetlen ítéletet mondani. Másrészt ez az érték jellemzi a hajtás reakciósebességét, azt, hogy milyen gyorsan fog válaszolni egy kérésre és lehetővé teszi a rendszer számára a kapott adatok felhasználását. RAID tömbök esetén ez az érték elsősorban a használt meghajtók válaszidejétől függ. De ahogy nem nehéz belátni, ez a kontrolleren is múlik: a 3ware és az Areca, akik a legjobb címért versengenek egy kicsit, de így is felülmúlják a többieket - a legrosszabbtól (ami az Promise volt) körülbelül fél milliszekundum. Úgy tűnik, milyen apróságok, de milyen nehéz ezeket megszerezni, ez a 0,5 ms erősítés, abban az esetben, ha a válaszidő kevesebb, mint 7 ms. Akár tetszik, akár nem, ez a két kontroller a nyeremény 8%-át írta fel a számlájára.

Külön szavak érdemlik meg a HighPoint és az LSI sikerét a tükrözést használó tömbökön. A „jó” lemez páros rendkívül hatékony kiválasztásának köszönhetően ezeknek a vezérlőknek sikerült még egy ezredmásodpercet visszanyerniük. Kiváló eredmény, kiváló algoritmusok - minden más gyártónak feltétlenül figyelnie kell ezekre az eredményekre. Általában RAID10 tömböket használnak az adatbázisok tárolására, és ha az adatbázis nem fér bele teljesen a szerver RAM-jába, akkor nem szabad elhanyagolni egy ilyen kellemes lehetőséget a teljesítmény javítására.

Az írási válaszidő esetében a vezetőt meglehetősen könnyű megjósolni – természetesen az Adaptec lett a vezető, kiváló írási teljesítményt mutatva az egész "IOMeter:Database" teszt során. Apránként, de minden tömbön ez a vezérlő az, amelyik felülmúlja az azonos osztályú versenytársakat.
A HighPoint és a Promise eredményei a RAID5 és RAID6 tömbökön őszintén szomorúak – az elsőben a késleltetett írások problémái szabad szemmel láthatóak, a másodiknál pedig a hiánya szörnyű (több mint egy nagyságrendű!) növekedést eredményezett. válaszidő.

A 2 GB memóriával rendelkező Areca eredményei érdekesnek tűnnek: három esetben ismét megismétlik az 512 MB-nál kapott értékeket, de a RAID6-ban a 2 GB már érezhetően előnyösebbnek tűnik. Lehet, hogy a vezérlőnek egyszerűen nincs elegendő terhelése ugyanazon 2 GB teljes kihasználásához - bizonyos szempontból vezérlőink takarékos üzemmódban működnek, minden lemeznek külön adatcsatornája van, bővítőket nem használnak. Elképzelhető, hogy a 2 GB memória teljes erejét olyan esetekben látnánk, amikor több lemez lóg minden csatornán, és nincs elég sávszélesség mindenkinek (hidd el, a helyzet egyáltalán nem spekulatív - pontosan ez az, ami azokban az esetekben történik, amikor egy kéttucatnyi lemezes polcot egy külső csatlakozóra akasztanak). De sajnos nincs lehetőségünk tesztelni a feltételezésünket, de egyelőre a 2 GB sehogy sem mutatkozik meg.

IOMeter: Véletlenszerű olvasás és írás

Most becsüljük meg a tetszőleges címzésű vezérlők olvasási és írási módban való teljesítményének függőségét a felhasznált adatblokk méretétől.

A véletlenszerű adatcímzéssel végzett munka során kapott eredményeket két változatban vesszük figyelembe. A kis méretű blokkokon a másodpercenkénti műveletek számának függőségei épülnek fel a használt blokk méretétől. A nagy blokkokon pedig a műveletek száma helyett a megabájt/másodpercben mért sebesség számít teljesítménykritériumnak. Ez a megközelítés lehetővé teszi a tömbök munkájának értékelését két tipikus terhelési esetben egyszerre: a kis blokkokban végzett munka jellemző az adatbázisokra, és a másodpercenkénti műveletek száma fontosabb számára, mint a szokásos sebesség; de a nagy és nagyon nagy blokkok munkája közel áll igazi munka kis fájlokkal, és itt a szokásos megabájtban másodpercenkénti sebesség kerül előtérbe.

Kezdjük az olvasással.

Jó utat, szoros! Igen, a RAID0-ban nem kell nagy különbségre számítani. Ennek ellenére az Areca és a 3ware egy kicsit jobban kezeli a kis kéréseket, mint a többi.

A RAID10-ben az LSI és a HighPoint bemutatja vitathatatlan előnyét – a vezérlők tükörpárjaiból történő olvasáshoz kiváló algoritmusok nem hagynak esélyt a versenytársaknak. A többiek közül a 3ware valamivel jobb eredménnyel emelkedik ki, nyeresége pedig a felhasznált blokkok méretének növekedésével nő.

A RAID5 és RAID6 tömbök esetében ismét az összes vezérlő egy sűrű csoportot alkotott - nincs mit optimalizálni, általában tudod, hogy egyenként szedjük le az információkat a lemezekről, de nem kell emlékezni az ellenőrző összegekre.

Nagy blokkokon, még a RAID0 esetében is, észrevehető különbségek kezdenek megjelenni - a lineáris sebesség és az előzetes letöltés hatása. Ennek eredményeként az LSI átveszi a vezetést, a 3ware pedig egy kicsit le van maradva. Egyre nehezebb meghatározni a veszteseket - a HighPoint és az Areca sikertelenül teljesít több megabájtos blokkon, de aztán nagyon vidáman veszik fel a sebességet, ennek eredményeként magabiztosan előzik meg a Promise-t és az Adaptecet.

Az Areca ismét meglepetést okoz: 512 MB memóriával gyorsabban olvas, mint 2 GB-tal. Egyetlen feltételezésünk van: a gyorsítótár megnövekedett mérete növelte a keresési késéseket, ami ezt a hatást okozta. Nem teszünk úgy, mintha az igazság lenne, de egyszerűen nem látunk más magyarázatot.

A RAID10-es tömbökön viszonylag nagy blokkok olvasásakor a jó lemez kiválasztása már nem nyerő stratégia, és ennek eredményeként a vezetők változását látjuk. A 3ware került a tetejére, majd az LSI.

Őszintén kiábrándító Areca - mindkét esetben őszintén megmagyarázhatatlan sebességcsökkenést mutat. Nyilvánvalóan vannak hibák a firmware-ében, és most ezeket látjuk.

A RAID5 erőkiosztása megismétli a RAID0-ban látottakat, ami általában véve nem meglepő.

A RAID6-on sem sokat változtat, csakhogy az Adaptec nagyon nagy blokkokon kiesik az összképből, nem veszi fel elég gyorsan a sebességet.

Térjünk át a véletlenszerű címzésű műveletek írására.

És itt már tiszta formájában működik a lemez. Sőt, láthatóan az nyer, aki egyszerre tart nagy mennyiség gyorsítótárazási sorok. Ennek eredményeként az első helyen az Adaptec áll, egyértelmű előnnyel – makacsul ragaszkodik ahhoz, hogy az ő rekordja a legjobb, mint az első teszten. Az egyértelmű vesztesek az LSI és a Promise.

Érdekes módon a 2 GB-os Areca megint veszít a kevesebb memóriával rendelkező társa előtt (micsoda nyereség ott a nagyobb mennyiség miatt, mi vagy te). Ez a memóriában való bonyolultabb keresésnek is köszönhető?

Hmm, úgy tűnik, a lemezen már nem lehet a vezetőről beszélni. De a vesztesekről – még mindig megéri. Ha a Promise alacsony eredménye a lusta írás hiányával magyarázható, akkor nem tudjuk, milyen hiányosságok okoztak ilyen komoly teljesítménycsökkenést az LSI-ben a RAID10-ben.

A RAID5 és RAID6 tömbökben a vezérlők nagyon hasonlóan viselkednek. Az Adaptec egyértelműen az élen áll kis blokkokban, őt követi a 3ware lenyűgöző lemaradással. Utóbbinak egy érdekes tulajdonságát látjuk: az 512 bájtos blokkon a teljesítménye alacsonyabb, mint a 2 kB-os blokkoknál - úgy tűnik, ebben az esetben pontosan ennek a vezérlőnek a sajátos architektúrájának teljesítményhatárát látjuk. Ezek a funkciók azonban nem hasonlíthatók össze a HighPoint és a Promise problémáival. A HighPoint nem tud megbirkózni a nagyon kis blokkok írásával – ha a blokk mérete 32 kB alá csökken, a teljesítménye érezhetően csökken. A processzora megegyezik az Adaptecével – nyilvánvalóan nem az erejéről van szó. A Promise vezérlő még rosszabb - lusta írás nélkül egyszerűen lefullad az apró kérések folyamában.

A nagy blokkok rögzítésekor a karakterek pompás választékát látjuk. Mindenekelőtt az Adaptec problémáit szeretném megjegyezni, hogy ez a vezérlő mennyire jól birkózott meg a véletlenszerű címzésű kis blokkok folyamával, mint ahogy a nagy blokkok írásával is. Úgy tűnik, hogy 120 MB / s sebességkorlátozója van. Jellemzőit tekintve teljesen hozzá hasonló Areca, éppen ellenkezőleg, az első helyre tör be. Ugyanakkor ugyanaz az Areca 2 GB memóriával már érezhetően rosszabb, és úgy tűnik, a korlátozóját is megtalálta...

Végül az LSI és a Promise megmagyarázhatatlan, de szinkron sebességcsökkenést mutat az 512 kB-os blokkon. Ugyanakkor, ha a Promise akkor a blokk növelésével nagy erőkkel igyekszik utolérni a vezetőket, akkor az LSI feleslegesen szerényen viselkedik. Számunkra teljesen érthetetlen, hogy ezek a vezérlők miért tapasztalnak problémákat a teljes csíkok rögzítésekor (nyolc 64 kB-os lemezen éppen 512 kB-ot nyerünk).

Senki másnak nincs ilyen komoly problémája a RAID10-re íráskor, kivéve, hogy a Promise ismét enyhe sebességcsökkenést mutat ugyanazon a területen. Az Areca ismét vezet, és ezúttal - szinkronban, mindkét változatban.

És az ellenőrzőösszeg-rögzítéssel rendelkező tömbökön ismét zűrzavar és ingadozás tapasztalható, bár nem olyan erős. Ismét érthetetlen akadályokba ütközött az Adaptec és az Areca 2 GB memóriával, a RAID6 esetében pedig az LSI is csatlakozott hozzájuk. Észrevehetően rosszabbul teljesítik a Promise tesztet, mint a "sikeres" vezérlők (amelyek egyébként szűk csoportban vannak). A nagy blokkok írása lehetővé teszi, hogy teljes csíkokkal dolgozzon, ami némileg korrigálja a helyzetet a késleltetett írás hiányával (hadd emlékeztessem Önöket arra, hogy teljes csík írásakor az ellenőrző összeget csak egyszer számítják ki a teljes csíkra, ami drasztikusan csökkenti a rezsiköltséget), de még mindig nincs hatalmában ahhoz, hogy teljesítményét a többiek szintjén tartsa.

IOMeter: Szekvenciális olvasás és írás

Értékeljük a vezérlők képességeit szekvenciális műveletekben. Ebben a tesztben a meghajtók négyes parancssormélységű kéréseket kapnak. Percenként egyszer megnő az adatblokk mérete. Ennek eredményeként lehetőségünk nyílik nyomon követni a tömbök lineáris olvasási és írási sebességének függését a felhasznált adatblokkok méretétől, és megbecsülni az elérhető maximális sebességeket.

A RAID0 maximális olvasási sebességét a 3ware kivételével (amelynek eredményét az architektúra jellemzői egyértelműen befolyásolták) minden vezérlő ugyanazon a szinten mutatta. De most a tömbökön elérték különböző méretű: Az éllovas Areca és a HighPoint már 16 kB-os blokkon érte el, az LSI-nek 64 kB, az Adaptecnek - 128 kB, a Promise-nak pedig még 512 kB (nyolc 64 kB-os lemez teljes sávja).

A RAID10 lineáris olvasása egyértelműen demonstrálja a vezérlők azon képességét, hogy párhuzamosítsák az olvasást két tükrözött párban lévő lemezen. Senki sem tudott ideális viselkedést bemutatni, de az Areca egyértelműen jobb és gyorsabb, mint a többi ebben a tesztben (egyébként vegye figyelembe, hogy 2 GB memóriával, 512 MB-tal - ismét ugyanazokat az eredményeket látjuk). A kis méretű blokkok olvasási sebességében ismét a vezető szerephez tartozik. Az Adaptec és a HighPoint is jól teljesít, de utóbbi túlságosan válogatós a blokk méretét illetően. De a Promise, az LSI és a 3ware őszintén csalódást okoz ebben a tesztben.

Az erők elrendezése nem változik a RAID5 és RAID6 tömbökről történő olvasás során – az Adaptec mennyire megbirkózott a véletlenszerű írásokkal, az Areca és a HighPoint tökéletesen viselkedik lineáris olvasás során.

A 3ware őszintén kiábrándító - a maximális sebessége alacsonyabb, mint a többi, és a sebesség alacsony a kis blokkokon. És nagyon nagy - nyilvánvaló problémáknál.

Amikor a RAID0-ba ír, a HighPoint átveszi a vezetést. Areca közel tart, de még mindig valamivel rosszabb. Sőt, csak az 512 MB memóriával rendelkező változat – a 2 GB-os változat hirtelen veszített a sebességéből. Mi történt vele és miért nem is sejthetjük. Ugyanezek a problémák azonban az Adaptecnél is jelentkeztek - rendkívül lassan ír, mintha nem egy tömbünk lenne, hanem egyetlen lemezünk.

Az Arecának ugyanezek a problémái vannak a 2 GB memóriával és a RAID10-ben történő rögzítéssel. Az Adaptec azonban furcsán viselkedik – a kis kockákon az „átlagok” legjobbja, míg a maximális sebesség tekintetében a legjobb az összesítésben, ugyanakkor megmagyarázhatatlan sebességcsökkenést szenved a 128 kB-os blokkon. A benyomások összegét tekintve az 512 MB-os Areca jobban néz ki, mint a többi - kiváló eredményeket mutat kis blokkon, és nagyon stabil és meglehetősen nagy sebességet a nagyoknál. De a HighPoint ismét lemaradt tőle – gondok vannak a nagy blokkokon.

A RAID5-ben néhány embernek sikerült sikeres lineáris rögzítést elérnie - csak az Areca (és csak az alapmemória méretével, a 2 GB-tal ismét lenyűgöző gondok vannak) és a HighPoint kellemes a szemnek. Az LSI és a 3ware csak érezhetően lemarad a vezetők mögött, az Adaptec-nek ismét vannak gondjai, de a Promise-ról nincs mit mondani – legalábbis valami kézzelfogható sebesség csak a 128 kB-os és nagyobb blokkokon jelenik meg.

A RAID6-ban a helyzet sok tekintetben hasonló a RAID5-höz, ezért csak a főbb különbségeket említjük. Az Areca már mindkét opcióban sikeresen működik, a HighPoint hirtelen veszít a sebességéből a nagy blokkokon, és ott nagyon komoly problémák vannak az LSI-vel. Az Adaptecnél és a Promisenál még mindig minden szomorú. De ha a Promise rendkívül gyenge teljesítménye éppen a hiányzó lusta írásnak köszönhető, akkor az Adaptec-el mi történt, rejtély.

IOMeter: Többszálú olvasás és írás

Ez a teszt lehetővé teszi a vezérlők viselkedésének értékelését többszálú terhelés mellett. Ezalatt az a helyzet emulálódik, amikor egy-négy alkalmazás dolgozik a meghajtóval, és a tőlük érkező kérések száma egytől nyolcig változik, és az egyes alkalmazások címterei, amelyek szerepét az "IOMeterben" dolgozók látják el. ", ne fedjék egymást.

Mint mindig, a legleleplezőbb és legérdekesebbnek tekintjük diagramok írását és olvasását olyan helyzetekre, amelyeknél egy kérés mélysége van. Pontosan ez az a helyzet, ami valós körülmények között általában kialakul. Külön érdekesség az a tény, hogy amint azt megfigyeléseink is mutatják, nem minden vezérlő képes a maximális sebesség kimutatására a minimális sormélység mellett.

A RAID0-ban az Areca és a HighPoint egyértelműen jobb, mint a többiek egyetlen adatfolyam beolvasásában - a minimális sormélységben a veszteségeik minimálisak, ami a többiről nem mondható el. Az Adaptec és az LSI a lehetséges maximális sebességnek csak a felét, a Promise és a 3ware pedig csak a negyedét mutatja be rajtuk.

A szálak számának kettőre, háromra és négyre történő növelése egyértelműen azt mutatja, hogy két szálon minden vezérlő észrevehetően veszít sebességéből, de a jövőben nem lesz drámai változás. Általában az Areca nyerte meg ezt a tesztet – ez a vezérlő minden terhelésnél maximális sebességet mutat. De a Promise és a 3ware cégeknek nyilvánvalóan ki kell javítaniuk a helyzetet - modelljeik sebessége túl alacsony.

Egyetlen szálon a RAID10-ben ugyanaz az erőkiosztás, mint a RAID0-ban, csak az Areca fölénye a többihez képest érezhetően sokkal erősebb, mivel jobban megbirkózik a tükörpárok váltakozó olvasásával. Ugyanaz a vezérlő ismét sokkal jobb, mint mások több szál olvasásakor. És figyeljen arra, hogy a vezérlő mennyivel gyorsabban olvas két adatfolyamot - ez az, a streamek hatékony felosztása különböző lemezekre a tükrökben.

A többi közül csak az Adaptec tűnik ki tisztességes eredménnyel (sajnos csak két szállal), a HighPoint pedig három és négy olvasószálon.

A RAID5 és RAID6 tömbök olvasása nagyon hasonló: az Areca és a HighPoint jobban kezel egy adatfolyamot, mint a többi. A HighPoint egy kicsit jobban teljesít több szálon, mint mások, de általában minden tömb jól működik, kivéve a Promise és a 3ware, amelyek ismét nagyon gyenge teljesítményt mutatnak. nagy sebességek.

A RAID0-ra írással nem kevésbé mulatságos a kép: egyrészt könnyebb a többszálas írás, mivel ezt érezhetően megkönnyítik a lusta írási mechanizmusok. Másrészt, mivel nem nehéz átlátni, még egy szál rögzítése minimális sormélységgel sem egyszerű terhelés mindenkinek. Igazán nagy sebességről csak az Areca és a HighPoint beszélhet. És csak az Areca tartja fenn ugyanazt a nagy sebességet (és még egy kicsit többet is) több adatfolyamon. De már három kontroller is felzaklatott minket alacsony eredménnyel: az Adaptec és az LSI csatlakozott a Promise-hoz (a felvételen elért alacsony eredményének okai már a fogak között vannak).

Sebesség és RAID10-re írás esetén minden rendben van az Arecával. Az Adaptec ugyanilyen típusú tömbökön is javított - több szállal sikeresen versenyez az Arecával a vezető címért. A teszt vesztesei között van ismét az LSI és a Promise.

És ismét hasonló vezérlő viselkedést látunk a RAID5 és RAID6 tömbökön. Rekordonként egy adatfolyammal az Areca és a HighPoint sokkal jobban néz ki, mint a többi, de a streamek számának növekedésével az Areca nagyszerű elszigeteltségben továbbra is az élen áll. Érdekes módon ezúttal a 2 GB-os verzió nagyon más. Csak az a kár, hogy ez nem jobb - sebessége minden terhelésnél több mint kétszer alacsonyabb. Ennek ellenére az Areca furcsa viselkedést mutat a fedélzeti memória növelésekor, úgy tűnik, hogy egyszerűen nem ilyen kötetekre tervezték.

Ami a Promise eredményeit illeti, a késleltetett írásoktól mentes, nevetségesen kicsik ilyen terhelés mellett.

IOMeter: webszerver, fájlszerver és munkaállomás

Ebben a tesztcsoportban a meghajtókat kiszolgálókra és munkaállomásokra jellemző terhelés mellett tesztelik.

Hadd emlékeztesselek arra, hogy a "Webszerver" és "Fájlszerver" esetén a meghajtó működését emuláljuk a megfelelő szervereken, míg a "Workstation"-ben a meghajtó működését szimuláljuk a munkaállomásra jellemző betöltési módban, maximális várakozási sor mellett. 32 kérés mélységi határa. Természetesen a "Webszerver" és a "Fájlszerver" nem mások, mint gyűjtőnevek; az első nagyon hasonló módon emulálja bármely olyan szerver terhelését, amely valójában csak olvasási kérésekkel működik, a második pedig egy olyan szerver, amely túlnyomórészt olvasási kérelmekkel rendelkezik, de ugyanakkor bizonyos, észrevehetően nem nulla írási kérelmekkel. .

Annak érdekében, hogy ne tömítsük el a cikket nagyon őrülten sok grafikonnal, ebben a részben mindegyiket közzétettük külön oldal , és diagramok alapján fogunk beszélni.

A kizárólag (többnyire véletlenszerű) olvasási kérésekből álló terhelés esetén a tömbök túlnyomó többsége ugyanolyan jól kezelhető – a különbség mindössze 5%. Ráadásul a tömb típusa nem játszik különösebb szerepet - a RAID6 olyan gyorsan működik, mint a RAID0. De van egy jelentős kivétel: a RAID10 tömbök azokon a vezérlőkön, amelyek nagyon hatékonyan tudnak „jó” lemezt keresni tükörpárban, azaz a 3ware-en, a HighPoint-on és az LSI-n, egyértelműen termelékenyebbek.

Az írási kérések megjelenése a terhelésben már az eredmények észrevehető változatosságához vezet. Először is, a RAID5 és RAID6 kezd észrevehetően lemaradni a RAID0 és RAID10 mögött. Másodszor, a vezérlők egyéni jellemzői kezdenek hatni. Tehát a RAID10-ben továbbra is a 3ware és a HighPoint a legjobb (az LSI "kiesésének" okai egyszerűek, csak nézd meg a grafikont – ennek a vezérlőnek a teljesítménye nem növekszik egy bizonyos sormélységtől kezdve). Ahogy az várható volt, a Promise sokkal rosszabb, mint a többi az ellenőrzőösszeg-tömbök kezelésében. Ugyanezen tömbökön a HighPoint lemaradt a többi mögött.

Hasonló helyzet figyelhető meg a Workstation esetében is, de ezt tovább súlyosbítja az írási kérelmek nagy száma és a kérések nagyon eltérő mintázata a terhelésben. Ennek eredményeként az Areca átveszi a vezetést a RAID0-ban. A RAID10-ben a HighPoint és a 3ware még mindig nyilvánvalóan jobb, mint mások. Nos, a RAID5 és RAID6 esetében a HighPoint és a Promise lemaradása nagyon jelentőssé válik.

Ugyanaz a terhelés, de csak 32 GB-ra korlátozott tömbökön fut (csak a leggyorsabb lemezzónákat használják, a válaszidő minimális), jelentősen megváltoztatja az erőviszonyokat. Tehát nyilvánvaló lemaradók jelentek meg a RAID0-ban – az LSI és a Promise voltak. A RAID10-ben a 3ware és a HighPoint előnye minimálisra csökkent - a jó lemez kiválasztása gyakorlatilag már nem fontos, mert a válasz mindenhol minimális. De megjelent egy lemaradó – az ígéret ismét azzá vált. A RAID5 és RAID6 esetében az általános teljesítmény nőtt, de a HighPoint és a Promise lemaradása nem tűnt el.

FC teszt

Befejezi a mai FileCopy tesztünket. Két 32 GB-os partíció jön létre a meghajtón, amelyeket a tesztelés két szakaszában jelölnek meg, először NTFS-ben, majd FAT32-ben, majd létrejön egy bizonyos fájlkészlet a partíción, beolvassák, másolják a partíción belül, és másolják partícióról partícióra. . Mindezen műveletek ideje rögzített. Emlékezzünk vissza, hogy a "Windows" és a "Programok" készletek nagyszámú kis fájlt tartalmaznak, míg a fennmaradó három mintát ("MP3", "ISO" és "Telepítés") kisebb számú nagyobb fájl jellemzi, és a " ISO" a legnagyobb fájlokat használja.

Ne felejtsük el, hogy a másolási teszt nem csak az egyetlen meghajtón belüli másolás sebességét mutatja be, hanem lehetővé teszi annak összetett terhelés alatti viselkedésének megítélését is. Valójában a másolás során a meghajtó egyidejűleg két adatfolyammal működik, az egyik az olvasáshoz, a másik pedig az íráshoz.

Csak az „Install”, „ISO” és „Programok” fájlkészletekben elért értékeket vesszük figyelembe részletesen az NTFS-ben, amelyek jellemzőbbek a normál tömbhasználatra. A többi eredményt, ha szeretné, mindig megtudhatja a cikkekben található táblázatokban az egyes vezérlőkhöz

Az "Install" fájlok halmazának rögzítése egyértelműen két esetre osztható. A RAID0 és RAID10 tömbökön az Areca és az Adaptec nyer, míg az LSI a vesztesnek bizonyul az egészen várt Promise mellett.

A RAID5 és RAID6 tömbökön az Adaptec vezetőpárja már 3ware. Az LSI már nem olyan rossz, de a Promise őszintén tehetetlen.

Felhívjuk figyelmét, hogy az Areca 2 GB memóriával sokkal rosszabbul kezeli a fájlokat, mint az eredeti vezérlő. Csodák és még sok más.

Az Areca egyértelműen jobban megbirkózik a nagy fájlok írásával, mint mások RAID0-ban és RAID10-ben, de az ellenőrzőösszegű tömbökön a HighPoint sikeresen versenyez vele. A RAID0 kivételével minden esetben az Adaptec és az LSI eredményei csak sajnálatot okoznak - túl kicsik. Nos, az ígéretről teljesen hallgatunk - az írástesztben nincs esélye.

De a fájlok rögzítésével mindenki megközelítőleg ugyanúgy kezeli. És ugyanolyan lassú – ügyeljen arra, hogy a felvételi sebesség mennyivel csökken jelentősen, ha a fájlméretet csökkenti.

Az esetek túlnyomó többségében az „Install” vegyes készletének olvasása valamivel jobb az LSI és a HighPoint vezérlők számára. Ami a lemaradókat illeti, azok 3ware és Promise voltak (és itt már nem igazolható a hiányzó késleltetett írás).

A nagy fájlok esetében az Areca őszintén "felgyújt" - még az őt követő HighPoint is aligha nevezhető versenytársának. A RAID10 eredményei különösen figyelemre méltóak, ahol az Areca egyértelműen bemutatja, miért kell felváltva olvasni a lemezekről.

De a lemaradók továbbra is ugyanazok - 3ware és Promise, az LSI pedig őszintén gyengének tűnik RAID10-ről olvasva (megtérülés egy sikeres lemez kiváló választásáért?).

Ugyanazok a veszteseink vannak a kis fájlokban. A vezetők azonban újak: az LSI és a HighPoint küzd az első helyért.

Ha az „Install” vegyes készletét három tömbtípusra másoljuk, az Adaptec, a HighPoint és az LSI csoportja egyértelműen az élen jár. Ám a RAID10-ben az LSI kiesik a vezetők közül, de Areca belép oda, és azonnal kiesik az első helyre. A vesztes minden esetben egy - aki a késleltetett írási Ígéret hiányában szenved.

Csak két vezető van a nagy fájlokon: a HighPoint és az Areca. Ez utóbbi sokkal gyorsabb a RAID10-ben, de némileg elmarad a többi tömbtől. A többi vezérlő, hogy őszinte legyek, gyenge versenytárs.

Kis fájlok másolása a "Programok"-ban meglehetősen nehéz minden vezérlő számára. Bár az LSI és az Adaptec egy kicsit jobban néz ki, mint mások.

Összegzés

Talán ennek a tesztelésnek a fő eredménye megelégszik azzal a banális gondolattal: nincs ideális. Minden vezérlőnek megvannak a maga előnyei és hátrányai, ezért a legjobb azt feltételezni, hogy egyes vezérlők jobban megfelelnek bizonyos munkaterheléseknek, mint mások. A legfontosabb dolog az, hogy ne felejtsük el, hogy a firmware néha drasztikusan megváltoztathatja a vezérlők viselkedését. Mostantól díjakat osztunk ki, és véleményt nyilvánítunk, kizárólag azon benyomások alapján, amelyeket a vezérlők a jelenlegi firmware-en mutattak be.

Az Adaptec RAID ASR-5805 és Areca-1680x-16 hagyták magukról a legjobb benyomást. Ez a két modell ment a legstabilabban a teszteken, és ezeknél van a legkevesebb komolyabb firmware hiba. Általánosságban elmondható, hogy az Adaptec valamivel jobban alkalmas adatbázisok rendszerezésére, míg az Areca jobban kezeli a többszálas műveleteket és a fájlokkal dolgozik. Mindenesetre mindketten méltó képviselői a modern vezérlőknek. Érdekes módon valójában nagyon hasonló platformokra épülnek – ugyanaz a processzor és ugyanannyi RAM.

Igen, az Areca lehetővé teszi a memória megváltoztatását és a hangerő növelését, de tesztelésünk nem mutatott pozitív hatást ennek a műveletnek, inkább az ellenkezőjét - a 2 GB-os verzió gyakran kissé rosszabbnak bizonyult. Azonban megismételjük: lehetséges, hogy a 2 GB teljesen megmutatkozik, ha a lemezvezérlőt bővítőkkel csatlakoztatják, amikor az interfész sávszélessége már nem lesz elegendő minden lemez számára.

A 3ware 9690SA-8I és a HighPoint RocketRAID HPT4320 kissé vegyes benyomást keltett. Az első nagyon jó vezérlő lenne, de eléggé elrontja a gyenge eredmények a fájlokkal való munka során, így véleményünk szerint az adatbázisok az útja, ahol tökéletesen bebizonyítja majd, hogy kiegyensúlyozott ill. erős készülék. A másodiknak kiváló algoritmusai vannak a RAID10-nel való munkához, és nagyon jó a rekord, de még mindig túl sok probléma van a tömbökkel az ellenőrző összeg rögzítésével. Szeretném remélni, hogy a jövőben a firmware-ben megoldódnak, és a jövőben a jó vezérlők választéka eggyel több modell lesz.

Ami az LSI MegaRAID SAS 8708EM2-t és a Promise SuperTrak EX8650-et illeti, jelenlegi formájukban csalódást okoznak. Természetesen a Promise a nem működő késleltetett írás miatt valamivel nyilvánvalóan rosszabb körülmények között szerepelt tesztjeinkben, de ennek ellenére az olvasásban gyakran túl alacsony eredményeket hoz a versenytársakhoz képest. És az LSI-nek egyszerűen túl sok hiányossága van, bár a kis fájlokkal végzett munka és a sikeres lemez kiváló kiválasztása tükörpárokban lenyűgöző. De a firmware kiadásra kerül, ami azt jelenti, hogy mindenkinek van esélye. Ismét megismételjük: sok esetben bármely vállalat működő kontrollereinek meglévő infrastruktúrájának megléte sokkal fontosabb, mint a teljesítmény, kivéve, ha ez utóbbi teljesen helyrehozhatatlan módon szenved.

Egyéb anyagok ebben a témában

Areca ARC-1680ix-16 SAS RAID vezérlő tesztelése
HighPoint RocketRAID HPT4320 SAS RAID vezérlő teszt
Az LSI MegaRAID SAS 8708EM2 SAS RAID vezérlő tesztelése
Az Adaptec RAID ASR-5805 SAS RAID vezérlő tesztelése
A SAS RAID vezérlő 3ware 9690SA-8I tesztelése
Ígérje meg a SuperTrak EX8650 SAS RAID vezérlő tesztjét

nem tartalmazza.

Nagy teljesítményű 6 Gb/s 9260-8i hardveres RAID vezérlő 8 belső porttal (2x SFF8087 csatlakozó) és 512 MB beépített memóriával akár 128 SAS és SATA meghajtó csatlakoztatásához RAID technológia-chipen.

A MegaRAID SATA+SAS 9260 nagy teljesítményű termékcsalád 2880 MB/s olvasási, 1850 MB/s írási és akár 147 000 véletlen hozzáférésű IOPS adatátviteli sebességet biztosít, lehetővé téve a legigényesebb alkalmazások, például adatbázisok futtatását is. és videó feldolgozás.

Ezek a termékek 3 Gb/s és 6 Gb/s adathordozót tesznek lehetővé, mind a SATA, mind a SAS meghajtók belső támogatásával.

A szerver SATA vagy SAS meghajtóinak belső csatlakozása. Lehetővé teszi, hogy 128 eszközzel dolgozzon SAS bővítőkkel. LSI RAID-on-Chip (ROC) technológia és elsődleges PCI Express interfész nagy sávszélességű alkalmazásokhoz.

Opcionális tartalék akkumulátor, amely megakadályozza az adatvesztést szerver meghibásodása esetén.

További CacheCade, FastPath és Recovery/Snapshots szoftverek támogatása.

Főbb jellemzők

Maximális elérhető teljesítményszint: Olvasás: 2,875 MB/s, Írás: 1,850 MB/s
A PCI Express 2.0 nagyobb jelsebességet biztosít a nagy sávszélességű alkalmazásokhoz
Maximális megoldási rugalmasság 3 Gb/s és 6 Gb/s SATA és SAS meghajtó támogatással
A SafeStore Encryption technológia erősebb adatvédelmet biztosít
Az alacsony profilú MD2 kialakítás illeszkedik a kompakt 1U és 2U architektúrákba

Műszaki adatok

Paraméter	Leírás
processzor	LSISAS2108 RAID-on-Chip (ROC) 800 MHz PowerPC®
Teljesítmény	Akár 6 Gbps portonként
Interfészek	Nyolc belső SATA+SAS port Két belső SFF-8087 interfész
memória	Gyorsítótár - 512 MB DDRII (800 MHz)
A támogatott eszközök száma	akár 32 SATA és/vagy SAS meghajtó
Támogatott RAID szintek	RAID - 0, 1, 5 és 6 szint Speciális RAID 10, 50 és 60
Gazdavezérlő interfész	X8 PCI Express 2.0 verzió
Formafaktor	Alacsony profilú MD2 formátum (167,64 mm x 64,42 mm)
Funkcionalitás	Vészáramellátás (opció, közvetlen csatlakozás) Automatikus újraindítás frissítés után Automatikus folytatás a helyreállítás után Online kapacitásbővítés (OCE) Online migráció egyik RAID-szintről a másikra (RLM) SafeStore adatkódoló rendszer Azonnali adattörlés funkció SSD támogatás SSD Guard™ technológiával Globális és dedikált redundancia, vészhelyzeti forró készenlét adat-helyreállítással Automatikus helyreállítás Szerkezeti integritás a forró készenléthez SATA Emergency Hot Spare SAS tömbökhöz Többcsatornás támogatási struktúra egy vezérlőhöz (feladatátvétel) Terhelés-elosztás Átfogó RAID-kezelő szoftver

Kedves vásárlók.
Kérjük, vegye figyelembe, hogy az ezen az oldalon található árucikkekkel kapcsolatos referenciainformáció nem ajánlat, a berendezések elérhetőségét és költségét a NAG LLC vezetőivel kell tisztázni, akik szívesen segítenek a felszerelés kiválasztásában és a megrendelés feladásában. .

A gyártó fenntartja a jogot a megjelenés, a műszaki adatok és a felszereltség előzetes értesítés nélküli megváltoztatására.

Röviden a modern RAID vezérlőkről

Jelenleg a RAID vezérlők, mint külön megoldás, kizárólag egy speciális szerverpiaci szegmensre koncentrálnak. Valójában minden felhasználói PC-khez való modern alaplap (nem szerverlap) rendelkezik integrált hardver-szoftver SATA RAID vezérlőkkel, amelyek képességei bőven elegendőek a PC-felhasználók számára. Igaz, észben kell tartani, hogy ezek a vezérlők kizárólag a Windows operációs rendszer használatára összpontosítanak. A Linux család operációs rendszereiben a RAID tömböket szoftver hozza létre, és minden számítás a RAID vezérlőről a központi processzorra kerül.

A szerverek hagyományosan hardveres-szoftveres vagy tiszta hardveres RAID-vezérlőket használnak. A hardveres RAID-vezérlő lehetővé teszi RAID-tömb létrehozását és karbantartását az operációs rendszer és a központi processzor részvétele nélkül. Az ilyen RAID-tömböket az operációs rendszer egyetlen lemeznek (SCSI-lemeznek) tekinti. Ebben az esetben nincs szükség speciális illesztőprogramra - a szabványos (az operációs rendszer része) SCSI lemezmeghajtót használják. Ebben a tekintetben a hardvervezérlők platformfüggetlenek, és a RAID-tömb konfigurálása ezen keresztül történik Vezérlő BIOS. A hardveres RAID-vezérlő nem használja a CPU-t az összes ellenőrzőösszeg stb. kiszámításakor, mivel saját speciális processzort és RAM-ot használ a számításokhoz.

A készülékvezérlőkhöz dedikált illesztőprogramra van szükség, amely helyettesíti a szabványos SCSI-lemez-illesztőprogramot. Ezenkívül a szoftver- és hardvervezérlők fel vannak szerelve felügyeleti segédprogramokkal. Ebben a tekintetben a szoftver- és hardvervezérlők egy adott operációs rendszerhez vannak kötve. Ebben az esetben az összes szükséges számítást maga a RAID-vezérlő processzora is elvégzi, de használja szoftver meghajtóés a felügyeleti segédprogramok lehetővé teszik a vezérlő vezérlését operációs rendszer, és nem csak a vezérlő BIOS-án keresztül.

Tekintettel arra, hogy a szerverek SCSI-lemezeit már lecserélték SAS-lemezekre, minden modern szerver RAID-vezérlő a SAS- vagy SATA-lemezek támogatására összpontosít, amelyeket a szerverekben is használnak.

Tavaly lemezek egy új SATA interfész 3 (SATA 6 Gb / s), amely fokozatosan felváltotta a SATA 2 (SATA 3 Gb / s) interfészt. Nos, a SAS interfésszel (3 Gb / s) rendelkező lemezeket felváltották a SAS 2.0 interfésszel rendelkező lemezek (6 Gb / s). Természetesen, új szabvány A SAS 2.0 teljes mértékben kompatibilis a régi szabvánnyal.

Ennek megfelelően megjelentek a SAS 2.0 szabványt támogató RAID vezérlők. Úgy tűnik, nincs értelme a SAS 2.0 szabványra váltani, ha még a leggyorsabb SAS-lemezek olvasási és írási sebessége sem haladja meg a 200 MB / s-ot, és a SAS protokoll sávszélessége (3 Gb / s vagy 300 MB / s) elég nekik.

Valójában, ha minden meghajtó egy külön porthoz csatlakozik a RAID-vezérlőn, 3 Gb/s (ami elméletben 300 MB/s) elegendő. A RAID-vezérlő minden portjához azonban nem csak egyedi lemezek, hanem lemeztömbök (lemezketrecek) is csatlakoztathatók. Ebben az esetben egy SAS-csatornát több meghajtó osztozik egyszerre, és a 3 Gb / s sávszélesség már nem lesz elegendő. Nos, emellett figyelembe kell venni az SSD-meghajtók jelenlétét is, amelyek olvasási és írási sebessége már túllépte a 300 MB / s-os sávot. Például az új Intel SSD 510 akár 500 MB/s szekvenciális olvasási és akár 315 MB/s szekvenciális írási sebességgel is rendelkezik.

A szerver RAID vezérlők piacának jelenlegi helyzetének rövid bemutatása után vessünk egy pillantást az LSI 3ware SAS 9750-8i vezérlő specifikációira.

3ware SAS 9750-8i RAID-vezérlő specifikációi

Ez a RAID-vezérlő egy speciális LSI SAS2108 XOR processzoron alapul, 800 MHz-es órajellel és PowerPC architektúrával. Ez a processzor 512 MB 800 MHz-es DDRII RAM-ot használ hibajavítással (ECC).

Az LSI 3ware SAS 9750-8i vezérlő kompatibilis a SATA- és SAS-meghajtókkal (a HDD-k és az SSD-k is támogatottak), és akár 96 eszköz csatlakoztatását teszi lehetővé SAS-bővítőkkel. Fontos, hogy ez a vezérlő a SATA 600 MB/s (SATA III) és a SAS 2 meghajtókat egyaránt támogatja.

A lemezek csatlakoztatásához a vezérlő nyolc porttal rendelkezik, amelyeket fizikailag két Mini-SAS SFF-8087 csatlakozóba egyesítenek (négy port mindegyik csatlakozóban). Vagyis ha a lemezeket közvetlenül a portokhoz csatlakoztatjuk, akkor összesen nyolc lemez csatlakoztatható a vezérlőhöz, és ha a lemezrekeszek minden portjához csatlakoztatjuk, a lemezek teljes mennyisége 96-ra növelhető. A nyolc port mindegyike A vezérlő sávszélessége 6 Gb / s, ami megfelel a SAS 2 és SATA III szabványoknak.

Természetesen, ha lemezeket vagy lemezrekeszeket csatlakoztat ehhez a vezérlőhöz, speciális kábelekre lesz szüksége, amelyek egyik végén belső Mini-SAS SFF-8087 csatlakozó, a másik végén pedig csatlakozó található, ami attól függ, hogy mi van a vezérlőhöz csatlakoztatva. Ha például SAS-meghajtókat közvetlenül a vezérlőhöz csatlakoztat, olyan kábelt kell használnia, amelynek egyik oldalán Mini-SAS SFF-8087 csatlakozó, a másikon pedig négy SFF 8484 csatlakozó található, amelyek lehetővé teszik a SAS-meghajtók közvetlen csatlakoztatását. Vegye figyelembe, hogy magukat a kábeleket nem tartalmazza a csomag, és azokat külön kell megvásárolni.

Az LSI 3ware SAS 9750-8i vezérlő PCI Express 2.0 x8 interfésszel rendelkezik, amely 64 Gb / s (minden irányban 32 Gb / s) átviteli sebességet biztosít. Nyilvánvaló, hogy ez az átviteli sebesség teljesen elegendő nyolc SAS-porthoz, amelyek mindegyike 6 Gb / s sávszélességgel rendelkezik. Vegye figyelembe azt is, hogy a vezérlő speciális csatlakozóval rendelkezik, amely opcionálisan csatlakoztatható az LSIiBBU07 tartalék akkumulátorhoz.

Fontos, hogy ehhez a vezérlőhöz illesztőprogram telepítése szükséges, vagyis szoftveres és hardveres RAID vezérlő. Támogatja az operációs rendszereket, mint pl Windows Vista, Windows Server 2008, Windows Server 2003 x64, Windows 7, Windows 2003 Server, MAC OS X, LinuxFedora Core 11, Red Hat Enterprise Linux 5.4, OpenSuSE 11.1, SuSE Linux Enterprise Server (SLES) 11, OpenSolaris 2009.06 ESX/ESMware 4.0/4.0 update-1 és más Linux család rendszerek. A csomag tartalmazza a 3ware Disk Manager 2 szoftvert is, amely lehetővé teszi a RAID tömbök kezelését az operációs rendszeren keresztül.

Az LSI 3ware SAS 9750-8i vezérlő támogatja a szabványos RAID típusokat: RAID 0, 1, 5, 6, 10 és 50. Talán az egyetlen nem támogatott tömbtípus a RAID 60. Ez annak a ténynek köszönhető, hogy ez a vezérlő képes létrehozni egy RAID 6 tömböt, amelyben mindössze öt meghajtó csatlakozik közvetlenül az egyes vezérlőportokhoz (elméletileg a RAID 6 négy meghajtóval is létrehozható). Ennek megfelelően egy RAID 60 tömbhöz ehhez a vezérlőhöz legalább tíz lemezre van szükség, amelyek egyszerűen nem léteznek.

Nyilvánvaló, hogy a RAID 1 tömb támogatása irreleváns egy ilyen vezérlő esetében, mivel adott típus egy tömb csak két lemezen jön létre, és egy ilyen vezérlőt csak két lemezre használni logikátlan és rendkívül pazarló. De a RAID 0, 5, 6, 10 és 50 tömbök támogatása nagyon fontos. Bár talán siettünk a RAID 0 tömbbel. Ennek a tömbnek azonban nincs redundanciája, ezért nem biztosít megbízható adattárolást, ezért szerverekben ritkán használják. Elméletileg azonban ez a tömb a leggyorsabb az adatolvasási és -írási sebesség tekintetében. Azonban ne feledjük, mit különböző típusok A RAID-tömbök különböznek egymástól, és különböznek egymástól.

RAID szintek

A „RAID-tömb” kifejezés 1987-ben jelent meg, amikor Patterson, Gibson és Katz amerikai kutatók, a Kaliforniai Egyetem Berkeley-ben, „Az olcsó lemezek redundáns tömbjeihez, RAID” című cikkükben leírták, hogy Ily módon egyesítsen több olcsó merevlemezt egyetlen logikai eszközbe úgy, hogy az eredmény megnövekedett rendszerkapacitás és sebesség, és az egyes meghajtók meghibásodása ne vezesse a teljes rendszer meghibásodását. Csaknem 25 év telt el a cikk megjelenése óta, de a RAID-tömbök építésének technológiája ma sem veszítette el relevanciáját. Az egyetlen dolog, ami azóta változott, az a RAID mozaikszó dekódolása. A helyzet az, hogy kezdetben a RAID-tömbök egyáltalán nem épültek olcsó lemezekre, ezért az Olcsó ("olcsó") szót Independent-re ("független") változtatták, ami inkább igaz volt.

A RAID tömbök hibatűrése redundanciával érhető el, vagyis a lemezterület kapacitásának egy részét szolgáltatási célokra allokálják, így a felhasználó elérhetetlenné válik.

A lemez alrendszer teljesítménynövekedését több lemez egyidejű működése biztosítja, és ebben az értelemben minél több lemez van a tömbben (egy bizonyos határig), annál jobb.

A tömbben lévő meghajtók párhuzamos vagy független hozzáféréssel is megoszthatók. Párhuzamos hozzáférés esetén a lemezterület blokkokra (csíkokra) van osztva az adatrögzítéshez. Hasonlóképpen, a lemezre írandó információ ugyanazokra a blokkokra van osztva. Íráskor az egyes blokkok különböző lemezekre íródnak, több blokk pedig egyidejűleg különböző lemezekre, ami az írási műveletek teljesítményének növekedéséhez vezet. A szükséges információk külön blokkokban, egyidejűleg több lemezről is beolvasásra kerülnek, ami szintén hozzájárul a teljesítménynövekedéshez a tömbben lévő lemezek számával arányosan.

Meg kell jegyezni, hogy a párhuzamos hozzáférési modell csak akkor valósul meg, ha az adatírási kérelem mérete nagyobb, mint magának a blokknak a mérete. Egyébként gyakorlatilag lehetetlen több blokkot párhuzamosan írni. Képzeljünk el egy olyan helyzetet, amikor egyetlen blokk mérete 8 KB, és egy adatírási kérés mérete 64 KB. Ebben az esetben a forrásinformáció nyolc, egyenként 8 KB-os blokkra van vágva. Ha van egy négy lemezből álló tömb, akkor négy blokk, vagyis 32 KB írható egyszerre. Nyilvánvaló, hogy ebben a példában az írási és olvasási sebesség négyszer nagyobb lesz, mint egyetlen lemez használatakor. Ez csak ideális helyzetre igaz, azonban a kérés mérete nem mindig a blokkméret és a tömbben lévő lemezek számának többszöröse.

Ha a rögzített adatok mérete kisebb, mint a blokkméret, akkor egy alapvetően más modellt - független hozzáférést - valósítanak meg. Sőt, ez a modell akkor is használható, ha az írandó adatok mérete nagyobb, mint egy blokk mérete. Független hozzáféréssel egy adott kérés minden adata külön lemezre kerül, vagyis a helyzet megegyezik az egyetlen lemezzel való munkavégzéssel. A független hozzáférési modell előnye, hogy ha több írási (olvasási) kérés érkezik egyidejűleg, akkor ezek egymástól függetlenül, külön lemezeken kerülnek végrehajtásra. Ez a helyzet jellemző például a szerverekre.

Vminek megfelelően különféle típusok hozzáférés, különböző típusú RAID-tömbök léteznek, amelyeket általában RAID-szintek jellemeznek. A hozzáférés típusa mellett a RAID-szintek különböznek a redundáns információk elhelyezésének és kialakításának módjában is. A redundáns információk elhelyezhetők egy dedikált lemezen, vagy eloszthatók az összes lemezen.

Jelenleg számos RAID-szintet széles körben használnak, ezek a RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 és RAID 60. Korábban a RAID 2, RAID 3 és RAID 4 szinteket is használták, azonban Ezeket a RAID-szinteket jelenleg nem használják, és a modern RAID-vezérlők sem támogatják őket. Vegye figyelembe, hogy minden modern RAID vezérlő támogatja a JBOD (Just a Bench Of Disks) funkciót is. Ebben az esetben nem RAID-tömbről beszélünk, hanem egyszerűen az egyes lemezek RAID-vezérlőhöz való csatlakoztatásáról.

RAID 0

A RAID 0 vagy csíkozás szigorúan véve nem RAID-tömb, mivel az ilyen tömb nem redundáns, és nem biztosít adattárolási megbízhatóságot. Történelmileg azonban RAID-tömbnek is nevezik. A RAID 0 tömb (1. ábra) két vagy több lemezre építhető, és akkor használatos, ha a lemezalrendszer nagy teljesítményének biztosításához szükséges, és az adattárolás megbízhatósága nem kritikus. A RAID 0 tömb létrehozásakor az információkat blokkokra osztják (ezeket a blokkokat csíkoknak (csíkoknak) nevezik), amelyek egyidejűleg külön lemezekre íródnak, azaz párhuzamos hozzáférésű rendszer jön létre (ha természetesen a blokk mérete lehetővé tesz). A több meghajtó egyidejű I/O-jának lehetőségével a RAID 0 biztosítja a leggyorsabb adatátviteli sebességet és a lemezterület leghatékonyabb felhasználását, mivel nincs szükség hely az ellenőrző összegek tárolására. Ennek a szintnek a megvalósítása nagyon egyszerű. A RAID 0 főként olyan területeken használatos, ahol nagy mennyiségű adat gyors átvitelére van szükség.

Rizs. 1. RAID 0 tömb

Elméletileg az olvasási és írási sebesség növekedésének a tömbben lévő lemezek számának többszörösének kell lennie.

Egy RAID 0 tömb megbízhatósága nyilvánvalóan alacsonyabb, mint bármelyik lemez megbízhatósága külön-külön, és csökken a tömbben lévő lemezek számának növekedésével, mivel bármelyik meghibásodása a teljes tömb működésképtelenségéhez vezet. Ha az egyes lemezek MTBF-je MTTF lemez, akkor egy RAID 0 tömb MTBF-je, amely a következőkből áll: n lemezek, egyenlő:

MTTF RAID0 = MTTD lemez /n.

Ha egy lemez meghibásodásának valószínűségét jelöljük egy bizonyos ideig p, majd egy RAID 0 tömbhöz innen n lemezek esetén annak a valószínűsége, hogy legalább egy lemez meghibásodik (a tömb leesésének valószínűsége) a következő lesz:

P (tömb esés) = 1 - (1 - p) n.

Például, ha egy lemez meghibásodásának valószínűsége három éven belül 5%, akkor a két lemezből álló RAID 0 tömb meghibásodásának valószínűsége már 9,75%, nyolc lemezé pedig 33,7%.

RAID 1

A RAID 1 tömb (2. ábra), más néven tükör, egy kétlemezes tömb 100 százalékos redundanciával. Vagyis az adatok teljesen megkettőződnek (tükrözve), aminek köszönhetően nagyon magas szintű megbízhatóság (valamint költség) érhető el. Vegye figyelembe, hogy a RAID 1 megvalósítása nem igényli a lemezek és az adatok előzetes blokkokra történő particionálását. A legegyszerűbb esetben két meghajtó ugyanazt az információt tartalmazza, és egy logikai meghajtó. Ha az egyik lemez meghibásodik, egy másik hajtja végre a funkcióit (ami teljesen átlátható a felhasználó számára). Egy tömb visszaállítása egyszerű másolással történik. Ezenkívül a RAID 1-nek elméletileg meg kell dupláznia az olvasási sebességet, mivel ez a művelet egyszerre két lemezről is végrehajtható. Az ilyen információtárolási sémát főként olyan esetekben alkalmazzák, amikor az adatbiztonság ára jóval magasabb, mint egy tárolórendszer megvalósításának költsége.

Rizs. 2. RAID 1

Ha az előző esethez hasonlóan egy lemez meghibásodásának valószínűségét jelöljük egy bizonyos ideig p, akkor RAID 1 tömb esetén annak a valószínűsége, hogy mindkét lemez egyszerre meghibásodik (a tömb meghibásodásának valószínűsége) a következő lesz:

p(tömbcsepp) = p 2.

Például, ha egy lemez meghibásodásának valószínűsége a működést követő három éven belül 5%, akkor két lemez egyidejű meghibásodásának valószínűsége már 0,25%.

RAID 5

A RAID 5 tömb (3. ábra) egy hibatűrő lemeztömb elosztott ellenőrzőösszeg-tárolóval. Íráskor az adatfolyamot bájt szinten blokkokra (csíkokra) osztják, amelyek ciklikus sorrendben egyidejűleg a tömb összes lemezére íródnak.

Rizs. 3. RAID 5 tömb

Tegyük fel, hogy a tömb tartalmazza n lemezek, és a csík mérete az d. Minden egyes részéhez n–1 csíkos ellenőrző összeg kerül kiszámításra p.

Csík d1 az első lemezre rögzített, csík d2- a másodikon és így tovább egészen a csíkig d n–1, amely az (n–1)-edik lemezre van írva. Legközelebb n-edik lemez ellenőrző összeg van írva p n, és a folyamat ciklikusan megismétlődik attól a lemeztől kezdve, amelyre a csíkot írták d n.

A rögzítési folyamat ( n–1) a csíkokat és azok ellenőrző összegét egyszerre állítják elő mindenki számára n lemezek.

Az ellenőrző összeg kiszámításához bitenkénti XOR műveletet használunk az írandó adatblokkon. Igen, ha van n merevlemezek és d- adatblokk (csík), akkor az ellenőrző összeget a következő képlettel számítjuk ki:

p n = d 1⊕ d2 ⊕ ... ⊕ d n-1.

Bármely lemez meghibásodása esetén a rajta lévő adatok visszaállíthatók a vezérlő adatokból és az egészséges lemezeken maradt adatokból. Valóban, az identitások felhasználásával (a⊕ b) A b= aés a⊕ a = 0 , ezt kapjuk:

p n⊕ (dk⊕ p n) = dl⊕ d n⊕ ...⊕ ...⊕ d n–l⊕ (dk⊕ pn).

d k = d 1⊕ d n⊕ ...⊕ dk-1⊕ dk+1⊕ ...⊕ p n.

Így ha egy blokkal rendelkező lemez meghibásodik dk, akkor a fennmaradó blokkok értékével és az ellenőrző összeggel visszaállítható.

RAID 5 esetén a tömbben lévő összes lemeznek azonos méretűnek kell lennie, azonban az írásra rendelkezésre álló lemezalrendszer teljes kapacitása pontosan egy lemezzel csökken. Például, ha öt lemez 100 GB-os, akkor a tömb tényleges mérete 400 GB, mivel 100 GB van lefoglalva a paritásinformációk számára.

A RAID 5 tömb három vagy több merevlemezre építhető. A tömbben lévő merevlemezek számának növekedésével a redundancia csökken. Vegye figyelembe azt is, hogy a RAID 5 tömb újraépíthető, ha csak egy meghajtó hibásodik meg. Ha azonban egyszerre két meghajtó meghibásodik (vagy ha a második meghajtó meghibásodik a tömb újraépítése közben), akkor a tömb nem állítható vissza.

RAID 6

Egy RAID 5 tömbről bebizonyosodott, hogy helyreállítható, ha az egyik meghajtó meghibásodik. Néha azonban magasabb szintű megbízhatóságot kell biztosítani, mint egy RAID 5 tömb esetében. Ebben az esetben használhat RAID 6 tömböt (4. ábra), amely lehetővé teszi a tömb visszaállítását akkor is, ha két lemez egyszerre meghibásodik. idő.

Rizs. 4.RAID 6 tömb

A RAID 6 hasonló a RAID 5-höz, de nem egy, hanem két ellenőrző összeget használ, amelyek ciklikusan vannak elosztva a lemezeken. Első ellenőrző összeg p ugyanazon algoritmus szerint kerül kiszámításra, mint egy RAID 5 tömbben, vagyis egy XOR művelet a különböző lemezekre írt adatblokkok között:

p n = d 1⊕ d2⊕ ...⊕ d n–1.

A második ellenőrző összeget egy másik algoritmussal számítják ki. Anélkül, hogy matematikai részletekbe mennénk, mondjuk ez is egy XOR művelet az adatblokkok között, de minden adatblokkot előre megszoroznak egy polinomiális tényezővel:

q n = g 1 d 1⊕ g 2 d 2⊕ ...⊕ g n–1 d n–1 .

Ennek megfelelően a tömbben lévő két lemez kapacitása ellenőrző összegekhez van lefoglalva. Elméletileg egy RAID 6 tömb négy vagy több meghajtón is létrehozható, azonban sok vezérlőben legalább öt meghajtón is létrehozható.

Ne feledje, hogy a RAID 6 tömb teljesítménye általában 10-15%-kal alacsonyabb, mint a RAID 5 tömb teljesítménye (azonos számú meghajtóval), amit a vezérlő által elvégzett nagy mennyiségű számítás okoz. szükséges a második ellenőrző összeg kiszámításához, valamint további lemezblokkok olvasásához és felülírásához minden blokk írásakor).

RAID 10

A RAID 10 tömb (5. ábra) a 0 és 1 szintek kombinációja. Ehhez a szinthez legalább négy meghajtó szükséges. A négy lemezből álló RAID 10 tömbben ezek páronként RAID 1 tömbökké egyesülnek, és mindkét tömb logikai lemezként egy RAID 0 tömbbe kerül. Egy másik megközelítés is lehetséges: kezdetben a lemezeket RAID 0 tömbbe egyesítik. tömbök, majd ezeken a tömbökön alapuló logikai lemezek – egy RAID 1 tömbbe.

Rizs. 5. RAID 10 tömb

RAID 50

A RAID 50 tömb a 0 és 5 szint kombinációja (6. ábra). Ennek a szintnek a minimális követelménye hat lemez. A RAID 50 tömbben először két RAID 5 tömb jön létre (mindegyik legalább három lemez), amelyeket ezután logikai lemezekként egy RAID 0 tömbbé egyesítenek.

Rizs. 6.RAID 50 tömb

LSI 3ware SAS 9750-8i vezérlő vizsgálati módszertana

Az LSI 3ware SAS 9750-8i RAID vezérlő teszteléséhez egy speciális IOmeter 1.1.0 tesztcsomagot (2010.12.02-i verzió) használtunk. próbapad a következő konfigurációval rendelkezett:

processzor - Intel Core i7-990 (Gulftown);
alaplap - GIGABYTE GA-EX58-UD4;
memória - DDR3-1066 (3 GB, háromcsatornás mód);
rendszerlemez- WD Caviar SE16 WD3200AAKS;
videokártya - GIGABYTE GeForce GTX480 SOC;
RAID vezérlő - LSI 3ware SAS 9750-8i;
A RAID-vezérlőhöz csatlakoztatott SAS-meghajtók Seagate Cheetah 15K.7 ST3300657SS.

A tesztelést Microsoft Windows 7 Ultimate (32 bites) operációs rendszer alatt végeztük.

A RAID vezérlő Windows illesztőprogramjának 5.12.00.007 verzióját használtuk, és frissítettük a vezérlő firmware-ét is az 5.12.00.007 verzióra.

A rendszerlemezt az Intel X58 lapkakészlet déli hídjába integrált vezérlőn keresztül megvalósított SATA-hoz, a SAS lemezeket pedig két Mini-SAS SFF-8087 -> 4 db SAS kábellel közvetlenül a RAID vezérlő portjaihoz kötöttük.

A RAID-vezérlőt az alaplap PCI Express x8 foglalatába telepítették.

A vezérlőt a következő RAID tömbökkel tesztelték: RAID 0, RAID 1, RAID 5, RAID 6, RAID 10 és RAID 50. A RAID tömbbe kombinálható meghajtók száma minimumtól nyolcig változott mindegyiknél. tömbtípus.

A csíkok mérete az összes RAID-tömbön nem változott, és elérte a 256 KB-ot.

Emlékezzünk vissza, hogy az IOmeter csomag lehetővé teszi, hogy mind a logikai partíciót létrehozó lemezekkel, mind a logikai partíció nélküli lemezekkel dolgozzon. Ha egy lemezt tesztelünk logikai partíció nélkül, akkor az IOmeter a logikai adatblokkok szintjén működik, azaz az operációs rendszer helyett parancsokat küld a vezérlőnek az LBA blokkok írására vagy olvasására.

Ha logikai partíciót hozunk létre a lemezen, akkor az IOmeter segédprogram kezdetben létrehoz egy fájlt a lemezen, amely alapértelmezés szerint a teljes logikai partíciót lefoglalja (elvileg ennek a fájlnak a mérete megváltoztatható, ha 512 bájtban adja meg szektorok), és akkor már ezzel a fájllal működik, azaz ezen a fájlon belül olvas vagy ír (felülír) egyes LBA blokkokat. De ismét az IOmeter az operációs rendszer megkerülésével működik, azaz közvetlenül küld kéréseket a vezérlőnek az adatok olvasására / írására.

Általánosságban elmondható, hogy a HDD-lemezek tesztelésekor, amint azt a gyakorlat mutatja, gyakorlatilag nincs különbség a létrehozott logikai partícióval és anélküli lemez tesztelésének eredménye között. Ugyanakkor úgy gondoljuk, hogy helyesebb egy létrehozott logikai partíció nélkül tesztelni, mivel ebben az esetben a teszt eredménye nem függ a használt fájlrendszertől (NTFA, FAT, ext stb.). Ezért a tesztelést logikai partíciók létrehozása nélkül végeztük.

Ezenkívül az IOmeter segédprogram lehetővé teszi a kérés blokk méretének (Transfer Request Size) beállítását az adatok írására / olvasására, és a teszt elvégezhető mind a szekvenciális (szekvenciális) olvasáshoz és íráshoz, amikor LBA-blokkokat olvas, és szekvenciálisan egymás után írva, és véletlenre (Random), amikor az LBA blokkokat véletlenszerű sorrendben olvassák és írják. Betöltési forgatókönyv generálásakor beállíthatja a tesztidőt, a szekvenciális és véletlenszerű műveletek százalékos arányát (Percent Random/Sequential Distribution), valamint az olvasási és írási műveletek százalékos arányát (Percent Read/Write Distribution). Ezenkívül az IOmeter segédprogram lehetővé teszi a teljes tesztelési folyamat automatizálását, és az összes eredményt egy CSV-fájlba menti, amelyet aztán könnyen exportálhat egy Excel-táblázatba.

Egy másik beállítás, amelyet az IOmeter segédprogram lehetővé tesz, az adatátviteli kérések blokkjainak úgynevezett igazítása (I / Os be) a határok mentén. kemény korong. Alapértelmezés szerint az IOmeter 512 bájtos lemezszektorhatárokhoz igazítja a kérésblokkokat, de tetszőleges igazítást is beállíthat. Valójában a legtöbb merevlemez szektormérete 512 bájt, és csak mostanában kezdtek megjelenni a 4 KB szektorméretű lemezek. Emlékezzünk vissza, hogy a merevlemezeken a szektor a lemezre írható vagy onnan olvasható adatok minimális címezhető mérete.

Teszteléskor be kell állítani az adatátviteli kérelmek blokkjainak igazítását a lemezszektor méretének megfelelően. Mert be Seagate hajt A Cheetah 15K.7 ST3300657SS szektor mérete 512 bájt, mi 512 bájtos szektorhatár-igazítást használtunk.

Az IOmeter tesztcsomag segítségével megmértük a létrehozott RAID tömb szekvenciális olvasási és írási sebességét, valamint véletlenszerű olvasási és írási sebességét. A továbbított adatblokkok mérete 512 bájt, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 és 1024 KB volt.

A fenti betöltési forgatókönyvekben a tesztidő minden egyes adatblokk átvitelére vonatkozó kérés esetén 5 perc volt. Vegye figyelembe azt is, hogy a fenti tesztek mindegyikében a feladatsor mélységét (a kiemelkedő I/O-k száma) 4-re állítottuk az IOmeter beállításaiban, ami jellemző a felhasználói alkalmazásokra.

Vizsgálati eredmények

A teszteredmények elemzése után meglepődtünk az LSI 3ware SAS 9750-8i RAID vezérlő teljesítményén. És olyannyira, hogy elkezdték átnézni a szkriptjeinket, hogy azonosítsák bennük a hibákat, majd többször megismételték a tesztelést más RAID-vezérlő beállításokkal. Módosítottuk a csík méretét és a RAID vezérlő gyorsítótár módját. Ez természetesen az eredményekben is megmutatkozott, de nem változtatott az adatátviteli sebesség adatblokk méretétől való függésének általános jellegén. És egyszerűen nem tudtuk megmagyarázni ezt a függőséget. Munka ezt a vezérlőt teljesen logikátlannak tűnik számunkra. Először is, az eredmények instabilok, azaz minden rögzített adatblokk méretnél a sebesség periodikusan változik, és az átlagos eredmény nagy hibás. Vegye figyelembe, hogy az IOmeter segédprogrammal végzett lemezek és vezérlők tesztelésének eredményei általában stabilak, és nagyon kevéssé különböznek.

Másodszor, a blokk méretének növekedésével az adatsebességnek növekednie kell vagy állandónak kell maradnia telítettségi módban (amikor a sebesség eléri a maximális értéket). Az LSI 3ware SAS 9750-8i vezérlő esetében azonban egyes blokkméreteknél meredeken csökken az adatátviteli sebesség. Emellett továbbra is rejtély számunkra, hogy a RAID 5 és RAID 6 tömbök azonos számú lemezénél miért nagyobb az írási sebesség, mint az olvasási sebesség. Egyszóval nem tudjuk megmagyarázni az LSI 3ware SAS 9750-8i vezérlő működését - csak a tényeket közölhetjük.

A teszteredmények többféleképpen osztályozhatók. Például rendszerindítási forgatókönyvek szerint, amikor minden rendszerindítási típushoz az összes lehetséges RAID-tömbhöz adnak eredményeket különböző számú csatlakoztatott lemezzel, vagy RAID-tömbtípusok szerint, amikor az eredményeket minden RAID-tömbtípushoz különböző számú lemezzel jelzik. lemezek szekvenciális olvasási, szekvenciális írási, véletlenszerű olvasási és véletlenszerű írási forgatókönyvekben. Az eredményeket a tömbben lévő meghajtók száma alapján is osztályozhatja, amikor a vezérlőhöz csatlakoztatott minden egyes meghajtószámra az összes lehetséges (adott számú meghajtóra vonatkozó) RAID tömb eredményét megadjuk szekvenciális olvasásban és szekvenciális írásban, véletlenszerű olvasási és véletlenszerű írási forgatókönyvek.

Úgy döntöttünk, hogy az eredményeket tömbtípusok szerint csoportosítjuk, mert véleményünk szerint a meglehetősen nagy számú grafikon ellenére egy ilyen bemutatás vizuálisabb.