Sýndarhönnun gagnavera

Sýndarhönnun gagnavera

Inngangur

Upplýsingakerfi frá sjónarhóli notandans er vel skilgreint í GOST RV 51987 - "sjálfvirkt kerfi, niðurstaðan af því er framsetning úttaksupplýsinga til síðari notkunar." Ef við lítum á innri uppbyggingu, þá er í raun hvaða IS kerfi samtengdra reiknirita útfært í kóða. Í víðum skilningi Turing-Church ritgerðarinnar, reiknirit (eða IS) umbreytir mengi inntaksgagna í mengi úttaksgagna.
Jafnvel mætti ​​segja að umbreyting inntaksgagna sé merking tilvistar upplýsingakerfis. Í samræmi við það er gildi IS og alls IS flókið ákvarðað með gildi inn- og úttaksgagna.
Út frá þessu þarf hönnun að hefjast og vera gagnastýrð, sníða arkitektúr og aðferðir að uppbyggingu og þýðingu gagnanna.

Geymd gögn
Lykilstig í undirbúningi fyrir hönnun er að fá eiginleika allra gagnasetta sem fyrirhuguð eru til vinnslu og geymslu. Þessir eiginleikar innihalda:
- Gagnamagn;
— Upplýsingar um lífsferil gagna (vöxtur nýrra gagna, líftími, vinnsla úreltra gagna);
— Flokkun gagna með forskriftum áhrif á kjarnastarfsemi fyrirtækisins (þrenning trúnaðar, heiðarleika, aðgengis) ásamt fjárhagslegum vísbendingum (til dæmis kostnaði við tap á gögnum á síðustu klukkustund);
— Landafræði gagnavinnslu (líkamleg staðsetning vinnslukerfa);
— Reglugerðarkröfur fyrir hvern gagnaflokk (til dæmis Federal Law-152, PCI DSS).

Upplýsingakerfi

Gögn eru ekki aðeins geymd, heldur einnig unnin (umbreytt) af upplýsingakerfum. Næsta skref eftir að gagnaeiginleikarnir hafa verið fengnir er fullkomnasta skráning upplýsingakerfa, byggingareiginleika þeirra, innbyrðis háð og innviðakröfur í hefðbundnum einingum fyrir fjórar tegundir auðlinda:
— Tölvunarorka örgjörva;
- Magn vinnsluminni;
— Kröfur um rúmmál og afköst gagnageymslukerfisins;
— Kröfur fyrir gagnaflutningsnetið (ytri rásir, rásir milli IS-hluta).
Í þessu tilviki verða að vera kröfur um hverja þjónustu/örþjónustu sem hluta af IS.
Sérstaklega er nauðsynlegt að hafa í huga að fyrir rétta hönnun er aðgengi að gögnum um áhrif IS á kjarnastarfsemi fyrirtækisins í formi kostnaðar við IS niður í miðbæ (rúblur á klukkustund) skylda.

Ógnalíkan

Það verður að vera til formlegt líkan af ógnum sem fyrirhugað er að vernda gögn/þjónustu fyrir. Þar að auki inniheldur ógnunarlíkanið ekki aðeins þætti trúnaðar heldur einnig heiðarleika og aðgengi. Þeir. Til dæmis:
— Bilun á líkamlega netþjóninum;
— Bilun í rofa efst á rekki;
— Truflun á sjónsamskiptarás milli gagnavera;
— Bilun í öllu rekstrarlegu geymslukerfi.
Í sumum tilfellum eru ógnarlíkön skrifuð ekki aðeins fyrir innviðahluta, heldur einnig fyrir tiltekin upplýsingakerfi eða íhluti þeirra, svo sem bilun í DBMS með rökrænni eyðingu gagnabyggingarinnar.
Allar ákvarðanir innan verkefnisins til að verjast ólýstri ógn eru óþarfar.

Reglugerðarkröfur

Ef um gögnin sem unnið er að gilda gilda sérstakar reglur sem eftirlitsaðilar setja þarf upplýsingar um gagnasöfn og vinnslu/geymslureglur.

RPO/RTO markmið

Til að hanna hvers kyns vernd þarf að hafa gagnatapsvísa og miða endurheimtartíma þjónustu fyrir hverja ógn sem lýst er.
Helst ættu RPO og RTO að hafa tilheyrandi kostnað vegna gagnataps og niður í miðbæ á tímaeiningu.

