Hogyan válassz tárolóhelyet anélkül, hogy lábon lőnéd magad

Bevezetés

Ideje tárolót vásárolni. Melyiket vigyem, kit hallgass? Az A szállító B szállítóról beszél, és ott van a C integrátor, aki ennek az ellenkezőjét mondja, és tanácsot ad a D szállítónak. Ilyen helyzetben még egy tapasztalt tárolótervező feje is megfordul, különösen a divatos új gyártók, SDS és hiperkonvergencia esetében. Ma.

Szóval hogyan lehet kitalálni az egészet, és nem lesz bolond a végén? Mi (AntonVirtual Anton Zsbankov és corp Jevgenyij Elizarov) próbáljunk meg beszélni erről egyszerű oroszul.
A cikknek sok hasonlósága van, és valójában a „Virtualizált adatközpont tervezés” a tárolási rendszerek kiválasztása és a tárolási technológiák felülvizsgálata terén. Röviden áttekintjük az általános elméletet, de javasoljuk, hogy olvassa el ezt a cikket is.

Miért

Gyakran előfordulhat olyan helyzet, amikor egy új személy jön egy fórumra vagy egy speciális csevegésre, például a Storage Discussions, és felteszi a kérdést: „Itt két tárolási lehetőséget kínálnak nekem - ABC SuperStorage S600 és XYZ HyperOcean 666v4, mit ajánlasz ?”

És kezdődik a zavar, hogy kinek milyen jellemzői vannak a szörnyű és érthetetlen tulajdonságok megvalósításában, amelyek egy felkészületlen ember számára teljesen kínaiak.

Tehát a legfontosabb és legelső kérdés, amelyet jóval a kereskedelmi ajánlatokban szereplő specifikációk összehasonlítása előtt fel kell tennie magának: MIÉRT? Miért van szükség erre a tárolórendszerre?

Hogyan válassz tárolóhelyet anélkül, hogy lábon lőnéd magad

A válasz váratlan lesz, és nagyon Tony Robbins stílusban - az adatok tárolására. Köszönöm, kapitány! És mégis, néha annyira belemerülünk a részletek összehasonlításába, hogy elfelejtjük, miért is tesszük mindezt.

Tehát egy adattároló rendszer feladata az ADATOK tárolása és elérése adott teljesítménnyel. Kezdjük az adatokkal.

Adat

Adattípus

Milyen adatokat tervezünk tárolni? Nagyon fontos kérdés, amely sok tárolórendszert kiküszöbölhet a mérlegelés alól. Például videók és fényképek tárolását tervezi. Azonnal áthúzhatja a kis blokkokban véletlenszerű hozzáférésre tervezett rendszereket, vagy a tömörítési/duplikációmentes funkciókkal rendelkező rendszereket. Lehet, hogy ezek egyszerűen kiváló rendszerek, nem akarunk semmi rosszat mondani. De ebben az esetben erősségeik vagy gyengülnek (a videó és a fotók nincsenek tömörítve), vagy egyszerűen csak jelentősen megnövelik a rendszer költségeit.

Ezzel szemben, ha a tervezett felhasználás egy forgalmas tranzakciós DBMS, akkor a kiváló multimédiás streaming rendszerek, amelyek képesek másodpercenként gigabájtot szállítani, rossz választásnak bizonyulnak.

Adatmennyiség

Mennyi adatot tervezünk tárolni? A mennyiség mindig minőséggé fejlődik, ezt soha nem szabad elfelejteni, különösen az adatmennyiség exponenciális növekedése idején. A petabájt osztályú rendszerek ma már nem ritkák, de minél nagyobb a petabájtos kapacitás, annál specifikusabbá válik a rendszer, annál kevésbé lesz elérhető a kis és közepes méretű véletlen hozzáférésű rendszerek szokásos funkcionalitása. Ez triviális, mert a blokk hozzáférési statisztikai táblázatok önmagukban nagyobbak, mint a vezérlőkön rendelkezésre álló RAM mennyisége. A tömörítésről/szintezésről nem is beszélve. Tegyük fel, hogy a tömörítési algoritmust egy erősebbre szeretnénk váltani, és 20 petabájtnyi adatot tömörítünk. Mennyi ideig tart: hat hónap, egy év?

Másrészt minek foglalkozni azzal, ha 500 GB adatot kell tárolni és feldolgozni? Csak 500. Az ekkora háztartási SSD-k (alacsony DWPD-vel) nem kerülnek semmibe. Miért építsünk Fibre Channel gyárat és vásároljunk csúcskategóriás külső tárolórendszereket, amelyek költsége egy öntöttvas hídnak felel meg?

A teljes szám hány százaléka forró adat? Mennyire egyenlőtlen a terhelés adatmennyiség szempontjából? Ebben az esetben a többszintű tárolási technológia vagy a Flash-gyorsítótár nagyon hasznos lehet, ha a forró adatok mennyisége kicsi az összeshez képest. Vagy fordítva, a teljes kötetben egyenletes terhelés mellett, ami gyakran megtalálható a streaming rendszerekben (videófelügyelet, egyes analitikai rendszerek), az ilyen technológiák nem nyújtanak semmit, és csak növelik a rendszer költségét/bonyolultságát.

