Inleiding
'N Inligtingstelsel vanuit die gebruiker se oogpunt word goed gedefinieer in GOST RV 51987 - "'n outomatiese stelsel, waarvan die resultaat die aanbieding van uitsetinligting vir latere gebruik is." As ons die interne struktuur oorweeg, dan is enige IS in wese 'n stelsel van onderling gekoppelde algoritmes wat in kode geïmplementeer is. In 'n breë sin van die Turing-Church-proefskrif transformeer 'n algoritme (of IS) 'n stel insetdata in 'n stel uitsetdata.
Mens kan selfs sê dat die transformasie van insetdata die betekenis van die bestaan van 'n inligtingstelsel is. Gevolglik word die waarde van die IS en die hele IS-kompleks bepaal deur die waarde van inset- en uitsetdata.
Op grond hiervan moet ontwerp begin en data-gedrewe wees, wat argitektuur en metodes aanpas by die struktuur en betekenis van die data.
Gestoorde data
'n Sleutelstadium in voorbereiding vir ontwerp is die verkryging van die eienskappe van alle datastelle wat vir verwerking en berging beplan word. Hierdie kenmerke sluit in:
- Data volume;
— Inligting oor die lewensiklus van data (groei van nuwe data, lewensduur, verwerking van verouderde data);
— Klassifikasie van data vanuit die oogpunt impak op die maatskappy se kernbesigheid (die drietal van vertroulikheid, integriteit, beskikbaarheid) saam met finansiële aanwysers (byvoorbeeld die koste van dataverlies in die laaste uur);
— Geografie van dataverwerking (fisiese ligging van verwerkingstelsels);
— Regulerende vereistes vir elke dataklas (byvoorbeeld, Federal Law-152, PCI DSS).
Inligtingstelsels
Data word nie net gestoor nie, maar ook deur inligtingstelsels verwerk (getransformeer). Die volgende stap na die verkryging van die data-eienskappe is die mees volledige inventaris van inligtingstelsels, hul argitektoniese kenmerke, interafhanklikhede en infrastruktuurvereistes in konvensionele eenhede vir vier tipes hulpbronne:
— Verwerker rekenaarkrag;
- Hoeveelheid RAM;
— Vereistes vir die volume en werkverrigting van die databergingstelsel;
— Vereistes vir die data-oordragnetwerk (eksterne kanale, kanale tussen IS-komponente).
In hierdie geval moet daar vereistes wees vir elke diens/mikrodiens as deel van die IS.
Afsonderlik is dit nodig om daarop te let dat, vir korrekte ontwerp, die beskikbaarheid van data oor die impak van die IS op die maatskappy se kernbesigheid in die vorm van die koste van IS-stilstand (roebels per uur) verpligtend is.
Bedreigingsmodel
Daar moet 'n formele model van bedreigings wees waarteen dit beplan word om data/dienste te beskerm. Boonop sluit die bedreigingsmodel nie net aspekte van vertroulikheid in nie, maar ook integriteit en beskikbaarheid. Dié. Byvoorbeeld:
— Mislukking van die fisiese bediener;
— Mislukking van die bo-op-die-rak-skakelaar;
— Ontwrigting van die optiese kommunikasiekanaal tussen datasentrums;
— Mislukking van die hele operasionele bergingstelsel.
In sommige gevalle word bedreigingsmodelle nie net vir infrastruktuurkomponente geskryf nie, maar ook vir spesifieke inligtingstelsels of hul komponente, soos 'n DBMS-fout met logiese vernietiging van die datastruktuur.
Alle besluite binne die projek om teen 'n onbeskryfde bedreiging te beskerm is onnodig.
Regulatoriese vereistes
As die data wat verwerk word onderhewig is aan spesiale reëls wat deur reguleerders vasgestel is, word inligting oor datastelle en verwerkings-/bergingsreëls vereis.
RPO/RTO teikens
Om enige tipe beskerming te ontwerp, vereis teikendataverliesaanwysers en teikendienshersteltyd vir elk van die beskryfde bedreigings.
Ideaal gesproke behoort RPO en RTO gepaardgaande koste van dataverlies en stilstand per tydseenheid te hê.
Verdeling in hulpbronpoele
Nadat al die aanvanklike insette inligting ingesamel is, is die eerste stap om datastelle en IP in poele te groepeer gebaseer op bedreigingsmodelle en regulatoriese vereistes. Die tipe verdeling van verskeie poele word bepaal - programmaties op die stelselsagtewarevlak of fisies.
Voorbeelde:
— Die kring wat persoonlike data verwerk, is heeltemal fisies geskei van ander stelsels;
- Rugsteune word op 'n aparte bergingstelsel gestoor.
In hierdie geval kan die poele onvolledig onafhanklik wees, byvoorbeeld, twee poele van rekenaarhulpbronne word gedefinieer (verwerkerkrag + RAM), wat 'n enkele databergingpoel en 'n enkele data-oordraghulpbronpoel gebruik.
Verwerkingskrag
Opsomming, die verwerkingskragvereistes van 'n gevirtualiseerde datasentrum word gemeet in terme van die aantal virtuele verwerkers (vCPU's) en hul konsolidasieverhouding op fisiese verwerkers (pCPU). In hierdie spesifieke geval is 1 pCPU = 1 fisiese verwerkerkern (uitgesluit Hyper-Threading). Die aantal vCPU's word opgetel oor alle gedefinieerde hulpbronpoele (wat elkeen sy eie konsolidasiefaktor kan hê).
Die konsolidasiekoëffisiënt vir gelaaide stelsels word empiries verkry, gebaseer op bestaande infrastruktuur, of deur loodsinstallasie en vragtoetsing. Vir afgelaaide stelsels word "beste praktyk" gebruik. Spesifiek, VMware noem die gemiddelde verhouding as 8:1.
Operatiewe geheue
Die totale RAM-vereiste word verkry deur eenvoudige opsomming. Die gebruik van RAM-oorintekening word nie aanbeveel nie.
Berging hulpbronne
Bergingsvereistes word verkry deur bloot alle swembaddens volgens kapasiteit en werkverrigting op te som.
Prestasievereistes word uitgedruk in IOPS gekombineer met 'n gemiddelde lees/skryf-verhouding en, indien nodig, 'n maksimum reaksie latency.
Gehalte van diens (QoS) vereistes vir spesifieke poele of stelsels moet afsonderlik gespesifiseer word.
Datanetwerkhulpbronne
Die datanetwerkvereistes word verkry deur eenvoudig al die bandwydtepoele op te som.
Gehalte van diens (QoS) en latency (RTT) vereistes vir spesifieke poele of stelsels moet afsonderlik gespesifiseer word.
As deel van die vereistes vir datanetwerkhulpbronne, word vereistes vir isolasie en/of enkripsie van netwerkverkeer en voorkeurmeganismes (802.1q, IPSec, ens.) ook aangedui.
Argitektuur seleksie
Hierdie gids dek nie ander keuses as x86-argitektuur en 100% bedienervirtualisering nie. Daarom kom die keuse van rekenaarsubstelselargitektuur neer op die keuse van bedienervirtualiseringsplatform, bedienervormfaktor en algemene bedienerkonfigurasievereistes.
Die sleutelpunt van keuse is die sekerheid van die gebruik van 'n klassieke benadering met skeiding van funksies van verwerking, berging en oordrag van data of 'n konvergente een.
klassieke argitektuur behels die gebruik van intelligente eksterne substelsels vir die stoor en oordrag van data, terwyl bedieners slegs verwerkingskrag en RAM bydra tot die gemeenskaplike poel van fisiese hulpbronne. In uiterste gevalle word bedieners heeltemal anoniem, met nie net hul eie skywe nie, maar nie eers 'n stelselidentifiseerder nie. In hierdie geval word die bedryfstelsel of hipervisor gelaai vanaf ingeboude flitsmedia of vanaf 'n eksterne databergingstelsel (selflaai vanaf SAN).
Binne die raamwerk van klassieke argitektuur word die keuse tussen lemme en rakke hoofsaaklik gebaseer op die volgende beginsels:
— Kostedoeltreffend (gemiddeld is rekgemonteerde bedieners goedkoper);
— Rekenaardigtheid (hoër vir lemme);
— Energieverbruik en hitte-afvoer (lemme het 'n hoër spesifieke eenheid per eenheid);
— Skaalbaarheid en beheerbaarheid (lemme vereis gewoonlik minder moeite vir groot installasies);
- Gebruik van uitbreidingskaarte (baie beperkte keuse vir lemme).
Konvergente argitektuur (ook bekend as hiperkonvergeer) behels die kombinasie van die funksies van dataverwerking en berging, wat lei tot die gebruik van plaaslike bedienerskywe en, as gevolg daarvan, die verlating van die klassieke lemvormfaktor. Vir gekonvergeerde stelsels word óf rekbedieners óf groepstelsels gebruik, wat verskeie lembedieners en plaaslike skywe in 'n enkele geval kombineer.
SVE/geheue
Om die konfigurasie korrek te bereken, moet jy die tipe las vir die omgewing of elk van die onafhanklike trosse verstaan.
SVE gebonde – 'n omgewing wat beperk is in werkverrigting deur verwerkerkrag. Die byvoeging van RAM sal niks verander in terme van werkverrigting (aantal VM'e per bediener).
Geheue gebonde - omgewing beperk deur RAM. Meer RAM op die bediener laat jou toe om meer VM's op die bediener te laat loop.
GB / MHz (GB / pCPU) - die gemiddelde verhouding van verbruik van RAM en verwerkerkrag deur hierdie spesifieke las. Kan gebruik word om die vereiste hoeveelheid geheue vir 'n gegewe prestasie te bereken en omgekeerd.
Bedienerkonfigurasieberekening
Eerstens moet jy alle tipes las bepaal en besluit om verskillende rekenaarpoele in verskillende groepe te kombineer of te verdeel.
Vervolgens, vir elk van die gedefinieerde trosse, word die GB / MHz-verhouding bepaal teen 'n las wat vooraf bekend is. As die las nie vooraf bekend is nie, maar daar is 'n rowwe begrip van die vlak van verwerkerkragbenutting, kan jy standaard vCPU:pCPU-verhoudings gebruik om swembadvereistes in fisiese om te skakel.
Vir elke groep, deel die som van vCPU-poelvereistes deur die koëffisiënt:
vCPUsum / vCPU:pCPU = pCPUsum – vereiste aantal fisiese eenhede. kerne
pCPUsum / 1.25 = pCPUht – aantal kerns aangepas vir Hyper-Threading
Kom ons neem aan dat dit nodig is om 'n groep met 190 kerns / 3.5 TB RAM te bereken. Terselfdertyd aanvaar ons 'n teikenlading van 50% van verwerkerkrag en 75% van RAM.
pCPU
190
CPU gebruik
50%
Mem
3500
Mem nut
75%
Socket
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
In hierdie geval gebruik ons altyd afronding op na die naaste heelgetal (=ROUNDUP(A1;0)).
Uit die tabel word dit duidelik dat verskeie bedienerkonfigurasies gebalanseer is vir die teikenaanwysers:
— 26 bedieners 2*6c / 192 GB
— 19 bedieners 2*10c / 256 GB
— 10 bedieners 2*18c / 512 GB
Die keuse van hierdie konfigurasies moet dan gemaak word op grond van bykomende faktore, soos termiese pakket en beskikbare verkoeling, bedieners wat reeds gebruik is, of koste.
Kenmerke van die keuse van 'n bedienerkonfigurasie
Wye VM'e. As dit nodig is om wye VM'e te huisves (vergelykbaar met 1 NUMA-nodus of meer), word dit aanbeveel, indien moontlik, om 'n bediener te kies met 'n opset wat toelaat dat sulke VM'e binne die NUMA-nodus bly. Met 'n groot aantal wye VM'e is daar 'n gevaar van fragmentasie van groephulpbronne, en in hierdie geval word bedieners gekies wat toelaat dat wye VM'e so dig as moontlik geplaas word.
Enkele mislukking domein grootte.
Die keuse van bedienergrootte is ook gebaseer op die beginsel om die enkele mislukkingsdomein te minimaliseer. Byvoorbeeld, wanneer jy kies tussen:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Alle ander dinge gelyk, moet jy die tweede opsie kies, aangesien wanneer een bediener misluk (of in stand gehou word), gaan nie 33% van die groephulpbronne verlore nie, maar 17%. Op dieselfde manier word die aantal VM'e en IS'e wat deur die ongeluk geraak word, gehalveer.
Berekening van klassieke bergingstelsels gebaseer op werkverrigting
Klassieke bergingstelsels word altyd bereken deur die ergste scenario te gebruik, uitgesluit die invloed van die operasionele kas en optimalisering van bedrywighede.
As basiese prestasie-aanwysers neem ons meganiese werkverrigting vanaf die skyf (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Vervolgens word die aantal skywe in die skyfpoel bereken deur die volgende formule te gebruik: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Waar:
- TotalIOPS – totale vereiste werkverrigting in IOPS vanaf die skyfpoel
- RW – persentasie leesbewerkings
- RAID pen – RAID-boete vir die geselekteerde RAID-vlak
Lees meer oor Device RAID en RAID Penalty hier - и и
Gebaseer op die gevolglike aantal skywe, word moontlike opsies bereken wat aan die bergingskapasiteitvereistes voldoen, insluitend opsies met multivlakberging.
Die berekening van stelsels wat SSD as die bergingslaag gebruik, word afsonderlik oorweeg.
Kenmerke van berekeningstelsels met Flash Cache
flits kas – '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).
Berekening van lae-end/middelafstand hibriede stelsels
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.
Vir gelaagde berging word die werkverrigting van die boonste vlak eerste bereken, terwyl die onderste bergingvlak beskou word om slegs by te dra tot die ontbrekende bergingskapasiteit. Vir 'n hibriede meervlakkige stelsel is dit verpligtend om flitskastegnologie vir die meervlakpoel te gebruik om te kompenseer vir die prestasievermindering vir skielik verhitte data vanaf die laer vlak.
Gebruik 'n SSD in 'n gelaagde skyfpoel
Die gebruik van SSD's in 'n multi-vlak skyfpoel het variasies, afhangende van die spesifieke implementering van flitskasalgoritmes deur 'n gegewe vervaardiger.
Die algemene praktyk van bergingsbeleid vir 'n skyfpoel met 'n SSD-vlak is SSD eerste.
Lees Slegs Flash Cache. Vir 'n leesalleen flitskas, kom die bergingslaag op die SSD met 'n aansienlike lokalisering van skryfwerk, ongeag die kas.
Lees / Skryf Flash Cache. In die geval van flitskas, word die skryfkasgrootte eers op die maksimum kasgrootte gestel, en die SSD-bergingvlak verskyn slegs wanneer die kasgrootte onvoldoende is om die hele gelokaliseerde werklading te bedien.
SSD- en kasprestasieberekeninge word elke keer gemaak op grond van die vervaardiger se aanbevelings, maar altyd vir die ergste scenario.
Bron: will.com