Sýndarhönnun gagnavera

Skipting í auðlindapotta

Eftir að hafa safnað öllum fyrstu inntaksupplýsingum er fyrsta skrefið að flokka gagnasett og IP í hópa sem byggjast á ógnarlíkönum og reglugerðarkröfum. Tegund skiptingar ýmissa lauga er ákvörðuð - forritunarlega á kerfishugbúnaðarstigi eða líkamlega.
Dæmi:
— Hringrásin sem vinnur persónuupplýsingar er algjörlega líkamlega aðskilin frá öðrum kerfum;
— Afrit eru geymd á sérstöku geymslukerfi.

Í þessu tilviki geta laugarnar verið ófullkomlega sjálfstæðar, til dæmis eru skilgreindar tvær laugar af tölvuauðlindum (örgjörvaafl + vinnsluminni), sem nota eina gagnageymslusafn og eina gagnaflutningsauðlind.

Vinnsluorka

Sýndarhönnun gagnavera

Ágrip, vinnsluorkuþörf sýndargerðar gagnavera er mæld með tilliti til fjölda sýndargjörva (vCPUs) og samstæðuhlutfalls þeirra á líkamlegum örgjörvum (pCPU). Í þessu tiltekna tilviki, 1 pCPU = 1 líkamlegur örgjörva kjarna (að undanskildum Hyper-Threading). Fjöldi vCPUs er tekinn saman yfir alla skilgreinda auðlindahópa (sem hver um sig getur haft sinn samstæðustuðul).
Samþjöppunarstuðullinn fyrir hlaðin kerfi er fengin með reynslu, byggt á núverandi innviðum, eða með tilraunauppsetningu og hleðsluprófum. Fyrir óhlaðin kerfi eru „bestu venjur“ notaðar. Nánar tiltekið, VMware nefnir meðalhlutfallið sem 8:1.

Vinnsluminni

Heildarvinnsluminniþörfin er fengin með einfaldri samantekt. Ekki er mælt með því að nota RAM ofáskrift.

Geymsluauðlindir

Geymslukröfur eru fengnar með því einfaldlega að leggja saman allar laugar eftir getu og afköstum.
Frammistöðukröfur eru gefnar upp í IOPS ásamt meðaltali les/skrifhlutfalls og, ef nauðsyn krefur, hámarks svörunartíma.
Kröfur um þjónustugæði (QoS) fyrir tilteknar laugar eða kerfi verða að tilgreina sérstaklega.

Gagnanetsauðlindir

Gagnanetskröfurnar eru fengnar með því einfaldlega að leggja saman allar bandbreiddarsamstæðurnar.
Kröfur um þjónustugæði (QoS) og leynd (RTT) fyrir sérstakar laugar eða kerfi ætti að tilgreina sérstaklega.
Sem hluti af kröfum um gagnanetsauðlindir eru einnig tilgreindar kröfur um einangrun og/eða dulkóðun netumferðar og valinn aðferð (802.1q, IPSec, osfrv.).

Byggingarval

Þessi handbók fjallar ekki um annað val en x86 arkitektúr og 100% sýndarvæðingu netþjóna. Þess vegna kemur val á tölvuundirkerfisarkitektúr niður á vali á sýndarvæðingarvettvangi netþjóns, formstuðli netþjóns og almennum kröfum um uppsetningu netþjóns.

Lykilatriði valsins er sú vissa að nota klassíska nálgun með aðskilnaði aðgerða til að vinna, geyma og senda gögn eða sameina.

klassískum byggingarlist felur í sér notkun á snjöllum utanaðkomandi undirkerfum til að geyma og senda gögn, en netþjónar leggja aðeins til vinnsluorku og vinnsluminni til sameiginlegs safns líkamlegra auðlinda. Í sérstökum tilfellum verða netþjónar algjörlega nafnlausir, þeir hafa ekki aðeins sína eigin diska heldur ekki einu sinni kerfisauðkenni. Í þessu tilviki er stýrikerfið eða hypervisorinn hlaðinn frá innbyggðum flassmiðlum eða frá ytra gagnageymslukerfi (ræstu frá SAN).
Innan ramma klassísks arkitektúrs er valið á milli blaða og rekka fyrst og fremst byggt á eftirfarandi meginreglum:
— Hagkvæmt (að meðaltali eru netþjónar sem eru festir fyrir rekki ódýrari);
— Reikniþéttleiki (hærri fyrir blöð);
— Orkunotkun og hitaleiðni (blað hafa hærri sértæka einingu á hverja einingu);
— Sveigjanleiki og stýranleiki (blað þurfa almennt minni fyrirhöfn fyrir stórar uppsetningar);
- Notkun stækkunarkorta (mjög takmarkað val fyrir blöð).
Samræmd arkitektúr (líka þekkt sem ofsamleitt) felur í sér að sameina aðgerðir gagnavinnslu og geymslu, sem leiðir til notkunar staðbundinna netþjóna og þar af leiðandi er hætt við klassíska blaðformstuðulinn. Fyrir sameinuð kerfi eru annað hvort rekkiþjónar eða klasakerfi notaðir, sem sameina nokkra blaðþjóna og staðbundna diska í einu tilfelli.