IP

Az adatok másik oldala az adatokat felhasználó információs rendszer. Az IS-nek olyan követelménykészlete van, amely örökli az adatokat. Az IS-ről további információt a „Virtualizált adatközpont-tervezés” című részben talál.

Rugalmassági/elérhetőségi követelmények

A hibatűrési/adatelérhetőségi követelmények az ezeket használó IS-től örökölték, és három számmal vannak kifejezve - RPO, OTR, elérhetőség.

elérhetőség — egy adott időtartamra vonatkozó részesedés, amely alatt az adatok rendelkezésre állnak a velük való munkavégzéshez. Általában 9-es számként fejezik ki. Például az évi két kilenc azt jelenti, hogy a rendelkezésre állás 99%, vagy egyébként évi 95 óra elérhetetlenség megengedett. Három kilences – évi 9,5 óra.

Az RPO / RTO nem teljes mutató, hanem minden eseményre (balesetre) vonatkozik, ellentétben a rendelkezésre állással.

RPO — a baleset során elveszett adatok mennyisége (órákban). Például, ha a biztonsági mentések naponta egyszer történnek, akkor RPO = 24 óra. Azok. Katasztrófa és a tárolórendszer teljes elvesztése esetén akár 24 óráig is elveszhetnek adatok (a biztonsági mentés pillanatától számítva). Az IS-hez megadott RPO alapján például mentési szabályzatok készülnek. Ezenkívül az RPO alapján megértheti, hogy mennyi szinkron/aszinkron adatreplikációra van szükség.

OTR — a szolgáltatás (adathozzáférés) helyreállításának ideje katasztrófa után. A megadott RTO érték alapján megérthetjük, hogy szükség van-e metro klaszterre, vagy elegendő az egyirányú replikáció. Csúcskategóriás többvezérlős tárolórendszerre van szüksége?

Hogyan válassz tárolóhelyet anélkül, hogy lábon lőnéd magad

Teljesítménykövetelmények

Bár ez egy nagyon kézenfekvő kérdés, a legtöbb nehézség itt merül fel. Attól függően, hogy rendelkezik-e már valamilyen infrastruktúrával vagy sem, kiépülnek a szükséges statisztikák összegyűjtésének módjai.

Már rendelkezik tárolórendszerrel, és cserét keres, vagy szeretne egy másikat vásárolni a bővítéshez. Itt minden egyszerű. Megérti, milyen szolgáltatásai vannak már, és melyeket tervez a közeljövőben megvalósítani. A jelenlegi szolgáltatások alapján lehetősége van teljesítménystatisztika gyűjtésére. Határozza meg az IOPS jelenlegi számát és az aktuális késleltetést - melyek ezek a mutatók, és elegendőek-e a feladataihoz? Ez megtehető magán az adattároló rendszeren és a hozzá kapcsolódó gazdagépeken is.

Ezenkívül nem csak az aktuális terhelést kell néznie, hanem egy bizonyos időszakra (lehetőleg egy hónapra). Nézze meg, mik a maximális csúcsok a nap folyamán, milyen terhelést hoz létre a mentés stb. Ha a tárolórendszere vagy annak szoftvere nem biztosítja Önnek ezeknek az adatoknak a teljes készletét, használhatja az ingyenes RRDtool-t, amely a legtöbb legnépszerűbb tárolórendszerrel és kapcsolóval működik, és részletes teljesítménystatisztikát tud nyújtani. Érdemes megnézni az ezzel a tárolórendszerrel működő gazdagépek terhelését is, adott virtuális gépeknél, vagy hogy pontosan mi fut ezen a gazdagépen.

Hogyan válassz tárolóhelyet anélkül, hogy lábon lőnéd magad

Külön érdemes megjegyezni, hogy ha a kötet és az ezen a köteten található adattár késései jelentősen eltérnek, akkor érdemes odafigyelni a SAN hálózatra, nagy a valószínűsége annak, hogy problémák vannak vele, és mielőtt újat vásárolna. rendszer, érdemes utánajárni ennek a kérdésnek , mert nagyon nagy a valószínűsége annak, hogy a jelenlegi rendszer teljesítménye növekedni fog.

Infrastruktúrát épít a nulláról, vagy rendszert vásárol valamilyen új szolgáltatáshoz, amelynek terheléséről nincs tudomása. Számos lehetőség közül választhat: kommunikáljon kollégáival a speciális erőforrásokon, hogy megtudja és előre jelezze a terhelést, vegye fel a kapcsolatot egy olyan integrátorral, aki tapasztalattal rendelkezik hasonló szolgáltatások megvalósításában, és aki ki tudja számítani a terhelést az Ön számára. A harmadik lehetőség pedig (általában a legnehezebb, különösen, ha otthon írt vagy ritka alkalmazásokról van szó) az, hogy megpróbáljuk megtudni a teljesítménykövetelményeket a rendszerfejlesztőktől.

