Indledning
Et informationssystem fra brugerens synspunkt er veldefineret i GOST RV 51987 - "et automatiseret system, hvis resultat er præsentationen af outputinformation til efterfølgende brug." Hvis vi betragter den interne struktur, så er enhver IS i det væsentlige et system af indbyrdes forbundne algoritmer implementeret i kode. I en bred forstand af Turing-Church-afhandlingen omdanner en algoritme (eller IS) et sæt inputdata til et sæt outputdata.
Man kan endda sige, at transformationen af inputdata er meningen med eksistensen af et informationssystem. Følgelig bestemmes værdien af IS og hele IS-komplekset gennem værdien af input- og outputdata.
Med dette in mente skal design starte og være datadrevet, skræddersy arkitektur og metoder til dataenes struktur og betydning.
Gemte data
Et nøgletrin i forberedelsen til design er at opnå egenskaberne for alle datasæt, der er planlagt til behandling og lagring. Disse egenskaber omfatter:
- Datavolumen;
— Oplysninger om datas livscyklus (vækst af nye data, levetid, behandling af forældede data);
— Klassificering af data fra et synspunkt indvirkning på virksomhedens kerneforretning (triaden af fortrolighed, integritet, tilgængelighed) sammen med finansielle indikatorer (f.eks. omkostningerne ved tab af data inden for den sidste time);
— Geografi af databehandling (fysisk placering af behandlingssystemer);
— Lovmæssige krav for hver dataklasse (f.eks. Federal Law-152, PCI DSS).
Informationssystemer
Data lagres ikke kun, men behandles (transformeres) også af informationssystemer. Det næste trin efter opnåelse af dataegenskaberne er den mest komplette opgørelse over informationssystemer, deres arkitektoniske funktioner, indbyrdes afhængighed og infrastrukturkrav i konventionelle enheder for fire typer ressourcer:
— Processorens computerkraft;
— Mængde RAM;
— Krav til datalagringssystemets volumen og ydeevne;
— Krav til datatransmissionsnettet (eksterne kanaler, kanaler mellem IS-komponenter).
I dette tilfælde skal der være krav til hver service/mikroservice som en del af IS.
Separat er det nødvendigt at bemærke, at for korrekt design er tilgængeligheden af data om virkningen af IS på virksomhedens kerneforretning i form af omkostningerne ved IS-nedetid (rubler i timen) obligatorisk.
Trusselsmodel
Der skal være en formel model for trusler, som det er planlagt at beskytte data/tjenester mod. Desuden omfatter trusselsmodellen ikke kun aspekter af fortrolighed, men også integritet og tilgængelighed. De der. For eksempel:
— Fejl i den fysiske server;
— Fejl i kontakten øverst på stativet;
— Afbrydelse af den optiske kommunikationskanal mellem datacentre;
— Fejl i hele det operationelle lagersystem.
I nogle tilfælde skrives trusselsmodeller ikke kun til infrastrukturkomponenter, men også til specifikke informationssystemer eller deres komponenter, såsom en DBMS-fejl med logisk ødelæggelse af datastrukturen.
Alle beslutninger inden for projektet for at beskytte mod en ubeskrevet trussel er unødvendige.
Lovmæssige krav
Hvis de data, der behandles, er underlagt særlige regler fastsat af tilsynsmyndigheder, kræves oplysninger om datasæt og behandling/opbevaringsregler.
RPO/RTO mål
At designe enhver form for beskyttelse kræver, at du har måldatatabsindikatorer og målrettet tjenestegendannelsestid for hver af de beskrevne trusler.
Ideelt set bør RPO og RTO have tilknyttede omkostninger til datatab og nedetid pr. tidsenhed.
Opdeling i ressourcepuljer
Efter at have indsamlet alle de indledende inputoplysninger, er det første skridt at gruppere datasæt og IP i puljer baseret på trusselsmodeller og lovmæssige krav. Typen af opdeling af forskellige puljer bestemmes - programmatisk på systemsoftwareniveau eller fysisk.
Eksempler:
— Kredsløbet, der behandler personoplysninger, er fuldstændig fysisk adskilt fra andre systemer;
— Sikkerhedskopier gemmes på et separat lagersystem.
I dette tilfælde kan puljerne være ufuldstændigt uafhængige, for eksempel er to puljer af computerressourcer defineret (processorkraft + RAM), som bruger en enkelt datalagerpulje og en enkelt datatransmissionsressourcepulje.
Bearbejdningskraft
Abstrakt, processorkraftkravene for et virtualiseret datacenter måles i form af antallet af virtuelle processorer (vCPU'er) og deres konsolideringsforhold på fysiske processorer (pCPU). I dette særlige tilfælde er 1 pCPU = 1 fysisk processorkerne (ekskl. Hyper-Threading). Antallet af vCPU'er summeres på tværs af alle definerede ressourcepuljer (som hver kan have sin egen konsolideringsfaktor).
Konsolideringskoefficienten for belastede systemer opnås empirisk, baseret på eksisterende infrastruktur, eller gennem pilotinstallation og belastningstest. For ubelastede systemer anvendes "best practice". Specifikt nævner VMware det gennemsnitlige forhold som 8:1.
Operativ hukommelse
Det samlede RAM-behov opnås ved simpel summering. Det anbefales ikke at bruge RAM-overabonnement.
Lagerressourcer
Opbevaringskrav opnås ved blot at summere alle pools efter kapacitet og ydeevne.
Ydeevnekrav er udtrykt i IOPS kombineret med et gennemsnitligt læse/skriveforhold og om nødvendigt en maksimal responsforsinkelse.
Quality of Service (QoS)-krav for specifikke puljer eller systemer skal specificeres separat.
Datanetværksressourcer
Datanetværkskravene opnås ved blot at summere alle båndbreddepuljerne.
Quality of Service (QoS) og latency (RTT) krav for specifikke puljer eller systemer bør specificeres separat.
Som en del af kravene til datanetværksressourcer angives også krav til isolering og/eller kryptering af netværkstrafik og foretrukne mekanismer (802.1q, IPSec, etc.).
Valg af arkitektur
Denne vejledning dækker ikke andre valg end x86-arkitektur og 100 % servervirtualisering. Derfor kommer valget af computerundersystemarkitektur ned til valget af servervirtualiseringsplatform, serverformfaktor og generelle serverkonfigurationskrav.
Det vigtigste valg er sikkerheden ved at bruge en klassisk tilgang med adskillelse af funktioner til behandling, lagring og transmission af data eller en konvergent.
klassisk arkitektur involverer brugen af intelligente eksterne undersystemer til lagring og transmission af data, mens servere kun bidrager med processorkraft og RAM til den fælles pulje af fysiske ressourcer. I ekstreme tilfælde bliver servere fuldstændig anonyme, idet de ikke kun har deres egne diske, men ikke engang en system-id. I dette tilfælde indlæses OS eller hypervisor fra indbyggede flashmedier eller fra et eksternt datalagringssystem (boot fra SAN).
Inden for rammerne af klassisk arkitektur er valget mellem klinger og stativer primært taget ud fra følgende principper:
— Omkostningseffektiv (i gennemsnit er rackmonterede servere billigere);
— Beregningstæthed (højere for vinger);
— Energiforbrug og varmeafledning (vinger har en højere specifik enhed pr. enhed);
— Skalerbarhed og kontrollerbarhed (vinger kræver generelt mindre indsats for store installationer);
- Brug af udvidelseskort (meget begrænset valg til blade).
Konvergent arkitektur (også kendt som hyperkonvergeret) involverer at kombinere funktionerne til databehandling og lagring, hvilket fører til brugen af lokale serverdiske og som en konsekvens opgivelse af den klassiske blade-formfaktor. Til konvergerede systemer bruges enten rackservere eller klyngesystemer, der kombinerer flere bladeservere og lokale diske i et enkelt tilfælde.
CPU/hukommelse
For at beregne konfigurationen korrekt skal du forstå typen af belastning for miljøet eller hver af de uafhængige klynger.
CPU bundet – et miljø begrænset i ydeevne af processorkraft. Tilføjelse af RAM vil ikke ændre noget med hensyn til ydeevne (antal VM'er pr. server).
Hukommelse bundet – miljø begrænset af RAM. Mere RAM på serveren giver dig mulighed for at køre flere VM'er på serveren.
GB / MHz (GB / pCPU) – det gennemsnitlige forhold mellem forbrug af RAM og processorkraft ved denne særlige belastning. Kan bruges til at beregne den nødvendige mængde hukommelse for en given ydelse og omvendt.
Beregning af serverkonfiguration
Først skal du bestemme alle typer belastning og beslutte dig for at kombinere eller opdele forskellige computerpuljer i forskellige klynger.
Dernæst bestemmes GB/MHz-forholdet for hver af de definerede klynger ved en på forhånd kendt belastning. Hvis belastningen ikke er kendt på forhånd, men der er en grov forståelse af niveauet for processorkraftudnyttelse, kan du bruge standard vCPU:pCPU-forhold til at konvertere poolkrav til fysiske.
For hver klynge skal du dividere summen af vCPU-puljekrav med koefficienten:
vCPUsum / vCPU:pCPU = pCPUsum – påkrævet antal fysiske enheder. kerner
pCPUsum / 1.25 = pCPUht – antal kerner justeret til Hyper-Threading
Lad os antage, at det er nødvendigt at beregne en klynge med 190 kerner / 3.5 TB RAM. Samtidig accepterer vi en målbelastning på 50 % af processorkraften og 75 % af RAM.
pCPU
190
CPU brug
50 %
hukommelse
3500
Mem nytte
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
I dette tilfælde bruger vi altid afrunding op til nærmeste heltal (=ROUNDUP(A1;0)).
Fra tabellen bliver det tydeligt, at flere serverkonfigurationer er afbalancerede for målindikatorerne:
— 26 servere 2*6c / 192 GB
— 19 servere 2*10c / 256 GB
— 10 servere 2*18c / 512 GB
Valget af disse konfigurationer skal derefter foretages baseret på yderligere faktorer, såsom termisk pakke og tilgængelig køling, servere, der allerede er brugt, eller omkostninger.
Funktioner ved at vælge en serverkonfiguration
Brede VM'er. Hvis det er nødvendigt at være vært for brede VM'er (sammenlignelig med 1 NUMA-node eller mere), anbefales det, hvis det er muligt, at vælge en server med en konfiguration, der tillader sådanne VM'er at forblive inden for NUMA-knuden. Med et stort antal brede VM'er er der fare for fragmentering af klyngresourcer, og i dette tilfælde vælges servere, der gør det muligt at placere brede VM'er så tæt som muligt.
Størrelse af et enkelt fejldomæne.
Valget af serverstørrelse er også baseret på princippet om at minimere det enkelte fejldomæne. For eksempel, når du vælger mellem:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Alt andet lige skal du vælge den anden mulighed, da når en server fejler (eller vedligeholdes), går ikke 33 % af klyngressourcerne tabt, men 17 %. På samme måde halveres antallet af VM'er og IS'er, der er ramt af ulykken.
Beregning af klassiske lagersystemer baseret på ydeevne
Klassiske lagringssystemer beregnes altid ud fra worst case-scenarie, eksklusive påvirkningen af den operationelle cache og optimering af operationer.
Som grundlæggende ydeevneindikatorer tager vi mekanisk ydeevne fra disken (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Derefter beregnes antallet af diske i diskpuljen ved hjælp af følgende formel: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Hvor:
— TotalIOPS – samlet påkrævet ydeevne i IOPS fra diskpuljen
— RW – procentdel af læseoperationer
— RAID pen – RAID-straf for det valgte RAID-niveau
Læs mere om Device RAID og RAID Penalty her - и и
Baseret på det resulterende antal diske, beregnes mulige muligheder, der opfylder kravene til lagerkapacitet, herunder optioner med lager på flere niveauer.
Beregningen af systemer, der bruger SSD som lagerlag, betragtes separat.
Funktioner af beregningssystemer med Flash Cache
Flash cache – et fælles navn for alle proprietære teknologier til brug af flashhukommelse som en cache på andet niveau. Når du bruger en flash-cache, beregnes lagersystemet normalt til at give en konstant belastning fra magnetiske diske, mens toppen betjenes af cachen.
I dette tilfælde er det nødvendigt at forstå belastningsprofilen og graden af lokalisering af adgang til blokke af lagervolumener. Flash-cache er en teknologi til arbejdsbelastninger med meget lokaliserede forespørgsler og er praktisk talt uanvendelig til ensartet indlæste volumener (såsom for analysesystemer).
Beregning af low-end/mid-range hybridsystemer
Hybride systemer af lavere og middelklasse bruger lagring på flere niveauer med data, der flytter mellem niveauer efter en tidsplan. Samtidig er størrelsen på multi-level storage-blokken for de bedste modeller 256 MB. Disse funktioner tillader os ikke at betragte tiered storage-teknologi som en teknologi til at øge produktiviteten, som mange mennesker fejlagtigt tror. Multi-level storage i lav- og mellemklassesystemer er en teknologi til optimering af lageromkostninger for systemer med udtalte belastningsujævnheder.
For lagdelt lager beregnes ydeevnen af det øverste lag først, mens det nederste lager anses for kun at bidrage til den manglende lagerkapacitet. For et hybrid multi-tier-system er det obligatorisk at bruge flash-cache-teknologi til multi-tier-puljen for at kompensere for ydeevnenedsættelsen for pludseligt opvarmede data fra det lavere niveau.
Brug af en SSD i en lagdelt diskpool
Brugen af SSD'er i en diskpulje på flere niveauer har variationer, afhængigt af den specifikke implementering af flash-cache-algoritmer af en given producent.
Den generelle praksis for lagerpolitik for en diskpool med et SSD-niveau er SSD først.
Skrivebeskyttet Flash-cache. For en skrivebeskyttet flash-cache kommer lagerlaget på SSD'en med betydelig lokalisering af skrivninger, uanset cachen.
Læs/skriv Flash-cache. I tilfælde af flash-cache indstilles skrive-cache-størrelsen først til den maksimale cache-størrelse, og SSD-lagerniveauet vises kun, når cachestørrelsen er utilstrækkelig til at betjene hele den lokaliserede arbejdsbyrde.
SSD- og cache-ydelsesberegninger foretages hver gang baseret på producentens anbefalinger, men altid i det værste tilfælde.
Kilde: www.habr.com