Örgjörvi/minni

Til að reikna út uppsetninguna á réttan hátt þarftu að skilja tegund álags fyrir umhverfið eða hvern óháðu klasa.
CPU bundinn – umhverfi sem takmarkast af afköstum af örgjörvaafli. Að bæta við vinnsluminni mun ekki breyta neinu hvað varðar afköst (fjöldi VM á hvern netþjón).
Minni bundið - umhverfi takmarkað af vinnsluminni. Meira vinnsluminni á þjóninum gerir þér kleift að keyra fleiri VM á þjóninum.
GB / MHz (GB / pCPU) – meðalhlutfall neyslu vinnsluminni og örgjörvaafls með þessu tiltekna álagi. Hægt að nota til að reikna út nauðsynlega minnisfjölda fyrir tiltekna frammistöðu og öfugt.

Útreikningur á stillingum miðlara

Sýndarhönnun gagnavera

Í fyrsta lagi þarftu að ákvarða allar gerðir af álagi og ákveða að sameina eða skipta mismunandi tölvusamböndum í mismunandi klasa.
Næst, fyrir hvern af skilgreindum þyrpingum, er GB / MHz hlutfallið ákvarðað við álag sem vitað er fyrirfram. Ef álagið er ekki vitað fyrirfram, en það er grófur skilningur á aflnýtingu örgjörva, geturðu notað staðlað vCPU:pCPU hlutföll til að breyta kröfum um laug í líkamlegar.

Fyrir hvern klasa skaltu deila summu vCPU-geymslukrafna með stuðlinum:
vCPUsum / vCPU:pCPU = pCPUsum – nauðsynlegur fjöldi líkamlegra eininga. kjarna
pCPUsum / 1.25 = pCPUht – fjöldi kjarna stilltur fyrir Hyper-Threading
Gerum ráð fyrir að það sé nauðsynlegt að reikna út þyrping með 190 kjarna / 3.5 TB af vinnsluminni. Á sama tíma tökum við við markmiðsálagi upp á 50% af örgjörvaafli og 75% af vinnsluminni.

pCPU
190
CPU not
50%

minni
3500
Mem gagnsemi
75%

Sökkull
Core
Srv/CPU
Srv Mem
Srv/Mem

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

Í þessu tilviki notum við alltaf námundun upp í næstu heiltölu (=ROUNDUP(A1;0)).
Af töflunni verður augljóst að nokkrar netþjónastillingar eru í jafnvægi fyrir markvísana:
— 26 netþjónar 2*6c / 192 GB
— 19 netþjónar 2*10c / 256 GB
— 10 netþjónar 2*18c / 512 GB

Valið á þessum stillingum verður síðan að byggjast á viðbótarþáttum, svo sem hitapakka og tiltækri kælingu, netþjónum sem þegar eru notaðir eða kostnaði.

Eiginleikar þess að velja stillingar miðlara

Breiður VM. Ef nauðsynlegt er að hýsa breiðar VMs (sambærilegt við 1 NUMA hnút eða fleiri), er mælt með því, ef mögulegt er, að velja miðlara með uppsetningu sem gerir slíkum VM kleift að vera innan NUMA hnútsins. Með miklum fjölda breiðra VM er hætta á sundrun þyrpingaauðlinda og í þessu tilviki eru netþjónar valdir sem gera kleift að setja breiðar VMs eins þéttar og hægt er.

Stærð léns fyrir staka bilun.

