Sissejuhatus
On aeg osta andmehaldussüsteem. Milline valida, keda kuulata? Vendor A räägib vendorist B, samas on ka integrator C, kes räägib vastupidist ja soovitab vendorit D. Sellises olukorras võib isegi kogenud andmesalvestuse arhitekti pea ringi käima minna, eriti kui arvestada kõiki uusi vendoreid ja tänapäeval moes olevaid SDS-i ja hüperkonvergentsi.
Nii et, kuidas selles kõiges orienteeruda ja mitte lolliks jääda? Meie ( Anton Zhbankov ja Evgeny Elizarov) proovime sellest rääkida eesti keeles.
Artikkel peegeldab paljusid aspekte ja on tegelikult laienduseks “” andmesalvestussüsteemide valiku ja tehnoloogiate ülevaate osas. Vaatame lühidalt üle üldise teooria, kuid soovitame tutvuda ka viidatud artikliga.
Miks
Sageli näeme olukorda, kus uus inimene tuleb foorumisse või spetsialiseeritud vestlusesse, nagu näiteks Storage Discussions, ja küsib: “mulle pakutakse kahte varianti andmehaldussüsteemist — ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitate?”
Ja alustatakse arutelu, millised on hirmutavate ja arusaamatute funktsioonide rakendamise erinevused, mis tunduvad täiesti arusaamatud valmistumata inimesele.
Seega, peamine ja esimene küsimus, mida endalt küsida enne, kui hakata vaatama spetsifikatsioone äripakkumistes — MILLEKS? Miks on vajalik see SALVESTUS?
Vastus tuleb ootamatu ja Tony Robbinse stiilis — et andmeid salvestada. Aitäh, kapten! Ja sellegipoolest, mõnikord süveneme detailide võrdlemisse nii sügavalt, et unustame, miks me seda üldse teeme.
Niisiis, andmete salvestamise süsteemi ülesanne on andmete salvestamine ja nendele eelneva jõudluse tagamine. Just andmetest alustame.
Andmed
Andmetüüp
Milliseid andmeid me plaanime salvestada? See on väga oluline küsimus, mis võib jätta paljusid salvestussüsteeme kõrvale. Näiteks plaanitakse salvestada videosid ja fotosid. Sellega saab kohe kõrvaldada süsteemid, mis on ette nähtud juhuslikuks juurdepääsuks väikeste plokkide kaupa või süsteemid, millel on kaubanduslikud omadused kompressioonis / deduplikatsioonis. Need võivad olla lihtsalt suurepärased süsteemid, me ei taha midagi halba öelda. Kuid antud juhul võivad nende tugevused muutuda vastupidiseks nõrkusteks (videod ja fotod ei kompressi) või lihtsalt suurendada süsteemi maksumust oluliselt.
Ja vastupidi, kui sihtkasutuseks on koormatud tehingute andmebaas, siis suurepärased voogedastusüsteemid meedia jaoks, mis suudavad anda gigabaitide kaupa sekundis, ei ole halb valik.
Andmete maht
Kuidas me plaanime andmeid salvestada? Kvaliteet tuleneb alati hulgast, seda ei tohi kunagi unustada, eriti praegusel ajal, mil andmete maht kasvab eksponentsiaalselt. Petabaitide klassi süsteemid ei ole enam haruldased, kuid mida suurem on petabaitide maht, seda spetsiifilisemaks muutub süsteem, ning seda vähem on saadaval tavalistele väikese ja keskmise mahuga süsteemidele tüüpilisi funktsioone. Lihtsalt seetõttu, et üksnes juurdepääsustatistika tabelid muutuvad suuremaks kui kontrollereid olemasolev operatiivmälu. Rääkimata kompressioonist või tihendamisest. Oletame, et tahame vahetada kompressioonialgoritmi võimsama vastu ja tihendada 20 petabaiti andmeid. Kui kaua see aega võtab: kuus kuud, aasta?
Teiselt poolt, miks luua suuri lahendusi, kui tuleb salvestada ja töödelda 500 GB andmeid? Ainult 500. Kodumaised SSD-d (madala DWPD-ga) sellise mahuga maksavad väga vähe. Miks ehitada selle jaoks Fiber Channeli tehast ja osta kõrgekvaliteediline väline andmesalvestussüsteem, mille hind on nagu rauast sild?
Kui suur on kuumade andmete osakaal kogumahust? Kui ebaühtlane on koormus andmemahtude lõikes? Just siin võib palju kasu olla mitme tasandi salvestustehnoloogiast või Flash Cache'ist, kui kuumade andmete maht on võrreldes kogumahuga minimaalne. Vastasel juhul, kui koormus on terve mahu lõikes ühtlane, mis on levinud voogesitussüsteemides (näiteks videovalve, mõned analüüsisüsteemid), ei too sellised tehnoloogiad midagi lisaks, ja suurendavad ainult süsteemi kulusid/puudusi.
IS
Andmete vastaspooleks on infotehnoloogia süsteem, mis kasutab neid andmeid. Infotehnoloogia süsteemil on hulk nõudeid, mis pärinevad andmetest. Lisainfot infotehnoloogia süsteemi kohta leiate artiklist 'Virtuaalsete andmekeskuste disain'.
Tõrkekindluse / kättesaadavuse nõuded
Andmete tõrkekindluse / kättesaadavuse nõuded pärinevad need andmeid kasutavast infosüsteemist ja väljenduvad kolmes numbris — RPO, RTO, saadavus.
Saadavus — ajavaus teatud ajavahemikuks, mille jooksul on andmed kergesti kättesaadavad. See väljendatakse tavaliselt numbritega 9. Näiteks kaks seitsme pinna mõttes tähistab, et kättesaadavus on 99%, või muul viisil aktsepteeritakse 95 tundi katkemist aastas. Kolm seitsme pinna mõttes — 9,5 tundi aastas.
RPO / RTO on näitajad, mis ei ole kogusummad, vaid iga sündmuse (hädaolu) jaoks eraldi, erinevalt kättesaadavusest.
RPO — andmete maht, mis kadus hädaolukorras (tundides). Näiteks, kui varundamine toimub üks kord päevas, siis RPO = 24 tundi. See tähendab, et hädaolukorra korral, kui kogu andmesalvestis on kadunud, võivad andmed, mis on kadunud, olla kuni 24 tundi (varukoopia hetkest). Tuginedes määratud RPO-le, saab näiteks koostada varundamise eeskirjad. Samuti, tuginedes RPO-le, on võimalik mõista, kui palju on vajalik sünkroonne / asünkroonne andmete replikatsioon.
RTO — teenuse (andmete kätte saamise) taastamisaeg pärast hädaolukorda. Võttes arvesse määratud RTO väärtust, saame aru, kas on vajalik metrokluster või piisab ühest suunatud replikatsioonist. Kas on vajalik kõrge klassi mitmekontrollerline andmesalvestus — samuti.
Tootmisvõimekuse nõuded
Kuigi see on ilmselgelt küsimus, on sellega seotud enamus raskusi. Sõltuvalt sellest, kas teil on juba mingisugune infrastruktuur või mitte, ja millised andmete kogumise teed rajatakse.
Teil on juba andmesalvestussüsteem (SXY) ja otsite sellele asendust või soovite osta veel ühe laiendamiseks. Siin on kõik lihtne. Te teate, millised teenused teil juba on ja milliseid kavatsete lähitulevikus juurutada. Praeguste teenuste põhjal on teil võimalus koguda andmeid jõudluse kohta. Otsustage praegune IOPS ja viivitused – kui head on need näitajad ja kas need on teie vajadustele piisavad? Seda saab teha nii andmesalvestussüsteemis kui ka hostide pool, mis sellele on ühendatud.
Tähtis on jälgida mitte ainult praegust koormust, vaid ka mingit ajavahemikku (soovitavalt kuu). Vaadake, millised on maksimaalsed tipud päevasel ajal, millist koormust põhjustab varundamine jne. Kui teie salvestusseade või selle tarkvara ei paku teile nende andmete täielikku kogumit, võite kasutada tasuta RRDtool'i, mis oskab töötada enamikuga populaarseimatest salvestusseadmetest ja lülititest ning suudab anda teile üksikasjalikku statistikat jõudluse kohta. Samuti tasub jälgida koormust ka hostides, mis töötavad selle salvestusseadmest, konkreetsete virtuaalmasinate või sellel hostil töötava koormuse osas.
Tuleb eraldi märkida, et kui viivitused mahtudes ja andmestores, mis asub antud mahus, erinevad märkimisväärselt — tasub tähelepanu pöörata teie SAN-võrgule, on suure tõenäosusega probleeme ja enne uue süsteemi ostmist tuleks sellega seotud küsimustega tegeleda, sest praeguse süsteemi jõudluse suurendamise tõenäosus on väga kõrge.
Te ehitat infrastruktuuri nullist või ostad süsteemi uue teenuse jaoks, mille koormustest sa ei tea. Siin on mitu varianti: rääkida kolleegidega spetsialiseeritud allikates, et proovida aru saada ja prognoosida koormust; pöörduda integratori poole, kellel on kogemusi sarnaste teenuste rakendamisel ja kes suudab teie eest koormust arvutada. Ja kolmas variant (tavaliselt kõige keerulisem, eriti kui see puudutab ise kirjutatud või haruldasi rakendusi) on proovida arendajatelt välja selgitada jõudlusnõuded.
Ja, tähelepanu, kõige õigem variant praktilise rakendamise seisukohalt on piloot praegusel seadmel või seadmel, mida pakub katsetamiseks tootja/integrator.
Spetsiaalsed nõuded
Spetsiaalsed nõuded — kõik, mis ei kuulu jõudluse, häireteta jätkusuutlikkuse ja funktsionaalsuse nõuete alla andmete vahetu töötlemisel ja edastamisel.
Üks lihtsamaid nõudeid andmesalvestussüsteemile on nn "võõrandatavad andmekandjad". Sellega on kohe selge, et antud andmesalvestussüsteem peab hõlmama lintbiblioteeki või lihtsalt lintseifi, kuhu kopeeritakse varukoopia. Pärast seda allkirjastab spetsiaalselt koolitatud isik lindi ja kannab selle uhkelt spetsiaalsesse seifi.
Teine näide spetsiaalsetest nõuetest on löögikindel täitmine.
Kus
Teine peamine aspekt SКD valimisel on teave selle kohta, KUS see SКD paikneb. Alates geograafiast ja kliimaoludest kuni personalini.
Tellija
Kellele on antud SКD planeeritud? Küsimus põhineb järgmistel kaalutlustel:
Riigihankija / kommerts.
Kommerts tellijal ei ole mingeid piiranguid ja ta ei pea isegi konkursse korraldama, välja arvatud oma sisemiste regulatsioonide alusel.
Riigihankija on teine asi. 44 FZ ja muud iludused koos konjunktsioonide ja spetsifikatsioonidega, mida saab vaidlustada.
Tellija on sanktsioonide all.
Siin on küsimus väga lihtne — valik piirdub ainult sellele kliendile saadaval olevate pakkumistega.
Sisemised eeskirjad / lubatud ostmiseks müüjad / mudelid
Küsimus on samuti äärmiselt lihtne, kuid seda tuleks meeles pidada.
Kus füüsiliselt
Selles osas käsitleme kõiki küsimusi seonduvalt geograafia, sidekanalite ja ruumilise mikrokliimaga.
Personal
Kes töötab antud andmesalvestussüsteemiga? See on sama oluline kui see, mida andmesalvestussüsteem otse suudab.
Kui palju iganes on andmesalvestussüsteem A perspektiivne, äge ja suurepärane, siis pole selle paigaldamisel ilmselt mõtet, kui personal oskab töötada ainult müüjaga B, ega plaanita edasisi oste ega pidevat koostööd A-ga.
Ja loomulikult on tagapool küsimus — kui kergesti on sel konkreetsel geograafilisel alal saadaval kvalifitseeritud personal ettevõtte sees ja potentsiaalselt tööturul. Piirkondade jaoks võib olla oluline valida salvestuslahendused, millel on lihtsad liidesed või võimalus kaugtasandil keskset juhtimist. Muidu võib mingil hetkel muutuda see äärmiselt valusaks. Internet on täis lugusid, kuidas uus töötaja, kes oli eile tudeng, seadistas midagi sellist, et kogu ettevõte kukkus kokku.
Keskkond
Ja loomulikult on oluline küsimus — millises keskkonnas see salvestuslahendus töötama hakkab.
- Kuidas on lood elektri ja jahutusega?
- Milline on ühendamine
- Kuhu see paigaldatakse
- Ja nii edasi.
Sageli peetakse neid küsimusi iseenesestmõistetavaks ja neid ei analüüsita süvitsi, kuid vahel võivad just need muutuda kõike pööravaks.
Mida
Tarnija
Tänase seisuga (2019. aasta keskpaik) võib Venemaa salvestuslahenduste turu jagada tinglikult viieks kategooriaks:
- Ülemine liiga — tuntud ettevõtted laia tooteportfelliga alates kõige lihtsamatest kettapinkidest kuni tipptasemeni (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Teine divisjon — ettevõtted, kelle tooteportfell on piiratud, nišimängijad, tõsised SDS tarnijad või uued tulijad (Fujitsu, Datacore, Infinidat, Huawei, Pure jne)
- Kolmas divisjon — nišilahendused madala hinnaklassi, odav SDS, odavad lahendused Cephil ja teistel avatud projektidel (Infortrend, Starwind jne)
- SOHO segment — väikesed ja üliväikesed andmesalvestusseadmed kodu/ väikese büroo tasemel (Synology, QNAP jne)
- Imposteeritud andmesalvestusseadmed — siia kuuluvad nii esimese divisjoni seadmed, millele on liimitud teised sildid, kui ka haruldased teise divisjoni esindajad (RAIDIX, anname neile eelise teise divisjoni osas), kuid enamasti on need kolmas divisjon (Aerodisk, Baum, Depo jne)
Jaotus on piisavalt tinglik ja ei tähenda, et kolmas või SOHO segment oleks halb ja seda ei tohiks kasutada. Spetsiifilistes projektides, kus on täpselt määratletud andmestik ja koormusprofiil, võivad need töötada väga hästi, ületades esimest divisjoni hinna/kvaliteedi suhe. Oluline on kõigepealt määratleda ülesanded, kasvu võimalused, nõutavad funktsioonid — ja siis teenib Synology teid usaldusväärselt, samal ajal kui juuksed muutuvad pehmeks ja siidiseks.
Üks olulisi tegureid teenusepakkuja valimisel on praegune keskkond. Kui palju ja milliseid salvestusseadmeid teil juba on ning milliste salvestusseadmetega suudavad insenerid töötada. Kas on vajalik veel üks teenusepakkuja, veel üks kontaktpunkt, kavatsete tõsta kogu koormuse aeglaselt teenusepakkuja A-lt teenusepakkuja B-le?
Ei tohiks luua rohkem üksusi kui vajalik.
iSCSI / FC / File
Ligipääsuprotokollide osas pole inseneride seas konsensust, vaidlused meenutavad pigem teoloogilisi arutelusid kui inseneritehnilisi. Kuid üldiselt võib märkida järgmisi punkte:
FCoE on pigem surnud kui elus.
FC vs iSCSI. Üks FC peamisi eeliseid 2019. aastal IP salvestusseadmete ees, eraldatud tehase ligipääsuks andmetele, tasakaalustatakse eraldatud IP võrguga. FC-l pole globaalset üleolekut IP-võrkude ees, ja IP-põhiseid salvestusseadmeid saab ehitada igasuguste koormuste jaoks, sealhulgas suure pankade ABSe jaoks, mis nõuavad raskete andmebaaside süsteeme. Teisest küljest on FC surma tõukesüsteeme ennustatud juba aastaid, kuid sellele takistab pidevalt miski. Näiteks arendavad mõned turu mängijad aktiivselt NVMEoF standardit. Kas see jagab FCoE saatuse — näitab aeg.
Faili ligipääs ei ole midagi, mida võiks tähelepanuta jätta. NFS / CIFS toimivad suurepäraselt tootmiskeskkondades ja korraliku projekteerimise korral ei ole neil rohkem kaebusi kui plokkprotokollidel.
Hübriidne / All Flash Array
Klassikalised andmehoidlad jagunevad kaheks:
- AFA (All Flash Array) — süsteemid, mis on optimeeritud SSD-de kasutamiseks.
- Hübriidsed — võimaldavad kasutada nii HDD-d kui ka SSD-d või nende kombinatsiooni.
Peamine erinevus nende vahel on toedud hoidmistehnoloogiate tõhusus ja maksimaalne jõudlustase (kõrged IOPS näitajad ja madalad latentsusajad). Mõlemad süsteemid (enamikus mudelites, välja arvatud madala klassi segmendis) võivad toimida nii plokkseadmete kui ka failidena. Süsteemi tase mõjutab ka toetatud funktsioone, kus madalamate mudelite puhul on see sageli piiratud minimaalsete võimalustega. Seda tasub arvesse võtta, kui uurite konkreetse mudeli omadusi, mitte lihtsalt kogu tootevaliku võimalusi. Samuti sõltuvad süsteemi tehnilised omadused, nagu protsessor, mälumaht, vahemälu, portide arv ja tüübid jne. Halduse seisukohalt erinevad AFA hübriidsüsteemidest (ketasseadmetest) peamiselt SSD-mäluseadmete kasutamise mehhanismide rakendamise osas, ja isegi kui kasutate SSD-d hübriidsüsteemis, ei tähenda see, et saate AFA süsteemi tasemel jõudlust. Enamikul juhtudel on ka hübriidsüsteemide efektiivne salvestamise inline-mehhanism välja lülitatud, ja selle sisselülitamine toob kaasa jõudluse languse.
Spetsiaalne salvestuslahendus
Lisaks üldotstarbelistele salvestuslahendustele, mis on peamiselt suunatud andmete kiirele töötlemisele, on olemas spetsiaalsed lahendused, mille põhimõtted on radikaalselt erinevad tavapärasest (madal latentsus, palju IOPS):
Meedia.
Need süsteemid on mõeldud meediafailide salvestamiseks ja töötlemiseks, mis on suure mahuga. Vastav latentsus muutub peaaegu ebaoluliseks ja esiplaanile tõuseb võime edastada ja vastu võtta andmeid laia ribalaiusega mitmes paralleelses voos.
Duplikaatide eemaldamise salvestuslahendused varukoopiate jaoks.
Kuna varukoopiad erinevad harva tavalistes tingimustes üksteisest (keskmine varukoopia erineb eilsetest 1-2%), pakendab see süsteemiteema väga tõhusalt salvestatud andmed suhteliselt väheste füüsiliste andmekandjate ulatuses. Näiteks võivad mõningatel juhtudel andmete tihendamise suhted ulatuda 200:1.
Objekti salvestuslahendused.
Nendes objektisalvestussüsteemides ei ole tavalisi mahtu, millega pääseb plokitasandi juurdepääsuga ega jagatud faile, vaid nad meenutavad enam kui suurt andmebaasi. Juurdepääs objektile, mis on sellises süsteemis salvestatud, toimub unikaalse identifikaatori või metandmete kaudu (näiteks kõik JPEG formaadis objektid, mille loomise kuupäev on vahemikus XX-XX-XXXX kuni YY-YY-YYYY).
Süsteemide vastavus.
Need ei ole Venemaal praegu nii levinud, kuid neist tasub rääkida. Selliste objektisalvestussüsteemide eesmärk on tagada andmete säilitamine vastavuses turvapoliitikaga või regulatiivsete nõuetega. Mõnedes süsteemides (näiteks EMC Centera) on ellu viidud funktsioon andmete kustutamise keelamiseks — niipea kui võti on pööratud ja süsteem on läinud sellesse režiimi, ei saa ei administraator ega keegi teine füüsiliselt kustutada juba salvestatud andmeid.
Patenteeritud tehnoloogiad
Flash cache
Flash Cache on üldnimetus kõigile patenteeritud tehnoloogiatele, mis kasutavad flash-mälu teise tasandi vahendina. Flash-cache'i kasutamisel arvutatakse objektisalvestussüsteemi jõudlus magnetdiskidelt juba kehtestatud koormuse järgi, samal ajal kui tipukoormust teenindab vahemälu.
Siiski on oluline mõista koormuse profiili ja pöördumiste lokaliseerimise määra salvestustehnoloogia blokki. Flash-cache on tehnoloogia, mis sobib kõrge pöördumise lokaliseerimisega koormustele, kuid on praktiliselt kasutamatu ühtlaselt koormatud mahtude jaoks (näiteks analüütiliste süsteemide puhul).
Turul on saadaval kaks flash-cache'i rakendust:
- Ainult lugemine. Sel juhul salvestatakse ainult lugemisandmed, kuid kirjutamine toimub kohe ketastele. Mõned tootjad, nagu NetApp, usuvad, et kirjutamine nende salvestuslahendustes toimub juba optimaalselt ning cache ei too mingit kasu.
- Lugemine/Kirjutamine. Salvestatakse mitte ainult lugemine, vaid ka kirjutamine, mis võimaldab voogu vahemällu salvestada ja vähendada RAID-karistuse mõju, mis omakorda suurendab üldist jõudlust mitte nii optimaalse kirjutamismehhanismiga salvestuslahendustes.
Kihistamine
Mitmekihiline salvestus (tireerimine) on tehnoloogia, mis ühendab erineva jõudlusega kettatasemed, nagu SSD ja HDD, ühte kettapaaki. Kui andmeplokkide päringud on selgelt ebaühtlased, suudab süsteem automaatselt tasakaalustada andmeplokke, liikudes koormatud plokkide kõrge jõudlusega tasemele ja külmad, vastupidi, aeglasemale tasemele.
Hübriidsüsteemid madalamate ja keskklasside jaoks kasutavad mitmekihilist salvestust, liigutades andmeid tasemete vahel vastavalt ajakavale. Samal ajal on parimate mudelite mitmekihilise salvestuse ploki suurus 256 MB. Need omadused ei võimalda pidada mitmekihilist salvestust jõudluse suurendamise tehnoloogiaks, nagu paljud ekslikult arvavad. Mitmekihiline salvestus madala ja keskklassi süsteemides on salvestuse kulutõhususe optimeerimise tehnoloogia, mis sobib süsteemidele, kus koormus on selgelt ebaühtlane.
Snapshots
Kuigi me räägime andmete salvestamise usaldusväärsusest, on palju võimalusi, kuidas andmeid kaotada, mis ei sõltu riistvara probleemidest. Need võivad olla viirused, häkkerid või juhuslikud andmete kustutamised/ kahjustamised. Seetõttu on tootmisandmete varundamine inseneri töö lahutamatu osa.
Snaapshot on mahust tehtud pilt mingil ajahetkel. Enamikus süsteemides, nagu virtualiseerimine, andmebaasid jne, on meil vaja teha selline pilt, millest kopeerime andmed varukoopia jaoks, samal ajal kui meie infosüsteemid saavad selle mahuga rahulikult edasi töötada. Kuid tuleb meeles pidada, et kõik snaapshotid ei ole võrdselt kasulikud. Erinevatel tootjatel on erinevad lähenemisviisid snaapshotide loomisele, mis on seotud nende arhitektuuriga.
CoW (Copy-On-Write). Andmete plokki kirjutamise katse korral kopeeritakse selle originaalsisu spetsiaalsesse piirkonda, mille järel kirjutamine toimub normaalsetes tingimustes. Nii hoitakse ära andmete kahjustamine snapshots sees. Loomulikult põhjustavad kõik need «parasiitlikud» andmemanipulatsioonid suurema koormuse salvestuslahendusele ja seetõttu ei soovita tarnijad, kellel on selline teostus, kasutada rohkem kui kümmet snapshot'i ning kõrge koormusega mahutites ei kasuta neid üldse.
RoW (Redirect-on-Write). Sel juhul külmutatakse originaalne maht, ja andmete ploki kirjutamise katse korral kirjutab salvestuslahendus andmed spetsiaalsesse valdkonda vabasse ruumi, muutes selle ploki asukohta metainfote tabelis. See vähendab ümberkirjutamise operatsioonide arvu, mis omakorda tasakaalustab jõudluse languse ja eemaldab piirangud snapshot'idele ja nende arvule.
Snapshot'id võivad samuti olla kahte tüüpi rakenduste suhtes:
Rakenduse konsistentne. Snapshot'i loomise hetkel kutsub andmesalvestus süsteemi agendi, mis sunnib ketta vahemälu mälu ketastele kirjutama ning sunnib rakendust seda tegema. Sellisel juhul on andmed taastamisel snapshot'ist kooskõlalised.
Krahhi kooskõlaline. Antud juhul ei synni midagi sellist ja snapshot luuakse nagu on. Taastamisel sellisest snapshot'ist on olukord identne sellele, kui toide ootamatult katkeb, ja võib esineda teatud andmete kadumine, mis jäi vahemällu ja ei jõudnud ketastele. Sellised snapshot'id on kergemini teostatavad ning ei põhjusta rakendustes jõudluse langust, kuid on vähem usaldusväärsed.
Miks on andmesalvestussüsteemides vajalikud snapshot'id?
- Agendivaba varundamine otse andmesalvestusest
- Tegemist katsetuskeskkondade loomisega reaalsest andmestikust
- Failide andmesalvestuste puhul võib seda kasutada VDI keskkondade loomiseks, kasutades andmesalvestuse snapshot'e hüperviisori asemel
- Madalate RPO-de tagamine, luues snapshot'e ajakava alusel, mille sagedus on oluliselt kõrgem kui varundamise sagedus
Kloonimine
Kettavolu kloonimine toimib sarnasel põhimõttel nagu snapshots, kuid see ei ole mõeldud ainult andmete lugemiseks, vaid täieõiguslikuks töötamiseks nendega. Meil on võimalus saada täpne koopia meie mahust koos kõigi andmetega sellel, luues füüsilist koopiat, mis aitab kokku hoida ruumi. Tavaline kettahaldus, mis rahuldab Test&Dev, või kui soovite kontrollida mõnede uuenduste töökorras hoidmist teie IS-iga. Kloonimine võimaldab seda teha maksimaalselt kiiresti ja põhimõtteliselt odavalt arvestades kettaruumi, kuna salvestatakse ainult muudetud andmeplokid.
Replikatsioon / ajakiri
Replikatsioon on andmete koopia loomise mehhanism teisele füüsilisele salvestusseadmestikule. Igal tootjal on tavaliselt oma tehnoloogia, mis töötab ainult nende ainulaadse tootesarja raames. Kuid olemas on ka kolmandate osapoolte lahendusi, sealhulgas need, mis töötavad hüperviisori tasandil, näiteks VMware vSphere Replication.
Tootjate tehnoloogiate funktsionaalsus ja kasutusmugavus ületavad tavaliselt universaalseid, kuid need ei ole rakendatavad, kui on vajalik näiteks NetAppi replikatsiooni tegemine HP MSA-le.
Replikatsioon jaguneb kaheks alamtüübiks:
Sünkroonne. Sünkroonses replitseerimises edastatakse kirjutamistegevus kohe teisele salvestusseadmestikku ning täitmine ei kinnitata, kuni kaugseade ei kinnita. Selle tõttu suureneb ligipääsu latentsus, kuid samas on meil täpne peegelpilt andmetest. See tähendab, et RPO = 0 pea seadme kadumise korral.
Asünkroonne. Kirjutamistegevused toimuvad ainult peamiselt salvestusseadmestikus ja kinnitatakse kohe, kogunedes samal ajal vahemällu pakkedastamiseks kaugseadmestikku. See tase replitseerimist sobib vähem väärtuslikele andmetele või kanalitele, millel on madal ribalaius või kõrge latentsus (iseloomulik üle 100 km kaugusele). Seetõttu RPO = pakette saatmise sagedusele.
Sageli koos replitseerimisega eksisteerib mehhanism logimise kettaoperatsioone. Sel juhul eraldatakse eriline ala logimiseks ja salvestatakse teatud sügavusel ajas toimingud, või logi mahuga piiratud toimingud. Spetsiaalsete tehnoloogiate puhul, nagu näiteks EMC RecoverPoint, on olemas integreerimine süsteemitehnoloogiate tarkvaraga, mis võimaldab siduda teatud märke logis konkreetse kirje jaoks. Selle tõttu on võimalik taastada mahtude seisund (või luua kloon) mitte ainult 23. aprillil kell 11:59:13.013, vaid ka hetkel, mis eelnes "DROP ALL TABLES; COMMIT".
Metro cluster
Metro cluster on tehnoloogia, mis võimaldab luua kahepoolselt sünkroonset replikatsiooni kahe andmesalvestussüsteemi vahel, nii et see paar näeb välja nagu üks andmesalvestussüsteem. Kasutatakse geograafiliselt eraldatud klastrite loomiseks metroo kaugusel (vähem kui 100 km).
Virtuaalserverite keskkonnas kasutamine võimaldab metroklusteril luua andmepoe, mis on kergesti kirjutatav kahes andmekeskuses. Sellisel juhul luuakse hüperviisori tasemel klaster, mis koosneb erinevates füüsilistes andmekeskustes asuvatest hostidest, ühendatud selle andmepoe juurde. See võimaldab järgmisi tegevusi:
- Kogu protsessi automaatne taaste tõrgete korral ühe andmekeskuse kadumisel. Ilma täiendavate tööriistadeta käivitatakse kõik VM-id, mis töötasid kadunud andmekeskuses, automaatselt allesjäänud keskuses. RTO = kõrge saadavuse klastri taimer (15 sekundit VMware jaoks) + operatsioonisüsteemi laadimise ja teenuste käivitamise aeg.
- Katastroofide vältimine. Kui andmekeskuses 1 on plaanitud elektritööd, siis on meil enne tööde algust võimalus migrida kogu oluline koormus andmekeskusesse 2 pidevalt.
Virtualiseerimine
SAS virtualiseerimine on tehniliselt mahute kasutamine teise enam kui ühe SASH-i kettadena. SASH-i virtualiseerija võib lihtsalt edastada teise mahu tarbijale oma kettana, samas peegeldades seda teisele SASH-ile või isegi luua RAID välisest mahust.
Traditsioonilised esindajad SASH-i virtualiseerimise klassis on EMC VPLEX ja IBM SVC. Ja loomulikult SASH-id, millel on virtualiseerimise funktsioon — NetApp, Hitachi, IBM / Lenovo Storwize.
Miks see võib vajalik olla?
- SASH-i taseme varundamine. Looge peegel kahe mahu vahel, kusjuures üks pool võib olla HP 3Par-l ja teine NetApp-l. Ja EMCi virtualiseerija.
- Andmete migreerimine minimaalse seisakuga erinevate tootjate SASH-ide vahel. Oletame, et andmed tuleb migreerida vanalt 3Par-ilt, mis läheb välja, uuele Dellile. Sel juhul tarbijad lülitatakse 3Par-ilt välja, mahud edastatakse VPLEX-iga ja esitatakse taas tarbijatele. Kuna mahul pole ühtegi bitti muutunud, jätkub töö. Taustal käivitatakse mahukopeerimise protsess uuele Dellile ning pärast lõpetamist hävitatakse peegel ja 3Par lülitatakse välja.
- Metroklasterite korraldamine.
Kompresseerimine / dedupe.
Kompresseerimise ja dedupeerimise tehnoloogiad aitavad teil säästa ruumi oma salvestusseadmest. On oluline märkida, et mitte kõik andmed ei sobi kompressimiseks ja/või dedupeerimiseks; samas mõned andmetüübid kompressitakse ja dedupeeritakse paremini kui teised.
Kompresseerimine ja dedupeerimine jagunevad kaheks:
Inline — andmeplokkide kompressioon ja dedupeerimine toimub enne nende andmete salvestamist kettale. Seega arvutab süsteem lihtsalt ploki räsikoodi ja võrdleb seda olemasolevatega. Esiteks toimub see kiiremini kui lihtsalt kettale kirjutamine, teiseks ei raiska me liigset kettaruumi.
Post — kui neid toiminguid tehakse salvestatud andmete peal, mis asuvad ketastel. Vastavalt sellele kirjutatakse andmed esmalt kettale ja alles seejärel arvutatakse räsikood ning eemaldatakse liigsed plokid, vabastades kettaruumi.
Oluline on märkida, et enamik tarnijaid kasutab kahte tüüpi, mis võimaldab neid protsesse optimeerida ja seeläbi tõsta nende efektiivsust. Enamikul tarnijatel on olemas utiliidid, mis võimaldavad analüüsida teie andmekogusid. Need utiliidid töötavad samade põhimõtete alusel nagu SÜSD, seega on hindamisvõimekus sama. Samuti ei tasu unustada, et paljusid tarnijaid on tõhususe garantii programmid, mis lubavad määra, mis ei ole madalam kui määratud teatud (või kõikide) andmetüüpide jaoks. Ja ärge alahinnake seda programmi, sest kui arvutate süsteemi oma ülesannete jaoks, arvestades konkreetse süsteemi efektiivsuse koefitsienti, võite säästa mahus. Samuti tuleb arvesse võtta, et need programmid on mõeldud AFA süsteemidele, kuid ostes väiksema mahu SSD, võrreldes HDD-ga klassikalistes süsteemides, võimaldab see vähendada nende hinda ja kui ei saavuta samasse hinda diskisüsteemiga, siis kindlasti läheneda sellele.
Mudel
Ja siin jõuame õigesti esitatud küsimusele.
„Mulle pakutakse kahte varianti SĒD - ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitate?”
Muudetakse „Mulle pakutakse kahte varianti SĒD - ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitate?”
Sihtkoormus on segatud VMware virtuaalmasinad tootmisest / testimisest / arendusest. Test = tootmine. 150 TB igaüks haripunkti jõudlusega 80 000 IOPS 8kb ploki 50% juhuslikuks juurdepääsuks 80/20 lugemine-kirjutamine. 300 TB arenduseks, seal on piisavalt 50 000 IOPS, 80 juhuslik, 80 kirjutamine.
Tootmine on eeldatavasti metroklastri RPO = 15 minutit RTO = 1 tund, arendus asünkroonse replikatsiooniga RPO = 3 tundi, test ühelt platvormilt.
Sealt tuleb 50TB andmebaasi, neile oleks hea logimine.
Meil on kõikjal Dell'i serverid, SĒD on vanad Hitachi'd, vaevu saavad hakkama, plaanime kasvu 50% koormusest nii mahtu kui jõudlust.”
Kuidas öeldakse, õigesti sõnastatud küsimuses on 80% vastusest.
Lisainformatsioon
Millele tasub lisaks tutvuda autorite arvates.
Raamatud
- Oliifer ja Oliifer „Arvutivõrgud”. Raamat aitab süsteemseid teadmisi ja võib-olla paremini mõista, kuidas töötab andmeedastus keskendumise keskkond IP / Ethernet andmesalvestussüsteemide jaoks.
- „EMC Information Storage and Management”. Suurepärane raamat andmesalvestuse ja haldamise alused, miks, kuidas ja milleks.
Foorumid ja vestlusruumid
Üldised soovitused
Hinnad
Nüüd, mis puudutab hindu — andmesalvestuse süsteemide puhul on hinnad, kui neid üldse leidub, enamasti list price, mille alusel iga klient saab individuaalse allahindluse. Allahindluse suurus sõltub paljusid teguritest, seega ei saa prognoosida, millise lõpphinna teie ettevõte saab, ilma et pöörduda edasimüüja poole. Samas on viimastel aastatel low-end mudelid hakanud ilmuma tavapärastesse arvutipoedesse, nagu näiteks või . Neid süsteeme saab koheselt osta fikseeritud hinnaga, nagu kõiki teisi arvutikomponente.
Siiski tahaksin kohe märkida, et otse võrdlemine TB/$-ga ei ole korrektne. Kui seda aspekti vaadata, siis odavaim lahendus oleks tavaline JBOD + server, mis ei paku vajalikku paindlikkust ega usaldusväärsust, mida tagab täielik, kahekontrolleriline salvestussüsteem. See ei tähenda, et JBOD oleks halb, vaid on oluline, et mõistaksite täpselt, kuidas ja milleks te kavatsete seda lahendust kasutada. Tihti võib kuulda, et JBOD ei saa katki minna, kuna seal on vaid üks tagasiühendus. Siiski, ka tagasiühendused võivad rikkis olla. Kõik kahjustub varem või hiljem.
Kokku
Süsteeme tuleb omavahel võrrelda mitte ainult hinna või mitte ainult jõudluse põhjal, vaid kõigi näitajate summana.
Ostke HDD-d ainult siis, kui olete kindel, et vajate HDD-sid. Madala koormuse ja mitte-survestavate andmetüüpide puhul peaksite vaatama SSD-de säilitamise tõhususe garantiiprogramme, mis on nüüd enamiku tootjate seas olemas (ja need tõesti töötavad, isegi Venemaal), kuid kõik sõltub rakendustest ja andmetest, mis antud salvestussüsteemi paigutatakse.
Ärge laske end petta odavusest. Tihti peidab see endas mitmeid ebameeldivusi, millest on oma artiklites kirjutanud Jevgeni Elizarov. Ja mis paraku, võib see odavus teile lõpuks kalliks maksma minna. Ärge unustage — "ahne maksab kaks korda".
Allikas: habr.com
