{"id":36005,"date":"2019-10-31T22:09:06","date_gmt":"2019-10-31T19:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/otkazoustojchivost-v-shd-qsan\/"},"modified":"2019-10-31T22:09:06","modified_gmt":"2019-10-31T19:09:06","slug":"otkazoustojchivost-v-shd-qsan","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/otkazoustojchivost-v-shd-qsan","title":{"rendered":"T\u00f5rkekindlus Qsan andmesalvestuss\u00fcsteemides","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

T\u00e4nap\u00e4eva IT-infrastruktuuris, kus virtuaalsus on laialdaselt kasutusel, on andmesalvestuss\u00fcsteemid tuum, mis hoiab k\u00f5iki virtuaalseid masinaid. Selle s\u00f5lme rike v\u00f5ib t\u00e4ielikult peatada andmekeskuse t\u00f6\u00f6. Kuigi suur osa serveritehnoloogiast on teatud m\u00e4\u00e4ral \u201evaikimisi\u201d rikke\u00f5hutust, esitavad just andmesalvestuss\u00fcsteemid andmekeskuse raames k\u00f5rgemaid n\u00f5udeid selle \u201epikkaealisusele\u201d.<\/p>\n

<\/p>\n

\"T\u00f5rkekindlus
\n<\/a><\/noindex><\/p>\n

K\u00f5ige t\u00f5husam viis rikke\u00f5hutuse tagamiseks IT-s on mitme seadme ja tarkvara (Lihtsaim juhul \u2013 andmete duplikeerimise) kasutamine. Loomulikult saab andmesalvestuss\u00fcsteemi t\u00e4ielikult duplikeerida. Just selline l\u00e4henemine toimub katastroofide taastamiseks. Kuid selline lahendus ei ole k\u00f5igile ettev\u00f5tetele taskukohane. R\u00e4\u00e4gime isegi mitte ainult varustatud seadmete kahekordistumisest, vaid ka muust kuludest sellise lahenduse korraldamisel ja selle edasises toetamisel. <\/p>\n

<\/p>\n

Kuid seadmete duplikeerimise v\u00f5imalus ei muuda vajalikuks tagada rikke\u00f5hutust komponentide tasandil. Eelk\u00f5ige rakendatakse andmesalvestuss\u00fcsteemis toiteallikate, jahutuss\u00fcsteemide, salvestite ja loomulikult kontrollerite reservi. K\u00f5ik see on juba ammu saanud tavap\u00e4raseks. On raske leida andmesalvestuss\u00fcsteemi, mis ei kasuta sellist disaini. Qsan <\/a><\/noindex>siin \u2013 pole erand. Kuid selles artiklis tahame r\u00e4\u00e4kida sellest, mis ei torka kohe silma ja on suunatud eelk\u00f5ige s\u00fcsteemi kogu rikke\u00f5hutuse suurendamisele.<\/p>\n

<\/p>\n

Jahutuss\u00fcsteemid<\/h3>\n

<\/p>\n

V\u00e4ga sageli kasutatakse 2U-3U korpustega kombineeritud mooduleid, mis \u00fchendavad toiteplokid ja ventilaatorid. \u00dchelt poolt on see mugav, kuna hooldust vajab vaid \u00fcks plokk. Teiselt poolt, kui jahutuss\u00fcsteem rikub, v\u00f5ib toiteplokk automaatselt v\u00e4lja l\u00fclituda \u00fclekuumenemise v\u00e4ltimiseks. Ja kuigi see v\u00f5ib tunduda mitte k\u00f5ige kriitilisema olukorrana, ei tohiks siiski andmesalvestuss\u00fcsteemi haavatavusi lisada. Salvestusseadmed <\/a><\/noindex>jahtudes<\/p>\n

<\/p>\n

Qsan'i salvestuss\u00fcsteemides jahutus on korraldatud eraldi moodulitena, mis v\u00f5imaldavad \u201ekuuma\u201c vahetust, s\u00f5ltumatult toiteplokkidest. Toiteplokkides on oma ventilatorid, mis on m\u00f5eldud plokkide jahutamiseks. Jahutusmoodul sisaldab kahte s\u00f5ltumatut ventilatorit, mis t\u00f6\u00f6tavad omavahel koos. Selliseid mooduleid on salvestuss\u00fcsteemis kaks: paremal ja vasakul \u2013 k\u00f5igi komponentide t\u00f5husaks jahutamiseks. Kui \u00fcks ventilaatoreist rikki l\u00e4heb, suurendavad k\u00f5ik \u00fclej\u00e4\u00e4nud automaatselt oma p\u00f6\u00f6rdeid, et kompenseerida tekkinud \u00f5huvoo puuduj\u00e4\u00e4ki. Seet\u00f5ttu ei p\u00f5hjusta ventilatori rike kogu seadme \u00fclekuumenemise ohtu.<\/p>\n

<\/p>\n

Lisapinkide \u00fchendustopoloogia<\/h3>\n

<\/p>\n

Klassikaline \u00fchendusskeem laiendush\u00fctid<\/a><\/noindex> salvestuss\u00fcsteemide jaoks t\u00e4histab topoloogiat nimega kaskaad. Sellisel juhul \u00fchendatakse vastavad riiulite ja salvestuss\u00fcsteemide kontrollerid omavahel \u00fche SAS-kaabli kaudu. Kokku on kahe kontrolleriga s\u00fcsteemis 2 kaablit. Kui on vaja \u00fchendada teine, siis see \u00fchendatakse esimesse riiulisse sama meetodi abil. Ja nii edasi. Selle topoloogia pluss on seadme lihtne teostamine. Miinuseks on teatav haavatavus SAS-ahela \u00e4kilise katkestamise suhtes, mis tuleneb \u00fchendamata kontrollerite ja riiulite ohtlikest riketest v\u00f5i \u00fche lisariiuli toite kadumisest ahela keskel. Tulemuseks on juurdep\u00e4\u00e4su kaotamine osadele ketastele ning v\u00f5imalik RAID-grupi lagunemine, kui see on jaotatud mitme korpuse vahel.<\/p>\n

<\/p>\n

Qsan'il on kaitse kontrollerite ristkatkestuste eest, mis seisneb kontrollerite vahelises sisemises loogilises \u00fchenduses l\u00e4bi salvestuss\u00fcsteemi tagaplaadi. See t\u00e4hendab, et salvestuss\u00fcsteemi kontroller n\u00e4eb mitte ainult JBOD kontrollerit, mis on temaga otseselt \u00fchendatud, vaid ka \u201enaabri\u201c kontrollerit erilise lingi kaudu tagaplaadil. Seet\u00f5ttu, kui selline olukord tekib ja keegi ei t\u00f5mba f\u00fc\u00fcsiliselt SAS-kaableid salvestuss\u00fcsteemi ja riiuli vahel v\u00e4lja, s\u00e4ilib juurdep\u00e4\u00e4s k\u00f5igile ketastele.<\/p>\n

<\/p>\n

\"T\u00f5rkekindlus<\/p>\n

SAS ahela katkestuste, n\u00e4iteks \u00fche lisariiuli toite kadumise, v\u00e4ltimiseks kasutatakse tavaliselt teistsugust \u00fchendustopoloogiat \u2013 tagakaskaadi. Sellisel juhul \u00fchendatakse salvestuss\u00fcsteem otse esimese ja viimase riiuliga ahelas, saades juurdep\u00e4\u00e4su ketastele justkui kahest k\u00fcljest.<\/p>\n

<\/p>\n

\"T\u00f5rkekindlus<\/p>\n

Kui soovite tugevamat kaitset, saate luua suuremaid konfiguratsioone, kasutades n\u00e4iteks puutopoloogiat. V\u00f5i saate teha keerulisemaks, kombineerides juba mainitud topoloogiaid. See on v\u00f5imalik t\u00e4nu suurele hulgale SAS-pistikutega seadmetel (2 igal salvestusruumi kontrolleril ja 5 igal JBOD kontrolleril), mis toetavad automaatset t\u00f6\u00f6re\u017eiimide tuvastamist. Peamine on, et administraator ise ei segaks asja \u00e4ra. Ja salvestusruum suudab konfiguratsiooni \u00f5igesti seadistada.<\/p>\n

<\/p>\n

Kiire taastamine<\/h3>\n

<\/p>\n

S\u00fcsteemis olevad kuumalt vahetatavad varudiskid (hot spare) suurendavad oluliselt andmete s\u00e4ilitamise usaldusv\u00e4\u00e4rsust. Kuid lihtsalt selliste kettaste eraldamine ei t\u00e4henda absoluutset kaitset. Asi on selles, et taastamisprotsess (rebuilt) on piisavalt t\u00f6\u00f6mahukas ja tihti aega n\u00f5udev. T\u00f6\u00f6mahu suurenemine tuleneb j\u00e4tkuvast ligip\u00e4\u00e4sust p\u00f5hisisule. Teisis\u00f5nu, s\u00fcsteem peab koos k\u00e4imasoleva t\u00f6\u00f6ga andmed uuele kettale kopeerima. Ja taastamise kestus s\u00f5ltub otseselt salvestusruumi mahust ja selle j\u00f5udluse omadustest. Kuna s\u00fcsteem ei tea, kui palju ruumi on kettadel tegelikult h\u00f5ivatud, kopeerib ta taastamise k\u00e4igus lihtsalt k\u00f5ik: plokk haaval. <\/p>\n

<\/p>\n

Tulemuseks on, et kaasaegse suure mahuga ketta taastamine 10+ TB puhul t\u00f5sise koormusega salvestusruumil v\u00f5ib kergesti kesta n\u00e4dal v\u00f5i kauem. Samuti tuleks meeles pidada, et taastamise ajal suureneb oluliselt t\u00f5en\u00e4osus, et muud kettad eba\u00f5nnestuvad nendele suure koormuse t\u00f5ttu. See v\u00f5ib kujutada t\u00f5sist ohtu, kui n\u00e4iteks kasutatakse RAID5.<\/p>\n

<\/p>\n

Selle probleemi lahendamiseks on paljud salvestusruumi arendajad mures taastamisprotsessi kiirendamise p\u00e4rast. Selleks v\u00f5ib rakendada erinevaid l\u00e4henemisviise, kuid p\u00f5him\u00f5te on \u00fcks \u2013 taastamise k\u00e4igus tuleb kopeerida ainult t\u00f5eliselt h\u00f5ivatud plokke. Qsan ei j\u00e4\u00e4 sellest probleemist k\u00f5rvale. Selle tarnija salvestusruumidel, kui on aktiveeritud valik Kiire taastamine<\/a><\/noindex> s\u00fcsteem j\u00e4lgib kirjutamiseks kasutatavaid plokke ja suudab seega ketta eba\u00f5nnestumise korral kopeerida uuele kettale ainult need.<\/p>\n

<\/p>\n

\"T\u00f5rkekindlus<\/p>\n

Valik Kiire taastamine ei ole vaikimisi aktiveeritud uute volume'ide loomisel, kuna selle kasutamine m\u00f5jutab j\u00f5udlust, eriti juhuslike kirjutuste toimingute korral, kuna:<\/p>\n

<\/p>\n

    \n
  1. Track record entries in blocks;<\/li>\n
  2. 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.<\/li>\n<\/ol>\n

    <\/p>\n

    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.<\/p>\n

    <\/p>\n

    L\u00f5petuseks<\/h2>\n

    <\/p>\n

    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: <\/p>\n

    <\/p>\n