Val á stærð miðlara er einnig byggt á meginreglunni um að lágmarka staka bilunarlénið. Til dæmis, þegar þú velur á milli:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Að öðru óbreyttu verður þú að velja seinni valmöguleikann, þar sem þegar einn þjónn bilar (eða er viðhaldið) tapast ekki 33% af klasaauðlindum heldur 17%. Að sama skapi fækkar þeim VM og IS sem verða fyrir áhrifum slyssins um helming.

Útreikningur á klassískum geymslukerfum byggt á frammistöðu

Sýndarhönnun gagnavera

Klassísk geymslukerfi eru alltaf reiknuð út með því að nota versta tilfelli, að frátöldum áhrifum rekstrarskyndiminnis og hagræðingar á rekstri.
Sem grunnframmistöðuvísar tökum við vélrænni frammistöðu af disknum (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

Næst er fjöldi diska í diskapottinum reiknaður út með eftirfarandi formúlu: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Hvar:
- TotalIOPS – heildar nauðsynleg afköst í IOPS frá diskapottinum
- RW – hlutfall af lestri aðgerðum
- RAID penni – RAID refsing fyrir valið RAID stig

Lestu meira um Device RAID og RAID Penalty hér - Geymsluafköst. Fyrsti hluti. и Geymsluafköst. Partur tvö. и Geymsluafköst. Þriðji hluti

Byggt á fjölda diska sem myndast, eru mögulegir valkostir reiknaðir út sem uppfylla kröfur um geymslurými, þar á meðal valkostir með fjölþrepa geymslu.
Útreikningur á kerfum sem nota SSD sem geymslulag er skoðaður sérstaklega.
Eiginleikar reiknikerfa með Flash Cache

Flash skyndiminni – sameiginlegt heiti á allri sértækni til að nota flassminni sem skyndiminni á öðru stigi. Þegar flash skyndiminni er notað er geymslukerfið venjulega reiknað út til að veita stöðugt álag frá seguldiskum, á meðan toppurinn er þjónað af skyndiminni.
Í þessu tilviki er nauðsynlegt að skilja hleðslusniðið og hversu staðbundin aðgangur að geymslumöppum er. Flash skyndiminni er tækni fyrir vinnuálag með mjög staðfærðum fyrirspurnum og er nánast óviðeigandi fyrir jafnt hlaðið magn (eins og fyrir greiningarkerfi).

Útreikningur á lág-/millisviða hybrid kerfum

Hybrid kerfi lægri og millistéttar nota fjölþrepa geymslu með gögnum sem flytjast á milli stiga samkvæmt áætlun. Á sama tíma er stærð fjölþrepa geymslublokkarinnar fyrir bestu gerðirnar 256 MB. Þessir eiginleikar leyfa okkur ekki að líta svo á að geymslutækni í flokki sé tækni til að auka framleiðni, eins og margir telja ranglega. Fjölþrepa geymsla í lág- og millistéttarkerfum er tækni til að hámarka geymslukostnað fyrir kerfi með áberandi ójafnvægi á álagi.

Fyrir þrepaskipt geymslu er afköst efsta þrepsins reiknuð fyrst, en neðsta þrep geymslu er aðeins talið stuðla að því geymslurými sem vantar. Fyrir blandað fjölþrepa kerfi er skylt að nota flass skyndiminni tækni fyrir fjölþrepa laugina til að bæta upp afköstunarskerðingu fyrir skyndilega hituð gögn frá neðra stigi.

Notkun SSD í lagskiptu diskalaug

Sýndarhönnun gagnavera

Notkun SSD diska í fjölþrepa diskalaug hefur afbrigði, allt eftir tiltekinni útfærslu á glampi skyndiminni reiknirit af tilteknum framleiðanda.
Almenn framkvæmd geymslustefnu fyrir diskalaug með SSD-stigi er SSD fyrst.
Lesaðeins Flash Cache. Fyrir skrifvarið flassskyndiminni kemur geymslulagið á SSD með verulegri staðfærslu á skrifum, óháð skyndiminni.
Lesa/skrifa Flash Cache. Ef um er að ræða flash skyndiminni er stærð skyndiminni fyrst stillt á hámarks skyndiminni og SSD geymslustigið birtist aðeins þegar skyndiminni stærðin er ófullnægjandi til að þjóna öllu staðbundnu vinnuálagi.
SSD- og skyndiminnisútreikningar eru gerðir hverju sinni út frá ráðleggingum framleiðanda, en alltaf í versta falli.

Heimild: www.habr.com

Bæta við athugasemd