Tänapäeva IT-infrastruktuuris, kus virtuaalsus on laialdaselt kasutusel, on andmesalvestussüsteemid tuum, mis hoiab kõiki virtuaalseid masinaid. Selle sõlme rike võib täielikult peatada andmekeskuse töö. Kuigi suur osa serveritehnoloogiast on teatud määral „vaikimisi” rikkeõhutust, esitavad just andmesalvestussüsteemid andmekeskuse raames kõrgemaid nõudeid selle „pikkaealisusele”.
Kõige tõhusam viis rikkeõhutuse tagamiseks IT-s on mitme seadme ja tarkvara (Lihtsaim juhul – andmete duplikeerimise) kasutamine. Loomulikult saab andmesalvestussüsteemi täielikult duplikeerida. Just selline lähenemine toimub katastroofide taastamiseks. Kuid selline lahendus ei ole kõigile ettevõtetele taskukohane. Räägime isegi mitte ainult varustatud seadmete kahekordistumisest, vaid ka muust kuludest sellise lahenduse korraldamisel ja selle edasises toetamisel.
Kuid seadmete duplikeerimise võimalus ei muuda vajalikuks tagada rikkeõhutust komponentide tasandil. Eelkõige rakendatakse andmesalvestussüsteemis toiteallikate, jahutussüsteemide, salvestite ja loomulikult kontrollerite reservi. Kõik see on juba ammu saanud tavapäraseks. On raske leida andmesalvestussüsteemi, mis ei kasuta sellist disaini. siin – pole erand. Kuid selles artiklis tahame rääkida sellest, mis ei torka kohe silma ja on suunatud eelkõige süsteemi kogu rikkeõhutuse suurendamisele.
Jahutussüsteemid
Väga sageli kasutatakse 2U-3U korpustega kombineeritud mooduleid, mis ühendavad toiteplokid ja ventilaatorid. Ühelt poolt on see mugav, kuna hooldust vajab vaid üks plokk. Teiselt poolt, kui jahutussüsteem rikub, võib toiteplokk automaatselt välja lülituda ülekuumenemise vältimiseks. Ja kuigi see võib tunduda mitte kõige kriitilisema olukorrana, ei tohiks siiski andmesalvestussüsteemi haavatavusi lisada. jahtudes
Qsan'i salvestussüsteemides jahutus on korraldatud eraldi moodulitena, mis võimaldavad „kuuma“ vahetust, sõltumatult toiteplokkidest. Toiteplokkides on oma ventilatorid, mis on mõeldud plokkide jahutamiseks. Jahutusmoodul sisaldab kahte sõltumatut ventilatorit, mis töötavad omavahel koos. Selliseid mooduleid on salvestussüsteemis kaks: paremal ja vasakul – kõigi komponentide tõhusaks jahutamiseks. Kui üks ventilaatoreist rikki läheb, suurendavad kõik ülejäänud automaatselt oma pöördeid, et kompenseerida tekkinud õhuvoo puudujääki. Seetõttu ei põhjusta ventilatori rike kogu seadme ülekuumenemise ohtu.
Lisapinkide ühendustopoloogia
Klassikaline ühendusskeem salvestussüsteemide jaoks tähistab topoloogiat nimega kaskaad. Sellisel juhul ühendatakse vastavad riiulite ja salvestussüsteemide kontrollerid omavahel ühe SAS-kaabli kaudu. Kokku on kahe kontrolleriga süsteemis 2 kaablit. Kui on vaja ühendada teine, siis see ühendatakse esimesse riiulisse sama meetodi abil. Ja nii edasi. Selle topoloogia pluss on seadme lihtne teostamine. Miinuseks on teatav haavatavus SAS-ahela äkilise katkestamise suhtes, mis tuleneb ühendamata kontrollerite ja riiulite ohtlikest riketest või ühe lisariiuli toite kadumisest ahela keskel. Tulemuseks on juurdepääsu kaotamine osadele ketastele ning võimalik RAID-grupi lagunemine, kui see on jaotatud mitme korpuse vahel.
Qsan'il on kaitse kontrollerite ristkatkestuste eest, mis seisneb kontrollerite vahelises sisemises loogilises ühenduses läbi salvestussüsteemi tagaplaadi. See tähendab, et salvestussüsteemi kontroller näeb mitte ainult JBOD kontrollerit, mis on temaga otseselt ühendatud, vaid ka „naabri“ kontrollerit erilise lingi kaudu tagaplaadil. Seetõttu, kui selline olukord tekib ja keegi ei tõmba füüsiliselt SAS-kaableid salvestussüsteemi ja riiuli vahel välja, säilib juurdepääs kõigile ketastele.
SAS ahela katkestuste, näiteks ühe lisariiuli toite kadumise, vältimiseks kasutatakse tavaliselt teistsugust ühendustopoloogiat – tagakaskaadi. Sellisel juhul ühendatakse salvestussüsteem otse esimese ja viimase riiuliga ahelas, saades juurdepääsu ketastele justkui kahest küljest.
Kui soovite tugevamat kaitset, saate luua suuremaid konfiguratsioone, kasutades näiteks puutopoloogiat. Või saate teha keerulisemaks, kombineerides juba mainitud topoloogiaid. See on võimalik tänu suurele hulgale SAS-pistikutega seadmetel (2 igal salvestusruumi kontrolleril ja 5 igal JBOD kontrolleril), mis toetavad automaatset töörežiimide tuvastamist. Peamine on, et administraator ise ei segaks asja ära. Ja salvestusruum suudab konfiguratsiooni õigesti seadistada.
Kiire taastamine
Süsteemis olevad kuumalt vahetatavad varudiskid (hot spare) suurendavad oluliselt andmete säilitamise usaldusväärsust. Kuid lihtsalt selliste kettaste eraldamine ei tähenda absoluutset kaitset. Asi on selles, et taastamisprotsess (rebuilt) on piisavalt töömahukas ja tihti aega nõudev. Töömahu suurenemine tuleneb jätkuvast ligipääsust põhisisule. Teisisõnu, süsteem peab koos käimasoleva tööga andmed uuele kettale kopeerima. Ja taastamise kestus sõltub otseselt salvestusruumi mahust ja selle jõudluse omadustest. Kuna süsteem ei tea, kui palju ruumi on kettadel tegelikult hõivatud, kopeerib ta taastamise käigus lihtsalt kõik: plokk haaval.
Tulemuseks on, et kaasaegse suure mahuga ketta taastamine 10+ TB puhul tõsise koormusega salvestusruumil võib kergesti kesta nädal või kauem. Samuti tuleks meeles pidada, et taastamise ajal suureneb oluliselt tõenäosus, et muud kettad ebaõnnestuvad nendele suure koormuse tõttu. See võib kujutada tõsist ohtu, kui näiteks kasutatakse RAID5.
Selle probleemi lahendamiseks on paljud salvestusruumi arendajad mures taastamisprotsessi kiirendamise pärast. Selleks võib rakendada erinevaid lähenemisviise, kuid põhimõte on üks – taastamise käigus tuleb kopeerida ainult tõeliselt hõivatud plokke. Qsan ei jää sellest probleemist kõrvale. Selle tarnija salvestusruumidel, kui on aktiveeritud valik süsteem jälgib kirjutamiseks kasutatavaid plokke ja suudab seega ketta ebaõnnestumise korral kopeerida uuele kettale ainult need.
Valik Kiire taastamine ei ole vaikimisi aktiveeritud uute volume'ide loomisel, kuna selle kasutamine mõjutab jõudlust, eriti juhuslike kirjutuste toimingute korral, kuna:
- Track record entries in blocks;
- During a rebuild, checksums for unoccupied space are not recalculated, so when a new entry is made in this area, it needs to be 'initialized' first.
Therefore, using Fast Rebuild is not recommended for volumes, for example, with high-load databases or in video surveillance systems, where the volume will ultimately be filled to 100%. However, for file or mail servers, this option can be very useful.
Lõpetuseks
Every storage system manufacturer assumes that its devices are reliable. And if there are no fatal flaws in the design of the devices and an incredible drive to save during their manufacturing and testing, then in general, one can agree with the vendor. However, it is important to understand:
- the basic fault tolerance of the storage system is primarily a way to continue having access to data in the event of a failure of any component(s);
- additional options regarding fault tolerance (like those described above) are exceptions to some fault scenarios and increase your chances of accessing data;
- 100% reliability, unfortunately, does not exist. But to get as close to it as possible, most reasonable storage system vendors (including ) make maximum efforts for continuous improvement of their products both in hardware and software.
At the same time, it is also important to remember that no absolute reliability of the storage system cancels the need for backups, clear and rehearsed recovery plans in case of a disaster, and prompt technical support from the vendor.
Allikas: habr.com
