Sissejuhatus
On jõudnud aeg osta andmesalvestussüsteem. Milline valida ja kellele kuulata? Vendor A räägib vendorist B, aga on ka integrator C, kes räägib vastupidist ja soovitab vendorit D. Sellises olukorras võib isegi kogenud andmesalvestuse arhitekti pea ringi minna, eriti kõigi uute vendorite ja tänaste moekate SDS-i ja hüperkonvergentsi tõttu.
Nii et kuidas kõigest sellest aru saada ja mitte lolliks minna? Me ( Anton Zhbankov ja Evgeny Elizarov) proovime sellest rääkida eesti keeles selgelt.
Artikkel seondub suuresti ja on tegelikult laiendus “” kontekstis andmesalvestussüsteemide valiku ja salvestustehnologiate ülevaate osas. Vaatleme lühidalt üldteooriat, kuid soovitame tutvuda ka nimetatud artikliga.
Miks
Sageli võib kohata olukorda, kus uus inimene jõuab foorumisse või spetsialiseeritud vestlusesse, nagu näiteks Storage Discussions, ja küsib: “Mulle pakutakse kahte varianti andmesalvestust — ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitate?”
Ja algab mõõtmine, kellel on millised kohandatud ja arusaamatud funktsioonid, mis on tavalise inimese jaoks täiesti hiina keel.
Nii et esimene ja kõige olulisem küsimus, mille peaks endale esitama kaua enne kui võrrelda spetsifikatsioone kommertspakkumistes — MIKS? Miks vajame seda andmesalvestust?
Vastus on üllatav ja väga Tony Robbinsi stiilis — et andmeid salvestada. Aitäh, kapten! Ja ometi, mõnikord süveneme nii kaugele detailide võrdlemisse, et unustame, miks me seda kõike teeme.
Nii et andmesalvestussüsteemi ülesanne on andmete salvestamine ja nendele määratud jõudlusega juurdepääsu andmine. Andmetest me ka alustame.
Andmed
Andmete tüüp
Millised andmed me plaanime salvestada? See on väga oluline küsimus, mis võib kõrvaldada paljusid salvestussüsteeme isegi arutelust. Näiteks, kui plaanitakse salvestada videomaterjale ja fotosid. Siis võib kohe kõrvaldada süsteemid, mis on mõeldud juhuslikuks juurdepääsuks väikeste plokkide kaupa, või süsteemid, millel on tootja 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 osutuda vastupidiseks nõrkusteks (video ja foto ei komprimeeru) või lihtsalt suurendada süsteemi hinda märkimisväärselt.
Ja vastupidi, kui sihtotstarbeks on suure koormusega tehinguteandmebaas, siis suurepärased voogesitusüsteemid multimeedia jaoks, mis suudavad edastada gigabaitide kaupa sekundis, oleksid kehv valik.
Andmemaht
Kui palju andmeid me plaanime salvestada? Kogus muutub alati kvaliteediks, seda ei tohi kunagi unustada, eriti meie aja eksponeeruva andmemahtu arvestades. Petabaitide klassi süsteemid ei ole enam haruldased, kuid mida suurem on petabaitide maht, seda spetsiifilisemaks muutub süsteem, ja vähem on tavapärast funktsionaalsust väikese ja keskmise mahu juhusliku juurdepääsuga süsteemides. Lihtsalt sellepärast, et üksnes juurdepääsu statistika tabelid plokkide kaupa muutuvad suuremaks kui olemasolev operatiivmälu kontrolleritel. Rääkimata kompressioonist / tirimisest. Oletame, et tahame vahetada kompressioonialgoritmi võimsama vastu ja suruda kokku 20 petabaiti andmeid. Kui kaua see aega võtab: kuus kuud, aasta?
Teiselt poolt, miks ehitada suurt infrastruktuuri, kui tuleb salvestada ja töödelda 500 GB andmeid? Ainult 500. Kodused SSD-d (madala DWPD-ga) sellise mahuga maksavad tõeliselt vähe. Miks ehitada sellega seoses Fiber Channeli tehast ja osta kõrgekvaliteediline väline salvestussüsteem, mille hind on nagu raudbetoonist sild?
Kui suur osa kogu mahust on kuumad andmed? Kui ebaühtlane on koormus andmete mahus? Just siin võib tehnoloogia mitmekihilistest andmete talletamisest või Flash Cache'ist olla suureks abiks, kui kuumade andmete maht on võrreldes kogumahuga vähenenud. Vastupidi, kui koormus on ühtlane kogu mahus, mis esineb sageli voosüsteemides (videoivalve, teatud analüütikasüsteemid), siis sellised tehnoloogiad ei too kasu ja suurendavad ainult süsteemi kulusid / keerukust.
IS
Andmete vastaspooleks on infotehnoloogiasüsteem, mis kasutab neid andmeid. IS-l on hulk nõudmisi, mis pärinevad andmetest. Rohkem teavet IS kohta vt „Virtuaalset andmekeskust kujundades“.
Tõrketaluvuse / kättesaadavuse nõuded
Tõrketaluvuse / kättesaadavuse nõuded andmete osas pärinevad neid kasutavast IS-st ja väljenduvad kolmes numbris — RPO, RTO, kättesaadavus.
Saadavus — osa määratud ajavahemikus, mille jooksul andmed on tööks kättesaadavad. Seda väljendatakse tavaliselt devideerimisega 9. Näiteks kaks üheksat aastas tähendab, et kättesaadavus on 99%, ehk lubatakse 95 tunni mitteolek aastas. Kolm üheksat — 9,5 tundi aastas.
RPO / RTO — need näitajad ei ole kogusummad, vaid iga intsident (õnnetus) eraldi, erinevalt kättesaadavusest.
RPO — andmete hulk, mis kadus õnnetuse korral (tundides). Näiteks, kui varukoopiaid tehakse kord ööpäevas, siis RPO = 24 tundi. See tähendab, et õnnetuse ja täieliku andmesalvestuse kaotuse korral võivad andmed kaduda kuni 24 tundi (viimase varukoopia ajast). Vastavalt IS-le määratud RPO-le, näiteks, koostatakse varukoopiate regulatsioon. Samuti, RPO-st lähtuvalt, saab aru, kui vajalik on andmete sünkroonne / asünkroonne replikatsioon.
RTO — teenuse (andmete kättesaadavuse) taastamise aeg pärast õnnetust. Vastavalt antud RTO väärtusele saame aru, kas on vajalik metroklaster või piisab ühesuunalisest replikatsioonist. Kas on vajalik mitme kontrolleriga andmesalvestus hi-end klassis — samuti.
Tõhususe nõuded
Kuigi see on täiesti ilmne küsimus, tekib sellega just kõige rohkem raskusi. Sõltuvalt sellest, kas teil on juba mingisugune infrastruktuur või mitte, ning millised on vajaliku statistika kogumise teed.
Teil on juba olemasolev salvestussüsteem ning otsite sellele asendust või soovite soetada veel ühe laienemiseks. Siin on kõik lihtne. Te mõistate, millised teenused teil juba on ja milliseid plaanite lähitulevikus juurutada. Lähtuvalt olemasolevatest teenustest on teil võimalus koguda statistikat jõudluse kohta. Määrake praegune IOPS ja viivitused — millised on need näitajad ja kas need piisavad teie ülesannete jaoks? Seda on võimalik teha nii salvestussüsteemis endas kui ka hostide poolt, mis on sellele ühendatud.
Siinkohal tuleks jälgida mitte ainult praegust koormust, vaid ka mingit perioodi (parem oleks kuu). Vaadake, millised on maksimaalsed tipud päeva jooksul, millist koormust tekitab varundamine jne. Kui teie salvestussüsteem või sellele tarkvara ei paku teile täielikku andmete komplekti, võite kasutada tasuta RRDtooli, mis oskab töötada enamikuga populaarsemaid salvestussüsteeme ja lüliteid ning suudab anda teile üksikasjaliku jõudlustatistika. Samuti tasub vaadata koormust ka hostides, mis töötavad selle salvestussüsteemiga, konkreetsete virtuaalmasinate või selle hosti teiste elementide kaupa.
Tasub eraldi mainida, et kui viivitused mahul ja andmestooris, mis asub sellel mahul, erinevad üsna tugevalt — tasub tähelepanu pöörata teie SAN-võrgule, tõenäosus on, et seal on probleeme ja enne uue süsteemi soetamist tasuks selle küsimusega tegeleda, kuna on väga suur tõenäosus, et praeguse süsteemi jõudlust on võimalik parandada.
Te rajate infrastruktuuri nullist või soetate süsteemi uue teenuse jaoks, mille koormusest te ei ole teadlik. Siin on mitu võimalust: suhelda kolleegidega spetsialiseeritud ressurssides, et proovida välja selgitada ja prognoosida koormust, pöörduda integreerija poole, kellel on kogemusi sarnaste teenuste juurutamises ja kes suudab koormuse teie eest arvutada. Ja kolmas variant (tavaliselt kõige keerulisem, eriti kui see puudutab kohandatud või haruldaseid rakendusi) on proovida välja selgitada jõudlusnõuded süsteemi arendajatelt.
Ja, tähelepanu, kõige sobivam variant praktilise kasutuse seisukohalt on piloot olemasoleval seadmel või seadmel, mis on antud katsetamiseks tootja / integreerija poolt.
Erinõuded
Erinõuded — kõik, mis ei kuulu otse andmete töötlemise ja edastamise jõudlus-, talitluse ja funktsionaalsuse nõuete alla.
Üks lihtsamaid erinõudeid andmesalvestussüsteemile on "üleminekul saadaval olevad teabe kandjad". Ja kohe on selge, et see andmesalvestussüsteem peab sisaldama lintraamatukogu või lihtsalt streamerit, kuhu kopeeritakse varukoopia. Pärast seda allkirjastab spetsiaalselt koolitatud inimene lindi ja kannab selle uhkelt spetsiaalsesse seifisse.
Teine näide erinõudest on löögikindel täideviimine.
Kus
Teine peamine tegur andmesalvestussüsteemi valimisel on teave selle kohta, KUS see süsteem asub. Alates geograafiast või kliimatingimustest kuni personali küsimusteni.
Tellija
Kellele on see andmesalvestussüsteem mõeldud? Küsimus tugineb järgnevatele aluspunktidele:
Riiklik tellija / kommertstellijad.
Kommertstellijal ei ole mingeid piiranguid ja ta ei ole kohustatud isegi hankeid korraldama, välja arvatud vastavalt oma sisereeglitele.
Riiklik tellija — olukord on teine. 44 FZ ja muud hanke- ja TŠ-süsteemi omadused, mida võivad vaidlustada.
Tellija sanktsioonide all
Siin on küsimus väga lihtne — valik piirdub ainult nende pakkumistega, mis on sellele tellijale kergesti kätte saadavad.
Sisedokumendid / ostmiseks lubatud tootjad / mudelid
Küsimus on samuti äärmiselt lihtne, kuid seda tuleks meeles pidada.
Kus füüsiliselt
Selles osas vaatleme kõiki geograafia, sidekanalite ja ruumide mikrokliima küsimusi.
Personal
Kes hakkab selle andmesalvestussüsteemiga töötama? See on mitte vähem oluline kui see, mida andmesalvestussüsteem ise suudab.
Kuigi A tootja andmesalvestussüsteem võib olla perspektiivikas, lahe ja suurepärane, pole selle paigaldamisel ilmselt mõtet, kui personal oskab töötada ainult tootja B süsteemiga ning edasised ostud ja pidev koostöö A-ga ei ole plaanis.
Ja selgelt, teise poole küsimus on — kui kergesti on selles geograafilises asukohas kätte saadav ettevalmistatud personal otse ettevõttest ja potentsiaalselt tööturult. Piirkonnast sõltuvalt võib olla oluline valida andmekeskuse lahendus, millel on lihtsad liidesed või võimalus kaugjuhtimiseks tsentraliseeritud juhtimise kaudu. Vastasel juhul võib mingil hetkel tekkida tõsiseid probleeme. Internet on täis lugusid, kuidas uus töötaja, kes on eelmisel päeval lõpetanud ülikooli, konfigureeris midagi, mis viis kogu firma kokku kukkumiseni.
Keskkond
Ja loomulikult on oluline küsimus — millises keskkonnas see andmekeskuse lahendus töötab.
- Kuidas on lood elektri- / jahutusega?
- Milline on ühendus?
- Kuidas see paigaldatakse?
- Ja nii edasi.
Tihti peetakse neid küsimusi iseenesestmõistetavateks ja neid ei kaaluta tõsiselt, kuid vahel võivad just need küsimused kõik pahupidi pöörata.
Mis?
Tootja
Tänase seisuga (2019. aasta keskpaik) võib Venemaa andmekeskuste turgu jagada viieks tinglikuks kategooriaks:
- Kõrgeim divisjon — tunnustatud ettevõtted laia tooteportfelliga, alates lihtsatest ketaspinkidest kuni hi-end lahendusteni (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Teine divisjon — ettevõtted piiratud tooteportfelliga, nišimängijad, tõsised SDS tarnijad või uued tõusvad tegijad (Fujitsu, Datacore, Infinidat, Huawei, Pure jne)
- Kolmas divisjon — nišilahendused madalama otsa tasemel, odav SDS, ega ka madalate tasemete lahendused ceph'il ja teistel avatud projektidel (Infortrend, Starwind jne)
- SOHO-segment — väikesed ja ülikerged andmekeskused kodu/väike büroo tasemel (Synology, QNAP jne)
- Imporditud andmekeskused — siia kuuluvad nii esimese divisjoni riistvara uuesti bränditud, kui ka haruldased teise divisjoni esindajad (RAIDIX, anname neile eeliseks teise), kuid peamiselt on need kolmas divisjon (Aerodisk, Baum, Depo jne)
Jagamine on päris tinglik ja ei tähenda sugugi, et kolmas või SOHO segment on halb ning neid ei saa kasutada. Spetsiifilistes projektides, millel on selgelt määratletud andmekogum ja koormusprofiil, võivad need töödelda väga hästi, ületades esimest divisjoni hinna/kvaliteedi osas. Oluline on esmalt määrata ülesanded, kasvuvõimalused, vajalikud funktsioonid — ja siis töötab Synology teile truult, samas kui juuksed saavad pehmeks ja siidiseks.
Üks olulisi tegureid teenusepakkuja valimisel on praegune keskkond. Kui palju ja milliseid salvestusseadmeid teil juba on, milliste salvestusseadmetega oskavad insenerid töötada. Kas vajate veel ühte teenusepakkujat, veel ühte kontaktpunkti, kas kavatsete kogu koormuse järk-järgult teenusepakkujalt A teenusepakkujale B üle viia?
Ei tohiks luua entiteete rohkem kui hädavajalik.
iSCSI / FC / File
Ligipääsu protokollide osas pole inseneride seas ühtemeelsust, ja vaidlused meenutavad pigem teoloogilisi arutelu, kui inseneriteemasid. 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 olemasolu andmete juurde pääsemiseks, neutraliseeritakse eraldatud IP võrguga. FC-l ei ole globaalseid eeliseid IP-võrkude ees, ja IP-le saab ehitada salvestusseade mis tahes koormuse tasemele, sealhulgas raskete andmebaasisüsteemide (ABS) jaoks suurte pankade jaoks. Teisest küljest on FC surma ennustatud juba mitu aastat, kuid midagi takistab seda. Täna, näiteks, arendavad mõned salvestussektoris tegutsejad aktiivselt NVMEoF standardit. Kas see eraldab FCoE saatuse — näitab aeg.
Failipääs ei ole samuti midagi tähelepanuta jäetavat. NFS / CIFS toimivad suurepäraselt tootmiskeskkondades ja õige projekteerimise korral on neil sama palju kaebusi kui plokkprotokollidel.
Hübriid / All Flash Array
Klassikalised salvestusseadmed jagunevad kahte tüüpi:
- AFA (All Flash Array) — süsteemid, mis on optimeeritud SSD-de kasutamiseks.
- Hübriid — võimaldavad kasutada nii HDD-d kui SSD-d või nende kombinatsiooni.
Nende peamine erinevus on toetatavad salvestustehnoloogiad ja maksimaalne jõudlus (kõrged IOPS näitajad ja madalad latentsusajad). Mõlemad süsteemid (enamikus oma mudelites, välja arvatud madala lõpuga segment) saavad töötada nii plokkseadmestena kui ka failiseadmetena. Süsteemi tase määrab ka toetatava funktsionaalsuse, ning madalamate mudelite puhul on see enamasti piiratud minimaalse tasemega. Sellele tasub tähelepanu pöörata, kui uurite konkreetse mudeli omadusi, mitte lihtsalt tootesarja üldisi võimalusi. Samuti sõltuvad süsteemi tehnilised omadused, nagu protsessor, mälu, vahemälu, portide arv ja tüübid jne, süsteemi tasemest. Mis puutub haldustarkvarasse, siis AFA-d erinevad hübriidsüsteemidest (ketas) vaid SSD-de kasutamise mekanismide rakendamise küsimustes, ja isegi kui kasutate SSD-sid hübriidsüsteemis, ei tähenda see, et saavutate AFA-süsteemi tasemel jõudluse. Enamikul juhtudel on hübriidsüsteemides inline efektiivse salvestamise mekanismid keelatud ning nende sisselülitamine põhjustab jõudluse languse.
Spetsiaalsed salvestussüsteemid
Lisaks üldotstarbelistele salvestussüsteemidele, mis on suunatud peamiselt andmete operatiivsele töötlemisele, eksisteerivad spetsiaalsed salvestussüsteemid, mille põhialused erinevad tuntud omadustest (madal latentsus, kõrge IOPS):
Meedia.
Need süsteemid on mõeldud meediafailide salvestamiseks ja töötlemiseks, mis eristuvad suure suurusega. Seetõttu muutub latentsus praktiliselt ebaoluliseks ja esiplaanile tõuseb laia ribalaiuse võimalus andmete vastuvõtmiseks ja edastamiseks mitme paralleelse voolu kaudu.
Dedupikatsiooniga salvestussüsteemid varukoopiateks.
Kuna varukoopiad erinevad tavalistes tingimustes harva üksteisega (keskmine varukoopia erineb eilsetest 1-2% võrra), pakendavad need süsteemid äärmiselt tõhusalt enda peale salvestatud andmeid piisavalt vähese füüsilise mälumahu piires. Näiteks mõningatel juhtudel võib andmete kokkusuru määr ulatuda 200:1.
Objektil põhinevad salvestussüsteemid.
Need to add translation for this string
Järgnev süsteemide jälgimiseks.
Need ei ole Eestis väga levinud, kuid neist tasub rääkida. Nende süsteemide eesmärk on tagada andmete säilitamine vastavuses turvapoliitikate või regulatiivsete nõuetega. Mõnedes süsteemides (nt EMC Centera) on rakendatud funktsioon andmete kustutamise keeldumise korral - niipea kui võti keeratakse ja süsteem läheb sellesse režiimi, ei saa administrator ega keegi teine füüsiliselt kustutada juba salvestatud andmeid.
Bränditehnoloogiad
Flash cache
Flash Cache on üldine nimetus kõigile bränditehnoloogiatele, mis kasutavad flash-mälu teise taseme vahemäena. Flash-cache'i kasutamisel arvutatakse süsteemi koormust magnetketastelt, samas kui tippkoormust teenindab vahemälu.
Oluline on mõista koormuse profiili ja sekkumise aste salvestustükkide plokkidesse. Flash Cache on tehnoloogia, mis on mõeldud suure lokaaliseerimisega päringute koormustele ja on praktiliselt kasutamiskõlbmatu ühtlaselt koormatud mahtude jaoks (nagu näiteks analüüsi süsteemide jaoks).
Turul on saadaval kaks flash-cache'i rakendust:
- Read Only. Selles režiimis salvestatakse ainult lugemisandmed, samas kui kirjed suunatakse kohe kettale. Mõned tootjad, nagu NetApp, usuvad, et kirjed nende süsteemides toimuvad optimaalselt ja vahemälu ei aita.
- Read/Write. Salvestatakse mitte ainult lugemine, vaid ka kirjutamine, mis võimaldab voolu vahemällu salvestada ja vähendab RAID karistuse mõju, mille tulemusena tõuseb üldine jõudlus süsteemides, kus kirjutamise mehhanism ei ole nii optimeeritud.
Tiering
Mitmetasandiline salvestamine (tiering) on tehnoloogia, mis ühendab ühte ketta bassein sisemise taseme, nt SSD ja HDD erineva jõudlusega. Kui andmeblokke kasutatakse ebaühtlaselt, suudab süsteem automaatselt tasakaalustada andmeblokke, liikudes koormatud kõrge jõudlusega tasemele ning külmad madalama kiiruseni.
Alumise ja keskmise klassi hübriidsüsteemid kasutavad mitmetasandilist salvestust andmete liigutamisega tasandite vahel vastavalt graafikule. Samuti on mitmetasandilise salvestuse ploki suurus parimates mudelites 256 MB. Need omadused ei võimalda mitmetasandilist salvestust pidada jõudluse suurendamise tehnoloogiaks, nagu paljud ekslikult arvavad. Mitmetasandiline salvestus alumise ja keskmise klassi süsteemides on salvestuskulude optimeerimise tehnoloogia, mida iseloomustab väljendunud ebaühtlane koormus.
Snapshot
Kui palju me ka räägime andmeside salvestuslahenduste usaldusväärsusest, on mitu võimalust andmete kaotamiseks, mis ei sõltu riistvaraprobleemidest. Need võivad olla näiteks viirused, häkkerid või igasugune muu tahtmatu andmete kustutamine/katkestamine. Selle tõttu on tootmisandmete varundamine inseneri töö oluline osa.
Snapshot on hetke pilt mahust. Enamikus süsteemides, nagu virtualiseerimine, andmebaasid jne, on meil vaja sellist pilti, millest saame andmeid varundamiseks kopeerida, samal ajal kui meie infosüsteemid saavad rahulikult seda mahtu kasutada. Kuid tuleb meeles pidada, et kõik snapshots ei ole võrdselt kasulikud. Erinevatel tarnijatel on erinevad lähenemised snapshotsi loomisele, mis on seotud nende arhitektuuriga.
CoW (Copy-On-Write). Andmeploki kirjutamise katse korral kopeeritakse originaali sisu spetsiaalsesse piirkonda ning seejärel toimub kirjutamine normaalselt. Sellega ennetatakse andmete kahjustamist snapshotsis. Loomulikult kutsuvad kõik need „parasiitlikud“ andmete manipuleerimised esile täiendava koormuse andmeside salvestuslahendusele ning seetõttu ei soovita sellise rakenduse tarnijad kasutada rohkem kui tosin snapshotsi, ja kõrge koormusega mahtudel ei soovita neid üldse kasutada.
RoW (Redirect-on-Write). Sellisel juhul külmutatakse originaalne maht, ja andmeploki kirjutamise katse korral salvestab andmeside salvestuslahendus andmed spetsiaalsesse vaba ruumi, muutes ploki asukohta metandmete tabelis. See vähendab ümberkirjutamise operatsioonide arvu, mis lõpuks tasakaalustab jõudluse languse ja eemaldab piirangud snapshotside ja nende arvu osas.
Snapshots võivad samuti olla kahesugused rakenduste suhtes:
Rakenduste konsistentne. Snapshot’i loomise hetkel kutsub andmeside salvestuslahendus üles rakenduse agenti kliendi operatsioonisüsteemis, mis sunnib diskivahendi vahemälu mälust kettale tühjendama ja paneb rakenduse seda tegema. Sellisel juhul taastamisel snapshotsist on andmed konsistentsed.
Krahhi konsistentneSellest tulenevalt ei juhtu midagi sarnast ja kohandamine toimub sellisena nagu see on. Taastamisel sellisest kohandamisest on olukord identne nagu siis, kui toide ootamatult katkevad ning andmete kadumisvõimalus, mis on jäänud vahemälude külge ja pole kunagi ketasse jõudnud, on olemas. Sellised kohandamised on kergemini rakendatavad ja ei põhjusta rakendustes jõudluse langust, kuid on vähem usaldusväärsed.
Miks on andmesalvestussüsteemides vajalikke kohandamisi?
- Agendivaba varundamine otse andmesalvestussüsteemist
- Testimiskeskkondade loomine reaalse arenduse andmete põhjal
- Failide andmesalvestussüsteemide puhul saab kasutada VDI keskkondade loomiseks, kasutades andmesalvestussüsteemi kohandamisi hüpervisaatori asemel
- Madala RPO tagamine kohandamiste loomisega ajakava põhjal, mille sagedus on märkimisväärselt kõrgem kui varundamise sagedus
Klonimine
Mahuti klonimine töötab sarnaselt kohandamistele, kuid mitte lihtsalt andmete lugemiseks, vaid nende täielikuks kasutamiseks. Meil on võimalus saada täpne koopia meie mahutist koos kõigi selle andmetega ilma füüsilise koopia tegemiseta, mis säästab ruumi. Tüüpiliselt kasutatakse mahutite klonimist kas Test&Dev'is või kui soovite testida, kuidas mingid uuendused teie süsteemis töötavad. Klonimine võimaldab seda teha maksimaalselt kiiresti ja ökonoomselt kettaressursside vaates, kuna kirjutatakse ainult muudetud andmeplokid.
Replikatsioon / ajakirjastamine
Replikatsioon on mehhanism, mis loob andmete koopia teisele füüsilisele andmesalvestussüsteemile. Iga tootja jaoks on tavaliselt oma ainulaadne tehnoloogia, mis töötab ainult nende enda tootesarjas. Samuti on olemas ka kolmandate osapoolte lahendusi, sealhulgas need, mis töötavad hüpervisaatori tasemel, nagu näiteks VMware vSphere Replikatsioon.
Tootjate tehnoloogiate funktsionaalsus ja kasutusmugavus ületavad tavaliselt universaalseid lahendusi, kuid need ei ole rakendatavad, kui on näiteks vajalik teha replikatsioon NetAppist HP MSA-le.
Replikatsioon jaguneb kaheks alamliigiks:
Sünkroonne. Sünkrone replikatsiooni korral edastatakse kirjutamistegevus koheselt teisele salvestusseadmestikule ning selle täitmine ei kinnitata, kuni kaugseade ei kinnita. Sellega suureneb ligipääsu latentsus, kuid me saame täpse peegeldatud koopia andmetest. Ehk RPO = 0 põhiseadmestiku kadumise korral.
Asünkroonne. Kirjutamistegevused täidetakse ainult peamisel salvestusseadmestikul ja need kinnitatakse kohe, samal ajal kogunedes puhvris, et edastada need pakettide kaupa kaugseadmestikule. Selline replikatsiooni tüüp on asjakohane vähem väärtuslike andmete jaoks, või madala läbilaskevõimega kanalitele, või kanalitele, kus esineb kõrge latentsus (iseloomulik kaugustele üle 100 km). Seega RPO = pakettide saatmise sagedusele.
Tihti koos replikatsiooniga eksisteerib mehanism logimise kettaoperatsioonide jaoks. Sel juhul eraldatakse spetsiaalne ala logimiseks ja salvestatakse kirjutamistegevused teatud ajasügavuse järgi, või piiratud logi mahuga. Eriliste tehnoloogiate, nagu näiteks EMC RecoverPoint, puhul on olemas integratsioon süsteemse tarkvaraga, mis võimaldab siduda teatud märkmeid kindla kirje logis. Tänu sellele on võimalik tagastada mahtude olek (või luua kloon) mitte lihtsalt 23. aprillil kell 11:59:13.013, vaid hetkel, mis eelnes “DROP ALL TABLES; COMMIT”.
Metro klaster
Metro klaster — tehnoloogia, mis võimaldab luua kahe salvestusseadmestiku vahel kahepoolse sünkrone replikatsiooni, nii et selline paar näib väljastpoolt nagu üks seade. Seda kasutatakse klastrite loomiseks geograafiliselt hajutatud harudega metro-oktoobria vahemaa (alla 100 km).
Näiteks virtuaalsete masinate keskkonnas võimaldab metro klaster luua andmestori, mis on kirjutamiseks koheselt saadaval kahest andmekeskusest. Sel juhul luuakse klaster hüperviisorite tasemel, koosnedes erinevates füüsilistes andmekeskustes paiknevatest hostidest, mis on ühendatud selle andmestoriga. See võimaldab järgmist:
- Täielik automatiseerimine andmekeskuse surmast taastumise protsessis. Ilma täiendavate vahenditeta käivituvad kõik VM-d, mis töötasid surnud andmekeskuses, automaatselt ülejäänud andmekeskuses. RTO = kõrge saadavuse klastrite aegumisaeg (15 sekundit VMware jaoks) + operatsioonisüsteemi käivitamise ja teenuste alustamise aeg.
- Katastrite vältimine ehk disaster avoidance. Kui andmekeskuses 1 on plaanitud elektritööd, saame eelnevalt, enne tööde algust, migreerida kogu olulise koormuse andmekeskusesse 2 nonstop.
Virtualiseerimine
DRA virtualiseerimine on tehniliselt seotud teiste DRA-de mahtude kasutamisega diskidena. DRA virtualiseerija võib lihtsalt suunata võõra mahu tarbijale kui oma, samal ajal peegeldades seda veel ühe DRA-le, või isegi luua RAID välistest mahtudest.
Klassikalised esindajad DRA virtualiseerimise klassis on EMC VPLEX ja IBM SVC. Ja loomulikult DRA-d, millel on virtualiseerimise funktsioon - NetApp, Hitachi, IBM / Lenovo Storwize.
Miks seda vaja võib minna?
- DRA taseme reserveerimine. Luues peegli mahtude vahel, kus üks pool võib olla HP 3Par-il ja teine NetApp-il. Ja virtualiseerija EMC-lt.
- Andmete üleviimine minimaalsete seisakute ajal erinevate tootjate DRA-de vahel. Oletame, et andmed tuleb migreerida vanalt 3Par-ilt, mis läheb väljalaskmisele, uuele Dellile. Sel juhul katkestatakse tarbijad 3Par-ilt, mahud suunatakse VPLEX-i ja esitatakse tarbijatele uuesti. Kuna mahtude peal ei ole ühtegi bitti muudetud, jätkub töö. Taustal käivitub protsess mahu peegeldamiseks uuele Dellile ning lõpetamisel puruneb peegel ja 3Par väljajätetakse.
- Metroklastrite korraldamine.
Kompresseerimine / dedupeerimine
Kompresseerimine ja dedupeerimine on tehnoloogiad, mis võimaldavad teil säästa ketta ruumi teie DRA-l. Tuleb kohe märkida, et kõik andmed ei allu kompressioonile ja / või dedupeerimisele, samas kui mõned andmete tüübid tihenduvad ja dedupeeruvad paremini, teised aga vastupidiselt.
Kompresseerimine ja dedupeerimine on kahte tüüpi:
Inline — andmed blokke kokkusurumine ja deduplikatsioon toimub enne nende andmete kirjutamist kettale. Seeläbi süsteem lihtsalt arvutab ploki räsiväärtuse ja võrdleb seda juba olemasolevate tabelitega. Esiteks toimub see kiiremini kui lihtsalt kirjutamine kettale, teiseks ei kuluta me liigset kettaruumi.
Post — kui neid operatsioone viiakse läbi juba kirjutatud andmete puhul, mis on ketastel. Seega andmed salvestatakse esmalt kettale ja alles seejärel arvutatakse räsiväärtus ning toimub liigsete plokkide eemaldamine ja kettaruumi vabastamine.
On oluline märkida, et enamik müüjatest kasutab mõlemat tüüpi, mis võimaldab neid protsesse optimeerida ja seeläbi tõsta nende efektiivsust. Enamikul andmesalvestussüsteemide (СХД) müüjatest on olemas utiliidid, mis võimaldavad analüüsida teie andmete kogumeid. Need utiliidid töötavad sama loogika põhjal, mis on rakendatud ka СХД-s, seega efektiivsuse hinnanguline tase vastab. Samuti ei tohi unustada, et paljudel müüjatel on efektiivsuse garantiiprogrammid, mis lubavad taset, mis ei ole madalam kui lubatud teatud (või kõikide) andmetüüpide jaoks. Ja seda programmi ei tohiks alahinnata, sest teie süsteemi ülesehitamisel, arvestades konkreetse süsteemi efektiivsuse koefitsiendi, saate mahtu kokku hoida. Samuti tuleks arvestada, et need programmid on mõeldud AFA-süsteemidele, kuid tänu väiksema SSD mahu ostmisele võrreldes HDD-dega klassikalistes süsteemides, on võimalik nende hinda alandada ja kui mitte võrdsustada diskosüsteemide hindadega, siis sellega üsna lähedale jõuda.
Mudel
Ja siin jõuame õigesti esitatud küsimuseni.
“Mulle pakuvad kahte varianti СХД — ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitaksite?”
Muundub “Mulle pakuvad kahte varianti СХД — ABC SuperStorage S600 ja XYZ HyperOcean 666v4, mida soovitaksite?
Cdn. sihtkoormus on segatud virtuaalmasinad VMware produktiivsete / test / arendavate kontuuride jaoks. Test = produktiiv. 150 TB igaühe jaoks, mille maksimaalne jõudlus on 80 000 IOPS 8kb ploki suurusega 50% juhuslik juurdepääs 80/20 lugemine-kirjutamine. 300 TB arenduseks, seal piisab 50 000 IOPS-st, 80 juhuslikult, 80 kirjutamiseks.
Produktiivsus eeldatavasti metroklastris RPO = 15 minutit RTO = 1 tund, arendus asünkroonses replikatsioonis RPO = 3 tundi, test ühel saidil.
50 TB and a database would benefit from logging.
We have Dell servers everywhere, and the old Hitachi storage systems are barely keeping up; we're planning a 50% increase in load by volume and performance.
As they say, a well-formulated question contains 80% of the answer.
Lisainformatsioon
What to explore further, according to the authors.
Raamatud
- Oliker and Oliker, "Computer Networks". This book will help systematize and possibly better understand how the data transmission environment works for IP/Ethernet storage systems.
- "EMC Information Storage and Management". A great book on the fundamentals of storage systems: why, how, and for what.
Forums and chats
General recommendations
Hinnad
Now, regarding prices—storage systems' prices are usually list prices, from which each customer receives an individual discount. The size of the discount is based on a large number of parameters, so it is impossible to predict what final price your company will receive without a inquiry to the distributor. However, recently, low-end models have begun appearing in regular computer stores, such as või . In these stores, you can immediately purchase the system of interest at a fixed price, just like any other computer components.
However, I want to note right away that direct comparisons based on TB/$ aren't valid. If approached from this perspective, the cheapest solution would be a simple JBOD and server, which won't provide the flexibility or reliability of a full-featured, dual-controller storage system. This certainly doesn't mean JBOD is a terrible option; one just needs to understand clearly how and for what purposes they will use this solution. It's often said that there's nothing to break in a JBOD since there's just one backplane. However, backplanes can fail too. Everything breaks down sooner or later.
Kokkuvõttes
When comparing systems, it is necessary to consider not only the price or only the performance, but also the overall combination of all indicators.
Osta HDD ainult siis, kui oled kindel, et sul on HDD-d vaja. Madala koormuse ja mittekompressitavate andmetüüpide jaoks on mõistlik kaaluda SSD-ide efektiivsuse garantii programme, mis on nüüd enamikes vedajates olemas (ja need tõesti töötavad, isegi Venemaal), kuid kõik sõltub rakendustest ja andmetest, mis sellel andmesalvestussüsteemil asuvad.
Ära jälita odavust. Mõnikord peitub selle taga palju ebameeldivaid asju, millest kirjutas Evgeni Elizarov oma artiklites kohta. . Ja lõpuks võib see odavus sulle kalliks maksma minna. Ei tohi unustada — "säästlik maksab kaks korda".
Allikas: habr.com
