Inleiding
Dit is tyd om stoorplek te koop. Watter een om te neem, na wie om te luister? Verkoper A praat van verkoper B, en dan is daar integreerder C, wat die teenoorgestelde vertel en verkoper D adviseer. In so 'n situasie sal selfs 'n ervare bergingsargitek se kop draai, veral met al die nuwe verkopers en SDS en hiperkonvergensie wat modieus is vandag.
So, hoe vind jy dit alles uit en word nie uiteindelik 'n dwaas nie? Ons ( Anton Zhbankov en Evgeniy Elizarov) kom ons probeer om hieroor in gewone Russies te praat.
Die artikel het baie ooreenkomste, en is in werklikheid 'n uitbreiding van "” in terme van die keuse van bergingstelsels en die hersiening van bergingstegnologieë. Ons sal kortliks na die algemene teorie kyk, maar ons beveel aan dat jy ook hierdie artikel lees.
hoekom
Jy kan dikwels 'n situasie sien waar 'n nuwe persoon na 'n forum of 'n gespesialiseerde klets, soos Storage Discussions, kom en die vraag vra: "hier bied hulle vir my twee bergingsopsies - ABC SuperStorage S600 en XYZ HyperOcean 666v4, wat beveel jy aan ?”
En die verwarring begin oor wie het watter kenmerke van die implementering van verskriklike en onverstaanbare kenmerke, wat vir 'n onvoorbereide persoon heeltemal Chinees is.
Dus, die sleutel en heel eerste vraag wat u uself moet afvra lank voordat u spesifikasies in kommersiële voorstelle vergelyk, is WAAROM? Hoekom is hierdie bergingstelsel nodig?
Die antwoord sal onverwags wees, en baie Tony Robbins-styl - om data te stoor. Dankie, kaptein! En tog, soms raak ons so diep in die vergelyking van besonderhede dat ons vergeet hoekom ons dit alles in die eerste plek doen.
Dus, die taak van 'n databergingstelsel is om DATA met 'n gegewe werkverrigting te stoor en toegang tot DATA te verskaf. Ons begin met data.
Data
Datatipe
Watter soort data beplan ons om te stoor? 'N Baie belangrike vraag wat baie stoorstelsels van selfs oorweging kan uitskakel. Byvoorbeeld, jy beplan om video's en foto's te stoor. U kan stelsels wat ontwerp is vir ewekansige toegang in klein blokkies, of stelsels met eie kenmerke in kompressie / deduplisering onmiddellik deurkruis. Dit kan eenvoudig uitstekende stelsels wees, ons wil niks sleg sê nie. Maar in hierdie geval sal hul sterkpunte óf swak word (video en foto's word nie saamgepers nie) óf bloot die koste van die stelsel aansienlik verhoog.
Omgekeerd, as die beoogde gebruik 'n besige transaksionele DBBS is, sal uitstekende multimedia-stroomstelsels wat in staat is om gigagrepe per sekonde te lewer, 'n swak keuse wees.
Data volume
Hoeveel data beplan ons om te stoor? Kwantiteit ontwikkel altyd in kwaliteit; dit moet nooit vergeet word nie, veral in ons tyd van eksponensiële groei in die volume data. Petagreep-klasstelsels is nie meer ongewoon nie, maar hoe groter die petagreepkapasiteit, hoe meer spesifiek die stelsel word, hoe minder toeganklik sal die gewone funksionaliteit van klein en mediumgrootte ewekansige toegangstelsels wees. Dit is triviaal omdat die bloktoegangstatistiektabelle alleen groter word as die beskikbare hoeveelheid RAM op die beheerders. Om nie eens te praat van kompressie/tiering nie. Kom ons sê ons wil die kompressie-algoritme na 'n kragtiger een oorskakel en 20 petagrepe data saampers. Hoe lank sal dit neem: ses maande, 'n jaar?
Aan die ander kant, hoekom pla as jy 500 GB data moet stoor en verwerk? Slegs 500. Huishoudelike SSD's (met lae DWPD) van hierdie grootte kos niks. Waarom 'n Fibre Channel-fabriek bou en hoë-end eksterne bergingstelsels koop wat die ekwivalent van 'n gietysterbrug kos?
Watter persentasie van die totaal is warm data? Hoe ongelyk is die vrag in terme van datavolume? Dit is waar gelaagde bergingstegnologie of Flash Cache baie nuttig kan wees as die hoeveelheid warm data klein is in vergelyking met die totaal. Of andersom, met 'n eenvormige lading deur die hele volume, wat dikwels in stromingstelsels (videobewaking, sommige ontledingstelsels) voorkom, sal sulke tegnologieë niks verskaf nie en sal net die koste/kompleksiteit van die stelsel verhoog.
IP
Die ander kant van die data is die inligtingstelsel wat die data gebruik. 'n IS het 'n stel vereistes wat data erf. Vir meer inligting oor die IS, sien "Gevirtualiseerde datasentrumontwerp."
Veerkragtigheid/beskikbaarheidvereistes
Vereistes vir fouttoleransie/databeskikbaarheid word van die IS oorgeërf wat dit gebruik en word in drie getalle uitgedruk - RPO, OTR, beskikbaarheid.
beskikbaarheid — die aandeel vir 'n gegewe tydperk waartydens data beskikbaar is om met hulle te werk. Gewoonlik uitgedruk as 'n getal van 9. Byvoorbeeld, twee nege per jaar beteken dat beskikbaarheid 99% is, of andersins word 95 uur onbeskikbaarheid per jaar toegelaat. Drie nege - 9,5 uur per jaar.
RPO / RTO is nie totale aanwysers nie, maar vir elke voorval (ongeluk), in teenstelling met beskikbaarheid.
RPO — die hoeveelheid data wat tydens 'n ongeluk verloor is (in ure). Byvoorbeeld, as rugsteun een keer per dag plaasvind, dan is RPO = 24 uur. Dié. In die geval van 'n ramp en algehele verlies van die bergingstelsel, kan data tot 24 uur verlore gaan (vanaf die oomblik van die rugsteun). Op grond van die RPO wat vir die IS gespesifiseer word, word byvoorbeeld rugsteunregulasies geskryf. Ook, gebaseer op RPO, kan jy verstaan hoeveel sinchrone / asinchrone data replikasie nodig is.
OTR - tyd om diens (datatoegang) te herstel na 'n ramp. Gebaseer op die gegewe RTO-waarde, kan ons verstaan of 'n metro-kluster nodig is, en of eenrigting replikasie voldoende is. Benodig jy 'n hoëklas multi-beheerder bergingstelsel?
Prestasievereistes
Alhoewel dit 'n baie ooglopende vraag is, is dit waar die meeste van die probleme ontstaan. Afhangende van of jy reeds 'n soort infrastruktuur het of nie, sal maniere gebou word om die nodige statistieke in te samel.
Jy het reeds 'n stoorstelsel en soek 'n plaasvervanger of wil 'n ander een koop vir uitbreiding. Alles is eenvoudig hier. Jy verstaan watter dienste jy reeds het en wat jy beplan om in die nabye toekoms te implementeer. Op grond van huidige dienste het u die geleentheid om prestasiestatistieke in te samel. Besluit op die huidige aantal IOPS en huidige latensie - wat is hierdie aanwysers en is dit genoeg vir jou take? Dit kan gedoen word op beide die databergingstelsel self en vanaf die gashere wat daaraan gekoppel is.
Boonop moet u nie net na die huidige vrag kyk nie, maar oor 'n sekere tydperk (verkieslik 'n maand). Kyk wat die maksimum pieke gedurende die dag is, watter las die rugsteun skep, ens. As jou bergingstelsel of sy sagteware jou nie van 'n volledige stel van hierdie data voorsien nie, kan jy die gratis RRDtool gebruik, wat met die meeste van die gewildste bergingstelsels en skakelaars kan werk en jou van gedetailleerde prestasiestatistieke kan voorsien. Dit is ook die moeite werd om te kyk na die las op die gashere wat met hierdie bergingstelsel werk, vir spesifieke virtuele masjiene, of wat presies op hierdie gasheer werk.
Dit is die moeite werd om afsonderlik op te let dat as die vertragings op die volume en die datastoor wat op hierdie volume geleë is redelik beduidend verskil, moet u aandag gee aan u SAN-netwerk, daar is 'n groot waarskynlikheid dat daar probleme daarmee is en voordat u 'n nuwe aankoop stelsel, is dit die moeite werd om na hierdie kwessie te kyk, want daar is 'n baie hoë waarskynlikheid om die prestasie van die huidige stelsel te verhoog.
Jy bou 'n infrastruktuur van nuuts af, of koop 'n stelsel vir een of ander nuwe diens waarvan jy nie bewus is nie. Daar is verskeie opsies: kommunikeer met kollegas oor gespesialiseerde hulpbronne om die vrag te probeer uitvind en voorspel, kontak ’n integreerder wat ondervinding het in die implementering van soortgelyke dienste en wat die las vir jou kan bereken. En die derde opsie (gewoonlik die moeilikste, veral as dit tuisgeskrewe of skaars toepassings gaan) is om die werkverrigtingvereistes van die stelselontwikkelaars te probeer uitvind.
En, let asseblief op, die mees korrekte opsie uit die oogpunt van praktiese toepassing is 'n loods op huidige toerusting, of toerusting wat verskaf word vir toetsing deur 'n verkoper/integreerder.
Spesiale vereistes
Spesiale vereistes is alles wat nie onder die vereistes vir werkverrigting, fouttoleransie en funksionaliteit vir die direkte verwerking en verskaffing van data val nie.
Een van die eenvoudigste spesiale vereistes vir 'n databergingstelsel kan "vervreembare bergingsmedia" genoem word. En dit word dadelik duidelik dat hierdie databergingstelsel 'n bandbiblioteek of bloot 'n bandstasie moet insluit waarop die rugsteunkopie gestort word. Waarna 'n spesiaal opgeleide persoon die band teken en dit met trots na 'n spesiale kluis dra.
Nog 'n voorbeeld van 'n spesiale vereiste is 'n beskermde skokbestande ontwerp.
waar
Die tweede hoofkomponent in die keuse van 'n spesifieke bergingstelsel is inligting oor WAAR hierdie bergingstelsel geleë sal wees. Begin by geografie of klimaatstoestande, en eindig met personeel.
Kliënt
Vir wie word hierdie bergingstelsel beplan? Die vraag het die volgende redes:
Staatskliënt/kommersieel.
Die kommersiële klant het geen beperkings nie en is nie eers verplig om tenders te hou nie, behalwe in ooreenstemming met sy eie interne regulasies.
'n Staatskliënt is 'n ander saak. 44 Federale Reg en ander genot met tenders en tegniese spesifikasies wat uitgedaag kan word.
Die kliënt is onder sanksies
Wel, die vraag hier is baie eenvoudig - die keuse word slegs beperk deur die aanbiedinge wat vir 'n gegewe kliënt beskikbaar is.
Interne regulasies / verskaffers / modelle toegelaat vir aankoop
Die vraag is ook uiters eenvoudig, maar jy moet dit onthou.
Waar fisies
In hierdie deel oorweeg ons alle kwessies met geografie, kommunikasiekanale en mikroklimaat in die verblyfperseel.
personeel
Wie sal met hierdie bergingstelsel werk? Dit is nie minder belangrik as wat die bergingstelsel self kan doen nie.
Maak nie saak hoe belowend, koel en wonderlik die stoorstelsel van verkoper A is nie, daar is waarskynlik min sin om dit te installeer as die personeel net weet hoe om met verkoper B te werk, en daar is geen planne vir verdere aankope en deurlopende samewerking met A nie.
En natuurlik is die ander kant van die vraag hoe beskikbaar opgeleide personeel in 'n gegewe geografiese ligging direk in die maatskappy en moontlik op die arbeidsmark is. Vir streke kan die keuse van bergingstelsels met eenvoudige koppelvlakke of die vermoë om bestuur op afstand te sentraliseer baie sin maak. Andersins kan dit op 'n sekere punt verskriklik pynlik word. Die internet is vol stories oor hoe 'n nuwe werknemer wat aangekom het, gister se student, so iets gekonfigureer het dat die hele kantoor vernietig is.
Die omgewing
En natuurlik is 'n belangrike vraag in watter omgewing hierdie bergingstelsel sal werk.
- Wat van kragtoevoer/verkoeling?
- Watter verband
- Waar sal dit geïnstalleer word?
- Ens.
Dikwels word hierdie vrae as vanselfsprekend aanvaar en nie besonder oorweeg nie, maar soms is dit diegene wat alles kan omkeer.
Wat
Verkoper
Vanaf vandag (middel 2019) kan die Russiese bergingsmark in 5 kategorieë verdeel word:
- Die hoogste afdeling is goed gevestigde maatskappye met 'n wye reeks skyfrakke van die eenvoudigste tot hoë-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Tweede afdeling - maatskappye met 'n beperkte lyn, nisspelers, ernstige SDS-verskaffers of opkomende nuwelinge (Fujitsu, Datacore, Infinidat, Huawei, Pure, ens.)
- Derde afdeling - nisoplossings in die lae eindrang, goedkoop SDS, gevorderde produkte gebaseer op ceph en ander oop projekte (Infortrend, Starwind, ens.)
- SOHO-segment - klein en ultra-klein bergingstelsels van die huis/klein kantoorvlak (Sinology, QNAP, ens.)
- Invoer-gesubstitueerde bergingstelsels - dit sluit beide hardeware van die eerste afdeling met herbenoemde etikette in, en seldsame verteenwoordigers van die tweede (RAIDIX, ons gee hulle vooraf die tweede), maar dit is hoofsaaklik die derde afdeling (Aerodisk, Baum, Depo, ens.)
Die verdeling is redelik arbitrêr, en beteken glad nie dat die derde of SOHO-segment sleg is en nie gebruik kan word nie. In spesifieke projekte met 'n duidelik gedefinieerde datastel en vragprofiel kan hulle baie goed werk, wat die eerste afdeling ver oortref in terme van prys/kwaliteit verhouding. Dit is belangrik om eers te besluit oor jou doelwitte, groeivooruitsigte en vereiste funksionaliteit – en dan sal Synology jou getrou dien, en jou hare sal sag en syerig word.
Een van die belangrike faktore by die keuse van 'n verkoper is die huidige omgewing. Hoeveel bergingstelsels jy reeds het en met watter bergingstelsels jou ingenieurs kan werk. Het u 'n ander verkoper nodig, nog 'n kontakpunt, sal u die hele vrag geleidelik van verkoper A na verkoper B migreer?
Mens moet nie entiteite voortbring bo wat nodig is nie.
iSCSI/FC/Lêer
Daar is geen konsensus onder ingenieurs oor die kwessie van toegangsprotokolle nie, en die debat lyk meer na teologiese besprekings as ingenieurs. Maar in die algemeen kan die volgende punte opgemerk word:
FCoE meer dood as lewend.
FC vs iSCSI. Een van die belangrikste voordele van FC in 2019 bo IP-berging, 'n toegewyde fabriek vir datatoegang, word geneutraliseer deur 'n toegewyde IP-netwerk. FC het geen globale voordele bo IP-netwerke nie, en IP kan gebruik word om stoorstelsels van enige lasvlak te bou, tot stelsels vir swaar DBBS vir die kernbankstelsel van 'n groot bank. Aan die ander kant word die dood van FC nou al etlike jare geprofeteer, maar iets verhoed dit voortdurend. Vandag, byvoorbeeld, is sommige spelers in die bergingsmark aktief besig om die NVMEoF-standaard te ontwikkel. Of hy die lot van FCoE sal deel - die tyd sal leer.
Lêertoegang is ook nie iets wat aandag onwaardig is nie. NFS/CIFS presteer goed in produktiwiteitsomgewings en, indien korrek ontwerp, het dit nie meer klagtes as blokprotokolle nie.
Hibried / All Flash Array
Klassieke bergingstelsels kom in 2 tipes voor:
- AFA (All Flash Array) - stelsels geoptimaliseer vir SSD-gebruik.
- Hibriede - wat jou toelaat om beide HDD en SSD of 'n kombinasie daarvan te gebruik.
Hul belangrikste verskil is die ondersteunde bergingsdoeltreffendheidtegnologieë en die maksimum vlak van werkverrigting (hoë IOPS en lae latensie). Beide stelsels (in die meeste van hul modelle, die lae-end segment nie ingereken nie) kan beide as blok- en lêertoestelle werk. Die ondersteunde funksionaliteit hang af van die vlak van die stelsel, en vir jonger modelle word dit meestal tot 'n minimum vlak verminder. Dit is die moeite werd om aandag te skenk aan wanneer jy die eienskappe van 'n spesifieke model bestudeer, en nie net die vermoëns van die hele lyn as 'n geheel nie. Ook, natuurlik, sy tegniese eienskappe, soos verwerker, hoeveelheid geheue, kas, aantal en tipes poorte, ens., hang ook af van die vlak van die stelsel. Uit 'n bestuursoogpunt verskil AFA's slegs van hibriede (skyf) stelsels in die implementering van meganismes om met SSD-aandrywers te werk, en selfs as jy 'n SSD in 'n hibriede stelsel gebruik, beteken dit glad nie dat jy in staat sal wees om om die vlak van prestasie op die vlak van 'n AFA-stelsel te bereik. In die meeste gevalle word inlyn doeltreffende bergingsmeganismes ook op hibriede stelsels gedeaktiveer, en die insluiting daarvan lei tot 'n verlies in werkverrigting.
Spesiale bergingstelsels
Benewens algemene stoorstelsels, wat hoofsaaklik op operasionele dataverwerking gefokus is, is daar spesiale bergingstelsels met sleutelbeginsels wat fundamenteel verskil van die gewone (lae latensie, hoë IOPS):
Media.
Hierdie stelsels is ontwerp vir die stoor en verwerking van groot medialêers. Resp. die vertraging raak feitlik onbelangrik, en die vermoë om data in 'n wye band in baie parallelle strome te stuur en te ontvang, kom na vore.
Deduplisering van bergingstelsels vir rugsteun.
Aangesien rugsteunkopieë onderskei word deur hul ooreenkoms met mekaar, wat skaars is onder normale toestande (die gemiddelde rugsteunkopie verskil van gister se kopie met 1-2%), verpak hierdie klas stelsels die data wat daarop aangeteken is uiters doeltreffend binne 'n redelik klein aantal fisiese media. Byvoorbeeld, in sommige gevalle kan datakompressieverhoudings 200 tot 1 bereik.
Voorwerpbergingstelsels.
Hierdie bergingstelsels het nie die gewone bloktoegangvolumes en lêeraandele nie, en die meeste van alles lyk soos 'n groot databasis. Toegang tot 'n voorwerp wat in so 'n stelsel gestoor word, word uitgevoer deur 'n unieke identifiseerder of deur metadata (byvoorbeeld alle JPEG-formaat voorwerpe met 'n skeppingsdatum tussen XX-XX-XXXX en YY-YY-YYYY).
Voldoeningstelsel.
Hulle is vandag nie so algemeen in Rusland nie, maar dit is die moeite werd om te noem. Die doel van sulke bergingstelsels is gewaarborgde databerging om aan sekuriteitsbeleide of regulatoriese vereistes te voldoen. Sommige stelsels (byvoorbeeld EMC Centera) het 'n funksie geïmplementeer om die uitvee van data te verbied - sodra die sleutel gedraai word en die stelsel hierdie modus betree, kan nie die administrateur of enigiemand anders data fisies uitvee wat reeds aangeteken is nie.
Eie tegnologieë
Flash-kas
Flash Cache is 'n algemene naam vir alle eiendomstegnologieë vir die gebruik van flitsgeheue as 'n tweedevlakkas. Wanneer 'n flitskas gebruik word, word die bergingstelsel gewoonlik bereken om 'n bestendige lading vanaf magnetiese skywe te verskaf, terwyl die piek deur die kas bedien word.
In hierdie geval is dit nodig om die vragprofiel en die mate van lokalisering van toegang tot blokke stoorvolumes te verstaan. Flitskas is 'n tegnologie vir werkladings met hoogs gelokaliseerde navrae, en is feitlik ontoepasbaar vir eenvormig gelaaide volumes (soos vir ontledingstelsels).
Daar is twee flitskas-implementerings op die mark beskikbaar:
- Slegs lees. In hierdie geval word slegs leesdata gekas, en skryfwerk gaan direk na die skywe. Sommige vervaardigers, soos NetApp, glo dat skryf na hul stoorstelsels reeds optimaal is, en die kas sal glad nie help nie.
- Lees skryf. Nie net lees nie, maar ook skryf word gekas, wat jou toelaat om die stroom te buffer en die impak van RAID Penalty te verminder, en as gevolg daarvan die algehele werkverrigting vir bergingstelsels met 'n minder optimale skryfmeganisme te verhoog.
Tiering
Multi-vlak berging (vermoeiend) is 'n tegnologie vir die kombinasie van vlakke met verskillende werkverrigting vlakke, soos SSD en HDD, in 'n enkele skyf poel. In die geval van uitgesproke ongelykheid van toegang tot datablokke, sal die stelsel datablokke outomaties kan balanseer, gelaaide blokke na 'n hoëprestasievlak skuif, en koues, inteendeel, na 'n stadiger een.
Hibriede stelsels van die laer en middelklas gebruik multi-vlak berging met data wat tussen vlakke beweeg op 'n skedule. Terselfdertyd is die grootte van die meervlakkige stoorblok vir die beste modelle 256 MB. Hierdie kenmerke laat ons nie toe om vlakbergingstegnologie as 'n tegnologie te beskou om produktiwiteit te verhoog nie, soos baie mense verkeerdelik glo. Meervlakkige berging in lae- en middelklasstelsels is 'n tegnologie vir die optimalisering van bergingskoste vir stelsels met uitgesproke ladingsongelykheid.
Kiekie
Maak nie saak hoeveel ons oor die betroubaarheid van bergingstelsels praat nie, daar is baie geleenthede om data te verloor wat nie van hardewareprobleme afhang nie. Dit kan virusse, kuberkrakers of enige ander onbedoelde uitvee/korrupsie van data wees. Om hierdie rede is die rugsteun van produksiedata 'n integrale deel van 'n ingenieur se werk.
'n Momentopname is 'n momentopname van 'n volume op 'n sekere tydstip. Wanneer jy met die meeste stelsels werk, soos virtualisering, databasisse, ens. ons moet so 'n momentopname neem waaruit ons die data na 'n rugsteunkopie sal kopieer, terwyl ons IS veilig sal kan voortgaan om met hierdie volume te werk. Maar dit is die moeite werd om te onthou dat nie alle foto's ewe nuttig is nie. Verskillende verskaffers het verskillende benaderings om foto's te skep wat verband hou met hul argitektuur.
CoW (Kopieer-op-skryf). Wanneer jy probeer om 'n datablok te skryf, word die oorspronklike inhoud daarvan na 'n spesiale area gekopieer, waarna die skryf normaalweg voortgaan. Dit voorkom datakorrupsie binne die momentopname. Natuurlik veroorsaak al hierdie "parasitiese" datamanipulasies bykomende las op die bergingstelsel en om hierdie rede beveel verskaffers met soortgelyke implementerings nie aan om meer as 'n dosyn momentopnames te gebruik nie, en glad nie op hoogs gelaaide volumes te gebruik nie.
RoW (aanstuur-op-skryf). In hierdie geval vries die oorspronklike volume natuurlik, en wanneer u probeer om 'n datablok te skryf, skryf die stoorstelsel data na 'n spesiale area in vrye spasie, wat die ligging van hierdie blok in die metadatatabel verander. Dit laat jou toe om die aantal herskryfbewerkings te verminder, wat uiteindelik die daling in werkverrigting uitskakel en beperkings op kiekies en hul aantal verwyder.
Foto's is ook van twee tipes met betrekking tot toepassings:
Toepassing konsekwentheid. Op die oomblik van die skep van 'n momentopname trek die bergingstelsel 'n agent in die verbruiker se bedryfstelsel, wat skyfkasgeheue met geweld van geheue na skyf uitspoel en die toepassing dwing om dit te doen. In hierdie geval, wanneer u vanaf 'n momentopname herstel, sal die data konsekwent wees.
Ineenstorting konsekwent. In hierdie geval gebeur niks so nie en word die momentopname geskep soos dit is. In die geval van herstel vanaf so 'n momentopname, is die prentjie identies aan wat sou gebeur as die krag skielik afgeskakel word en 'n mate van verlies van data moontlik is, vas in kas en nooit die skyf bereik nie. Sulke foto's is makliker om te implementeer en veroorsaak nie prestasie-agteruitgang in toepassings nie, maar is minder betroubaar.
Waarom is foto's op bergingstelsels nodig?
- Agentlose rugsteun direk vanaf die bergingstelsel
- Skep toetsomgewings gebaseer op werklike data
- In die geval van lêerbergingstelsels, kan dit gebruik word om VDI-omgewings te skep deur die gebruik van stoorstelsel-snapshots in plaas van 'n hypervisor
- Verseker lae RPO's deur geskeduleerde foto's te skep teen 'n frekwensie wat aansienlik hoër is as die rugsteunfrekwensie
Kloning
Volumekloning - werk op 'n soortgelyke beginsel as foto's, maar word nie net gebruik om data te lees nie, maar om ten volle daarmee te werk. Ons kan 'n presiese kopie van ons volume kry, met al die data daarop, sonder om 'n fisiese kopie te maak, wat spasie sal bespaar. Tipies word volumekloning óf in Test&Dev gebruik óf as jy die funksionaliteit van sommige opdaterings op jou IS wil nagaan. Kloning sal jou toelaat om dit so vinnig en ekonomies moontlik te doen in terme van skyfhulpbronne, want Slegs veranderde datablokke sal geskryf word.
Replikasie / Joernaalskrywing
Replikasie is 'n meganisme om 'n kopie van data op 'n ander fisiese bergingstelsel te skep. Tipies het elke verkoper 'n eie tegnologie wat slegs binne sy eie lyn werk. Maar daar is ook derdeparty-oplossings, insluitend dié wat op die hipervisor-vlak werk, soos VMware vSphere Replication.
Die funksionaliteit van eie tegnologieë en die gebruiksgemak daarvan is gewoonlik baie beter as universele, maar dit blyk ontoepasbaar te wees wanneer dit byvoorbeeld nodig is om 'n replika van NetApp na HP MSA te maak.
Replikasie word in twee subtipes verdeel:
Sinchronies. In die geval van sinchrone replikasie, word die skryfbewerking onmiddellik na die tweede stoorstelsel gestuur en die uitvoering word nie bevestig totdat die afgeleë stoorstelsel dit bevestig nie. As gevolg hiervan neem die toegangsvertraging toe, maar ons het 'n presiese spieëlkopie van die data. Dié. RPO = 0 in geval van verlies van die hoofbergingstelsel.
asynchronies. Skryfbewerkings word slegs op die hoofbergingstelsel uitgevoer en word onmiddellik bevestig, terwyl dit terselfdertyd in 'n buffer ophoop vir bondeloordrag na die afgeleë bergingstelsel. Hierdie tipe replikasie is relevant vir minder waardevolle data, of vir kanale met lae bandwydte of hoë latensie (tipies vir afstande oor 100 km). Gevolglik is RPO = pakketversendingfrekwensie.
Dikwels, saam met replikasie, is daar 'n meganisme aanteken skyf bedrywighede. In hierdie geval word 'n spesiale area toegeken vir logging en opname van bedrywighede van 'n sekere diepte in tyd, of beperk deur die volume van die log, word gestoor. Vir sekere eiendomstegnologieë, soos EMC RecoverPoint, is daar integrasie met stelselsagteware wat jou toelaat om sekere boekmerke aan 'n spesifieke loginskrywing te koppel. Danksy dit is dit moontlik om die toestand van 'n volume terug te rol (of 'n kloon te skep) nie net na 23 April, 11 uur 59 sekondes 13 millisekondes nie, maar na die oomblik voor "DROP ALL TABLES; VERPLEEG.”
Metro-kluster
Metro cluster is 'n tegnologie wat jou toelaat om tweerigting sinchroniese replikasie tussen twee stoorstelsels te skep op so 'n manier dat hierdie paar van buite soos een stoorstelsel lyk. Dit word gebruik om groepe te skep met geografies geskeide arms op metro-afstande (minder as 100 km).
Gebaseer op die voorbeeld van gebruik in 'n virtualisasie-omgewing, laat die metrocluster jou toe om 'n datastoor met virtuele masjiene te skep, toeganklik vir opname vanaf twee datasentrums tegelyk. In hierdie geval word 'n groepering op die hiperviseerdervlak geskep, bestaande uit gashere in verskillende fisiese datasentrums, gekoppel aan hierdie datastoor. Wat jou toelaat om die volgende te doen:
- Volle outomatisering van die herstelproses na die dood van een van die datasentrums. Sonder enige bykomende fondse sal alle VM's wat in die afgestorwe datasentrum loop, outomaties in die oorblywende een herbegin word. RTO = hoë beskikbaarheid cluster timeout (15 sekondes vir VMware) + tyd om die bedryfstelsel te laai en dienste te begin.
- Rampvermyding of, in Russies, vermyding van rampe. As kragtoevoerwerk in datasentrum 1 beplan word, dan het ons die geleentheid om die hele belangrike vrag vooraf onophoudelik na datasentrum 2 te migreer, voordat die werk begin.
Virtualisering
Bergingvirtualisering is tegnies die gebruik van volumes van 'n ander bergingstelsel as skywe. ’n Bergingvirtualiseerder kan eenvoudig iemand anders se volume aan die verbruiker as sy eie oordra, dit terselfdertyd na ’n ander bergingstelsel weerspieël, of selfs ’n RAID van eksterne volumes skep.
Klassieke verteenwoordigers in die bergingvirtualiseringsklas is EMC VPLEX en IBM SVC. En natuurlik, bergingstelsels met virtualisasie-funksionaliteit - NetApp, Hitachi, IBM / Lenovo Storwize.
Hoekom is dit dalk nodig?
- Oortolligheid op bergingstelselvlak. 'n Spieël word tussen die volumes geskep, en die een helfte kan op HP 3Par wees, en die ander op NetApp. En die virtualiseerder is van EMC.
- Beweeg data met minimale stilstand tussen bergingstelsels van verskillende vervaardigers. Kom ons neem aan dat data van die ou 3Par, wat afgeskryf sal word, na die nuwe Dell gemigreer moet word. In hierdie geval word verbruikers van 3Par ontkoppel, die volumes word onder VPLEX oorgedra en word weer aan verbruikers aangebied. Aangesien daar nie 'n bietjie aan die volume verander het nie, gaan werk voort. Die proses om die volume na die nuwe Dell te weerspieël, begin in die agtergrond, en na voltooiing is die spieël gebreek en 3Par is gedeaktiveer.
- Organisasie van metroclusters.
Kompressie/deduplisering
Kompressie en deduplisering is tegnologieë wat jou toelaat om skyfspasie op jou stoorstelsel te bespaar. Dit is die moeite werd om dadelik te noem dat nie alle data in beginsel aan kompressie en/of deduplisering onderhewig is nie, terwyl sommige tipes data beter saamgepers en gededupliseer word, en sommige - omgekeerd.
Daar is 2 tipes kompressie en deduplisering:
In lyn - kompressie en deduplisering van datablokke vind plaas voordat hierdie data na skyf geskryf word. Dus, die stelsel bereken slegs die hash van die blok en vergelyk dit in die tabel met die bestaandes. Eerstens is dit vinniger as om net na skyf te skryf, en tweedens mors ons nie ekstra skyfspasie nie.
Post - wanneer hierdie bewerkings uitgevoer word op reeds aangetekende data wat op skywe geleë is. Gevolglik word die data eers na skyf geskryf, en eers dan word die hash bereken en onnodige blokke word uitgevee en skyfbronne word vrygestel.
Dit is die moeite werd om te sê dat die meeste verskaffers beide tipes gebruik, wat hulle in staat stel om hierdie prosesse te optimaliseer en sodoende hul doeltreffendheid te verhoog. Die meeste bergingsverskaffers het nutsprogramme wat jou toelaat om jou datastelle te ontleed. Hierdie nutsprogramme werk volgens dieselfde logika wat in die bergingstelsel geïmplementeer word, dus sal die geraamde vlak van doeltreffendheid dieselfde wees. Hou ook in gedagte dat baie verskaffers prestasiewaarborgprogramme het wat ten minste net so goeie werkverrigting vir sekere (of alle) datatipes beloof. En u moet hierdie program nie verwaarloos nie, want deur die stelsel vir u take te bereken, met inagneming van die doeltreffendheidskoëffisiënt van 'n spesifieke stelsel, kan u volume bespaar. Dit is ook die moeite werd om te oorweeg dat hierdie programme ontwerp is vir AFA-stelsels, maar danksy die aankoop van 'n kleiner volume SSD's as HDD's in klassieke stelsels, sal dit hul koste verminder, en indien nie gelyk aan die koste van 'n skyfstelsel nie, dan kom redelik naby daaraan.
Model
En hier kom ons by die regte vraag.
"Hulle bied my twee bergingsopsies - ABC SuperStorage S600 en XYZ HyperOcean 666v4, wat beveel jy aan?"
Verander in "Hier bied hulle my twee bergingsopsies - ABC SuperStorage S600 en XYZ HyperOcean 666v4, wat beveel jy aan?
Die teikenlading is gemengde VMware virtuele masjiene met produksie-/toets-/ontwikkelingslusse. Toets = produktief. 150 TB elk met 'n topprestasie van 80 000 IOPS 8kb blok 50% ewekansige toegang 80/20 lees-skryf. 300 TB vir ontwikkeling, 50 000 IOPS is genoeg, 80 ewekansig, 80 skryf.
Produktiwiteit vermoedelik in die metrocluster RPO = 15 minute RTO = 1 uur, ontwikkeling in asynchrone replikasie RPO = 3 uur, toets op een perseel.
Daar sal 'n 50TB DBMS wees, aanteken sal vir hulle lekker wees.
Ons het oral Dell-bedieners, ou Hitachi-bergingstelsels, hulle kan skaars klaarkom, ons beplan om die las met 50% te verhoog in terme van volume en werkverrigting.”
Soos hulle sê, 'n korrek geformuleerde vraag bevat 80% van die antwoord.
bykomende inligting
Wat jy addisioneel moet lees volgens die skrywers
boeke
- Olifer en Olifer "Rekenaarnetwerke". Die boek sal help om te sistematiseer en miskien beter te verstaan hoe die data-oordragmedium vir IP / Ethernet-bergingstelsels werk
- "EMC-inligtingberging en -bestuur." 'n Uitstekende boek oor die basiese beginsels van bergingstelsels, die hoekoms, hoes en waaroms.
Forums en geselsies
Algemene aanbevelings
pryse
Nou, soos vir pryse - in die algemeen, as daar pryse vir stoorstelsels is, is dit gewoonlik Lyspryse, waaruit elke kliënt 'n individuele afslag ontvang. Die grootte van die afslag bestaan uit 'n groot aantal parameters, so dit is eenvoudig onmoontlik om te voorspel watter finale prys jou maatskappy sal ontvang sonder om die verspreider te vra. Maar terselfdertyd het onlangs lae-end-modelle in gewone rekenaarwinkels begin verskyn, soos bv. of . Hier kan jy dadelik die stelsel waarin jy belangstel teen 'n vaste prys koop, soos enige rekenaarkomponente.
Maar ek wil dadelik daarop let dat 'n direkte vergelyking deur TB/$ nie korrek is nie. As ons dit vanuit hierdie oogpunt benader, sal die goedkoopste oplossing 'n eenvoudige JBOD + bediener wees, wat nie die buigsaamheid of betroubaarheid sal bied wat 'n volwaardige, dubbelbeheerder bergingstelsel bied nie. Dit beteken glad nie dat JBOD walglik en 'n nare vuil truuk is nie, jy moet net weer baie duidelik verstaan hoe en vir watter doeleindes jy hierdie oplossing gaan gebruik. Jy kan dikwels hoor dat daar niks is om te breek in JBOD nie, daar is net een backplane. Agtervliegtuie faal egter ook soms. Alles breek vroeër of later.
In totaal
Dit is nodig om stelsels met mekaar te vergelyk, nie net volgens prys nie, of nie net volgens prestasie nie, maar deur die totaliteit van alle aanwysers.
Koop slegs HDD as jy seker is dat jy HDD nodig het. Vir lae vragte en onsamedrukbare datatipes, anders is dit die moeite werd om na SSD-bergingsdoeltreffendheidwaarborgprogramme te wend, wat die meeste verskaffers nou het (en hulle werk regtig, selfs in Rusland), maar dit hang alles af van die toepassings en data wat geleë sal wees. op hierdie stoorstelsel.
Moenie vir goedkoop gaan nie. Soms verberg dit baie onaangename oomblikke, waarvan Evgeniy Elizarov een beskryf het in sy artikels oor . En dat hierdie goedkoopheid uiteindelik op jou kan terugslaan. Moenie vergeet nie - "die vrek betaal twee keer."
Bron: www.habr.com