Innledning
Et informasjonssystem fra brukerens synspunkt er godt definert i GOST RV 51987 - "et automatisert system, hvis resultat er presentasjon av utdatainformasjon for senere bruk." Hvis vi vurderer den interne strukturen, så er i hovedsak enhver IS et system av sammenkoblede algoritmer implementert i kode. I en bred forstand av Turing-Church-oppgaven, transformerer en algoritme (eller IS) et sett med inndata til et sett med utdata.
Man kan til og med si at transformasjonen av inputdata er meningen med eksistensen av et informasjonssystem. Følgelig bestemmes verdien av IS og hele IS-komplekset gjennom verdien av inn- og utdata.
Ut fra dette skal design starte og være datadrevet, skreddersy arkitektur og metoder til strukturen og betydningen av dataene.
Lagrede data
Et nøkkeltrinn i forberedelsene til design er å oppnå egenskapene til alle datasett som er planlagt for behandling og lagring. Disse egenskapene inkluderer:
- Datavolum;
— Informasjon om livssyklusen til data (vekst av nye data, levetid, behandling av utdaterte data);
— Klassifisering av data fra et synspunkt innvirkning på selskapets kjernevirksomhet (triaden av konfidensialitet, integritet, tilgjengelighet) sammen med økonomiske indikatorer (for eksempel kostnadene for tap av data den siste timen);
— Geografi av databehandling (fysisk plassering av prosesseringssystemer);
— Reguleringskrav for hver dataklasse (for eksempel Federal Law-152, PCI DSS).
Informasjonssystemer
Data blir ikke bare lagret, men også behandlet (transformert) av informasjonssystemer. Det neste trinnet etter å ha oppnådd datakarakteristikkene er den mest komplette oversikten over informasjonssystemer, deres arkitektoniske funksjoner, gjensidig avhengighet og infrastrukturkrav i konvensjonelle enheter for fire typer ressurser:
— Prosessorens datakraft;
— Mengde RAM;
— Krav til volumet og ytelsen til datalagringssystemet;
— Krav til dataoverføringsnettet (eksterne kanaler, kanaler mellom IS-komponenter).
I dette tilfellet må det stilles krav til hver tjeneste/mikrotjeneste som en del av IS.
Separat er det nødvendig å merke seg at for riktig design er tilgjengeligheten av data om virkningen av IS på selskapets kjernevirksomhet i form av kostnadene for IS-nedetid (rubler per time) obligatorisk.
Trusselmodell
Det må foreligge en formell modell for trusler som det er planlagt å beskytte data/tjenester fra. Dessuten inkluderer trusselmodellen ikke bare aspekter av konfidensialitet, men også integritet og tilgjengelighet. De. For eksempel:
— Feil på den fysiske serveren;
— Feil på toppen av stativet-bryteren;
— Avbrudd i den optiske kommunikasjonskanalen mellom datasentre;
— Svikt i hele det operative lagringssystemet.
I noen tilfeller skrives trusselmodeller ikke bare for infrastrukturkomponenter, men også for spesifikke informasjonssystemer eller deres komponenter, for eksempel en DBMS-feil med logisk ødeleggelse av datastrukturen.
Alle beslutninger innenfor prosjektet for å beskytte mot en ubeskrevet trussel er unødvendige.
Reguleringskrav
Dersom opplysningene som behandles er underlagt spesielle regler fastsatt av regulatorer, kreves det opplysninger om datasett og behandlings-/lagringsregler.
RPO/RTO-mål
Utforming av alle typer beskyttelse krever at du har målindikatorer for tap av data og målrettet tjenestegjenopprettingstid for hver av de beskrevne truslene.
Ideelt sett bør RPO og RTO ha tilhørende kostnader for datatap og nedetid per tidsenhet.
Inndeling i ressurspooler
Etter å ha samlet inn all innledende informasjon, er det første trinnet å gruppere datasett og IP i bassenger basert på trusselmodeller og regulatoriske krav. Type inndeling av ulike bassenger bestemmes - programmatisk på systemprogramvarenivå eller fysisk.
Eksempler:
— Kretsen som behandler personopplysninger er fullstendig fysisk atskilt fra andre systemer;
— Sikkerhetskopier lagres på et eget lagringssystem.
I dette tilfellet kan bassengene være ufullstendig uavhengige, for eksempel er to bassenger med dataressurser definert (prosessorkraft + RAM), som bruker en enkelt datalagringspool og en enkelt dataoverføringsressurspool.
Prosessorkraft
Sammendrag, prosessorkraftkravene til et virtualisert datasenter måles i form av antall virtuelle prosessorer (vCPUer) og deres konsolideringsforhold på fysiske prosessorer (pCPU). I dette spesielle tilfellet er 1 pCPU = 1 fysisk prosessorkjerne (unntatt Hyper-Threading). Antall vCPUer summeres over alle definerte ressurspooler (som hver kan ha sin egen konsolideringsfaktor).
Konsolideringskoeffisienten for belastede systemer oppnås empirisk, basert på eksisterende infrastruktur, eller gjennom pilotinstallasjon og lasttesting. For ubelastede systemer brukes "beste praksis". Spesifikt siterer VMware gjennomsnittsforholdet som 8:1.
random access memory
Det totale RAM-behovet oppnås ved enkel summering. Det anbefales ikke å bruke RAM-overabonnement.
Lagringsressurser
Lagringskrav oppnås ved ganske enkelt å summere alle bassengene etter kapasitet og ytelse.
Ytelseskrav er uttrykt i IOPS kombinert med et gjennomsnittlig lese/skriveforhold og, om nødvendig, maksimal responsforsinkelse.
Quality of Service (QoS)-krav for spesifikke bassenger eller systemer må spesifiseres separat.
Datanettverksressurser
Datanettverkskravene oppnås ved ganske enkelt å summere alle båndbreddepoolene.
Krav til tjenestekvalitet (QoS) og latens (RTT) for spesifikke bassenger eller systemer bør spesifiseres separat.
Som en del av kravene til datanettverksressurser er også krav til isolering og/eller kryptering av nettverkstrafikk og foretrukne mekanismer (802.1q, IPSec, etc.) angitt.
Utvalg av arkitektur
Denne veiledningen diskuterer ikke noe annet valg enn x86-arkitektur og 100 % servervirtualisering. Derfor kommer valget av databehandlingsundersystemarkitektur ned til valget av servervirtualiseringsplattform, serverformfaktor og generelle serverkonfigurasjonskrav.
Nøkkelpunktet for valg er sikkerheten ved å bruke en klassisk tilnærming med separasjon av funksjoner for behandling, lagring og overføring av data eller en konvergent.
Klassisk arkitektur innebærer bruk av intelligente eksterne undersystemer for lagring og overføring av data, mens servere bare bidrar med prosessorkraft og RAM til den felles poolen av fysiske ressurser. I ekstreme tilfeller blir servere helt anonyme, og har ikke bare sine egne disker, men ikke engang en systemidentifikator. I dette tilfellet lastes operativsystemet eller hypervisoren fra innebygde flash-medier eller fra et eksternt datalagringssystem (oppstart fra SAN).
Innenfor rammen av klassisk arkitektur gjøres valget mellom blader og stativer primært basert på følgende prinsipper:
— Kostnadseffektiv (i gjennomsnitt er rackmonterte servere billigere);
— Beregningstetthet (høyere for blader);
— Energiforbruk og varmespredning (blader har en høyere spesifikk enhet per enhet);
— Skalerbarhet og kontrollerbarhet (blader krever generelt mindre innsats for store installasjoner);
- Bruk av utvidelseskort (svært begrenset valg for blader).
Konvergent arkitektur (også kjent som hyperkonvergert) innebærer å kombinere funksjonene til databehandling og lagring, noe som fører til bruk av lokale serverdisker og, som en konsekvens, forlatelse av den klassiske bladformfaktoren. For konvergerte systemer brukes enten rackservere eller klyngesystemer, som kombinerer flere bladservere og lokale disker i et enkelt tilfelle.
CPU/minne
For å beregne konfigurasjonen riktig, må du forstå typen belastning for miljøet eller hver av de uavhengige klyngene.
CPU bundet – et miljø begrenset i ytelse av prosessorkraft. Å legge til RAM vil ikke endre noe når det gjelder ytelse (antall VM-er per server).
Minnet er bundet – miljø begrenset av RAM. Mer RAM på serveren lar deg kjøre flere VM-er på serveren.
GB / MHz (GB / pCPU) – det gjennomsnittlige forholdet mellom forbruk av RAM og prosessorkraft ved denne spesielle belastningen. Kan brukes til å beregne nødvendig mengde minne for en gitt ytelse og omvendt.
Beregning av serverkonfigurasjon
Først må du bestemme alle typer belastning og bestemme deg for å kombinere eller dele forskjellige databehandlingspooler i forskjellige klynger.
Deretter, for hver av de definerte klyngene, bestemmes GB / MHz-forholdet ved en belastning kjent på forhånd. Hvis belastningen ikke er kjent på forhånd, men det er en grov forståelse av nivået på prosessorkraftutnyttelsen, kan du bruke standard vCPU:pCPU-forhold for å konvertere poolkrav til fysiske.
For hver klynge, del summen av vCPU-poolkravene med koeffisienten:
vCPUsum / vCPU:pCPU = pCPUsum – nødvendig antall fysiske enheter. kjerner
pCPUsum / 1.25 = pCPUht – antall kjerner justert for Hyper-Threading
La oss anta at det er nødvendig å beregne en klynge med 190 kjerner / 3.5 TB RAM. Samtidig godtar vi en målbelastning på 50 % av prosessorkraften og 75 % av RAM.
pCPU
190
CPU-bruk
50%
Memes
3500
Mem-verktøy
75%
Socket
Kjerne
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
I dette tilfellet bruker vi alltid avrunding opp til nærmeste heltall (=ROUNDUP(A1;0)).
Fra tabellen blir det tydelig at flere serverkonfigurasjoner er balansert for målindikatorene:
— 26 servere 2*6c / 192 GB
— 19 servere 2*10c / 256 GB
— 10 servere 2*18c / 512 GB
Valget av disse konfigurasjonene må da gjøres basert på tilleggsfaktorer, slik som termisk pakke og tilgjengelig kjøling, servere som allerede er brukt, eller kostnad.
Funksjoner ved å velge en serverkonfigurasjon
Brede VM-er. Hvis det er nødvendig å være vert for brede VM-er (sammenlignbar med 1 NUMA-node eller mer), anbefales det, hvis mulig, å velge en server med en konfigurasjon som lar slike VM-er forbli innenfor NUMA-noden. Med et stort antall brede VM-er er det fare for fragmentering av klyngressursene, og i dette tilfellet velges servere som lar brede VM-er plasseres så tett som mulig.
Enkeltfeil domenestørrelse.
Valget av serverstørrelse er også basert på prinsippet om å minimere enkeltfeildomenet. For eksempel når du velger mellom:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Alt annet likt, må du velge det andre alternativet, siden når en server svikter (eller vedlikeholdes), går ikke 33 % av klyngressursene tapt, men 17 %. På samme måte halveres antallet VM-er og IS-er som er berørt av ulykken.
Beregning av klassiske lagringssystemer basert på ytelse
Klassiske lagringssystemer beregnes alltid ved å bruke det verste tilfellet, unntatt påvirkning av operasjonsbufferen og optimalisering av operasjoner.
Som grunnleggende ytelsesindikatorer tar vi mekanisk ytelse fra disken (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Deretter beregnes antall disker i diskpoolen ved å bruke følgende formel: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Hvor:
- TotalIOPS – total nødvendig ytelse i IOPS fra diskpoolen
- RW – prosentandel av leseoperasjoner
- RAID-penn – RAID-straff for det valgte RAID-nivået
Les mer om Device RAID og RAID Penalty her - и и
Basert på det resulterende antallet disker, beregnes mulige alternativer som oppfyller kravene til lagringskapasitet, inkludert alternativer med lagring på flere nivåer.
Beregningen av systemer som bruker SSD som lagringslag vurderes separat.
Funksjoner av beregningssystemer med Flash Cache
flash-cache – et felles navn for alle proprietære teknologier for bruk av flash-minne som en cache på andre nivå. Ved bruk av flash-cache beregnes lagringssystemet vanligvis til å gi en jevn belastning fra magnetiske disker, mens toppen betjenes av cachen.
I dette tilfellet er det nødvendig å forstå lastprofilen og graden av lokalisering av tilgang til blokker med lagringsvolumer. Flash-cache er en teknologi for arbeidsbelastninger med svært lokaliserte spørringer, og er praktisk talt ubrukelig for jevnt lastede volumer (som for analysesystemer).
Beregning av low-end/mid-range hybridsystemer
Hybride systemer i lavere og middelklasse bruker lagring på flere nivåer med data som beveger seg mellom nivåer etter en tidsplan. Samtidig er størrelsen på flernivålagringsblokken for de beste modellene 256 MB. Disse funksjonene tillater oss ikke å betrakte lagdelt lagringsteknologi som en teknologi for å øke produktiviteten, slik mange feilaktig tror. Lagring på flere nivåer i lav- og middelklassesystemer er en teknologi for å optimalisere lagringskostnadene for systemer med utpregede belastningsujevnheter.
For lagdelt lagring beregnes ytelsen til det øverste nivået først, mens det nederste nivået av lagring anses å bare bidra til den manglende lagringskapasiteten. For et hybrid flerlagssystem er det obligatorisk å bruke flash-cache-teknologi for flerlagspoolen for å kompensere for ytelsesnedgangen for plutselig oppvarmede data fra det lavere nivået.
Bruke en SSD i en lagdelt diskpool
Bruken av SSD-er i en diskpool på flere nivåer har variasjoner, avhengig av den spesifikke implementeringen av flash-cache-algoritmer av en gitt produsent.
Den generelle praksisen for lagringspolicy for en diskpool med et SSD-nivå er SSD først.
Skrivebeskyttet Flash Cache. For en skrivebeskyttet flash-cache, kommer lagringslaget på SSD-en med betydelig lokalisering av skriving, uavhengig av cachen.
Les/skriv Flash Cache. Når det gjelder flash-buffer, settes skrivebufferstørrelsen først til maksimal hurtigbufferstørrelse, og SSD-lagringsnivået vises bare når hurtigbufferstørrelsen er utilstrekkelig til å betjene hele den lokaliserte arbeidsbelastningen.
SSD- og cache-ytelsesberegninger gjøres hver gang basert på produsentens anbefalinger, men alltid i verste fall.
Kilde: www.habr.com