És, kérjük, vegye figyelembe, hogy a gyakorlati alkalmazás szempontjából a legmegfelelőbb megoldás a jelenlegi berendezések próbaverziója, vagy a gyártó/integrátor által tesztelésre biztosított berendezés.

Speciális követelmények

Speciális követelmény mindaz, ami nem tartozik a teljesítmény, a hibatűrés és a funkcionalitás követelményei közé az adatok közvetlen feldolgozásához és szolgáltatásához.

Az adattároló rendszerrel szemben támasztott egyik legegyszerűbb speciális követelményt „elidegeníthető adathordozónak” nevezhetjük. És azonnal világossá válik, hogy ennek az adattároló rendszernek tartalmaznia kell egy szalagos könyvtárat vagy egyszerűen egy szalagos meghajtót, amelyre a biztonsági másolatot kiírják. Ezt követően egy speciálisan képzett személy aláírja a szalagot, és büszkén viszi egy speciális széfbe.
Egy másik példa a különleges követelményre a védett ütésálló kialakítás.

ahol

Egy adott tárolórendszer kiválasztásának második fő összetevője az, hogy a tárolórendszer HOL lesz elhelyezve. A földrajztól vagy az éghajlati viszonyoktól kezdve a személyzetig.

Vevő

Kinek tervezik ezt a tárolórendszert? A kérdésnek a következő okai vannak:

Kormányzati ügyfél/kereskedelmi.
A kereskedelmi megrendelőnek nincsenek megkötései, és nem is köteles pályázatot tartani, kivéve saját belső szabályzata szerint.

Az állami ügyfél az más kérdés. 44 Szövetségi törvény és egyéb örömök a megtámadható pályázatokkal és műszaki leírásokkal.

Az ügyfél szankciók alatt áll
Nos, a kérdés itt nagyon egyszerű - a választást csak az adott ügyfél számára elérhető ajánlatok korlátozzák.

Belső előírások / eladók / modellek megvásárolhatók
A kérdés is rendkívül egyszerű, de emlékezned kell rá.

Ahol fizikailag

Ebben a részben a földrajzzal, a kommunikációs csatornákkal és a szálláshelyek mikroklímájával kapcsolatos összes kérdést megvizsgáljuk.

Персонал

Ki fog dolgozni ezzel a tárolórendszerrel? Ez nem kevésbé fontos, mint amire maga a tárolórendszer képes.
Bármennyire is ígéretes, menő és csodálatos az A szállító tárolórendszere, valószínűleg nincs értelme telepíteni, ha a személyzet csak B szállítóval tudja együtt dolgozni, és nincs tervben további vásárlások és folyamatos együttműködés A-val.

És persze a kérdés másik oldala az, hogy egy adott földrajzi helyen közvetlenül a vállalaton belül és potenciálisan a munkaerőpiacon mennyire állnak rendelkezésre képzett munkaerők. A régiók számára az egyszerű interfésszel rendelkező tárolórendszerek választása vagy a felügyelet távolról történő központosítása sok értelmet nyerhet. Ellenkező esetben egy bizonyos ponton elviselhetetlenül fájdalmassá válhat. Az internet tele van történetekkel arról, hogy egy új alkalmazott, a tegnapi diák úgy konfigurált, hogy az egész irodát megölték.

Hogyan válassz tárolóhelyet anélkül, hogy lábon lőnéd magad

A környezet

És persze fontos kérdés, hogy ez a tárolórendszer milyen környezetben fog működni.

  • Mi a helyzet a tápellátással/hűtéssel?
  • Milyen kapcsolat
  • Hol lesz telepítve?
  • Stb.

Ezeket a kérdéseket gyakran természetesnek veszik, és nem veszik különösebben figyelembe, de néha ezek azok, amelyek mindent megfordíthatnak.

Hogy

Eladó

