Hyrje
Është koha për të blerë një sistem ruajtjeje. Cilin të zgjedh, kë do të dëgjoj? Furnizuesi A flet për furnizuesin B, ndërsa ka integrator C, i cili thotë të kundërtën dhe rekomandon furnizuesin D. Në këtë situatë, madje edhe një arkitekt i përvojës në sistemet e ruajtjes mund të humbasë kontrollin, veçanërisht me të gjithë furnizuesit e rinj dhe trendet si SDS dhe hiperconvergenca.
Pra, si të kuptojmë gjithçka këtë dhe të mos dalim të budallenj? Ne ( Anton Zhbankov dhe Evgeny Elizarov) do të përpiqemi ta shpjegojmë këtë në gjuhën ruse në mënyrë të thjeshtë.
Artikulli në shumë aspekte është në harmoni, dhe në fakt është një zgjerim i “” në aspektin e zgjedhjes së sistemeve të ruajtjes së të dhënave dhe rishikimit të teknologjive të sistemeve të ruajtjes. Ne do të shqyrtojmë teorinë e përgjithshme, por rekomandojmë gjithashtu të shqyrtoni edhe artikullin e përmendur.
Pse
Shpesh mund të vërehet një situatë si kur një person i ri hyn në forum ose në një bisedë speciale, siç është Storage Discussions dhe bën një pyetje: “më ofrojnë dy opsione për sistemin e ruajtjes — ABC SuperStorage S600 dhe XYZ HyperOcean 666v4, çfarë më rekomandoni?”
Fillimi i përmendjes së veçorive të realizimit të frikshme dhe të paqartë, që për një person të papërgatitur janë si shkronjat kineze.
Ja, pyetja kyçe dhe e para që duhet t'i bëni vetes shumë përpara se të filloni të krahasoni specifikimet në ofertat komerciale është PSE? Pse është e nevojshme kjo SHT?
Përgjigjja do të jetë e papritur, dhe me stilin e Tony Robbins — për të ruajtur të dhënat. Faleminderit, kapiten! Dhe megjithatë, ndonjëherë thellohemi aq shumë në krahasimin e detajeve, saqë harrojmë përse po e bëjmë këtë.
Pra, detyra e sistemit të ruajtjes së të dhënave është ruajtja dhe ofrimi i qasjes në TË DHËNA me performancën e caktuar. Nga të dhënat do të fillojmë.
Të dhënat
Lloji i të dhënave
Cilat të dhëna planifikojmë të ruajmë? Pyetje shumë e rëndësishme, që mund të përjashtojë shumë sisteme për ruajtjen e të dhënave nga shqyrtimi. Për shembull, planifikohet ruajtja e regjistrimeve video dhe fotografive. Menjëherë mund të përjashtohen sistemet që janë projektuar për akses të rastësishëm me blloqe të vogla, ose sistemet me karakteristika unike në kompresim / deduplicim. Këto mund të jenë sisteme të shkëlqyera, nuk dëshirojmë të themi asgjë të keqe për to. Por në këtë rast, pikë forte e tyre do të bëhet e dobët (videoja dhe fotografitë nuk kompresohen) ose thjesht do të rrisin ndjeshëm koston e sistemit.
Dhe anasjelltas, nëse përdorimi i synuar është një DBMS i ngarkuar me transaksione, atëherë sistemet e shkëlqyera në transmetimin e multimedia, të cilat mund të lëshojnë gigabajt në sekondë, do të jenë një zgjedhje e keqe.
Vëllimi i të dhënave
Sa sa i ruajmë të dhëna? Sasia kurrë nuk duhet të harrohet, veçanërisht në epokën tonë të rritjes eksponenciale të volumit të të dhënave. Sistemet e klasit petabayt tashmë nuk janë të rralla, por sa më shumë të dhëna të kenë petabayt, aq më specifike bëhet sistemi, dhe aq më pak do të jetë e disponueshme funksionaliteti i zakonshëm i sistemeve me qasje të rastësishme të volumit të vogël dhe të mesëm. Kjo është për arsyen se vetëm tabelat statistikore të qasjes për blloqe bëhen më të mëdha se sa është volumi i kujtesës оперативë në kontrollorët. E nuk po flasim që të kompresojmë / të radhitemi. Le të supozojmë se duam të kalojmë në një algoritëm kompresimi më të fuqishëm dhe të kompresohemi 20 petabayt të dhënash. Sa do të zgjasë: gjashtë muaj, një vit?
Nga ana tjetër, pse të krijojmë një sistem të madh nëse duhet të ruajmë dhe procesojmë vetëm 500 GB të dhënë? Vetëm 500. SSD-të shtëpiake (me DWPD të ulët) të këtij sasie nuk kushtojnë shumë. Pse duhet të ndërtosh një fabrikë Fiber Channel dhe të blesh një sistem të jashtëm të ruajtjes të klasit të lartë me çmim si një urë prej hekur?
Cili është përqindja e të dhënave të ngrohta nga volumi i përgjithshëm? Sa është e pandershme ngarkesa sipas volumit të të dhënave? Teknologjia e ruajtjes në nivele ose Flash Cache mund të ndihmojë shumë në këtë rast, nëse volumi i të dhënave të ngrohta është shumë i vogël krahasuar me përgjithshëm. Ose përkundrazi, në raste kur ngarkesa është e barabartë në të gjithë volumin, që ndodh shpesh në sistemet streaming (monitorim video, disa sisteme analitike), këto teknologji nuk do të japin asgjë dhe vetëm do të rrisin kostot / kompleksitetin e sistemit.
IS
Ana tjetër e të dhënave është sistemi informativ që përdor këto të dhëna. IS ka një grup kërkesash që trashëgojnë të dhënat. Më shumë rreth IS-it mund të gjeni në “Dizajni i qendrës së të dhënave të virtualizuara”.
Kërkesat për qëndrueshmëri / disponueshmëri
Kërkesat për qëndrueshmëri / disponueshmëri të të dhënave trashëgojnë nga IS që i përdor ato dhe shprehen në tri numra — RPO, RTO, ndryshme.
Disponueshmëria — periudha e caktuar kohore gjatë së cilës të dhënat janë të aksesueshme për punë. Shprehet zakonisht në numrin 9. Për shembull, dy nëntë në vit do të thotë se disponueshmëria është 99%, ose ndryshe lejohet 95 orë papunësie në vit. Tre nëntë — 9.5 orë në vit.
RPO / RTO — këto janë tregues që nuk janë të përgjithshëm, por për çdo incident (katastrofë), në dallim nga disponueshmëria.
RPO — sasia e të dhënave të humbura gjatë një katastrofe (në orë). Për shembull, nëse bëhet një kopje rezervë çdo ditë, atëherë RPO = 24 orë. Pra, gjatë një katastrofe dhe humbjes totale të sistemit të ruajtjes, mund të humben të dhëna deri në 24 orë (nga koha e kopjimit të rezervës). Duke u bazuar në RPO-në e caktuar për sistemin e informacionit, për shembull, shkruhet rregullorja e kopjimit të rezervës. Po ashtu, duke u bazuar në RPO-në, mund të kuptojmë sa e domosdoshme është replikimi i të dhënave në mënyrë sinkrone / asinkrone.
RTO — koha e rikuperimit të shërbimit (aksesit në të dhëna) pas një katastrofe. Duke u bazuar në vlerën e caktuar të RTO-së, mund të kuptojmë nëse na nevojitet një metrokaster, apo është e mjaftueshme replikimi njëdrejtim. Po ashtu, ne duhet të vendosim nëse na nevojitet një sistem i ruajtjes me shumë kontrollorë të klasës hi-end — gjithashtu.
Kërkesat për performancë
Megjithëse është një pyetje krejt e qartë, këtu shpesh shfaqen shumica e vështirësive. Në varësi të faktit nëse tashmë keni ndonjë infrastrukturë apo jo, do të ndërtohen rrugët e mbledhjes së statistikave të nevojshme.
Ju tashmë keni një SAS dhe jeni duke kërkuar një zëvendësim për të ose dëshironi të blini një tjetër për të zgjeruar. Këtu është e thjeshtë. Ju kuptoni shërbimet që tashmë i keni dhe ato që planifikoni të implementoni në të ardhmen e afërt. Duke u bazuar në shërbimet aktuale, keni mundësinë të mbledhni statistika mbi performancën. Të përcaktoni numrin aktual të IOPS dhe vonesat aktuale – cila është këto tregues dhe a janë të mjaftueshme për nevojat tuaja? Kjo mund të bëhet si në sistemin e ruajtjes së të dhënave, ashtu edhe nga ana e hosteve që janë lidhur me të.
Njëkohësisht, është e rëndësishme të shikoni jo thjesht ngarkesën aktuale, por edhe për një periudhë të caktuar (preferohet një muaj). Shikoni cila janë pikat maksimale në orët e ditës, çfarë ngarkese krijon kopjimi dhe të tjera. Nëse sistemi juaj i ruajtjes ose programi nuk ofron një set të plotë të këtyre të dhënave, mund të përdorni RRDtool, i cili punon me shumicën e sistemeve më të njohura të ruajtjes dhe switch-eve dhe do t'ju ofrojë statistikë të detajuar mbi performancën. Gjithashtu, është e rëndësishme të monitoroni ngarkesën edhe në host-at që punojnë me këtë sistem ruajtjeje, në lidhje me makinat virtuale specifike ose çfarëdo që funksionon në atë host.
Vlen të theksohet veçmas se nëse vonesat në volum dhe në ruajtjen e të dhënave, të cilat ndodhen në këtë volum, ndryshojnë shumë — duhet të shqetësoheni për rrjetin tuaj SAN, ka një probabilitet të lartë që të ketë probleme dhe para se të blini një sistem të ri, duhet të merreshi me këtë çështje, pasi ekziston një mundësi shumë e lartë për të rritur performancën e sistemit aktual.
Po ndërtoni infrastrukturën nga e para, ose blini një sistem për ndonjë shërbim të ri, për ngarkesat e të cilave nuk keni njohuri. Këtu ka disa mundësi: të bisedoni me kolegët në burime të specializuara për të përpjekur të kuptoni dhe parashikoni ngarkesën, të kontaktoni një integrator që ka përvojë në zbatimin e këtyre shërbimeve dhe që mund të llogarisë ngarkesën për ju. Dhe mundësia e tretë (zakonisht më e vështira, sidomos nëse lidhet me aplikacione të shkruara vetë ose të rralla) është të përpiqeni të përcaktoni kërkesat për performancë nga zhvilluesit e sistemit.
Dhe, vëmendje, opsioni më i saktë nga këndvështrimi i aplikimit praktik — është një provë në pajisjet aktuale, ose në pajisjet e ofruara për test nga furnizuesi / integratori.
Kërkesat speciale
Kërkesat speciale — janë të gjitha ato që nuk bien nën kërkesat për performancë, disponueshmëri dhe funksionalitet në përpunimin dhe ofrimin e të dhënave.
Një nga kërkesat më të thjeshta për sistemin e ruajtjes së të dhënave është "mediat e informacionit të shitshme". Shpejt bëhet e qartë se ky sistem ruajtjeje duhet të përfshijë një bibliotekë bandë ose thjesht një bandë, në të cilën shkarkohet një kopje rezervë. Pas kësaj, një person i trajnuar nënshkruan bandën dhe e mban me krenari në një kasafortë të veçantë.
Një shembull tjetër i kërkesave speciale është realizimi i mbrojtur ndaj goditjeve.
Ku
Pjesa e dytë kryesore në zgjedhjen e sistemit të ruajtjes së të dhënave është informacioni se KUNDË do të vendoset ky sistem. Nga gjeografia apo kushtet klimatike, deri te personeli.
Porositësi
Për kë është planifikuar ky sistem i ruajtjes së të dhënave? Pyetja ka këto baza:
Porositësi shtetëror / komercialisht.
Porositësi comercial nuk ka asnjë kufizim dhe nuk është i detyruar të zhvillojë tenderë, përveç atyre që parashikohen nga rregullat e tij të brendshme.
Porositësi shtetëror është një çështje ndryshe. Ligji 44-FZ dhe kënaqësitë e tjera me tenderët dhe Të DH, të cilat mund të kontestohen.
Porositësi nën sanksione
Këtu pyetja është shumë e thjeshtë — zgjedhja kufizohet vetëm te ofertat e disponueshme për këtë klient.
Rregullat e brendshme / furnizuesit e lejuar për blerje / modelet
Pyetja gjithashtu është shumë e thjeshtë, por duhet mbajtur mend.
Ku fizikisht
Në këtë pjesë ne shqyrtojmë të gjitha çështjet që lidhen me gjeografinë, kanalet e komunikimit dhe mikroklimën në ambientin e vendosjes.
Personeli
Kush do të punojë me këtë sistem ruajtje të dhënash? Kjo është po aq e rëndësishme sa ajo që sistemi i ruajtjes mund të bëjë drejtpërdrejt.
Sikurse të jetë sistemi i ruajtjes nga furnizuesi A, sa do të jetë ai i perspektivës së madhe, ndoshta ka pak kuptim ta vendosësh, nëse stafi di të punojë vetëm me furnizuesin B dhe nuk planifikohen blerje të tjera apo bashkëpunim të vazhdueshëm me A.
Natyrisht, një shqetësim tjetër është sa i arritshëm është stafi i kualifikuar brenda kompanisë dhe potencialisht në tregun e punës në këtë lokacion gjeografik. Për rajonet, mund të ketë një rëndësi të madhe zgjedhja e një SHT me ndërfaqe të thjeshta ose mundësinë e menaxhimit qendror në distancë. Përndryshe, në një moment, situata mund të bëhet shumë e dhimbshme. Interneti është plot me historia se si një punonjës i ri, një student i ditëve të kaluara, ka bërë një konfigurim të tillë që e ka lënë të gjithë kompaninë pa funksion.
Mjedisi
Po ashtu, një pyetje e rëndësishme është se në cilin mjedis do të funksionojë ky SHT.
- Si është energjia elektrike / ftohja?
- Çfarë lidhjeje ka?
- Ku do të montohet?
- Etj.
Shpesh, këto pyetje konsiderohen si të qenësishme dhe nuk shqyrtohen shumë, por ndonjëherë ato mund të përmbysin gjithçka përmbi katër.
Çfarë
Shitesi
Sot (në mes të vitit 2019), tregu rus i SHT-ve mund të ndahet në pesë kategori të ndara:
- Divizioni më i lartë — kompani të njohura me një gamë të gjerë nga raftet më të thjeshta të disqeve deri te hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Divizioni i Dytë — kompanitë me një linjë të kufizuar, lojtarë të nišës, furnizues të rëndësishëm SDS ose fillestarë të ngritur (Fujitsu, Datacore, Infinidat, Huawei, Pure etj.)
- Divizioni i Tretë — zgjidhje të nišës në rangun low end, SDS të lira, produkte amatore në ceph dhe projekte të tjera të hapura (Infortrend, Starwind etj.)
- Segmenti SOHO — sisteme të vogla dhe super të vogla të magazinimit për shtëpi/zyrë të vogël (Synology, QNAP etj.)
- Sistemet e magazinimit të importuara — këtu përfshihen si pajisjet e divizionit të parë me etiketa të ricikluara, ashtu edhe përfaqësues të rrallë të divizionit të dytë (RAIDIX, do t'u japim një avantazh të dytë), por kryesisht është divizioni i tretë (Aerodisk, Baum, Depo etj.)
Klasifikimi është mjaft i kushtueshëm dhe nuk do të thotë se segmenti i tretë ose SOHO është i dobët dhe nuk mund të përdoret. Në projekte specifike me një grup të qartë të të dhënave dhe profilin e ngarkesës, ato mund të punojnë shumë mirë, duke e tejkaluar divizionin e parë në raportin çmim/kuali. Është e rëndësishme të përcaktohet së pari detyra, perspektivat e rritjes, funksionaliteti i kërkuar — dhe atëherë Synology do t'ju shërbejë me besnikëri, ndërsa flokët do të bëhen të butë dhe me shkëlqim.
Një nga faktorët më të rëndësishëm në zgjedhjen e një ofruesi është mjedisi aktual. Sa dhe cilat sisteme ruajtjeje (SХД) e keni tashmë, me cilat SХД dinë të punojnë inxhinierët. A keni nevojë për një ofrues tjetër, një tjetër pikë kontakti, do të migroni gradualisht gjithë ngarkesën nga ofruesi A te ofruesi B?
Nuk duhet të krijoni entitete përtej nevojës.
iSCSI / FC / File
Për çështjen e protokolleve të qasjes nuk ka një mendim të njëjtë midis inxhinierëve, dhe debatet duken më shumë si diskutime teologjike sesa inxhinierike. Por në përgjithësi, mund të theksohen këto pika:
FCoE është më shumë i vdekur sesa i gjallë.
FC vs iSCSI. Një nga avantazhet kryesore të FC në vitin 2019 krahasuar me SХД-të IP, fabrika e dedikuar për qasjen në të dhëna, është nivellizuar nga rrjeti i dedikuar IP. Nuk ka avantazhe globale të FC mbi rrjetet IP dhe mbi IP mund të ndërtohen SХД të çdo niveli ngarkese, deri në sisteme për DBMS të rënda për ABS të një banke të madhe. Nga ana tjetër, vdekja e FC parashikohet prej vitesh, por diçka gjithmonë e pengon këtë. Sot, për shembull, disa lojtarë në tregun e SХД-ve po zhvillojnë aktivisht standardin NVMEoF. Nëse ai do të ndajë fatin e FCoE, koha do ta tregojë.
Qasja në skedarë ashtu nuk është diçka e padëshirueshme. NFS / CIFS performojnë mjaft mirë në mjedise produktive dhe, nëse janë projektuar siç duhet, kanë jo më shumë ankesat se protokollet bllokuese.
Hibrid / All Flash Array
Sistemet e klasike të ruajtjes ndahen në 2 lloje:
- AFA (All Flash Array) — sisteme të optimizuara për përdorimin e SSD-ve.
- Hibrid — duke lejuar përdorimin e HDD-ve, SSD-ve apo një kombinim të tyre.
Dallësia kryesore e tyre është teknologjitë mbështetëse të ruajtjes dhe niveli maksimal i performancës (të dhëna të larta IOPS dhe vonesa të ulëta). Të dy sistemet (në shumicën e modeleve të tyre, përveç segmenteve low-end) mund të funksionojnë si pajisje bllokuese ashtu edhe si skedarë. Niveli i sistemit përcakton gjithashtu funksionalitetin e mbështetur, dhe për modelet më të vogla, ai shpesh është reduktuar në nivelin minimal. Kjo është e rëndësishme të keni parasysh kur studioni karakteristikat e një modeli të caktuar, dhe jo thjesht mundësitë e gjithë gamës. Po ashtu, sigurisht, niveli i sistemit ndikon edhe në karakteristikat teknike të tij, si procesori, kapaciteti i memories, caches, numri dhe tipet e porteve, etj. Nga këndvështrimi i menaxhimit të softuerit, AFA nga sistemet hibride (disku) ndryshojnë vetëm në çështjet e zbatimit të mekanizmave të punës me SSD-të e ruajtjes, dhe madje nëse përdorni SSD në një sistem hibrid, kjo nuk do të thotë që do të mund të arrini një nivel performance në nivelin e një sistemi AFA. Po ashtu në shumicën e rasteve, mekanizmat inline të ruajtjes efikase në sistemet hibride janë të çaktivizuar, dhe aktivizimi i tyre çon në një humbje të performancës.
Sistemi të veçantë të ruajtjes
Përveç sistemeve të ruajtjes së përgjithshme, të orientuara kryesisht për përpunimin e dhënave në kohë reale, ekzistojnë sisteme të veçanta ruajtjeje me parime kyçe që ndryshojnë thelbësisht nga ato të zakonshmet (vonesa e ulët, shumë IOPS):
Media.
Këto sisteme janë të destinuara për ruajtjen dhe përpunimin e skeda mediale që karakterizohen nga madhësi të mëdha. Prandaj, vonesa bëhet praktisht e padëshiruar, dhe në plan të parë del kapaciteti për të dërguar dhe pranuar të dhëna në një gjerësi të madhe të kanalit në shumë rrjedha paralele.
Sistemet e ruajtjes me deduplication për kopje rezervë.
Duke qenë se kopjet rezervë zakonisht dallohen nga ngjashmëria e vogël (kopja mesatare ndryshon nga ajo e djeshme me 1-2%), ky klas sistemesh paketoni shumë efikasht të dhënat e regjistruara në to brenda një numri të mjaftueshëm të vogël të mediave fizike. Në disa raste, koeficientët e kompresimit të të dhënave mund të arrijnë deri në 200 me 1.
Sistemet e ruajtjes objektive.
Në këto sistemet e ruajtjes nuk ka volume tradicionale me akses bllok dhe ndarje skedari, por e ngjajnë më shumë me një bazë të madhe të dhënash. Qasja në një objekt të ruajtur në një sistem të tillë bëhet përmes një identifikuesi unik ose nga metadatet (për shembull, të gjitha objektet në formatin JPEG, me datën e krijimit ndërmjet XX-XX-XXXX dhe YY-YY-YYYY).
Sistemet e përputhshmërisë.
Nuk ndodhin aq shpesh në Rusi sot, por ia vlen të përmenden. Qëllimi i këtyre sistemeve të ruajtjes është ruajtja e garantuar e të dhënave për të përmbushur politikat e sigurisë ose kërkesat e rregullatorëve. Në disa sisteme (për shembull EMC Centera) është implementuar funksioni i ndalimit të fshirjes së të dhënave - sapo çelësi kthehet dhe sistemi kalon në këtë mod, as administratori dhe asnjë person tjetër fizikisht nuk mund të fshijë të dhënat e regjistruara tashmë.
Teknologjitë e markës
Cache Flash
Cache Flash – është emri i përgjithshëm për të gjitha teknologjitë e markës që përdorin kujtesën flash si cache të nivelit të dytë. Kur përdoret cache flash, sistemi i ruajtjes zakonisht llogaritet për të siguruar ngarkesën që është vendosur nga disqet magnetike, ndërsa pikat më të larta i shërben cache.
Është e nevojshme të kuptohet profili i ngarkesës dhe niveli i lokalizimit të kërkesave për blloket e volumeve të ruajtjes. Flash cache është një teknologji për ngarkesa me lokalizim të lartë të kërkesave dhe është praktikisht e papërdorshme për volumet me ngarkesa të barabarta (si për shembull për sistemet analitike).
Në treg janë të disponueshme dy realizime të flash cache:
- Leximi i vetëm. Në këtë rast, angazhohen vetëm të dhënat për lexim, ndërsa shkrimi kalon direkt në disqe. Disa prodhues, si p.sh., NetApp, mendojnë se shkrimi në sistemin e tyre të ruajtjes kalon në mënyrë optimale dhe cache nuk ndihmon fare.
- Leximi/Shkrimi. Angazhohet jo vetëm leximi, por edhe shkrimi, që lejon tamponizimin e rrjedhës dhe zvogëlon ndikimin e RAID Penalty, dhe si pasojë rrit performancën totale për sistemet e ruajtjes me mekanizma të shkrimit që nuk janë aq optimalë.
Tiers
Ruajtja ndërshtresore (tiering) është një teknologji që bashkon nivele me performancë të ndryshme, siç janë SSD dhe HDD, në një rezervar të vetëm disku. Në rast të një pabarazie të dukshme në kërkesat për blloqet e të dhënave, sistemi do të jetë në gjendje të balancojë automatikisht blloqet e të dhënave, duke transferuar ato të ngarkuara në një nivel me performancë të lartë, ndërsa ato të ftohta në një nivel më të ngadalshëm.
Sistemet hibride në klasat e ulta dhe të mesme përdorin ruajtje ndërshtresore me transferim të të dhënave midis niveleve sipas një skeduli. Në këtë rast, madhësia e bllokut të ruajtjes ndërshtresore te modelet më të mira është 256 MB. Këto karakteristika nuk e lejojnë që teknologjia e ruajtjes ndërshtresore të konsiderohet si një teknologji për përmirësimin e performancës, siç mendojnë gabimisht shumë. Ruajtja ndërshtresore në sistemet e klasave të ulta dhe të mesme është një teknologji për optimizimin e kostos së ruajtjes për sistemet me një pabarazi të dukshme të ngarkesës.
Snapshot
Pavarësisht se sa flasim për besueshmërinë e sistemit të ruajtjes së të dhënave, ka shumë mundësi për të humbur të dhëna, që nuk varen nga problemet harduerike. Këto mund të jenë si viruse, hakerë, ose çfarëdo tjetër që çon në fshirje apo dëmtim të paqëndrueshëm të të dhënave. Për këtë arsye, backup-i i të dhënave produktive është një pjesë e rëndësishme e punës së inxhinerit.
Snapshot është një imazh i vëllimit në një moment të caktuar në kohë. Kur punojmë me shumicën e sistemeve, si virtualizimi, bazat e të dhënave etj., na nevojitet të marrim një snapshot nga i cili do të kopjojmë të dhënat për backup, ndërsa sistemet tona mund ta vazhdojnë me lehtësi punën me këtë vëllim. Por duhet të mbani mend — jo të gjithë snapshotet janë po aq të dobishme. Diferent furnizues kanë qasje të ndryshme në krijimin e snapshot-eve, të lidhura me arkitekturën e tyre.
CoW (Copy-On-Write). Kur provoni të shkruani një bllok të dhënash, përmbajtja e tij origjinale kopjohet në një zonë të veçantë, pas së cilës shkrimi kalon normalisht. Kjo parandalon dëmtimin e të dhënave brenda snapshot-it. Natyrisht, të gjitha këto manipulime "parazitare" me të dhënat shkaktojnë ngarkesë shtesë në pajisjen e ruajtjes dhe për këtë arsye, shitësit me implementime të tilla nuk rekomandojnë përdorimin e më shumë se dhjetë snapshot-eve, dhe në volumet me ngarkesë të lartë, të mos i përdorin fare.
RoW (Redirect-on-Write). Në këtë rast, volumi origjinal natyrisht ngrin, dhe kur provoni të shkruani një bllok të dhënash, pajisja e ruajtjes shkruan të dhënat në një zonë të veçantë në hapësirën e lirë, duke ndryshuar vendndodhjen e këtij blloku në tabelën e metadatumve. Kjo lejon të reduktojë numrin e operacioneve të rishkrimit, që përfundimisht zbut rënien e performancës dhe heq kufizimet për snapshot-et dhe numrin e tyre.
Snapshot-et gjithashtu ndahen në dy tipe në lidhje me aplikacionet:
Konsistente për aplikacionin. Në momentin e krijimit të snapshot-it, storja e të dhënave tërheq agjent nga sistemi operativ i konsumatorit, i cili detyrohet të heqë cache-në e disqeve nga memoria në disk dhe e bën këtë aplikacion. Në këtë rast, kur rikuperohet nga snapshot-i, të dhënat do të jenë konsistente.
Konsistencë e dështimit. Në këtë rast, asgjë e tillë nuk ndodh dhe snapshot-i krijohet ashtu siç është. Në rast rikuperimi nga një snapshot të tillë, pamja është e njëjtë si nëse energjia ishte ndaluar papritur dhe ka mundësi që disa të dhëna të humbin, të mbetura në cache dhe që nuk arritën kurrë në disk. Të tillët snapshot janë më të lehtë për t'u zbatuar dhe nuk shkaktojnë ulje të performancës në aplikacione, por janë më pak të besueshëm.
Pse janë të nevojshme snapshot-et në sistemet e ruajtjes së të dhënave?
- Backup pa agjent direkt nga SHD
- Krijimi i mjediseve testuese mbi të dhëna reale
- Në rastin e SHD-ve të skedarëve, mund të përdoret për të krijuar mjedise VDI duke përdorur snapshot-et e SHD-ve në vend të hipervizorit
- Sigurimi i RPO-ve të ulët përmes krijimit të snapshot-eve me një orar me frekuencë shumë më të lartë se sa backup-i
Kloni
Kloni i volumit funksionon në një parim të ngjashëm me snapshots, por shërben jo vetëm për leximin e të dhënave, por për një punë të plotë me to. Ne kemi mundësinë të marrim një kopje të saktë të volumit tonë, me të gjitha të dhënat e tij, pa bërë një kopje fizike, që do të na lejojë të kursim hapësirë. Zakonisht, klonimi i volumeve përdoret ose në Test & Dev ose nëse dëshironi të kontrolloni funksionalitetin e disa azhurnimeve në sistemin tuaj të informacionit. Klonimi do ta lejojë këtë të bëhet sa më shpejt dhe ekonomikisht në aspektin e burimeve disk, pasi do të regjistrohen vetëm blloqet e të dhënave të ndryshuara.
Replikimi / Regjistrimi
Replikimi është mekanizmi për krijimin e një kopje të të dhënave në një tjetër pajisje fizike të ruajtjes. Zakonisht, çdo prodhues ka teknologjinë e tij të markës që punon vetëm brenda gamës së vet. Por gjithashtu ka zgjidhje të tjera të palëve të treta, duke përfshirë ato që funksionojnë në nivelin e hipervizorit, siç është VMware vSphere Replication.
Funksionaliteti i teknologjive të markës dhe lehtësia e përdorimit të tyre zakonisht janë shumë më të avancuara se ato universale, por nuk aplikohen kur, për shembull, duhet të bëni një replikë nga NetApp në HP MSA.
Repikimi ndahet në dy nënllogari:
Sinkronike. Në rastin e replikimit sinkronik, operacioni i shkruar përcillet menjëherë në sistemin e ruajtjes të dytë dhe nuk konfirmohet ekzekutimi derisa sistemi i ruajtjes në distancë të konfirmojë. Kjo rrit vonesën e qasjes, por na ofron një kopje të saktë të dhënash. Pra, RPO = 0 në rast të humbjes së sistemit kryesor.
Asinkronike. Operacionet e shkruara ekzekutohen vetëm në sistemin kryesor dhe konfirmohen menjëherë, duke u mbledhur paralelisht në një tampon për transferim me grup në sistemin e ruajtjes në distancë. Ky lloj replikimi është i rëndësishëm për të dhënat më pak të çmuara, ose për lidhjet me kapacitet të ulët ose me vonesa të larta (karakteristike për distanca mbi 100 km). Përkatësisht RPO = frekuencën e dërgimit me grup.
Shpesh së bashku me replikimin ekziston një mekanizëm journalizimi operacioneve diskore. Në këtë rast, ng allocated to spa për regjistrim dhe ruajnë operacionet e shkruar për një thellësi të caktuar të kohës, ose të kufizuara nga volumi i regjistrit. Për teknologjitë e veçanta të markave, siç është EMC RecoverPoint, ekziston integrimi me softuerin sistemor, që lejon lidhjen e shënimeve të caktuara për një regjistrim të caktuar në regjistër. Falë kësaj, është e mundur të rikthehet gjendja e volumeve (ose të krijohet një klon) jo thjesht në 23 prill në orën 11:59:13, por në momentin që i parapriu 'DROP ALL TABLES; COMMIT'.
Metro cluster
Metro cluster është një teknologji që lejon krijimin e një replikimi dykahësh sinkron midis dy SHT- ve në atë mënyrë që për nga ana e jashtme, kjo çift duket si një SHT. Ajo përdoret për të krijuar klastera me distanca gjeografike të shpërndara në distanca metro (më pak se 100 km).
Si përmbledhje e përdorimit në mjedisin e virtualizimit, metroklausti lejon krijimin e një datastori me makinat virtuale, të cilat janë të disponueshme për shkrim nga dy qendra të të dhënave. Në këtë rast, krijohet një grup në nivelin e hipervizorëve, i përbërë nga hostë në qendra të ndryshme fizike të të dhënave, të lidhur me këtë datastor. Kjo lejon realizimin e sa më poshtë:
- Automatizimi i plotë i procesit të rikuperimit pas vdekjes së njërit prej qendrave të të dhënave. Pa asnjë mjet shtesë, të gjitha VM-të që punonin në qendrën e vdekur do të rinisin automatikisht në atë që mbetet. RTO = kohë ndalimi e grupit të lartë të disponueshmërisë (15 sekonda për VMware) + koha e ngarkimit të sistemit operativ dhe fillimit të shërbimeve.
- Shmangia e katastrofave ose, në gjuhën shqipe, shmangia e katastrofave. Nëse janë planifikuar punime për energjinë elektrike në qendrën e të dhënave 1, atëherë ne me kohë, para fillimit të punimeve, kemi mundësinë të migrojmë të gjithë ngarkesën e rëndësishme në qendrën e të dhënave 2 pa ndërprerje.
Виртуализация
Virtualizimi i SAN është teknologjia që përdor volumet e një SAN tjetër si disqe. Virtualizuesi i SAN mund të thjeshtë të kalojë një volum tjetër për konsumatorin si të tijin, duke e pasqyruar atë në një SAN tjetër, apo madje edhe të krijojë RAID nga volumin e jashtëm.
Përfaqësuesit klasikë në klasën e virtualizimit të SAN janë EMC VPLEX dhe IBM SVC. Sigurisht, SAN-et me funksionin e virtualizimit janë NetApp, Hitachi, IBM / Lenovo Storwize.
Pse mund të nevojitet?
- Mbrojtja në nivelin e SAN. Krijohet një pasqyrë midis volumesh, ku një gjysmë mund të jetë në HP 3Par dhe tjetra në NetApp. Dhe virtualizuesi nga EMC.
- Migrimi i të dhënave me minimumin e pushimit midis SAN-eve të prodhuesve të ndryshëm. Supozoni se të dhënat duhet të migrohen nga një 3Par i vjetër, që do të dalë nga përdorimi, në një Dell të ri. Në këtë rast, konsumatorët janë shkëputur nga 3Par, volumet kalohen përmes VPLEX dhe prezantohen përsëri për konsumatorët. Duke qenë se nuk është ndryshuar asnjë bit në volum, puna vazhdon. Procesi i pasqyrimit të volumit në Dell të ri fillon, dhe pas përfundimit, pasqyra thyhet dhe 3Par shkëputet.
- Organizimi i metrokasterëve.
Kompressimi / deduplicimi
Kompressimi dhe dedupikimi janë teknologjitë që ju lejojnë të kurseni hapësirën e diskut në Storage Area Network (SAN) tuaj. Duhet të përmendet menjëherë se jo të gjithë të dhënat janë të përshtatshme për kompresim dhe/o dedupikim në parim; disa lloje të dhënash kompresohen dhe dedupikohen më mirë, ndërsa disa — përkundrazi.
Kompressimi dhe dedupikimi ndahen në 2 lloje:
Inline — kompresimi dhe dedupikimi i blloqeve të të dhënave ndodh para shkrimit të këtyre të dhënave në disk. Në këtë mënyrë, sistemi vetëm llogarit hash-in e bllokut dhe e krahasohet me tabelën e blloqeve që tashmë ekzistojnë. Së pari, kjo kryhet më shpejt se sa thjesht shkrimi në disk; së dyti, ne nuk shpenzojmë hapësirë të panevojshme në disk.
Post — kur këto operacione kryhen tashmë mbi të dhënat e regjistruara që ndodhen në disqe. Përkatësisht, të dhënat fillimisht regjistrohen në disk, dhe vetëm pas kësaj llogaritet hash dhe ndodhin largimi i blloqeve të panevojshme dhe çlirimi i burimeve disk.
Duhet theksuar se shumica e ofruesve përdorin të dyja llojet, gjë që lejon optimizimin e këtyre proceseve dhe kështu rrit efikasitetin e tyre. Shumica e ofruesve të SAN-ve kanë në dispozicion mjete që lejojnë të analizoni grumbujt tuaj të të dhënave. Këto mjete funksionojnë sipas logjikës që është implementuar edhe në SAN, prandaj niveli i vlerësimit të efikasitetit do të përputhet. Gjithashtu, nuk duhet të harroni se shumë ofrues kanë programe garancie efikasiteti që premtojnë një nivel jo më të ulët se ai që është deklaruar për llojin e caktuar (ose të gjitha) të të dhënave. Dhe nuk duhet ta neglizhoni këtë program, pasi duke kalkuluar sistemin sipas detyrave tuaja, duke marrë parasysh koeficientin e efikasitetit të sistemit të veçantë, mund të kurseni në volumin e tij. Gjithashtu, duhet të merret parasysh se këto programe janë të llogaritura për sistemet AFA, por falë blerjes së një volumi më të vogël SSD sesa HDD në sistemet klasike, kjo do të mundësojë uljen e kostos së tyre, dhe nëse nuk do të barazohet me kostot e sistemit të diskut, do të afrojë shumë me to.
Modeli
Dhe këtu arrijmë te pyetja e saktë.
“Më ofrohen dy variante të SHTP-së – ABC SuperStorage S600 dhe XYZ HyperOcean 666v4, çfarë do të më rekomandonit?”
Shndërrohet në “Më ofrohen dy variante të SHTP-së – ABC SuperStorage S600 dhe XYZ HyperOcean 666v4, çfarë do të më rekomandonit?”
Ngarkesa e synuar janë makina virtuale të përziera VMware me konture produktive / test / zhvillim. Testi = produktivitet. 150 TB për secilin me performancë maksimale 80,000 IOPS për bllok 8kb me 50% qasje të rastësishme 80/20 lexim-shkrim. 300 TB për zhvillim, ku 50,000 IOPS do të mjaftojnë, 80% të rastit, 80% shkrim.
Produktiviteti supozohet të jetë në metrokllaster RPO = 15 minuta, RTO = 1 orë, zhvillimi në replikim asinkron RPO = 3 orë, testi në një vend.
Do të ketë 50 TB të DB-së, do të ishte mirë për ta për journaling.
Kemi gjithandej serverë Dell, SHTP të vjetër Hitachi, që sapo përballojnë, planifikojmë rritje të ngarkesës për 50% në volum dhe performancë.”
Siç thotë, në një pyetje të Formuluar saktë, përfshihet 80% e përgjigjes.
Informacione shtesë
Çfarë duhet të shqyrtojmë më tej sipas autorëve
Libra
- Oлifer dhe Oлifer “Rrjetet kompjuterike”. Libri ndihmon në sistematizimin dhe ndoshta në kuptimin më të mirë se si funksionon mjedisi i transmetimit të të dhënave për sistemet IP / Ethernet të ruajtjes.
- “EMC Information Storage and Management”. Një libër i shkëlqyer mbi bazat e ruajtjes së të dhënave, pse, si dhe përse.
Forume dhe biseda
Rekomandime të Përgjithshme
Çmimet
Tani, sa i përket çmimeve - në përgjithësi në ruajtjen e të dhënave, çmimet, nëse ndodhin, zakonisht janë çmimi i listës, nga i cili çdo klient merr një zbritje të veçantë. Shuma e zbritjes përbëhet nga shumë parametra, kështu që është e pamundur të parashikohet çmimi përfundimtar që do të marrë kompania juaj pa bërë një kërkesë te distributori. Por së fundmi, modelët me kosto të ulët kanë filluar të shfaqen në dyqanet e zakonshme të kompjuterëve, si për shembull ose . Në të cilat mund të blini menjëherë sistemin që ju intereson për një çmim të fiksuar, ashtu si çdo pajisje kompjuterike.
Por duhet theksuar menjëherë se krahasimi i drejtpërdrejtë sipas TB/$ nuk është i saktë. Nëse e shohim nga kjo pikëpamje, zgjidhja më e lirë do të ishte një JBOD i thjeshtë + një server, i cili nuk do të ofronte as fleksibilitetin dhe as qëndrueshmërinë që siguron një sistem i plotë, me dy kontrollues. Kjo nuk do të thotë se JBOD është një gjë e tmerrshme dhe një marrëzi, thjesht është shumë e rëndësishme të kuptoni saktësisht – si dhe për çfarë qëllimesh do të përdorni këtë zgjidhje. Shpesh mund të dëgjoni se në JBOD nuk ka çfarë të thyhet, pasi është vetëm një backplane. Megjithatë, backplane të tilla gjithashtu mund të dështojnë. Çdo gjë thyhet рано или поздно.
Në përfundim
Duhet të krahasohen sistemet jo vetëm sipas çmimit, ose vetëm sipas performancës, por sipas një kombinimi të të gjitha treguesve.
Blini HDD vetëm nëse jeni të sigurt se ju nevojiten HDD. Për ngarkesa të ulëta dhe lloje të dhënash të paushqyera, përndryshe, duhet të shqyrtoni programet e garancisë për efikasitetin e ruajtjes në SSD, që tani ka shumica e ofruesve (dhe ato vërtet funksionojnë, madje dhe në Rusi), por këtu gjithçka vares nga aplikacionet dhe të dhënat që do të vendosen në këtë sistem.
Mos u ndiqni pas çmimeve të ulëta. Ndonjëherë, pas tyre fshihen shumë çështje të pakëndshme, njëra prej të cilave është përshkruar nga Evgeni Elizariov në shkrimet e tij për . Dhe çfarë, në fund të fundit, kjo çmim i ulët mund t'ju kthehet si një bumerang. Mos harroni - "kush kursen paguan dy herë".
Burimi: habr.com