A mai naptól (2019 közepétől) az orosz tárolási piac 5 kategóriába sorolható:

  1. A legmagasabb részleget a jól bejáratott cégek alkotják, amelyek a legegyszerűbbtől a csúcskategóriás lemezpolcok széles választékával rendelkeznek (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
  2. Második divízió - korlátozott vonallal rendelkező cégek, niche-játékosok, komoly SDS-szállítók vagy feltörekvő újoncok (Fujitsu, Datacore, Infinidat, Huawei, Pure stb.)
  3. Harmadik divízió - niche-megoldások az alsó kategóriákban, olcsó SDS, fejlett ceph-alapú termékek és más nyitott projektek (Infortrend, Starwind stb.)
  4. SOHO szegmens - otthoni/kisirodai szintű kis és ultra-kis tárolórendszerek (Synology, QNAP stb.)
  5. Import-helyettesített tárolórendszerek - ide tartozik mind az első részleg hardverei újracímkézett címkékkel, mind a második ritka képviselői (RAIDIX, a másodikat előre megadjuk), de főleg ez a harmadik divízió (Aerodisk, Baum, Depo stb.)

A felosztás meglehetősen önkényes, és egyáltalán nem jelenti azt, hogy a harmadik vagy SOHO szegmens rossz és nem használható. Konkrét projektekben egyértelműen meghatározott adatkészlettel és terhelési profillal nagyon jól tudnak működni, ár/minőség arányban messze felülmúlják az első osztályt. Fontos, hogy először döntsön a céljairól, a növekedési kilátásairól és a szükséges funkcionalitásáról – majd a Synology hűségesen szolgálja Önt, és haja puha és selymes lesz.

A szállító kiválasztásánál az egyik fontos tényező az aktuális környezet. Hány tárolórendszere van már, és milyen tárolórendszerekkel dolgozhatnak a mérnökei. Szüksége van egy másik szállítóra, egy másik kapcsolattartási pontra, fokozatosan migrálja a teljes terhelést A szállítóról B szállítóra?

Nem szabad olyan entitásokat előállítani, mint amennyire szükséges.

iSCSI/FC/Fájl

A mérnökök között nincs konszenzus a hozzáférési protokollok kérdésében, és a vita inkább teológiai, mint mérnöki vitákhoz hasonlít. Általánosságban azonban a következő pontokat lehet megjegyezni:

FCoE inkább halott, mint élő.

FC vs iSCSI. Az FC egyik legfontosabb előnyét 2019-ben az IP-tároláshoz képest, amely egy dedikált adatelérési gyár, amelyet egy dedikált IP-hálózat ellensúlyoz. Az FC-nek nincs globális előnye az IP-hálózatokkal szemben, és az IP bármilyen terhelési szintű tárolórendszer felépítésére használható, egészen a nagy bankok központi bankrendszerének nehéz DBMS-rendszereiig. Másrészt már több éve jósolják az FC halálát, de valami folyamatosan megakadályozza. Ma például a tárolási piac egyes szereplői aktívan fejlesztik az NVMEoF szabványt. Hogy osztozik-e az FCoE sorsában – az idő eldönti.

Fájl hozzáférés szintén nem érdemtelen figyelmet. Az NFS/CIFS jól teljesít a termelékenységi környezetekben, és ha helyesen tervezték, nincs több panasza, mint a blokkprotokolloknak.

Hibrid / All Flash Array

A klasszikus tárolórendszerek két típusban kaphatók:

  1. AFA (All Flash Array) – SSD-használatra optimalizált rendszerek.
  2. Hibrid – lehetővé teszi HDD és SSD vagy ezek kombinációjának használatát.

Legfőbb különbségük a támogatott tárolási hatékonysági technológiák és a maximális teljesítmény (magas IOPS és alacsony késleltetés). Mindkét rendszer (a legtöbb modellben, nem számítva a low-end szegmenst) képes blokk- és fájleszközként is működni. A támogatott funkcionalitás a rendszer szintjétől függ, és a fiatalabb modelleknél leggyakrabban minimális szintre csökken. Erre érdemes odafigyelni, amikor egy adott modell jellemzőit tanulmányozza, és nem csak a teljes vonal egészének képességeit. Természetesen a műszaki jellemzői, mint a processzor, a memória mennyisége, a gyorsítótár, a portok száma és típusa stb., szintén a rendszer szintjétől függenek. Menedzsment szempontból az AFA-k csak az SSD-meghajtókkal való munkavégzés mechanizmusainak megvalósításában különböznek a hibrid (lemezes) rendszerektől, és még ha hibrid rendszerben is SSD-t használ, ez egyáltalán nem jelenti azt, hogy képes lesz. egy AFA-rendszer szintű teljesítményszint elérése . Ezenkívül a legtöbb esetben a beépített hatékony tárolási mechanizmusok le vannak tiltva a hibrid rendszereken, és beépítésük teljesítménycsökkenéshez vezet.

Speciális tárolórendszerek

Az általános célú, elsősorban operatív adatfeldolgozásra koncentráló tárolórendszerek mellett léteznek speciális, a megszokottól alapvetően eltérő alapelvű tárolórendszerek (alacsony késleltetés, magas IOPS):

Média.

Ezeket a rendszereket nagy médiafájlok tárolására és feldolgozására tervezték. Ill. a késleltetés gyakorlatilag lényegtelenné válik, és előtérbe kerül a széles sávban történő adatküldés és -fogadás lehetősége számos párhuzamos adatfolyamban.

Tárolórendszerek duplikálása a biztonsági mentésekhez.

Mivel a biztonsági másolatokat az egymáshoz való hasonlóság különbözteti meg, ami normál körülmények között ritka (az átlagos biztonsági másolat 1-2%-kal tér el a tegnapi másolattól), ez a rendszerosztály rendkívül hatékonyan csomagolja a rajtuk rögzített adatokat egy meglehetősen kis keretbe. fizikai adathordozók száma. Például bizonyos esetekben az adattömörítési arány elérheti a 200:1-et.

Objektumtároló rendszerek.

Ezek a tárolórendszerek nem rendelkeznek a szokásos blokkos hozzáférésű kötetekkel és fájlmegosztásokkal, és leginkább egy hatalmas adatbázisra hasonlítanak. Az ilyen rendszerben tárolt objektumokhoz való hozzáférés egyedi azonosító vagy metaadatok alapján történik (például minden olyan JPEG formátumú objektum, amelynek létrehozási dátuma XX-XX-XXXX és YY-YY-YYYY között van).

Megfelelőségi rendszer.

Ma Oroszországban nem olyan gyakoriak, de érdemes megemlíteni. Az ilyen tárolórendszerek célja a garantált adattárolás a biztonsági szabályzatoknak vagy a szabályozási követelményeknek megfelelően. Egyes rendszerek (például az EMC Centera) olyan funkciót implementáltak, amely tiltja az adatok törlését – amint a kulcsot elfordítják és a rendszer ebbe a módba lép, sem a rendszergazda, sem más nem tudja fizikailag törölni a már rögzített adatokat.

Szabadalmaztatott technológiák

Flash gyorsítótár

A Flash-gyorsítótár az összes szabadalmaztatott technológia általános neve, amelyek a flash memóriát második szintű gyorsítótárként használják. Flash-gyorsítótár használatakor a tárolórendszert általában úgy számítják ki, hogy egyenletes terhelést biztosítson a mágneses lemezekről, míg a csúcsot a gyorsítótár szolgálja ki.

Ebben az esetben meg kell érteni a terhelési profilt és a tárolókötetek blokkjaihoz való hozzáférés lokalizációjának mértékét. A Flash-gyorsítótár olyan technológia, amely nagymértékben lokalizált lekérdezéseket tartalmazó munkaterhelésekhez használható, és gyakorlatilag nem alkalmazható egyenletesen betöltött köteteknél (például elemzőrendszereknél).

Két flash-gyorsítótár-megvalósítás érhető el a piacon:

  • Csak olvasható. Ebben az esetben csak az olvasott adatok kerülnek a gyorsítótárba, és az írás közvetlenül a lemezekre megy. Egyes gyártók, például a NetApp úgy vélik, hogy a tárolórendszereikre írás már optimális, és a gyorsítótár egyáltalán nem segít.
  • Ír olvas. Nem csak az olvasás, hanem az írás is gyorsítótárazott, ami lehetővé teszi a stream pufferelését és a RAID-büntetés hatásának csökkentését, ennek eredményeként pedig a kevésbé optimális írási mechanizmussal rendelkező tárolórendszerek általános teljesítményének növelését.

Többszintű

A többszintű tárolás (fárasztó) egy olyan technológia, amely a különböző teljesítményszintű szinteket, például az SSD-t és a HDD-t egyetlen lemeztárba kombinálja. Az adatblokkokhoz való hozzáférés kifejezett egyenetlensége esetén a rendszer képes lesz automatikusan kiegyenlíteni az adatblokkokat, a betöltötteket nagy teljesítményszintre mozgatva, a hidegeket pedig éppen ellenkezőleg, lassabbra.

Az alsó és középosztály hibrid rendszerei többszintű tárolást használnak, és az adatok ütemezetten mozognak a szintek között. Ugyanakkor a legjobb modellek többszintű tárolóblokkjának mérete 256 MB. Ezek a funkciók nem teszik lehetővé, hogy a többszintű tárolási technológiát a termelékenység növelésének technológiájának tekintsük, ahogyan azt sokan tévesen hiszik. A többszintű tárolás alacsony és középkategóriás rendszerekben egy olyan technológia, amely optimalizálja a tárolási költségeket olyan rendszerek esetében, ahol a terhelés egyenetlensége van.

Pillanatkép

Bármennyit is beszélünk a tárolórendszerek megbízhatóságáról, számos lehetőség adódik az adatok elvesztésére, amelyek nem függenek hardverproblémáktól. Ez lehet vírus, hacker vagy bármilyen más nem szándékos adattörlés/megsérülés. Emiatt a gyártási adatok biztonsági mentése a mérnök munkájának szerves részét képezi.

A pillanatfelvétel egy kötet pillanatfelvétele egy adott időpontban. Amikor a legtöbb rendszerrel dolgozik, például virtualizációval, adatbázisokkal stb. olyan pillanatképet kell készítenünk, amelyből az adatokat egy biztonsági másolatba másoljuk, miközben az IS biztonságosan folytathatja a munkát ezzel a kötettel. De érdemes megjegyezni, hogy nem minden pillanatfelvétel egyformán hasznos. A különböző szállítók eltérő módon közelítik meg az architektúrájukhoz kapcsolódó pillanatképek készítését.

Tehén (másolás-írás). Amikor megpróbál írni egy adatblokkot, annak eredeti tartalma egy speciális területre másolódik, majd az írás a szokásos módon megy végbe. Ez megakadályozza az adatok sérülését a pillanatfelvételen belül. Mindezek a „parazita” adatmanipulációk természetesen további terhelést okoznak a tárolórendszeren, ezért a hasonló implementációkkal rendelkező gyártók nem javasolják egy tucatnál több pillanatfelvétel használatát, és egyáltalán nem javasolják, hogy erősen terhelt köteteken használjuk őket.

sor (átirányítás íráskor). Ebben az esetben az eredeti kötet természetesen lefagy, és amikor egy adatblokkot próbál írni, a tárolórendszer egy speciális területre ír adatokat a szabad térben, megváltoztatva ennek a blokknak a helyét a metaadattáblázatban. Ez lehetővé teszi az újraírási műveletek számának csökkentését, ami végső soron kiküszöböli a teljesítmény csökkenését, és megszünteti a pillanatképekre és azok számára vonatkozó korlátozásokat.

A pillanatképek kétféle típusúak az alkalmazásokhoz kapcsolódóan:

Alkalmazási konzisztencia. A pillanatkép létrehozásának pillanatában a tárolórendszer behív egy ügynököt a fogyasztó operációs rendszerébe, amely erőszakkal üríti ki a lemez gyorsítótárait a memóriából a lemezre, és erre kényszeríti az alkalmazást. Ebben az esetben a pillanatképből történő visszaállításkor az adatok konzisztensek lesznek.

Összeomlás következetes. Ebben az esetben semmi ilyesmi nem történik, és a pillanatkép úgy jön létre, ahogy van. Egy ilyen pillanatfelvételből való helyreállítás esetén a kép megegyezik azzal, ami akkor történne, ha hirtelen kikapcsolnák az áramellátást, és előfordulhat, hogy a gyorsítótárakba ragadva és soha nem érve el a lemezt. Az ilyen pillanatképek könnyebben megvalósíthatók, és nem okoznak teljesítménycsökkenést az alkalmazásokban, de kevésbé megbízhatóak.

Miért van szükség pillanatképekre a tárolórendszereken?

  • Ügynök nélküli biztonsági mentés közvetlenül a tárolórendszerről
  • Hozzon létre tesztkörnyezeteket valós adatok alapján
  • Fájltároló rendszerek esetén VDI-környezetek létrehozására használható hipervizor helyett tárolórendszer-pillanatképek használatával.
  • Biztosítsa az alacsony RPO-kat úgy, hogy ütemezett pillanatfelvételeket készít a biztonsági mentés gyakoriságánál lényegesen magasabb gyakorisággal

Klónozása

Kötet klónozás - hasonló elven működik, mint a pillanatképek, de nem csak adatok olvasására, hanem teljes körű munkára is használják. A kötetünkről pontos másolatot kaphatunk, minden adattal, fizikai másolat készítése nélkül, ami helyet takarít meg. A kötet klónozását általában a Test&Dev programban használják, vagy ha ellenőrizni szeretné az IS egyes frissítéseinek működését. A klónozás lehetővé teszi, hogy ezt a lehető leggyorsabban és leggazdaságosabban végezze el a lemez erőforrások szempontjából, mert Csak a megváltozott adatblokkok kerülnek kiírásra.

Replikáció / Naplózás

A replikáció egy másik fizikai tárolórendszeren lévő adatok másolatának létrehozására szolgáló mechanizmus. Általában minden szállító rendelkezik saját technológiával, amely csak a saját termékcsaládján belül működik. De léteznek harmadik féltől származó megoldások is, beleértve azokat, amelyek hypervisor szinten működnek, például a VMware vSphere Replication.

A szabadalmaztatott technológiák funkcionalitása és könnyű használhatósága általában sokkal jobb, mint az univerzálisoké, de alkalmatlannak bizonyulnak, ha például NetApp-ról HP MSA-ra kell replikát készíteni.

A replikáció két altípusra oszlik:

Szinkron. Szinkron replikáció esetén az írási művelet azonnal elküldésre kerül a második tárolórendszernek, és a végrehajtást csak a távoli tárolórendszer megerősíti. Emiatt a hozzáférési késleltetés megnő, de az adatok pontos tükörmásolatával rendelkezünk. Azok. RPO = 0 a fő tárolórendszer elvesztése esetén.

aszinkron. Az írási műveletek csak a fő tárolórendszeren hajtódnak végre, és azonnal megerősítésre kerülnek, miközben egy pufferben halmozódnak fel a távoli tárolórendszerbe történő kötegelt átvitelhez. Ez a replikációs típus kevésbé értékes adatok, vagy alacsony sávszélességű vagy nagy késleltetésű csatornák esetében releváns (100 km-nél nagyobb távolságokra jellemző). Ennek megfelelően RPO = csomagküldési frekvencia.

Gyakran a replikáció mellett van egy mechanizmus is fakitermelés lemezműveletek. Ebben az esetben egy speciális terület van kijelölve a fakitermeléshez, és bizonyos időmélységű, vagy a rönk térfogata által korlátozott műveletek rögzítésére kerül sor. Bizonyos védett technológiák, például az EMC RecoverPoint esetében a rendszerszoftverrel való integráció lehetővé teszi bizonyos könyvjelzők egy adott naplóbejegyzéshez való kapcsolását. Ennek köszönhetően a kötet állapotát nem csak április 23-ra, 11 óra 59 másodpercre 13 ezredmásodpercre lehet visszagörgetni (vagy klónt létrehozni), hanem a „DROP ALL TABLES; ELKÖVETNI."

Metró klaszter

A Metro cluster egy olyan technológia, amely lehetővé teszi kétirányú szinkron replikáció létrehozását két tárolórendszer között oly módon, hogy ez a pár kívülről egy tárolórendszernek tűnjön. Metró távolságra (100 km-nél kisebb) földrajzilag elválasztott karokkal rendelkező klaszterek létrehozására szolgál.

A virtualizációs környezetben való felhasználás példája alapján a metrocluster lehetővé teszi egy virtuális gépekkel rendelkező adattár létrehozását, amely egyszerre két adatközpontból érhető el rögzítésre. Ebben az esetben egy fürt jön létre a hypervisor szintjén, amely különböző fizikai adatközpontokban lévő gazdagépekből áll, amelyek ehhez az adattárhoz kapcsolódnak. Ez lehetővé teszi a következőket:

  • A helyreállítási folyamat teljes automatizálása az egyik adatközpont halála után. További pénzeszközök nélkül az elhalálozott adatközpontban futó összes virtuális gép automatikusan újraindul a fennmaradóban. RTO = magas rendelkezésre állású fürt időtúllépés (15 másodperc VMware esetén) + az operációs rendszer betöltésének és a szolgáltatások elindításának ideje.
  • Katasztrófák elkerülése vagy oroszul katasztrófák elkerülése. Ha az 1-es adatközpontban áramellátási munkákat tervezünk, akkor lehetőségünk van a teljes fontos terhelést előre, a munka megkezdése előtt non-stop migrálni a 2-es adatközpontba.

Virtualizáció

A tárolóvirtualizáció technikailag egy másik tárolórendszerből származó kötetek lemezként történő felhasználása. A tárolóvirtualizátor egyszerűen átadhatja valaki más kötetét a fogyasztónak sajátjaként, egyidejűleg tükrözve azt egy másik tárolórendszerre, vagy akár RAID-et is létrehozhat külső kötetekből.
A tárolási virtualizációs osztály klasszikus képviselői az EMC VPLEX és az IBM SVC. És természetesen tárolórendszerek virtualizációs funkciókkal - NetApp, Hitachi, IBM / Lenovo Storwize.

Miért lehet rá szükség?

  • Redundancia a tárolórendszer szintjén. A kötetek között tükör jön létre, és az egyik fele a HP 3Par-on, a másik a NetApp-on lehet. A virtualizáló pedig az EMC-től származik.
  • Az adatokat minimális állásidővel mozgassa a különböző gyártók tárolórendszerei között. Tételezzük fel, hogy az adatokat a régi 3Par-ból kell áttelepíteni az új Dellbe. Ebben az esetben a fogyasztók lekapcsolódnak a 3Par-ról, a kötetek VPLEX alatt kerülnek átvitelre, és újra megjelennek a fogyasztóknak. Mivel a hangerőn egy cseppet sem változott, a munka folytatódik. A kötet tükrözésének folyamata az új Dellre a háttérben kezdődik, és a befejezés után a tükör megsérül, és a 3Par le van tiltva.
  • Metroklaszterek szervezése.

Tömörítés/deduplikáció

A tömörítés és a deduplikáció olyan technológiák, amelyek lehetővé teszik, hogy lemezterületet takarítson meg a tárolórendszeren. Rögtön meg kell említeni, hogy elvileg nem minden adat esik tömörítésre és/vagy deduplikációra, míg bizonyos típusú adatok jobban tömöríthetők és deduplikálhatók, és vannak, amelyek fordítva.

A tömörítésnek és a deduplikációnak két típusa van:

Sorban — az adatblokkok tömörítése és duplikálása az adatok lemezre írása előtt megtörténik. Így a rendszer csak a blokk hash-jét számítja ki, és a táblázatban összehasonlítja a meglévőkkel. Egyrészt gyorsabb, mint a lemezre írás, másrészt nem pazarolunk felesleges lemezterületet.

állás - amikor ezeket a műveleteket a lemezeken lévő, már rögzített adatokon hajtják végre. Ennek megfelelően az adatokat először a lemezre írják, és csak ezután számítják ki a hash-t, és törlik a felesleges blokkokat, és felszabadítják a lemez erőforrásait.

Érdemes elmondani, hogy a legtöbb szállító mindkét típust használja, ami lehetővé teszi számukra, hogy optimalizálják ezeket a folyamatokat, és ezáltal növeljék hatékonyságukat. A legtöbb tárológyártó rendelkezik olyan segédprogramokkal, amelyek lehetővé teszik az adatkészletek elemzését. Ezek a segédprogramok ugyanazon logika szerint működnek, mint a tárolórendszerben, így a becsült hatékonysági szint ugyanaz lesz. Ne feledje továbbá, hogy sok gyártó rendelkezik teljesítménygarancia programokkal, amelyek bizonyos (vagy az összes) adattípushoz legalább olyan jó teljesítményt ígérnek. És nem szabad elhanyagolni ezt a programot, mert a rendszer kiszámításával a feladataihoz, figyelembe véve egy adott rendszer hatékonysági együtthatóját, megtakaríthatja a mennyiséget. Érdemes azt is figyelembe venni, hogy ezeket a programokat AFA-rendszerekhez tervezték, de a klasszikus rendszerekben lévő HDD-knél kisebb mennyiségű SSD-k vásárlásának köszönhetően ez csökkenti azok költségeit, és ha nem egyenlő egy lemezrendszer költségével, akkor egészen közel kerülni hozzá.

Modell

És itt elérkeztünk a helyes kérdéshez.

„Két tárolási lehetőséget kínálnak – ABC SuperStorage S600 és XYZ HyperOcean 666v4, mit ajánlasz?”

„Itt két tárolási lehetőséget kínálnak nekem – ABC SuperStorage S600 és XYZ HyperOcean 666v4, mit ajánlasz?

A célterhelés vegyes VMware virtuális gépek termelési/tesztelési/fejlesztési hurokkal. Teszt = produktív. 150 TB egyenként 80 000 IOPS 8kb csúcsteljesítménnyel, 50%-os véletlen hozzáférésű 80/20 írás-olvasás. 300 TB fejlesztésre, 50 000 IOPS elég, 80 random, 80 írás.

Termelékenység feltehetően a metroklaszterben RPO = 15 perc RTO = 1 óra, fejlesztés aszinkron replikációban RPO = 3 óra, teszt egy helyen.

Lesz egy 50TB-os DBMS, jó lenne nekik a naplózás.

Mindenhol vannak Dell szervereink, régi Hitachi tárolórendszereink, alig bírják, a terhelést 50%-kal tervezzük növelni mennyiségben és teljesítményben.”

Ahogy mondani szokták, egy helyesen megfogalmazott kérdés a válasz 80%-át tartalmazza.

további információk

Amit még érdemes elolvasni a szerzők szerint

könyvek

  • Olifer és Olifer „Számítógépes hálózatok”. A könyv segít rendszerezni és talán jobban megérteni az IP/Ethernet tárolórendszerek adatátviteli közegének működését
  • "EMC információ tárolása és kezelése." Kiváló könyv a tárolási rendszerek alapjairól, a miértekről, a hogyanokról és a miértekről.

Fórumok és csevegések

Általános ajánlások

Árak

Nos, ami az árakat illeti - általában, ha vannak tárolórendszerek árai, azok általában Listaárak, amelyekből minden vásárló egyedi kedvezményt kap. A kedvezmény mértéke nagyszámú paraméterből áll, így egyszerűen lehetetlen megjósolni, hogy a forgalmazó megkérdezése nélkül milyen végső árat kap a cége. Ugyanakkor az utóbbi időben az alacsony kategóriás modellek elkezdtek megjelenni a szokásos számítógépes boltokban, mint például nix.ru vagy xcom-shop.ru. Itt azonnal megvásárolhatja az Önt érdeklő rendszert fix áron, mint bármely számítógépes alkatrészt.

De rögtön meg szeretném jegyezni, hogy a TB/$ közvetlen összehasonlítása nem helyes. Ha ebből a szemszögből közelítjük meg, akkor a legolcsóbb megoldás egy egyszerű JBOD + szerver lesz, ami nem biztosítja sem azt a rugalmasságot, sem a megbízhatóságot, amit egy teljes értékű, kétvezérlős tárolórendszer nyújt. Ez egyáltalán nem jelenti azt, hogy a JBOD undorító és csúnya piszkos trükk, csak ismét nagyon világosan meg kell értenie, hogyan és milyen célokra használja ezt a megoldást. Gyakran hallani, hogy a JBOD-ban nincs mit eltörni, csak egy hátlap van. A hátlapok azonban néha meghibásodnak. Minden elromlik előbb-utóbb.

Összességében

A rendszereket nem csak ár, vagy nem csak teljesítmény, hanem az összes mutató összessége alapján kell összehasonlítani egymással.

Csak akkor vásároljon HDD-t, ha biztos abban, hogy HDD-re van szüksége. Kis terhelések és tömöríthetetlen adattípusok esetén egyébként érdemes az SSD tárhelyhatékonysági garanciaprogramokhoz folyamodni, amelyekkel a legtöbb gyártó már rendelkezik (és valóban működnek még Oroszországban is), de minden a megtalálni kívánt alkalmazásoktól és adatoktól függ. ezen a tárolórendszeren.

Ne menjen olcsón. Néha ezek sok kellemetlen pillanatot rejtenek, amelyek közül az egyiket Jevgenyij Elizarov leírta cikkeiben Infortrend. És hogy a végén ez az olcsóság visszaüthet rád. Ne felejtsd el: "a fösvény kétszer fizet."

Forrás: www.habr.com

Hozzászólás